Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Proyecto Final de Carrera
BCN Look & Find Tu sitio web de objetos perdidos y encontrados en Barcelona y alrededores
Título BCN Look & Find. Sitio web de objetos perdidos y
encontrados en Barcelona y alrededores
Autor David Santiso Puigarnau
Fecha 28 de marzo de 2012
Directora Ana Edelmira Pasarella Sánchez
Codirectora Amalia Duch Brown
Departamento Lenguajes y Sistemas Informáticos (LSI)
Titulación Ingeniería en Informática Técnica de Gestión
Centro Facultat d’Informàtica de Barcelona (FIB)
Universidad Universitat Politècnica de Catalunya (UPC) Barcelona Tech
1
Agradecimientos
Quiero agradecer a RDLab-‐LSI la colaboración en el proyecto, prestando un servidor donde alojar el sistema BCN Look & Find con acceso público y en especial a Gabriel Verdejo por la constante colaboración y ayuda resolviendo dudas técnicas en el proceso de instalación del sistema en el servidor. También agradezco a todos los usuarios que han colaborado en el testeo del sitio web, proponiendo funcionalidades, mejoras de diseño, usabilidad, etc.
2
Motivación personal
Tiempo atrás el análisis, desarrollo y diseño web comenzó a despertar mi interés. Pensé que el proyecto final de carrera era una buena oportunidad para adentrarme en este mundo y aprender, a la par que plasmar algo de lo aprendido en la carrera.
Buscando entre propuestas de proyectos relacionados con este campo, topé con la de Amalia Duch y Edelmira Pasarella que tenían una idea que prometía ser interesante. Su propuesta consistía en crear BCN Look & Find, un sitio web que hiciera de intermediario entre personas que pierden y/o encuentran objetos en la ciudad de Barcelona y alrededores. El sitio debía permitir el registro y búsqueda de objetos y facilitar el contacto entre las personas involucradas.
Inicialmente la idea me gustó, pero a su vez me sentía escéptico pensando que era difícil que la gente que pierde y encuentra objetos se parara a utilizar el sitio web. Mi escepticismo duró poco. Lo que tardé en comenzar a ver sitios web con el mismo propósito o con funcionalidades similares, cuyo desarrollo, diseño, uso, etc., dejaban mucho que desear y aun así eran utilizados.
3
Índice
1 Introducción .......................................................................................................................... 5
2 Preliminares ........................................................................................................................... 7
2.1 Conceptos básicos .......................................................................................................... 7
2.2 Conocimientos técnicos .................................................................................................. 7
2.3 Análisis de sistemas de gestión de contenido ................................................................ 8
3 Especificación del sistema ................................................................................................... 11
3.1 Análisis de otros sitios web ........................................................................................... 11
3.2 Usuarios ........................................................................................................................ 23
3.3 Objetos ......................................................................................................................... 23
3.4 Casos de uso ................................................................................................................. 26
3.5 Diagramas de secuencia ............................................................................................... 49
3.6 Flujo de objeto perdido ................................................................................................ 52
3.7 Flujo de objeto encontrado .......................................................................................... 53
3.8 Clases ............................................................................................................................ 54
3.9 Diseño de la interfaz ..................................................................................................... 58
4 Desarrollo del sistema ......................................................................................................... 75
4.1 Introducción al sistema eZ Publish ............................................................................... 75
4.2 Instalación del sistema ................................................................................................. 84
4.3 Desarrollo de secciones básicas .................................................................................... 85
4.4 Objeto encontrado y objeto perdido ............................................................................ 86
4.5 Categorías de objeto ..................................................................................................... 89
4.6 Estados de objeto ......................................................................................................... 89
4.7 Usuarios ........................................................................................................................ 90
4.8 Desarrollo de la página principal .................................................................................. 95
4.9 Desarrollo de la sección Comunidad ............................................................................ 97
4.10 Desarrollo del menú, cabecera y pie de página ......................................................... 97
4.11 Extensión de diseño del sistema eZ Publish ............................................................... 98
4.12 Extensión funcional del sistema eZ Publish .............................................................. 103
4.13 Posicionamiento del sitio web y otros desarrollos ................................................... 108
5 Experimentación ................................................................................................................ 110
5.1 Pruebas de usuario ..................................................................................................... 110
5.2 Encuestas .................................................................................................................... 112
4
6 Gestión del proyecto ......................................................................................................... 113
6.1 Estimación inicial ........................................................................................................ 113
6.2 Resultado final ............................................................................................................ 115
7 Conclusiones ...................................................................................................................... 117
8 Propuestas de trabajo futuro ............................................................................................ 118
Bibliografía ............................................................................................................................... 120
5
1 Introducción
Según el artículo “La Oficina de Hallazgos de Barcelona devuelve a sus propietarios el 86% de los objetos perdidos que le llegan”, del día 07 de Febrero de 2011, del periódico “La Vanguardia” (1), en la ciudad de Barcelona se pierden miles de objetos al año de los cuales, en el año 2010, llegaron 30.763 a la oficina de hallazgos del Ayuntamiento de Barcelona. De estos objetos, el 86% logró ser devuelto a sus propietarios.
Un reto importante de la susodicha oficina es poder devolver el porcentaje restante de objetos, además de otros que no están siendo registrados en esta oficina del Ayuntamiento de Barcelona. Para ello es muy importante poder facilitar a las personas que pierden o encuentran objetos en esta ciudad la posibilidad de registrar esta información.
Una manera de llevar a cabo esta tarea es aprovechando Internet. De hecho ya existen varias plataformas (que se analizan más adelante), con este fin. Sin embargo, desde nuestro punto de vista, todas ellas presentan serios inconvenientes. Por este motivo, en este proyecto se propone desarrollar un sitio web 2.0 que subsane la mayoría de los problemas que hemos detectado. En particular incluimos el tratamiento de centros de objetos perdidos que curiosamente no se tienen en cuenta en ninguna de las plataformas que hemos encontrado.
El objetivo principal del proyecto es crear una plataforma web lo más segura, consistente y usable posible, con la finalidad de hacer de intermediario entre personas que pierden y encuentran objetos perdidos en la provincia de Barcelona y alrededores. Y facilitar a oficinas de objetos perdidos, lugares o transportes públicos, comisarías de policía y cualquier otro centro donde se depositan objetos perdidos, la labor de devolver estas pertenencias a sus propietarios.
El objetivo principal se puede desglosar en varias sub-‐tareas.
• Analizar los déficits y los puntos fuertes de otros sitios webs con la misma finalidad. • Estudiar Sistemas de Gestión de Contenido.
o Aprender qué es un Sistema de Gestión de Contenido. o Analizar y comparar Sistemas de Gestión de Contenido web de libre
distribución, más populares. o Seleccionar un Sistema de Gestión de Contenido sobre el que desarrollar el
sistema BCN Look & Find. o Aprender a utilizar y familiarizarse con el Sistema de Gestión de Contenido
seleccionado. • Especificar el sistema BCN Look & Find. • Desarrollar el sistema BCN Look & Find. • Realizar pruebas de funcionalidad del sitio web.
o Simular uso del sitio web. o Obtener opiniones de usuarios reales. o Mejorar el sitio web en función de los resultados de los casos de pruebas
obtenidos.
6
• Meditar y exponer funcionalidades, extensiones, mejoras, etc., para posibles trabajos futuros del proyecto BCN Look & Find.
A continuación se describe cómo se ha estructurado la memoria con la finalidad de guiar al lector.
• En la Sección 2, se describen algunos conceptos básicos, tanto técnicos como teóricos, que irán apareciendo a lo largo de la memoria. Además se hará un análisis de sistemas de gestión de contenido, para escoger el más adecuado para la creación del sistema BCN Look & Find.
• En la Sección 3, se describe la especificación del sistema. Primero de todo se hace un análisis de otros sitios web con el mismo objetivo que BCN Look & Find, para extraer ideas y así decidir que tipo de funcionalidades y qué diseño tendrá el sistema. Posteriormente se especificarán los tipos y roles de usuarios que interactuarán con él, casos de uso, clases, etc.
• En la Sección 4, se describe cómo se ha llevado a cabo el desarrollo del sistema. • En la Sección 5, se describe la experimentación que se ha llevado a cabo, para
comprobar si el sistema cumple con los objetivos expuestos anteriormente. Y en el caso de no ser así, qué cambios se han tenido que llevar a cabo para solucionarlo.
• En la Sección 6, se expone la gestión del proyecto. El tiempo, recursos y costes estimados inicialmente para llevar a cabo el proyecto y el tiempo, recursos y costes reales que finalmente han sido necesarios.
• En la penúltima sección, se exponen las conclusiones a las que se ha llegado una vez terminado el proyecto.
• Finalmente se exponen algunas de las posibles extensiones del proyecto, a desarrollar en un futuro.
7
2 Preliminares
2.1 Conceptos básicos
En esta memoria se mencionarán algunos conceptos cuyas definiciones se muestran a continuación.
• Web 2.0. Según Wikipedia (2), un sitio web es 2.0 cuando permite que los usuarios interactúen con él. Ya sea comunicándose con otros usuarios, compartiendo información o de cualquier otro modo. El sitio web que se pretende crear es 2.0 ya que es necesaria una interacción de los usuarios, registrando datos de objetos entre otras cosas y una comunicación entre ellos.
• URL. Según Wikipedia (3), una URL (Localizador uniforme de conceptos), es una secuencia de caracteres, de acuerdo a un formato modélico y estándar, que se usa para nombrar recursos en Internet para su localización o identificación.
• Formularios POST y GET. En el lenguaje de programación web HTML, definido en la siguiente sección, se utilizan estos dos métodos para la creación de formularios. Estos formularios según WebTaller (4) son una de las herramientas de las que se dispone a la hora de hacer sitios web interactivas, en el sentido de que permite recopilar información del usuario que ve la página, procesarla y responder a ella, pudiendo de esta forma responder adecuadamente a sus acciones o peticiones. POST y GET son los métodos que se utilizan para transferir las variables del formulario. GET envía los datos añadiéndolos al URL de manera transparente al usuario. El método POST los envía de manera oculta.
• SEO. Según Wikipedia (5), el posicionamiento es el proceso de mejorar la visibilidad de un sitio web en los diferentes buscadores como Google, Yahoo o Bing de manera orgánica, es decir sin pagarle dinero al buscador para tener acceso a una posición destacada en los resultados.
2.2 Conocimientos técnicos
A continuación se presentan algunos conceptos necesarios para realizar la especificación y el desarrollo del sistema BCN Look & Find.
• Notación UML para la especificación de los casos de uso, diagramas de flujo, clases, etc. La documentación de apoyo ha sido extraída del libro “Enginyeria del Software Especificació” (6).
• Arquitectura, usabilidad y diseño web para la creación de un sitio web que garantice una buena experiencia de usuario. La documentación de apoyo ha sido extraída del documento “Arquitectura de la informació: Garanteix una bona experiència d'usuari” (7).
Los conocimientos técnicos previos para el desarrollo del sistema dependen en parte del sistema de gestión de contenidos escogido, pero generalmente se suelen utilizar los siguientes lenguajes para el desarrollo web.
8
• Lenguaje PHP. Según Wikipedia (8), PHP es un lenguaje de programación interpretado, diseñado originalmente para la creación de páginas web dinámicas. Su sitio web de documentación oficial es php.net (9).
• Lenguaje HTML. Según Wikipedia (10), HTML es el lenguaje de marcado predominante para la elaboración de páginas web. Es usado para describir la estructura y el contenido en forma de texto. Su sitio web de documentación oficial es w3schools.com (11).
• Lenguaje JavaScript. Según Wikipedia (12), JavaScript es un lenguaje de programación orientado a objetos y dinámico, utilizado principalmente en su forma del lado del cliente, implementado como parte de un navegador web permitiendo mejoras en la interfaz de usuario y páginas web dinámicas. La documentación de apoyo se ha extraído del sitio web w3schools (13).
• Hojas de estilo CSS. Según Wikipedia (14), CSS es un lenguaje de usado para definir la presentación de un documento creado en HTML. La documentación de apoyo ha sido extraída del sitio web csszengarden.com (15).
• Librerías JQuery. Según Wikipedia (16), JQuery es una librería de JavaScript, que permite simplificar la manera de interactuar con los documentos HTML, manejar eventos, desarrollar animaciones y agregar interacción con la técnica AJAX a páginas web. El sitio web oficial es jquery.com (17).
• AJAX, según Wikipedia (18), es una técnica de desarrollo web para crear aplicaciones interactivas. Estas aplicaciones se ejecutan en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas.
• Plantillas TPL. TPL es un formato de archivo en el que se define la estructura de un sitio web, utilizando el lenguaje HTML y a su vez carga contenido dinámico utilizando instrucciones definidas por un motor que depende de la librería o “framework” utilizado.
• Ficheros XML. Según Wikipedia (19), XML es un metalenguaje extensible de etiquetas que permite definir la gramática de lenguajes específicos. No es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades.
2.3 Análisis de sistemas de gestión de contenido
Uno de los requisitos de este proyecto final de carrera es el de desarrollar el sistema BCN Look & Find sobre un sistema de gestión de contenido, para ello es necesario llevar a cabo un estudio comparativo de los sistema de libre distribución más populares y seleccionar el más apropiado para los propósitos del proyecto.
Según Wikipedia (20), un Sistema de Gestión de Contenido (Content Management System, CMS), es una aplicación que permite crear una estructura de soporte para la creación y administración de contenido. En este caso el documento se centra en sistemas de gestión de contenido para sitios web.
Consiste en una interfaz que controla una base de datos donde se aloja el contenido del sitio web. Esta interfaz permite añadir módulos, editar el contenido y cambiar el diseño entre otras
9
cosas, utilizando un entorno gráfico. En todo momento permite acceder al código y editarlo manualmente.
Los sistemas de gestión de contenido de que se han escogido para llevar a cabo el análisis están desarrollados bajo licencia GNU GPL, por lo tanto son de libre distribución.
Drupal (21)
eZ Publish (22)
Joomla (23)
WordPress (24)
Las características, ventajas y desventajas de cada uno de los CMS que se exponen a continuación, se basan en información obtenida directamente de sus correspondientes sitios web oficiales referenciados anteriormente, de un testeo superficial y experiencias de terceros.
La tabla que se muestra a continuación contiene una lista de características y se indica qué CMS dispone de ella.
Características
Dispone de asistentes, ayuda, tutoriales, etc. ✔ ✔ ✔
Su contenido está indexado para facilitar su búsqueda ✔
Dispone de módulos oficiales descargables para extender el sistema ✔
Dispone de módulos no oficiales descargables para extender el sistema ✔ ✔ ✔
Utiliza bases de datos MySQL ✔ ✔ ✔ ✔
Utiliza bases de datos PostgreSQL ✔
Utiliza lenguaje PHP ✔ ✔ ✔ ✔
Utiliza lenguaje PHPTML ✔ ✔ ✔
Utiliza lenguaje CSS ✔ ✔ ✔ ✔
Utiliza lenguaje TPL ✔
Utiliza URL amigables ✔ ✔ ✔ ✔
Dispone de roles de usuario y permisos ✔ ✔
Dispone de sistema de control de versiones ✔
Se actualiza automáticamente ✔
Es multilenguaje ✔ ✔
Utiliza sistemas de memoria caché ✔ ✔ ✔
Dispone de comunidad de usuarios ✔ ✔
Permite escoger que paquete instalar ✔
Dispone de variedad de módulos por defecto ✔
Permite crear diferentes tipos de contenido ✔
Estructura el contenido basándose en directorios ✔
Permite crear borradores con publicación automática ✔
Permite crear extensiones ✔
10
Su página pública está separada de la de administración ✔ ✔
Su instalación es fácil ✔ ✔
Dispone de diferentes diseños oficiales descargables ✔ ✔
Su aprendizaje es corto y sencillo ✔
Dispone de diferentes diseños por defecto ✔
Dispone de una herramienta de edición de contenido muy completa ✔
Tabla 1, Análisis de CMS
Finalmente se ha optado por utilizar eZ Publish para el desarrollo del sistema BCN Look & Find. Las razones principales por las que se ha optado por este sistema son las siguientes.
• Es un sistema muy amplio y completo en comparación con otros CMS. • Dispone de un “framework” muy completo para desarrollos propios. • A pesar de que su aprendizaje es largo y costoso, parece más interesante, sobre todo
teniendo en cuenta que esto es un proyecto de ingeniería. • Es un sistema poco conocido y utilizado (al menos en España), pero que parece que
pueda llegar a ser uno de los mejores. Otras aplicaciones de eZ Systems son muy conocidas y utilizadas en todo el mundo. Muchas empresas buscan desarrolladores en “framework” eZ.
Una vez escogido el sistema de gestión de contenido sobre el que se va a desarrollar el sistema BCN Look & Find, es el momento de adentrarse en su funcionamiento.
11
3 Especificación del sistema
En este punto se especifica cada uno de los elementos que forman parte del sistema BCN Look & Find. En primer lugar es conveniente realizar un análisis de los puntos fuertes y de los problemas que puedan tener otros sitios web con el mismo objetivo.
3.1 Análisis de otros sitios web
Un ejemplo de sitio web de objetos perdidos que está bastante bien respecto a funcionalidad, diseño y usabilidad es Finder Base (25). De aquí han surgido muchas ideas, para el sistema BCN Look & Find.
En la página principal aparece un mapa centrado en la ubicación del usuario visitante, donde se marcan todos los objetos registrados en el sistema.
Ilustración 1, Finder Base, Página principal
Un mapa que localice los objetos no es totalmente imprescindible, pero utilizado de manera correcta y usable es una funcionalidad interesante a tener en cuenta.
12
Otro sitio web de objetos perdidos que hace un uso diferente de un mapa genérico en la página principal es Megalost (26).
Ilustración 2, Megalost, Página principal
Megalost (26) igual que Finder Base (25) es un sitio web de objetos perdidos que abarca el mundo al completo. En la primera fase del proyecto BCN Look & Find solo se pretende abarcar la zona de Barcelona y alrededores. Esto centra y facilita la búsqueda de objetos perdidos.
Megalost (26) dispone de un mapa mundial en su página principal con el objetivo de ubicar al usuario en un punto concreto. Antes de poder ver cualquier objeto registrado se debe seleccionar el país sobre el que se quiere realizar la búsqueda. Posteriormente una provincia y para finalizar una ciudad. Una vez llegados a este punto se muestran automáticamente los
13
objetos registrados, ubicados en la ciudad seleccionada, además de la posibilidad de añadir nuevos.
Quizás para un sitio web que abarque todas las ciudades del mundo es una manera óptima de ubicar al usuario, pero para un sitio web centrado en un área concreta es mucho más usable mostrar datos de objetos registrados en el sistema, sin obligar al usuario previamente a interactuar con el sitio web.
Llegados a este punto es el momento de hablar de la manera de mostrar los datos de los objetos registrados.
Algo curioso es que en ninguno de los dos sitios web mencionados requiere de la creación de una cuenta de usuario para acceder a los datos completos de los objetos registrados, pero a pesar de ello no se muestran públicamente en primera instancia. Por ejemplo en Finder Base (25), se muestran los datos del objeto de manera muy bien ordenada en una ficha en una sección aparte. Para acceder a ella hay que pulsar sobre alguno de los marcadores de objetos en el mapa.
Ilustración 3, Finder Base, Información de objeto
14
Es necesario que el usuario esté casi seguro que se trata del objeto que está buscando, antes de pulsar ningún botón y por supuesto antes de hacerlo cambiar de sección. Para ello es necesario mostrar parte de los datos del objeto en la página principal.
(26) Megalost por el contrario muestra un resumen de los datos del objeto, antes de entrar en la ficha completa de éste.
Ilustración 4, Megalost, Información de objeto
A pesar de ello, como se ha comentado antes es necesario escoger diversas opciones antes de llegar a ver información como ésta.
Una buena práctica para mostrar la información de objetos registrados en el sistema es la del sitio web Wikifinding (27). En este ejemplo muestra al usuario los datos del objeto que se han creído oportunos antes de acceder a su información completa.
Ilustración 5, Wikifinding, Resumen de objeto
En la página principal se muestra una lista de bloques como este, previamente de que el usuario comience a interactuar con el sitio web.
También es importante qué información se muestra y cómo se muestra. Por ejemplo la captura anterior es un buen ejemplo de diseño y estructuración de la información a mostrar. No se puede decir lo mismo de Objetos Perdidos (28).
15
Ilustración 6, Objetos Perdidos, Información de objeto
Puede que la información que muestra sea la correcta, incluso en el caso de objetos con fotografía se mostraba, pero es evidente que el diseño y estructuración de la información no es la correcta.
Otro ejemplo de mal diseño y estructuración de la información de los objetos registrados es la de Lost Objects Community (29).
Ilustración 7, Lost Objects Community, Resumen de objeto
Como además se puede observar en el ejemplo, la información del sitio web en general es demasiado extensa horizontalmente, de ahí a que la imagen tenga que ser tan pequeña para poderla adjuntar en el documento. Esto provoca que el usuario deba desplazarse no solo verticalmente para buscar un objeto en la lista de la página principal, sino que además debe hacerlo horizontalmente para poder leer toda la información.
En el caso de Oomia (30) el diseño es simple, pero la información se muestra ordenada y estructurada.
Ilustración 8, Oomia, Resumen de objeto
Un problema es que la simpleza con la que se muestra la información es tal que es necesario aclarar al usuario qué tipo de datos está viendo, este problema se resuelve mirando el nombre de las columnas en el inicio de la tabla, pero ya es necesario desplazarse.
Se debe tener en cuenta la cantidad de objetos que se pueden llegar a registrar en un sitio web de estas características. A pesar de necesitar mostrar objetos al usuario en la página principal, hay que controlar la cantidad. Para ello hay varios recursos. El más simple es limitar el número de objetos a mostrar y dividirlos en páginas, como en Wikifinding (27).
16
Ilustración 9, Wikifinding, Lista de objetos
Otra manera de reducir la cantidad de objetos a mostrar es estructurarlos de diversas maneras y añadir filtros de búsqueda. Una división bastante común y obvia es crear dos tipos de objetos, objetos que los usuarios han perdido y registrado y objetos que los usuarios han encontrado y registrado (perdidos y encontrados). Dentro de estos dos tipos de objetos se suelen dividir en categorías de objetos, como llaves, carteras, ropa, etc.
Ilustración 10, Oomia, Tipos de objeto
17
Oomia (30) por ejemplo, divide los objetos en perdido y encontrado y en categorías. Pulsando una opción, muestra los objetos pertenecientes al tipo y categoría seleccionado. A pesar de ello no muestra ningún objeto por defecto.
Wikifinding (27) divide los objetos por categorías y sub-‐categorías de manera demasiado concreta, pero no posee dos tipos de objetos diferenciados. También incluye unos filtros que muestran objetos recientes, destacados, los más vistos y aleatorios. Quizás estos últimos filtros de objetos no son totalmente necesarios.
Ilustración 11, Wikifinding, Categorías de objeto
Finder Base (25) estructura los objetos por tipo (encontrado y perdido) y por categorías generales. Además para mayor compresión del usuario utiliza iconos para diferenciar las categorías.
18
Ilustración 12, Finder Base, Categorías de objeto
Incluso Lost Objects Community (29) divide los objetos en perdidos y encontrados. Pero los muestra todos al mismo tiempo. Así que, aunque se limite la búsqueda de objetos por tipo, no se gana nada en cuanto a cantidad de objetos a mostrar.
Ilustración 13, Lost Objects Community, Tipos de objeto
Por supuesto cualquier estructuración, división y categorización de objetos es mucho mejor que ninguna, como es el caso de Objetos Perdidos (28).
Otra funcionalidad cuya disponibilidad debe ser inmediata es el registro de nuevos objetos en el sistema. Finder Base (25) es un buen ejemplo ya que dispone de dos opciones en el menú principal con las que se accede directamente a los formularios para añadir objetos perdidos o encontrados.
Ilustración 14, Finder Base, Registrar objeto
Oomia (30) también dispone de una opción en el menú principal para registrar objetos, pero su nombre “Añadir anuncio” puede confundir al usuario. El mismo caso ocurre con Lost Objects Community (29). Dispone de una opción en el menú principal, pero el nombre no es
19
apropiado “Publica tu anuncio gratis”. También se puede mencionar que su localización y diseño hace que sea poco llamativo.
Con el sitio web Megalost (26) ocurre el caso contrario. El usuario debe escoger diferentes opciones para seleccionar una ubicación antes de poder registrar un objeto. Una vez llegado a este punto se muestra un botón llamativo y bien diseñado para acceder al formulario, pero éste no diferencia entre objetos perdidos y encontrados, hasta que no se rellena el campo “estado” del formulario, que por cierto tampoco queda muy claro su significado.
Finder Base (25) dispone de una peculiaridad respecto al resto de sitios web. En el menú principal puede seleccionarse la opción “Community”. Al entrar en esta sección se muestra una lista de los diez usuarios que más objetos han encontrado y devuelto a sus propietarios. Este tipo de funcionalidades ayudan a que el usuario confíe en el sitio web y se sienta parte de él.
Ilustración 15, Finder Base, Top 10
20
Que el usuario reconozca rápidamente de que trata el sitio web que está visitando es muy importante. Y por supuesto que debe hacer en cada momento y que pasos seguir para conseguir su objetivo es algo que no debe pasarse por alto. Por ejemplo, cuando un usuario accede a Wikifinding (27) reconoce que está visitando un sitio web de objetos perdidos solo viendo la cabecera.
Ilustración 16, Wikifinding, Cabecera
Oomia (30) dispone de un mensaje corto y conciso en la cabecera que informa al usuario el objetivo del sitio web.
Ilustración 17, Oomia, Información
Megalost (26) provee al usuario de un vídeo en la página principal donde se explica cómo debe usarse y un pequeño texto explicativo que además mejora el aspecto del sitio web.
Ilustración 18, Megalost, Ayuda
Por el contrario en Objetos Perdidos (28) es complicado adivinar de qué trata la página. El título no tiene el tamaño, fuente ni color adecuado y está mal ubicado. Los objetos registrados se confunden con noticias generales. La publicidad llama demasiado la atención y además no
21
hay ningún texto, imagen o vídeo que informe al usuario del objetivo del sitio web y mucho de menos de los pasos que debe seguir.
Uno de los objetivos de BCN Look & Find es proveer a oficinas de objetos perdidos, empresas, transportes públicos, comisarías y otros centros de una plataforma donde también puedan registrar objetos que usuarios han perdido en su área o han depositado en ellos. Algunas empresas públicas ya disponen de sitio web propio para este cometido.
Por ejemplo, dispone de un apartado para objetos perdidos en su sitio web TMB (31). Como es obvio TMB no se dedica exclusivamente a devolver objetos perdidos a sus clientes, por lo tanto la sección de objetos perdidos de su sitio web simplemente está compuesta por un formulario donde el usuario puede hacer reclamaciones y donde se informa del proceso a seguir.
Algo similar, pero más simple todavía se encuentra en el sitio web de Institut Metropolità del Taxi (32). Dispone de un apartado para objetos perdidos, pero simplemente informa del proceso que debe seguir el usuario cuando ha dejada olvidada alguna pertenencia en un taxi de Barcelona.
Lo mismo ocurre con el sitio web del AVE (33). Esta sección informa al usuario del plazo máximo que disponen los clientes que han perdido pertenencias en cualquier dependencia de Renfe, para poder recuperarlas.
Como puede notarse es evidente que TMB, Taxis de Barcelona, Renfe y otros centros, oficinas, lugares y servicios públicos necesitan de un sitio web donde depositar información de objetos perdidos en sus dependencias.
El sitio web Megalost (26) dispone de algo que parte del mismo problema, pero en bajo nivel.
Ilustración 19, Megalost, Transportes
Estos iconos representan transportes públicos dónde clientes suelen olvidar su equipaje y otras pertenencias. Al pulsar cualquiera de estos iconos y tras seleccionar la ubicación, Megalost (26) muestra los objetos perdidos y/o encontrados en las estaciones del tipo de transporte seleccionado y en la ubicación seleccionada.
Una vez analizados los anteriores sitios web, se dispone de una serie de elementos funcionales y de diseño, que añadir en el sistema BCN Look & Find, de la misma manera que algunos problemas que se deben solucionar en esta nueva plataforma.
• El sitio web dispondrá en su página principal de una lista con el resumen de la información de los objetos registrados por los usuarios. Puesto que se pretende crear
22
un sitio web de objetos perdidos, lo primero que el usuario debe ver al entrar en el sitio web son objetos.
• Los objetos se dividirán en dos tipos (perdidos y encontrados) y dispondrán de una categoría con el objetivo de mantener un orden para que el usuario pueda buscar objetos e identificarlos lo más fácilmente posible.
• Para facilitar la búsqueda de objetos y controlar la cantidad de contenido de la página principal, los objetos que la lista mostrará dependerán de unos filtros que el usuario podrá seleccionar. El usuario podrá seleccionar el tipo de objeto que desea ver y/o la categoría a la que pertenecen. Para mejorar el diseño y a su vez la experiencia de usuario las categorías se representarán con imágenes. Además por las mismas razones, la lista de objetos se dividirá en páginas de cinco objetos.
• Uno de los atributos más importantes que los objetos registrados dispondrán es el la dirección postal aproximada donde se ha perdido o encontrado el objeto. Es más fácil para el usuario identificar un objeto si se conoce la zona aproximada donde se perdió o encontró. Para explotar al máximo esta información se añadirá en la página principal un mapa donde se marcarán los objetos que el usuario está visualizando en ese momento, teniendo en cuenta los filtros seleccionados.
• Una de las funcionalidades más importantes y básicas es la de permitir que los usuarios registren objetos perdidos y encontrados en el sistema. Dada su importancia el acceso a los respectivos formularios de registro tiene que ser lo más inmediato posible, por ello se añadirá un enlace a ellos en el menú principal, accesibles desde todas las secciones.
• Para animar a los usuarios a usar el sitio web, dar confianza y promover la creación de una comunidad, el sitio web dispondrá de una sección llamada “Comunidad”. Aquí el usuario podrá ver sus aportaciones, las aportaciones de otros usuarios, su perfil de usuario y una lista con los diez usuarios que más objetos han encontrado y devuelto a sus propietarios. Esta última funcionalidad también fomentará la participación de los usuarios convirtiendo la búsqueda de objetos perdidos en una especie de competición.
• Como ya se ha comentado en la Sección 1, se va a desarrollar un sitio web 2.0 donde los usuarios interactuarán entre ellos y con el sitio web, registrando objetos, notificando que han encontrado un objeto perdido registrado o que son los propietarios de un objeto encontrado registrado, etc. Por ello es necesario mantener un control de qué usuarios han insertado o modificado contenido en el sistema, además de la necesidad de algunos de sus datos personales como su dirección de correo electrónico. Para ello se ha decidido que los usuarios tengan que crear una cuenta de usuario registrado, para poder añadir o interactuar con objetos. También se requerirá de una cuenta de usuario para poder acceder a la sección “Comunidad”, reservada para miembros, ver información personal de usuarios y otros temas que requieren control por seguridad y privacidad de datos.
• Para facilitar el registro de objetos que han sido depositados en alguna oficina de objetos perdidos, lugar o transporte público o cualquier otro tipo de centro, se ha decidido crear un tipo de cuenta de usuario específica para este tipo de centros. Para que el resto de usuarios puedan hacer búsquedas específicas sobre un centro, en la página principal se incluirá otro filtro en forma de selector, que permitirá al usuario
23
seleccionar cualquier centro con cuenta de usuario y así poder visualizar únicamente los objetos registrados por éste.
• Por supuesto para orientar al usuario se incluirá la sección FAQ con ayuda y preguntas más frecuentes. Además de un formulario para enviar cuestiones concretas al administrador del sistema.
Una vez analizados otros sitios web de objetos perdidos y obtenida una idea de las funcionalidades y aspectos de diseño y usabilidad que se pretenden desarrollar, es el momento de comenzar con la especificación más concreta del sistema BCN Look & Find.
3.2 Usuarios A continuación se definen los tipos de usuarios que van a interactuar con el sistema y cuáles serán sus posibles roles.
• Visitante. Es aquel que solo puede acceder a las secciones públicas del sitio web. • Registrado. Usuario con una cuenta de usuario en el sistema con permisos para
acceder a parte de las secciones privadas del sitio web y para crear contenido. Dentro de este tipo de usuario, existe un subtipo con algunas peculiaridades.
• Centro. Persona jurídica registrada en el sistema en representación de una unidad organizacional que almacena objetos perdidos. Como por ejemplo: TMB, aeropuertos, centros comerciales, oficinas de objetos perdidos en general, etc.
• Administrador. Usuario con cuenta de usuario en el sistema con todos los privilegios.
Los roles que puede desempeñar un usuario que accede al sitio web se exponen a continuación.
• “Owner”. Usuario registrado que ha perdido un objeto de su propiedad. • “Finder”. Usuario registrado que ha encontrado un objeto que no es de su propiedad o
centro en el que se ha depositado un objeto perdido.
3.3 Objetos
Como antes se ha comentado, uno de los objetivos del sitio web es permitir que un usuario que ha perdido o se ha encontrado un objeto perdido, pueda registrarlo en el sistema con facilidad y rapidez. Esto implica que es necesaria la definición de dos tipos de objeto diferentes.
3.3.1 Tipos de objeto
• Objeto perdido es aquel objeto que un usuario con rol “owner” registra en el sistema cuando ha perdido un objeto de su propiedad.
• Objeto encontrado es aquel objeto que un usuario con rol “finder” registra en el sistema cuando se ha encontrado un objeto que no es de su propiedad o cuando ha sido depositado un objeto perdido en el centro al que representa.
De ahora en adelante se utilizará estar terminología para referirse a cada uno de los tipos de objeto.
24
3.3.2 Estados de objeto
Los objetos tienen un ciclo de vida dentro del sistema y puede encontrarse en los siguientes estados.
En paradero desconocido. El usuario con rol “owner” ha perdido un objeto y lo registra en el sistema. El objeto está en paradero desconocido.
Posiblemente encontrado. Un usuario con rol “finder” ha encontrado un objeto y cree que se corresponde con algún objeto en paradero desconocido registrado en el sistema.
Tras un proceso expuesto en la siguiente sección el objeto pasa a estar en estado posiblemente encontrado y pendiente de devolución.
Devuelto a su propietario. El usuario con rol “owner” , siguiendo un proceso expuesto en la siguiente sección, ha recuperado el objeto perdido que ha registrado en el sistema.
Se busca al propietario. El usuario con rol “finder” se ha encontrado un objeto perdido y lo registra en el sistema.
Tiene un posible propietario. Un usuario registrado con rol “owner” cree que el objeto encontrado, registrado en el sistema, del cual se busca al propietario, es de su
propiedad. Tras un proceso expuesto en la siguiente sección el objeto pasa a tener un posible propietario y a estar pendiente de devolución.
Devuelto a su propietario. El usuario con rol “finder”, siguiendo un proceso expuesto en la siguiente sección, ha devuelto a su propietario el objeto encontrado que había
registrado en el sistema.
Una vez mencionados los estados en los que se puede encontrar un objeto se define paso a paso el proceso que siguen para cambiar de un estado a otro.
Diagrama 1, Ciclo de vida de objeto
En el anterior diagrama se muestra el ciclo de vida de los objetos pedidos (izquierda) y el ciclo de vida de los objetos encontrados (derecha).
25
3.3.3 Ciclo de vida de objeto perdido
Como se ha comentado anteriormente, cuando el usuario con rol “owner” pierde un objeto y lo registra en el sistema, el objeto se crea automáticamente en estado En paradero desconocido, tal y como se muestra en la parte izquierda del diagrama 1.
El usuario con rol “owner” que ha dado de alta el objeto perdido en el sistema, puede darlo de baja en cualquier momento y el objeto es eliminado definitivamente del sistema.
Si el usuario recupera el objeto por sí mismo o de manera externa al sitio web, puede cancelar su búsqueda en vez de eliminarlo del sistema. Cuando el usuario pulse el botón “Cancelar búsqueda” el objeto pasará directamente al estado Devuelto a su propietario.
Si el usuario con rol “finder” encuentra un objeto y cree que se trata del objeto perdido que el usuario con rol “owner” ha registrado, pulsará el botón “Lo he encontrado”. De esta manera el objeto pasará automáticamente al siguiente estado Posiblemente encontrado.
En este momento se entra en el proceso de comprobación de la identidad del objeto. Automáticamente se envía un mensaje de correo electrónico al usuario con rol “owner” que ha registrado el objeto en el sistema. El mensaje de correo electrónico incluirá la dirección de correo electrónico del usuario con rol “finder”, (previamente se habrá avisado al usuario de que dichos datos serán enviados). De esta manera los usuarios podrán ponerse en contacto. El objeto permanecerá en este estado hasta que el usuario con rol “owner” que ha registrado el objeto en el sistema confirme o descarte la devolución del objeto.
• El usuario con rol “owner” se ha puesto en contacto con el usuario con rol “finder” y ha llegado a la conclusión de que el objeto no es de su propiedad. El usuario con rol “owner” pulsa el botón “Descartar” y el objeto vuelve a su estado inicial En paradero desconocido.
• El usuario con rol “owner” se ha puesto en contacto con el usuario con rol “finder” y ha llegado a la conclusión de que el objeto es de su propiedad. El usuario con rol “finder” devuelve el objeto al usuario con rol “owner” y éste pulsa el botón Confirmar. El objeto pasa al estado final Devuelto a su propietario.
3.3.4 Ciclo de vida de un objeto encontrado
Como se ha comentado anteriormente, cuando el usuario con rol “finder” se encuentra un objeto o es depositado un objeto perdido en el centro del que es responsable y lo registra en el sistema, el objeto se crea automáticamente en estado Se busca al propietario, tal y como se muestra en la parte derecha del diagrama 1.
Cuando el usuario con rol “finder” registra un objeto, tiene la opción de añadir una pregunta secreta sobre el objeto que solo el verdadero propietario sabe contestar correctamente. Esta pregunta secreta se muestra a todo usuario que quiera informar que es el propietario del objeto. La validación de la respuesta es totalmente manual. Como se mencionará en breve, el usuario recibirá esa respuesta por correo electrónico y dependiendo de ésta, podrá descartar al usuario que reclama el objeto sin necesidad de ponerse en contacto con él.
26
El usuario con rol “owner” que ha dado de alta el objeto encontrado en el sistema, puede darlo de baja en cualquier momento y el objeto es eliminado definitivamente del sistema.
Si el usuario devuelve el objeto a su propietario por sí mismo o de manera externa al sitio web, puede cancelar la búsqueda del propietario del objeto en vez de eliminarlo del sistema. Cuando el usuario pulse el botón “Cancelar búsqueda” el objeto pasará directamente al estado Devuelto a su propietario.
Si el usuario con rol “owner” reconoce el objeto y cree que es de su propiedad, pulsará el botón “Es mío”.
• Si el usuario con rol “finder” ha registrado el objeto con una pregunta secreta, el usuario con rol “owner” deberá responder a dicha pregunta, (que la respuesta sea correcta o no, dependerá del usuario con rol “finder” que la recibe). De lo contrario el objeto no cambiará de estado.
• Si el usuario con rol encontrado ha registrado el objeto sin pregunta secreta, el objeto cambiará automáticamente de estado, ya que el usuario con rol “finder” ha decidido no añadir ninguna validación previa.
Si se cumple uno de los dos casos anteriormente mencionados, el objeto pasará automáticamente al siguiente estado Tiene un posible propietario.
En este momento se entra en el proceso de comprobación de la identidad del propietario. Automáticamente se envía un mensaje de correo electrónico al usuario con rol “finder”. El mensaje incluye la dirección de correo electrónico del usuario con rol “owner” , (previa confirmación) y la respuesta a la pregunta secreta si la hay. De esta manera los usuarios pueden ponerse en contacto. El objeto permanece en este estado hasta que el usuario con rol “finder” que ha registrado el objeto en el sistema confirma o descarta la devolución del objeto.
• El usuario con rol “finder” considera que la respuesta a la pregunta secreta no es correcta, (si la hay) o se ha puesto en contacto con el usuario con rol “owner” y ha llegado a la conclusión de que el objeto no es de su propiedad. El usuario con rol “finder” pulsa el botón “Descartar” y el objeto vuelve a su estado inicial Se busca al propietario.
• El usuario con rol “finder” considera que la respuesta a la pregunta secreta es correcta, (si la hay) y se ha puesto en contacto con el usuario con rol “owner” y ha llegado a la conclusión de que el objeto es de su propiedad. El usuario con rol “finder” devuelve el objeto a su propietario y pulsa el botón “Confirmar”. El objeto pasa al estado final Devuelto a su propietario.
A continuación se exponen los casos de uso.
3.4 Casos de uso
Los siguientes diagramas representan cada uno de los casos de uso que los usuarios pueden efectuar en el sistema. En primer lugar se muestra la jerarquía de los tipos de usuario definidos
27
en la Sección 3.2, utilizando un diagrama de jerarquía de actores y utilizando como documentación de apoyo el libro Enginyeria del Software Especificació (6).
• Todos los tipos de usuario pueden acceder a los casos de uso de un usuario visitante, por lo tanto el resto de usuarios se sitúan por debajo jerarquicamente.
• Los usuarios de tipo centro disponen de unos casos de uso específicos, pero a su vez son también accesibles por los usuarios de tipo registrado. Es por ello que éste últimos se sitúa por debajo jerarquicamente.
• Los usuarios de tipo registrado pueden acceder a los casos de uso de un usuario de tipo centro y a su vez disponen de casos de uso específicos.
• Por último el usuario de tipo administrador dispone de casos de uso específicos, accesibles desde la página de administración o desde el propio sitio web. Por supuesto también tiene acceso a los casos de uso del resto de tipos de usuario, pero no se le puede considerar una extensión de estos, ya que la utilización de estos casos de uso sería con el fin de administración y no con el mismo objetivo que el resto de usuarios.
A continuación se muestra el diagrama teniendo en cuenta estas características.
Diagrama 2, Jerarquía de usuarios
28
3.4.1 Casos de uso de usuario visitante
Los casos de uso expuestos a continuación pretenden reflejar el uso que los usuarios de tipo visitante pueden darle al sitio web.
Diagrama 3, Casos de uso usuario visitante
Buscar objetos por buscador
• Actores. Usuario visitante. • Descripción. El usuario quiere buscar un objeto utilizando el buscador. • Escenario principal de éxito.
o El usuario escribe una palabra o palabras que pueden estar contenidas en el objeto que está buscando y pulsa el botón Buscar.
o El sistema muestra una lista con el nombre de los objetos que contienen esa palabra o palabras en su nombre o el resto de su información.
• Extensión 1. o El usuario pulsa sobre el enlace del nombre de uno de los objetos de la lista. o Se accede al caso de uso Intentar ver información de objetos.
Buscar objetos por etiquetas
• Actores. Usuario visitante.
29
• Descripción. El usuario quiere buscar un objeto utilizando la nube de etiquetas. • Escenario principal de éxito.
o El usuario pulsa sobre alguna de las etiquetas contenidas en el bloque de la nube de etiquetas.
o El sistema muestra una lista con el nombre de los objetos que contienen esa etiqueta.
• Extensión 1. o El usuario pulsa sobre el enlace del nombre de uno de los objetos de la lista. o Se accede al caso de uso Intentar ver información de objetos.
Ver información del sitio web
• Actores. Usuario visitante. • Descripción. El usuario quiere ver la información del sitio web. • Escenario principal de éxito.
o El usuario pulsa el enlace Sobre nosotros del pie de página. o El sistema muestra esta sección con la información del sitio web.
Ver F.A.Q
• Actores. Usuario visitante. • Descripción. El usuario necesita ayuda y quiere ver las preguntas más frecuentes. • Escenario principal de éxito.
o El usuario pulsa el enlace Preguntas más frecuentes del pie de página. o El sistema muestra esta sección con las preguntas más frecuentes.
Enviar consultas
• Actores. Usuario visitante. • Descripción. El usuario tiene preguntas y quiere transmitirlas al administrador del sitio
web. • Escenario principal de éxito.
o El usuario pulsa el enlace Formulario de consulta del pie de página. o El sistema muestra el formulario de consulta. o El usuario rellena el formulario de consulta. o El sistema envía la consulta al administrador del sitio web.
Ver condiciones de uso
• Actores. Usuario visitante. • Descripción. El usuario quiere leer las condiciones de uso. • Escenario principal de éxito.
o El usuario pulsa el enlace Condiciones de uso del pie de página. o El sistema muestra la sección con las condiciones de uso.
Ver política de privacidad
• Actores. Usuario visitante.
30
• Descripción. El usuario quiere leer la política de privacidad. • Escenario principal de éxito.
o El usuario pulsa el enlace Política de privacidad del pie de página. o El sistema muestra la sección con la política de privacidad.
Ver resumen de objetos
• Actores. Usuario visitante. • Antecedentes. El usuario está visualizando la página principal. • Descripción. El usuario quiere ver el resumen de la información de los objetos
registrados en el sistema. • Escenario principal de éxito.
o El sistema muestra una lista con el resumen de la información de los objetos. • Extensión 1.
o El usuario pulsa sobre el botón Objetos para localizar. o El sistema muestra una lista con el resumen de la información de los objetos
perdidos. • Extensión 2.
o El usuario pulsa sobre el botón Objetos para devolver. o El sistema muestra una lista con el resumen de la información de los objetos
encontrados. • Extensión 3.
o El usuario pulsa sobre una categoría. o El sistema muestra una lista con el resumen de la información de los objetos
de esa categoría y del tipo perdido o encontrado, seleccionado. • Extensión 4.
o El usuario selecciona un centro de la lista de selección Objetos bajo custodia. o El sistema muestra los objetos registrados por el centro, del tipo perdido o
encontrado y categoría, seleccionada. • Extensión 5.
o El usuario pulsa sobre el botón Entrar, para ver la información completa de algún objeto de la lista.
o Se accede al caso de uso Intentar ver información de objetos. • Extensión 6.
o El usuario con rol “finder” pulsa sobre el botón Lo he encontrado de algún objeto de la lista, para notificar que ha encontrado el objeto.
o Se accede al caso de uso Intentar marcar objetos. • Extensión 7.
o El usuario con rol “owner” pulsa sobre el botón Es mio de algún objeto de la lista, para notificar que es de su propiedad.
o Se accede al caso de uso Intentar marcar objetos.
Intentar añadir objetos
• Actores. Usuario visitante. • Descripción. El usuario quiere añadir un nuevo objeto de tipo perdido o encontrado.
31
• Escenario principal de éxito. o El usuario pulsa el botón Añadir objeto y sobre una de las dos opciones Objeto
perdido o Objeto encontrado. o Se accede al caso de uso Registrarse.
Intentar ver la sección comunidad
• Actores. Usuario visitante. • Descripción. El usuario quiere ver la sección “Comunidad”. • Escenario principal de éxito.
o El usuario pulsa sobre la opción del menú principal Comunidad. o Se accede al caso de uso Registrarse.
Ver último objeto devuelto
• Actores. Usuario visitante. • Antecedentes. El usuario está visualizando la página principal. • Descripción. El usuario quiere ver el resumen de la información del último objeto
devuelto a su propietario. • Escenario principal de éxito.
o El sistema muestra un anuncio con el resumen de la información del último objeto devuelto a su propietario.
• Extensión 1. o El usuario pulsa sobre el enlace Ver más historias como ésta. o Se accede al caso de uso Intentar ver aportaciones de la comunidad.
Intentar ver información de objetos
• Actores. Usuario visitante. • Antecedentes. El usuario está visualizando el resumen de la información de un objeto
en la página principal, ha pulsado sobre una etiqueta de la nube de etiquetas o ha efectuado una búsqueda con el buscador.
• Descripción. El usuario quiere ver la información completa de alguno de los objetos que está visualizando.
• Escenario principal de éxito. o El usuario pulsa sobre el botón Entrar o sobre el enlace del nombre del objeto,
dependiendo de su ubicación. o Se accede al caso de uso Registrarse.
Intentar marcar objetos
Pueden darse dos casos dependiendo del rol del usuario.
• Actores. Usuario visitante con rol “owner”. • Antecedentes. Puede darse una de las siguientes situaciones.
o El usuario con rol “owner” está viendo la lista de objetos de la página principal.
32
o El usuario con rol “owner” está viendo la información completa de algún objeto.
• Descripción. El usuario con rol “owner” cree que un objeto del sistema es de su propiedad y quiere recuperarlo.
• Escenario principal de éxito. o El usuario con rol “owner” pulsa el botón Es mio. o Se accede al caso de uso Registrarse.
Segundo caso.
• Actores. Usuario visitante con rol “finder”. • Antecedentes. Puede darse una de las siguientes situaciones.
o El usuario con rol “finder” está viendo la lista de objetos de la página principal. o El usuario con rol “finder” está viendo la información completa de algún
objeto. • Descripción. El usuario con rol “finder” ha encontrado un objeto del sistema y quiere
devolverlo a su propietario. • Escenario principal de éxito.
o El usuario con rol “finder” pulsa sobre el botón Lo he encontrado. o Se accede al caso de uso Registrarse.
Intentar ver aportaciones de la comunidad
• Actores. Usuario visitante. • Antecedentes. El usuario está visualizando el anuncio en el que se muestra el resumen
de la información del último objeto devuelto a su propietario, ubicado en la página principal.
• Descripción. El usuario quiere ver otras historias similares. • Escenario principal de éxito.
o El usuario pulsa sobre el enlace Ver más historias como ésta. o Se accede al caso de uso Registrarse.
Registrarse
• Actores. Usuario visitante. • Antecedentes. El usuario ha pulsado sobre algún botón, enlace o sección sobre la que
no dispone privilegios. • Descripción. El usuario quiere registrarse en el sistema. • Escenario principal de éxito.
o El usuario pulsa sobre el enlace Crear una cuenta de la ventana que aparece o de la cabecera del sitio web.
o El sistema muestra el formulario de registro. o El usuario rellena el formulario y pulsa sobre botón registrar. o El sistema crea la cuenta y convierte al usuario en usuario de tipo registrado.
33
3.4.2 Casos de uso de usuario centro
Los usuarios que disponen de cuenta de usuario de tipo centro disponen de los casos de uso de un usuario de tipo visitante hasta que se identifican con los datos de su cuenta. A continuación se muestran los casos de uso de un usuario de tipo centro.
Diagrama 4, Casos de uso usuario centro
Identificarse
• Actores. Usuario centro. • Antecedentes. El usuario (todavía sin identificarse), ha pulsado sobre algún botón,
enlace o sección sobre la que no dispone privilegios. • Descripción. El usuario quiere identificarse como usuario registrado en el sistema,
para disponer de las funcionalidades de este tipo de usuario. • Escenario principal de éxito.
o El usuario pulsa sobre el enlace Identifícate de la ventana que aparece o de la cabecera del sitio web.
o El sistema muestra el formulario de identificación. o El usuario rellena el formulario y pulsa sobre botón entrar. o El sistema, tras validar los datos del formulario dota al usuario de los
privilegios de un usuario de tipo centro, que le permite acceder a los siguientes casos de uso.
34
Recuperar contraseña
• Actores. Usuario centro. • Antecedentes. El usuario (todavía sin identificarse), ha pulsado sobre algún botón,
enlace o sección sobre la que no dispone privilegios. • Descripción. El usuario ha olvidado los datos de su cuenta. • Escenario principal de éxito.
o El usuario pulsa sobre el enlace ¿Has olvidado la contraseña?. o El sistema muestra el formulario de recuperación de la contraseña. o El usuario rellena el formulario y pulsa sobre botón recuperar. o El sistema, tras validar los datos del formulario envía por correo electrónico
una nueva contraseña para que el usuario acceda a su cuenta.
Ver información de objetos
• Actores. Usuario centro. • Antecedentes. El usuario está visualizando el resumen de la información de un objeto
en la página principal, ha pulsado sobre una etiqueta de la nube de etiquetas o ha efectuado una búsqueda con el buscador.
• Descripción. El usuario quiere ver la información completa de alguno de los objetos que está visualizando.
• Escenario principal de éxito. o El usuario pulsa sobre el botón Entrar o sobre el enlace del nombre del objeto,
dependiendo de su ubicación. o El sistema muestra la información completa del objeto.
• Extensión 1. El objeto que se está mostrando es de tipo perdido y su estado es perdido.
o El sistema muestra el botón Lo he encontrado. o El usuario con rol “finder” pulsa sobre el botón Lo he encontrado. o Se accede al caso de uso Marcar objetos.
• Extensión 2. El objeto que se está mostrando es de tipo encontrado, su estado es perdido y el usuario que lo está visualizando es quién lo ha registrado.
o El sistema muestra el botón Cancelar búsqueda. o El usuario con rol “finder” pulsa sobre el botón Cancelar búsqueda. o Se accede al caso de uso Marcar objetos.
• Extensión 3. El objeto que se está mostrando es de tipo encontrado, su estado es pendiente y el usuario que lo está visualizando es quién lo ha registrado.
o El sistema muestra el botón Confirmar devolución y Descartar devolución. o El usuario con rol “finder” pulsa sobre alguno de dichos botones. o Se accede al caso de uso Confirmar o descartar devoluciones.
• Extensión 4. o El usuario pulsa sobre el botón Añadir comentario. o Se accede al caso de uso Ver y añadir comentarios.
• Extensión 5. El usuario que está visualizando la información del objeto es quién lo ha registrado.
35
o El sistema muestra el botón Borrar. o El usuario pulsa sobre el botón Borrar. o Se accede al caso de uso Borrar objetos.
• Extensión 6. El usuario que está visualizando la información del objeto es quién lo ha registrado.
o El sistema muestra el botón Editar. o El usuario pulsa sobre el botón Editar. o Se accede al caso de uso Ver y editar objetos personales.
• Extensión 7. o El usuario pulsa sobre el enlace del nombre del usuario que ha añadido el
objeto o sobre la fotografía o el enlace del nombre del usuario que ha añadido algún comentario.
o Se accede al caso de uso Ver información y estadísticas de usuarios. • Extensión 8. El usuario que está visualizando la información del objeto es quién lo ha
registrado. o El usuario pulsa sobre el enlace de su nombre o sobre la fotografía o el enlace
de su nombre de algún comentario añadido por él. o Se accede al caso de uso Ver y editar perfil personal.
Añadir objetos
• Actores. Usuario centro. • Descripción. El usuario quiere añadir un nuevo objeto de tipo encontrado. • Escenario principal de éxito.
o El usuario pulsa el botón Añadir objeto y sobre una de la opción Objeto encontrado.
o El sistema muestra el formulario correspondiente. o El usuario añade los datos necesarios. o El sistema valida que los datos sean correctos y registra el objeto.
Ver sección Comunidad
• Actores. Usuario centro. • Descripción. El usuario quiere ver la sección “Comunidad”. • Escenario principal de éxito.
o El usuario pulsa sobre la opción del menú principal Comunidad. o El sistema muestra el contenido de la sección “Comunidad”.
Ver último objeto devuelto
• Actores. Usuario centro. • Antecedentes. El usuario está visualizando la página principal. • Descripción. El usuario quiere ver el resumen de la información del último objeto
devuelto a su propietario. • Escenario principal de éxito.
36
o El sistema muestra un anuncio con el resumen de la información del último objeto devuelto a su propietario.
• Extensión 1. o El usuario pulsa sobre el enlace Ver más historias como ésta. o Se accede al caso de uso Ver aportaciones de la comunidad.
Marcar objetos
• Actores. Usuario centro con rol “finder”. • Antecedentes. Puede darse una de las siguientes situaciones.
o El usuario con rol “finder” está viendo la lista de objetos de la página principal. o El usuario con rol “finder” está viendo la información completa de algún
objeto. • Descripción. El usuario con rol “finder” dispone de un objeto del sistema en el centro
del que es responsable y quiere devolverlo a su propietario. • Escenario principal de éxito.
o El usuario con rol “finder” pulsa sobre el botón Lo he encontrado. o El sistema notifica al usuario que ha registrado el objeto con la dirección de
correo electrónico del usuario con rol “finder” y actualiza el estado del objeto a pendiente.
• Extensión 2. El usuario con rol “finder” a su vez es el usuario que ha registrado el objeto (encontrado) y ha pulsado el botón Cancelar búsqueda.
o El sistema cancela la búsqueda del objeto y éste pasa a estado devuelto.
Ver y añadir comentarios
• Actores. Usuario centro. • Antecedentes. El usuario está visualizando la información completa de cualquier
objeto. • Descripción. El usuario quiere ver o añadir comentarios. • Escenario principal de éxito.
o El sistema muestra los comentarios. o El usuario pulsa el botón Nuevo comentario. o El sistema muestra el formulario correspondiente. o El usuario rellena los datos requeridos y pulsa sobre el botón Publicar. o El sistema registra y muestra el comentario.
Borrar objetos
• Actores. Usuario centro. • Antecedentes. El usuario está visualizando la información completa de algún objeto
que él ha registrado. • Descripción. El usuario quiere borrar un objeto anteriormente registrado por él. • Escenario principal de éxito.
o El usuario identificado pulsa el botón Borrar. o El sistema borra definitivamente el objeto.
37
Ver y editar objetos personales
• Actores. Usuario centro. • Antecedentes. El usuario está visualizando la información completa de algún objeto
anteriormente registrado por él. • Descripción. El usuario quiere cambiar alguno de los datos del objeto que ha
registrado anteriormente. • Escenario principal de éxito.
o El usuario pulsa el botón Editar. o El sistema vuelve a mostrar el formulario que se rellenó anteriormente para
registrar el objeto con los valores actuales por defecto. o El usuario modifica los datos del objeto y pulsa el botón Publicar. o El sistema guarda la información del objeto actualizada.
Ver información y estadísticas de usuarios
• Actores. Usuario centro. • Antecedentes. Puede darse una de las siguientes situaciones.
o El usuario está viendo la lista de objetos de la página principal. o El usuario está viendo la información completa de algún objeto. o El usuario está viendo las aportaciones de la comunidad. o El usuario está viendo sus aportaciones personales. o El usuario está viendo el top 10. o El usuario ha recibido un correo electrónico que incluye un enlace a la
información de un usuario. • Descripción. El usuario quiere ver la información y estadísticas de algún usuario. • Escenario principal de éxito.
o El usuario pulsa sobre la fotografía o el enlace del nombre de algún usuario. o El sistema muestra la información pública y las estadísticas del usuario.
Ver y editar perfil personal
• Actores. Usuario centro. • Antecedentes. Puede darse una de las siguientes situaciones.
o El usuario ha accedido a la sección Comunidad. o El usuario está viendo la lista de objetos de la página principal y entre ellos hay
objetos añadidos por él. o El usuario está viendo la información completa de un objeto registrado por él
o que ha comentado o marcado. o El usuario está viendo las aportaciones de la comunidad. o El usuario está viendo sus aportaciones personales.
• Descripción. El usuario quiere ver o editar los datos de su cuenta. • Escenario principal de éxito.
o El usuario pulsa sobre la opción de menú Mi cuenta o pulsa sobre su nombre de usuario o foto en cualquiera de las ubicaciones antes mencionadas.
o El sistema muestra todos los datos de su cuenta y estadísticas.
38
• Extensión 1. El usuario está viendo los datos de su cuenta y estadísticas. o El usuario pulsa sobre el botón Editar. o El sistema muestra un formulario para editar, añadir o borrar datos de su
cuenta. Además de poder escoger la privacidad de alguno de los datos. o El sistema guarda los datos y preferencias del usuario.
Confirmar o descartar devoluciones
• Actores. Usuario centro con rol “finder”. • Antecedentes. El usuario con rol “finder” está viendo la información completa de un
objeto que ha sido depositado en el centro del que es responsable y ha registrado. Algún usuario con rol “owner” ha notificado (marcado) que el objeto es de su propiedad.
• Descripción. El usuario con rol “finder” se ha puesto en contacto con el usuario con rol “owner” y le ha devuelto el objeto.
• Escenario principal de éxito. o El usuario con rol “finder” ha devuelto el objeto, así que pulsa el botón
Confirmar. o El sistema cambia el estado del objeto a devuelto.
• Extensión 1. o El usuario con rol “finder” no ha devuelto el objeto, no ha conseguido ponerse
en contacto con el usuario con rol “owner” o simplemente no se trata realmente de su objeto, así que pulsa el botón Descartar.
o El sistema cambia el estado del objeto a perdido.
Ver aportaciones personales
• Actores. Usuario centro. • Antecedentes. El usuario ha accedido a la sección Comunidad. • Descripción. El usuario quiere ver sus aportaciones personales a la comunidad. • Escenario principal de éxito.
o El usuario pulsa la opción de menú Aportaciones personales. o El sistema muestra la interacción del usuario con el sistema u otros usuarios.
• Extensión 1. o El usuario pulsa sobre su foto o enlace de su nombre. o Se accede al caso de uso Ver y editar perfil personal.
• Extensión 2. o El usuario pulsa sobre la foto o enlace del nombre de algún otro usuario con el
que ha interactuado. o Se accede al caso de uso Ver información y estadísticas de usuarios.
• Extensión 3. o El usuario pulsa sobre el enlace del nombre de algún objeto registrado por él. o Se accede al caso de uso Ver y editar objetos personales.
• Extensión 4. o El usuario pulsa sobre el enlace del nombre de algún objeto con el que ha
interactuado, pero no ha sido registrado por él.
39
o Se accede al caso de uso Ver información de objetos.
Ver top 10
• Actores. Usuario centro. • Antecedentes. El usuario ha accedido a la sección Comunidad. • Descripción. El usuario quiere ver la lista de los diez usuarios que más objetos han
encontrado y devuelto a sus propietarios. • Escenario principal de éxito.
o El usuario pulsa la opción de menú Top 10. o El sistema muestra un resumen de la información de los diez usuarios que más
objetos han encontrado y devuelto a sus propietarios. • Extensión 1.
o El usuario pulsa sobre la fotografía o el enlace del nombre de algún usuario de la lista.
o Se accede al caso de uso Ver información y estadísticas de usuarios.
Ver aportaciones de la comunidad
• Actores. Usuario centro. • Antecedentes. El usuario ha accedido a la sección Comunidad. • Descripción. El usuario quiere ver las aportaciones de la comunidad. • Escenario principal de éxito.
o El usuario pulsa la opción de menú Aportaciones de la comunidad. o El sistema muestra la interacción de todos los usuarios del sistema con el
sistema u otros usuarios. • Extensión 1.
o El usuario pulsa sobre su foto o enlace de su nombre de algún elemento de la lista en la que aparece.
o Se accede al caso de uso Ver y editar perfil personal. • Extensión 2.
o El usuario pulsa sobre la foto o enlace del nombre de algún otro usuario de algún elemento de la lista.
o Se accede al caso de uso Ver información y estadísticas de usuarios. • Extensión 3.
o El usuario pulsa sobre el enlace del nombre de algún objeto registrado por él, de algún elemento de la lista.
o Se accede al caso de uso Ver y editar objetos personales. • Extensión 4.
o El usuario pulsa sobre el enlace del nombre de algún objeto registrado por otros usuarios, de algún elemento que aparece en la lista.
o Se accede al caso de uso Ver información de objetos.
40
3.4.3 Casos de uso de usuario registrado
Los usuarios de tipo registrado de la misma manera que un usuario de tipo centro, dispone de los casos de uso de un usuario de tipo visitante hasta que se identifica con los datos de su cuenta de usuario registrado. Los casos de uso de un usuario de tipo registrado son los mismos que los de un usuario de tipo centro, a excepción de dos casos de uso que disponen de más funcionalidades para los usuarios de tipo registrado.
Diagrama 5, Casos de uso usuario registrado
Marcar objetos
Además de los escenarios y extensiones expuestas anteriormente en este caso de uso para los usuarios de tipo centro, para los usuarios de tipo registrado se incluyen estas.
• Actores. Usuario registrado con rol “owner”. • Antecedentes. Puede darse una de las siguientes situaciones.
o El usuario con rol “owner” está viendo la lista de objetos de la página principal. o El usuario con rol “owner” está viendo la información completa de algún
objeto. • Descripción. El usuario con rol “owner” cree que un objeto del sistema es de su
propiedad y quiere recuperarlo. • Escenario principal de éxito.
o El usuario con rol “owner” pulsa el botón Es mio. o Si el objeto dispone de pregunta secreta, el sistema la muestra. o Si el objeto dispone de pregunta secreta, el usuario la responde. o El sistema notifica al usuario que ha registrado el objeto con la dirección de
correo electrónico del usuario con rol “owner” y actualiza el estado del objeto a pendiente.
• Extensión 1. El usuario con rol “owner” a su vez es el usuario que ha registrado el objeto (perdido) y ha pulsado el botón Cancelar búsqueda.
o El sistema cancela la búsqueda del objeto y éste pasa a estado devuelto.
Añadir objetos
La única diferencia entre el caso de uso para un centro y para un usuario registrado es que el usuario registrado puede seleccionar el tipo de objeto a registrar (perdido o encontrado).
41
Ver top 10
La única diferencia que el caso de uso para un centro y para un usuario registrado es que el usuario registrado puede acceder a la extensión 2.
• El usuario pulsa sobre su fotografía o el enlace a su nombre, si es que éste aparece. • Se accede al caso de uso Ver y editar perfil personal.
Confirmar o descartar devoluciones
Además de los escenarios y extensiones expuestas anteriormente en este caso de uso para los usuarios de tipo centro, para los usuarios de tipo registrado se incluyen estas.
• Actores. Usuario registrado con rol “owner”. • Antecedentes. El usuario con rol “owner” está viendo la información completa de
algún objeto que ha perdido y registrado. Algún usuario con rol “finder” ha notificado (marcado) que lo ha encontrado.
• Descripción. El usuario con rol “owner” se ha puesto en contacto con el usuario con rol “finder” y se le ha devuelto el objeto de su propiedad.
• Escenario principal de éxito. o El usuario con rol “owner” ha recuperado el objeto, así que pulsa el botón
Confirmar. o El sistema cambia el estado del objeto a devuelto.
• Extensión 1. o El usuario con rol “owner” no ha recuperado el objeto, no ha conseguido
ponerse en contacto con el usuario con rol “finder” o simplemente no se trata realmente de su objeto, así que pulsa el botón Descartar.
o El sistema cambia el estado el objeto a perdido.
42
3.4.4 Casos de uso de usuario administrador
Teniendo en cuenta que el sistema se ha desarrollado sobre un CMS, la mayoría de los casos de uso de un usuario administrador dependen de dicho CMS, por lo tanto a continuación se exponen solo algunos de los más imprescindibles. Estos casos de uso son accesibles desde la página de administración (“back-‐end”).
Diagrama 6, Casos de uso usuario administrador
Ver sección Contenido
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la página principal de la plataforma de
administración (“back-‐end”). • Descripción. El usuario quiere acceder a la sección Contenido. • Escenario principal de éxito.
o El usuario pulsa sobre la opción del menú principal, Contenido. o El sistema muestra una lista con sub-‐secciones que agrupan contenidos.
Ver sección Usuarios
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la página principal de la plataforma de
administración (“back-‐end”). • Descripción. El usuario quiere acceder a la sección Usuarios. • Escenario principal de éxito.
o El usuario pulsa sobre la opción del menú principal, Usuarios. o El sistema muestra una lista con sub-‐secciones que agrupan usuarios.
43
Limpiar cachés
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la página principal de la plataforma de
administración (“back-‐end”). • Descripción. El usuario quiere borrar algún tipo de contenido guardado en las
memorias caché. • Escenario principal de éxito.
o El usuario selecciona el tipo de contenido que desea eliminar y pulsa sobre el botón Borrar caché.
o El sistema elimina el tipo de contenido seleccionado de las memorias caché.
Actualizar sistema
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la página principal de la plataforma de
administración (“back-‐end”). • Descripción. Puesto que el sistema se va a desarrollar sobre un CMS, es posible que
con el tiempo sea necesario actualizarlo. • Escenario principal de éxito.
o El usuario pulsa sobre el botón Actualizar sistema. o El sistema actualiza el sistema.
Ver resumen de objetos
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la lista de sub-‐secciones de la sección
Contenido. • Descripción. El usuario quiere ver la lista con el resumen de los objetos añadidos en el
sistema. • Escenario principal de éxito.
o El usuario pulsa sobre la opción, Objetos. o El sistema muestra una lista con el resumen de los objetos añadidos en el
sistema. • Extensión 1.
o El usuario pulsa sobre el enlace del nombre del objeto. o Se accede al caso de uso Ver y editar objetos.
• Extensión 2. o El usuario pulsa sobre el botón de borrar. o Se accede al caso de uso Borrar objetos.
Ver resumen de otros contenidos
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la lista de sub-‐secciones de la sección
Contenido.
44
• Descripción. El usuario quiere ver la lista con el resumen de algún otro tipo de contenido.
• Escenario principal de éxito. o El usuario pulsa sobre la opción correspondiente al tipo de contenido que
quiere visualizar. o El sistema muestra una lista con el resumen de los contenidos
correspondientes a esa opción • Extensión 1.
o El usuario pulsa sobre el enlace del nombre del contenido. o Se accede al caso de uso Ver y editar otros contenidos.
• Extensión 2. o El usuario pulsa sobre el botón de borrar. o Se accede al caso de uso Borrar otros contenidos.
Ver resumen de personas
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la lista de sub-‐secciones de la sección
Personas. • Descripción. El usuario quiere ver la lista con el resumen de los usuarios de tipo
persona, registrados en el sistema. • Escenario principal de éxito.
o El usuario pulsa sobre la opción, Miembros. o El sistema muestra una lista con el resumen de los usuarios de tipo persona,
registrados en el sistema. • Extensión 1.
o El usuario pulsa sobre el enlace del nombre del usuario de tipo persona. o Se accede al caso de uso Ver y editar cuentas de personas.
• Extensión 2. o El usuario pulsa sobre el botón de borrar. o Se accede al caso de uso Borrar cuentas de personas.
Ver resumen de centros
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la lista de sub-‐secciones de la sección
Usuarios. • Descripción. El usuario quiere ver la lista con el resumen de los centros registrados en
el sistema. • Escenario principal de éxito.
o El usuario pulsa sobre la opción, Centros. o El sistema muestra una lista con el resumen de los centros registrados en el
sistema. • Extensión 1.
o El usuario pulsa sobre el enlace del nombre del centro. o Se accede al caso de uso Ver y editar centros.
45
• Extensión 2. o El usuario pulsa sobre el botón de borrar. o Se accede al caso de uso Borrar centros.
Administrar roles y permisos
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la lista de sub-‐secciones de la sección
Usuarios. • Descripción. El usuario quiere administrar roles y permisos de usuario. • Escenario principal de éxito.
o El usuario pulsa sobre la opción, Administrar roles y permisos. o El sistema muestra una lista con el resumen de los roles y sus respectivos
permisos.
Ver y editar objetos
• Actores. Usuario administrador. • Antecedentes. El usuario ha pulsado sobre el enlace del nombre de un objeto o sobre
el botón de editar. • Descripción. El usuario quiere ver la información de un objeto y/o editarla. • Escenario principal de éxito.
o El sistema muestra la información del objeto con campos editables. o El usuario visualiza la información del objeto y la modifica si lo desea. o El usuario pulsa sobre el botón de guardar. o El sistema almacena los cambios efectuados en el objeto.
• Extensión 1. o El usuario pulsa sobre el botón de cancelar. o El sistema cancela los cambios efectuados por el usuario en el objeto.
Ver y editar otros contenidos
• Actores. Usuario administrador. • Antecedentes. El usuario ha pulsado sobre el enlace del nombre de algún otro tipo de
contenido o sobre el botón de editar. • Descripción. El usuario quiere ver la información de algún otro tipo de contenido y/o
editarla. • Escenario principal de éxito.
o El sistema muestra la información del contenido con campos editables. o El usuario visualiza la información del contenido y la modifica si lo desea. o El usuario pulsa sobre el botón de guardar. o El sistema almacena los cambios efectuados en el contenido.
• Extensión 1. o El usuario pulsa sobre el botón de cancelar. o El sistema cancela los cambios efectuados por el usuario en el contenido.
46
Añadir otros contenidos
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la lista con el resumen de otros contenidos. • Descripción. El usuario quiere añadir algún otro tipo de contenido. • Escenario principal de éxito.
o El usuario escoge el tipo de contenido que desea crear y pulsa el botón de añadir.
o El sistema muestra un formulario con los campos a rellenar para crear el contenido.
o El usuario rellena el formulario y pulsa el botón de publicar. o El sistema crea el contenido y lo muestra el sitio web público (front-‐end).
• Extensión 1. o El usuario pulsa el botón de cancelar. o Se cancela la creación del nuevo contenido.
Añadir otros contenidos
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la lista con el resumen de los roles y
permisos. • Descripción. El usuario quiere añadir un nuevo rol o permiso. • Escenario principal de éxito.
o El usuario pulsa sobre el botón Añadir rol o Añadir permiso. o El sistema muestra un formulario con los campos a rellenar para crear el
nuevo rol o el nuevo permiso. o El usuario rellena el formulario y pulsa el botón de publicar. o El sistema crea el nuevo rol o permiso.
• Extensión 1. o El usuario pulsa el botón de cancelar. o Se cancela la creación del nuevo rol o permiso.
Ver y editar cuentas de personas
• Actores. Usuario administrador. • Antecedentes. El usuario ha pulsado sobre el enlace del nombre de un usuario de tipo
persona o sobre el botón de editar. • Descripción. El usuario quiere ver la información de un usuario de tipo persona y/o
editarla. • Escenario principal de éxito.
o El sistema muestra la información del usuario de tipo persona con campos editables.
o El usuario visualiza la información del usuario de tipo persona y la modifica si lo desea.
o El usuario pulsa sobre el botón de guardar. o El sistema almacena los cambios efectuados en el usuario de tipo persona.
47
• Extensión 1. o El usuario pulsa sobre el botón de cancelar. o El sistema cancela los cambios efectuados por el usuario en el usuario de tipo
persona.
Ver y editar cuentas centros
• Actores. Usuario administrador. • Antecedentes. El usuario ha pulsado sobre el enlace del nombre de un centro o sobre
el botón de editar. • Descripción. El usuario quiere ver la información de un usuario de tipo centro y/o
editarla. • Escenario principal de éxito.
o El sistema muestra la información del centro con campos editables. o El usuario visualiza la información del centro y la modifica si lo desea. o El usuario pulsa sobre el botón de guardar. o El sistema almacena los cambios efectuados en el centro.
• Extensión 1. o El usuario pulsa sobre el botón de cancelar. o El sistema cancela los cambios efectuados por el usuario en el centro.
Ver y editar roles y permisos
• Actores. Usuario administrador. • Antecedentes. El usuario ha pulsado sobre el enlace del nombre de un rol o permiso
de tipo o sobre el botón de editar. • Descripción. El usuario quiere ver la información de un rol o permiso y/o editarla. • Escenario principal de éxito.
o El sistema muestra la información del rol o permiso con campos editables. o El usuario visualiza la información del rol o permiso y lo edita. o El usuario pulsa sobre el botón de guardar. o El sistema almacena los cambios efectuados en el rol o permiso.
• Extensión 1. o El usuario pulsa sobre el botón de cancelar. o El sistema cancela los cambios efectuados en el rol o permiso.
Borrar objetos
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la lista con el resumen de los objetos
añadidos en el sistema. • Descripción. El usuario quiere borrar un objeto. • Escenario principal de éxito.
o El usuario pulsa el botón de borrar de alguno de los objetos. o El sistema elimina el objeto.
48
Borrar otros contenidos
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la lista con el resumen de algún otro tipo
de contenido. • Descripción. El usuario quiere borrar algún otro tipo de contenido. • Escenario principal de éxito.
o El usuario pulsa el botón de borrar de alguno de los contenidos. o El sistema elimina el contenido.
Borrar cuentas de personas
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la lista con el resumen de los usuarios de
tipo persona, registrados en el sistema. • Descripción. El usuario quiere borrar la cuenta de un usuario de tipo persona. • Escenario principal de éxito.
o El usuario pulsa el botón de borrar de alguno de los usuarios de tipo persona. o El sistema elimina el usuario de tipo persona.
Borrar cuentas de centros
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la lista con el resumen de las cuentas de los
usuarios de tipo centro, registrados en el sistema. • Descripción. El usuario quiere borrar la cuenta de un centro. • Escenario principal de éxito.
o El usuario pulsa el botón de borrar de la cuenta de alguno de los centros. o El sistema elimina la cuenta del centro.
Borrar roles o permisos
• Actores. Usuario administrador. • Antecedentes. El usuario está visualizando la lista con el resumen de los roles y
permisos. • Descripción. El usuario quiere borrar un rol o un permiso. • Escenario principal de éxito.
o El usuario pulsa el botón de borrar de alguno de los roles o permisos. o El sistema elimina el rol o el permiso.
Para poder entender de manera más clara los procesos que provocan algunos casos de uso, se han utilizado diagramas de secuencia.
49
3.5 Diagramas de secuencia
En esta sección se muestran diagramas de secuencia de los diferentes procesos que se desarrollan en los casos de uso genéricos “Marcar objetos” y “Confirmar o descartar devoluciones”.
3.5.1 Secuencia marcar objeto “lo he encontrado”
La situación que se muestra en el siguiente diagrama de secuencia describe como un usuario con rol “finder” encuentra algún objeto registrado en el sistema como perdido, por un usuario con rol “owner”. El usuario con rol “finder” quiere devolver el objeto a su propietario y pulsa el botón “Lo he encontrado”.
Diagrama 7, Secuencia marcar objeto “lo he encontrado”
3.5.2 Secuencia confirmar devolución de objeto perdido
El siguiente diagrama de secuencia muestra el proceso que se desarrolla una vez el usuario con rol “owner” recibe un mensaje de correo electrónico, informándole que un usuario con rol “finder” ha encontrado su objeto perdido registrado. En este momento se supone que el usuario con rol “owner”, que ha recibido el correo electrónico, se ha puesto en contacto con el usuario con rol “finder” y éste le ha devuelto el objeto, por lo tanto, el usuario con rol “finder” quiere confirmar la devolución.
Diagrama 8, Secuencia confirmar devolución de objeto perdido
50
3.5.3 Secuencia descartar devolución de objeto perdido
El diagrama que se muestra a continuación representa la alternativa a la secuencia anterior. Por alguna razón, el usuario con rol “owner” que ha recibido el mensaje de correo electrónico, ha decidido descartar la devolución del objeto.
Diagrama 9, Secuencia descartar devolución de objeto perdido
3.5.4 Secuencia marcar objeto “Es mio”
A continuación se muestra el diagrama de secuencia que representa el proceso que se lleva a cabo cuando un usuario con rol “owner”, que ha perdido un objeto, cree que algún objeto encontrado registrado en el sistema, es de su propiedad. El usuario con rol “owner” quiere recuperar su objeto y pulsa el botón “Es mio”.
Diagrama 10, Secuencia marcar objeto "Es mio"
51
3.5.5 Secuencia confirmar devolución de objeto encontrado
El siguiente diagrama representa el proceso que se lleva a cabo cuando un usuario con rol “finder”, que ha registrado un objeto encontrado, recibe un mensaje de correo electrónico, informándole que hay un posible propietario para uno de los objetos que ha registrado. Se supone que el usuario con rol “finder”, que ha recibido el correo electrónico, se ha puesto en contacto con el usuario con rol “owner” y le ha devuelto el objeto de su propiedad.
Diagrama 11, Secuencia confirmar devolución objeto encontrado
3.5.6 Secuencia descartar devolución de objeto perdido
Por último, el diagrama que se muestra a continuación representa la alternativa a la secuencia expuesta anteriormente. Por alguna razón, el usuario con rol “finder”, que ha recibido el correo electrónico, ha decidido descartar la devolución del objeto al usuario con rol “owner”.
Diagrama 12, Secuencia descartar devolución de objeto perdido
Ahora que ya se han expuesto los diferentes casos de uso, los tipos de objetos, los ciclos de vida de los objetos, secuencias, etc., se exponen, utilizando diagramas de flujo, cómo los tres roles de usuario interactúan con el sistema.
52
3.6 Flujo de objeto perdido
El diagrama de flujo que se muestra a continuación pretende mostrar el ciclo de vida de un objeto perdido. Desde que un usuario con rol “owner” lo pierde y registra en el sistema, hasta que un usuario con rol “finder” lo encuentra y se lo devuelve.
Diagrama 13, Flujo de objeto perdido
53
3.7 Flujo de objeto encontrado
El diagrama de flujo que se muestra a continuación pretende mostrar el ciclo de vida de un objeto encontrado. Desde que un usuario con rol “finder” lo encuentra y lo registra o desde que es depositado en un centro cuyo representante con rol “finder” lo registra, hasta que un usuario con rol “owner” lo reconoce se le devuelve.
Diagrama 14, Flujo de objeto encontrado
54
Una vez definidos los elementos que forman el sistema del sitio web, objetos perdidos, usuarios, etc., es el momento de exponer de manera más concreta la forma de estos objetos y cómo interactúan entre sí.
3.8 Clases
El siguiente diagrama de clases muestra la estructura de cada uno de los objetos que forman el sistema.
3.8.1 Category
• Descripción. Representa cada una de las categorías en las que se agrupan los objetos. • Atributos.
o id. Valor entero que identifica la categoría en el sistema. o name. Nombre de la categoría. Identifica la categoría en el sitio web. o description. Descripción de la categoría o ejemplos de tipos de objeto que
puede agrupar. o image. Imagen que representa la categoría. Identifica la categoría en el sitio
web de manera visual. • Asociaciones.
o Grouped – Object. Una categoría puede agrupar diversos objetos.
3.8.2 LostStatus
• Descripción. Representa cada uno de los estados que puede poseer un objeto perdido. • Atributos.
o id. Valor entero que identifica el estado en el sistema. o name. Nombre del estado. Identifica el estado en el sistema. o message. Mensaje que se muestra en el sitio web para representar el estado.
Identifica el estado en el sitio web. o image. Imagen que representa el estado. Identifica el estado en el sitio web de
manera visual. • Asociaciones.
55
o Has – Lost. En un estado de objeto extraviado pueden encontrarse diversos objetos extraviados.
3.8.3 FoundStatus
Esta clase, de la misma manera que la “LostStatus”, representa cada uno de los estados que puede poseer un objeto encontrado.
3.8.4 User
• Descripción. Representa cada uno de los usuarios que interactúan en el sistema. • Asociaciones.
o View -‐ Object. Un usuario puede ver parte de la información de cualquier objeto.
3.8.5 Anonymous
• Descripción. Representa cada uno de los usuarios de tipo visitante que interactúan en el sistema. La clase hereda de User.
3.8.6 Member
• Descripción. Representa cada uno de los usuarios de tipo registrado que interactúan en el sistema. La clase hereda de User.
• Atributos. o id. Valor entero que identifica el usuario en el sistema. o username. Nombre que identifica al usuario en el sitio web. o password. Contraseña para validar la cuenta de usuario. o email. Dirección de correo electrónico del usuario. o public_email. Campo booleano que indica si el usuario ha decidido que su
dirección de correo electrónico se muestre al resto de usuarios. o photografy. Fotografía del usuario. Identifica al usuario en el sitio web de
manera visual. o address. Dirección postal de la ubicación o residencia del usuario. o public_address. Campo booleano que indica si el usuario ha decidido que su
dirección postal se muestre al resto de usuarios. o objects_returned. Campo entero que acumula el número de objetos que el
usuario ha encontrado y devuelto a su propietario. • Asociaciones.
o Comment -‐ Object. Un usuario registrado puede añadir comentarios en cualquier objeto.
o Add -‐ Object. Un usuario registrado puede añadir diversos objetos. o Is owner – Found. Un usuario registrado puede ser propietario de cualquier
objeto de tipo encontrado. o Find – Lost. Un usuario registrado puede encontrar cualquier objeto de tipo
extraviado.
56
3.8.7 Person
• Descripción. Representa cada uno de los usuarios de tipo registrado, tras los cuales hay una persona física.
• Atributos. o id. Valor entero que identifica la persona en el sistema. o firstname. Nombre de pila de la persona. o lastname. Apellido de la persona. o public_name. Campo booleano que indica si la persona ha decidido que su
nombre y apellido se muestre al resto de usuarios. o birth. Fecha de nacimiento de la persona. o public_birth. Campo booleano que indica si el usuario ha decidido que su
fecha de nacimiento se muestre al resto de usuarios.
3.8.8 Center
• Descripción. Representa cada uno de los usuarios de tipo registrado, tras los cuales hay un centro.
• Atributos. o id. Valor entero que identifica el centro en el sistema. o center_name. Nombre del centro. Identifica el centro en el sitio web. o responsible_firstname. Nombre de pila de la persona responsable del centro. o responsable_lastname. Apellido de la persona responsable del centro. o information. Información del centro. Da más datos sobre la labor del centro. o url. Dirección del sitio web del centro. o telephone. Número de teléfono de contacto con el centro. o public_telephone. Campo booleano que indica si el responsable ha decidido
que el número de teléfono del centro se muestre al resto de usuarios.
3.8.9 Object
• Descripción. Representa cada uno de los objetos añadidos en el sistema. • Atributos.
o id. Valor entero que identifica el objeto en el sistema. o name. Nombre del objeto. Identifica el objeto en el sitio web. o description. Descripción u otros comentarios relacionados con el objeto. o address. Dirección postal aproximada en la que se ha extraviado o encontrado
el objeto. o date. Fecha aproximada en la que se ha extraviado o encontrado el objeto. o photografy. Fotografía del objeto. Identifica el objeto en el sitio web de
manera visual. o tags. Conjunto de etiquetas que identifican el objeto en el sitio web.
• Asociaciones. o Grouped – Category. Diferentes objetos pueden agruparse en una misma
categoría.
57
3.8.10 Lost
• Descripción. Representa cada uno de los objetos extraviados añadidos en el sistema. La clase hereda de Object.
• Atributos. o id. Valor entero que identifica el objeto extraviado en el sistema. o reward. Valor decimal que representa la recompensa que el usuario que ha
añadido el objeto ofrece al usuario que lo encuentre. o temp_finder. Valor entero que identifica el usuario que posiblemente ha
encontrado el objeto. o finder. Valor entero que identifica el usuario que ha encontrado el objeto.
• Asociaciones. o Has -‐ LostStatus. Un objeto extraviado, en un mismo instante, solo puede
tener un estado de objeto extraviado. o Finder – Member. Un objeto extraviado, solo puede ser encontrado por un
usuario registrado.
3.8.11 Found
• Descripción. Representa cada uno de los objetos encontrados añadidos en el sistema. La clase hereda de Object.
• Atributos. o id. Valor entero que identifica el objeto encontrado en el sistema. o question. Pregunta secreta que el usuario con rol “owner” deberá responder
en el momento que indique que el objeto es de su propiedad. o temp_owner. Valor entero que identifica el usuario que posiblemente es el
propietario del objeto. o owner. Valor entero que identifica el usuario propietario del objeto.
• Asociaciones. o Is in – Location. Un objeto encontrado, solo puede estar en un lugar. o Has -‐ FoundStatus. Un objeto encontrado, en un mismo instante, solo puede
tener un estado de objeto encontrado. o Owner – Member. Un objeto encontrado, solo puede ser propiedad de un
usuario registrado.
Llegados a este punto se ha definido cada uno de los elementos que componen el sistema eZ Publish, desde nivel significado a nivel representación. Se han concreado cada uno de los tipos de usuario que van a interactuar con el sistema, cómo lo van a hacer y que roles poseerán. Se han expuesto los procesos y la utilización que se le dará al sistema. Es el momento de pasar a un nivel más superficial y cercano al usuario.
58
3.9 Diseño de la interfaz
En esta sección se concreta la ubicación de los diferentes elementos que componen el sitio web, para ello se utilizan plantillas o modelos que esquematizan cada una de las pantallas.
3.9.1 Pantalla principal
Plantilla 1, Página principal
Como puede verse en la plantilla anterior, la página principal se compone de dos zonas, además de la cabecera y el menú principal.
Cabecera
La cabecera está compuesta por el título o logo del sitio web a la izquierda y un conjunto de enlaces en la parte derecha. Estos enlaces son los siguientes.
59
• Identifícate. Se muestra al usuario un formulario para que pueda identificarse como usuario registrado.
• Regístrate. Se muestra al usuario un explicación sobre los tipos de cuenta que puede crear (persona o centro) y dos enlaces a las respectivas opciones. Cuando el usuario pulsa sobre una de las dos opciones, accede a la sección Crear cuenta, expuesta a continuación.
• Idiomas. Se muestran todos los idiomas en los que se encuentra disponible el sitio web. Se ha decidido que por el momento sean español ya que es el idioma principal y catalán ya que el sitio web se centra en usuarios que residen en Barcelona y alrededores. Al pulsar sobre un idioma se accederá al sitio web en el idioma seleccionado.
Menú principal
En el menú principal se muestran las siguientes opciones.
• BCN y alrededores. Además del logo o título de la cabecera del sitio web, no está de más añadir una opción en el menú que además de redirigir a la página principal informe al usuario sobre qué contenido está visualizando. En este caso por defecto el usuario está viendo los objetos que los usuarios han registrado en el sistema y todavía no han sido devueltos a sus propietarios. Una muy probable futura extensión del proyecto, sea la de extender el sistema a otras ciudades, esta es otra razón por la que se ha seleccionado este nombre.
• Comunidad. Como se ha comentado anteriormente, esta sección solo estará disponible para usuarios con cuenta que estén identificados. A pesar de ello se ha decidido que esta opción sea siempre visible en el menú principal, para que los usuarios anónimos sepan de su existencia. Lógicamente cuando un usuario no identificado pulse sobre ella, se le notificará que primero debe crear una cuenta de usuario o identificarse si ya la posee.
• Añadir objeto. De la misma manera que la sección comunidad se ha decidido que los enlaces a los formularios para añadir objetos sean siempre visibles para todos los tipos de usuario. Evidentemente cuando un usuario anónimo pulse sobre cualquiera de las opciones del sub-‐menú de añadir objeto, se le informará que primero debe identificarse como usuario registrado. Se ha creído conveniente que este botón con opciones desplegables sea lo más llamativo posible, ya que al fin y al cabo será la funcionalidad utilizada más frecuentemente. Inicialmente se decidió utilizar una opción que re-‐direccionará a una sección donde se expusieran al usuario los tipos de objetos que podía registrar, acompañados de dos enlaces a los respectivos formularios. Definitivamente esta idea no era lo suficiente usable, ya que es imprescindible que el usuario pueda acceder al formulario para añadir objetos de la forma más rápida posible.
• Buscador. A pesar de que el buscador no sea una opción del menú principal se ha escogido esta ubicación. Por espacio, diseño y usabilidad. Esta funcionalidad, como se ha comentado anteriormente, permite al usuario buscar objetos registrados en el
60
sistema, por nombre, descripción u otras cadenas de caracteres que se incluyan en su información.
Área central
Como ya se intuye, el área principal muestra una lista con el resumen de la información de los objetos registrados en el sistema que todavía no han sido devueltos a sus propietarios. En la parte superior de esta lista se muestran tres opciones que permiten concretar los tipos de objetos a mostrar.
• Objetos para localizar. Cuando el usuario selecciona esta opción, se muestran solo los objetos que sus propietarios han perdido y registrado. (Objetos de tipo perdido)
• Objetos para devolver. Cuando el usuario selecciona esta opción, se muestran solo los objetos que usuarios han encontrado y quieren devolver a sus propietarios. (Objetos de tipo encontrado).
• Objetos bajo custodia. El usuario podrá seleccionar cualquier centro registrado en el sitio web, del selector y automáticamente se mostrarán solo los objetos ubicados en el centro seleccionado. Cuando se seleccione está opción las otras dos opciones desaparecerán, ya que un centro no puede registrar objetos que ha perdido y el hecho de mostrar estas opciones podrían confundir al usuario. Para volver a ver los objetos registrados por todos los tipos de usuario, simplemente se tendrá que pulsar sobre la opción “BCN y alrededores”.
Ha sido una tarea laboriosa escoger el nombre de estas opciones, ya que parecía que cualquier opción era confusa para el usuario. Han sido valoradas diversas alternativas y al final se ha recurrido a hacer una encuesta a usuarios reales y la opción escogida ha sido la que se muestra en la plantilla y en el sitio.
En una versión anterior del sitio web, se había ubicado el selector de centros en el menú principal, pero se llegó a la conclusión que su tamaño quitaba protagonismo a otras opciones. La ubicación actual, da protagonismo a la funcionalidad de buscar objetos depositados en centros, pero no lo quita a otras más importantes.
Como puede verse en la parte posterior de la lista de objetos hay un mapa. Esta funcionalidad permite al usuario visualizar de manera rápida la ubicación de los objetos que se están mostrando actualmente en la lista. La lista de objetos puedes ser larga y hacer interminable la página principal, por ese motivo se ha decidido incluir un “paginador”, de esta manera se pueden dividir los objetos a mostrar en grupos de cinco y avanzar o retroceder de página. Los objetos mostrados en el mapa también varían dependiendo de la página seleccionada. A pesar de haberse tomado esta medida, la inclusión del mapa en la página principal hacía que ésta fuera demasiado larga. Esto provoca que el usuario tenga que desplazarse demasiado horizontalmente para ver todo el contenido. Para solucionar este problema sin excluir ninguna funcionalidad, se ha decidido esconder la información de los objetos. Por defecto se mostrará la cabecera del objeto con el nombre y el estado en el que se encuentra, pero al pulsar sobre cualquiera de ellos se desplegará el resto de la información.
61
Área derecha
En el área derecha del sitio web se mostrará la lista de categorías de objeto. Cuando el usuario pulse sobre cualquiera de estas categorías se mostrará en la lista de objetos del área centra, los objetos del tipo y categoría seleccionada. Este filtro también estará disponible para los objetos registrados por un centro.
Justo después de la lista de categorías se ubica la nube de etiquetas. Esta nueve de etiquetas muestra las etiquetas más utilizadas por los usuarios al registrar los objetos. Como ya se ha comentado anteriormente y como se mostrará más adelante en los formularios para añadir objetos, se permite a los usuarios introducir etiquetas que identifiquen los objetos en el sistema.
Esta área además de estos bloques, puede incluir otros que vayan apareciendo durante el desarrollo del sitio web.
3.9.2 Crear cuenta
Cuando un usuario de tipo visitante pulsa sobre cualquiera de los enlaces crear cuenta del sitio web, se muestra una sección donde se explica la diferencia entre registrar un usuario y un centro y se le hace escoger. Una vez el usuario pulsa la opción de registro que desea se le muestran los siguientes formularios.
Crear cuenta de usuario persona
Plantilla 2, Crear cuenta de usuario persona
62
Para crear una cuenta de usuario se requieren estos datos:
• Nombre de pila del usuario que va a crear la cuenta. • Apellido del usuario que va a crear la cuenta. • Nombre de usuario que le identifica en el sistema y se muestra públicamente en el
sitio web. Se le pide en el formulario de identificación. • Contraseña para validar la cuenta de usuario. Se le pide en el formulario de
identificación. • Confirmar la contraseña. Se utiliza para comprobar que el usuario no ha errado al
escribir la contraseña escogida y para evitar registros automáticos. • Correo electrónico personal del usuario. También será único en el sistema. Se utiliza
para ponerse en contacto con el usuario si fuera necesario. • Por último el usuario deberá leer y aceptar las condiciones de uso del sitio web. Para
ello se añadirá un enlace para acceder al documento.
Crear cuenta de usuario centro
Plantilla 3, Crear cuenta de usuario centro
Para crear una cuenta de usuario para representar a un centro se requieren estos datos:
• Nombre del centro para el que se va a crear la cuenta. • Nombre del responsable que va a registrar el centro. • Apellido del responsable que va a registrar el centro. • Nombre de usuario que identifica el centro en el sistema y se muestra públicamente
en el sitio web. Se le pide al responsable en el formulario de identificación.
63
• Contraseña para validar la cuenta del centro. Se le pide al responsable en el formulario de identificación.
• Confirmar la contraseña. Se utiliza para comprobar que el responsable no ha errado al escribir la contraseña escogida y para evitar registros automáticos.
• Correo electrónico del centro. También será único en el sistema. Se utiliza para ponerse en contacto con el responsable o responsables del centro, si fuera necesario.
• Por último el responsable deberá leer y aceptar las condiciones de uso del sitio web. Para ello se añadirá un enlace para acceder al documento.
64
3.9.3 Añadir objeto perdido
Plantilla 4, Añadir objeto perdido
Si el usuario pierde un objeto y no lo encuentra entre los registrados en el sistema, es lógico pensar que querrá añadirlo. Para ello pulsará sobre la opción Añadir objeto y después sobre la
65
sub-‐opción Objeto perdido. Si el usuario es de tipo registrado se le mostrará el formulario representado por esta plantilla. Para añadir un objeto perdido se requerirán los siguientes datos:
• Como ya se ha comentado en puntos anteriores los objetos se agruparán por categorías para facilitar su búsqueda.
• El nombre del objeto lo identificará en el sistema. • Opcionalmente el usuario podrá añadir una descripción del objeto o cualquier otro
comentario que crea conveniente. • El usuario tendrá que introducir la dirección postal aproximada donde cree que perdió
el objeto. Teniendo en cuenta que probablemente un usuario no recuerde la dirección postal exacta donde perdió un objeto, se le facilita un mapa.
• Por la razón antes mencionada se dará la opción al usuario de introducir una descripción del lugar donde ha perdido el objeto.
• Debe introducir la fecha aproximada en la que cree que ha perdido el objeto, para ello se le facilita un calendario.
• Opcionalmente podrá añadir una fotografía del objeto. • El usuario podrá ofrecer una recompensa al usuario que encuentre su objeto. • Por último el usuario podrá introducir una o varias etiquetas separadas por comas que
identifiquen su objeto en el sistema.
66
3.9.4 Añadir objeto encontrado
67
Plantilla 5, Añadir objeto encontrado
Si el usuario se encuentra un objeto y quiere devolverlo a su propietario, pero no lo encuentra entre los registrados en el sistema, es lógico pensar que querrá añadirlo. Para ello pulsará sobre la opción Añadir objeto y después sobre la sub-‐opción Objeto encontrado. Si el usuario es de tipo registrado se le mostrará el formulario representado por esta plantilla. Para añadir un objeto encontrado se requerirán los siguientes datos:
• Como ya se ha comentado en puntos anteriores los objetos se agruparán por categorías para facilitar su búsqueda.
• El nombre del objeto lo identificará en el sistema. • Opcionalmente el usuario podrá añadir una descripción del objeto o cualquier otro
comentario que crea conveniente. • El usuario tiene que introducir la dirección postal aproximada donde se ha encontrado
el objeto. Teniendo en cuenta que probablemente un usuario no recuerde la dirección postal exacta donde ha encontrado un objeto, se le facilita un mapa.
• Por la razón antes mencionada se dará la opción al usuario de introducir una descripción del lugar donde ha encontrado el objeto.
• Debe introducir la fecha aproximada en la que ha encontrado el objeto, para ello se le facilita un calendario.
• Opcionalmente podrá añadir una fotografía del objeto. • El usuario deberá seleccionar donde se encuentra el objeto actualmente, de una lista
de opciones. Por ejemplo, el usuario ha depositado el objeto en una oficina de objetos perdidos o lo ha entregado a la policía o simplemente lo está guardando él.
• Como ya se ha comentado en el proceso de devolución de un objeto, una vez el usuario haya publicado el objeto recibirá un mensaje de correo electrónico en el momento que el usuario con rol “owner” pulse sobre el botón Es mío del objeto. Para que el usuario pueda ahorrarse comunicarse con el propietario vía correo electrónico para asegurarse que el objeto es suyo realmente, puede introducir una pregunta secreta que solo el verdadero propietario podrá responder. El usuario recibirá en el mensaje la respuesta a la pregunta y así podrá descartar la devolución directamente si fuera necesario.
• Por último el usuario podrá introducir una o varias etiquetas separadas por comas que identifiquen su objeto en el sistema.
68
3.9.5 Información completa del objeto
Plantilla 6, Información completa del objeto
Cuando un usuario de tipo registrado pulse sobre el título o la foto de un objeto de la lista de la página principal, accederá la información completa de éste. En esta plantilla se expone como se mostrará la información del objeto.
En la parte superior se mostrará el título del objeto, el tipo del objeto (extraviado o encontrado) y si se trata de un objeto que ha añadido el usuario que lo está viendo, se mostrará un botón para editar la información del objeto.
69
A continuación se mostrará la categoría a la que pertenece el objeto, acompañada del logo que representa la categoría. En el extremo derecho se mostrará el nombre del usuario que ha registrado el objeto, este nombre será un enlace a la información completa del usuario. También se mostrará una fotografía del usuario.
Como se puede ver en la plantilla se mostrará el mapa con la dirección postal donde se ha perdido o encontrado el objeto, su fotografía y una tabla con el resto de datos. Las filas de la tabla que aparecen en rojo simbolizan datos que dependerán del tipo el objeto, por supuesto si el objeto es de tipo perdido se mostrará la recompensa, si por el contrario es encontrado, se mostrará la localización actual y la pregunta secreta si la tuviera.
Debajo de los datos del objeto aparecerá el botón Lo he encontrado o Es mío, dependiendo del tipo de objeto. La funcionalidad de este botón es la misma que la mencionada en la lista de objetos de la página principal.
Por último, en la parte inferior de la sección se mostrará una lista de comentarios que los usuarios han hecho, además de un botón que posibilitará añadir nuevos.
70
3.9.6 Comunidad
Plantilla 7, Comunidad
Como ya se ha comentado anteriormente, solo los usuarios de tipo registrado podrán ver la opción Comunidad en el menú y por supuesto acceder a la sección.
Esta sección servirá para que el usuario pueda ver un resumen de todo lo que ha ocurrido en el sitio web. Se ha escogido el nombre Comunidad para que el usuario sienta que en el momento de crearse una cuenta pasa a formar parte de una comunidad y no solo de un sitio web corriente.
En la sección se divide en dos zonas. La zona primaria se sitúa a la derecha y es donde se muestre el contenido más importante. La zona secundaria se sitúa a la izquierda y muestra sub-‐secciones y otro contenido menos importante.
En la parte superior de la zona derecha se muestra un resumen de los datos personales del usuario que está en este momento haciendo uso del sitio. Solo se muestran el nombre de usuario, su nombre y apellidos, la dirección de correo electrónico y su fotografía.
71
El siguiente bloque de la zona de la derecha muestra una pequeña lista con las cinco últimas aportaciones que el usuario ha hecho en el sitio. Concretamente mostrará si se ha añadido algún objeto, si se ha comentado algún o si ha devuelto o le han devuelto algún objeto. Cada una de estas aportaciones contendrá un enlace al objeto que se está tratando y si hay implicado algún otro usuario también habrá un enlace a sus datos.
El último bloque de la zona derecha muestra una lista de las últimas diez aportaciones de todos los usuarios del sistema. Las aportaciones seguirán el mismo criterio que las aportaciones personales.
Por supuesto, cada bloque tiene un enlace que re-‐direcciona a la sub-‐sección correspondiente donde se muestra la información completa correspondiente a la sección. La sección Mis aportaciones muestra todas las aportaciones personales del usuario y la sección Aportaciones de la comunidad muestra todas las aportaciones de todos los usuarios del sistema. Por supuesto cada una de estas secciones dispone de un “paginador” que ordenará las aportaciones según la fecha en la que se han efectuado.
Como ya se ha comentado, el primer bloque de la zona de la izquierda muestra los enlaces a las sub-‐secciones.
A continuación se mostrará un anuncio agradeciendo la colaboración al último usuario que ha devuelto algún objeto. Evidentemente contendrá enlaces a la información del usuario y al objeto devuelto. Este bloque es importante para que los usuarios que consiguen encontrar y devolver objetos a sus propietarios, sientan que realmente se valora su colaboración. Además puede generar motivación a otros usuarios.
Por último se muestra otra nube de etiquetas como la de la página principal.
72
3.9.7 Mi cuenta
Plantilla 8, Mi cuenta
Como se ha expuesto en la sección anterior, cuando un usuario pulsa sobre el enlace Ver todo del bloque de los datos del usuario o sobre la opción Mi cuenta del sub-‐menú, accederá a la información personal completa del usuario. Esta plantilla representa como se muestran los datos de la cuenta del usuario o centro. Cuando un usuario acceda a la información completa de otro usuario, los datos se mostrarán de la misma manera con la diferencia que los datos que el usuario haya seleccionado como privados, no se mostrarán.
Para editar los datos de la cuenta o para escoger que campos serán públicos para el resto de usuarios, se debe pulsar sobre el botón Editar de la parte superior de la sección. El usuario podrá añadir nuevos datos que no se pidieron en el formulario de registro.
73
• Fecha de nacimiento. El usuario podrá escoger si se muestra al resto de usuarios. • Dirección postal. El usuario podrá añadir la dirección postal de su residencia y escoger
si se muestra al resto de usuarios.
Si se trata de un centro, también se podrán añadir nuevos datos personales.
• Dirección postal. El responsable podrá añadir la dirección postal del centro registrado y escoger si muestra al resto de usuarios.
• El responsable podrá añadir una descripción del centro registrado, qué tipo de centro es, a qué se dedica, si es público o privado, etc.
• Se puede añadir la dirección del sitio web del centro. • También se permite añadir un número de teléfono de contacto con el centro y
escoger si el resto de usuarios lo podrán ver. De esta manera se facilita que cualquier usuario se pueda poner en contacto con el centro.
Justo debajo de la información del usuario o centro, se muestran las estadísticas de objetos añadidos y devueltos por el usuario. Como se puede ver en el modelo se muestran dos tablas. Una corresponde a los objetos añadidos por el usuario diferenciados entre objetos que ha extraviado o se ha encontrado y sobre esa cantidad cuantos ha devuelto o le han devuelto. La segunda tabla corresponde a los objetos añadidos por otro usuario que han sido devueltos al usuario o ha devuelto a su propietario.
74
3.9.8 Top 10
Plantilla 9, Top 10
Este modelo representa la sección Top 10. En esta sección se muestran los diez usuarios que más objetos han encontrado y devuelto a sus propietarios. Para que la página no sea demasiado larga y el usuario no tenga que hacer uso excesivo de la barra lateral para desplazarse, se muestra la información en pequeñas barras verticales, exceptuando las tres primeras que serán un poco más grandes. De esta manera también se les otorga más importancia a los usuarios en las tres primeras posiciones. En cada una de las barras se mostrará la información siguiente:
• Posición en el ranking según el número de objetos encontrados y devueltos a sus propietarios.
• Número de objetos encontrados y devueltos a sus propietarios. • Nombre del usuario con enlace a su información completa. • Fotografía del usuario con enlace a su información completa.
Llegado este punto se ha finalizado la especificación del sistema BCN Look & Find.
75
4 Desarrollo del sistema
En esta sección se exponen los pasos que se han seguido para desarrollar el sistema BCN Look & Find sobre el sistema de gestión de contenido eZ Publish. Para ello se ha utilizado una metodología ágil, en el sentido de que se han llevado a cabo constantes iteraciones con puntos de control y retroalimentación. Concretamente se han hecho pequeños desarrollos de aproximadamente unas dos semanas de duración, con una posterior reunión con las directoras del proyecto, para revisar el resultado y compararlo con los requerimientos, sacar conclusiones y planificar mejoras, modificar la especificación, documentación, diseño, funcionalidades, etc.
4.1 Introducción al sistema eZ Publish
En primer lugar se expone una breve introducción al sistema eZ Publish. En general la información ha sido obtenida del sitio web de documentación de eZ Publish (34) y de su sitio web oficial ez.no (22). Para los detalles técnicos del sistema y para la utilización de su “framework”, han sido de gran ayuda estos sitios web, pero algunos detalles más teóricos y de utilización de la plataforma, ha sido necesario obtener información de los siguientes libros, eZ Publish Content Management (35), eZ Publish Basics (36) y eZ Publish Enterprise Tour (37).
Como la mayoría de sistemas de gestión de contenidos, eZ Publish consiste en una aplicación compuesta de diferentes módulos, conectada a una base de datos, donde se almacenan todos los elementos, contenidos y características que lo componen. Esta aplicación permite al usuario elaborar su sitio web.
Este sistema se ha desarrollado siguiendo el patrón de arquitectura “Modelo Vista Controlador” (MVC). Este patrón consiste en mantener una separación entre los componentes que forman la capa de presentación, más cercana al usuario (Vista), los componentes que forman la capa sobre la que se manejan los datos, procesado, almacenamiento, etc. (Modelo) y los elementos que se utilizan de intermediarios entre las otras dos capas (Controlador).
En el caso de eZ Publish, la capa vista está formada por plantillas TPL, hojas de estilo CSS, JavaScript, imágenes, etc. Las plantillas TPL se codifican mezclando código HTML y el código propio del motor que intercambia datos entre el controlador y la vista. La capa modelo está formada por una base de datos MySQL y clases PHP que interactúan directamente con esta base de datos. Por último la capa controlador está formada por clases, módulos y “scripts” PHP que intercambian datos del modelo a la vista y viceversa.
El conjunto de estas tres capas forman un sitio web personalizable. El sitio web se compone de dos páginas, el frontal (“front-‐end”) donde pueden verse los resultados que finalmente visualizará el usuario y el “back-‐end” sobre el que el administrador, desarrollador, etc., puede administrar, crear, borrar y editar el contenido.
Antes de exponer el funcionamiento del sistema eZ Publish es necesario definir algunos conceptos y elementos.
76
4.1.1 Conceptos básicos sobre eZ Publish
El sistema eZ Publish denomina “object” (objeto) a cada uno de los elementos que forman el contenido del sistema. El concepto objeto es similar al conocido de lenguajes de programación orientados a objetos ya que al fin y al cabo los contenidos del sistema son instancias de clases que definen su estructura. Puesto que este proyecto trabaja con objetos perdidos, encontrados, etc., a partir de ahora se utilizará la palabra “contenido” para referirse a este elemento y omitir posibles confusiones. Un ejemplo de contenido es un usuario.
Como se ha comentado los contenidos del sistema son instancias de clases que definen su estructura. eZ Publish utiliza el elemento “class” (clase), para definir la estructura de los contenidos que se crean en el sistema. Un ejemplo de clase es la que define la estructura de un usuario.
Las clases que definen la estructura de los contenidos están formadas por “datatypes” (tipos de datos). Estos tipos de datos pueden ser desde lo más simple como una línea de texto, a más complejos como un mapa de Google.
Los objetos creados a partir de las clases están compuestos de “attributes” (atributos). Un atributo no es más que el contenido asignado a un tipo de dato de la clase sobre la que se ha creado el objeto.
Un “node” (nodo), es otro elemento abstracto que el sistema utiliza para denominar a cada una de las ubicaciones de los contenidos. Un contenido puede ser accesible desde diferentes puntos del sitio web y mostrarse de diferentes maneras. Por ejemplo un mismo usuario puede mostrarse accediendo desde la página principal o desde la sección “Comunidad”. El acceso al usuario también es diferente, puede ser un enlace con su nombre, una fotografía, etc. Y también pueden mostrarse los datos del usuario de manera diferente, en ocasiones puede mostrarse solo su nombre o en otras toda su información, etc. Cada una de estas “exposiciones” de un contenido se denomina nodo.
Para completar la definición de estos conceptos básicos a continuación se muestra un diagrama utilizando como ejemplo un objeto perdido registrado en el sistema por algún usuario.
77
Diagrama 15, Estructura del contenido eZ Publish
4.1.2 Estructura de la base de datos
A diferencia de un sitio web desarrollado desde cero o sobre un “framework”, un sistema de gestión de contenido dispone de una estructura de base de datos muy genérica, ya que tiene que adaptarse a los requerimientos de cualquier sitio web. Por ejemplo, si se hubiera tenido que desarrollar la estructura de base de datos para el sistema BCN Look & Find, ésta dispondría de tablas como “lost_objects” y “found_objects” que almacenarían la información de los objetos registrados por los usuarios, pero la estructura sobre la que se ha trabajado es más compleja.
A continuación se expone parte de la estructura de la base de datos del sistema eZ Publish. Puesto que es un sistema amplio, sólo se muestran los elementos que afectan e interactúan más directamente el sistema BCN Look & Find.
78
A continuación se describe la función de cada una de estas tablas y se define su estructura, columnas, claves primarias, asociaciones, etc.
Ezcontentclass Como se ha comentado anteriormente, el sistema eZ Publish utiliza un elemento llamado clase, para representar la estructura de cada uno de los contenidos, define qué atributos tiene, de que tipo son, etc. Esta tabla es la encargada de almacenar esta información.
• Clave primaria. (id, version). • Atributos.
o id. Valor entero que identifica la clase en el sistema. o version. Valor entero que representa la versión de la clase. o created. Fecha de creación de la clase. o modified. Fecha de la última modificación de la clase. o identifier. Nombre único que identifica la clase en el sistema. o contentobject_name. Este campo especifica el atributo de la clase encargado
de identificar cada uno objetos instanciados de ella. o url_alias_name. Atributo utilizado como alias de URL para acceder a las
secciones/contenidos creados a partir de esta clase. o creator_id. Valor entero que identifica al usuario que ha creado la clase. o modifier_id. Valor entero que identifica al último usuario que ha modificado la
clase. • Asociaciones.
o ezcontentclass_name. Una clase puede tener diferentes nombres dependiendo de su versión.
o ezcontentclass_attribute. Una clase está formada por diversos atributos. o ezcontentobject. Una clase puede tener diferentes objetos (instancias) que
forman el contenido del sitio web.
Diagrama 16, Base de datos
79
ezcontentclass_name Esta tabla se encarga de almacenar en base de datos cada uno de los nombres que tenido una clase en el sistema. Cuando un usuario administrador puede editar las clases, se hace necesario mantener un control de versiones.
ezcontentclass_attribute Como se ha comentado anteriormente las clases definen la estructura del contenido, en esta tabla de base de datos se almacena la estructura y el tipo de cada uno de los atributos de una clase.
• Clave primaria. (id, version). • Atributos.
o id. Valor entero que identifica el atributo de clase en el sistema. o version. Valor entero que representa la versión del atributo de clase. o identifier. Nombre único del atributo que lo identifica en el sistema. o data_float. Si el atributo contiene información de tipo decimal se almacena en
este campo. o data_int. Si el atributo contiene información de tipo entero se almacena en
este campo. o data_text. Si el atributo contiene información de tipo texto se almacena en
este campo. o data_type_string. Si el atributo contiene información de tipo cadena de
caracteres, aquí se especifica el tipo de cadena de caracteres usado. o is_required. Valor entero que especifica si el atributo es requerido. o contentclass_id. Valor entero que identifica la clase a la que pertenece el
atributo. • Asociaciones.
o ezcontentclass. Un atributo de clase en una versión específica pertenece únicamente a una clase.
o ezcontentclass_attribute. Un atributo de clase en una versión específica contiene varios atributos de clase.
ezcontentobject Esta tabla es la encargada de almacenar la información de cada uno de los objetos (instancias) creados a partir de las clases. Estos elementos representan el contenido del sitio web. Su estructura es muy similar a la de las clases.
• Clave primaria. id. • Atributos.
o id. Valor entero que identifica el atributo de clase en el sistema. o published. Fecha de publicación del contenido. o modified. Fecha de la última modificación del contenido. o current_version. Valor entero que representa la versión que actualmente está
en curso. o owner_id. Valor entero que identifica al usuario propietario del contenido
(creador).
80
o status. Valor entero que representa el estado en el que se encuentra el contenido.
o name. Nombre del contenido. o contentclass_id. Valor entero que representa la clase a la que pertenece el
contenido. • Asociaciones.
o ezcontentclass. Un contenido pertenece únicamente a una clase. o ezcontentobject_name. Un contenido puede disponer de diferentes nombres
según su versión. o ezcontentobject_version. Un contenido puede disponer de diferentes
versiones. o ezcontentobject_attribute. Un contenido está formado por varios atributos de
objeto. o ezuser. Un contenido puede representar varios usuarios.
ezcontentobject_name De la misma manera que para las clases, esta tabla se encarga de almacenar cada uno de los nombres que ha tenido un objeto según su versión.
ezcontentobject_version Junto con los datos almacenados en la tabla anterior, esta tabla mantiene un control de versiones de cada uno de los contenidos creados en el sistema.
• Clave primaria. id. • Atributos.
o id. Valor entero que identifica la versión del contenido en el sistema. o created. Fecha de creación de la versión del contenido. o version. Valor entero que representa la versión del contenido. o status. Valor entero que representa el estado en el que se encuentra la
versión del contenido. o creator_id. Valor entero que identifica el usuario creador de la versión del
contenido. o user_id. Valor entero que identifica al usuario al que representa la versión del
contenido, si es que representa a algún usuario. o contentobject_id. Valor entero que identifica el contenido al que pertenece la
versión. • Asociaciones.
o ezcontentobject. Una versión de contenido pertenece únicamente a un contenido.
ezcontentobject_attribute
De la misma manera que para las clases, esta tabla de base de datos almacena la información de cada uno de los atributos de los contenidos. Puesto que su estructura es similar a “ezcontentclass_attribute”, no se entra en detalle.
81
ezuser
Esta tabla de base de datos almacena la información de cada una de las cuentas de usuario del sistema. El sistema eZ Publish, como el resto de elementos, representa cada cuenta de usuario como un contenido con algunas peculiaridades, que se exponen a continuación.
• Clave primaria. (contentobject_id). • Atributos.
o contentobject_id. Valor entero que identifica el contenido que representa al usuario en el sistema.
o email. Dirección de correo electrónico única del usuario. o login. Nombre de usuario único que identifica al usuario en el sistema. o password_hash. Contraseña para que el usuario pueda acceder a su cuenta.
• Asociaciones. o ezcontentobject. Un usuario es representado por un único contenido. o ezuser_role. Un usuario puede disponer varios roles de usuario.
ezrole
Esta tabla de base de datos almacena la información de cada uno de los roles de usuario.
• Clave primaria. id. • Atributos.
o id. Valor entero que identifica el rol de usuario en el sistema. o version_id. Valor entero que representa la versión del rol de usuario. o name. Nombre del rol de usuario.
• Asociaciones. o ezuser_role. Un rol de usuario puede tener varias relaciones entre usuario y
rol. o ezpolicy. Un rol de usuario puede poseer varias políticas.
ezuser_role
Esta tabla de base de datos almacena la información de cada una de las relaciones entre usuarios y roles de usuario.
ezpolicy
Esta tabla de base de datos almacena la información de cada una de las políticas que definen los permisos de usuario.
• Clave primaria. id. • Atributos.
o id. Valor entero que identifica la política en el sistema. o function_name. Nombre único que de la función sobre la que se define la
política de permisos. o module_name. Nombre único del módulo de eZ Publish sobre el que se está
definiendo la política de permisos.
82
o role_id. Valor entero que identifica el rol al que pertenece la política. • Asociaciones.
o ezrole. Una política de permisos pertenece únicamente a un rol de usuario. o ezpolicy_limitation. Una política de permisos puede disponer varias
limitaciones.
ezpolicy_limitation
Esta tabla de base de datos almacena la información de cada una de las limitaciones de permisos del sistema.
• Clave primaria. id. • Atributos.
o id. Valor entero que identifica la limitación de permisos en el sistema. o identifier. Nombre único que identifica la limitación de permisos en el sistema. o policy_id. Valor entero que identifica la política sobre la que se aplica la
limitación de permisos. • Asociaciones.
o ezpolicy. Una limitación de permisos, limita únicamente una política de permisos.
o ezpolicy_limitation_value. Una limitación puede disponer de varios valores.
ezpolicy_limitation_value
Esta tabla de base de datos almacena la información de cada uno de los valores de limitaciones de permisos.
• Clave primaria. id. • Atributos.
o id. Valor entero que identifica el valor de limitación de permisos en el sistema. o value. Valor alfabético, cuyo significado representa una limitación de
permisos. o limitation_id. Valor entero que identifica la limitación de permisos a la que se
le aplica este valor. • Asociaciones.
o ezpolicy_limitation. Un valor se aplica a una única limitación de política de permisos.
4.1.3 Estructura de directorios
Después de analizar la estructura de base de datos, es el momento de analizar la estructura de directorios que forman el código del sistema eZ Publish.
83
Imagen 1, Estructura de directorios del sistema
El sistema eZ Publish se compone de los directorios mostrados en la imagen anterior. A continuación se van a mencionar los más importantes y sobre los que se ha trabajado.
• El directorio “bin” contiene “scripts” PHP ejecutables necesarios, entre otras cosas, para el mantenimiento del sistema. Un “script” que normalmente se ha utilizado es “ezcache.php”. El código de este ejecutable parametrizable, elimina los datos almacenados en la memoria cache del sistema. Muy útil cuando se efectúan cambios de código o de diseño.
• El directorio “design” contiene todos los elementos que componen el diseño del sitio web, plantillas TPL, archivos CSS, imágenes, ficheros JavaScript, etc. Cada uno de los diseños del sistema se encuentran dentro de diferentes directorios que tienen la misma estructura. Por ejemplo podemos directorios de diseño como “standard”, “ezflow”, ezwebin”, etc. La estructura interna de estos elementos se compone de un directorio para imágenes, otro para “JavaScript”, otro para estilos CSS, otro que contiene las plantillas TPL y por último otro llamado “override”. El último fichero se utiliza para sobrescribir cualquier tipo de elemento de diseño utilizando la misma estructura de directorios. Por ejemplo si se decide sobrescribir la plantilla que muestra el formulario de registro de usuarios, esta se creará dentro del directorio “override/templates” con el nuevo nombre especificado y el sistema creará una regla de sobrescritura que obligará a mostrar esta plantilla en vez de la original. El tema diseño será expondrá más profundamente en secciones posteriores.
• El directorio “extension” es indiscutiblemente el más utilizado. Aquí se guardan todas las extensiones del sistema eZ Publish. Una extensión, como su propio nombre indica es cualquier módulo de código que extiende las funcionalidades o el diseño del sistema por defecto. Por supuesto el sistema eZ Publish contiene por defecto algunas extensiones, estas extensiones pueden activarse o desactivarse en cualquier momento desde la página de administración. Estas extensiones también pueden contener directorios de diseño, el sistema eZ Publish busca inicialmente elementos de diseño dentro de las extensiones, si los encuentra, los utiliza, sino los busca en el directorio
84
por defecto “design”. El tema extensiones funcionales y de diseño se tratará más profundamente en secciones posteriores.
• El directorio “kernel” es el más importante del sistema, ya que contiene todos los módulos y código PHP por defecto que permite el funcionamiento básico del sistema eZ Publish. No es conveniente modificar los archivos de este directorio, se recomienda utilizar extensiones, ya que en todo momento se puede volver al sistema original eliminando la extensión creada. Además al instalar una actualización del sistema, podrían substituirse ficheros del directorio “kernel” y perder todo lo que se haya modificado en su interior. En ocasiones no hay más remedio.
• El directorio “settings” guarda todos los archivos que definen la configuración del sistema. Estos ficheros se crean automáticamente con la instalación de la aplicación, con los datos que se le han introducido. En estos ficheros se encuentra datos como los de conexión a base de datos, título del sitio web, idiomas disponibles, etc.
• El directorio “share” contiene todos los ficheros de traducción del sitio web. El sitio web de BCN Look & Find está disponible en castellano y catalán, por lo tanto se han tenido que insertar y modificar traducciones en los dos ficheros correspondientes.
• El directorio “var” contiene entre otras cosas, datos almacenados en memoria cache, imágenes insertadas por usuarios, etc.
Una vez introducidos los aspectos básicos del sistema de gestión de contenido que se ha utilizado para el desarrollo del sitio web, se procede a exponer los pasos que se han llevado a cabo para desarrollar el sistema BCN Look & Find.
4.2 Instalación del sistema
El primer paso ha sido instalar el sistema eZ Publish. Inicialmente se instaló la última versión en curso 4.3, pero conforme fue avanzando el proyecto fue publicada una nueva versión 4.4, puesto el desarrollo del proyecto todavía no estaba muy avanzado se decidió actualizar el sistema con dicha versión. El sistema se ha descargado de share.ez.no (38).
Según la documentación doc.ez.no (34), los requisitos recomendados para un funcionamiento óptimo del sistema eZ Publish 4.4 son los siguientes.
• Sistema operativo Debian 2.0 o Linux 2.6 • Servidor web Apache 2.2.16. • Base de datos MySQL 5.0.51a. • PHP 5.2.14. • Aplicación para administración de imágenes ImageMagick 6.4.9.
Los requisitos mínimos para el funcionamiento del sistema eZ Publish 4.4 son los siguientes.
• Sistema operativo Windows 2008 o posterior, Solaris 10 Intel with Sun Webstack, Opensolaris 2009.06 Intel.
• Servidor web Apache 2.2.x, MS IIS 7 con Microsoft URL Rewrite Module 1.1. • Base de datos MySQL 5.0.x, 5.1.x, PostgreSQL 8, Oracle 11g. • PHP 5.2.1 o posterior y PHP 5.3.x.
85
• Aplicación para administración de imágenes ImageMagick 6.4.x o PHP extensión GD2.
4.3 Desarrollo de secciones básicas
Como se ha comentado anteriormente, para el aprendizaje del sistema ha sido necesario utilizar la documentación y algún libro indicados anteriormente, pero para algunos aspectos del desarrollo no ha sido suficiente y se ha tenido que recurrir al foro oficial share.ez.no (39). Gran parte de la información obtenida por otros usuarios ha sido de gran ayuda y una manera de avanzar un poco más rápido en el aprendizaje del sistema.
Como se ha comentado anteriormente eZ Publish utiliza una tabla genérica en base de datos para guardar todo el contenido creado en el sistema. La estructura, campos y datos de estos elementos llamados objetos vienen definidos por los registros llamados clases contenidos en otra tabla genérica. La página de administración del sistema eZ Publish permite crear objetos utilizando clases por defecto o crear nuevas clases con la estructura que el usuario desee.
Lo primero que se ha llevado a cabo en el desarrollo del sistema es la creación de las secciones básicas del sitio web.
Las secciones “¿Qué es BCN Look & Find?”, “Preguntas más frecuentes”, “Condiciones de uso” y “Política de privacidad” se han creado utilizando la clase por defecto de eZ Publish “Documentation page”. Esta clase permite introducir un título que identifica la sección y un área de texto.
El sistema crea automáticamente un nodo principal para cada objeto creado. Este nodo representa la visualización en el sitio web del objeto creado. Cada uno de los nodos dispone de plantillas TPL en la capa “vista” del sistema. La plantilla que utilizan por defecto los objetos de la clase “Documentation page” pertenecen a la extensión de eZ Publish “ezwebin”.
Esta plantilla muestra el contenido del objeto. Además construye un índice si el texto adjunto incluye títulos y sub-‐títulos y añade un pie con la fecha de actualización de la información.
Por defecto, si el usuario dispone de los permisos adecuados, el sistema crea una opción en el menú principal para acceder a las secciones. En un inicio se pensó el diseño del sitio web para que las secciones “¿Qué es BCN Look & Find?” y “Preguntas más frecuentes”, fueran accesibles desde el menú principal, pero por razones ya comentadas en el punto “Especificación del sistema”, se ha decidido situarlas en el pie de página. Para excluir estas secciones del menú principal es necesario modificar la plantilla TPL correspondiente.
Para modificar el pie de página se debe editar la plantilla TPL de la extensión “ezflow” correspondiente.
Para intentar no modificar en lo posible el código estándar del sistema eZ Publish se ha creado una extensión de diseño que se expondrá en puntos posteriores. Separando el nuevo diseño del resto del código utilizando un extensión, se consigue que sea más sencillo incorporar nuevos diseños, editar el existente o incluso desactivarlo y recuperar el diseño de eZ Publish por defecto.
86
El siguiente paso ha sido el de crear los dos elementos más importantes del sistema BCN Look & Find, objeto encontrado y objeto perdido.
4.4 Objeto encontrado y objeto perdido
El sistema eZ Publish no dispone de ninguna clase por defecto que cumpla los requisitos necesarios para crear objetos encontrados y objetos perdidos, por lo tanto se han creado dos clases nuevas, “Lost object” y “Found object”, con los atributos necesarios, utilizando los tipos de datos que el sistema suministra.
La clase que representa la estructura de objetos encontrados se llama “Found object” y contiene los siguientes atributos.
• Categoría. Para crear este atributo se ha utilizado el tipo de dato “Relación de objeto”. Este tipo de dato permite crear una relación con un conjunto de objetos y mostrarlos utilizando un selector desplegable. Este atributo se ha definido como obligatorio ya que en la especificación del sistema se ha decidido asignar cada objeto a una categoría para facilitar su búsqueda.
• Nombre. Tipo de dato “Línea de texto”. Desarrollado sobre el “input” básico de HTML “text”. Este atributo se ha definido como obligatorio, ya que en la especificación del sistema se ha decidido que los objetos posean un título para su identificación en el sitio web.
• Descripción. Tipo de dato “Área de texto”. Desarrollado sobre el “input” básico de HTML “textarea”.
• ¿Dónde lo has encontrado? Tipo de dato “Dirección GMap”. Utiliza la API de Google para mostrar un mapa sobre el que se puede seleccionar una dirección postal. Este atributo se ha definido como obligatorio, ya que en la especificación del sistema se ha decidido que es necesario que los usuarios añadan una dirección aproximada del lugar dónde se ha encontrado el objeto, para que su propietario pueda identificarlo más fácilmente.
• Descripción de la dirección. Tipo de dato “Área de texto”. • ¿Cuándo lo has encontrado? Tipo de dato “Fecha”. Muestra tres líneas de texto sobre
las que introducir el día, mes y año. Además de un calendario desarrollado en “javascript” sobre el que se puede seleccionar una fecha. Se ha tenido que modificar el código de este tipo de dato para establecer un límite en las fechas a seleccionar del calendario, ya que no tiene ningún sentido que un objeto haya sido encontrado en una fecha futura. El atributo “¿Cuándo lo has encontrado?” se ha definido como obligatorio, ya que en la especificación del sistema se ha decidido que es necesario que el usuario añada esta fecha de manera aproximada, para que su propietario pueda identificar el objeto con mayor facilidad.
• Fotografía. Tipo de dato “Imagen”. Muestra un “input” HTML sobre el que subir una imagen con unas restricciones definidas en la configuración del sistema.
• Pregunta secreta. Tipo de dato “Área de texto”. • Etiquetas. Tipo de dato “Palabras clave”. Muestra una línea de texto sobre la que se
debe introducir palabras separadas por comas.
87
• Estado. Tipo de dato “Relación de objeto”. Este atributo se ha definido como obligatorio, con la relación por defecto al estado “Perdido” del conjunto de estados de un objeto encontrado de los que se hablará en puntos posteriores. Este campo no es seleccionable por el usuario, por lo tanto es necesario modificar la plantilla que permite crear objetos encontrados.
• Identificador el posible propietario. Tipo de dato “Número entero”. Implementado sobre el “input” básico de HTML “text”, con algunas restricciones. Este atributo se ha creado con la finalidad de almacenar temporalmente el identificador del usuario que ha marcado el objeto como de su propiedad. Como es lógico este atributo no será visible ni editable por los usuarios, por lo tanto se ha modificado la plantilla que muestra la información del objeto registrado y la plantilla que permite registrar objetos encontrados.
• Identificador del propietario. Tipo de dato “Número entero”. Este atributo se ha incluido con la finalidad de guardar el identificador del usuario propietario definitivo del objeto encontrado. Este atributo no será visible ni editable por los usuarios, por lo tanto se ha modificado la plantilla que muestra la información del objeto registrado y la plantilla que permite registrar objetos encontrados.
La clase que representa la estructura de cada uno de los objetos perdidos se llama “Lost object” y está formada por los siguientes atributos.
• Categoría. Igualmente que el atributo de la clase que representa objetos encontrados, está representado por el tipo de dato “Relación de objeto” y se ha definido como obligatorio.
• Nombre. Tipo de dato “Línea de texto”. • Descripción. Tipo de dato “Área de texto”. • ¿Dónde lo has visto por última vez? Representa el lugar donde el usuario ha perdido
el objeto, utilizando el tipo de dato “Dirección GMap”. Este atributo se ha definido como obligatorio.
• Descripción de la dirección. Tipo de dato “Área de texto”. • ¿Cuándo lo has visto por última vez? Representa la fecha en la que el usuario ha
perdido el objeto, utilizando el tipo de dato “Fecha”. Este atributo se ha definido como obligatorio.
• Recompensa. Utiliza el tipo de dato “Decimal” que está implementado sobre el “input” básico HTML “text”, con las restricciones correspondientes que debe poseer un número decimal.
• Fotografía. Tipo de dato “Imagen”. • Etiquetas. Tipo de dato “Línea de texto”. • Estado. Del mismo modo que el atributo estado de la clase que representa objetos
encontrados, este campo utiliza el tipo de dato “Relación de objeto” y está relacionado por defecto con el estado “Perdido” del conjunto de estados de objeto perdido. Los usuarios no editar este atributo, por lo tanto se ha editado la plantilla correspondiente.
88
• Identificador del posible “finder”. Este atributo definido con el tipo de dato “Número entero” se utiliza para almacenar temporalmente el identificador del usuario que ha marcado el objeto como encontrado.
• Identificador del “finder”. Este atributo definido con el tipo de dato “Número entero” se utiliza para guardar el identificador del usuario que finalmente ha encontrado el objeto.
El sistema BCN Look & Find ya dispone de dos nuevas clases que definen la estructura de los objetos encontrados y perdidos que los usuarios registran. El siguiente paso es crear una ubicación donde almacenarlos. Inicialmente se había pensado la estructura del sitio web para que existieran dos secciones diferenciadas, para visualizar, añadir y almacenar objetos encontrados y perdidos, accesibles desde el menú principal. En su momento se habían creado estas dos secciones utilizando la clase “Front page”. Esta clase, (utilizando para la página principal por defecto), dispone de diferentes opciones para estructurar el contenido de la sección. La idea inicial era mostrar en una parte central grande una lista de objetos registrados y en el pequeño lateral derecho la lista de categorías de objetos, por esta razón la clase “Front page” era ideal para crear esta sección. Más tarde se decidió prescindir de estas secciones y que los objetos registrados se mostraran en su totalidad en la página principal, para no rehacer los contenedores de objetos se decidió conservar estas secciones exclusivamente como almacén de objetos.
Una vez decidida la ubicación de los objetos encontrados y perdidos, hay que permitir y facilitar crear estos tipos de contenido a los usuarios registrados, (“Members” en el sistema eZ Publish).
Para ello se han editado los permisos de usuario desde la página de administración del sistema. El usuario visitante (“Anonymous” en eZ Publish), deberá poder visualizar los objetos registrados en el sistema y el usuario registrado deberá poder crear este tipo de contenido. Funcionalidades como editar y borrar son tienen un tratamiento especial, ya que un usuario registrado solo puede editar y borrar contenidos que ha creado personalmente, exceptuando los casos de cambio de estado provocados por los botones “Es mío” y “Lo he encontrado”.
Agregar permisos a los usuarios no sirve de nada si no se implementa una interfaz para que puedan acceder al formulario de creación de contenido. Así que se ha editado la plantilla TPL que muestra el menú principal, anteriormente mencionada, para incorporar un botón “Añadir objeto” que despliegue dos botones más “Objeto perdido” y “Objeto encontrado”.
Estos dos botones llaman a la acción que muestra los formularios para añadir el tipo de contenido correspondiente. Como se ha comentado anteriormente, para no modificar en lo posible el código estándar del sistema eZ Publish se ha creado una extensión de diseño.
La plantilla que muestra el formulario para registrar o editar objetos encontrados y perdidos es una plantilla genérica para añadir contenido de la extensión “ezwebin”.
Puesto que los formularios para añadir objetos tienen peculiaridades específicas no se puede utilizar una plantilla genérica, así que se ha creado una plantilla específica para cada tipo de
89
objeto, sobrescribiendo la genérica. Esta acción crea plantillas el directorio “override” del directorio de diseño especificado. En este caso se ha utilizado el directorio de diseño “ezflow” ya que es el que figuraba por defecto.
Estas nuevas plantillas se han creado con el código de la plantilla original por defecto, posteriormente se editarán utilizando la nueva extensión de diseño.
Lo mismo ocurre con las plantillas que muestran la información de los objetos encontrados y perdidos registrados. Se ha sobrescrito del mismo modo creando dos nuevas específicas para cada tipo de objeto.
4.5 Categorías de objeto
Como se ha especificado anteriormente en la Sección 3, los objetos se dividen en categorías. Estas categorías se utilizarán en diferentes partes del sistema y de diferentes maneras, en la página principal para filtrar los objetos a mostrar, en la información de objetos que se muestra en diferentes lugares del sitio web, etc. Como se ha expuesto anteriormente, la clase que define a su vez la estructura de objetos encontrados y perdidos, contiene un atributo de tipo “Relación de objeto”, que relaciona los objetos creados con el objeto categoría seleccionado por el usuario.
Puesto que las categorías son elementos complejos que disponen de varios atributos y son utilizadas en diferentes procesos y mostradas en diferentes ubicaciones, se ha decidido crear una clase específica para ellas. La clase que define la estructura de una categoría se llama “Object category” y se compone de los siguientes atributos.
• Nombre. Nombre que identifica la categoría. Tipo de dato “Línea de texto”. • Descripción. Descripción de la categoría. Tipo de dato “Área de texto”. • Imagen. Imagen representativa de la categoría. Tipo de dato “Imagen”.
Para ubicar las categorías se ha creado una sección “Administración” a la que solo el usuario con rol administrador acceder. Dentro de esta sección encontramos dos sub-‐secciones “Categorías” y “Estados de objeto”. De esta manera se mantiene un orden para ubicar todos los elementos no públicos, necesarios para el desarrollo del sistema BCN Look & Find.
A partir del momento en el que se crean las categorías, sus datos pueden ser consultados desde cualquier plantilla y pueden ser relacionadas desde cualquier otro tipo de contenido.
4.6 Estados de objeto
Del mismo modo que las categorías de objeto, se han creado los estados de objeto encontrado y perdido, especificados en la Sección 3. Teniendo en cuenta que estos estados tienen que ser relacionados con objetos encontrados y perdidos registrados en el sistema y que su información será consultada en diferentes puntos del sistema, se ha decidido crearlos como objetos. Para ello es necesario crear una nueva clase que defina la estructura de estos estados. Esta clase se llama “Object status” y está formada por los siguientes atributos.
90
• Nombre. Nombre que identifica el estado. Se han utilizado nombres cortos representativos “Perdido”, “Pendiente” y “Devuelto”. Se utilizan tanto para los dos tipos de objetos. Tipo de dato “Línea de texto”. Este atributo es obligatorio.
• Mensaje. Mensaje que se muestra al usuario en el sitio web. Tipo de dato “Área de texto”. Este atributo es obligatorio.
• Descripción. Descripción extra del estado. Está información no se muestra en ningún lugar público. Tipo de dato “Área de texto”.
Puesto que los estados de objeto también son contenidos creados de la clase “Object status”, es necesario ubicarlos en algún lugar del sistema. De la misma manera que las categorías se ha decidido almacenarlos en la sección “Administración”, a la que solo los usuarios administradores puede acceder. Para utilizar o mostrar estos estados, serán cargados desde esta ubicación. Los estados de objeto se almacenarán en la sub-‐sección “Estados de objeto”, de la sección “Administración” y dentro de ésta se dividirán entre otras dos sub-‐secciones “Estados de objeto encontrado” y “Estados de objeto perdido”, de esta manera es más sencillo obtener la información de los estados, según el tipo de objeto.
Por último se han creado tres estados de objeto dentro de la sección “Estados de objeto encontrado” y tres más dentro de la sección “Estados de objeto perdido”. Tanto los estados de objeto perdido como los de objeto encontrado se identifican con el mismo nombre, “Perdido”, “Pendiente”, “Devuelto”, de esta manera su uso interno es más genérico y solo es necesario especificar el directorio donde se encuentra, para saber a que tipo de objeto se refieren. Por supuesto la información que se muestra a los usuarios varía según el tipo de objeto y el estado siguiendo las especificaciones de la Sección 3.3.2.
A partir de este momento los datos de los estados de objeto podrán ser consultados desde cualquier parte del sistema y podrán ser relacionados con cualquier otro objeto.
4.7 Usuarios
Una vez comentado como se ha construido la estructura de las secciones básicas del sitio web, los objetos encontrados y perdidos, las categorías y los estados de objeto, es el momento de definir la estructura de otro elemento muy importante del sistema, los usuarios.
Como se ha especificado anteriormente en la Sección 3.2, el sistema BCN Look & Find requiere de cuatro tipos de usuario, visitante, registrado, centro y administrador. Como ya se ha comentado anteriormente, eZ Publish considera un usuario como un tipo de contenido con la peculiaridad que este tipo de contenido de la clase “User”, dispone de un atributo llamado “cuenta de usuario”. Este atributo se compone del identificador numérico del usuario, el nombre, la dirección de correo electrónico y la contraseña. Por defecto eZ Publish dispone únicamente de una clase llamada “User” que representa todos los tipos de usuario del sistema (incluso el usuario visitante). Para diferenciar el tipo de usuario utiliza un elemento llamado “User group”. Todos los usuarios creados como contenido de la clase “User”, hacen referencia a un “User group” y de esta manera reciben un trato y unas características específicas del tipo de usuario. Los grupos de usuario del sistema eZ Publish son los siguientes.
91
• Anonymous. Los usuarios pertenecientes a este grupo representan los usuarios visitantes (anónimos) del sistema.
• Members. Los usuarios pertenecientes a este grupo representan los usuarios registrados (miembros) del sistema.
• Administrators. Los usuarios pertenecientes a este grupo representan los usuarios administradores del sistema.
A continuación se explica como se ha adaptado el sistema de usuarios de eZ Publish a las necesidades del sistema BCN Look & Find.
Para representar el usuario visitante y administrador, se ha utilizado la estructura por defecto de eZ Publish.
Para representar el usuario de tipo registrado, también se ha utilizado la estructura por defecto de eZ Publish, por lo tanto el usuario registrado, de manera interna será representado por el grupo de usuarios “Members”.
Como es evidente no hay manera de representar el usuario centro con la estructura por defecto de eZ Publish, por lo tanto ha sido necesario ampliarla. Para ello se ha creado un nuevo grupo de usuarios llamado “Centers” donde se ubicarán los usuarios de tipo centro. Las diferencias entre casos de uso especificados en la Sección 3.4, de usuarios registrados y usuarios de tipo centro quedan resueltas con la creación de este nuevo grupo de usuarios, puesto que los roles y los permisos se aplican sobre los grupos de usuarios. El problema que no queda resuelto es el de las diferencias en cuanto a datos personales del usuario. Un usuario de tipo centro tiene un perfil distinto que el de un usuario registrado, por lo tanto la clase “User” que utiliza el sistema eZ Publish por defecto para representar todos los usuarios, no satisface las necesidades del sistema BCN Look & Find. Para resolver este inconveniente se ha decidido crear una nueva clase independiente para representar los usuarios de tipo centro. Esta nueva clase se llama “Center” y dispone de los siguientes atributos.
• Nombre del centro. Tipo de dato línea de texto. Este nombre representa el nombre del centro como TMB, Biblioteca Rector Gabriel Ferraté, etc. Se ha limitado el número de caracteres a cuarenta ya que este nombre se muestra en el selector de centros de la página principal. Si se permite añadir nombres demasiado largos podrían desestructurar el diseño de la página. Este campo se ha definido como obligatorio, ya que tal y como se ha especificado anteriormente los centros necesitan de un título, para que el resto de usuarios sepan a qué centro se refiere.
• Nombre del responsable. Tipo de dato línea de texto. Representa el nombre de pila de la persona física que registra el centro. Este campo se ha definido como obligatorio, ya que tal y como se ha especificado anteriormente los centros deben tener una persona a su cargo que se responsabilice del registro.
• Apellido del responsable. Tipo de dato línea de texto. Representa el apellido de la persona física que registra el centro.
• Cuenta de usuario. Como ya se ha comentando la diferencia principal entre un tipo de contenido que representa un usuario y el resto de contenidos, es que éste posee un tipo de dato cuenta de usuario. Este tipo de dato se compone de nombre de usuario,
92
contraseña, “repetir contraseña” y dirección de correo electrónico. Evidentemente este atributo se ha definido como obligatorio, ya que a parte de ser un requerimiento del sistema eZ Publish, es la forma de identificar al usuario centro en el sistema BCN Look & Find.
• He leído y acepto las condiciones de uso. Tipo de dato “Checkbox”. El usuario debe aceptar las condiciones de uso para poder finalizar el registro. Este atributo solo incluye un marcador, pero en la plantilla que muestra el formulario se ha añadido un enlace que muestra una ventana modal con las condiciones de uso.
Estos son los atributos que se muestran para crear una cuenta de usuario de tipo centro, pero dispone de otros campos opcionales que el usuario puede añadir o editar en cualquier momento. A continuación se muestran los atributos extra de la clase “Centro”.
• ¿Quieres que la dirección de correo electrónico sea pública? Tipo de dato “Checkbox”. Por defecto nunca se mostrará en el perfil público del usuario la dirección de correo electrónico de éste, pero puede modificarse en cualquier momento marcando esta casilla. Esta dirección de correo electrónico solo será desvelada sin tener en cuenta esta casilla en el momento en que el usuario marca un objeto pulsado “Lo he encontrado”, ya que se envía un correo electrónico al usuario que ha registrado el objeto, con dicha información. A pesar de ello el usuario será informado justo antes de enviar el mensaje de correo electrónico.
• Información del centro. Tipo de dato “Área de texto”. Este atributo permite al usuario introducir una descripción del centro, de cara al resto de usuarios.
• Fotografía. Tipo de dato “Imagen”. El centro podrá añadir una fotografía, para que el resto de usuarios la vean.
• Dirección postal. Tipo de dato “Dirección GMap”. El usuario podrá indicar la dirección postal en la que se encuentra el centro al que representa.
• ¿Quieres que la dirección postal del centro sea pública? Tipo de dato “Checkbox”. Por defecto no se muestra la dirección postal del centro al resto de usuarios, pero puede editarse marcando este campo.
• Dirección web. Tipo de dato “URL”. El usuario responsable del centro registrado podrá añadir una dirección al sitio web del centro que se mostrará al resto de usuarios.
• Teléfono de contacto. Tipo de dato “Línea de texto”. Podrá añadirse un número de teléfono para contactar con el centro registrado.
• ¿Quieres que el teléfono de contacto sea público? Tipo de dato “Checkbox”. Este campo define si el usuario quiere que el teléfono de contacto del centro sea visible al resto de usuarios.
• Objetos devueltos. Tipo de dato “Número entero”. Como se ha comentado en otras secciones, se ha creado una sección en la que se muestra una lista con los diez usuarios que más objetos han devuelto a sus propietarios, para facilitar este recuento se ha añadido este campo que incrementa cada que el usuario devuelve un objeto. Los centros están excluidos de este “top ten”, ya que se supone que van a ser los usuarios que más objetos devuelvan, pero no está de más incluir el campo por si necesitara para otros usos.
93
Como ya se ha comentado la clase “User” estándar del sistema eZ Publish se utiliza para el resto de tipos de usuario (visitante, registrado y administrador). En el caso de los usuarios de tipo visitante, los datos que se exponen a continuación son valores por defecto o nulos que el sistema eZ Publish introduce automáticamente.
• Nombre. Tipo de dato “Línea de texto”. Este atributo representa el nombre de pila del usuario.
• Apellido. Tipo de dato “Línea de texto”. Representa el apellido del usuario. • Cuenta de usuario. Como ya se ha comentado anteriormente este tipo de dato
contiene “nombre de usuario”, “contraseña”, “repetir la contraseña” y “dirección de correo electrónico”. Es imprescindible para identificar esta clase como usuario.
• Fotografía. Tipo de dato “Imagen”. Permite al usuario añadir una fotografía. • He leído y acepto las condiciones de uso. Tipo de dato “Checkbox”. Como en el
usuario centro, es necesario marcar esta casilla para poder finalizar el registro del usuario.
Para cumplir con los requerimientos del sistema BCN Look & Find, ha sido necesario añadir algunos atributos, de la misma manera que para el usuario centro.
• ¿Quieres que tu nombre y apellido sean públicos? Tipo de dato “Checkbox”. Por defecto el nombre y el apellido del usuario no se mostrarán en el perfil público al resto de usuarios, esto es del todo configurable marcando está opción.
• ¿Quieres que la dirección de correo electrónico sea pública? Tipo de dato “Checkbox”. De la misma manera que el nombre y el apellido del usuario, si esta casilla no se marca, la dirección de correo electrónico del usuario no se mostrará en su perfil público. Únicamente se desvelará vía mensaje de correo electrónico a otro usuario, a pesar del contenido de este campo, en el momento que el usuario marque un objeto pulsando los botones “Es mio” o “Lo he encontrado”, por las razones antes mencionadas en el usuario de tipo centro.
• Dirección postal. Tipo de dato “Dirección GMap”. El usuario podrá indicar la dirección postal de su domicilio personal.
• ¿Quieres que la dirección postal del centro sea pública? Tipo de dato “Checkbox”. Por defecto no se muestra la dirección postal del domicilio del usuario al resto de usuarios, pero puede editarse marcando este campo.
• Fecha de nacimiento. Tipo de dato “Fecha”. El usuario podrá optar por añadir su fecha de nacimiento.
• ¿Quieres que tu fecha de nacimiento sea pública? Tipo de dato “Checkbox”. Este campo define si el usuario quiere que su fecha de nacimiento sea pública.
• Objetos devueltos. Tipo de dato “Número entero”. Como se ha comentado en otras secciones, se ha creado una sección en la que se muestra una lista con los diez usuarios que más objetos han devuelto a sus propietarios, para facilitar este recuento se ha añadido este campo que se incrementa cada vez que el usuario devuelve un objeto.
94
En el momento que un usuario de tipo visitante pulsa el enlace para registrarse, eZ Publish muestra por defecto el formulario de registro para usuarios de tipo registrado. Esto es un problema teniendo en cuenta que ahora también se dispone del tipo de usuario centro. Para que el sistema muestre los formularios correspondientes dependiendo del tipo de cuenta que el usuario visitante desea registrar ha sido necesario editar el código PHP que registra usuarios y las plantillas TPL relacionadas con el registro, identificación, perfil de usuario, etc.
El enlace de la cabecera del sitio web “crear cuenta”, por defecto re-‐direccionaba directamente al formulario de registro. Puesto que se debe seleccionar previamente el tipo de usuario a registrar, se ha modificado este enlace para que muestre una pantalla previa donde se expone la información necesaria y un enlace a los dos tipos de formulario posibles.
Para ello se ha creado un nuevo contenido titulado “Regístrate”. Una vez creado se ha sobrescrito la plantilla por defecto.
A continuación se ha editado la plantilla que muestra el formulario para registrar un usuario estándar.
A parte de modificar el diseño de esta plantilla se hace un control previo del tipo de usuario seleccionado para mostrar el formulario correspondiente. Como se ha comentado anteriormente en el formulario de registro no se muestran todos los campos del perfil de usuario, únicamente el nombre, apellido, nombre de usuario, dirección de correo electrónico, contraseña y el “checkbox” para aceptar las condiciones de uso.
Para que el sistema permita registrar el nuevo tipo de usuario centro ha sido necesario modificar el código PHP por defecto.
“…/kernel/user/register.php”.
Este “script”, entre otras cosas, selecciona el identificador del grupo de usuarios, “Members” por defecto y el identificador de la clase que define la estructura del usuario, “User” por defecto, del fichero de configuración y a continuación muestra la plantilla con el formulario de registro correspondiente. Lo que se ha hecho ha sido añadir el identificador del nuevo grupo de usuarios “Centers” y de la nueva clase “Center” en el fichero de configuración. Ahora cuando se hace la llamada a este “script” se le pasa por parámetro el tipo de usuario a registrar, se comprueba qué tipo de usuario es y se muestra el formulario correspondiente, de la clase correspondiente, finalmente se añade el contenido al grupo de usuarios correspondiente.
Una vez registrado el usuario se le debe permitir editar su perfil. El sistema eZ Publish muestra un enlace en la cabecera del sitio web “my profile” que redirecciona al perfil de usuario.
En el caso del sistema BCN Look & Find, a parte de modificar el nombre del enlace a “Mi perfil”, se ha decidido también ubicar el acceso a la cuenta de usuario en la sección “Comunidad” de la que se hablará más adelante.
95
4.8 Desarrollo de la página principal
Por defecto eZ Publish dispone de un tipo de contenido llamado “Front page” sobre el que se ha creado la página principal. Esta página principal no se puede eliminar, pero pueden ser modificados algunos de sus elementos.
El paquete instalado de eZ Publish llamado eZ Flow, dispone de la posibilidad de modificar la estructura y áreas de los contenidos creados sobre la estructura de la clase “Front page”. Por ejemplo en el caso de la página principal de BCN Look & Find se ha decidido que se disponga de un área en la parte izquierda mayor y un área menor en la parte derecha. Este tipo de disposición es denominado “2 zones layout 1”. Refiriéndose a que se compone de dos zonas la primera de las cuales es la principal y por lo tanto la mayor. Es importante entender este sistema para poder encontrar con facilidad la plantilla que se está utilizando para mostrar el contenido de las secciones que utilizan la clase “Front page”.
El sistema permite añadir bloques por defecto ya desarrollados. Como por ejemplo la nube de etiquetas que se ha añadido en la zona de la derecha de la página principal. Para mostrar la lista de objetos de la zona izquierda en un inicio se intentó utilizar el bloque que muestra todo el contenido de un tipo concreto. Su funcionamiento no era el esperado y requería de editar mucho código, así que se ha decidido crearlo desde cero editando la plantilla correspondiente y creando nuevas. En el caso de la lista de categorías y otros elementos se ha seguido el mismo proceso.
Otro elemento que puede generarse automáticamente es el mapa que muestra la ubicación de los objetos registrados. El sistema eZ Publish permite añadir este tipo de bloque, simplemente seleccionando la clase o las clases a las que pertenecen los tipos de contenido que se quieren mostrar y cuál es su ubicación. A pesar de ello su funcionalidad no se ajusta a los requerimientos del sistema BCN Look & Find, ya que, entre otros motivos no permite mostrar ubicaciones de diferentes tipos de objeto de manera independiente, el diseño no se adecua al requerido en esta sección y se hace casi imposible referenciar las marcas en el mapa, con los objetos mostrados en la lista. Finalmente ha sido más sencillo buscar su código en las extensiones de eZ Publish, copiarlo en la nueva extensión de diseño y editarlo para que complemente la lista de objetos y se adapte a las necesidades requeridas.
A continuación se explica como se ha llevado a cabo este desarrollo, incluyendo partes de código.
Cuando se incluye el bloque por defecto, éste utiliza la plantilla ubicada en la extensión “ezmaplocation”.
Lo primero que se hace en esta plantilla es cargar la librería de JavaScript de Google necesaria.
96
En el nuevo bloque se ha desarrollado, se incluye en la plantilla “objects_list.tpl”, donde se construye la lista de objetos de la página principal.
El siguiente paso es inicializar cada uno de los marcadores que contendrá el mapa. Para ello se ha reaprovechado la carga de los objetos de la lista, de esta manera también se fuerza que los objetos mostrados en el mapa sean los mismos que los mostrados en la lista, teniendo en cuenta los filtros de búsqueda seleccionados.
Como puede verse se utilizan los valores del atributo “address” de cada uno de los objetos.
Cabe recordar que una vez obtenida la información de cada uno de los objetos, se manda a la plantilla “object.tpl” que tiene como objetivo construir el objeto. Para que el mapa reconozca a qué objeto pertenece cada marcador, es necesario incluir el valor de $o_Gmap.id. Este valor servirá para construir el identificador de cada uno de los objetos.
El último paso es el de dibujar el mapa. Para ello simplemente se debe incluirse una etiqueta <div> con el identificador del mapa inicializado. La librería de Google ya se encarga de lo demás.
<script
src=http://maps.google.com/maps?file=api&key={ezini(‘SiteSettings’, ‘GMapsKey’)}
type=”text/javascript”>
</script>
<script type=”text/javascript”>
{foreach $st_objects as $o_Object}
data{$o_Gmap.id}.push(
{ldelim}
point: new GLatLng({$o_Object.data_map[‘address’].content.latitude}, {$o_Object.data_map[‘address’].content.logitude}),
address: ‘
<br>{$o_Object.data_map[‘address’].content.address}
<br><b>{$o_Object.data_map.name.content}</b>’
{rdelim});
{/foreach}
eZFLGMapAddListener(window, ‘load’, function()
{ldelim} eZFLGMapView(‘{$o_Gmap.id}’, data{$o_Gmap.id})
{rdelim}, false);
</script>
97
4.9 Desarrollo de la sección Comunidad
Como se ha comentado anteriormente en la Sección 3.9.6, entre otras, comunidad es una sección donde el usuario podrá acceder a un resumen de sus aportaciones (objetos registrados, objetos devueltos, comentarios, etc.) y un resumen de aportaciones del resto de usuarios. Además cabe recordar que está sección disponía de subsecciones para acceder a la información completa de estos tipos, al perfil del usuario y a un “top 10” con una lista de los diez usuarios que más objetos han encontrado y devuelto a sus propietarios.
Dada la estructura y posicionamiento de los elementos de la sección “Comunidad” se ha escogido la clase “Front page” para crear este tipo de contenido y sus sub-‐secciones.
El primer paso ha sido crear un nuevo contenido de tipo “Front page” con título “Comunidad” y añadiéndole la descripción correspondiente. Tal y como se muestra en la especificación de las plantillas, esta sección y sus sub-‐secciones se componen de dos áreas, una pequeña a la izquierda y otra grande, la central, a la derecha. El sistema eZ Publish permite escoger esta disposición, que denomina “2 zones layout 2”. Pretende indicar que se compone de dos zonas y que la segunda es la principal y por lo tanto la mayor.
De la misma manera que en la página principal se ha añadido el elemento automático nube de etiquetas en el bloque de la izquierda. El resto de componentes se han tenido que incluir modificando la correspondiente plantilla y creando nuevas.
Una vez creada la sección comunidad se ha creado un contenido de tipo “Front page” por cada sub-‐sección: “Mi cuenta”, “Mis aportaciones”, “Aportaciones de la comunidad” y “Top 10”. Cada una con su título y descripción correspondiente. El resto de elementos se han añadido creando nuevas plantillas, que se expondrán más adelante.
4.10 Desarrollo del menú, cabecera y pie de página
Como ya se ha comentado anteriormente, el sistema eZ Publish muestra automáticamente una opción en el menú principal por cada sección creada, dependiendo de los permisos del usuario que está actualmente en curso. Si por ejemplo, se desea que un usuario visitante no pueda visualizar la sección “Comunidad”, hay que omitir este permiso del rol “Anonymous” del sistema eZ Publish y así no se mostrará tampoco la opción en el menú.
En el caso del sistema que se ha creado, el menú principal es peculiar y rompe con esta regla estándar, por lo tanto se han tenido que hacer ajustes. A pesar de que solo los usuarios identificados con una cuenta, puedan visualizar la sección “Comunidad”, se desea que también los usuarios visitantes puedan ver la opción en el menú principal, para que sepan que existe esta sección. La solución que se ha llevado a cabo ha sido la de otorgar permisos de visualización de esta sección, a todos los roles de usuarios, de esta manera la opción de menú se hace visible a su vez. Para conservar la restricción en la que los usuarios visitantes no pueden acceder a la sección, se ha editado el código añadiendo un control al pulsar el enlace.
<div id=”ezflb-‐map-‐{$o_Gmap.id}”></div>
98
Teniendo en cuenta el funcionamiento automático de generación de opciones de menú del sistema eZ Publish, es lógico pensar que automáticamente deben haber aparecido varias opciones más por cada contenido que se ha creado “¿Qué es BCN Look & Find?”, “Preguntas más frecuentes”, “Regístrate” e incluso los contenedores de objetos perdidos y encontrados. Para excluir estos nodos se ha modificado la plantilla que construye el menú principal.
Hay que recordar que el enlace a la sección “Regístrate” se ha añadido en el encabezado de página. Para ello se ha modificado la plantilla correspondiente.
El resto de enlaces no tan importantes como para incluirse en el menú principal, pero obligadas a ser accesibles, han sido situados en el pie de página. Las secciones cuyos enlaces corresponden son:
• ¿Qué es BCN Look & Find? Enlazada por Sobre nosotros. • Preguntas más frecuentes. Enlazada por FAQ. • Contacta con nosotros. • Condiciones de uso. • Política de privacidad.
Para ello se ha modificado la plantilla correspondiente.
Además se ha añadido un enlace al mapa del sitio que el sistema construye automáticamente según la ubicación y los permisos de las secciones creadas. De la misma manera que el menú principal ha sido necesario excluir algunas opciones e incluir otras.
Como puede observarse en los modelos de plantillas especificados en la Sección 3.9.1, el menú principal contiene dos opciones más, “BCN y alrededores” y “Añadir objeto”, que realmente no corresponden a secciones, por lo tanto el sistema eZ Publish no puede crear automáticamente. Así que se han añadido editando el código de la plantilla que muestra el menú. El desplegable que muestra los tipos de objeto a registrar que aparece al situar el cursor sobre la opción “Añadir objeto” se ha desarrollando utilizando “JavaScript” (13) y una librería JQuery (17) cargada directamente desde su sitio web, en vez de descargarlas e incluirlas en el código. Se ha enlazado la siguiente librería
http://cdn.jquerytools.org/1.2.5/full/jquery.tools.min.js
desde la plantilla que construye la estructura del sitio web, ha sido suficiente para obtener todos los recursos necesarios para desarrollar los elementos del sitio web.
4.11 Extensión de diseño del sistema eZ Publish
El amplio sistema eZ Publish permite crear una estructura de contenido estándar, pero no dispone de algunas funcionalidades, aspectos de diseño, etc., muy concretas del sistema BCN Look & Find. Por lo tanto, es necesario extenderlo. Para ello se ha seguido el estándar del “framework” eZ Publish y se ha desarrollado un módulo conocido como “extension”. Para desarrollar las extensiones se ha utilizado el tutorial Tutorial Introducción en el desarrollo de extensiones en eZ Publish (40).
99
4.11.1 Estructura de directorios
El primer paso para desarrollado una nueva extensión es crear la siguiente estructura de directorios dentro del directorio “extensión”.
Ilustración 20, Estructura de directorios extensión de diseño
Como el resto de extensiones por defecto, se ha creado un directorio con el nombre de la extensión “bcnlfdesign”. Dentro de este directorio se crean los directorios “design” que contendrá las plantillas, archivos CSS, JS, etc. y “settings” donde se establece la configuración.
4.11.2 Configuración
Dentro del directorio “settings” se han añadido dos ficheros de configuración “design.ini.append.php” y “module.ini.append.php”.
El fichero “design.ini.append.php” indica al sistema que dentro de esta extensión hay ficheros de diseño. De esta manera además de crear nuevas plantillas, estilos, etc., se puede sobrescribir cualquier otro fichero de diseño (CSS, TPL, JS, etc.), que tenga el mismo nombre.
El fichero “module.ini.append.php” indica al sistema que en este directorio se encuentra una extensión.
4.11.3 Diseño de la extensión
Como ya se ha comentado anteriormente el sistema eZ Publish comenzará a buscar elementos de diseño en los directorios con el nombre “design” de cada una de las extensiones activadas. Si no encuentra el elemento lo busca en el directorio “design” por defecto. Por supuesto, en un nivel más prioritario están las reglas de sobrescritura. Cada vez que se decide sobrescribir una plantilla, el sistema crea una regla de sobrescritura en el directorio de configuración correspondiente. En el caso del sistema BCN Look & Find, este fichero está ubicado en el siguiente directorio.
“…/settings/siteaccess/plain_site/override.ini.append.php”.
100
El sistema eZ Publish ubica la configuración general en el directorio con el nombre “plain_site” por defecto. Este nombre puede modificarse en el momento de la instalación. A su vez, si al instalar el sistema se han seleccionado diversos paquetes de idiomas para construir el sitio web, aparecerá un directorio por cada idioma. En el caso de BCN Look & Find, aparecen los directorios “esl” y “cat”. Si se desea crear una regla de sobrescritura o modificar cualquier otra configuración de manera específica para un solo idioma, se deberán modificar los ficheros de configuración contenidos en el directorio del idioma correspondiente.
En algunos casos ya comentados anteriormente se ha decidido utilizar reglas de sobrescritura para modificar plantillas por defecto, pero en la mayoría de casos se ha utilizado la nueva extensión de diseño.
Para utilizar la nueva extensión de diseño es tan simple como replicar la estructura de directorios donde se ubica la plantilla que se quiere sobrescribir y crear la plantilla con el mismo nombre. Por ejemplo una de las plantillas modificadas ha sido la que muestra la cabecera del sitio web.
En la mayoría de casos en que los cambios en la plantilla son mínimos, se ha copiado la plantilla por defecto y posteriormente se ha modificado el código.
El caso es el mismo para imágenes, ficheros de diseño CSS, JavaScript, etc.
Por supuesto no se van a explicar todas las modificaciones que se han efectuado en las plantillas para obtener el resultado actual del sitio web, pero si se comentarán algunas, para que sea posible hacerse una idea del trabajo llevado a cabo. Un buen ejemplo es el desarrollo de la página principal.
Diseño de la página principal
Como ya se comentado anteriormente en la Sección 4, la página principal ya está creada por defecto utilizando el tipo de contenido “Front page”. Este tipo de contenido acaba cargando la plantilla de la extensión “ezflow” correspondiente.
Esta plantilla se divide en dos zonas cuyas reglas de diseño CSS definen su posición, de manera que el resultado es una zona central y una pequeña zona en la parte derecha. El código de la plantilla simplemente carga los bloques que han sido incluidos en ambas zonas a partir de unas variables genéricas que han sido asignadas a la plantilla.
Como puede verse en este fragmento de código, se crea un bucle que obtiene cada uno de los bloques $block de la zona correspondiente dentro del conjunto $zones[].
Se han incluido nuevas plantillas. En la zona central se ha cargado la nueva plantilla “objects_list.tpl” y en la zona de la derecha se han cargado las nuevas plantillas “total_returned.tpl”, “category_list.tpl” y “last_returned.tpl”, utilizando la siguiente instrucción.
{foreach $zones[$i].blocks as $block}
101
En la posición donde se encuentra parameter pueden incluirse varias variables que se cargarán en la plantilla.
La plantilla “objects_list.tpl” es la encargada de mostrar la lista de objetos, el mapa, los filtros de búsqueda y el “paginador”. En la parte superior se han añadido los botones de filtros que no son más que referencias a la misma sección pero incluyendo unos parámetros que se utilizarán para saber qué tipo de objetos se deben mostrar.
Ilustración 21, Filtros de búsqueda de objetos
Las URL tienen este aspecto.
“…/(center_filter)/458/(object_filter)/167/(category_filter)/269/(oldpage)/1/(newpage)/1”.
• El parámetro “center_filter” indica el identificador del centro del que se van a mostrar los objetos.
• El parámetro “object_filter” indica el identificador del tipo de objeto que se va a mostrar (perdido o encontrado).
• El parámetro “category_filter” indica el identificador de la categoría a la que pertenecen los objetos que se van a mostrar.
• El parámetro “oldpage” indica cuál era la página anteriormente mostrada. • El parámetro “newpage” indica la página que se está mostrando.
Para la creación del selector de centros se ha incluido una nueva plantilla donde se hace una consulta de los centros registrados en el sistema y se construye posteriormente el selector mostrado en la imagen anterior.
Cada vez que el usuario selecciona un centro del selector y teniendo en cuenta el resto de filtros, el sitio web hace una llamada a una URL como la anteriormente mostrada. El valor de los parámetros de la llamada es recogido para hacer una posterior consulta de los correspondientes objetos a mostrar.
Para hacer una consulta desde plantillas TPL de información guardada en base de datos se utiliza la instrucción del motor de eZ Publish, “fetch”. A continuación se adjunta el fragmento de código TPL que obtiene la información de los objetos teniendo en cuenta los filtros que el usuario ha escogido.
{include uri = ’design:category_list.tpl’ parameter = ‘value’}
102
Esta consulta fetch devuelve todos los contenidos ‘content’, ‘list’, cuyo nodo padre ‘parent_node_id’ es el contendor de objetos perdidos o encontrados array($i_lost, $i_found), ordenados por fecha de publicación ‘sort_by’, array(‘published’, false()), que han sido registrados por el centro indicado $i_center que pertenecen a la categoría indicada $i_category, con límite $i_limit, comenzando por la posición $i_offset.
Esta consulta elaborada utilizando código TPL del motor eZ Publish, será convertida por las correspondientes librerías PHP a una consulta directamente a base de datos. Obteniendo así el conjunto de objetos especificados en la variable $st_objects.
Por cada objeto guardado dentro de dicha variable se hará una llamada a una nueva plantilla “object.tpl” que es la encargada de ordenar y mostrar los datos obtenidos del objeto. Dependiendo de las características del objeto y del usuario se mostrarán unos datos u otros y de una manera u otra. Por ejemplo si el objeto es de tipo encontrado, se encuentra en estado perdido y el usuario que lo está visualizando no es quién lo ha añadido, se mostrará el botón “Es mío”. En la imagen que hay a continuación puede verse un ejemplo del resultado.
Ilustración 22, Resumen de objeto
Por supuesto se han tenido que modificar y añadir reglas de diseño en las hojas de estilo CSS. Los ficheros CSS que está utilizando el sistema de manera prioritaria son los del diseño “ezflow”. Estos ficheros son “core.css”, “ezflow.css” y “pagelayout.css” y se han copiado en el directorio de la nueva extensión de diseño, para así modificarlos conservando los originales.
También se han añadido nuevas imágenes como las de los estados de objeto, bocadillos de ayuda, etc.
{set $st_objects = fetch(‘content’, ‘list’, hash(
‘parent_node_id’, array($i_lost, $i_found),
‘sort_by’, array(‘published’, false()),
‘attribute_filter’, array(array(‘owner’, ‘=’, $i_center)),
‘attribute_filter’, array(array(
array(‘found_object/category’, ‘=’, $i_category)),
‘attribute_filter’ array(array(
array(‘lost_object/category’, ‘=’, $i_category)),
‘offset’, $i_offset,
‘limit’, $i_limit))}
103
De la misma manera que la lista de objetos del área central de la página principal se ha creado la plantilla con la lista de categorías del área derecha. Como ya se ha comentado anteriormente en la Sección 4.5, las categorías son contenidos del sistema ubicados en un apartado de la sección de administración, por lo tanto para obtener su información hay que hacer una consulta de los elementos contenidos en esa sección utilizando el método “fetch”, tal y como se ha hecho para los objetos. Cada una de las categorías está formada por una etiqueta “<a>” de HTML con una referencia a la URL antes mencionada, modificando el parámetro “category_filter” por el identificador de la categoría.
El código de las plantillas TPL, como ya se ha dicho, está formado por HTML y el leguaje del motor de plantillas definido por el “framework” de eZ Publish. Un ejemplo de la combinación de ambos es la construcción de cada una de las categorías.
En el fragmento de código anterior se diferencia el código HTML por su color azul y el código TPL por su color negro. Como puede verse, la URL se construye concatenando el nombre de las variables, con el contenido de las variables que definen los parámetros, como $i_category. href={concat(‘…/(category_filter)/’, $i_category, ‘/…’)|ezurl()}. Para que eZ Publish construya la URL en el formato correcto se añade al final la instrucción ezurl().
Como se ha comentado, este fragmento de código construye cada una de las categorías tal y como se muestra en la siguiente imagen.
Ilustración 23, Categoría de objeto
4.12 Extensión funcional del sistema eZ Publish
Como ya se ha comentado en la sección anterior, el sistema eZ Publish dispone de unas funcionalidades estándar que no satisfacen totalmente los requerimientos del sistema BCN Look & Find. Añadir botones como “Es mío”, “Lo he encontrado”, “Cancelar búsqueda”, etc., es sencillo de desarrollar sobre las correspondientes plantillas TPL, pero los procesos que estos botones conllevan son muy específicos (cambios de estado, envío de mensajes de correo electrónico, etc.). Así que de la misma manera que la extensión de diseño ya expuesta
<a class=”category”
href={concat(‘…/(category_filter)/’, $i_category, ‘/…’)|ezurl()}>
<h3>
<span class=”image”>{$o_image}</span>
<span class=”title”>{$s_title}</span>
<span class=”description”>{$s_description}</span>
</h3>
</a>
104
anteriormente, se ha creado una extensión funcional siguiendo el estándar del “framework” de eZ Publish.
4.12.1 Estructura de directorios
El primer paso para desarrollar una nueva extensión es crear la siguiente estructura de directorios dentro del directorio “extension”.
Ilustración 24, Estructura de directorios de extensión funcional
Como el resto de extensiones por defecto y como en la extensión de diseño ya expuesta, se ha creado un directorio con el nombre de la extensión “bcnlfextension”, con sus respectivos subdirectorios, ficheros de configuración, etc.
4.12.2 Módulos
En el directorio “modules” es donde se deben desarrollar las funcionalidades. Para cada módulo se debe crear un directorio con un archivo “module.php” y otro archivo con un “script” PHP por cada funcionalidad a desarrollar.
El archivo “module.php” define la estructura del módulo. Qué acciones posee, qué “script” debe ejecutar para cada una de ellas, qué parámetros reciben, etc.
Los “scripts” PHP contienen el código que se desea ejecutar en cada acción. Para ejecutar una acción se debe hacer mediante una llamada POST o GET directamente introduciendo la URL o desde una plantilla de diseño TPL. Por ejemplo, si se quiere acceder a la funcionalidad de registro de usuarios, hay que ejecutar la acción (“script”) “register” del módulo “user”, con unos parámetros enviados por POST, por lo tanto sobre la plantilla donde se quiere ejecutar esta acción habrá que crear un formulario que envié la petición a la siguiente URL.
“…/user/register/”.
105
Si en el archivo “module.php” está definida correctamente la estructura del módulo se acabará ejecutando el “script” “register.php” con los parámetros enviados.
Se han desarrollado tres módulos. “bcnlfuser”, “finder” y “owner”.
Módulo bcnlfuser
Este módulo pretender ampliar las acciones definidas en el módulo “user” por defecto. Las funcionalidades que se han desarrollado son las siguientes.
• Auto-‐identificación del usuario en el sistema cuando pulsa cualquier URL adjunta en los mensajes de correo electrónico personales que se le envían. Acción “autologin”.
• Redirección del usuario después de su identificación a otras acciones que requieren parámetros mediante POST. El sistema por defecto permite indicar la URL a la que será redirigido el usuario cuando se identifica, pero no permite ejecutar acciones con parámetros POST. En el caso del sistema BCN Look & Find es necesario si se quiere redireccionar al usuario a los formularios de registro de objetos, después de identificarse, tras haber intentado acceder sin estarlo. Acción “redirect”.
Primero se ha creado el fichero “module.php” definiendo las dos acciones y los parámetros que reciben cada una de ellas.
La llamada a la acción de auto-‐identificación se realizará de la siguiente manera.
“…/bcnlfuser/autologin/[parámetro1]/[parámetro2]/[parámetro3]”.
El primer parámetro contiene el nombre que identifica en el sistema al usuario que se va a auto-‐identificar. El segundo parámetro contiene el identificador “hash” del objeto que representa el usuario en el sistema y el tercer parámetro será el identificador del nodo que se quiere mostrar al usuario después de la identificación.
La llamada a la acción de redirección se realizará de la siguiente manera.
“…/bcnlfuser/redirect/[parámetro1]/[parámetro2]/[parámetro3]”.
El primer parámetro contiene el tipo de contenido que el usuario pretendía crear antes de que el sistema pidiera su identificación. En el caso del sistema BCN Look & Find es objeto perdido (lost_object) o objeto encontrado (found_object). El segundo parámetro es el identificador del nodo que contendrá el contenido creado. Y por último, el tercer parámetro contendrá el código del idioma en el que se va a crear el contenido. Estos tres parámetros son los que utiliza la acción para crear contenido por defecto de eZ Publish (“action/content”).
El archivo “autologin.php” es sencillo. Buscará el usuario con el nombre de identificación contenido en el primer parámetro. Comprobará si el identificador hash del objeto que lo representa corresponde con el del segundo parámetro. Si es así, lo identificará y lo redireccionará a la acción por defecto que muestra el contenido del nodo correspondiente con el identificador del parámetro tres. En el caso del sistema BCN Look & Find normalmente se estará redireccionando a la información de algún objeto o usuario.
106
El archivo “redirect.php” también es sencillo. Simplemente ejecutará la acción para crear contenido de eZ Publish.
“.../content/edit/[parámetro4]/[parámetro5]”.
El cuarto parámetro es el identificador numérico del tipo de contenido a crear, se obtendrá a partir del nombre del contenido. El quinto parámetro es la versión del contenido. Es este caso 1. Podría llamarse directamente a esta acción desde la plantilla, pero el sistema eZ Publish está creado para que previamente se cree un objeto (contenido) vacío y después se complete mediante un formulario. Por lo tanto es necesario un paso intermedio que cree este objeto vacío.
Módulos finder y owner
El módulo “finder” se ha creado para albergar todas las funcionalidades involucradas en el proceso de devolución de un objeto de tipo perdido registrado en el sistema. Se han desarrollado las siguientes funcionalidades.
• Cancelar la búsqueda de un objeto perdido registrado en el sistema. Esta funcionalidad solo está disponible, a nivel de plantilla, para el usuario que ha registrado el objeto y siempre y cuando el objeto esté en estado perdido. Acción “cancel”.
• Marcar objeto como encontrado. Estando el objeto también en estado perdido, para el resto de usuarios está disponible la funcionalidad a nivel de plantilla. Acción “find”.
• Confirmar devolución del objeto. Esta funcionalidad solo está disponible, a nivel de plantilla, para el usuario que ha registrado el objeto y siempre y cuando el objeto esté en estado pendiente. Acción “confirm”.
• Descartar devolución del objeto. Esta funcionalidad está disponible en las mismas circunstancias que la de confirmar devolución. Acción “discard”.
• Mostrar una plantilla de confirmación tras añadir o editar un objeto perdido. Acción “lost”.
Como ya se ha hecho en otros módulos, primero se ha creado el fichero “module.php”.
Las llamadas a las acciones correspondientes a este módulo se harán tal y como se ha comentado anteriormente con la diferencia que en este caso se les pasarán como parámetros únicamente el identificador numérico del objeto y la versión.
El archivo “cancel.php” busca el objeto perdido con el identificador del parámetro uno y la versión del parámetro dos y actualiza su estado a devuelto.
El archivo “find.php” busca el objeto perdido con el identificador del parámetro uno y la versión del parámetro dos y actualiza su estado a pendiente. Para poder tener presente qué usuario ha marcado el objeto, se enviará el identificador el usuario en curso por POST. El “script” recogerá esta variable y la guardará en el campo “finder_id_temp” del objeto perdido. Por el momento no es seguro que este usuario haya encontrado realmente el objeto así que se guarda en “finder_id” hasta que el propietario confirme la devolución. Por último carga la plantilla correspondiente.
107
El siguiente paso del proceso es la confirmación o descarte de la devolución del objeto.
En el caso que el propietario del objeto decida confirmar la devolución se hará una llamada a la acción “confirm.php” que buscará el objeto correspondiente y actualizará su estado a devuelto. Además moverá el identificador del usuario que ha encontrado el objeto del campo “finder_id_temp” a “finder_id” ya que la devolución ha sido confirmada. Por último carga la plantilla correspondiente.
En el caso contrario, el usuario hará una llamada a la acción descartar devolución “discard.php” de la misma manera que la de confirmación.
La última funcionalidad del módulo se carga cada vez que el usuario modifica o añade un objeto perdido. El “script” “lost.php” busca el objeto con el identificador del primer parámetro. Si la versión contenida en el segundo parámetro es uno carga la plantilla en la que se informa al usuario que el objeto ha sido registrado correctamente. Si por el contrario la versión es mayor que uno, entonces carga la plantilla en la que se informa al usuario que el objeto ha sido editado correctamente.
El módulo “owner” es similar al módulo “finder”, pero en este caso alberga todas las funcionalidades del proceso por el que pasa un objeto de tipo encontrado desde que es registrado hasta que se confirma la entrega a su propietario. Puesto que sus funcionalidades, acciones y “scripts” son prácticamente iguales no es necesario describir el funcionamiento de este módulo.
4.12.3 Diseño de la extensión
Como ya se ha comentado antes el sistema sobrescribe cualquier fichero de diseño que encuentre con el mismo nombre que el fichero que se añada en este directorio. Por ejemplo si se quiere sobrescribir la plantilla que se muestra al registrar un usuario
Hay que crear la misma estructura de directorios dentro del directorio de diseño de la extensión y después modificar la plantilla TPL como se desee.
En este caso no interesa sobrescribir ninguna plantilla sino crear nuevas.
En el directorio “design” de la extensión se ha creado el subdirectorio “standard”. Se ha escogido este nombre para respetar la nomenclatura por defecto de eZ Publish. Dentro se ha creado el directorio “templates”. Para diferenciar las plantillas de cada módulo se han creado subdirectorios con el nombre de los módulos.
El directorio “finder” contiene las plantillas TPL del módulo “finder”.
• La plantilla “cancel.tpl” se muestra tras ejecutar el código de “cancel.php”. Informa al usuario que la búsqueda de su objeto perdido ha sido cancelada y su objeto ha pasado a estado devuelto.
108
• La plantilla “find.tpl” se muestra tras ejecutar el código de “find.php”. Informa al usuario que se ha marcado el objeto como posiblemente encontrado y que se ha enviado un mensaje de correo electrónico al usuario que ha registrado el objeto.
• La plantilla “finderinfo_email.tpl” codifica el mensaje de correo electrónico que se envía tras ejecutar el código de “find.php”. Éste le envía los datos necesarios para construir enlaces, nombres de usuarios, objetos, etc.
• La plantilla “confirm.tpl” se muestra tras ejecutar el código de “confirm.php”. Informa al usuario que la devolución del objeto perdido que ha registrado ha sido confirmada y por lo tanto el objeto ha pasado a estado devuelto.
• La plantilla “discard.tpl” se muestra tras ejecutar el código de “discard.php”. Informa al usuario que la devolución del objeto perdido que ha registrado ha sido descartada y por lo tanto ha vuelto a estado perdido.
El directorio “owner” contiene las plantillas TPL del módulo “owner”. Éstas son similares a las del directorio “finder”.
4.13 Posicionamiento del sitio web y otros desarrollos
En esta sección se pretende describir muy brevemente qué se ha llevado a cabo para mejorar el posicionamiento SEO en el sitio web y otros desarrollos, como la inclusión del módulo de Facebook (41).
Durante el desarrollo del sistema se han tenido en cuenta algunos aspectos para mejorar el posicionamiento SEO del sitio web en buscadores, sobretodo en Google. A continuación se describen algunos de ellos.
Etiquetación del contenido siguiendo una jerarquía según su importancia. En el lenguaje de programación (11) HTML existen unas etiquetas para definir cabeceras <h1>, <h2>, <h3>, etc. A parte de modificar el tamaño y el grosor del texto que se encuentra dentro de estas etiquetas, los algoritmos de búsqueda de los buscadores las utilizan para indexar el contenido y asignarles una importancia. Para los títulos de las secciones se ha utilizado la etiqueta <h1> de mayor importancia. Cuando el usuario accede a la información completa del objeto, la sección se titula con el nombre del objeto dentro de la etiqueta <h1> también. De esta manera los buscadores indexarán cada uno de los objetos registrados en el sistema. En el caso de las categorías se ha utilizado la etiqueta <h2>, ya que no tienen la misma importancia que los objetos y las secciones, pero igualmente es una ventaja que los buscadores las indexen.
Modificar el código de la cabecera para que disponga de un título distinto según la sección que se está visualizando. Las páginas HTML se dividen en cabecera <header> y cuerpo <body>. Dentro de la etiqueta <header> se pueden añadir distintas etiquetas que almacenan algunos datos del sitio web. Una de las etiquetas más importantes y que los algoritmos de búsqueda de los buscadores tienen en cuenta es la etiqueta <title>. El sistema eZ Publish construye esta etiqueta dinámicamente con el título de la sección que se está visualizando, de esta manera favorece que los buscadores indexen las diferentes secciones del sitio web.
109
Agregar etiquetas “meta” en cabecera con descripciones y palabras clave del sitio web. Como se ha comentado anteriormente en la cabecera de una página HTML se pueden incluir diferentes etiquetas con datos del sitio web. Para añadir descripciones se ha añadido la etiqueta <meta content=”…” name=”description”>, que añade descripciones al sitio web situadas en el atributo “content”. Los buscadores indexarán cualquier descripción de esta etiqueta y la mostrará en los resultados de búsqueda como descripciones del sitio web. De la misma manera se han añadido palabras clave, añadiendo la etiqueta <meta content=”…” name=”keywords”>. Las palabras que se introduzcan aquí serán indexadas por los buscadores de manera que si por ejemplo un usuario busca la palabra “objeto” en Google y esta palabra está contenida en la etiqueta, el sitio web tendrá más posibilidades de ser mostrado en los resultados.
Para que Google comience a recopilar información del sitio web y así mejorar su posicionamiento, se ha utilizado una aplicación web que Google suministra llamada Webmasters (42). Para poder utilizar las herramientas de esta aplicación primero ha sido necesario crear una cuenta de Google para el sitio web. El siguiente paso ha sido el de registrar la URL del sitio web y su ubicación geográfica (país). Una vez hecho esto Google comienza a recopilar información del sitio web y a mejorar su posicionamiento de manera automática. Además se disponen de datos estadísticos y otras herramientas, como por ejemplo se le puede indicar la ubicación de un mapa del sitio que Google analizará y realizará sus posteriores búsquedas según las indicaciones de este fichero.
Un mapa de un sitio web es un documento XML compuesto por etiquetas que definen las URL de las diferentes secciones del sitio, que se quiere que los buscadores indexen. Para crear el mapa del sitio (sitemap.xml) se ha utilizado la documentación seowebconsultor.com (43).
Para mejorar la experiencia de usuario en el sitio web, fomentar su uso y también para mejorar su posicionamiento web, se ha decidido crear una página en Facebook (44). Facebook proporciona diferentes módulos para incorporar en el sitio web, entre ellos uno muy interesante que se ha decidido incorporar. Este módulo muestra, si el usuario tiene sesión abierta en Facebook, algunos de los amigos que tiene agregados en su cuenta y que han marcado la opción “me gusta” en la página de Facebook del sitio web, si el usuario no tiene sesión abierta muestra de manera aleatoria algunos de los usuarios que les gusta el sitio web. Además pueden acceder directamente a su cuenta o a dicha página y por supuesto marcar el sitio web con “me gusta”. Esta funcionalidad es interesante ya que crea una vinculación entre una poderosa red social como es Facebook y el sitio web BCN Look & Find. Además de captar nuevos usuarios, mejora su posicionamiento. Su desarrollo ha sido sencillo, ya que Facebook proporciona el código exacto que hay que copiar y pegar en BCN Look & Find, simplemente ha sido necesario ajustar su tamaño para incorporarlo en la estructura del sitio web.
110
5 Experimentación
Durante el desarrollo del sistema se han ido efectuado pruebas funcionales y de usabilidad. Algunas de las pruebas se han efectuado con usuarios reales ya que al fin y al cabo son quienes finalmente van a utilizar el producto final. Para ello se ha intentado hacer una selección de diferentes tipos de usuario, usuarios más técnicos e integrados en el mundo de la informática, usuarios más genéricos e incluso usuarios cuya experiencia con Internet es limitada.
Ha sido necesario dar pasos atrás constantemente en el desarrollo y parte de la especificación del proyecto teniendo en cuenta dichas pruebas, comentarios y opiniones de usuarios, tanto para reparar errores, como para mejorar aspectos funcionales, de diseño y usabilidad. Por ejemplo la localización de los filtros de búsqueda y las opciones del menú principal han sido un punto crítico en la usabilidad del sitio web.
5.1 Pruebas de usuario
En esta sección se describen los perfiles de algunos de los usuarios que han llevado a cabo pruebas del producto. Cuáles han sido algunas de sus conclusiones y qué soluciones se han llevado a cabo o se proponen para solucionar los problemas encontrados.
Las opiniones de este tipo de usuario, en parte, son de las más valiosas, ya que al fin y al cabo, abarcan la mayoría de usuarios que utilizarán el sitio web. A continuación se muestran algunas de las aportaciones de usuarios con este perfil.
✖ El usuario reporta que no hay ninguna manera de recuperar la contraseña cuando ésta es olvidada.
✔ Para solucionar este problema eZ Publish ya dispone de dicha funcionalidad. Simplemente se ha añadido el enlace con el nombre “¿Has olvidado la contraseña?” en el bloque de identificación de usuario.
✖ El usuario reporta que el acceso al perfil personal está demasiado escondido.
✔ Para solucionar este problema se ha añadido un enlace al perfil del usuario en la parte superior derecha de la cabecera, junto al enlace para cerrar la sesión de usuario.
111
Estos usuarios aportan un punto de vista más técnico a las pruebas del desarrollo.
✖ El usuario reporta que el botón para cambiar la contraseña, ubicado en el perfil del usuario, está demasiado escondido.
✔ Para solucionar este problema se ha movido el botón a la cabecera, junto con el botón de editar datos del perfil. También se ha añadido un icono representativo.
✖ El usuario reporta que el nombre para acceder a los datos de la cuenta personal del usuario “Mi cuenta”, no es el mas indicado.
✔ Teniendo en cuenta otros sitios web, sobre todo redes sociales, se ha decidido cambiar el nombre de “Mi cuenta” a “Mi perfil”.
Este perfil de usuario es el más indicado para opinar sobre el tema de la gestión de objetos perdidos registrados por usuarios de tipo centro. A continuación se describen algunas de las aportaciones de usuarios con este perfil.
✖ El usuario reporta que normalmente los usuarios no registran objetos perdidos de la categoría documentación. Es mucho más factible entregarlos personalmente o depositarlas en centros como comisarías de policía u oficinas de administración pública. Aunque el usuario decidiera registrar un objeto de tipo documentación se desconoce hasta que punto sería seguro revelar información personal del usuario propietario de la documentación.
A priori es lógico que cuando un usuario encuentre documentación del tipo DNI, carnet de conducir, tarjetas de crédito, prefiera entregarlos en persona en el domicilio especificado en la
112
documentación, si la hubiera, o en una comisaría de policía. A pesar de ello y teniendo en cuenta que suele ser un tipo de objeto que suele perderse frecuentemente, es necesario incorporar esta categoría. Hay que tener en cuenta que esta categoría puede englobar muchos tipos de documentos que no necesariamente tienen que contener datos personales.
✔ Una medida que se ha tomado es la de añadir mensajes de aviso que indiquen al usuario que él es el único responsable del registro de datos personales.
✔ Otra manera de evitar que los usuarios registren datos personales de otros al registrar un objeto de la categoría documentación, sería el de crear nuevos campos en el formulario que aparecieran solo en el caso de que el usuario seleccionara la categoría documentación. Para controlar los datos a introducir, primero se le obligaría a seleccionar qué tipo de documentación va a registrar y posteriormente permitirle añadir algún tipo de dato relacionado que no rompiera la privacidad del propietario. Dado el coste de esta posible solución no se ha desarrollado, pero se ha planteado como posible extensión futura.
5.2 Encuestas
En otros casos se ha recurrido a encuestas previas a los usuarios para que ellos mismos decidieran el resultado. Uno de los casos ha sido el de la elección del nombre de los filtros de búsqueda de objetos por tipo (“Objetos para localizar” y “Objetos para devolver”). Puesto que ambos tipos de objeto son al fin y al cabo objetos perdidos los nombres seleccionados inicialmente (“Objetos perdidos” y “Objetos encontrados”), podían provocar confusiones, así que se han propuesto varias opciones más la posibilidad de proponer nuevas alternativas. Tras la votación de unos siete usuarios, a los cuales se les agradece su colaboración, se han escogido los nombres actualmente en el sitio web. Estos han sido las propuestas y los resultados.
Tipo perdido Tipo encontrado Votos
Han perdido Se han encontrado 0
Objetos para localizar Objetos para devolver 3
Propietarios buscan objetos Objetos buscan propietarios 0
Encontré Perdí 1
Se buscan objetos Se buscan propietarios 0
Encontré objeto Busco objeto 2
Objetos que han sido perdidos Objetos que han sido encontrados 1
Tabla 2, Encuesta
113
6 Gestión del proyecto
En esta sección se expone el seguimiento y gestión del proyecto, tiempo empleado, costes, etc.
6.1 Estimación inicial
En primer lugar se expone la estimación inicial de la duración del proyecto, representada en el diagrama Diagrama 17, Gantt estimado, que se muestra a continuación.
Diagrama 17, Gantt estimado
Como puede verse en este diagrama se ha desglosado la elaboración del proyecto tareas genéricas. Para cada una de estas tareas se indica la duración en semanas, representada por una franja de color azul. Cada columna denominada por una “S” y un valor numérico indica la semana en la estima llevar a cabo esa tarea. A continuación se muestran las tareas en las que se ha dividido el proyecto y cuanto tiempo (semanas) se estima que durarán. Algunas tareas se han desarrollado paralelamente, esto se representa solapando las franjas de color azul.
• Análisis de otros sitios web 2 semanas. Teniendo en cuenta la documentación correspondiente, se estiman 1,5 semanas.
• Estudio de sistemas de gestión de contenido 2 semanas. • Especificación del sistema 5 semanas. • Estudio del sistema de gestión de contenido escogido 4 semanas. Teniendo en cuenta
que al mismo tiempo se lleva a cabo la tarea de especificación y se comienza el desarrollo con su correspondiente documentación, se estima 1 semana.
• Desarrollo del sistema 9 semanas. Teniendo en cuenta los solapamientos de otras tareas se contabilizan realmente 8 semanas.
o Creación de contenido 3 semanas. o Edición y creación de plantillas 3 semanas. o Desarrollo de extensiones 2 semanas.
• Implantación del sistema en un servidor público. Esta tarea se realizará en 3 puntos diferentes del desarrollo y se estima que en total implicará 5 horas.
• Experimentación 1 semana. • Documentación 9 semanas. Teniendo en cuenta que, en la práctica, esta tarea se lleva
a cabo de manera parcial durante el transcurso del resto de las tareas, se estima que realmente requerirá 2 semanas de dedicación neta para depurar y completar la memoria.
114
Cada una de las semanas del diagrama, están compuestas por 20 horas laborables. Teniendo en cuenta la normativa de PFC de la FIB, un proyecto de ingeniería técnica en informática como éste, está valorado en 22,5 créditos, con una carga de trabajo de 20 horas por crédito. La duración inicial estimada del proyecto es de 460 horas. Estas horas son cubiertas a tiempo parcial, por lo tanto se prevé una duración de 4 meses.
A continuación se describe el tipo y la cantidad de recursos asignados a cada tarea, utilizando la tabla Tabla 3, Recursos estimados. Para las tareas que van a llevar a cabo más de un recurso, se dividen las horas asignadas a esa tarea entre los diferentes recursos. Se debe tener en cuenta que el proyecto es llevado a cabo por una sola persona que adopta todos los roles necesarios. Estos roles y sus costes por recurso son los siguientes.
• Analista 40 € por hora. • Diseñador 35 € por hora. • Desarrollador 25 € por hora.
Puesto que no ha sido posible encontrar una fuente fiable en Internet que indique el sueldo medio de cada tipo de recurso, se ha optado por tomar como fuente de información un profesional del campo. Estos sueldos han sido aconsejados por el CTO (Chief Technology Officer) del área de IT, de la empresa Privalia.
• En cada una de las tareas participa uno o varios recursos indicados en la columna “Recurso”.
• La cantidad de este recurso por unidad (personas), se indica en la columna “Cantidad”. • El número de semanas que cada recurso empleará en la tarea se indica en la columna
“Semanas”. • El número de horas que cada recurso empleará en la tarea, teniendo en cuenta que
cada semana dispone de 20 horas laborables, se indica en la columna “Horas”. • El precio por hora en euros € que cuesta cada recurso asignado en la tarea se indica en
la columna “Precio por hora”. • Por último se indica en la columna “Coste” el coste total del recurso en esa tarea
(Coste = Cantidad * Precio por hora * Horas).
Tabla 3, Recursos estimados
115
El coste total estimado para el proyecto se calcula sumando los costes totales de cada tarea y asciende a 15.025,00 €, como puede verse al final de la columna “Coste”.
6.2 Resultado final
La estimación se ha visto afectada por la duración real de cada una de las tareas, recursos reales asignados, etc. El diagrama Diagrama 18, Gantt real, que se muestra a continuación muestra la duración real del proyecto y las horas empleadas en cada una de las tareas.
Diagrama 18, Gantt real
Como puede verse, la duración real del proyecto ha sido más larga de la estimada inicialmente. Los 4 meses laborables estimados han pasado a ser 8 meses. Esto provoca un aumento de las horas asignadas a cada uno de los recursos y por lo tanto un aumento del coste total del proyecto.
El tiempo final empleado para cada una de las tareas es el siguiente.
• Análisis de otros sitios web 2 semanas. • Estudio de sistemas de gestión de contenido 2,5 semanas. • Especificación del sistema 8 semanas. • Estudio del CMS eZ Publish 12 semanas. Teniendo en cuenta que esta tarea se ha
llevado a cabo a la par con el desarrollo del sistema, solo se contabilizan 3 semanas. • Desarrollo del sistema 17 semanas. Teniendo en cuenta el solapamiento con otras
tareas finalmente se contabilizan 10 semanas, que se desglosan en las siguientes sub-‐tareas.
o Creación de contenido 2 semanas. o Edición y creación de plantillas 4 semanas. o Desarrollo de extensiones 3 semanas.
• Implantación del sistema en un servidor público 6 horas. • Experimentación 8 semanas. Realmente se han contabilizado 2 semanas. • Documentación 25 semanas. Como se ha comentado anteriormente, parte de la
documentación ha estado sumergida en la realización del resto de las tareas. Por lo tanto, realmente, ha requerido un total de 4 semanas de dedicación completa.
La causa de la desviación de respecto a la estimación se centra en las tareas de especificación del sistema, estudio del CMS eZ Publish y desarrollo del sistema. Como se ha comentado anteriormente el CMS seccionado, por razones expuestas en la Sección 2.3, requería un aprendizaje más costoso. Es por esta razón que su estudio a requerido de más tiempo y por lo tanto también ha implicado un incremento de horas de desarrollo.
116
La metodología ágil que se ha seguido para el desarrollo del sistema y sus consecutivas iteraciones, además de un incremento en el desarrollo, también han provocado un incremento de horas en la especificación del sistema.
Por supuesto un incremento del tiempo dedicado a estas tareas implica un incremento en la documentación.
Otras tareas como la experimentación también han contribuido en la desviación del tiempo estimado, pero en menor medida. En el caso de la experimentación se han llevado a cabo un mayor número de pruebas de usuario y esto también ha provocado iteraciones, incrementando el desarrollo.
La tarea de implantación finalmente se llevó a cabo en más puntos del desarrollo de los estimados, además su desempeño fue más costoso del esperado y por lo tanto requirió más tiempo. Otro factor que afectó a esta tarea fue la migración del sistema del servidor privado de la FIB al servidor público del LSI para llevar a cabo una fase de experimentación más completa. A pesar de ello, solo se ha contabilizado 1 hora más respecto a la estimación, ya que estas tareas de implantación se ha realizado durante el desarrollo del sistema.
En la tabla Tabla 4, Recursos reales, expuesta a continuación, se muestran las horas reales que ha costado cada recurso en cada una de las tareas. El formato de la tabla es el mismo que el antes expuesto.
Tabla 4, Recursos reales
De la misma manera que se ha calculado el coste total estimado de cada una de las tareas, se ha obtenido el coste total real de cada una de las tareas (Coste real = Cantidad * Precio por hora * Horas reales). Teniendo en cuenta el incremento de horas por tarea estos costes han ascendido de los reales.
Una vez obtenidos los costes reales de cada una de las tareas, se han sumado y obtenido así, el coste total real del proyecto que asciende a 19.750,00 €.
117
7 Conclusiones
Una vez desarrollado el sistema BCN Look & Find, después de haber experimentado con él y de haber llevado a cabo mejoras, arreglos, cambios y de evaluar los resultados obtenidos, pueden extraerse las siguientes conclusiones.
El propósito general del proyecto consistía en desarrollar una plataforma web con la finalidad de hacer de intermediario entre personas que pierden y encuentran objetos perdidos en la provincia de Barcelona y alrededores y facilitar a centros donde se depositan objetos perdidos, la labor de devolverlos a sus propietarios. Si se analiza el sitio web, actualmente en versión alfa ubicado en http://look-‐and-‐find.lsi.ucp.edu/, se puede afirmar que se ha cumplido el objetivo principal en su totalidad. El sistema contiene funcionalidades que permiten llevar a cabo el objetivo de permitir a usuarios interactuar con el sistema y ponerse en contacto entre ellos. Por supuesto también se han tenido muy en cuenta los defectos extraídos de los sitios web analizados y como puede verse no se dan en este sistema. Una de las aportaciones más importantes de este proyecto ha sido la incorporación de usuarios de tipo centro en este tipo de plataforma web, con el objetivo de facilitar a dichos centros que custodian objetos perdidos, devolverlos a sus propietarios. Puede verse que se han incluido funcionalidades que facilitan esta labor, a pesar de que no ha sido posible que pasen por una fase de experimentación profunda, tal y como se planificó inicialmente.
Respecto a conclusiones técnicas, el desarrollo del sistema BCN Look & Find sobre un gestor de contenidos ha sido mas complicado de lo esperado. El sistema eZ Publish seleccionado, aporta grandes ventajas respecto a otros CMS, como la libertad a la hora de crear nuevos tipos de contenido, con una gran diversidad de atributos. Por otra parte también conlleva desventajas como la gran complejidad del sistema y la necesidad de editar constantemente el código, entre otros. En conclusión eZ Publish es muy recomendable para usuarios avanzados, con el objetivo de construir una plataforma web con funcionalidades complejas que se salen de lo habitual en un sitio web implementado sobre un gestor de contenidos. Por otra parte la utilización de un gestor de contenidos en general, facilita la creación de la estructura de un sitio web de manera rápida, al menos cuando ya se conoce el funcionamiento del CMS. Y sobretodo facilita que otros usuarios puedan administrar el sitio web de manera fácil una vez terminado el desarrollo.
Como ya se ha comentado, se han cumplido los objetivos previstos inicialmente, a pesar de ello hay varios aspectos funcionales y de diseño, que ha sido necesario excluir de los requerimientos del proyecto por falta de tiempo, pero que podrían mejorar el sistema y reforzar el cumplimiento de dichos objetivos a la par de llegar a otros. Algunos de estos aspectos se describen como posibles extensiones futuras en la siguiente sección.
118
8 Propuestas de trabajo futuro
Cuando se inició el desarrollo del proyecto se planteó tratar los temas de personas desaparecidas y mascotas perdidas, pero en seguida nos dimos cuenta que eran temas demasiado delicados, que podían herir la sensibilidad de algunos usuarios y que por tanto merecían un tratamiento especial. El proponer soluciones para el tratamiento de estos temas es una posible e interesante extensión del sistema BCN Look & Find.
En discusiones iniciales y después de analizar otros sitios web, se observó que para que una plataforma como ésta fuera útil, debía abarcar un área geográfica bien delimitada, ya que a nivel mundial es un servicio que no tiene sentido. Sin embargo, es una extensión interesante que requiere de un análisis en el que se deben tener en cuenta varios aspectos funcionales y de usabilidad.
Es muy importante que a pesar de expandir el área a un país entero, las estadísticas, los usuarios, objetos, top ten y otros recursos del sitio web, continúen siendo útiles. Por ejemplo un top ten de usuarios de toda España no sería demasiado representativo, lo lógico sería aplicar la zona seleccionada por el usuario a todos los elementos del sitio a sobre los que pueda hacer uso. El sitio web Finder Base (25) expuesto anteriormente es un claro ejemplo de lo que no se debe hacer. Finder Base (25) generaliza todo el contenido del sitio web, de manera que muchas funcionalidades interesantes dejan de ser útiles para el usuario, como el top ten (mundial), el mapa del mundo de la página principal que marca la ubicación de todos los objetos registrados en el sito, etc.
Una buena manera de ubicar al usuario en una zona geográfica es la que utiliza el sitio web Megalost (26), también expuesto al inicio del documento. Inicialmente se muestra un mapa mundial al usuario sobre el que puede seleccionar un país, después una comunidad y por último una ciudad. Estos datos se guardan y la próxima vez que el usuario acceda al sitio web, se le ubicará en la zona anteriormente seleccionada. Una aplicación web que puede ser útil investigar es el conocido Google Maps (46). Google Maps detecta automáticamente la ubicación del usuario y siempre la muestra por defecto, pero en todo momento el usuario tiene la posibilidad de modificarla e incluso tener un registro de ubicaciones favoritas.
Este tipo de extensión lleva a pensar en una extensión mayor.
En mi opinión, no es recomendable expandir el área de actuación del sitio web a objetos de todo el mundo. Es posible que al intentar abarcar tanto territorio se pierda precisión y utilidad. Finder Base (25) es un ejemplo de ello, muchos de los objetos registrados llevan mucho tiempo y se ve poca interacción con el sitio web.
A pesar de ello si se tienen en cuenta algunos aspectos podría funcionar. Como ya se ha comentado en la extensión a otras ciudades, es necesario concretar en todo momento una ubicación tanto cuando el usuario busca o registra un objeto, como cuando está visualizando otros datos, siempre deben estar relacionados con una ubicación concreta.
119
Ya son muchos los sitios web de contactos que incluyen mensajería privada, como por ejemplo el conocido Facebook (41). Esta aplicación incluye la posibilidad de enviar mensajes privados sin necesidad de utilizar ningún tipo correo electrónico externo. Incluyendo esta funcionalidad en BCN Look & Find, facilitaría el contacto entre usuarios. Es lógico pensar que algunos usuarios pudieran llegar a escoger no utilizar el sitio web, por la necesidad de dar su dirección de correo electrónico y de que la forma de contactar con otros sea mediante esta forma de correo. Esta es una razón importante porque sería muy conveniente incluir esta extensión en un futuro.
Este tipo de extensión puede ir acompañada de otra no tan necesaria, pero interesante.
De la misma manera que la mensajería interna privada, se podría disponer de un chat. Esta extensión también facilitaría a los usuarios el contacto entre ellos y por lo tanto la devolución de un mayor número de objetos a sus propietarios.
A pesar de ser un complemento interesante, se deben tener en cuenta algunos aspectos. Para empezar no estamos hablando de un sitio web de amistades, contactos, etc., lo que quiere decir que se debe limitar la libertad de chatear con cualquier usuario. Cuando un usuario desee entablar conversación con otro usuario, éste segundo debe tener la libertad de no permitir el contacto. Lo siguiente a tener en cuenta es cómo mostrar los usuarios al resto, cómo entablar conversación y cómo se sabe si un usuario está en ese momento visitando el sitio web. Existen dos posibles opciones a priori.
• En todo rincón del sitio web donde se muestran nombres y fotografías de usuarios, incluir un icono que indique si el usuario está en línea o no. Al entrar en su perfil dar la posibilidad al usuario de crear una conversación mediante chat. Esta funcionalidad permitiría al usuario en curso entablar conversación inmediata con el usuario que ha registrado cualquier objeto que le llame la atención.
• Otra opción sería similar a la funcionalidad de chats de otros sitios webs como por ejemplo Facebook (41). Se permitiría al usuario agregar a otros usuarios utilizando el concepto “amigo” o “favorito”. Cuando el usuario se identificara en el sitio web, en algún apartado siempre visible se mostraría su lista de “favoritos” y la posibilidad de entablar conversación con ellos. Por supuesto los usuarios tendrían la libertad de rechazar las peticiones de inclusión en listas de “favoritos” que se les hiciera.
Como se ha podido ver a lo largo del proyecto, el sistema BCN Look & Find está pensado para facilitar la interacción entre usuarios o centros, para que posteriormente ellos mismos contacten y se recuperen sus pertenencias personalmente. Es posible que muchos usuarios prefieran preservar su anonimato e incluso esto provoque que no utilicen el sitio web.
Un modo de solucionar este problema y captar más usuarios sería el de facilitar a los usuarios, desde el sitio web, el envío de los objetos a sus propietarios, utilizando algún tipo de empresa de mensajería o transporte, como Correos, MRW, SEUR, etc.
Una extensión que también podría ser interesante es la incorporación nuevas estadísticas, obtenidas a partir de la información de los objetos registrados. Un ejemplo de información que
120
se podría obtener a partir de estas estadísticas es las zonas donde se suelen perder una cantidad mayor de objetos.
Para terminar cabe mencionar uno de los aspectos más importantes del sistema BCN Look & Find, la gestión de objetos perdidos depositados en centros. Como se ha comentado anteriormente en la Sección 5, no ha sido posible llevar a cabo una fase de experimentación con centros como la que se hubiera deseado. A pesar de ello se ha recibido algún comentario en el que se expresaba la preocupación a la hora de registrar objetos de tipo documentación que contienen datos personales del propietario del objeto. Sería interesante implantar alguna mejora en este aspecto, para tener controlada dentro de lo posible, la privacidad del usuario. Una posibilidad sería la de modificar automáticamente el formulario de registro de objetos en el momento que se selecciona la categoría documentación e incluir nuevos campos como el tipo de documentación a registrar y otros dependiendo de éste, así guiar al usuario e intentar evitar el registro de datos privados.
Por supuesto, puesto que las plataformas web están en constante cambio y mejora, siempre es posible mejorar su usabilidad, accesibilidad, diseño, seguridad, posicionamiento SEO, etc.
Bibliografía
1. Vila, Iván. La Oficina de Hallazgos de Barcelona devuelve a sus propietarios el 86% de los objetos perdidos que le llegan. La Vanguardia. [En línea] 7 de Febrero de 2011. http://www.lavanguardia.com/vida/20110207/54110648163/la-‐oficina-‐de-‐hallazgos-‐de-‐barcelona-‐devuelve-‐a-‐sus-‐propietarios-‐el-‐86-‐de-‐los-‐objetos-‐perdidos-‐que.html#.Tnb9S8WGCzg.email/.
2. Wikipedia. Web 2.0. Wikipedia. [En línea] 13 de Diciembre de 2010. http://es.wikipedia.org/wiki/Web_2.0.
3. —. URL. Wikipedia. [En línea] 12 de Diciembre de 2011. http://es.wikipedia.org/wiki/Localizador_uniforme_de_recursos.
4. Factoría de Internet S.L. WebTaller Formularios HTML. WebTaller. [En línea] 2011. http://www.webtaller.com/construccion/lenguajes/html/lecciones/formularios_html.php.
5. Wikipedia. Posicionamiento en buscadores. Wikipedia. [En línea] 23 de Diciembre de 2011. http://es.wikipedia.org/wiki/Posicionamiento_en_buscadores.
6. Costal, Dolors, y otros, y otros. Enginyeria del Software Especificació. Edicions UPC. Barcelona : s.n., 2005. 84-‐8301-‐799-‐7.
7. Barcelona Activa Cibernàrium. Arquitectura de la informació: Granteix una bona experiència d'usuari. Cibernàrium. [En línea] 2011. http://www.cibernarium.cat/cibernarium/cat/index.jsp.
8. Wikipedia. PHP. Wikipedia. [En línea] 28 de Diciembre de 2011. http://es.wikipedia.org/wiki/PHP.
121
9. PHP Group. PHP. PHP. [En línea] 30 de Diciembre de 2011. http://www.php.net/.
10. Wikipedia. HTML. Wikipedia. [En línea] 16 de Diciembre de 2011. http://es.wikipedia.org/wiki/HTML.
11. W3Schools. HTML Tutorial. W3Schools. [En línea] 2011. http://www.w3schools.com/html/.
12. Wikipedia. JavaScript. Wikipedia. [En línea] 13 de Noviembre de 2011. http://es.wikipedia.org/wiki/JavaScript.
13. W3Schools. JavaScript Tutorial. W3Schools. [En línea] 2011. http://www.w3schools.com/js/.
14. Wikipedia. Hojas de Estilo en Cascada. Wikipedia. [En línea] 23 de Diciembre de 2011. http://es.wikipedia.org/wiki/Hojas_de_estilo_en_cascada.
15. Shea, Dave. Zend Garden. Zend Garden. [En línea] 2012. http://www.csszengarden.com/.
16. Wikipedia. JQuery. Wikipedia. [En línea] 16 de Diciembre de 2011. http://es.wikipedia.org/wiki/JQuery.
17. The JQuery Project. JQuery. JQuery. [En línea] 2010. http://jquery.com/.
18. Wikipedia. AJAX. Wikipedia. [En línea] 30 de Diciembre de 2011. http://es.wikipedia.org/wiki/AJAX.
19. —. Extensible Markup Language. Wikipedia. [En línea] 18 de Diciembre de 2011. http://es.wikipedia.org/wiki/Extensible_Markup_Language.
20. —. Sistema de Gestión de Contenidos. Wikipedia. [En línea] 13 de Diciembre de 2011. http://es.wikipedia.org/wiki/Sistema_de_gestión_de_contenidos.
21. Drupal. Drupal. Drupal. [En línea] http://drupal.org/.
22. eZ Systems AS. eZ Publish. eZ Publish. [En línea] 2011. http://ez.no.
23. Open Source Matters, Inc. Joomla. Joomla. [En línea] 2012. http://www.joomla.org.
24. WordPress. WordPress. WordPress. [En línea] http://wordpress.org/.
25. Finder Base. Finder Base. Finder Base. [En línea] http://www.finderbase.com/.
26. Grupo Enobras Networks, S.L. Megalost. Megalost. [En línea] 2012. http://megalost.com/.
27. Wikifinding -‐ Community Search. Wikifinding. Wikifinding. [En línea] 2012. http://www.wikifinding.com/.
28. Objetos Perdidos. Objetos Perdidos. Objetos Perdidos. [En línea] http://objetosperdidos.org/.
29. Lost Objects Community. Lost Objects Community. Lost Objects Community. [En línea] http://www.lostobjectscommunity.com/.
122
30. Oomia. Oomia. Oomia. [En línea] 2007. http://www.oomia.com/.
31. Transports Metropilitans de Barcelona, TMB. Objectes Perduts. Transports Metropilitans de Barcelona, TMB. [En línea] 2011. http://www.tmb.cat/es/objectes-‐perduts/.
32. Institut Metropolità del Taxi. Institut Metropolità del Taxi. Institut Metropolità del Taxi. [En línea] 2006. http://www.taxibarcelona.cat/tabid/904/Default.aspx/.
33. AVE. AVE. AVE. [En línea] http://ave-‐renfe.edreams.es/general/objetos-‐perdidos-‐en-‐el-‐ave/..
34. eZ Systems AS. eZ Publish Documentation. eZ Publish. [En línea] 2011. http://doc.ez.no/.
35. Marie Skaara, Bergfrid. eZ Publish Advanced Content Management. [ed.] Peter Keung. United States : Zickerman, Jennifer, 2008. 978-‐82-‐92792-‐05-‐1.
36. Halasy, Balazs. eZ Publish Basics. [ed.] Jennifer Zickerman. Norway : s.n., 2006. 978-‐82-‐92797-‐00-‐9.
37. eZ Systems AS. eZ Publish Enterprise Tour. 2010.
38. eZ Systems. Share eZ Publish Downloads. Share eZ Publish. [En línea] 2010. http://share.ez.no/download-‐develop/downloads/ez-‐publish-‐4.3/.
39. —. Share eZ Publish Forum. Share eZ Publish. [En línea] 2010. http://share.ez.no/forums/developer/.
40. JACSYSTEME. Ez publish 3.* Tutorial Introducción en el desarrollo de extensiones en eZ Publish. Ez publish 3.* Tutorial Introducción en el desarrollo de extensiones en eZ Publish. [En línea] 2007. www.jac-‐systeme.de.
41. Facebook. Facebook. Facebook. [En línea] 2012. https://www.facebook.com/.
42. Google. Webmasters. Google. [En línea] 2011. http://www.google.es/webmasters/.
43. SeoWeb. Tutorial Completo Sitemap. Consultor SEO Freelance| Experto posicionamiento web. [En línea] 31 de Mayo de 2011. http://seowebconsultor.com/2011/05/31/tutorial-‐completo-‐sitemap-‐xm/.
44. Duch, Amalia, Pasarella, Edelmira y Santiso, David. BCN Look & Find. Facebook. [En línea] 2012. https://www.facebook.com/pages/BCN-‐Look-‐Find/125525917548242.
45. Google. Google Maps. Google Maps. [En línea] 2011. http://maps.google.es/.
123