Web 2.0 para la gestión de votaciones de usuarios

Trabajo Fin de Grado Escuela de Ingeniería Informática Universidad de Las Palmas de Gran Canaria Web 2.0 para la Gestión de Votaciones de Usuarios Alexandre Alemán Pérez Las Palmas de Gran Canaria 14 Noviembre 2013 Trabajo Fin de Grado realizado en la Escuela de Ingeniería Informática de la Universidad de Las Palmas de Gran Canaria, para la consecución del título de Grado en Ingeniería Informática. Título: Web 2.0 para la Gestión de Votaciones de Usuarios Alumno: Alexandre Alemán Pérez Tutor: Javier Sánchez Pérez Fecha: 14 de Noviembre 2013 “El secreto del éxito en la vida de un hombre está en prepararse para aprovechar la ocasión cuando se presente.” Benjamin Disraeli (1766-1848) Estadista inglés. A mi familia i Índice General Prefacio .........................................................................................................................................iv 1 Introducción .......................................................................................................................... 1 1.1 ProAct y sus motivaciones ............................................................................................. 1 1.2 Objetivos ....................................................................................................................... 2 1.3 Aportaciones ................................................................................................................. 3 1.4 Organización del documento ........................................................................................ 4 2 Estado actual del arte ............................................................................................................ 7 2.1 Historia .......................................................................................................................... 7 2.2 Plataformas de votación ............................................................................................... 8 2.2.1 Change.org ............................................................................................................ 8 2.2.2 Activism.com ......................................................................................................... 9 2.2.3 SuryeMonkey ........................................................................................................ 9 2.3 Relación entre ProAct y ProActPro ............................................................................. 10 3 Recursos utilizados .............................................................................................................. 13 3.1 Recursos software ....................................................................................................... 13 3.2 Recursos hardware ...................................................................................................... 14 4 Planificación del trabajo ...................................................................................................... 17 4.1 Metodología de desarrollo .......................................................................................... 17 4.1.1 Dirigido por casos de uso .................................................................................... 18 4.1.2 Centrado en la Arquitectura ................................................................................ 18 4.1.3 Iterativo Incremental........................................................................................... 19 4.1.4 Fases del Proceso Unificado de Desarrollo ......................................................... 20 4.2 Planificación y temporización ..................................................................................... 22 4.3 Presupuesto ................................................................................................................ 24 4.3.1 Coste Personal ..................................................................................................... 24 4.3.2 Costes inventariarles ........................................................................................... 25 4.3.3 Costes Fungibles .................................................................................................. 25 4.3.4 Costes Indirectos ................................................................................................. 25 4.3.5 Presupuesto Total ............................................................................................... 26 5 Desarrollo del trabajo.......................................................................................................... 27 5.1 Requisitos del sistema ................................................................................................. 27 ii 5.1.1 Modelo del dominio ............................................................................................ 27 5.1.2 Lista de características ........................................................................................ 31 5.2 Requisitos del software ............................................................................................... 34 5.2.1 Actores ................................................................................................................ 35 5.2.2 Modelo de casos de uso ...................................................................................... 36 5.2.3 Especificación de casos de uso más prioritarios ................................................. 43 5.2.4 Prototipo de interfaz de usuario ......................................................................... 47 5.3 Modelo de análisis ...................................................................................................... 51 5.3.1 Diagramas de clases ............................................................................................ 51 5.3.2 Diagramas de colaboración ................................................................................. 51 5.4 Modelo de diseño........................................................................................................ 62 5.4.1 Especificación de casos de uso ............................................................................ 62 5.5 Implementación .......................................................................................................... 75 5.5.1 ¿Por qué Drupal? ................................................................................................. 75 5.5.2 Módulos necesarios para la implementación ..................................................... 76 5.5.3 Instalación de Drupal........................................................................................... 83 5.5.4 Configuración y creación de los elementos del portal ........................................ 86 5.6 Pruebas y arranque del servidor ................................................................................. 95 6 Conclusiones y trabajo futuro ............................................................................................. 97 6.1 Conclusiones................................................................................................................ 97 6.2 Implementación Rest y Trabajo futuro ....................................................................... 98 Anexo I: Competencias ................................................................................................................ 99 Anexo II: Legislación vigente ..................................................................................................... 101 Anexo III: Manual de usuario .................................................................................................... 105 Anexo IV: Detalles de implementación ..................................................................................... 111 Bibliografía ................................................................................................................................ 113 iii iv Prefacio El trabajo expuesto en este documento refleja la realización de un proyecto de ingeniería del software que parte con el objetivo de desarrollar un portal web encargado de recibir propuestas de voto realizadas por los usuarios del portal. La pretensión de esta plataforma web es la de conseguir alcanzar un objetivo por cada una de las propuestas realizadas en el portal y a través de los votos de apoyo aportados por los usuarios. Un sistema de votaciones o de seguimientos como éste pretende mediante la unión de fuerzas ejercer una acción social que trascienda a través del apoyo a las causas expuestas y por tanto, efectuar un cambio en aquellos fundamentos sociales que el conjunto de la sociedad considera ya obsoletos. Se ilustrará la metodología de desarrollo empleada que en este caso es la del Proceso Unificado de Desarrollo Software (PUD) y se presentarán los productos generados según indica la misma, utilizando técnicas y herramientas como UML entre otras. Es una metodología Iterativa e Incremental, dirigida por casos de uso, centrada en la arquitectura y enfocada a detectar los posibles riesgos dentro del ciclo de vida del proyecto. La aplicación final hará uso del CMF Drupal encargado de la generación de portales a través de los distintos módulos. La interfaz ha ido generada mediante la modificación de los Themes de Drupal, además de la utilización del Paint como programa de diseño para los logotipos y colores que aportan una escala cromática certera al mismo. En último lugar, se muestran las pruebas generadas para comprobar el uso correcto de la aplicación, además de realizar alguna comparativa con el modelo de organizaciones generado de manera independiente. 1 1 Introducción El voto y la firma electrónica son expresiones que comprenden varios tipos de votación y que abarcan tanto modos electrónicos de emitir votos (votos por internet), como medios electrónicos de contar los votos. Las tecnologías del voto y firma electrónica pueden acelerar el conteo de los votos y proveer una mejor accesibilidad para los votantes con algún tipo de discapacidad, ya que en el caso de la firma electrónica se establece un equivalente electrónico al de la firma manuscrita, donde una persona acepta el contenido de un mensaje electrónico a través de cualquier medio electrónico válido Una vez sabiendo la validez de la firma y el voto electrónico en cualquiera de sus facetas y dentro de un marco previamente establecido, se ha fusionado la necesidad de ejercer una acción social a través de los sistemas con el uso de una plataforma sencilla pero eficaz. En relación a este objetivo, la plataforma se caracteriza por ser una herramienta social , basada en la utilización de las firmas como medio de comunicación, consiguiendo que miles de personas se unan en pro del cambio a través de una causa en lo que solía ser un trabajo arduo que requería mucho tiempo, dinero y complejas infraestructuras 1.1 ProAct y sus motivaciones ProAct o Propuesta Activa como su acrónimo indica, nace de la necesidad existente en la sociedad de expresar sus inquietudes formando propuestas o consultas de orden social, personal o lucrativo en algún modo, con el objetivo de ser apoyadas o seguidas por el mayor número de personas posibles. El proyecto estará basado en un portal web interactivo en el que todo aquel usuario que desee acceder al mismo pueda efectuar su propia propuesta, la cual posee un objetivo a batir. Para poder alcanzar el objetivo será necesaria la firma de los diferentes usuarios, ya sean contactos a los que se les invita a participar o usuarios del portal que quieren aportar su opinión a las propuestas expuestas en el mismo. La aplicación permitirá gestionar tanto las propuestas como las votaciones o firmas de los usuarios, además de ofertar múltiples funcionalidades propias de los portales webs 2,0. Entre éstas funcionalidades, nos encontraremos con la posibilidad de aportar comentarios a las propuestas publicadas en el sistema, compartir con sus conocidos a través de correo electrónico las propuesta que se han decidido publicar en el portal o incluso, realizar una aportación económica a través de una pasarela de pago. 8 2.2 Plataformas de votación En esta sección se muestran algunas de las plataformas más usadas dentro del mundo de las votaciones o encuestas electrónicas. 2.2.1 Change.org Change.org Inc. es una organización o corporación constituida legalmente como persona jurídica y cuyo negocio está vasado en la acogida libre y pública de peticiones por internet de carácter cívico, reformista, social y, en general reivindicativo del cumplimiento de los derechos humanos. Comenzó su prestación de servicios el 7 de febrero de 20073 siendo sus promotores el actual CEO Ben Rattray junto a Marcos Dimas. El amplio apoyo a las demandas a través de Change.org ha conseguido que muchas de sus peticiones se hayan logrado. En 2011 se propuso la fusión de la plataforma hispana Actuable en Change.org que se llevó a cabo en 2012 cuando se hizo efectiva la unión voluntaria de los usuarios de Actuable en la plataforma Change.org. 9 2.2.2 Activism.com Activismo.com es una plataforma nacida en 2009 y que opera en el sector de la recogida de firmas online. Esta plataforma está basada en la creación de peticiones de forma gratuita con la posibilidad de promover las peticiones en Facebook y en otras redes sociales. El modelo de desarrollo que propone esta plataforma es el de una empresa que se pone en el mercado como portadora de altos valores molares tales como el pleno cumplimiento de la ley, el respeto de los empleados que le dan vida y una competencia leal con otras estructuras que operan en el mismo ámbito. Fieles a las opciones básicas, Firmas Online se basa, por lo tanto, en los valores de honestidad, transparencia, privacidad, seguridad y competencia leal y están obligados a cumplir con ese Código de Conducta en todos sus actos, ya sean internos o dirigidos al mundo exterior. 2.2.3 SuryeMonkey SurveyMonkey es una herramienta web para la creación de encuestas online. La aplicación te permite diseñar y enviar encuestas a través del correo electrónico, un enlace en tu web o página de Facebook, etc… SurveyMonkey ofrece un “plan BASIC” gratuito con diversas funcionalidades. Una vez registrado ya se está listo para empezar: 10  Se puede crear una encuesta nueva agregando tú mismo las preguntas o seleccionando una plantilla de encuesta diseñada por un experto.  Modifica las opciones de la encuesta  Envía la encuesta seleccionando una o varias de las diferentes formas de envío. Por ejemplo, puedes enviarla por correo pero también puedes insertarla en tu página de Facebook.  Espera a obtener resultados. Los resultados puedes consultarlos desde la plataforma web y las versiones de pago te permiten también descargarlas a tu ordenador, establecer filtros o tabular datos 2.3 Relación entre ProAct y ProActPro El desarrollo de ProAct y ProActPro ha sido ideado como una plataforma general de votaciones subdividas por el volumen de trabajo que implican. Esta relación existente parte de la necesidad de libertad por parte de los usuarios de un portal a la hora de realizar propuestas y la integración de las organizaciones en el uso de las tecnologías de opinión y desarrollo. La dependencia de la cual parten las organizaciones o partidos políticos para su labor democrática ha sido la base fundamental para la creación de una plataforma que cumpla con los valores sociales a través de su sección pública y de herramienta primordial en cuanto a la comunicación mediante organizaciones a través de la participación de sus integrantes en el ámbito privado. 11 El desarrollo general parte de la misma base en las dos implementaciones aunque sus diferencias son más grandes de lo que pueda parecer ya que la implementación partirá de diferentes visiones de trabajo. En este sentido, podemos subrayar el foco de unión que crea una propuesta o una votación se ve distanciado según los objetivos marcados por cada uno de los proyectos. La objetividad que crea una plataforma cerrada como es la de ProActPro dificulta la utilización del usuario final al contrario que pueda suceder en ProAct. La implementación de ambos sistemas se ha ideado como una única plataforma en la cual se muestran englobados todos los servicios expuestos en ambos PUDs y que son reflejados en cada uno de los proyectos de forma independiente. Por todo ello, podemos hablar de una plataforma ideada para toda aquella persona que desee ejercer una reivindicación de forma libre y con todas las garantías que te ofrece un portal de este tipo. Por tanto, hablamos de un portal encargado de nutrir a las organizaciones de una herramienta imprescindible hoy en día, que pertenece al ámbito de la comunicación en su organigrama a través de los grupos o consultas creados por éstas. 13 3 Recursos utilizados A lo largo de este apartado se van a mencionar los diferentes requisitos Hardware y software necesarios para la implementación del portal. También se hará una breve descripción de cada uno de ellos. 3.1 Recursos software Los principales recursos software utilizados para la consecución de este proyecto son: - Microsoft Windows Ha sido el sistema operativo en el que se ha desarrollado el proyecto. Concretamente las versiones Vista y 7. - CMF Drupal es un CMF(Content Management Framework) modular multipropósito y muy configurable que permite publicar artículos, imágenes, y otras cosas u otros archivos y servicios añadidos como foros, encuestas, votaciones, blogs y administración de usuarios y permisos. Drupal es un sistema dinámico: en lugar de almacenar sus contenidos en archivos estáticos en el sistema de ficheros del servidor de forma fija, el contenido textual de las páginas y otras configuraciones son almacenados en una base de datos y se editan utilizando un entorno Web. Es un programa libre, con licencia GNU/GPL, escrito en PHP, desarrollado y mantenido por una activa comunidad de usuarios. Destaca por la calidad de su código y de las páginas generadas, el respeto de los estándares de la web, y un énfasis especial en la usabilidad y consistencia de todo el sistema. - Apache es un servidor web HTTP de código abierto y multiplataforma que implementa el protocolo HTTP 1.1. Está bastante extendido en Internet debido a su soporte y la cantidad de módulos disponibles que presenta. - StarUML es una herramienta CASE (Computer-aided software engineering) para UML (United Modeling Language). Se integra fácilmente con la metodología PUD permitiendo un desarrollo más ágil e integrado. - MySQL es un sistema de administración de bases de datos (Database Management System, DBMS) para bases de datos relacionales. Así, MySQL no es más que una aplicación que permite gestionar archivos llamados de bases de datos. Existen muchos tipos de bases de datos, desde un simple archivo hasta sistemas relacionales orientados a objetos. MySQL, como base de datos relacional, utiliza múltiples tablas para almacenar y organizar la información. MySQL fue escrito en C y C++ y destaca por su gran adaptación a diferentes entornos de desarrollo, permitiendo su interactuación con los lenguajes de programación más utilizados como PHP, Perl y Java y su integración en distintos sistemas operativos. - jQuery es una biblioteca de JavaScript, creada inicialmente por John Resig, que permite simplificar la manera de interactuar con los documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar animaciones (FLV) y agregar interacción con 14 la técnica AJAX a páginas web. Fue presentada el 14 de enero de 2006 en el BarCamp NYC. jQuery es la biblioteca de JavaScript más utilizada. jQuery es software libre y de código abierto, posee un doble licenciamiento bajo la Licencia MIT y la Licencia Pública General de GNU v2, permitiendo su uso en proyectos libres y privativos. jQuery, al igual que otras bibliotecas, ofrece una serie de funcionalidades basadas en JavaScript que de otra manera requerirían de mucho más código, es decir, con las funciones propias de esta biblioteca se logran grandes resultados en menos tiempo y espacio. Lenguajes utilizados en el desarrollo - HTML HyperText Markup Language (Lenguaje de Marcado de HiperTexto). Es un lenguaje de marcado utilizado para la realización de páginas web y que _estas se muestren en un navegador. Permite estructurar el contenido del documento web, el formateado de textos, así como incluir imágenes y otros tipos de objetos. - CSS Cascading Style Sheets (Hojas de Estilo en Cascada). Es un lenguaje creado para describir la semántica de la presentación del documento web. En la práctica se utiliza para dar formato a los elementos del documento web, dejando la estructura para el HTML o XHTML. En general se trata de uno o varios ficheros que indican mediante una serie de reglas el formato de los diversos elementos que componen el documento web. - Javascript Es un lenguaje interpretado que implementan los navegadores web que permite realizar un cierto conjunto de operaciones desde el lado del usuario tales como: interacción con el usuario, control del navegador, comunicación asíncrona y posibilidad de modificar el documento web una vez mostrado. - PHP Hypertext Pre-processor (PHP Preprocesador de Hipertexto). Es un lenguaje de programación de propósito general que trabaja en el lado del servidor. Fue diseñado para el desarrollo web de contenido dinámico. Se puede incorporar directamente en el documento HTML en lugar de llamar a un archivo externo que procese los datos. El código es interpretado por un servidor web con un módulo de procesador de PHP que genera la página Web resultante. - 3.2 Recursos hardware El proyecto se ha realizado con un ordenador portátil Acer 3230 diferenciado por las siguientes características:  Procesador Intel Core 2 Duo T8100 a 1,6 Ghz.  Memoria RAM 8 GB DDR2  Tarjeta Gráfica NVIDIA GeForce 8600M GT  Pantalla de 15,4 pulgadas 15  Conexión a Internet vía Wi-Fi Hardware Cliente  Sistema operativo: Windows XP, Windows Vista o Windows 7 / Apple Mac OS X 10.5 o superior (Intel)  CPU: Pentium 4, 2,4 GHz o versiones posteriores o AMD 2400 XP o versiones posteriores  Memoria del sistema (RAM): 512 MB  Disco duro: 2 GB de espacio libre  Velocidad de red: 768 Kbps  Tarjeta gráfica: DirectX9 compatible con 3D con 256 MB de RAM de vídeo  Pantalla: 1.280 x 1.024 en color real de 32 bits Hardware Servidor  Procesador: Pentium IV o compatible  Memoria RAM: 1 Gb  Disco Duro: 2 Gb libres  Placa de Red: Ethernet compatible  Otros: Tarjeta Gráfica, Monitor recomendable  Configuración de la Red  Red LAN que soporte TCP/IP (en general, Internet) 17 4 Planificación del trabajo En este capítulo se describirá la metodología aplicada para la realización de este proyecto, se desglosaran las tareas a realizar y se realizará una estimación temporal del desarrollo del mismo. También se realizará una estimación de los costes de mano de obra y material necesarios para el correcto desarrollo de este trabajo. 4.1 Metodología de desarrollo Para la realización del proyecto se ha optado por la metodología PUD (Proceso Unificado de Desarrollo de Software). El proceso de desarrollo de software puede definirse como el conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema software. Sin embargo, el Proceso Unificado de Software está basado en componentes, haciendo que el software resultante esté formado por componentes software interconectados a través de interfaces bien definidas. El Proceso Unificado de Desarrollo utiliza el Lenguaje Unificado de Modelado (UML) para definir y especificar las diversas partes de un sistema. Es un lenguaje con un fuerte bagaje debido a su amplio uso. Además, el proceso pone en práctica el basar gran parte del proyecto de desarrollo en componentes reutilizables, es decir, piezas de software con una interfaz bien definida. Esta metodología está encuadrada dentro de un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura, además de ser iterativo e incremental. La utilización de esta metodología permite realizar software de calidad cumpliendo con los objetivos propuestos. El ciclo de vida del proceso unificado consta de cuatro fases: 1. Inicio 2. Elaboración 3. Construcción 4. Transición 24 Presentación y Defensa Presentación y Defensa Horas Memoria TFG 50 Supervisión de la memoria el Tutor 10 Realización de copias y encuadernación 1 Preparación de Presentación Oral 5 Defensa Oral TFG 1 TOTAL 67 Resumen de la Planificación Concepto Horas GESTIÓN TFG 15 REALIZACIÓN Y TRAMITACIÓN EL TFG 24 CUESTIONES PREVIAS A LA REALIZACIÓN DEL TFG 11 DESARROLLO DEL TFG 278 PRESENTACIÓN DEL TFG 67 TOTAL 395 4.3 Presupuesto El presupuesto necesario para la realización de este proyecto se descompone en cuatro partes. Para cada una por separado se detalla el coste de la misma y al final se expone el coste completo de la realización del proyecto. 4.3.1 Coste Personal Para calcular los costes laborales lo primero sería determinar el coste por hora trabajada. En este caso se han determinado 16 euros cada hora trabajada por el alumno (suponiendo unos ingresos de 1280 euros brutos mensuales) y 30 euros cada hora trabajada por el profesor (2504 euros brutos mensuales). El reparto de horas dedicadas al proyecto por los distintos participantes quedará de la siguiente manera:  Tutor 14 horas  Alumno 300 horas 25 Teniendo en cuenta los datos anteriores, tendríamos los siguientes costes laborales por participante: Total Tutor: 14 horas * 30 euros = 420 euros Total Alumno: 300 horas * 16 euros = 4.800 euros Concepto Cantidad Precio por Unidad Precio Total Coste Laboral Tutor 14 30 420 Coste Laboral Alumno 300 16 4800 4.3.2 Costes inventariarles El material necesario para el proyecto sería de un ordenador portátil. El software necesario para la elaboración del proyecto no supondrá ningún coste debido al uso de software libre y licencias de estudiante. Para el portátil su coste es de 1.200 €. El coste total asciende a 1.200€. Teniendo en cuenta que el tiempo de amortización es de 48 meses, y que el equipo se usará durante 4 meses, el coste para ese periodo es de 1.200 * 4 / 48 = 100€ Concepto Cantidad Precio por Unidad Precio Total Ordenador Portátil 1 1200 1200 4.3.3 Costes Fungibles Para la entrega del proyecto es necesario realizar cinco copias del mismo y sus respectivas encuadernaciones. Las cuales habrá que entregar en la administración, por lo tanto el coste es: Precio por tomo: 0.05 euros/pagina * 2 (ambas caras) * 70 páginas + 6 euros (encuadernación) = 13 euros Los 5 tomos: 13 euros * 5 tomos = 65 euros Concepto Cantidad Precio por Unidad Precio Total Tomo de la Memoria 5 13 65 4.3.4 Costes Indirectos Son aquellos que no dependen directamente de la realización del proyecto, esto es: trabajo del personal de la administración, gastos en los servicios de alumbrado y de red del 26 edificio de informática etc. Estos costes son difíciles de calcular por su complejidad y variedad, así que para simplificar se ha presupuestado un 5% del total del presupuesto. (Coste de personal + Costes inventariarles + Costes fungibles) * 5%= 6485 * 5% = 324,25 € Concepto Total Porcentaje Precio Total CP+CI+CF 6485 5% 324,25 4.3.5 Presupuesto Total A continuación se muestra una tabla resumen con los costes asociados al proyecto: CONCEPTO COSTE Costes laborales del alumno 4800 Costes laborales del tutor 420 Costes materiales 1200 Costes de documentación 65 Costes indirectos 324,25 TOTAL PRESUPUESTO 6809,25 El presupuesto total del proyecto es de 6809,25 euros. 27 5 Desarrollo del trabajo En este capítulo se ilustrarán varios de los diferentes artefactos que se han seguido hasta llegar a obtener el producto final, desde la recopilación de requisitos hasta la etapa de diseño del software. La primera parte del desarrollo del proyecto consistirá en identificar los requisitos del sistema y los requisitos del software. Este estudio servirá como base para definir y delimitar el ámbito del proyecto, y para utilizarlo como guía de desarrollo. Las herramientas que se utilizarán serán el modelo del dominio, la lista de características y los casos de uso. La segunda parte de este capítulo permite definir cualquier característica que fuese deseable incluir en la aplicación y la última perfila de forma algo más concreta las funciones que se esperan del mismo. 5.1 Requisitos del sistema En este apartado se describirán dos artefactos muy importantes a la hora de establecer el ámbito en el que se moverá la aplicación: el modelo del dominio y la lista de características. También ayudan a los desarrolladores a comprender el contexto del sistema, además de poder recopilar requisitos funcionales y no funcionales. 5.1.1 Modelo del dominio Un modelo del dominio captura los tipos más importantes de objetos en el contexto del sistema. Los objetos del dominio representan las “cosas" que existen o los eventos que suceden en el entorno en el que trabaja el sistema. Muchos de los objetos del dominio o clases (para emplear una terminología más precisa) pueden obtenerse de una especificación de requisitos o mediante la entrevista con los expertos del dominio. Las clases del dominio aparecen en tres formas típicas: - Objetos del negocio que representan cosas que se manipulan en el negocio, como pedidos, cuentas y contratos. - Objetos del mundo real y conceptos de los que el sistema debe hacer un seguimiento, como la aviación enemiga, misiles y trayectorias. - Sucesos que ocurrirán o han ocurrido, como la llegada de un avión, su salida y la hora de la comida. El modelo del dominio se describe mediante diagramas de UML (especialmente diagramas de clases). Estos diagramas muestran a los clientes, usuarios, revisores y a otros desarrolladores las clases del dominio y cómo se relacionan unas con otras mediante asociaciones. Desarrollo de un modelo del dominio: El modelado del dominio se realiza habitualmente en reuniones organizadas por los analistas del dominio, que utilizan UML y otros lenguajes de modelado para documentar los resultados. Para formar un equipo eficaz, estas reuniones deberán incluir tanto a expertos del dominio como a gente con experiencia en modelado. 28 El objetivo del modelado del dominio es comprender y describir las clases más importantes dentro del contexto del sistema. Los dominios de tamaño moderado normalmente requieren entre 10 y 50 de esas clases. Los dominios más grandes pueden requerir muchas más. Los restantes cientos de clases candidatas que los analistas pueden extraer del dominio se guardan como definiciones en un glosario de términos; de otra manera, el modelo del dominio se hará demasiado grande y requerirá más esfuerzo del necesario para esta parte del proceso. Algunas veces, como en los dominios de negocio muy pequeños, no es necesario desarrollar un modelo de objetos para el dominio; en su lugar, puede ser suficiente un glosario de términos. El glosario y el modelo del dominio ayudan a los usuarios, clientes, desarrolladores, y otros interesados a utilizar un vocabulario común. La terminología común es necesaria para compartir el conocimiento con los otros. Cuando abunda la confusión, el proceso de ingeniería se hace difícil, si no imposible. Para construir un sistema software de cualquier tamaño, los ingenieros de hoy en día deben “fundir" el lenguaje de todos los participantes en uno solo consistente. Por último, es necesaria una llamada de atención sobre el modelado del dominio. Puede ser bastante fácil el comenzar modelando las partes internas de un sistema y no su contexto. Por ejemplo, algunos objetos del dominio podrán tener una representación inmediata en el sistema, y algunos analistas del dominio podrán a su vez caer en la trampa de especificar los detalles relativos a esa representación. En casos como estos, es muy importante recordar que el objetivo del modelado del dominio es contribuir a la comprensión del contexto del sistema, y por lo tanto también contribuir a la comprensión de los requisitos del sistema que se desprenden de este contexto. En otras palabras, el modelado del dominio deberá contribuir a una comprensión del problema que se supone que el sistema resuelve en relación a su contexto. El modo interno por el cual el sistema resuelve este problema se tratará en los flujos de trabajo de análisis, diseño, e implementación. Dominio de ProAct ProAct es una plataforma basada en una web 2.0 que permite a los usuarios crear propuestas de voto o procesos de seguimientos sociales de forma que éstas puedan alcanzar el objetivo propuesto cuando se generaron. El usuario que accede al portal podrá visualizar todas las propuestas de voto que se encuentren activas e incluso filtrarlas para poder visualizar las que desee en ese momento. En este orden de cosas se podrán visualizar ya no solo las propuestas activas sino aquellas que han conseguido su objetivo o incluso compartirlas con amigos y demás usuarios que se deseen. El proceso de creación de propuestas estará basado en la creación de una nueva propuesta la cual hay que marcarle un objetivo del orden del número de votaciones recibidas. Los usuarios que deseen generar una propuesta procederán a un registro el cual dará la posibilidad de la creación y el manejo de la misma a través de un usuario autenticado. Todas las propuestas generadas podrán ser modificadas para su mejor visión, comprensión o estética en el portal. La plataforma ejercerá un control sobre el número de votaciones efectuadas por todos los usuarios que acceden al portal. Para poder difundir una propuesta se hará uso de las redes sociales o correos electrónicos que permitan dar a conocer la misma. 29 Los usuarios que desean firmar una propuesta deberán dejar una reseña de sus datos basados en su nombre, apellidos y correo electrónico, además de ejercer el voto mediante el clic de un botón. También hay que ofrecer funcionalidades básicas de una Web 2.0, por lo que se permitirá agregar comentarios a las propuestas que se deseen, proporcionando una mayor interacción entre los usuarios que acceden al portal y sus objetivos dentro del mismo. Los usuarios podrán hacer uso de un servicio de mensajería interna que servirá como hilo de contacto entre los diferentes usuarios en el portal. Diagramas de Dominio Diagrama de Propuesta El siguiente diagrama gestiona la relación entre los diferentes elementos de una propuesta mostrando los elementos contenedores que forman una propuesta en sí. Se podrá observar la relación de uno a muchos entre los elementos que se alimentan de la actividad de los usuarios en contra punto con la victoria que forma parte de la finalización o la información reinante a lo largo de todo el ciclo de vida de la propuesta. Diagrama de relación entre el Usuario y la Propuesta El diagrama a mostrar nos permitirá visualizar las acciones pertenecientes a un usuario en relación a una propuesta previamente seleccionada o su opción de selección a través de la visualización. Firma Propuesta Contiene 1* Voto Contiene 1 * Comentario Victoria Contiene 1 0..1 Contiene 1 * 30 Diagrama con inclusión del usuario autenticado El siguiente diagrama pretende mostrar la necesidad del “usuario identificado” en el sistema mediante la inclusión de las clases “usuario identificado” y “perfil”. Estas clases serán las encargadas de permitir al usuario la creación de nuevas propuestas y la modificación de las propuestas que ya estén publicadas en el sistema, siendo el usuario el autor de las mismas. Clases del modelo de Dominio: Clase Usuario: esta clase simboliza un usuario anónimo dentro de la plataforma Clase Usuario Identificado: esta clase hereda de la clase usuario anónimo adquiriendo mayores privilegios que ésta. Firma Propuesta Contiene 1 * Voto Contiene 1 * Usuario Comentario Victoria Contiene 1 * Tiene 1 1Tiene 1 1 Visualiza 1 *Contiene 1 0..1 Tiene * 1 Firma Propuesta Contiene 1 * Voto Contiene 1 * Usuario Comentario Victoria Contiene 1 * Tiene 1 1Tiene 1 1 Visualiza 1 *Contiene 1 0..1 Tiene * 1 PerfilUsuario Identificado Tiene 11 31 Clase Perfil: esta clase pertenece al usuario identificado y permite que éste ejerza los privilegios adquiridos por su categoría en el sistema. Clase Firma: esta clase representa la firma de un usuario en una propuesta. Clase Propuesta: esta clase es el núcleo del sistema donde irán asociadas múltiples clases referentes en el sistema. Clase Voto: esta clase representa un voto de un usuario asociado a una propuesta. Clase Comentario: esta clase representa un comentario de un usuario asociado a una propuesta Clase Victoria: esta clase refleja el objetivo alcanzar por cada propuesta seleccionada 5.1.2 Lista de características La lista de características es un artefacto que se obtiene después de aplicar la tarea de “Enumerar los requisitos candidatos", que se propone en la metodología del PUD (Proceso Unificado de Desarrollo), para la captura de requisitos. Por lo tanto se encuentra englobada dentro de la fase de inicio. Esta lista sirve para contener las ideas de clientes, usuarios, analistas y desarrolladores a modo de fichas sobre los posibles aspectos que se podrían incluir en la aplicación, y que, posteriormente, se podrán traducir en requisitos del software. Estas ideas se consideran requisitos candidatos que se podrán desarrollar en la versión actual del sistema o se podrán postergar a versiones futuras. Este artefacto sirve para gestionar el proyecto y sólo se utiliza para la planificación del trabajo. Podrá ir variando a medida que avance el proyecto, pudiéndose añadir y modificar las características que se crean oportunas, en cualquier momento del desarrollo. “proceso unificado de desarrollo de software - Jacobson, Booch, Rumbaugh”. Leyenda Para describir las características, utilizamos una tabla con los siguientes campos: - Código: Es el identificador de la característica. Se especifica como LC + Categoría + Número. Las categorías se detallan más abajo. - Nombre de la característica. - Descripción: Breve descripción de lo que comprende la característica. - Prioridad: Se asigna una prioridad a cada una con el fin de determinar el orden en que se van a ir desarrollando. Las prioridades que se usarán serán dadas por un valor numérico que representa el nivel de prioridad donde 0 sería la más baja y 100 la más alta, luego están los rangos que se muestran a continuación.  80-100 (Muy alta)  60-80 (Alta)  40-60 (Media)  20-40 (Baja)  0-20 (Muy baja) 32 - Estado: Cada característica tiene un estado asociado que irá variando a medida que progrese el sistema. Los posibles estados son:  Aceptado: La característica se desarrollará en esta versión del producto.  Planificada: La característica ya ha sido planificada y se empezará a desarrollar en un plazo de tiempo corto.  En desarrollo: Ya se está desarrollando.  Finalizada: Se ha terminado de desarrollar.  Postergada: No se desarrollará hasta una versión futura.  Rechazada: Probablemente no se desarrollará en ninguna versión. - Riesgo: Cada característica puede tener asociado un riesgo que representa la dificultad para conseguir implementarla correctamente. Utilizamos tres niveles de riesgo:  Crítico  Significativo  Rutinario Para organizar tenemos los identificadores para cada tipo de usuario de la aplicación A. Usuario Anónimo en ProAct I. Usuarios Identificados en ProAct M. Usuario Moderador de ProAct AD. Usuario Administrador de ProAct Con los identificadores anteriormente propuestos podemos ayudar a colocarle un código a cada característica con respecto al usuario que realiza la funcionalidad. Código Nombre Descripción Prioridad Estado Coste Riesgo LC-A.1 Buscar Propuesta La aplicación permitirá a cualquier usuario introducir el nombre de una propuesta y mostrará los resultados de la búsqueda 99 Aceptada LC-A.2 Visualizar Propuesta La aplicación permitirá una propuesta previamente localizada. 98 Aceptada LC-A.3 Visualizar propuestas ganadas El usuario puede acceder a un listado de las distintas propuestas las cuales han logrado su objetivo. 64 Aceptada LC-A.4 Visualizar propuestas recientes El usuario podrá listar las propuestas más recientes introducidas en el portal. 66 Aceptada LC-A.5 Visualizar propuestas populares El usuario podrá visualizar en un listado las propuestas más firmadas del portal. 70 Postergada LC-A.6 Visualizar El usuario podrá acceder a 76 Postergada 33 propuestas organizadas por causas una lista de peticiones organizadas por la causa objetivo LC-A.7 Compartir Propuesta El usuario podrá compartir una propuesta mediante correo electrónico o Redes sociales. 94 Aceptada LC-A.8 Firmar propuesta El usuario puede rellenando sus datos firmar una propuesta determinada, apoyando la misma. 97 Aceptada LC-A.9 Integrar donativo mediante PayPal El usuario podrá aportar un donativo a la propuesta mediante una pasarela de pago 58 Aceptada LC-A.10 Realizar Comentario El usuario podrá comentar una petición determinada. 17 Aceptada LC-A.11 Denunciar propuesta El usuario podrá denunciar el contenido de una propuesta 40 Postergada LC-A.12 Navegar en el portal El usuario podrá navegar por las funcionalidades del portal 38 Aceptada LC-A.13 Cambiar idioma El usuario podrá cambiar el idioma del portal web 35 Postergada LC-A.14 Crear Cuenta El usuario debe registrarse en el sistema 99 Aceptada LC-I.1 Iniciar cesión El usuario debe autenticarse para crear una propuesta 98 Aceptada LC-I.2 Cerrar cesión El usuario podrá cerrar cesión 83 Aceptada LC-I.3 Crear propuesta El usuario efectuar una propuesta para su publicación 100 Aceptada LC-I.4 Editar propuesta El usuario podrá editar el formato de la propuesta 75 Aceptada LC-I.5 Borrar Propuesta El usuario que efectúa la propuesta podrá eliminarla. 77 Aceptada LC-I.6 Enviar Mensajes El usuario podrá enviar mensajes a cualquier creador de una petición en el portal 69 Postergada LC-I.7 Imprimir listado de El usuario podrá imprimir el listado de votos 10 Postergada 40 Casos de uso del usuario identificado Este diagrama es el encargado de mostrar los casos de uso que están asociados a los actores que se encuentran identificados y por tanto autenticados en el sistema. Como se puede observar en este diagrama, se han incluido los casos de uso de inicio y cerrar sesión que vienen explicados posteriormente en un apartado siguiente. Esta inclusión parte de la necesidad de mostrar en un diagrama el conjunto de casos de uso que formar parte del actor identificado. System Usuario Anónimo Visualizar Propuesta Buscar Propuesta Compartir Propuesta Firmar Propuesta Comentar Propuesta Visualizar Propuestas Victoriosas Visualizar Propuestas Recientes Visualizar Propuestas Populares Visualizar Propuestas clasificadas por Causas Navegavilidad del portal Cambiar Idioma Denunciar Propuesta Realizar Un Donativo Mediante PayPal 41 Casos de uso interrelacionados entre el moderador y el usuario identificado Este diagrama nos muestra los casos de uso relacionados con el usuario identificado, a excepción de los relacionados con el proceso de inicio de sesión, ya que estos casos están relacionados con el proceso de identificación y crear una relación directa con el usuario anónimo. System Usuario Identificado Iniciar Sesión Cerrar sesión Editar Propuesta Declarar una Propuesta Victoriosa Crear Propuesta Imprimir listado de firmantes Enviar Mensajes System Usuario Identificado Editar Propuesta Declarar Una Propuesta Victoriosa Crear Propuesta Imprimir listado de firmantes Enviar Mensajes Borrar Propuesta Moderador Bloquear Propuesta <<extend>> 42 Como bien podemos observar, los casos de uso mostrados en este diagrama poseen dependencia con el inicio de sesión de un usuario. La razón de esta dependencia parte del caso de uso de manejo de perfil de propuestas y de la comunicación con los usuarios del sistema. También, se puede observar como el moderador comparte un caso de uso con el usuario, ya que puede eliminar cualquier propuesta del sistema. Casos de uso del proceso de identificación En este diagrama se puede observar como el proceso de registro y de inicio de sesión poseen una relación directa con los roles de usuario anónimo y usuario identificado. Esta relacion viene dada por la necesidad existente de crear una propuesta previo registro de un usuario en el sistema y logeado dentro del mismo. También podemos observar como los casos de uso iniciar sesión y registro dependen el uno del otro, ya que son casos necesarios para hacer uso del sistema de forma correcta. Casos de uso relacionados con el moderador de forma aislada En este caso, llamamos a los casos de uso relacionados con el moderado de forma aislada ya que será el único actor en poder ejecutar estas acciones y por tanto es necesaria la creación de un diagrama aislado para el mismo. System Usuario Anónimo Usuario Identificado Registro de Usuario Iniciar sesión Cerrar sesión <<extend>> <<extend>> Moderador Borrar Causa Crear Causa 43 El moderador podrá crear o eliminar causas que servirán para englobar las múltiples propuestas en función de su objetivo social, político, religioso, etc…. Casos de uso relacionados con el administrador El administrador será el usuario encargado de la actualización y bloqueo en determinados momentos del portal, además de ser el encargado de asignar los roles correspondientes a los usuarios que accedan al sistema y que en un momento determinado y siendo participe del reglamento del portal, puedan ejercer el papel filtrante dentro del mismo. 5.2.3 Especificación de casos de uso más prioritarios Crear Propuesta Caso de Uso Crear Propuesta Actor Usuario Identificado Precondición El usuario debe de encontrarse identificado en el sistema Post condición La propuesta queda publicada en el sistema Flujo normal 1La aplicación mostrará un formulario en el cual el usuario podrá incluir la propuesta que desea efectuar en conjunto con su correo electrónico como nombre de usuario y el objetivo alcanzar. 2El sistema valida la información del formulario y la pública en el portal. Flujo alternativo 1.1 -El usuario no inserta toda la información necesaria para crear una propuesta. Administrador Actualizar Portal Bloquear Portal Dar Permisos a los roles de usuario 44 1.2 El sistema impide la creación de la propuesta mandando un mensaje para que se rellenen todos los datos. Buscar una Propuesta Caso de Uso Buscar una Propuesta Actor Usuario Anónimo Precondición Post condición El sistema mostrará un listado de propuestas según los parámetros de búsqueda introducidos Flujo normal 1El usuario introduce los parámetros que desea encontrar en el buscador. 2El sistema realiza la búsqueda dentro del portal 3Se muestra un listado o una propuesta relacionada con los parámetros introducidos. Flujo alternativo 1.1El usuario no introduce ningún parámetro de búsqueda. 1.2El sistema muestra todas las propuestas ancladas en el portal. Visualizar Propuesta Caso de Uso Visualizar Propuesta Actor Usuario anónimo Precondición El sistema este mostrando los títulos de las propuestas existentes en el sistema Post condición El sistema muestra la propuesta con las vicisitudes de la misma. Flujo normal 1El usuario selecciona la propuesta que desea visualizar. 2El sistema muestra la propuesta Flujo alternativo Firmar Propuesta Caso de Uso Firmar Propuesta Actor Usuario anónimo Precondición La propuesta debe estar visualizándose previa selección 45 Post condición La propuesta queda firmada por el usuario Flujo normal 1El sistema muestra un formulario con los campos requeridos para realizar la firma 2El usuario rellena los campos del formulario y presiona el botón de firmar. 3El sistema valida la firma y la registra con éxito en la propuesta. Flujo alternativo 2.1El usuario no rellena todos los campos necesarios para realizar la firma. 2.2El sistema impide su avance y avisa de la falta de cumplimentación de los campos. 2.1.1El usuario realiza una aportación económica a la firma rellenando los campos requeridos 2.1.2El usuario recibe la confirmación del ingreso de la aportación económica. Declarar victoriosa una propuesta Caso de Uso Declarar victoriosa una propuesta Actor Usuario Identificado Precondición El usuario debe encontrarse en la edición de la propuesta Post condición La propuesta queda declarada como victoriosa mostrándose como tal Flujo normal 1 - El usuario selecciona el botón de victoria de propuestas dentro de la edición de la misma 2 - El sistema comprueba si el objetivo marcado en la creación se ha cumplido. 3 - El sistema declara victoriosa la propuesta. Flujo alternativo 2.1El sistema indica que no se ha cumplido el objetivo a batir 2.2El sistema vuelve a la edición de la propuesta sin realizar cambios. Compartir Propuesta Caso de Uso Compartir Propuesta Actor Usuario anónimo Precondición El usuario debe encontrarse en la edición de la propuesta Post condición Se envían correos y mensajes a todos las personas indicadas Flujo normal 1El usuario rellena el formulario con los correos electrónicos con quienes desea compartir la propuesta 2Los correos son enviados correctamente. 46 Flujo alternativo 1.1El usuario rellena mal los correos de los usuarios a compartir. 1.2El sistema muestra un mensaje de error. 1.3El sistema vuelve al formulario de envío de correos. Crear Cuenta Caso de Uso Crear Cuenta Actor Usuario Anónimo Precondición Post condición El Usuario queda registrado en el sistema Flujo normal 1La aplicación mostrará un formulario en el cual el usuario aportará sus datos personales para crear su cuenta en la aplicación 2El sistema valida los datos y crea la cuenta del usuario en el portal Flujo alternativo 1.3 -El usuario no inserta toda la información necesaria para crear una elección. 1.4 El sistema impide la creación de la Elección mandando un mensaje para que se rellenen todos los datos. Iniciar Sesión Caso de Uso Iniciar Sesión Actor Usuario Identificado Precondición El usuario debe tener cuenta en el sistema Post condición El usuario queda logueado dentro del sistema Flujo normal 1El usuario introduce su nombre de usuario y contraseña 2El sistema comprueba los datos introducidos en el sistema 3El usuario accede al sistema tras su logueado Flujo alternativo 1.3El usuario no introduce correctamente el nombre de usuario o la contraseña 1.4El sistema muestra un mensaje indicando la introducción errónea de datos 1.5El sistema permanece en la introducción de nombre de usuario y contraseña 47 5.2.4 Prototipo de interfaz de usuario En esta sección se describirá la futura interfaz de usuario de la aplicación a nivel físico y los elementos que la componen. Esta parte del desarrollo del software es de vital importancia pues es la responsable de la manera en que el usuario interactúa con la aplicación , ya sea durante la entrada o salida de datos, la forma de operar con los mismos, la generación de flujos de trabajo u otros. 5.2.4.1 Interfaz Página Principal En esta imagen se muestra la interfaz relacionada con la página principal, dentro de la cual podemos observar como muestra una estética acorde a un portal de diseño ágil y sencillo pero con un control de cromática avanzado y una correcta visualización de las propuestas realizadas. En esta captura de pantalla podemos ver la simbiosis existente entre las últimas propuestas realizadas y las victorias conseguidas por los usuarios, además de observar la imagen que aporta un alto nivel de información sobre las propuestas realizadas en el portal. En esta página de inicio también podemos observar el menú de usuario disponible en la misma y que cambiara según el rol del usuario que accede al portal, además de la actividad reciente en el sistema que muestra el volumen de publicaciones en el portal. 5.2.4.2 Interfaz “Creación de Propuestas” En esta imagen se muestra la interfaz encargada de la creación de nuevas propuestas por parte de los usuarios que accedan al portal. 48 Esta segunda imagen sobre creación de propuestas, muestra como es la creación de una nueva propuesta partiendo de la cumplimentación del formulario siguiente, el cual está compuesto por el nombre de la misma y un conjunto de campos que permiten formar una propuesta adecuada. En esta imagen podemos observar como dentro del proceso de creación de propuestas se debe indicar el tiempo de expiración de la misma y si se ha conseguido la propuesta mediante la modificación del campo de victorias. Como se puede observar, existe una vinculación con la interfaz de ProActPro sin crear una dependencia entre ellas y por tanto permitiendo efectuar la labor encomendada sin que exista la necesidad de realizar funciones no especificadas en ProAct. 49 5.2.4.3 Interfaz encargada del voto y de efectuar comentarios Esta imagen nos muestra la interfaz encargada de efectuar una votación perteneciente a una propuesta publicada en el portal, además de realizar comentarios relacionados con la propuesta creando un proceso de interactividad entre los usuarios del portal. También se ha considerado la necesidad de aportar la firma de los usuarios a la propuesta seleccionada, dándoles a los autores la posibilidad de efectuar listados de apoyo que sirvan de futuro soporte legal a las mismas. 5.2.4.4 Interfaz encargada de visualizar una propuesta 56 Diagrama de colaboración para el flujo normal 5.3.2.4 Modelos para el caso de uso: Firmar Propuesta Una clase de análisis y sus objetos normalmente participan en varias realizaciones de casos de uso, lo cual se representa de la siguiente manera en el caso de uso Firmar Propuesta. En este diagrama nos vamos a encontrar con una interfaz “Formulario Firma” que será la encargada de recibir todos los datos de los usuarios firmantes de una propuesta que haya sido previamente seleccionada. Una vez relleno el formulario se procede a validar los datos que el firmante ha introducido a través del control de validación, que a su vez está asociada con el control de firma siendo éste el control encargado del paso intermedio y la contabilización de las nuevas firmas. Por último se muestra el aumento o la actualización del proceso de firmado. Firmar Propuesta Firmar Propuesta <<trace>> 57 Diagrama de colaboración para el flujo normal Diagrama de colaboración para el flujo alternativo 5.3.2.5 Modelos para el caso de uso: Declarar Victoriosa una Propuesta. Una clase de análisis y sus objetos normalmente participan en varias realizaciones de casos de uso, lo cual se representa de la siguiente manera en el caso de uso Declarar Victoriosa una Propuesta. En este diagrama podemos observar el uso de la interfaz de usuario correspondiente a la declaración de una victoria sobre una propuesta. En este sentido será necesaria la asociación con un control de validación, que será el control encargado de la verificación de la victoria en función del objetivo marcado en la creación de la propuesta. Por último se mostrará una entidad de información de FormularioFirma Valida Validar() 2 Firma NuevaFirma Mostrar() 4 Mostrar() 1 Enviar() 3 FormularioFirma Valida Validar() 1 Firma NuevaFirma Actualizar() 3 Enviar() 2 Declarar Victoriosa Propuesta Declarar Victoriosa Propuesta <<trace>> 58 victorias que se encargará de la publicación de la misma para una posterior visualización por parte de los usuarios del sistema. Diagrama de colaboración para el flujo normal Diagrama de colaboración para el flujo alternativo. IUVictoria InfoVictoria Valida IUVictoria InfoVictoria Valida 1 Enviar() 3 Mostrar() 2 Validar() IUVictoria InfoVictoria Valida 1 Enviar() 3 Mostrar() 2 Validar() 59 5.3.2.6 Modelos para el caso de uso: Compartir Propuesta Una clase de análisis y sus objetos normalmente participan en varias realizaciones de casos de uso, lo cual se representa de la siguiente manera en el caso de uso Compartir Propuesta. En este diagrama podemos observar como es necesaria una interfaz encargada del formulario de compartición o correo, que mediante el control de “Envío” y previo paso por el servidor de correo, muestra la información de la compartición a todos aquellos usuarios o personas con las que se desee compartir una propuesta. Diagrama de colaboración para el flujo normal Compartir Propuesta Compartir Propuesta <<trace>> FormularioCorreo Servidor InfoEnvio Envio FormularioCorreo Servidor 1 Enviar() InfoEnvio Envio 3 Mostrar() 4 Mostrar() 2 Validar() 60 Diagrama de colaboración para el flujo alternativo. 5.3.2.7 Modelos para el caso de uso: Crear Cuenta Una clase de análisis y sus objetos normalmente participan en varias realizaciones de casos de uso, lo cual se representa de la siguiente manera en el caso de uso Crear Cuenta En este diagrama podremos observar una interfaz llamada “Formulario Registro”, que será la encargada de mostrar el formulario que un usuario debe rellenar para crear su cuenta dentro de la aplicación. Una vez rellenado dicho formulario se procede a la validación de los datos introducidos en el sistema y se efectúa el registro de los datos en el sistema, mostrándose a continuación el apartado de inicio de sesión o de login del sistema. FormularioCorreo Servidor 1 Enviar() InfoEnvio Envio 3 Actualizar() 2 Validar() Crear Cuenta Crear Cuenta <<trace>> FormularioRegistro Validación Registro login 61 Diagrama de colaboración para el flujo normal. Diagrama de colaboración para el flujo alternativo. 5.3.2.8 Modelos para el caso de uso: Iniciar Sesión Una clase de análisis y sus objetos normalmente participan en varias realizaciones de casos de uso, lo cual se representa de la siguiente manera en el caso de uso Iniciar Sesión En este diagrama podemos observar el uso de un formulario de inicio de sesión que se encargará de la introducción del nombre de usuario y la contraseña de un usuario previamente registrado. Una vez relleno el formulario se procede al envío de los datos al servidor de validación que será el encargado de la comprobación de la identificación del usuario. Por último y una vez comprobada la autentificación de los datos se muestra el perfil del usuario. FormularioRegistro Validación Registro login 1Validar() 2 Enviar() 3 Mostrar() FormularioRegistro Validación Registro login 1Validar() 3 Actualizar() 2 Enviar() Iniciar Sesión Iniciar Sesión <<trace>> 62 Diagrama de colaboración para el flujo normal. Diagrama de colaboración para el flujo alternativo. 5.4 Modelo de diseño Durante el diseño modelamos el sistema y su arquitectura para que soporte los requisitos funcionales y no funcionales. Una entrada esencial al diseño es el modelo de análisis. En esta fase se realizará, por un lado, un diagrama detallado de las clases finales que existirán en el modelo de implementación. Estas clases en muchos casos serán similares a las obtenidas durante el análisis, aunque también aparecerán nuevas clases que no fueron identificadas en la anterior etapa. Además, para cada diagrama de clases se adjuntará un diagrama de secuencia, que mostrará la evolución de las clases a lo largo del tiempo y la interacción entre ellas. 5.4.1 Especificación de casos de uso 5.4.1.1 Modelos para el caso de uso: Crear Propuesta Una realización de caso de uso del diseño proporciona una traza directa a una realización de caso de uso de análisis en el modelo de análisis. FormularioSesión ServidorValidación Perfil FormularioSesión ServidorValidación Perfil 1 Validar() 2 Mostrar() FormularioSesión ServidorValidación Perfil +1 Validar() +2 Actualizar() 63 En el diagrama siguiente podemos observar el conjunto de clases a utilizar en el caso de uso “Crear Propuesta”. Haciendo una descripción del diagrama podremos ver como se hará uso de una clase de validación encargada de comprobar que los datos introducidos en el formulario sean correctos. También podemos observar como la clase de registro especificada en el diagrama será la encargada de grabar en el sistema la nueva propuesta y una vez realizada esta acción dar paso a una nueva propuesta. Por último es obligado mentar el formulario de creación de propuestas que ejerce la función que su propio nombre indica, además de actualizar su imagen en caso de encontrarse dentro del periodo de flujo alternativo. Diagrama de secuencia para el flujo normal. Crear Propuesta Crear Propuesta <<trace>> FormularioCrearPropuesta +Enviar() +Actualizar() RegistroPropuesta +Registrar() +Enviar() Valida +Validar() NuevaPropuesta +Mostrar() 64 Diagrama de secuencia para el flujo alternativo. 5.4.1.2 Modelos para el caso de uso: Buscar Propuesta. Una realización de caso de uso del diseño proporciona una traza directa a una realización de caso de uso de análisis en el modelo de análisis. En este diagrama se puede observar la utilización de la clase “Generar Formulario” que es utilizada para la creación de un nuevo formulario de búsqueda y que a su vez se complementa con la clase de validación de los datos que se han introducido en el buscador. No puede faltar la clase enviar, que se utiliza para el envío de los datos que ya han sido validados previamente. Las clases de muestra de formulario y de la muestra de los resultados efectuarán una labor de muestra tanto de los datos del formulario como de los datos que han sido recabados tras la búsqueda y que son generados por la clase generar Vista. Buscar Propuesta Buscar Propuesta <<trace>> 65 Diagrama de secuencia para el flujo normal. Diagrama de secuencia para el flujo alternativo. 72 5.4.1.7 Modelos para el caso de uso: Crear Cuenta Una realización de caso de uso del diseño proporciona una traza directa a una realización de caso de uso de análisis en el modelo de análisis. En este diagrama se puede observar la utilización de la clase “Formulario de registro”, que será la clase encargada de las operaciones de envío de los datos para validarse y la operación de actualización del formulario para crear los nuevos usuarios del sistema. También se puede observar como la clase de validación es la encargada de comprobar que los datos de los nuevos usuarios a registrarse sean los correctos y posteriormente enviarlos a la clase de registro, que será la clase realmente encargada de efectuar el registro de la nueva cuenta o de devolver el error y mostrar la actualización del formulario con los errores de registro. Por último la clase de login es la clase sobrevenida del correcto registro de una cuenta de usuario y procede a través de su operación de muestra de datos a la iniciación en el sistema. Crear Cuenta Crear Cuenta <<trace>> FormularioRegistro +EnviarValidación() +Actualización() Validación +EnviarValidación() +MostrarDatos() Registro +Actualización() +MostrarDatos() Login +MostrarDatos() 73 Diagrama de secuencia para el flujo normal. Diagrama de secuencia para el flujo alternativo. 5.4.1.8 Modelos para el caso de uso: Iniciar Sesión. Una realización de caso de uso del diseño proporciona una traza directa a una realización de caso de uso de análisis en el modelo de análisis. : Usuario Registrado FormularioRegistro Validacion Registro Login 1 : Seleccion() 2 : Envio() 3 : Validacion() 4 : Muestra() : Usuario Registrado FormularioRegistro Validacion Registro Login 1 : Seleccion() 2 : Envio() 3 : Validacion() Iniciar Sesión Iniciar Sesión <<trace>> 74 En este diagrama visualizamos la clase de formulario de inicio de sesión, la cual está compuesta por las operaciones de envío de datos y de actualización, que serán los encargados de la validación de los datos en el servidor y de la actualización del formulario en caso de error. La clase del servidor de validación a través de sus operaciones se encargara de validar y de enviar los datos allí comprobados tanto al perfil si la validación se procede de forma correcta, como al formulario para su posterior rectificación. Diagrama de secuencia para el flujo normal. Diagrama de secuencia para el flujo alternativo. FormularioSesión +Actualización() +Envio() ServidorValidación +Envio() +Actualización() Perfil +Mostrar() : Usuario Registrado FormularioIncioSesión ServidorValidación Perfil 1 : Rellenar() 2 : Enviar() : Usuario Registrado FormularioIncioSesión ServidorValidación Perfil 1 : Rellenar() 2 : Enviar() 75 5.5 Implementación En este capítulo de hará un repaso por toda la implementación del portal así como de los diferentes módulos necesarios para el funcionamiento del mismo. En primer lugar daremos una pincelada sobre la decisión de utilizar Drupal para efectuar el proyecto y poco a poco iremos desgranando la configuración e instalación para que el funcionamiento del mismo sea el adecuado. 5.5.1 ¿Por qué Drupal? Antes de empezar a explicar los distintos aspectos de implementación del portal, vamos a realizar una justificación del porqué el uso de Drupal a la hora de llevar a cabo la implementación del portal. Por todos es sabido que la implementación de un portal web se puede realizar con muchos lenguajes de programación y CMS varios que permiten diferentes funcionalidades. En este sentido, la elección de Drupal no es un acto fortuito sino una elección premeditada que parte de los múltiples conectores y módulos previamente implementados que aporta Drupal y que a la vez proporcionan a nuestro sistema un amplio abanico de funciones a integrar en el mismo. Si bien se ha decidido usar Drupal porque no solo nos facilita mucho la vida a la hora de realizar el portal, también se ha tomado esta decisión porque es una herramienta testada por la comunidad informática aportando su correcto funcionamiento. Así mismo, nos ofrece a diferencia de otros gestores de contenido la posibilidad de modificarlo tal y como queremos a nivel no solo de usuario sino a nivel de una persona con conocimientos avanzados sobre Informática. Esto no quiere decir que viene todo hecho sino que hay que saber aportar múltiples conocimientos para el buen uso de la plataforma.. El ciclo de aprendizaje en cuanto a Drupal se va logrando con la práctica y a medida que se va avanzando en la implementación del sitio Web en cuestión. Además de adquirise estos conocimientos se refuerzan conocimientos previos tales como Php, Mysql, etc. Como conclusión, hemos decidido finalmente que Drupal es la herramienta oportuna ya que nos aporta bastante flexibilidad para llevar a cabo los requisitos de nuestra plataforma. Es por ello aprovechando los conocimientos ya adquiridos en una de las asignaturas de la carrera nos ha permitido valorar la mejor opción de uso en cuanto al desarrollo de nuestro portal web. 76 5.5.2 Módulos necesarios para la implementación En primer lugar se va proceder a indicar donde hemos conseguido todos los módulos correspondientes para el buen funcionamiento del portal. Para ello y tras una ardua búsqueda, hemos decidido obtener todos los módulos directamente desde el sitio oficial de Drupal. Este portal nos proporcionará no solo la posibilidad de descargar el módulo sino también la posibilidad de obtener errores y opiniones de los distintos usuarios, los cuales ya han probado el módulo y han tenido la amabilidad de compartir esta información. Es por ello que resulta de gran utilidad esta información ya que nos ayuda bastante a la hora de buscar una solución en el caso de tener problemas con algún módulo, ya sea por un error nuestro o por no saber cómo configurar el mismo. Pudiendo así utilizar los comentarios de los distintos usuarios como valoración de si hemos instalando bien el módulo o no. En este momento nos encontramos en disposición de hacer un recorrido por los distintos módulos utilizados para implementar el sitio dando información de cada uno de ellos y así mismo justificando el porqué de uso. 77 5.5.2.1 Views Este módulo nos permite hacer vistas personalizadas de nuestro contenido, pudiendo de esta manera ordenar bien el contenido según su tipo, según su fecha de publicación o cualquier otro filtro. Hay muchas combinaciones posibles y es un módulo muy importante ya que nos permite agrupar contenido de nuestro portal además de filtrarlo de distintas maneras. Su uso está más que justificado ya que gracias a él podemos organizar todo el contenido tal y como se quiera. En nuestro caso hemos utilizado este módulo para hacer las distintas vistas relacionadas con las propuestas en general o las propuestas de cada uno, etc. 78 5.5.2.2 Panels El panels es otro módulo que en conjunto con el views nos permite la posibilidad de crear distintos paneles a una vista en concreto, así como realizar una vista personalizada en función de un contexto utilizando una relación Justificando el uso de este módulo, podemos decir que al hacer un Conten Pane crea una relación entre el usuario logueado mediante un elemento Token del sistema y la propuesta en concreto. Este proceso crea una asociación con el autor de la propuesta y permite la realización de una vista personalizada de sus propuestas. 5.5.2.3 Rules El modulo Rules es un excelente módulo el cual nos permite de una forma bastante intuitiva crear diferentes reglas en el portal, pudiendo hacer que el sistema sea bastante flexible y dinámico por decirlo de alguna forma. De esta forma podemos variar bastante el comportamiento del portal y configurar su comportamiento a nuestro gusto. 79 Justificamos el uso de este módulo sobre todo a la hora de poder impedir el acceso a contenido dentro del portal por parte de roles los cuales no tienen permiso. Al mismo tiempo podemos redirigir a otro sitio de nuestro portal en caso de que uno de estos roles intente acceder al mismo. 5.5.2.4 WYSIWYG Este módulo lo consideramos uno de los más importantes, ya que nos permite configurar el formato de edición a la hora de agregar contenido y de esta manera facilita al usuario su trabajo a la hora de agregar contenido al portal, pudiendo tener un formato cómodo a la hora de trabajar con el mismo. La justificación es bastante obvia y es el poder enriquecer el formato a la hora de crear contenido para el portal. 80 5.5.2.5 Page Manager Módulo importantísimo para poder modificar las distintas páginas del portal a gusto del consumidor, pudiendo modificar unas páginas en función de unas reglas o un comportamiento. También permite modificar la página principal o crear alguna página y agregarla o modificarla como queramos. Este módulo viene muy bien para poder enriquecer al portal de una forma dinámica su comportamiento, bien añadiendo reglas o bien, permitiendo una relación para mostrar cierto contenido o no. Su justificación en el portal es clara y es el poder mostrar contenido en función de los roles del portal así como poder modificar distintas páginas y mostrarlas tal y como se quiere. 5.5.2.6 Menú Administrador Módulo útil para poder administrar el sitio de una forma más cómoda ya que nos ofrece la posibilidad de navegar dentro de la configuración del sitio desde un menú navegable sin necesidad de estar perdiendo el tiempo. Su uso se justifica en que se ahorra tiempo a la hora de llegar al punto de configuración necesario. Masquerade Módulo el cual viene bastante bien a la hora de hacer pruebas ya que nos ofrece la posibilidad de cambiar de usuario sin necesidad de tener que estar cerrando la sesión del mismo. Tan solo con hacer clic al usuario que queremos cambiar este módulo realiza el cambio de sesión. 81 Este módulo viene muy bien a la hora de llevar a cabo pruebas con distintos roles y poder comprobar que efectivamente cada rol cumple su función. Su uso está más que justificado y es bastante sencilla ahorrándonos tiempo. 5.5.2.7 CCK Es un módulo muy útil el cual nos permite agregar campos a nuestro contenido, pudiendo ser estos campos personalizados. Por tanto esto nos ayuda en gran medida a realizar posteriores relaciones con los distintos contenidos del portal y nos simplifica bastante la vida pudiendo así hacer relaciones complejas dentro del portal. Su uso se justifica en el poder añadir campos en los distintos tipos de contenido y de esta forma hacer una relación o añadir los campos necesarios para poder llevar a cabo funcionalidades del portal. 88 Con los siguientes campos: Vistas del Portal Otro aspecto importante en la configuración del portal son las vistas, ya que son como se va a mostrar el contenido del portal y tienen la siguiente configuración: 89 En este caso lo que nos importa es la vista relacionada con mis propuestas y las propuestas en general, así como la página principal. A continuación vamos a mostrar la relación con respecto al contexto y la configuración de la vista formada en Mis Propuestas ya que es la realmente interesante en este caso: 90 Esta vista es una muestra de las formantes en el proyecto en relación a un contenido creado en el portal. Organic Group: Otro aspecto a tener en cuenta pero el cual se va desarrollando a media que se va utilizando el portal, es la inclusión necesaria de grupos por la necesidad existente de permitir el acceso a datos de forma exclusiva y por tanto lo que se ha hecho es incluir un tipo de contenido OG con las siguientes características. Como se puede observas en la fotografía se ha asociado este “tipo de contenido” como Grupo y como contenido de grupo, lo que posteriormente a la hora de crear un contenido se puede relacionar a este grupo creado. En la configuración de OG en el aspecto de Field Settings habría que añadir los campos correspondientes en este caso a propuestas. 91 Como se muestra en la captura de pantalla tenemos dos campos los cuales nos dan la posibilidad de crear una propuesta y asignar una de estas propuestas a algunos de los grupos. Menú Principal Un aspecto de configuración importante que nos da acceso a los distintos enlaces del portal así como según el rol asignado a cada usuario, es el acceso a ciertos enlaces o no. Vamos a pasar a comentar cada uno de los enlaces: 92 Inicio Enlace el cual nos da acceso a la página principal todos los usuarios tienen acceso a él. Propuestas Enlace el cual nos muestra la vista anteriormente comentada y nos da acceso a la vista Propuestas la cual tienen acceso todos los usuarios pero solo muestra el contenido al cual ellos pueden acceder. Crear Propuesta Enlace disponible para todos los usuarios el cual nos da la posibilidad de crear una propuesta directamente. Apariencia Que decir con respecto a este aspecto tan importante que es la apariencia, pues bien tras buscar en profundidad se ha decidido utilizar un tema llamado Business, el cual nos da la posibilidad de configurar tanto el logo como el juego de la paleta de colores dando un aspecto bastante sencillo pero elegante y cómodo para el usuario. 93 Personas Con respecto a este aspecto hemos definido diferentes roles de usuarios los cuales, ya han sido especificado en el uso de la metodología PUD previamente utilizada. Módulos Al respecto de los módulos, los cuales ya se han mencionado más arriba, se va mencionar el módulo instalado a respecto de las votaciones, el cual nos da la posibilidad de votar las propuestas. Configuración del servidor de Correo Interno Que decir acerca de este aspecto tan importante el cual nos permite enviar correos desde un servidor de salida SMTP. Ha sido un módulo imprescindible y por tanto se procedió a su 94 configuración para enviar correos desde nuestra web bien para confirmar a un usuario o para dar cierta información a ciertos usuarios. Rules Nos encontramos con un aspecto importante en el cual se han creado diferentes reglas dentro de las cuales se encuentran aquellas que no dejan acceder al perfil a personas no tengan permiso para acceder a la misma. 95 5.6 Pruebas y arranque del servidor Una vez realizada la instalación y la configuración del portal, faltaba una de las partes claves de un sitio web, que es su correcto funcionamiento. Para comprobar el correcto uso del portal se ha decidido utilizar un servicio de NO-IP, el cual ofrece la posibilidad de agregar un host mediante el cual se permite el acceso desde el exterior. El proceso realizado en este servicio comienza con la creación de una cuenta de usuario y configurando el host, el cual ha recibido el nombre de proact.no-ip-org 96 Tras realizar esta actividad se procedió a la apertura de puertos del router permitiendo posteriormente el acceso al portal desde una red ajena a la local. Encontrándonos en esta situación solo fue necesaria la descarga del software que proporciona el servicio de no-ip para modificar la ip de forma dinámica y mantener activa la base de datos y el servidor web Apache a través del Xampp 97 6 Conclusiones y trabajo futuro Una vez dada por concluida la fase de desarrollo y prueba del proyecto se pueden extraer conclusiones del trabajo realizado, así como realizar un pequeño compendio de posibles ampliaciones a la aplicación creada. Estos dos puntos se tratarán por separado en los apartados que vienen a continuación. 6.1 Conclusiones Una vez llegados a este punto y tras efectuar todo un recorrido por la introducción, legislaciones, análisis, desarrollo y otros aspectos a tener en cuenta, es momento de efectuar las conclusiones oportunas sobre la realización del proyecto. En primer lugar, quiero hacer mención a la evolución reinante a lo largo de todo el proyecto, ya que si bien es considerado el comienzo del proyecto y el desarrollo del mismo, no es menos cierto que la idea de formar un portal de esta envergadura pertenece a un valor contable dentro del proceso de desarrollo. Una vez dicho esto, la labor de documentación ha sido una labor ardua de investigación en la cual se han tenido que valorar cuales eran las piezas claves y el verdadero espíritu que iba a ser aportado al portal web en la relación existente con los usuarios. El motivo de tan extensa tarea, es que no se conseguía el mismo efecto de libertad a la hora de obligar a los usuarios a retener sus datos dentro del portal que realizando este acto y por consiguiente creaba una relación de dependencia con el mismo que se aleja de la finalidad por la que fue diseñado. En cuanto al análisis ha sido complicado discernir cuales eran las características reseñables a implementar y posteriormente los casos de uso asociados a las mismas, ya que podrían crear conflictos a la hora de ubicar la conjunción de los proyectos ProAct Y ProActPRo. Otra conclusión a reseñar, es la necesidad existente de separar las dos versiones de ProAct, ya que se pretende aportar a los usuarios dentro de la misma plataforma web un soporte completo y a la vez diferenciados que aporte un punto de vista social y personal y otro organizativo e institucional. Tras la conclusión del análisis y en el proceso de desarrollo, han existido escollos que en cierta medida han podido salvarse en mayor o menor medida, ya que si bien el CMS de Drupal aporta una plataforma de desarrollo útil y orientada a los usuarios de forma segura. También encapsula dentro de su núcleo determinadas opciones a implementar, como son los aspectos interactivos o de interfaces que requieren la entrada a desarrollo en bajo nivel y que merma la velocidad de desarrollo del portal en otras secciones del mismo. La decisión de dejar abiertas ciertas secciones del software, parte de la necesidad de renovación y actualización que viene implícita en este tipo de portales y a razón de este hecho se puede hacer hincapié en los controles de seguridad a realizar periódicamente para comprobar la eficiencia del portal. En definitiva, la experiencia ha sido una labor completa de los conocimientos adquiridos a lo largo de todos mis años de estudio y sobre los cuales me encuentro orgulloso. 105 Anexo III: Manual de usuario A grandes rasgos, hay dos perfiles de audiencia claramente definidos a los que va dirigido este manual: el primero, integrado en su totalidad por los usuarios que acceden al portal para apoyar las propuestas, compuesto por aquellos que no necesitas o no tienen privilegios específicos dentro del portal; y el segundo, formado por los usuarios que pretenden crear propuestas y controlar las mismas. Por lo general, tanto los usuarios anónimos como los pertenecientes al portal, tienen escasos conocimientos técnicos, referentes al backend y la programación web, aunque sí un nivel considerable de experiencia en la navegación. Este manual pretende transmitir los conceptos y la estructura de la nueva web de votaciones para que cualquier usuario pueda sacar el máximo partido de ella. Estructura conceptual de la web de votos La reorganización de contenidos y reestructuración informativa, se ha basado en respetar al máximo la claridad visual y la simplicidad de uso, sin menospreciar contenido alguno, aumentando con ello la usabilidad global del sitio. En este sentido el principal hecho a destacar es la integración de las redes sociales a través de sus logotipos correspondientes aportando la necesidad existente en todos los portales de mantener la comunicación social. Existen 3 niveles de navegación:  Navegación por menú: cumple con la función de menú principal homogénea en todas las vistas y es inamovible en las secciones públicas. Ésta recoge un total de cinco enlaces correspondientes a las principales secciones de la web. Cada uno de estos enlaces te conduce a la página donde se destacarán los contenidos más importantes.  Navegación por redes sociales: es visible en la parte superior izquierda del portal y permite la integración en el mismo de las redes sociales más conocidas aportando un claro valor de sociedad. Está formado por cuatro enlaces distinguidos por los logotipos referentes en cada una de las redes sociales.  Navegación de Propuestas: recoge los enlaces de acceso a algunos de los contenidos contextuales de varias secciones del menú principal. Esta muestra a su vez, navegación del contenido reinante en alguna de las secciones mostradas en el menú principal 106 Estructura de la navegación por menú Como ya se ha comentado anteriormente, dentro del grupo de páginas principales se han creado unos menús especiales para cada uno de los usuarios del portal. En esta barra de menú correspondiente a la navegabilidad de un usuario anónimo en el portal nos encontraremos con los enlaces: - Inicio - Propuestas - Victorias - Crear Propuestas - Entrar 107 La barra de menú siguiente nos muestra la estructura de la misma cuando el usuario es perteneciente al sistema, es decir cuando esta logueado en el mismo y puede acceder a secciones restringidas para los demás usuarios. - Inicio - Propuestas - Mis Propuestas - Victorias - Crear Propuestas - Salir Estructura de vista Propuestas y Victorias En estas vistas del portal se podrá observar la aparición de dos secciones que no existían en el portal principal y que permiten la navegabilidad y la comunicación e información de una forma ágil y sencilla. Los menús navegables serán:  Menú de inicio sesión: este menú situado en la parte intermedia derecha permitirá mediante la autenticación en el mismo el acceso a los perfiles creados por los usuarios ya inscritos en el sistema.  Menú de actividad reciente: cómo podemos observar es un menú el cual indica a los usuarios las diferentes actividades que se han sucedido en un corto espacio de tiempo en el portal y que están relacionadas con nuevas propuestas. 108 Estructura de una propuesta Una vez encontrándonos en la vista interior de una propuesta, podremos observar cómo se divide en diferentes secciones para conformar una estructura homogénea y fácil de usar. La vista de una propuesta está conformada por cuatro secciones:  Sección de Votación e Imagen: En esta sección se permite aportar un voto a la propuesta además de visualizar una imagen relacionada con la misma en conjunto a quien va dirigida  Sección de Firma: aquí nos encontramos con la aportación más importante y que permite a los usuarios aportar su forma a través de sus datos a las propuestas que deseen apoyar.  Sección de cuerpo: en este apartado se podrá leer el cuerpo de la propuesta y el motivo por el cual necesita el apoyo social.  Sección de vitorias: en este apartado se podrá observar si el usuario ha alcanzado el objetivo propuesto cuando creo la propuesta. 109 Estructura iniciar sesión Para poder tener efectuar aportar nuevas propuestas al portal, todo usuario debe de estar registrado en el sistema y por ende logueado dentro del mismo, por lo tanto es del todo imprescindible el uso de una sección de autenticación. La sección de autenticado está dividida en tres partes:  Creación de cuenta: El usuario a través de los datos solicitados por el portal crea su cuenta de usuario en el sistema para poder acceder a los perfiles de las propuestas que ha creado o va a crear dentro del mismo.  Iniciar sesión: El usuario que previamente ha creado su cuenta o que desea crear una petición y no se ha logueado requiere efectuar este paso previo para realizar la acción que desea.  Solicitar contraseña: Previo requisito de seguridad esta sección permite a un usuario ya perteneciente al sistema recuperar o renovar la contraseña de usuario dentro del portal. 110 Estructura de perfil de Propuestas Esta pantalla será la encargada del manejo de un perfil de propuestas y de la creación de una propuesta nueva y por ello se ha dividido en diferentes secciones para su mejor creación y modificación: El manejo de una propuesta se divide en seis secciones: - Nombre de la propuesta - A quien va dirigida la misma - Imagen de la propuesta - Cuerpo de la propuesta - Victoria de la propuesta - Tiempo en que expira la propuesta 111 Anexo IV: Detalles de implementación Seguridad Con respecto a la seguridad del portal, se han tenido en cuenta los distintos elementos de valor reinantes en un sistema que debe ser seguro para poder proporcionar las funciones de forma eficaz. A continuación se muestras los elementos de seguridad a tener en cuenta en la instalación del portal web: Quitar todos los archivos CHANGELOG.txt y demás archivos .txt que contengan información acerca de la versión de Drupal que estemos usando. Quitar todos los archivos CHANGELOG.txt y demás archivos .txt de los módulos que instalados en el portal. Quitar el archivo install.php Cambiar la ruta de login, esto es que cuando entre a /user me niegue el acceso y esto lo podemos solucionar con el hook_menu_alter via @jedihe Poner un límite de intentos en el login por ejemplo con este módulo: http://drupal.org/project/flood_controlsi pueden tener un certificado ssl sería muy bueno. El pilón: Si usan git o svn para mantener su sitio con los últimos cambios en el de producción, revisen los permisos de las carpetas site.com/.svn site.com/.git o archivos en concreto site.com/.gitignore site.com/.svn/entries, más información. Suscribirse a la lista de seguridad de Drupal http://lists.drupal.org/mailman/listinfo/securitynews http://drupal.org/security/secure-configuration 113 Bibliografía [1] BYRON, A. BERRY, A. HAUG, N. EATON, J. WALKER, J. ROBBINS, J. Drupal, Madrid: Ediciones Anaya Multimedia, 2º ed., 544 p, 2010. [2] MERCER, D. Building powerful and robust websites with Drupal 6, Birmingham: Packt Publishing Ltd., 2o ed. 380 p,2008. [3] VANDYK, J. Drupal Development Pro, United States of America: Apress, 2o ed, 661 p, 2008. [4] BOWEN, R. COAR, K Apache Cookbook, United States of America: O’Reilly, 1o ed., 306 p, 2007. [5] SUEHRING, S. PHP6 and MySQL, Canada: Wiley Publishing Inc, 1o ed., 873 p, 2009. [6] DRUPAL Community, World Wide Web: <http://drupal.org/>, Drupal [En línea],2010. [7]Manual de Identidad Corporativa [en línea], World Wide Web: http://www.unileon.es/ficheros/informacion_general/id_visual_corporativa/manual_ule.pdf, Universidad de León, 2010. [8] Wordpress [en línea], World Wide Web: http://wordpress.org/, Wordpress, 2010. [9] PhpMyAdmin [en línea], World Wide Web: <http://www.phpmyadmin.net/home_page/>, PhpMyAdmin configuration, 2010. [10]Escuela en Ingeniería Informática de la ULPGC, Pautas y Presentación del Grado, http://www.eii.ulpgc.es/tb_university_ex/sites/default/files/files/trabajos%20fin%20de%20gr ado/Pautas_Presentacion_TFG.pdf, 2012 [11]Catedra de Proyecto Ingeniería y Sistemas de información, Introducción al Puds http://visualfox.ar.tripod.com/download/proyecto_2005_b.pdf, 2005. [12]Abaco Creación, Legislación Vigente y Normativa para un portal Web, http://www.abacocreacion.com/web/soluciones_web/legislacion_paginasweb_cumplir_lssi_lo pd.php, 2012. [13]Wikipedia La enciclopedia Libre, Proceso Unificado Racional, http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational,2013. [14]Wikipedia La enciclopedia Libre, PHP, http://es.wikipedia.org/wiki/PHP,2013. [15]Wikipedia La enciclopedia Libre, MySQL, http://es.wikipedia.org/wiki/MySQL,2013.