Desenvolupament d’una aplicació web per a una ONG

Títol: Desenvolupament d’una aplicació web per a una ONG Volum: 1 Alumne: Marc Ginesta Marquès Director/Ponent: Maria Carme Quer Bosor Departament: LSI Data: 30 de juny de 2009 DADES DEL PROJECTE Títol del Projecte: Desenvolupament d’una aplicació web per a una ONG Nom de l'estudiant: Marc Ginesta Marquès Titulació: Enginyeria Tècnica en Informàtica de Gestió Crèdits: 22,5 Director/Ponent: Maria Carme Quer Bosor Departament: LSI MEMBRES DEL TRIBUNAL (nom i signatura) Presidenta: Cristina Gómez Seoane Vocal: Joan Trias Pairó Secretària: Maria Carme Quer Bosor QUALIFICACIÓ Qualificació numèrica: Qualificació descriptiva: Data: Desenvolupament d’una aplicació web per a una ONG - 1 - Índex 1 Context del Projecte _____________________________________________________3 2 Objectiu del Projecte_____________________________________________________4 3 Etapes del projecte ______________________________________________________5 4 Planificació i estudi econòmic _____________________________________________6 4.1 Planificació _____________________________________________________________ 6 4.2 Estudi econòmic _________________________________________________________ 8 5 Anàlisi de requeriments _________________________________________________ 11 5.1 Descripció textual de l’aplicació ___________________________________________ 11 6 Requeriments detallats __________________________________________________14 6.1 Requeriments Funcionals ________________________________________________ 14 6.2 Requeriments No Funcionals _____________________________________________ 19 7 Especificació __________________________________________________________22 7.1 Diagrames de casos d’ús _________________________________________________ 22 7.2 Descripció de casos d’ús__________________________________________________ 25 7.3 Diagrama de classes _____________________________________________________ 43 8 Disseny i implementació de l’aplicació en la metodologia tradicional_____________46 8.1 Arquitectura i plataforma ________________________________________________ 46 8.2 Disseny de la base de dades _______________________________________________ 47 8.3 Disseny dels tractaments _________________________________________________ 54 8.4 Implementació _________________________________________________________ 58 9 Desenvolupament sobre un Sistema Gestor de Continguts (CMS)________________73 9.1 Què són els CMS?_______________________________________________________ 73 9.2 Justificació de l’ús i implantació d’un CMS _________________________________ 73 9.3 Selecció d’un CMS ______________________________________________________ 75 9.4 Disseny i implementació de l’aplicació a partir del CMS escollit ________________ 81 10 Proves _______________________________________________________________94 Desenvolupament d’una aplicació web per a una ONG - 2 - 11 Comparació de les dues metodologies de desenvolupament ___________________96 12 Comparació de característiques no-funcionals de les aplicacions obtingudes ___100 13 Consideracions finals ________________________________________________103 14 Conclusions________________________________________________________105 Annex I: Instal·lació de Drupal ______________________________________________106 Annex II: Instal·lació d’un tema a Drupal _____________________________________108 Annex III: Instal·lació d’un mòdul a Drupal ___________________________________ 110 Bibliografia ______________________________________________________________ 111 Desenvolupament d’una aplicació web per a una ONG - 3 - 1 Context del Projecte La Fundació UBUNTU és una ONG d’origen català presidida per Federico Mayor Zaragoza i amb seu a Barcelona que, per fer front al procés de globalització que sofreix el món en l’actualitat, s’encarrega de coordinar les activitats de les diferents organitzacions d’arreu del món que formen la societat civil internacional per tal que puguin incidir en els òrgans de govern, tant nacionals com internacionals, de manera que la societat civil pugui donar la seva opinió i tingui certa capacitat de decisió en aspectes polítics, socials, culturals i econòmics que afecten a tots els habitants del planeta. En aquest marc, l’ONG es planteja la necessitat d’un espai virtual on determinades organitzacions de la societat civil i estats implicats puguin publicar i compartir documents a fi de discutir-ne el contingut i intercanviar opinions sobre temes concrets. És per això que la Fundació UBUNTU m’ha encomanat el desenvolupament d’una aplicació que permeti dur a terme totes les funcionalitats esmentades anteriorment, per les quals es pot deduir clarament l’estructuració de l’aplicació en un fòrum. Per altra banda, em trobo al final de la carrera i necessito escollir un projecte (PFC). Tot i que inicialment he pensat d’agafar l’aplicació que em proposen com a projecte, després de rumiar-ho, considero que no té entitat suficient. Malgrat tot, com que sembla una aplicació interessant, he buscat la manera d’estendre-la per aconseguir un projecte amb prou gruix. La idea, doncs, és desenvolupar el fòrum amb la metodologia que fa servir l’ONG actualment i desenvolupar-lo posteriorment a partir d’un gestor de continguts (Content Management System, CMS) per tal de comparar les metodologies i el funcionament de l’aplicació; i en funció dels resultats obtinguts valorar la possibilitat d’implantació del CMS als llocs web de la Fundació UBUNTU, ja que segons la meva opinió la plataforma actual es basa en un sistema arcaic i poc amigable. Desenvolupament d’una aplicació web per a una ONG - 4 - 2 Objectiu del Projecte El projecte pretén fer el seguiment del procés comentat en el capítol anterior. Així doncs, d’una banda l’objectiu és desenvolupar l’aplicació amb un enfocament més tradicional seguint la metodologia usada per l’ONG sobre la plataforma habitual, i de l’altra, desenvolupar l’aplicació a partir de la implantació d’un gestor de continguts (CMS) que faciliti la feina a l’hora de crear nous continguts i gestionar-los. Tanmateix, del segon cas, se’n desprenen alguns objectius addicionals: • Fer un estudi de mercat sobre els CMS existents (escollir els més adequats en funció dels requeriments, característiques, diferències significatives, etc.). • Escollir un CMS adequat d’acord amb els requeriments de l’ONG. • Desenvolupar l’aplicació usant el CMS escollit. Finalment, un cop desenvolupades les dues aplicacions, també es vol: • Comparar el procés de desenvolupament tradicional enfront d’un desenvolupament basat en productes ja existents i veure els avantatges i inconvenients de cada un. • Comparar algunes característiques no-funcionals d’ambdues aplicacions que vénen donades pel fet de la plataforma sobre la que s’han implementat. • Valorar la possibilitat d’implantació permanent del CMS. Desenvolupament d’una aplicació web per a una ONG - 5 - 3 Etapes del projecte El procés de desenvolupament del software sol dividir-se en les següents etapes: anàlisi de requeriments, especificació, disseny, implementació i proves. Abans de començar pròpiament amb el desenvolupament, es va realitzar una planificació inicial del projecte, i en finalitzar-lo s’ha fet una planificació on es presenta el temps que s’ha trigat realment en cada etapa. Ambdues planificacions, inicial i final, es poden trobar al capítol 4 juntament amb l’estudi econòmic. A continuació, es va procedir a fer l’anàlisi de requeriments i l’especificació, que al ser activitats que no depenen de la tecnologia, són comunes a les dues metodologies de desenvolupament. El resultat d’aquestes etapes s’exposa en els capítols 5, 6 i 7. Les etapes de disseny i implementació es van realitzar de manera específica per les dues plataformes d’explotació. El resultat d’aquestes etapes per a l’aplicació programada a mida es descriu al capítol 8, i el resultat per a l’aplicació que s’ha desenvolupat en un CMS, al capítol 9, el qual conté l’estudi i la comparació de CMS que s’ofereixen en el mercat de components software. Tot seguit, al capítol 10, es presenten les proves que es van realitzar immediatament després de l’etapa d’implementació de cada aplicació, les quals són comunes a les dues plataformes de desenvolupament. Aleshores, vaig dur a terme la comparació de les dues metodologies de desenvolupament i la comparació de les característiques no-funcionals de les aplicacions obtingudes. El resultat d’aquests dos estudis es presenta als capítols 11 i 12. Per acabar, es poden trobar les consideracions finals al capítol 13 i les conclusions al capítol 14. Desenvolupament d’una aplicació web per a una ONG - 6 - 4 Planificació i estudi econòmic 4.1 Planificació Tot seguit, es presenten les planificacions inicial i final de forma conjunta, tot i que s’han realitzat per separat (una al principi del projecte i l’altra en acabar-lo), per tal de poder contrastar les diferències entre les dues. En un principi, la idea era començar el desenvolupament del projecte en un quadrimestre i aleshores, a mesura que anés agafant forma, matricular-lo per tal de presentar-lo en el quadrimestre següent; és a dir, dur-lo a terme en el període equivalent a un any acadèmic ja que per motius laborals m’era difícil realitzar-lo en un quadrimestre. Malgrat fer la planificació inicial, és difícil seguir-la al peu de la lletra i sempre hi pot haver contratemps que allarguin més del que s’espera determinades fases. A més, estudiar i treballar al mateix temps pot comportar un cert risc per finalitzar-ho tot com s’ha planejat. Per això no s’ha pogut complir els terminis fixats i s’ha allargat més dels 2 quadrimestres esperats degut a la dedicació irregular en el projecte. Tasca Estimació durada (h) Durada (h) Diferència (h) Anàlisi de Requeriments 20 40 20 Especificació 40 80 40 Disseny de la base de dades 20 20 0 Disseny dels tractaments 20 20 0 Implementació 100 160 60 Proves 20 20 0 Cerca d'informació sobre CMS 20 30 10 Estudi de mercat CMS 20 30 10 Cerca d’estudis comparatius 20 30 10 Cerca d’eines per comparar CMS 20 30 10 Selecció i comparació de CMS candidats 20 60 40 Aprenentatge del CMS escollit 120 300 180 Disseny de les dades 20 40 20 Disseny de l’aplicació 20 40 20 Implementació 20 30 10 Proves 20 30 10 Comparació de metodologies 20 30 10 Comparació característiques no-funcionals 20 20 0 Conclusions 20 30 10 Total 580 1040 460 Com es pot apreciar a la taula, el nombre real d’hores dedicades és clarament superior al que s’havia planejat. A part de les petites variacions que es poden Desenvolupament d’una aplicació web per a una ONG - 13 - 5.1.1.2 Administrador (Admin) És l’usuari encarregat de gestionar el contingut del fòrum, configurar les seves propietats i gestionar els usuaris. A més, pot dur a terme les mateixes accions que l’usuari Normal, però en aquest cas no es tindran en compte les seves visions de fitxes per a obtenir el còmput total de visionats ni tampoc es registraran els seus accessos. Hi haurà un únic usuari d’aquest tipus que, en principi, correspondrà a un membre de l’organització client. 5.1.1.3 Invitat (Guest) Es pot comparar el comportament de l’usuari Invitat al d’un observador ja que en accedir a l’aplicació podrà visitar qualsevol secció, llistar documents, descarregar-los i visualitzar-ne les fitxes però en cap cas podrà pujar-ne, deixar comentaris o penjar notícies. En quant a la zona d’administració, tan sols podrà llegir la informació del registre, és a dir, els accessos de cada usuari. No podrà crear, esborrar o modificar usuaris, donar d’alta o de baixa seccions ni categories. Pel que fa al visionat de fitxes i al registre dels accessos al fòrum, es procedirà igual que en l’usuari Administrador. D’ara en endavant, es referirà als usuaris esmentats com Normal, Admin i Guest. Desenvolupament d’una aplicació web per a una ONG - 14 - 6 Requeriments detallats 6.1 Requeriments Funcionals Tenint en compte la descripció de l’apartat anterior, s’obtenen les següents necessitats: 6.1.1 Estructura L’aplicació ha de requerir a l’usuari el seu nom d’usuari i contrasenya per accedir a l’aplicació, visualitzar el contingut i fer ús de totes les seves funcionalitats. L’aplicació ha de considerar com a mínim 3 rols d’usuari diferents: • Normal: amb accés de lectura i escriptura en determinats continguts. • Administrador: amb accés total al contingut, tant de lectura com escriptura. • Invitat: amb accés total de lectura i restringit o nul d’escriptura. L’aplicació ha de disposar, com a mínim, d’un menú per accedir a les pàgines i seccions que la formen. A més ha d’integrar un element per accedir a l’àrea d’administració i un altre que permeti tancar les sessions als usuaris. Hi ha d’haver una pàgina que contingui informació general per als usuaris, de la qual pengin diferents pàgines amb informació sobre l’aplicació. L’aplicació s’ha d’estructurar en un nombre concret de seccions, on cadascuna tindrà el seu llistat de documents i notícies. 6.1.1.1 Seccions Una secció es pot trobar activada o bé desactivada. Si una secció està desactivada, no s’ha de poder realitzar cap acció en ella i s’ha d’indicar que es troba desactivada. Inicialment, en una secció activada s’han de mostrar un màxim de 5 documents i 10 notícies. L’aplicació ha de permetre a l’usuari llistar tots els documents i notícies. Cada secció activada ha d’oferir la possibilitat als usuaris de penjar noves notícies i pujar nous documents. Desenvolupament d’una aplicació web per a una ONG - 15 - 6.1.1.2 Notícies Per tal de penjar una notícia a una secció, l’aplicació ha de demanar el títol i el cos d’aquesta. L’aplicació no ha de permetre pujar notícies sense cos, però en canvi, sí que pot permetre penjar-ne sense títol. Per cada notícia penjada s’ha de mostrar el títol, el cos, la data i hora quan va ser penjada i el nom d’usuari de la persona que l’ha penjada. A part, si l’usuari és administrador s’han de mostrar les opcions per tal de modificar (editar o esborrar) la notícia. Quan aquest usuari editi la notícia, l’aplicació ha de permetre modificar tant el títol com el cos d’aquesta. 6.1.1.3 Documents Quan un usuari demani pujar un document a una secció, l’aplicació ha de requerir, a més dels fitxers en sí, el títol, l’autor, la data de creació/publicació del document, la secció on s’ha de pujar, la categoria i la subcategoria. Pel que fa a aquests dos últims atributs, s’utilitzaran per a la classificació dels documents i l’aplicació ha d’oferir una llista amb diferents opcions a escollir. A la llista de documents d’una secció s’ha de visualitzar la data de publicació/creació del document, el títol, l’autor, el moment en què va ser pujat a l’aplicació, la categoria i la subcategoria, el nombre de comentaris i les vegades que s’ha visitat la fitxa del document. La llista de documents s’ha d’ordenar per defecte segons la data de publicació/creació, del més al menys recent, i l’aplicació ha de donar la possibilitat a l’usuari d’elegir el criteri d’ordenació, el qual pot ser qualsevol dels atributs que es mostren a la llista. A més, per cada document que estigui a la llista, l’atribut títol de cada document ha de permetre accedir a la fitxa d’aquest. La fitxa del document ha d’estar formada per la llista d’atributs que va introduir prèviament l’usuari en pujar-lo; és a dir, s’han de visualitzar el títol, l’autor, la data de creació/publicació, la secció on està penjat, la categoria, la subcategoria, i la llista de fitxers d’aquest document, cadascun dels quals ha de permetre als usuaris la seva visualització i descàrrega. A més, la fitxa ha d’indicar quin usuari ha pujat el Desenvolupament d’una aplicació web per a una ONG - 16 - document i la data i hora en què es va fer. A part, si l’usuari és administrador, s’han de mostrar les opcions per tal de modificar les dades referents al document. L’administrador ha de poder editar el títol, l’autor, la data de creació/publicació, la secció on es troba, la categoria, la subcategoria i l’usuari que va pujar el document a l’aplicació. També ha de tenir la possibilitat d’esborrar el document de l’aplicació. En aquest cas, s’esborrarà de l’aplicació el document, els seus comentaris, i els fitxers que li corresponen. D’altra banda, la fitxa ha de contenir, a continuació dels atributs del document, una llista amb un màxim de 10 comentaris ordenats cronològicament del més al menys recent i ha de permetre visualitzar tots els que s’han deixat sobre el document. A més, cada fitxa ha d’oferir la possibilitat de deixar-ne de nous. 6.1.1.4 Comentaris Per tal de deixar un comentari a un document, l’aplicació ha de demanar el text d’aquest. L’aplicació no ha de permetre deixar comentaris buits. Per cada comentari, s’ha de mostrar l’usuari que l’ha deixat, la data i hora en què s’ha escrit i el text d’aquest. Si l’usuari és administrador, l’aplicació ha de permetre modificar-lo (editar-lo o esborrar-lo). Quan l’usuari editi el comentari tan sols ha de poder modificar el text, i l’aplicació no ha de permetre cap comentari que estigui buit. 6.1.2 Administració L’àrea d’administració només ha de ser accessible per als usuaris de tipus Admin. Aquesta ha de permetre gestionar els usuaris, les organitzacions, les seccions, els documents, les categories i les subcategories; i també ha de permetre llistar quins usuaris han entrat a l’aplicació i el moment en què s’ha produït aquest accés. Les accions que es detallen a continuació es duen a terme únicament des de l’àrea d’administració i per l’usuari administrador, a no ser que s’especifiqui el contrari. 6.1.2.1 Usuaris L’aplicació ha de permetre crear usuaris, modificar-los i esborrar-los. Quan es creï un nou usuari, l’aplicació ha de requerir el nom, els cognoms, l’email, un email alternatiu, el tipus d’usuari, l’estat (activat/desactivat), l’idioma, el tracte (com cal adreçar-s’hi; per exemple: Doctor), i l’organització a la que pertany. L’aplicació ha Desenvolupament d’una aplicació web per a una ONG - 17 - d’assignar un contrasenya generada automàticament en crear un nou usuari. Dins del procés d’alta d’un usuari, l’aplicació ha de donar la possibilitat d’enviar un correu electrònic a les adreces introduïdes prèviament (als camps email i email alternatiu) notificant que s’ha creat un compte i facilitant l’adreça URL per accedir a l’aplicació, el nom d’usuari i la contrasenya. Cal tenir en compte les següents premisses: • El nom d’usuari (necessari per accedir a l’aplicació) que s’assigna ha de ser, per norma general, l’email de l’usuari. • Per a l’atribut idioma, l’aplicació ha de donar les següents possibilitats: anglès, francès, espanyol i català. • Per a l’atribut tipus d’usuari, l’aplicació ha d’oferir les següents possibilitats: administrador, invitat i normal. • L’email alternatiu i el tracte no han de ser obligatoris, poden deixar-se buits, a diferència de la resta d’atributs. Quan s’editi un usuari es podran modificar tots els seus camps, és a dir, el nom, els cognoms, l’email, un email alternatiu, el tipus d’usuari, l’estat, l’idioma, el tracte, i l’organització a la que pertany. També se li ha de poder assignar una nova contrasenya. A banda, qualsevol usuari (sigui del tipus que sigui) ha de tenir la possibilitat de modificar la seva contrasenya el primer cop que entri a l’aplicació, externament a l’àrea d’administració. Quan s’esborra un usuari s’han de conservar tots els documents, comentaris i notícies que ha pujat o escrit durant el seu període d’activitat. 6.1.2.2 Organitzacions L’aplicació ha de permetre l’alta, la baixa i la modificació d’organitzacions. Per donar d’alta una organització l’aplicació requerirà el nom i el tipus d’organització. En aquest últim cas, l’aplicació donarà a escollir entre les següents opcions: Organizations, States i Others. Desenvolupament d’una aplicació web per a una ONG - 18 - L’aplicació permetrà editar tots dos atributs quan l’usuari modifiqui una organització. Respecte a la baixa d’organitzacions, només permetrà esborrar aquelles que no estiguin associades a cap usuari. 6.1.2.3 Seccions En principi, hi ha un nombre concret de seccions i per això, de cara a l’administració, només es contemplen les opcions d’activació i desactivació de seccions. No es tenen en compte les accions d’alta i baixa tot i que des d’un punt de vista de completesa s’haurien de tenir en compte. Respecte a la modificació d’atributs, es podrà editar el nom de les seccions. 6.1.2.4 Documents Pel que fa a documents, s’han descrit anteriorment les accions d’alta, baixa i modificació. Respecte a l’àrea d’administració, l’aplicació ha de permetre llistar tots els documents que s’han pujat. En aquesta llista ha de constar com a mínim el títol del document, el qual ha de permetre accedir a la seva fitxa per tal de modificar-lo, deixar comentaris o esborrar-lo. A part, s’ha de poder realitzar la baixa de múltiples documents simultàniament. 6.1.2.5 Categories / Subcategories S’agrupen en un mateix apartat categories i subcategories per la seva analogia, tot i que s’han de gestionar de manera independent. A continuació, quan es faci referència a categories, serà vàlid també per a subcategories. L’aplicació ha de donar la possibilitat de crear categories, visualitzar les existents, modificar-les i esborrar-les. Quan es vulgui crear una nova categoria, l’aplicació requerirà únicament el nom, i l’usuari administrador l’ha de poder editar en tot moment. Pel que fa a la baixa de categories, només es permetrà esborrar aquelles que no estiguin associades a cap document. 6.1.2.6 Llistats L’àrea d’administració ha de permetre llistar, a mode informatiu, quins han estat els últims accessos dels usuaris a l’aplicació. El llistat ha de contenir el nom i els cognoms de l’usuari, el nom d’usuari i la data i hora de l’últim accés, en cas que existeixi. El llistat ha d’estar ordenat segons la data i hora de l’últim accés de forma Desenvolupament d’una aplicació web per a una ONG - 19 - descendent. En aquest cas, l’usuari Guest també podrà visualitzar el llistat d’accessos. 6.2 Requeriments No Funcionals A diferència dels requeriments funcionals (els quals descriuen les accions que ha de realitzar el software, el processos d’entrada i sortida de dades, etc.), els requeriments no funcionals defineixen les qualitats que ha de complir l’aplicació en realitzar la seva funció. Per tal d’avaluar-los en profunditat, s’agafa com a base l’estàndard ISO/IEC 9126-1 [i] , el qual permet avaluar la qualitat del software. A banda, s’utilitza l’extensió NTISO/IEC 9126 [ii] de l’estàndard esmentat per tal de poder avaluar aspectes no tècnics, com ara, la vessant econòmica del software usat. Tot seguit, es descriuen els requeriments no funcionals de l’aplicació agrupats segons les característiques que defineix l’estàndard esmentat. 6.2.1 Seguretat Capacitat del producte software per protegir la informació i les dades de manera que les persones o sistemes no autoritzats no les puguin llegir ni modificar, al mateix temps que no es denega l’accés a persones ni sistemes autoritzats. - L’aplicació ha de treballar sobre el protocol HTTPS (HTTP segur), ja que es tracta d’un fòrum privat que necessita l’intercanvi segur de fitxers. - L’aplicació ha d’utilitzar contrasenyes per tal d’identificar i autentificar els usuaris. - L’aplicació ha d’emmagatzemar xifrades 1 les contrasenyes de tots els usuaris de l’aplicació. 6.2.2 Fiabilitat Capacitat del producte software de mantenir el nivell de prestació sota condicions establertes durant un període de temps establert. (maduresa, recuperabilitat). - L’aplicació ha d’estar disponible en tot moment als dominis tablefordialogue.net i 1 Xifrar: Mantenir ocult per mitjà d’alguna tècnica de criptografia, per exemple, MD5 Desenvolupament d’una aplicació web per a una ONG - 20 - tablefordialogue.org, perquè són els dos dominis que destina al client per hostatjar l’aplicació. - S’ha de realitzar una còpia de seguretat de l’aplicació diàriament, de manera que en cas de baixa del sistema es pugui restaurar la del dia anterior. 6.2.3 Usabilitat Capacitat del producte software per ser entès, après, usat i ser atractiu per als usuaris finals, quan s’utilitza sota condicions concretes. - La interfície gràfica d’usuari ha de ser desenvolupada en anglès, ja que és l’idioma que dominen tots els usuaris de l’aplicació. - L’aplicació ha de ser fàcil d’utilitzar i el més intuïtiva possible, perquè es tracta d’usuaris, en la seva majoria, no experts. - L’aplicació ha de disposar d’eines que permetin administrar els continguts, els usuaris i l’aparença de la forma més senzilla possible. - L’aplicació haurà de respectar, sempre que sigui possible, els estàndards web establerts pel W3C respecte a accessibilitat, internacionalització i independència de dispositius. 6.2.4 Eficiència Capacitat del producte software per proporcionar prestacions adequades, relatives a la quantitat de recursos usats, sota condicions determinades. - El temps de resposta de l’aplicació ha de ser acceptable ja que no mou grans quantitats d’informació ni espera gran concurrència d’usuaris. Habitualment [iii] s’espera una resposta d’un màxim de 2 segons. Excepcionalment, es fixa una resposta màxima de 8 segons. 6.2.5 Mantenibilitat Conjunt d’atributs relacionats amb la facilitat d’estendre, modificar o corregir errors en un producte software (anàlisi, canvi, proves). - L’especificació s’ha de realitzar en llenguatge UML, per imposició del desenvolupador pel fet que es tracta d’un llenguatge estàndard que facilita la Desenvolupament d’una aplicació web per a una ONG - 21 - comprensió i l’extensió. - L’aplicació ha de treballar sempre amb versions estables del software. Les versions no estables queden restringides a aplicacions en proves. 6.2.6 Portabilitat Capacitat d’un producte software per ser transferit d’una plataforma a una altra. (instal·lació, reemplaçament, adaptabilitat). - L’aplicació ha de visualitzar-se correctament, com a mínim, en els següents navegadors: Internet Explorer (versions 6 i 7) i Mozilla Firefox (versions 2 i 3), ja que són els més utilitzats entre els usuaris [iv] . - L’aplicació ha de desenvolupar-se sobre un servidor Apache, s’ha de programar en PHP5 i ha d’utilitzar MySQL com a sistema gestor de bases de dades. - La base de dades de l’aplicació ha de poder administrar-se amb eines específiques per a bases de dades, com ara PHPMyAdmin. - Només es permetrà pujar documents a l’aplicació en format PDF, pel fet que és un format estàndard i de lliure accés. 6.2.7 Negoci Característiques del contracte entre el proveïdor i el client que poden influir en la qualitat del software. - Costos de llicència: El software utilitzat per al desenvolupament i gestió de l’aplicació ha de ser gratuït. Desenvolupament d’una aplicació web per a una ONG - 22 - 7 Especificació En aquest capítol es presenten els diagrames de casos d’ús propis de cada usuari i seguidament es fa la descripció d’aquests d’acord amb els requeriments funcionals explicats en el capítol 6. Requeriments detallats. Per acabar, es presenta el diagrama de classes, amb i sense atributs. 7.1 Diagrames de casos d’ús 7.1.1 Usuari Normal L’usuari Normal té assignats els següent casos d’ús: Desenvolupament d’una aplicació web per a una ONG - 29 - 7.2.2.4 Generar una contrasenya per a un usuari Entrades id_usuari:int, notificar:bool Sortides Retorna cert si no es dóna cap error. Semàntica Genera una contrasenya de forma aleatòria per a l’usuari identificat per id_usuari. Flux d’interacció Usuari Sistema Selecciona l’opció de generar una nova contrasenya per a l’usuari id_usuari. Assigna una nova contrasenya generada aleatòriament a l’usuari identificat per id_usuari i es guarda a la base de dades. Finalment, li envia un email notificant-li el canvi. Cursos alternatius Si l’usuari desmarca la casella de notificació, no se li envia cap email. 7.2.2.5 Canviar la contrasenya Entrades new_pass:String, repeated_pass:String Sortides Retorna cert si no es dóna cap error. Semàntica Canvia la contrasenya de l’usuari que està utilitzant l’aplicació per una que ell introdueix. Flux d’interacció Usuari Sistema Introdueix la nova contrasenya dues vegades de forma separada. Si coincideixen, s’emmagatzema la nova contrasenya i se li demana a l’usuari que torni a entrar a l’aplicació. Cursos alternatius Si no coincideixen les contrasenyes new_pass i repeated_pass, no es canvia la contrasenya i es notifica l’error a l’usuari. 7.2.3 Casos d’ús de secció El fòrum s’organitza, en principi, en un nombre fix de seccions, on cadascuna té els seus propis documents i notícies. Una secció pot estar activada o desactivada. Els usuaris tan sols poden pujar documents i penjar notícies en aquelles seccions que es trobin activades. D’acord amb l’anterior paràgraf, els casos d’ús que es poden dur a terme són: llistar els documents i notícies de les seccions, activar/desactivar seccions, modificar-ne la informació, pujar documents i penjar notícies (aquestes dues últimes explicades en els apartats 7.2.4.1 i 7.2.5.1, respectivament). Desenvolupament d’una aplicació web per a una ONG - 30 - 7.2.3.1 Llistar una secció Esquema típic d’una secció Entrades id_seccio:int Sortides No n’hi ha. Semàntica Llista els documents i les notícies de la secció identificada per id_seccio. Flux d’interacció Usuari Sistema Escull la secció que desitja llistar del menú principal. Mostra una llista dels cinc documents més recents (amb els seus atributs propis: títol, autor, data, categoria, versions, etc.), a continuació una llista de les deu últimes notícies de la secció escollida, i finalment una zona on poder introduirne de noves. Cursos alternatius En cas que no hi hagi documents per la secció escollida, es notifica a l’usuari tal situació. Menú principal que conté cadascuna de les seccions Llista dels documents d’una secció Llista de les notícies d’una secció Zona per introduir notícies a la secció Menú d’accions de l’usuari Desenvolupament d’una aplicació web per a una ONG - 31 - 7.2.3.2 Activació de seccions Entrades id_seccio:int Sortides Retorna cert si s’ha activat sense problemes. Semàntica Activa la secció identificada per id_seccio. Flux d’interacció Usuari Sistema Escull la secció que desitja activar i confirma. Activa la secció escollida per l’usuari. Cursos alternatius Si l’usuari no confirma, es cancel·la l’acció. 7.2.3.3 Desactivació de seccions Entrades id_seccio:int Sortides Retorna cert si s’ha desactivat sense problemes. Semàntica Desactiva la secció identificada per id_seccio. Flux d’interacció Usuari Sistema Escull la secció que desitja desactivar i confirma. El sistema desactiva la secció escollida per l’usuari. Cursos alternatius Es cancel·la l’acció si l’usuari no confirma. Desenvolupament d’una aplicació web per a una ONG - 32 - 7.2.3.4 Modificació de seccions Entrades id_seccio:int, nom_seccio:String Sortides Retorna cert si s’ha modificat sense problemes. Semàntica Canvia el nom de la secció identificada per id_seccio. Flux d’interacció Usuari Sistema Escull la secció que vol modificar. Llista els atributs propis d’una secció i permet editar-los. Realitza els canvis i escull l’opció de guardar-los del menú d’opcions. Emmagatzema els canvis realitzats sobre la secció a la base de dades. Cursos alternatius Si les dades introduïdes no són vàlides, el sistema notifica el problema i no s’actualitzen les dades. 7.2.4 Casos d’ús de document Tal com s’ha explicat anteriorment els usuaris poden pujar documents a les seccions del fòrum. En fer-ho es requereix, a més del/s document/s en sí, una sèrie de dades que l’identifiquen, les quals són emmagatzemades a la base de dades de l’aplicació. Posteriorment, quan l’usuari ho demana, aquestes dades són presentades a l’usuari en una fitxa, on hi ha la possibilitat de deixar-hi comentaris, visualitzar i descarregar el/s document/s. D’altra banda, l’usuari administrador duu la gestió de documents, de manera que pot modificar-los i donar-los de baixa, és a dir, esborrar-los del fòrum. Desenvolupament d’una aplicació web per a una ONG - 33 - 7.2.4.1 Pujar documents a una secció Esquema de la pantalla per pujar un document Entrades id_seccio:int, titol_doc:String, autor_doc:String, data_doc:Date, categoria:int, subcategoria:int, fitxers[]:File Sortides Retorna cert si ha pogut pujar els fitxers al servidor i no s’ha donat cap error. Semàntica Enregistra un nou document amb les dades d’entrada i l’associa amb la secció identificada per id_seccio. Puja els fitxers al servidor en el directori corresponent. Flux d’interacció Usuari Sistema Omple els camps requerits per un document (títol, autor, data, secció on s’ha de llistar, categoria, subcategoria i els fitxers amb les diferents versions) i escull les versions del document a pujar. Si les dades són vàlides, es guarda el document a la base de dades i s’emmagatzemen les diferents versions del document al servidor. Cursos alternatius Si les dades introduïdes no són vàlides, el sistema no guarda el document i no emmagatzema les diferents versions d’aquest. Notifica a l’usuari quines dades cal corregir. (zona per imprimir notificacions) Menú principal que conté cadascuna de les seccions Zona on es demanen els camps per crear la fitxa del document Zona on se seleccionen els fitxers amb les diferents versions del document Menú d’accions de l’usuari Desenvolupament d’una aplicació web per a una ONG - 34 - 7.2.4.2 Veure la fitxa d’un document Esquema de la fitxa d’un document Entrades id_document:int Sortides Retorna cert si el document existeix. En cas contrari, operació invàlida i es notifica l’error a l’usuari. Semàntica Visualitzar els atributs del document identificat per id_document i els comentaris relacionats. Flux d’interacció Usuari Sistema Escull el document que vol consultar de la llista de documents d’una secció determinada. Mostra les dades pròpies d’un document (títol, autor, data de publicació, secció on està penjat, categoria, subcategoria, etc.). Llista els comentaris que han deixat els usuaris sobre aquest document, en cas que n’hi hagi. S’incrementa el nombre de visites a la fitxa del document. Cursos alternatius Si l’usuari és admin, podrà editar la fitxa i els comentaris del document. Si l’usuari és admin o guest, no s’incrementa el nombre de visites a la fitxa del document. Menú principal que conté cadascuna de les seccions Llista dels atributs propis del document i les versions de què disposa Llista dels comentaris sobre el document Zona per introduir comentaris sobre document Menú d’accions de l’usuari Menú d’opcions de la fitxa del document Desenvolupament d’una aplicació web per a una ONG - 35 - 7.2.4.3 Visualitzar/Descarregar un document Entrades fitxer:URL Sortides Retorna cert si el fitxer existeix. En cas contrari, operació invàlida i es notifica l’error a l’usuari. Semàntica Descarregar el fitxer emmagatzemat a al servidor a partir de la seva URL. Flux d’interacció Usuari Sistema Escull el document que vol visualitzar, ja sigui a la llista de documents d’una secció o bé a la fitxa del propi document. Permet la visualització o la descàrrega del document. Cursos alternatius No n’hi ha. 7.2.4.4 Baixa de documents Entrades id_document:int Sortides Retorna cert si no es dóna cap error. Semàntica Esborra el document identificat per id_document, els comentaris i els fitxers associats. Flux d’interacció Usuari Sistema Escull els documents que vol esborrar de l’aplicació. Demana que l’administrador confirmi la baixa dels documents seleccionats. Confirma la baixa dels documents seleccionats. Esborra els documents i els seus comentaris de la base de dades i les diferents versions que s’han pujat al servidor. Cursos alternatius Si l’usuari no confirma la baixa dels documents, es cancel·la l’operació. Desenvolupament d’una aplicació web per a una ONG - 36 - 7.2.4.5 Modificació de documents Entrades id_document:int, titol_doc:String, autor_doc:String, data_doc:Date, id_seccio:int, categoria:int, subcategoria:int, uploader:int Sortides Retorna cert si no es dóna cap error. Semàntica Modifica els atributs del document identificat per id_document. Flux d’interacció Usuari Sistema Escull l’opció d’edició del menú d’opcions de la fitxa del document. Llista els atributs propis del document i permet editar-los. Realitza els canvis i escull l’opció de guardar-los del menú d’opcions de la fitxa. Emmagatzema els canvis realitzats sobre el document a la base de dades. Cursos alternatius Si les dades introduïdes no són vàlides, el sistema no actualitza les dades i notifica el problema a l’usuari. Si l’usuari cancel·la l’operació, no s’emmagatzema cap dels canvis realitzats. 7.2.5 Casos d’ús de notícies Les notícies són els comentaris que deixen els usuaris en una secció. Per tal d’accedir als casos d’ús d’una notícia s’ha de fer des de la mateixa secció on es troba. Ara bé, com es veurà posteriorment, els casos d’ús de baixa i modificació de notícies són exclusius de l’usuari administrador. 7.2.5.1 Penjar notícies a una secció Entrades id_seccio:int, new_title:String, new_text:String Sortides Retorna cert si no és dona cap error. Semàntica Enregistra una new amb els atributs de l’entrada i l’associa amb la secció identificada per id_seccio. Flux d’interacció Usuari Sistema Introdueix el títol i el text de la notícia a la zona que s’ha destinat dins de la secció. Si les dades són vàlides, guarda la notícia a la base de dades. Cursos alternatius Si les dades introduïdes no són vàlides, el sistema no guarda la notícia i notifica el problema a l’usuari. Desenvolupament d’una aplicació web per a una ONG - 37 - 7.2.5.2 Baixa de notícies Entrades id_new:int Sortides Retorna cert si s’ha esborrat sense problemes. Semàntica Esborra la new identificada per id_new de la base de dades. Flux d’interacció Usuari Sistema Escull la notícia que vol donar de baixa. Demana que l’administrador confirmi la baixa de la notícia seleccionada. Confirma la baixa de la notícia seleccionada. Esborra la notícia de la base de dades. Cursos alternatius Si l’usuari no confirma la baixa de la notícia, es cancel·la l’operació. 7.2.5.3 Modificació de notícies Entrades id_new:int, new_title:String, new_text:String Sortides Retorna cert si s’ha modificat sense problemes. Semàntica Modifica la new identificada per id_new. Flux d’interacció Usuari Sistema Escull la notícia que vol modificar. Llista els atributs propis de la notícia i permet editar-los. Realitza els canvis i escull l’opció de guardar-los del menú d’opcions. Emmagatzema els canvis realitzats sobre la notícia a la base de dades. Cursos alternatius Si les dades introduïdes no són vàlides, el sistema no actualitza les dades i notifica el problema a l’usuari. 7.2.6 Casos d’ús de comentaris Els comentaris funcionen de forma anàloga a les notícies, donada la naturalesa d’aquestes últimes. En aquest cas, s’accedeix als casos d’ús dels comentaris a través de la fitxa del document al qual fan referència, i els casos d’ús de baixa i modificació també estan restringides a l’usuari administrador. Desenvolupament d’una aplicació web per a una ONG - 38 - 7.2.6.1 Deixar un comentari a la fitxa d’un document Entrades id_document:int, text_comentari:String Sortides Retorna cert si no s’ha donat cap error. Semàntica Enregistra un comentari amb les dades donades i l’associa amb el document identificat per id_document. Flux d’interacció Usuari Sistema Introdueix el text del comentari a la zona que s’ha destinat dins de la fitxa del document. Si les dades són vàlides, guarda el comentari a la base de dades. Cursos alternatius Si les dades introduïdes no són vàlides, el sistema no guarda el comentari i notifica el problema a l’usuari. 7.2.6.2 Baixa de comentaris Entrades id_comentari:int Sortides Retorna cert si s’ha esborrat sense problemes. Semàntica Esborra el comentari identificat per id_comentari. Flux d’interacció Usuari Sistema Escull el comentari que vol donar de baixa. Demana que confirmi la baixa del comentari seleccionat. Confirma la baixa del comentari seleccionat. Esborra el comentari de la base de dades. Cursos alternatius Si l’usuari no confirma la baixa del comentari, es cancel·la l’operació. Desenvolupament d’una aplicació web per a una ONG - 45 - 7.3.2 Diagrama de classes sense atributs 7.3.3 Diagrama de classes amb atributs Desenvolupament d’una aplicació web per a una ONG - 46 - 8 Disseny i implementació de l’aplicació en la metodologia tradicional 8.1 Arquitectura i plataforma L’aplicació utilitza una arquitectura Client/Servidor [v] , de manera que el client, a través del seu navegador personal, realitza peticions a una màquina remota (el servidor) que s’encarrega de processar-les i retornar una resposta al client. No obstant, no s’ha optat ni per un disseny orientat a objectes [vi] ni per una distribució en capes [vii] malgrat que ambdues tècniques suposen molts avantatges respecte a la independència de les dades i l’extensibilitat de l’aplicació. Sinó que s’ha programat l’aplicació seguint la metodologia habitual de treball de l’ONG, és a dir, en una arquitectura monolítica [viii] de la banda del servidor, el qual controla l’entrada/sortida de dades, el processament d’aquestes, la gestió d’errors i decideix, en certa manera, la interfície d’usuari 2 . Esquema d’interacció de l’arquitectura Client/Servidor Així doncs, a la banda del servidor s’utilitza Apache com a servidor d’aplicacions (per requeriments no-funcionals de l’aplicació), el qual suporta PHP, el llenguatge amb el qual es programa l’aplicació (també per requeriments no-funcionals de l’aplicació). 2 És evident doncs, que aquesta tècnica genera un alt nivell d’acoblament, el qual no és recomanable de cara a la mantenibilitat i extensibilitat de l’aplicació, com es podrà veure als capítols 11 i 12 d’aquesta memòria. Desenvolupament d’una aplicació web per a una ONG - 47 - A més, PHP permet la connexió amb diferents sistemes gestors de bases de dades (SGBD). En aquest cas s’utilitza MySQL (per requeriments no-funcionals de l’aplicació), un SGBD multi-fil i multi-usuari molt utilitzat en aplicacions web, principalment per la seva velocitat. Aquest llenguatge de programació és interpretat, com altres llenguatges de la mateixa naturalesa 3 , de manera que el servidor interpreta totes les entrades (les peticions del client i els resultats obtinguts de les consultes a les bases de dades), les processa i presenta la sortida al client. 8.2 Disseny de la base de dades El disseny de la base de dades té com a punt de partida el disseny conceptual, presentat en aquesta memòria al capítol 7.3 Diagrama de classes. Ara bé, es requereix un pas previ abans de transformar el disseny conceptual en un disseny lògic. Aquest és el procés de normalització que es presenta tot seguit. Les regles de normalització que s’apliquen són les següents: • Es transforma l’associació ternària entre Participant – Secció Activa – DataHora de la qual resulta la classe associativa Document. En conseqüència, s’afegeix la restricció textual: “No hi pot haver dos documents amb els mateixos Participant, Secció Activa i Data Hora”. 3 Per exemple, Python i Perl. Desenvolupament d’una aplicació web per a una ONG - 48 - • Aquesta mateix associació ternària (Participant – Secció Activa – DataHora) també dóna lloc a la classe associativa New. I per tant, caldrà afegir la restricció textual: “No hi pot haver dues news amb els mateixos Participant, Secció Activa i DataHora”. • Es transforma l’associació ternària entre Participant – Document – DataHora de la qual s’esdevé la classe associativa Comment. En aquest cas, la restricció textual que s’ha d’afegir és: “No hi pot haver dos comments amb els mateixos Participant, Document i DataHora”. • Es materialitza l’atribut derivat “Views” de la classe Document dins d’aquesta mateixa classe. Desenvolupament d’una aplicació web per a una ONG - 49 - D’acord amb el procés de normalització descrit, el diagrama de classes corresponent al model conceptual queda com es mostra: Diagrama de classes normalitzat A més, cal afegir les restriccions següents: Restriccions d’integritat textual: No hi pot haver dos documents amb els mateixos Participant, Secció Activa i Data Hora. No hi pot haver dues news amb els mateixos Participant, Secció Activa i DataHora. No hi pot haver dos comments amb els mateixos Participant, Document i DataHora. Informació derivada: Views conté el nombre de visites del document per part d’usuaris de tipus Normal. Per a completar la traducció al model relacional s’han de dur a terme les transformacions següents basant-se en el model obtingut després de normalitzar: En principi, es crea una relació (taula a la base de dades) diferent per cada classe. No obstant, s’elimina la superclasse Participant, pel fet que és una classe amb Desenvolupament d’una aplicació web per a una ONG - 50 - l’objectiu de simplificar l’esquema conceptual i no pertany al domini de l’aplicació. També s’elimina la classe DataHora perquè és una classe que està implícita en l’SGBD (sistema gestor de bases de dades). A més, s’afegeix a cada relació un atribut de tipus enter que serà la clau primària, necessària per poder identificar cada element (o instància). Pel que fa a les associacions, totes són binàries. D’entrada no hi ha associacions recursives ni associatives, ja que per mitjà de la normalització s’han eliminat les ternàries/associatives. A més, totes les associacions binàries són de tipus un-amolts. Això vol dir que en un extrem de l’associació la multiplicitat és 0..1 o 1, mentre que a l’altre extrem és molts (*, 0..*, 1..*). En aquest cas, la transformació consisteix en afegir un atribut a la classe que es troba a l’extrem ‘molts’ que faci referència a la classe que es troba a l’extrem ‘un’, en altres paraules, com a clau forana. A més, cal tenir en compte que el valor d’aquest atribut no pot ser nul, ja que la multiplicitat és 1. Es presenta un exemple per veure el procediment explicat. En aquest exemple, la classe Version, tindrà un atribut que permeti identificar i referenciar el Document. De manera informal, considerant que {Doc} i {Ver} són, respectivament, les claus primàries de Document i Version, resultarà així: Document (Doc, ...) Version (Ver, ..., Doc) on {Doc} referencia Document Respecte a les especialitzacions (de tipus i estat), se segueix una estratègia similar al mapeig per clau forana, de manera que s’inclou un atribut a la superclasse que permeti identificar la subclasse i a la qual referencia en cas que s’hagi convertit en classe del model relacional. Desenvolupament d’una aplicació web per a una ONG - 51 - Així doncs, les especialitzacions estat es transformen en un atribut de tipus booleà en la seva superclasse corresponent, i les especialitzacions tipus, en un atribut de tipus enter que fa referència (ja que és clau forana) a una instància d’una classe determinada. Es pot veure en el següent exemple: Transformació de l’especialització de tipus de la classe User Pel que fa a les enumeracions, es converteixen cadascuna d’elles en una classe, on cada instància està formada per un identificador i un atribut, el qual correspon a un element de l’enumeració. Finalment, després dels processos de normalització i transformació descrits, s’obté el següent disseny de la base de dades relacional. Nota: en cada relació, la clau primària es troba en doble subratllat. Les claus foranes, en subratllat simple i es descriu a continuació a quina relació referencien. Users(id_user, user, password, language, form_address, name, surname, mail, mail2, organization, type, active) On {language} referencia Languages On {type} referencia User_types On {organization} referencia Organizations Desenvolupament d’una aplicació web per a una ONG - 52 - User_types(id, type_name) Aquesta classe correspon a la transformació de l’especialització per tipus de la classe User, com s’ha explicat més amunt. Organizations(id_org, org_name, org_type) On {org_type} referencia Org_types Sections(id_sec, title, subtitle, info_date, folder, section_name, active) News(id_news, date_added, news_text, news_title, section, uploader) On {section} referencia Sections On {uploader} referencia Users Documents(id_doc, doc_title, author, category, subcategory, doc_date, section, uploader, instant_added, public, views) On {category} referencia Categories On {subcategory} referencia Subcategories On {section} referencia Sections On {uploader} referencia Users Versions(id_doc, id_lang, file, doc_type) On {id_doc} referencia Documents On {id_lang} referencia Languages Al mateix temps, les dos claus foranes fan de claus primàries Comments(id_comment, doc, commenter, date_added, comment_text) On {doc} referencia Documents On {commenter} referencia Users Registry(id_reg, id_user, time_acces, ip_address, browser) On {id_user} referencia Users Desenvolupament d’una aplicació web per a una ONG - 53 - Les classes següents corresponen a les enumeracions: Org_types(id, type_name) Languages(id_lang, language) Categories(id_cat, name_cat) Subcategories(id_subcat, name_subcat) Doc_types (id, doc_type_name) Desenvolupament d’una aplicació web per a una ONG - 54 - 8.3 Disseny dels tractaments En aquesta secció s’explica com es duu a terme la interacció entre els diferents elements de l’arquitectura, és a dir, entre el client i el servidor. Es descriu textualment i gràfica la manera com el client envia les peticions al servidor, com aquest últim gestiona l’entrada i la sortida de dades, el processament d’aquestes, la gestió d’errors, etc. Es considera que la mecànica de totes les funcionalitats és la mateixa, i per això s’han buscat dos exemples suficientment representatius que incloguin tots els escenaris possibles i on intervinguin tots els serveis del servidor utilitzats per l’aplicació. Es presenten a continuació. 8.3.1 Exemple 1 :: Pujar documents a una secció En primer lloc, el client demana visualitzar la pàgina upload.php a través del seu navegador. El servidor rep la petició i llegeix el fitxer upload.php del seu disc dur. A continuació executa l’intèrpret de PHP, el qual realitza diferents peticions al sistema gestor de bases de dades per construir la pàgina sol·licitada (quines seccions estan actives i quines categories i subcategories hi ha disponibles) i retorna el resultat al navegador perquè el mostri al client. Seguidament, el client omple els camps del formulari (a través del navegador) i envia les dades al servidor per mitjà del mètode POST prement el botó ‘Upload’. En aquest cas, l’intèrpret de PHP comprova que l’usuari tingui els permisos suficients per a realitzar l’acció que sol·licita. Si no és així, no executa cap acció i retorna un missatge al client notificant-li l’error. Del contrari, comprova que les dades enviades a través de POST són vàlides per executar les accions sol·licitades i que els fitxers s’han enviat correctament al servidor. Si les dades no són vàlides, finalitza l’execució i retorna un missatge al client notificant-li l’error. Altrament, l’intèrpret de PHP envia les ordres al sistema gestor de bases de dades per inserir un nou document i les diferents versions a la base de dades de l’aplicació. A continuació, emmagatzema permanentment cadascun dels fitxers enviats a través del formulari en el directori corresponent, ja que es trobaven en un directori temporal durant l’execució del programa. Desenvolupament d’una aplicació web per a una ONG - 61 - access_list.php Llistar els últims accessos dels usuaris edit_new.php Baixa de notícies, Modificació de notícies edit_comment.php Baixa de comentaris, Modificació de comentaris Alguns fitxers, però, no tenen cap cas d’ús assignat, com per exemple, les pàgines amb informació per als usuaris (presentation.php, documents.php, participants.php, support.php, ubuntu.php), algunes de les capçaleres i el peu (head_login.php, head_thin.php i foot.php). Pel que fa a l’estructura de fitxers i directoris, s’ha decidit posar en primer pla tots els fitxers principals (els que fan referència a pàgines) i agrupar en diferents directoris la resta de fitxers. Així doncs, queda de la següent manera: css/ Conté les plantilles de configuració en CSS. docs/ El formen 3 directoris (doha_process, 2n_meeting, 3rd_meeting), els quals emmagatzemen els fitxers que pugen els usuaris en cada secció de l’aplicació. img/ Es troben les diferents imatges que s’utilitzen a l’aplicació. includes/ Hi ha fitxers que acostumen a formar part de les capçaleres. papers/ Emmagatzema una sèrie de documents que han estat penjats per l’administrador del lloc web, enllaçats des de les pàgines d’informació. Quant als fitxers del directori includes/, es presenten a continuació per l’ordre en què s’utilitzen al fitxer head.php: inici_sessio.php Inicia les sessions dels usuaris. connexio_bd.php Estableix la connexió amb la bases de dades. global.php Conté la definició de variables que s’utilitzen a l’aplicació, algunes de les quals es llegeixen directament de la BD. errors.php Es defineixen els codis i missatges d’error per a tots els formularis de l’aplicació check_settings.php Comprova si l’usuari prové de la pàgina settings.php, on l’usuari accedeix el primer cop que entra a l’aplicació i ha decidit conservar la contrasenya donada. Desenvolupament d’una aplicació web per a una ONG - 62 - check_sessio.php Comprova si l’usuari que ha iniciat la sessió existeix a la base de dades i s’ha autenticat correctament. funcions.php Inclou totes les funcions que s’utilitzen a l’aplicació. Per altra banda, aquest directori també conté les classes class.phpmailer.php i class.smtp.php, les quals són necessàries per a poder crear i enviar emails a través de l’aplicació, com s’explicarà més endavant. 8.4.3 Formularis El sistema per aconseguir la interacció usuaris-aplicació (en altres paraules, perquè els usuaris puguin enviar dades a l’aplicació) es duu a terme a través de formularis. Existeixen dos mètodes per a realitzar l’enviament de dades: GET i POST. <form action="edit_section.php" method="post"> Exemple de la capçalera d’un formulari que utilitza el mètode POST 8.4.3.1 Mètode GET El mètode GET passa els atributs del formulari a través de l’adreça URL després del caràcter “?“ i PHP els emmagatzema en la variable superglobal $_GET. Cal destacar que els atributs enviats resten visibles a l’usuari, cosa que pot provocar, si s’utilitzen formularis amb diversos atributs (com és habitual), adreces URL llargues i força inintel·ligibles. A part, la utilització d’aquest mètode podria comprometre la seguretat de les dades enviades, pel fet que un usuari malintencionat pot modificar fàcilment les dades que s’envien amb finalitats que difereixen del propi ús de l’aplicació. Pels motius esmentats, s’intenta evitar l’ús del mètode GET sempre que sigui possible. Tanmateix, pot ser una bona opció en aquelles ocasions en què es tractin dades poc rellevants, es passin poques dades i estiguin degudament tractats tots possibles valors que pot prendre. En aquest sentit, i tal com s’ha comentat anteriorment, s’ha utilitzat aquest mètode per desenvolupar alguns accions de les pàgines index.php i fitxa.php. S’explica el seu funcionament a partir dels exemples següents: /index.php?sec=1&alldocs=1 Desenvolupament d’una aplicació web per a una ONG - 63 - Es passen els atributs sec=1 i alldocs=1. D’acord amb això, es mostrarà la secció número 1 i es llistaran tots els seus documents a la pàgina actual. /fitxa.php?doc=83&sec=1&allcomments=1 La pàgina fitxa.php rep els atributs doc=83, sec=1 i allcomments=1; de manera que es carregarà la fitxa del document número 83 i es mostraran tots els comentaris que fan referència a aquest. D’altra banda, la finalitat de l’atribut sec és permetre la creació de links per retornar a la secció on es trobava l’usuari. 8.4.3.2 Mètode POST Aquest altre mètode, en canvi, utilitza la variable superglobal $_POST i s’utilitza més comunament ja que les variables que es passen a través d’un formulari són en principi invisibles als usuaris, tot i que hi ha eines per a interceptar-les i llegir-les. Aleshores, és responsabilitat del programador que es faci correctament el tractament de les variables. Aquest mètode és el que s’ha utilitzat en la majoria de formularis de l’aplicació, per exemple, per entrar a l’aplicació (login), pujar un document, penjar notícies a les seccions, deixar un comentari a un document, canviar la contrasenya, així com qualsevol formulari utilitzat a l’àrea d’administració. Formulari per editar seccions, el qual utilitza el mètode POST 8.4.3.3 Recepció i ús de les dades enviades A la capçalera dels formularis s’especifica, a part del mètode que s’utilitza, quina pàgina recull les dades que s’envien. Això s’aconsegueix per mitjà de l’etiqueta action. A més, cal identificar cadascuna de les variables del formulari amb un nom per tal que siguin accessibles des de la pàgina destí, amb independència del mètode que s’utilitzi per enviar-les. Així per exemple, el següent formulari està format per 2 camps, new_title i new_text, Desenvolupament d’una aplicació web per a una ONG - 64 - que seran enviats per POST a la pàgina index.php. <form action="index.php" method="post"> <input name="new_title" type="text" size="80" maxlength="255" value=""> <textarea name="new_text" cols="60" rows="6" maxlength="255" value=""> <input class="inputs" type="submit" name="add_new" value="Post"> </form> Si es vol accedir i assignar el valor d’aquests camps des de la pàgina index.php caldrà fer-ho de la següent manera: $titol=$_POST["new_title"] Es procediria de manera similar en cas que s’hagués utilitzat el mètode GET, substituint la variable $_POST per $_GET. 8.4.3.4 Tractament de les dades i detecció d’errors S’ha de tenir en compte, que els formularis poden ser objecte de manipulacions amb propòsits malintencionats amb la finalitat que l’aplicació no funcioni correctament o treure’n algun profit, com es comentava anteriorment. Per tal d’evitar aquests problemes, les dades han de rebre un tractament que garanteixi que arriben en un format concret i poder treballar correctament amb elles. Aquest tractament es realitza a la pàgina on s’envien les dades, entre la capçalera i el cos de pàgina, abans d’imprimir el contingut. D’aquesta manera, el resultat obtingut en les comprovacions permetrà distingir a l’intèrpret si ha de carregar el contingut sol·licitat (quan les dades enviades siguin correctes) o imprimir un missatge notificant l’error. De forma general, cal comprovar que: • Els camps de tipus text no estan buits. A més cal eliminar els espais buits del principi i el final del camp, i escapar els caràcters especials com “ i ‘. • Els camps de tipus data no estan buits, contenen dades numèriques i dates vàlides. • En les llistes seleccionables, que l’element seleccionat és una opció vàlida. Desenvolupament d’una aplicació web per a una ONG - 65 - • En els camps de tipus fitxer, que s’ha adjuntat un document i és del tipus esperat. A més, cal evitar atacs coneguts [ix] com injeccions SQL i XSS (Cross-site scripting). El primer fa referència a la inserció de codi SQL dins d’una consulta que s’ha d’executar per tal de modificar-ne el comportament i executar el codi maliciós a la base de dades. El segon consisteix, generalment, en inserir codi HTML o Javascript als formularis per tal que es publiquin de forma il·legal determinats continguts en una pàgina web. En qualsevol cas, aquests atacs es poden solucionar tractant oportunament les dades enviades. Pel que fa a les injeccions SQL, cal escapar els caràcters perillosos (com “ i ‘) per mitjà de la col·locació de contrabarres (\) al davant. Respecte als atacs XSS, per evitar-los és necessari eliminar tot el text comprès entre els caràcters “<” i “>” per mitjà de funcions de PHP com strip_tags(). Si les dades no són vàlides, l’aplicació no realitza cap acció, intenta reconèixer l’error i mostra a l’usuari un missatge per tal que modifiqui aquelles dades que l’aplicació marca com invàlides. Per codificar i identificar els errors s’utilitza la següent tècnica. Primerament, s’identifiquen tots els possibles errors que pot donar un formulari i s’assigna a cadascun d’ells una potència de 2 diferent (1, 2, 4, 8, 16, ...). El fet que el nombre d’error sigui una potència de 2 permet codificar diversos errors en una única variable, ja que la identificació es fa per mitjà d’operadors bit a bit. En segon lloc, s’han de definir els missatges d’error que caldrà mostrar si es donen i finalment, comprovar els errors que s’han produït i imprimir el missatge d’error corresponent. A continuació es presenta un exemple per facilitar la comprensió. S’agafa un formulari amb 2 camps de text (text1, text2) i 2 llistes seleccionables (llista1, llista2). Els possibles errors són: Element Error Codificació Text1 buit 1 Text2 buit 2 Llista1 Element invàlid 4 Llista2 Element invàlid 8 Desenvolupament d’una aplicació web per a una ONG - 66 - El codi per a comprovar si es produeix algun error és el següent: $error=0; //inicialment no hi ha cap error if($_POST["text1"]==''){ $error=$error + 1; } if($_POST["text2"]==''){ $error=$error + 2; } if(!in_array($_POST["llista1"], $valors_llista1) { $error=$error + 4; } if(!in_array($_POST["llista2"], $valors_llista2)) { $error=$error + 8; } Es defineixen els següents missatges d’error: $errors_possibles=array( 1 => 'Text1 buit', 2 => 'Text2 buit', 4 => 'Element llista1 invàlid', 8 => 'Element llista2 invàlid' ); Finalment, es comproven els errors que s’han produït: if($error!=0){ foreach($errors_possibles as $num_error => $text_error){ if($num_error&$error){ //imprimeix missatge d'error $text_error } } } En el codi anterior, s’executa un bucle que a cada volta comprova si es dóna un error diferent. La comprovació es realitza amb l’operació $num_error&$error, que utilitza l’operador bit a bit &. Aquest retorna el producte bit a bit dels dos operands; si el resultat és zero no hi ha error, en cas contrari hi ha error i cal imprimir el missatge corresponent. 8.4.3.5 Enviament de fitxers L’enviament de fitxers és necessari per poder pujar documents a l’aplicació, cosa que es fa a través de la pàgina upload.php. S’implementa a partir del mètode POST i Desenvolupament d’una aplicació web per a una ONG - 67 - per fer-ho utilitza la variable superglobal $_FILES, la qual és un vector que guarda el nom, el tamany, el tipus i la ruta on es guarda el fitxer temporalment de la següent manera: $_FILES['nom_fitxer']['name'] $_FILES['nom_fitxer']['size'] $_FILES['nom_fitxer']['type'] $_FILES['nom_fitxer']['tmp_name'] (substituint ‘nom_fitxer’ pel nom del camp que s’utilitza al formulari) A més, cal incloure paràmetres al formulari per distingir que es pugen fitxers a través d’ell (per mitjà de enctype="multipart/form-data"). <form id="form_upload" enctype="multipart/form-data" action="upload.php?sec=<?echo $mysec;?>" method="post"> I també cal indicar el tamany màxim (en bytes) de l’arxiu a través d’un input ocult que ha de portar el nom MAX_FILE_SIZE. <input type="hidden" name="MAX_FILE_SIZE" value="10000000"> Tot i això, el navegador pot no respectar el màxim fixat i, en conseqüència, cal comprovar posteriorment que la variable $_FILES[“fitxer”][“size”] no supera el valor establert. $max=10000000; if($_FILES["doc_file"]["size"]<= $max){ //codi que s’executa solament si el tamany //no supera el màxim que s’ha establert prèviament } Després de fer el tractament de dades corresponent, cal moure el fitxer, el qual es troba en un directori temporal, al directori definitiu on es guardarà. El navegador ha de disposar dels permisos necessaris per poder llegir i escriure en determinats directoris del servidor. Per tal que sigui possible, s’ha decidit posar-lo com usuari propietari del directori docs i de tots els seus subdirectoris, a part de disposar dels permisos de lectura i escriptura. $ chown –R www-data:www-data docs/ $ chmod –R 750 docs/ Desenvolupament d’una aplicació web per a una ONG - 68 - Dins del directori docs es troben 3 directoris: doha_process, 2nd_meeting i 3rd_meeting, cadascun dels quals corresponen a una secció de l’aplicació. Al mateix temps, cadascun d’aquests conté 4 directoris (en, es, fr, ct), que fan referència a les quatre llengües en què es pot penjar un document. Amb l’estructura presentada, els fitxers queden organitzats per seccions i llengües. D’altra banda, per tal de no sobreescriure els documents penjats anteriorment, s’utilitza l’algorisme de xifrat MD5 per generar una clau única a partir de l’instant en què es puja el document, de manera que es crea un directori que porta per nom el resultat obtingut del xifratge en el directori de les llengües marcades al formulari, on cadascun d’ells conté el document penjat. Potser l’explicació resulta una mica confusa, per això presenta el següent exemple. Suposem que a través del formulari es puja el document “informe.pdf” en català i en anglès a la secció Second Meeting. Si es el resultat del hash de l’instant en què es puja és 4d186321c1a7f0f354b297e8914ab240, les dues versions seran accessibles a les següents adreces: $directori_final= hash("md5",microtime()); //s’obté el resultat 4d186321c1a7f0f354b297e8914ab240 docs/second_meeting/ct/4d186321c1a7f0f354b297e8914ab240/informe.pdf docs/second_meeting/en/4d186321c1a7f0f354b297e8914ab240/informe.pdf En el moment de crear el directori cal donar-li els permisos corresponents i finalment moure el document del directori temporal al directori que s’acaba de crear. mkdir($directori, 0750); $desti="docs/second_meeting/ct/4d186321c1a7f0f354b297e8914ab240/info rme.pdf"; move_uploaded_file($_FILES["doc_file"]["tmp_name"], $desti); 8.4.4 Administració S’ha decidit dur l’administració del lloc web de forma centralitzada a partir de la pàgina management.php. Així doncs, s’ha proveït aquesta pàgina de formularis que permetin crear, editar i esborrar usuaris, organitzacions, categories, etc., cosa que no representa grans variacions respecte al que s’ha explicat anteriorment. Ara bé, val la pena destacar el sistema de gestió d’usuaris, el qual permet enviar-los Desenvolupament d’una aplicació web per a una ONG - 69 - emails notificant-los l’alta d’usuari o la generació d’un nova contrasenya 4 , cosa que s’aconsegueix per mitjà de dues classes de PHP: PHPMailer i SMTP, les quals s’implementen en els fitxers class.phpmailer.php i class.smtp.php, respectivament. A partir d’aquestes es poden enviar emails amb totes les possibilitats de què disposa qualsevol client de correu (fitxers adjunts, configuració del missatge HTML, etc.). Per fer-ho, cal instal·lar les classes en algun directori de l’aplicació i usar els mètodes que ofereixen. A més, també s’ha creat una funció pròpia que s’encarrega d’establir la configuració i construir l’email a partir de les dades rebudes. Es presenta la capçalera d’aquesta: function envia_mail($mail_user, $mail2_user, $pass, $lang_user, $tracte_user, $nom_user, $cognom_user, $org_user, $tipus_notificacio) En aquesta es troben atributs per a construir el missatge (nom i cognoms de l’usuari, contrasenya, organització, etc.), dades de configuració (adreces de l’usuari, llengua en què s’ha de redactar el missatge, etc.) i un atribut que indica el tipus de notificació: alta d’usuari o generació d’un contrasenya nova. D’acord amb tot l’anterior, es presenta una versió adaptada de la funció envia_mail() a mode d’exemple. //capçalera necessària per poder utilitzar les classes require_once "includes/class.phpmailer.php"; //configuració de la classe phpmailer $mail = new phpmailer(); $mail->PluginDir = ""; $mail->Mailer = "smtp"; $mail->Host = "relay.upc.edu"; //configuració de l'email $mail->SMTPAuth = false; 4 Veure funcionalitats Alta d’usuaris i Generar una contrasenya per a un usuari Desenvolupament d’una aplicació web per a una ONG - 70 - $mail->isHTML(true); $mail->From = "[email protected]"; $mail->FromName = "Info TableforDialogue"; .. .. .. .. $mail->AddAddress($mail_user); if($mail2_user!="") $mail->AddAddress($mail2_user); //es construeix el cos de l'email a partir de les funcions //construeix_mail_account i construeix_mail_password. //No es posen per no sobrecarregar l'exemple if($tipus_notificacio==0) $cos=construeix_mail_account($mail_user, $pass, $lang_user, $org_user); elseif($tipus_notificacio==1) $cos=construeix_mail_password($mail_user, $pass, $lang_user); //es construeix l'assumpte de l'email switch($tipus_notificacio){ case 0: $assumpte="New Account for tablefordialogue.net"; break; case 1: $assumpte="Password recovery for tablefordialogue.net"; break; default: break; } $mail->Subject = $assumpte; $mail->Body = "<html><body>$cos</body></html>"; $body_newuser=$mail->Body; .. .. .. .. Desenvolupament d’una aplicació web per a una ONG - 77 - Propòsit Un CMS gratuït de propòsit general Funcionalitats Autenticació d’usuaris Definició de diferents rols (tipus) d’usuari Accés i interactivitat amb les bases de dades Administració web del contingut Organització en diferents temes de discussió (fòrum) Permetre la introducció de PHP en el codi Càrrega/descàrrega de documents Possibilitat d’integració d’una eina de cerca Compatibilitat amb el servidor Servidor Apache HTTP Bases de dades MySQL Llenguatge de programació PHP (preferentment) Aparença Que l’aparença sigui àmpliament controlable i personalitzable en CSS i/o l’àrea d’administració de l’aplicació. Comunitat Que la comunitat que hi ha al darrera sigui activa, per tal d’obtenir actualitzacions de seguretat, noves funcionalitats, manuals, tutorials i informació de suport (sempre que sigui possible) Requeriments que ha de complir el CMS Després de fer una prospecció de mercat es pot veure que molts CMS gratuïts compleixen els requisits de compatibilitat amb el servidor (Apache, PHP, MySQL), i per tant caldrà cercar en estudis, informes comparatius i observar la tendència del mercat per determinar els CMS que cal tenir en compte. 9.3.2 Cerca d’estudis comparatius a Internet Es poden trobar bastants estudis [xi] que comparen els CMS del mercat, però sovint acostuma a haver un clar (i inevitable) favoritisme per part de l’autor de l’estudi. Per això m’he centrat en estudis en què l’autor hagi utilitzat els CMS que compara, per tal de ser el més imparcial possible. Voldria ressaltar el següent estudi: "The 2008 Open Source CMS Market Share Report” [xii] , el qual no respon quin és el millor CMS open source, sinó quin o quins són els líders del mercat. Aquest complet estudi es basa en dos indicadors: el ritme d’adopció (rate of adoption) i la força de la companyia (brand strength). El primer indicador té en compte factors com el nombre de descàrregues, d’instal·lacions, llibres impresos, etc. El segon, en canvi, es fixa en la seva visibilitat als motors de cerca (Google, Desenvolupament d’una aplicació web per a una ONG - 78 - Yahoo, etc.), en la popularitat, en el trànsit en llocs web de demostració, en les mencions en mitjans de comunicació, etc., i fa especial ressò als premis atorgats a cadascun dels CMS. Segons el primer indicador (malgrat la subjectivitat dels factors), el grup dels líders està format per WordPress, Joomla! i Drupal. El segon indicador, però, confirma el lideratge d’aquests tres CMS respecte la resta, els quals se situen a una distància força considerable. Pel que fa a premis, cal destacar que Drupal i Joomla! són els que més premis s’han emportat en els darrers anys per part de l’empresa Packt Publishing [xiii] . No obstant, el guanyador absolut de les dues últimes edicions ha estat Drupal, mentre que Joomla! ha quedat en segon lloc. Per altra banda, nombrosos estudis ressalten que Drupal disposa de millors funcionalitats (especialment en la gestió d’usuaris i permisos) i és molt més flexible en quant a gestió d’extensions i continguts que no el seu competidor Joomla!. 9.3.3 Eines de comparació dels CMS Tal com s’ha explicat anteriorment, el fet d’escollir un CMS és una tasca complexa i provar-los tots (instal·lar-los i dur a terme funcions senzilles) és inviable. Donada la generalització de l’ús de CMS han aparegut diverses eines, a més de llocs webs que recullen valoracions i puntuacions dels usuaris, per ajudar a comparar les seves característiques. Entre aquestes, destaco dues eines. La primera és CMS Matrix [xiv] , la qual consisteix en una extensa llista de CMS de la qual es poden escollir els que es volen comparar i llistar-ne les característiques, els requeriments de sistema i les funcionalitats de què disposa respecte a seguretat, facilitat d’ús, suport, gestió, etc. Desenvolupament d’una aplicació web per a una ONG - 79 - Comparació dels CMS Drupal i Joomla a CMS Matrix La segona és OpenSourceCMS [xv] . Aquest lloc web et facilita, entre altres coses, una interfície de proves (ja instal·lada) per cada CMS i un cop autenticat com a usuari es poden gestionar els continguts i analitzar el seu funcionament. Per altra banda, també proporciona una llista [xvi] dels CMS, agrupats per propòsit, que conté la puntuació mitjana atorgada pels usuaris a cada gestor. Llista de gestors amb les seves puntuacions a OpenSourceCMS Tot i que no té validesa suficient per a dir quin és el millor CMS (ja que les Desenvolupament d’una aplicació web per a una ONG - 80 - puntuacions poden ser manipulades votant diverses vegades afavorint un gestor o un altre) permet fer-se una idea sobre quins són els més usats i en quins estan més interessats els usuaris. 9.3.4 Resum del procediment de selecció El procediment de selecció que s’ha seguit es pot deduir dels apartats anteriors. Primer de tot, s’han plantejat les 5 preguntes bàsiques i el resultat obtingut ha estat la Taula de requeriments que ha de complir el CMS de l’apartat 9.3.1. Estudi de mercat dels CMS. A continuació, agafant com a referència l’estudi de Ric Shreves - water&stone citat en l’apartat 9.3.2 s’han buscat estudis comparatius entre Joomla! [xvii] , WordPress [xviii] i Drupal [xix] ja que compleixen plenament els requeriments establerts, per l’activitat de les comunitats que tenen al darrera i, en especial, per l’enorme quantitat de funcionalitats de què disposen. No s’ha descartat WordPress ja que, malgrat no ser considerat en molts casos un CMS de propòsit general, té una àmplia acceptació i un gran nombre de funcionalitats que el fan molt potent. Posteriorment, s’han comparat els CMS escollits. En primer lloc, utilitzant l’eina OpenSourceCMS, contrastant les puntuacions i observacions dels usuaris. En segon lloc, llistant les característiques de cadascun amb CMS Matrix. A partir d’aquest últim es pot concloure que WordPress té encara moltes extensions de seguretat, gestió i flexibilitat per cobrir; i per tant queda descartat. Es pot considerar que Drupal i Joomla! queden en igualtat de condicions i s’ha optat per instal·lar-los tots dos per tal de comparar els processos d’instal·lació i prendre contacte amb cadascun. Tots dos tenen un procés d’instal·lació simple i ràpid. Segons la meva opinió, la interfície de Drupal és molt més intuïtiva i professional, a diferència de la de Joomla!, la qual sembla més senzilla i amb menys possibilitats. Finalment, considerant les distincions rebudes, els estudis citats en l’apartat 9.3.2 (que situen en millors posicions Drupal que Joomla!) i una mínima experiència personal, es conclou que Drupal és més adequat per al desenvolupament de la nova aplicació de l’ONG ja que, a diferència de Joomla!, té eines per satisfer requeriments funcionals importants (com l’establiment de permisos de forma granular, configuració de tipus de dades propis), i compleix més fidelment els Desenvolupament d’una aplicació web per a una ONG - 81 - estàndards d’Internet. Així mateix, té una major extensibilitat, escalabilitat i flexibilitat, cosa que cal tenir en compte davant la possibilitat d’implantació del CMS en la resta d’aplicacions de l’ONG. 9.4 Disseny i implementació de l’aplicació a partir del CMS escollit Després de la ràpida i senzilla instal·lació de Drupal al servidor, s’ha procedit a la instal·lació d’un tema que permeti donar-li l’estructura adient, i a partir de la qual es pugui fixar la configuració i l’aparença desitjada d’acord amb els requeriments establerts en el capítol 6. Els passos esmentats es poden trobar als annexos I i II d’aquesta memòria. A continuació, s’ha procedit en el disseny de les dades, el disseny i la implementació de l’aplicació tal com es descriu tot seguit. 9.4.1 Disseny de les dades Des del meu punt de vista, Drupal s’organitza al voltant de dos conceptes bàsics: Node i Module. Per node s’entén qualsevol tipus de contingut (és a dir, pàgines, entrades de blog, etc.), els quals poden contenir diferents unitats de contingut com comentaris o fitxers, i estar relacionats amb altres nodes. Per altra banda, els mòduls són petites aplicacions que permeten estendre o augmentar les funcionalitats existents del gestor de continguts, o bé, afegir-ne de noves per tal d’aconseguir un determinat comportament o objectiu fins aleshores inabastable. Convé ressaltar que el nucli de Drupal (és a dir, el conjunt d’elements bàsics per al seu funcionament) està dividit en mòduls essencials i mòduls opcionals. En el primer, es troben mòduls com: • User: Gestiona el registre d’usuari i l’entrada al sistema. • Block: Controla els blocs d’informació (menús, capçalera, peu, etc.) que es mostren al voltant del contingut principal. • Filter: Realitza el filtratge de contingut que ha de ser mostrat. Desenvolupament d’una aplicació web per a una ONG - 82 - • Node: Permet la introducció de nou contingut i l’organitza en pàgines. • System: Gestiona la configuració general del lloc pels administradors. En canvi, en el conjunt de mòduls opcionals es troben utilitats força habituals en les aplicacions web com el cercador (Search), els comentaris (Comment), ... molts d’ells però, a diferència dels mòduls essencials, cal activar-los abans de poder-los utilitzar. Per defecte Drupal duu diversos mòduls activats, on, a més dels mòduls essencials, es troben els comentaris (Comment) i el gestor de menús (Menu), entre d’altres; cosa que permet tenir una aplicació força funcional just després de la instal·lació. En aquest sentit, es pot establir un cert paral·lelisme (no estricte, sinó funcional) entre els diferents mòduls de Drupal i les classes que formen l’aplicació. Es descriu a continuació: User Es pot aconseguir una gestió d’usuaris en diferents rols a partir del mòdul User. A més, permet la definició de nous rols i l’assignació de permisos (tant per l’accés al contingut com per la utilització de diferents mòduls). A part, es pot aconseguir la configuració dels usuaris activant el mòdul Profile, per tal d’afegir atributs personalitzats. Section Les seccions es poden gestionar des d’una pàgina. (Caldrà introduir certs canvis, com s’explicarà més endavant). Comment El mòdul Comment de Drupal és equivalent. New Les notícies (comentaris dins d’una secció) també poden tractar-se amb el mòdul Comment. Version La classe Version es pot considerar com un fitxer adjunt a una pàgina. Cal activar el mòdul Upload per poder adjuntar fitxers a les pàgines. Registry No cal implementar aquesta classe pel fet que Drupal disposa del mòdul Database logging, que s’encarrega de registrar totes les accions/esdeveniments de l’aplicació a la base de dades. Aleshores, Desenvolupament d’una aplicació web per a una ONG - 83 - es pot obtenir la informació desitjada destriant-la de la resta, com s’explicarà més endavant. Finalment, per completar el disseny de dades, cal instal·lar els mòduls d’aquells tipus de dades amb els quals Drupal no compta inicialment i que són necessaris per a l’aplicació: Email i Date. Aquests permeten definir atributs de tipus e-mail i data, respectivament, i al mateix temps porten incorporades les restriccions necessàries per aquests tipus de dades. (per exemple: que el caràcter @ estigui en els emails, que la data sigui vàlida: no es permetin dates de l’estil 31 de febrer de 2009). Malgrat tot, les possibilitats que dóna Drupal no són suficients per a fer front a qualsevol classe de l’aplicació, ja que n’hi ha algunes que tenen molts atributs o bé necessiten atributs concrets. Drupal, per si mateix, és incapaç de cobrir totes les necessitats i funcionalitats que es volen assignar a una classe personalitzada i per això cal buscar un mòdul que permeti modelar els tipus de contingut. Així doncs, Drupal disposa d’un mòdul molt potent (i en certa manera “màgic”) anomenat Content Construction Kit (CCK), el qual permet crear tipus de continguts personalitzats com també afegir atributs als tipus de contingut existents per tal de donar-li una finalitat específica. 9.4.1.1 Procés de creació de nous tipus de contingut El procés de creació de nous tipus de contingut es realitza des de l’àrea d’administració de l’aplicació i consisteix en respondre un seguit de preguntes que formula l’aplicació. Inicialment, s’ha de respondre a les característiques del nou tipus: • Nom i descripció del nou tipus • Noms dels atributs Title i Body (aquest últim opcional) • Volum de treball (si s’ha de publicar, si ha d’aparèixer a la primera pàgina, etc.) • Característiques dels comentaris (decidir si el nou tipus de continguts n’accepta, i en cas afirmatiu, configuració d’aquests) Desenvolupament d’una aplicació web per a una ONG - 84 - Selecció de característiques d’un nou tipus de contingut A continuació, basant-se en l’estructura típica d’una pàgina (Title i Body), cal introduir els atributs un per un, decidir el tipus de dades i les seves característiques; i, per últim, decidir com es mostraran. Edició dels atributs d’un nou tipus de contingut Desenvolupament d’una aplicació web per a una ONG - 85 - 9.4.1.2 Creació de nous tipus de contingut per aquest projecte Drupal està equipat amb un seguit de mòduls que permeten cobrir diversos tipus de contingut força habituals en aplicacions web. Així, per exemple, incorpora Page (per poder crear pàgines), Story (per fer pàgines més senzilles que equivalen entrades de blog) i Comment, el qual permet donar lloc als comentaris. Així mateix, els mòduls mencionats són utilitzats de la següent manera: Page, per a crear pàgines d’informació; Story, per a introduir entrades a la pàgina principal del lloc web; i Comment, per implementar comentaris dels documents i notícies de les seccions. No obstant, com s’ha comentat anteriorment, hi ha classes que queden més enllà dels límits de Drupal i s’han d’implementar per separat, en aquest cas, amb el mòdul CCK (Content Construction Kit). El procediment presentat en l’apartat anterior és el que s’ha seguit per a crear els tipus Document, Section i Organization. A continuació, es pot veure l’estructura resultant dels tipus de contingut esmentats. 9.4.1.2.1 Document En aquest cas s’ha desactivat l’atribut Body, ja que no serà utilitzat. I s’afegeixen els camps que es poden veure a la taula: Atribut Nom Tipus Title Node module form. Author Field_author Text Date Field_date Date Section Field_section Text Category Field_category Text Subcategory Field_subcategory Text Menu settings Menu module form. File attachments Upload module form. L’atribut derivat Views, el qual conté el número de visites, no s’ha materialitzat en aquest cas, és a dir, no es fa explícit en el tipus de contingut Document, ja que es gestiona internament a partir dels mòduls Statistics i Statistics Advanced Settings que es poden administrar de manera senzilla i tenen una gran flexibilitat. Desenvolupament d’una aplicació web per a una ONG - 86 - 9.4.1.2.2 Section El comportament i l’estructura de les seccions serà molt semblant al d’una pàgina qualsevol, i únicament s’afegeix el camp Subtitle. Atribut Nom Tipus Title Node module form. Subtitle Field_author Text Menu settings Menu module form. Body Node module form. 9.4.1.2.3 Organization En el cas de les organitzacions es canvia el nom de l’atribut principal Title per Name i es desactiva el Body, perquè tampoc serà utilitzat. Finalment s’afegeixen els camps que es poden veure a la taula: Atribut Nom Tipus Name Node module form. Acronym Field_author Text Type Field_section Text Menu settings Menu module form. 9.4.1.3 Configuració de la classe Usuari Per a completar la configuració dels usuaris, se segueix un procediment similar al que s’ha explicat amb el mòdul CCK, tot i que en aquest cas a partir del mòdul Profile. La mecànica és la mateixa, és a dir, anar afegint successivament atributs, escollir el tipus de dades i les seves característiques fins a conformar l’usuari tal com es desitja. Desenvolupament d’una aplicació web per a una ONG - 93 - 9.4.3 Implementació En aquest apartat, s’explica com s’ha arribat a aconseguir l’establiment de permisos, ja que no queda cobert amb el que s’ha explicat anteriorment. Cal recordar que s’han distingit 3 tipus d’usuaris (admin, normal i guest) amb diferents possibilitats sobre el contingut i per això cal assignar-los diferents permisos. Per aconseguir-ho, es fa servir el mòdul Content Access, el qual permet fixar permisos de forma general (per tipus de contingut) i per cada node, o en altres paraules, de forma granular, cosa que dóna molta flexibilitat. Edició dels permisos dels diferents tipus d’usuari sobre un node Desenvolupament d’una aplicació web per a una ONG - 94 - 10 Proves Aquesta etapa és una de les més importants del desenvolupament ja que, a part de provar que s’obté el comportament desitjat de tots els casos d’ús, permet descobrir possibles vulnerabilitats amb les que no s’havia comptat anteriorment i que podrien comprometre la seguretat de les dades del lloc web. Per a realitzar les proves s’ha utilitzat el navegador Firefox 3, ajudat de l’extensió Web Developer [xx] . Es presenten a continuació, els escenaris provats 6 . Escenaris provats Prog. a mida Drupal En el moment d’entrar a l’aplicació Deixar els camps username i password buits. X X Utilitzar dades incorrectes en els camps username i password. X X De forma general Els usuaris només poden accedir a les pàgines on disposen dels permisos necessaris. X X Només es comptabilitzen les visites dels usuaris de tipus Normal per al còmput de visites dels documents. X X Els documents d’una secció es mostren ordenats cronològicament. X X La llista de documents d’una taula es pot ordenar per qualsevol camp. X X Les notícies i els comentaris es mostren ordenats cronològicament. X X En el moment de publicar i editar el contingut Deixar els camps buits i intentar publicar. X X Introduir dades no numèriques en els camps de tipus data. X X Introduir dates invàlides en els camps de tipus data. X X Escollir una secció no permesa. X X Inserir dades amb longitud superior al límit permès. X X Inserir caràcters especials (‘, “, accents,...) i comprovar que es tracten correctament. X X Inserir codi en HTML i Javascript. X X Publicar més de 10 comentaris/notícies per comprovar que se seleccionen els/les més recents. X X Penjar més de 5 documents en una secció i comprova que seleccionen els més recents. X X La data i l’hora en què s’ha publicat és correcta. X X 6 Els que estan marcats amb NA, no s’han pogut provar en Drupal ja que s’implementa de manera diferent. Com s’explicarà en proper capítol, s’han hagut de rebaixar alguns dels objectius. Desenvolupament d’una aplicació web per a una ONG - 95 - Comprovar que només es poden pujar documents en format PDF. X X A l’àrea d’administració No assignar cap contrasenya a un usuari. X X Assignar una contrasenya més llarga/curta del límit. X X Introduir una adreça de correu invàlida (sense @). X X Comprovar que les contrasenyes es guarden xifrades. X X Crear un usuari i comprovar que s’envia correu electrònic de notificació. X X Comprovar que l’usuari pot canviar la contrasenya la primera vegada que entra a l’aplicació. X NA Comprovar que quan s’esborra un usuari es conserven els documents, notícies i comentaris que ha deixat a l’aplicació. X X Desactivar una secció i comprovar que no es llisten els seus documents ni notícies. X X Comprovar que no es pot esborrar una organització vinculada amb algun usuari. X NA Comprovar que no es pot esborrar una categoria o subcategoria vinculada amb algun document. X NA Comprovar que la llista del últims accessos dels usuaris agafa realment l’últim accés de cada usuari. X X Desenvolupament d’una aplicació web per a una ONG - 96 - 11 Comparació de les dues metodologies de desenvolupament L’objectiu principal d’aquest capítol és analitzar les dues metodologies de desenvolupament en base a diferents factors que es presenten a continuació. 11.1 Aprenentatge El mètode tradicional requereix conèixer HTML i PHP per poder programar les pàgines, SQL per poder fer les consultes a les bases de dades i la sintaxi CSS per poder dissenyar una aparença amb fulls d’estil. En canvi, en Drupal, un administrador novell podria prescindir de tots aquests coneixements. Ara bé, per aconseguir un nivell de personalització com el que s’ha aconseguit a l’aplicació que es presenta, a més d’aquests coneixements es necessita un aprenentatge per fer funcionar el CMS: instal·lació, configuració, l’administració, publicació, ... i en definitiva la personalització de l’aplicació perquè sigui com s’espera. Convé ressaltar, però, que donada la seva complexitat, Drupal té una corba d’aprenentatge lenta si es compara amb altres CMS, els quals no són tan potents ni disposen de les mateixes possibilitats. 11.2 Documentació Per sort, Drupal disposa de molta documentació (manuals, vídeos, fòrums de debat, etc.) i acostuma a seguir unes pautes per tal d’unificar el sistema per a fer determinades coses. En el cas de l’aplicació desenvolupada des de zero, en principi la documentació és inexistent, si no es tenen en compte l’API 7 de PHP i les sintaxis HTML i CSS. No obstant, el desenvolupador pot construir la seva pròpia documentació pels temes que ho requereixin. 11.3 Posada en marxa L’aplicació tradicional té una posada en marxa lenta i progressiva, on cal anar iterant 7 Application Programming Interface Desenvolupament d’una aplicació web per a una ONG - 97 - en la programació i fent les proves concretes fins a aconseguir el resultat esperat. Contràriament passa en Drupal, el qual té una posada en marxa molt ràpida, de manera que en tan sols unes hores es pot tenir una aplicació funcionant, la qual caldrà complementar amb la instal·lació dels diferents mòduls. 11.4 Configuració Ambdues aplicacions requereixen configuracions prèvies que els permetin gestionar els seus fitxers en el servidor (lectura i escriptura) i accedir a la base de dades. En relació amb aquest últim punt, cal ressaltar que a l’aplicació tradicional s’ha hagut de dissenyar la base de dades i implementar-la, cosa que en Drupal és transparent al desenvolupador. És a dir, Drupal crea i administra les taules de la base de dades d’acord amb el contingut que gestiona, els mòduls instal·lats i les seves configuracions. 11.5 Funcionalitats Respecte als casos d’ús que s’havien dissenyat, a l’aplicació tradicional s’han hagut de programar des de zero cadascun d’ells. De forma contrària, en Drupal els casos d’ús s’implementen en base a mòduls configurats convenientment per aconseguir el resultat esperat. Malgrat tot, a vegades resulta difícil satisfer els objectius fixats i cal pensar solucions alternatives o rebaixar els objectius. Així mateix, no ha estat possible satisfer les restriccions descrites pels casos d’ús 7.2.7.2. Baixa d’organitzacions i 7.2.8.2. Baixa de categories, que diuen que no es poden donar de baixa organitzacions ni categories (i subcategories) que estiguin associades a usuaris i documents, respectivament. En aquest cas, s’ha procedit a rebaixar els objectius, i es deixa com a responsabilitat de l’administrador la tasca de mantenir la concordança entre usuaris-organitzacions i documents-categories per tal que no es produeixin problemes. Respecte al cas d’ús 7.2.2.5. Canviar la contrasenya, s’havia convingut que els usuaris podrien canviar la seva contrasenya, únicament, la primera vegada que entressin a l’aplicació i, en Drupal, la poden canviar en qualsevol moment sense necessitat de tornar a iniciar la sessió. Aquest canvi, d’entrada, no suposa cap problema, però sí que comporta una rebaixa dels objectius. Desenvolupament d’una aplicació web per a una ONG - 98 - 11.6 Administració Pel que fa a l’administració de l’aplicació, Drupal disposa de moltes funcionalitats d’administració (tant de forma general com a nivell de mòduls i temes), les quals estan pre-dissenyades i tenen moltes capacitats. En canvi, a l’aplicació tradicional s’han hagut de desenvolupar des de zero totes les funcionalitats que es necessitaven. 11.7 Aparença Totes dues aplicacions permeten la separació del contingut i la seva presentació per mitjà de la definició d’estils en els fitxers CSS. Aleshores, depèn de les habilitats del desenvolupador, aconseguir una aparença atractiva per a l’aplicació. A més, Drupal permet una gestió de l’aparença a través del navegador, de la qual l’aplicació tradicional no disposa. 11.8 Publicació de continguts Respecte a la publicació de continguts, ambdues disposen de formularis que permeten automatitzar el procés de publicació. Com s’ha comentat anteriorment per a les funcionalitats i l’administració, a l’aplicació tradicional s’ha hagut de programar i, en canvi, a Drupal únicament és fa ús del mòduls necessaris. 11.9 Establiment de permisos Sobre l’establiment de permisos, Drupal permet dur un control bastant exhaustiu dels permisos sobre cada funcionalitat. A més, pot establir permisos de forma granular, o en altres paraules, permisos concrets per cada node, la qual cosa dóna molt de joc. Pel que fa a l’aplicació tradicional, s’ha optat per una gestió de permisos força senzilla, incrustada en el codi i gens automatitzada, que caldria revisar si es volgués fer més dinàmica i operativa des de l’àrea d’administració, però que satisfà les necessitats plantejades per l’aplicació. 11.10 Extensibilitat Quant a l’extensibilitat de les aplicacions, Drupal és totalment extensible a partir de mòduls i generalment no implica la modificació del codi. Totes les funcionalitats Desenvolupament d’una aplicació web per a una ONG - 99 - desitjades es poden aconseguir amb la instal·lació del mòdul corresponent, en cas que existeixi. A més, Drupal tolera tots els canvis en les bases de dades que comporta la instal·lació i l’ús d’aquests mòduls. En canvi, l’aplicació programada a mida, té una extensibilitat limitada en el sentit que qualsevol canvi en el comportament d’una funcionalitat o en la base de dades comporta modificar el codi, la qual cosa resulta incòmoda i poc avantatjosa. 11.11 Seguretat Respecte a la seguretat, totes dues aplicacions incorporen dispositius per garantir-ne la seguretat (per exemple, el xifrat de les contrasenyes). No obstant això, els formularis amb què es treballa són focus per explotar les vulnerabilitats de les aplicacions web en els que cal parar especial atenció. Per norma general, com més usuaris treballin amb una aplicació, més fàcil és descobrir-ne els punts dèbils. Al mateix temps però, una aplicació àmpliament usada també pot ser objectiu d’atacs aprofitant les vulnerabilitats conegudes, cosa que no passa en una aplicació programada a mida, en principi amb un ús més restringit. D’altra banda, en aquesta última, pot ser que s’hagin obviat o no s’hagin tingut en compte certs problemes En definitiva, en quant a seguretat un CMS possiblement estarà més preparat, perquè amb el temps haurà provat més escenaris i s’hauran solucionat més problemes (gràcies a la comunitat d’usuaris i desenvolupadors) que una aplicació programada a mida. Desenvolupament d’una aplicació web per a una ONG - 100 - 12 Comparació de característiques no-funcionals de les aplicacions obtingudes La comparació que es presenta en aquest capítol segueix l’estructura que s’ha fixat al capítol 6 respecte a Requeriments No Funcionals. 12.1 Seguretat - Totes dues aplicacions poden treballar sobre protocol HTTPS per garantir l’intercanvi segur de fitxers. - També s’utilitzen noms d’usuari i contrasenyes per fer l’autenticació d’usuaris i restringir l’accés al contingut. - Les dues guarden les contrasenyes xifrades per mitjà de l’algorisme MD5. 12.2 Fiabilitat - Les aplicacions es troben disponibles des de les adreces tablefordialogue.net i tablefordialogue.org. La redirecció porta a l’usuari l’aplicació desenvolupada amb Drupal. Per accedir a l’aplicació programada a mida cal afegir a /old al final de la URL. - Externament, es realitzen còpies de seguretat del servidor (totals i incrementals). Per aquest motiu no cal implementar-les des de les aplicacions. 12.3 Usabilitat - Les dues interfícies estan desenvolupades en anglès. A l’aplicació feta a mida s’ha hagut d’escriure i revisar tot el vocabulari. En canvi, Drupal disposa per defecte del vocabulari en anglès. - S’ha intentat fer les dues aplicacions el més intuïtives possible i on es pugui accedir fàcilment als continguts a través de menús i enllaços situats adequadament. - Les dues aplicacions disposen d’una àrea d’administració per gestionar els continguts i els usuaris. L’àrea d’administració de Drupal és més completa i Desenvolupament d’una aplicació web per a una ONG - 101 - ofereix més possibilitats. Malgrat tot, és una mica més complexa. - Pel que fa als estàndards d’accessibilitat, internacionalització i independència, Drupal els respecta en major grau, i el compliment d’aquests no requereix esforç per part dels usuaris (administradors i desenvolupadors, en principi) pel fet que es gestiona automàticament, a diferència de l’aplicació programada des de zero on constantment cal comprovar que es satisfan els estàndards citats. 12.4 Eficiència - El temps de resposta de les aplicacions se situa en tots dos casos dins de l’esperat (fixat el màxim en uns 2 segons). No obstant, el temps de l’aplicació desenvolupada a mida és lleugerament menor. En cap cas, s’arriba al màxim fixat de 8 segons. 12.5 Mantenibilitat - Com s’ha indicat anteriorment, Drupal és fàcil i ràpid d’estendre en tots els sentits (funcionalitats, administració, etc.), mentre que qualsevol extensió en l’aplicació desenvolupada des de zero requereix la modificació del codi, cosa que pot comportar bastant treball. - Pel que fa la solució d’errors, de forma general es pot dir que Drupal disposa d’una comunitat al darrera que s’encarrega de resoldre’ls i publica noves versions del software que no presenten els errors detectats. No obstant això, els problemes puntuals i petits són relativament fàcils de detectar en l’aplicació programada des de zero. 12.6 Portabilitat - Les dues aplicacions es visualitzen correctament Internet Explorer 6 i 7, i en Mozilla Firefox 2 i 3. - Ambdues aplicacions s’han desenvolupat sobre un servidor Apache, s’han programat en el llenguatge PHP5 i utilitzen MySQL com a sistema gestor de bases de dades. - En els dos casos, les bases de dades poden administrar-se externament amb Desenvolupament d’una aplicació web per a una ONG - 102 - eines com PHPMyAdmin. - Les dues aplicacions permeten pujar, únicament, documents en PDF. 12.7 Negoci - En ambdues plataformes de desenvolupament, els programes utilitzats disposaven de llicències gratuïtes. Desenvolupament d’una aplicació web per a una ONG - 109 - Esquema de l’estructura típica d’un tema de Drupal Desenvolupament d’una aplicació web per a una ONG - 110 - Annex III: Instal·lació d’un mòdul a Drupal La instal·lació d’un mòdul, el qual permet donar una funcionalitat determinada a l’aplicació, segueix un esquema molt similar al procediment utilitzat per a instal·lar un tema. És el següent: • Descarregar el mòdul d’Internet • Traspassar el mòdul al servidor amb algun programa que implementi els protocols FTP o SSH, i desempaquetar-lo al directori sites/all/modules/. • Activar el mòdul desitjat des de l’àrea d’administració (Administer>Site building>Modules). Activació de diversos mòduls a través de l’àrea d’administració Desenvolupament d’una aplicació web per a una ONG - 111 - Bibliografia La bibliografia s’estructura cronològicament seguint els capítols de la memòria. Hi ha fonts bibliogràfiques que s’han utilitzat com a base per al conjunt d’un capítol i d’altres, en canvi, que fan referència a termes concrets i, per això, es facilita la referència en números romans a la mateixa pàgina on apareix el terme. Requeriments Ingeniería de requisitos: http://es.wikipedia.org/wiki/Ingeniería_de_requerimientos [i] ISO/IEC 9126: http://es.wikipedia.org/wiki/ISO_912 [ii] Carvallo, J. P.; Franch, X.; Quer C. “Towards a Unified Catalogue of Non-technical Quality Attributes to Support COTS-Based Systems Lifecycle Activities” (best paper). International Conference on COTS-Based Software Systems, ICCBSS 2007 [iii] “¿Cuánto es el tiempo de carga de una página web que consideramos aceptable?”: http://www.clikear.com/cuanto_tiempo_carga_14752.aspx [iv] “Browser Statistics”: http://www.w3schools.com/browsers/browsers_stats.asp Especificació Costal, D.; Franch, X.; Ribera Sancho, M.; Teniente, E. (2000). “Enginyeria del Software: Especificació: Especificació dels sistemes orientats a objectes amb la notació UML”. Barcelona: Edicions UPC. Franch, X.; Gómez, C.; Martínez, E.; Pradel, J.; Raya, J.A. “Transparències de l’assignatura Enginyeria del Software II (ES2)”. Costal, D.; Rodríguez, E.; Urpí, T.; Martín, C.; Quer, C. “Transparències Bases de Dades”. CPET. Disseny i implementació Software architecture: http://en.wikipedia.org/wiki/Software_architecture [v] Client-server: http://en.wikipedia.org/wiki/Client-server [vi] Object-oriented programming: http://en.wikipedia.org/wiki/Object-oriented_programming [vii] Multitier architecture: http://en.wikipedia.org/wiki/Three_tier_architecture Desenvolupament d’una aplicació web per a una ONG - 112 - [viii] Monolithic system: http://en.wikipedia.org/wiki/Monolithic_system [ix] Inseguridad informática: http://es.wikipedia.org/wiki/Inseguridad_informática Informació sobre els CMS Content management system: http://en.wikipedia.org/wiki/Content_management_system Sistema de gestión de contenido: http://es.wikipedia.org/wiki/Cms [x] “5 Tips to help you choose a CMS”: http://cmscritic.com/5-tips-to-help-you-choose-a-cms Estudis Comparatius [xi] S’han tingut en compte diverses comparacions de gestors de continguts: • “Red Social con Drupal vs Joomla… o vs Elgg”: http://www.planetahuevo.es/internet/2008/07/18/red-social-con-drupal-vs-joomla-o-vselgg/ • “Drupal 6 vs Joomla 1.5. Actualización”: http://www.planetahuevo.es/2008/07/23/internet/drupal-vs-joomla-actualizacion/ • “Comparing Drupal vs. Joomla vs. Typo3 and Others”: http://www.usefultalk.com/cmswikis/comparing-drupal-vs-joomla-vs-typo3-and-others “Comparing Open Source CMSes: Joomla, Drupal and Plone”: http://www.idealware.org/articles/joomla_drupal_plone.php • “Joomla versus Drupal”: http://www.communicopia.net/blog/joomla-versus-drupal • “Wordpress vs Drupal”: http://www.bivingsreport.com/2007/wordpress-vs-drupal/ • “Wordpress vs. Drupal - Battle of the CMS”: http://www.brianchappell.com/wordpress-vsdrupal-battle-of-the-cms/ [xii] “The 2008 Open Source CMS Market Share Report, by Ric Shreves. Published by water&stone”: http://www.waterandstone.com [xiii] Premis Packt Publishing 2008: http://www.packtpub.com/article/2008-open-source-cmsaward-winner-announced Eines de comparació dels CMS [xiv] CMS Matrix: http://www.cmsmatrix.org/ Desenvolupament d’una aplicació web per a una ONG - 113 - [xv] OpenSourceCMS: http://php.opensourcecms.com/ [xvi] Llista de valoracions de CMS en PHP a OpenSourceCMS: http://php.opensourcecms.com/general/ratings.php Gestors de continguts [xvii] Joomla.org: http://www.joomla.org/ [xviii] Wordpress.org: http://wordpress.org/ [xix] Drupal.org: http://drupal.org/ Documentació i tutorials de Drupal Drupal.org: http://drupal.org/project/Modules Drupal.org - Themes: http://drupal.org/project/Themes Drupal.org - Modules: http://drupal.org/project/Modules Drupalmodules.com: http://drupalmodules.com/ Learnbythedrop.com: http://www.learnbythedrop.com GotDrupal.com: http://gotdrupal.com/ Masteringdrupal.com: http://www.masteringdrupal.com/ Theming guide - Drupal.org: http://drupal.org/theme-guide “Approaches to Access Control”: http://www.jefftraynor.org/node/96 Proves [xx] Mozilla.org: https://addons.mozilla.org/es-ES/firefox/addon/60 Consideracions finals [xxi] S’han utilitzat diverses fonts: • “Usar CMS o programar a medida un proyecto web”: http://www.seoprofesional.com/usar-cms-o-programar-a-medida-un-proyecto-web/ • “Las implicaciones de usar un CMS”: http://www.lucioalbenga.com/2008/11/03/lasimplicaciones-de-usar-un-cms/ Desenvolupament d’una aplicació web per a una ONG - 114 - • “¿CMS o desarrollo web personalizado?”: http://www.yafaonline.com/portal/joomla/joomla-noticias/cms-o-desarrollo-webpersonalizado.html Conclusions “Choosing the Right CMS Platform for Your Website (from an SEO perspective)”: http://www.seomoz.org/blog/choosing-the-right-cms-platform-for-your-website-from-an-seoperspective