TRABAJO FIN DE ESTUDIOS - biblioteca.unirioja.es · A mi familia, por el apoyo ... El software...

TRABAJO FIN DE ESTUDIOS

Wiki para la compartición de archivos en grupos detrabajo

Rodrigo Martínez Ruiz

PROYECTO FIN DE CARRERA

Tutor: Jesús María Aransay Azofra

Curso 2011-2012

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2012

publicaciones.unirioja.esE-mail: [email protected]

Wiki para la compartición de archivos en grupos de trabajo, trabajo fin deestudios

de Rodrigo Martínez Ruiz, dirigido por Jesús María Aransay Azofra (publicado por laUniversidad de La Rioja), se difunde bajo una Licencia

Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los

titulares del copyright.

1

UNIVERSIDAD DE LA RIOJA

Facultad de Ciencias, Estudios Agroalimentarios e Informática

PROYECTO FIN DE CARRERA

Ingeniería Técnica en Informática de Gestión

Wiki para la compartición de archivos en grupos de trabajo.

Alumno: Rodrigo Martínez Ruiz Director: Jesús Mª Aransay Azofra

Logroño, diciembre de 2011

3

Hemos construido una aplicación web que sirve para la compartición de

archivos y recursos online pensada para trabajos en grupo.

En la aplicación se pueden crear artículos asignándoles un fichero desde el

ordenador o un enlace URL a un recurso de Internet. El creador podrá

compartir el articulo con otros usuarios de la aplicación, pudiendo éstos

descargarse/ver el recurso asignado y hacer comentarios sobre él. El

creador también podrá subir nuevas versiones de un artículo existente.

Para su desarrollo se ha utilizado el lenguaje de programación PHP y

técnicas AJAX así como un framework de JavaScript llamado JQuery.

5

Agradecimientos:

A mi familia, por el apoyo constante durante este tiempo y por entender algunas decisiones

tomadas durante la realización del proyecto.

A mis amigos y compañeros, puesto que han sido de gran ayuda en muchos aspectos y no me

han negado ayuda o consejos, muchos de los cuales me han servido para superar con éxito

muchas fases.

A los profesores de la UR, por todo lo que me han enseñado estos años, pues entré en la

carrera sin haber tocado ni una línea de código.

Al tutor del proyecto, Jesús María Aransay, por su constante orientación y consejo en todo lo

relacionado con el proyecto. Ha hecho un magnífico trabajo.

7

Índice

1. Documento de Objetivos del Proyecto (DOP)

................................................................... 10

1.1 Descripción ............................................... 10

1.2 Justificación .............................................. 10

1.3 Antecedentes............................................ 11

1.4 Alcance ..................................................... 12

1.5 Entregables del proyecto .......................... 13

1.6 Estructura de descomposición del trabajo

(EDT) ........................................................... 14

1.6.1 Gestión de proyecto (GP) .................. 15

1.6.2 Análisis del Sistema de Información

(ASI) ............................................................ 16

1.6.3 Diseño del Sistema de Información

(DSI) ................................. 17, 46, 78, 119, 128

1.6.4 Construcción del Sistema de

Información (CSI).................................. 18, 19

1.7 Calendario de trabajo ............................... 20

1.8 Diagrama de Gantt ................................... 21

1.9 Riesgos ...................................................... 22

2. Análisis del Sistema de Información ........... 24

2.1. Establecimiento de requisitos. ................ 24

2.2 Análisis de Casos de Uso. .......................... 27

2.3. Análisis de Clases. .................................... 39

2.4. Definición de interfaces. .......................... 44

2.5. Plan de pruebas. ...................................... 45

3. Diseño del Sistema de Información (DSI) ... 46

3.1. Definición de la arquitectura del sistema. 46

3.2. Diseño de interfaces. .............................. 49

3.2.1. Introducción ..................................... 49

3.2.2. Prototipos de interfaz ...................... 51

3.3. Diseño de clases. .................................... 59

3.3.1. Relación con el diagrama del análisis

................................................................... 61

3.3.2. Vista concreta .................................. 62

3.4. Diseño de datos. ..................................... 66

3.4.1. Descripción Modelo de Datos ......... 67

3.4.2. Relaciones entre tablas ................... 74

4. Construcción del Sistema de Información

(CSI) ............................................................. 78

4.1. Preparación del entorno. ......................... 78

4.2. Generación de código de componentes y

procedimientos ........................................... 82

4.2.1. Estructura de directorios .................. 82

4.2.2. Implementación del modelo de datos

.................................................................... 84

4.2.3. Implementación de la lógica ............. 86

4.2.4. Creación de las interfaces de usuario

.................................................................... 99

4.3. Ejecución de pruebas. ............................ 117

5. Pruebas de implantación Sistema (IAS) .... 119

5.1. Pruebas de Implantación ....................... 119

5.2. Pruebas de aceptación ........................... 125

6. Valoraciones del proyecto ........................ 128

6.1. Análisis de duración del proyecto .......... 128

6.1.2. Cumplimiento del horario semanal 128

6.1.3. Duración real & Duración estimada 128

6.1.4. Riesgos ............................................ 131

6.2. Conclusiones .......................................... 133

6.3. Futuras Implementaciones .................... 134

6.3.1. Correcciones ................................... 134

6.3.2. Mejoras y ampliaciones .................. 134

Anexo I Diagrama de clases modificado ...... 135

Anexo II Manual de usuario ......................... 138

1.- Registro y Login ................................... 138

2.- Inicio y barra de navegación ................ 140

3.- Perfil .................................................... 141

4.- Artículos............................................... 143

5.- Búsquedas ........................................... 149

Anexo III Actas de reunión ........................... 151

8

Índices de ilustraciones

ILUSTRACIÓN 1: CALENDARIO ............................................................................................................................ 20

ILUSTRACIÓN 2: DIAGRAMA DE GANTT .............................................................................................................. 21

ILUSTRACIÓN 3: DIAGRAMA DE CLASES (ANÁLISIS) ................................................................................................. 43

ILUSTRACIÓN 4: ARQUITECTURA EN 3 CAPAS......................................................................................................... 46

ILUSTRACIÓN 5: ESQUEMA MVC........................................................................................................................ 59

ILUSTRACIÓN 6: DIAGRAMA DE CLASES ................................................................................................................ 60

ILUSTRACIÓN 7: DIAGRAMA DE MODELOS (CLASES) ............................................................................................... 62

ILUSTRACIÓN 8: DIAGRAMA DE CONTROLADORES (CLASES) ..................................................................................... 63

ILUSTRACIÓN 9: DIAGRAMA DE VISTAS (CLASES) ................................................................................................... 64

ILUSTRACIÓN 10: ESQUEMA DE LOS TPL ............................................................................................................ 101

ILUSTRACIÓN 11: GRAFICO COMPARATIVO DE HORAS ........................................................................................... 130

ILUSTRACIÓN 12: GRÁFICO TARTA DE HORAS ESTIMADAS ...................................................................................... 130

ILUSTRACIÓN 13: GRÁFICO TARTA DE HORAS REALES ............................................................................................ 130

CDU 1: AUTENTICACIÓN .................................................................................................................................. 28

CDU 2: DATOS USUARIO .................................................................................................................................. 30

CDU 3: GESTIÓN DE ENTRADAS ......................................................................................................................... 31

CDU 4: FICHA ................................................................................................................................................ 33

CDU 5: OPCIONES USUARIO ............................................................................................................................. 34

CDU 6: ADMINISTRADOR ................................................................................................................................. 36

INTERFACES 1: EJEMPLO 1 ................................................................................................................................ 49

INTERFACES 2: EJEMPLO 2 ................................................................................................................................ 50

INTERFACES 3: ESTRUCTURA BÁSICA .................................................................................................................... 51

INTERFACES 4: PROTOTIPO LOGIN ...................................................................................................................... 52

INTERFACES 5: PROTOTIPO BARRA NAVEGACIÓN ................................................................................................... 52

INTERFACES 6: PROTOTIPO INICIO ....................................................................................................................... 53

INTERFACES 7: PROTOTIPO PERFIL ...................................................................................................................... 54

INTERFACES 8: PROTOTIPO ARTÍCULOS ................................................................................................................ 55

INTERFACES 9: PROTOTIPO FICHA ....................................................................................................................... 56

INTERFACES 10: PROTOTIPO BÚSQUEDAS ............................................................................................................ 57

INTERFACES 11: PROTOTIPO ADMINISTRADOR ...................................................................................................... 58

ESQUEMAS BD 1: ESQUEMA WORKBENCH .......................................................................................................... 67

ESQUEMAS BD 2: USUARIO Y TIPOUSUARIO ........................................................................................................ 68

ESQUEMAS BD 3: ARTICULO Y TIPOARTICULO ...................................................................................................... 69

ESQUEMAS BD 4: ENLACE Y ARCHIVO ................................................................................................................. 70

ESQUEMAS BD 5: USUARIOCOLABORA................................................................................................................ 70

ESQUEMAS BD 6: COMENTARIO ........................................................................................................................ 71

ESQUEMAS BD 7: VERSIÓN ............................................................................................................................... 71

ESQUEMAS BD 8: CATEGORÍA ........................................................................................................................... 72

ESQUEMAS BD 9: CATEGORIA ........................................................................................................................... 72

ESQUEMAS BD 10: ACTUALIZACIÓN ................................................................................................................... 73

ESQUEMAS BD 11: RELACIONES USUARIO ........................................................................................................... 74

9

ESQUEMAS BD 12: RELACIONES USUARIOCOLABORA ............................................................................................ 75

ESQUEMAS BD 13: RELACIONES COMENTARIO ..................................................................................................... 76

ESQUEMAS BD 14: RELACIONES ARTÍCULO .......................................................................................................... 77

FIGURAS ANEXOS 1: DIAGRAMA MODELOS FINAL ................................................................................................ 135

FIGURAS ANEXOS 2: DIAGRAMA CONTROLADORES FINAL ...................................................................................... 136

FIGURAS ANEXOS 3: DIAGRAMA VISTAS FINAL .................................................................................................... 137

10

1. Documento de Objetivos del Proyecto (DOP)

1.1. Descripción

El proyecto consiste en la creación de una aplicación web que permita a una colección de usuarios identificados acceder y compartir en un servidor documentos (en general en formatos de sólo lectura) de múltiples formatos (pdf, doc, xsl, etc…).

Cada usuario será “propietario” de sus documentos y deberá ser capaz de determinar qué usuarios tendrán acceso a los mismos y durante qué periodo de tiempo. También proveerá la posibilidad de permitir a dichos usuarios que envíen comentarios sobre el documento que sean visibles por todos los usuarios con acceso al documento. La aplicación contará con un cierto control de versiones, de tal modo que una nueva versión de un documento pueda ser subida, permitiendo al usuario propietario seguir compartiendo la versión anterior o eliminándola del servidor. La aplicación también contará con un sistema de alertas que avisará a todos los usuarios con capacidad para acceder a un documento de que el mismo ha sido subido al servidor, o de que nuevos comentarios han sido realizados sobre el mismo. Los usuarios tendrán la capacidad de elegir sobre qué eventos de la aplicación recibir alertas.

A lo largo del desarrollo del proyecto podrían surgir nuevos requisitos de la aplicación. Las tecnologías a aplicar en el proyecto serán objeto de análisis del proyecto, y por tanto no están determinadas a priori. Sí que se tratará de emplear ciertas tecnologías de desarrollo web (AJAX, JQuery) que permitan mejorar la experiencia del usuario y la presentación y usabilidad de la herramienta.

1.2. Justificación

El proyecto fue propuesto por el tutor del mismo, Jesús María Aransay. Surge como un

medio para compartir archivos de cualquier formato digital que puedan ser compartidos por

personas/investigadores con interés común, ya sea por formar parte de un grupo de trabajo o

investigación específico o no.

Está orientado a grupos de trabajo, investigación o creación de proyectos, que necesitan

compartir información de todo tipo (referencias, archivos importantes o de interés,

documentos de un proyecto etc…), centralizándolo todo en una aplicación agradable y de fácil

uso y que pone en común documentos con las personas que el creador cree pertinentes.

En principio, la herramienta está enfocada para ser utilizada por un grupo de investigación

concreto y ser implantada en su entorno, sin embargo, la idea final es que la herramienta sea

11

lo suficientemente genérica como para ser utilizada para cualquier grupo de trabajo o

investigación.

1.3. Antecedentes

Un antecedente a lo que se pretende realizar, aunque no estrictamente, sería el llamado Software colaborativo o Groupware que se refiere al conjunto de programas informáticos que integran el trabajo en un solo proyecto con muchos usuarios concurrentes que se encuentran en diversas estaciones de trabajo, conectadas a través de una red.

El software colaborativo se puede dividir en tres categorías: herramientas de colaboración-comunicación, herramientas de conferencia y herramientas de gestión colaborativa.

Este último es el tipo de software más acorde a nuestro proyecto. Las herramientas de gestión colaborativa facilitan las actividades del grupo. De esta idea tomamos algunas políticas que serán comunes con nuestro proyecto. Nuestra herramienta podrá gestionar documentos y organizarlos para que los miembros del grupo de trabajo puedan accederlos. También tomará parte en la gestión del conocimiento, pues los archivos compartidos son información importante en el proyecto así como favorecer la disponibilidad de los miembros de un grupo de trabajo, puesto que la aplicación podrá ser accedida desde Internet, y por ende, desde cualquier ordenador con conexión a la red.

El principal motivo para poner en marcha la creación de este software – además del aprendizaje sobre la creación y gestión de proyectos - es ofrecer una plataforma sencilla y de fácil uso para poder conocer de primera mano las opiniones de tus archivos con los miembros de tu proyecto. Por ello, no es estrictamente un software colaborativo (como hemos apuntado antes) sino una herramienta social para que un miembro de un grupo de investigación pueda “pulir” sus documentos con las indicaciones de sus compañeros.

Quizá la herramienta de software colaborativo más conocida sea Google Docs, que tiene algunas semejanzas con la aplicación que queremos desarrollar, pero también alguna diferencia.

Google Docs te permite compartir un archivo con otros usuarios para que éstos lo vean y/o lo editen. Nuestra aplicación no permitirá la edición directa online como Google Docs, pero sí permitirá dejar comentarios sobre el archivo (a modo de comentarios en un artículo de un blog, por ejemplo), funcionalidad de la que Google Docs no dispone.

12

1.4. Alcance

La aplicación ha de ser capaz de:

Permitir el alta de usuarios con un formulario de registro.

Dar acceso a los usuarios registrados mediante un usuario y contraseña.

Permitir a un usuario subir un archivo desde el disco duro de su ordenador al servidor

de la aplicación, añadirle un tiempo durante el que permanecerá activo y añadir tantos

usuarios “lectores” como el usuario crea oportuno.

Al hilo del punto anterior, un usuario podrá ser asignado como lector de un archivo por

otro usuario y realizar comentarios sobre el mismo o descargarse el archivo.

El usuario que ha subido un archivo, puede subir una nueva versión del mismo,

eligiendo si quiere destruir la anterior o mantenerla.

Los usuarios recibirán alertas de comentarios y/o nuevas versiones en sus archivos

subidos y en los que están asignados.

Los usuarios que suben archivos, tendrán la oportunidad de elegir si quieren que el

archivo sea eliminado cuando acabe su tiempo de duración o pase a un índice de

archivos (Historial) dónde se podrán descargar después.

Por el contrario, el sistema y el proyecto no se encargará de:

La edición múltiple de archivos. La herramienta sirve para compartir el trabajo propio y

exponerlo a sugerencias y críticas, no para que se realicen correcciones de alguien que

no sea su autor.

El objetivo del proyecto no tiene en cuenta el mantenimiento de la herramienta una

vez instalada.

13

1.5. Entregables del proyecto

El proyecto tendrá una serie de documentos (tanto físicos como en formato software) que se

entregarán al finalizarlo y que comprenden la totalidad del trabajo realizado.

Memoria: Documento de texto que incluye todos los pasos para la elaboración del

proyecto: DOP, Análisis, Diseño, Anexos etc…

Manual de usuario e instalación: Documento de texto con indicaciones precisas para

explicar su uso a los usuarios. Será un anexo más de la memoria.

Aplicación: Todos los archivos de código de la aplicación.

1.6. Metodología

Para la realización del proyecto, vamos a utilizar la metodología MÉTRICA en su versión tres para la planificación y desarrollo de nuestro software. No va a suponer una guía estricta, puesto que cogeremos de ella los puntos que consideremos necesarios, debido a que nuestro proyecto no goza de una gran extensión. Promovida por el Ministerio de Administraciones Públicas del Gobierno de España, Métrica v3 propone las siguientes técnicas que utilizaremos en las diversas fases del proyecto:

Técnicas de gestión de proyectos: Técnicas de estimación, diagramas de planificación.

Técnicas de desarrollo: Casos de Uso, Diagrama de actividad, Diagramas de Clases. En cuanto a los perfiles, dado que el proyecto no es de elevada envergadura, los perfiles no están estrictamente definidos, siendo el alumno a la vez analista, programador y jefe de proyecto. El tutor hará las veces de cliente y usuario final, aunque el alumno podrá matizar algunos requisitos del sistema si así lo cree conveniente para el desarrollo del proyecto.

http://es.wikipedia.org/wiki/Planificaci%C3%B3n

http://es.wikipedia.org/wiki/Caso_de_uso

http://es.wikipedia.org/wiki/Diagrama_de_clases

14

1.7. Estructura de descomposición del trabajo (EDT)

La estructura de descomposición del trabajo o EDT es una estructura exhaustiva, jerárquica y descendente formada por los entregables a realizar en un proyecto. El propósito de una EDT es documentar el alcance del proyecto. Todo trabajo a ser hecho en el proyecto debe poder rastrear su origen en una o más entradas de la EDT. Vamos a seguir una descomposición clásica: Análisis, Diseño y Construcción para la descomposición de tareas. Seguiremos las tareas que propone Métrica v3 para sistemas orientados a objetos, aunque no estrictamente, puesto que se ha elegido las que se creían convenientes para la pequeña magnitud del proyecto. La numeración elegida para las tareas está inspirada en la que expone Métrica v3 en la web del Portal de Administración Electrónica.

Proyecto

Gestión de

proyecto (GP)

Análisis

(ASI)

Diseño

(DSI)

Construcción

(CSI)

Gestión de

proyecto

Reuniones

Creación del

DOP

Memoria

Formación

adicional

(GP5)

Establecimiento

de requisitos

Análisis de

Casos de Uso

Análisis de

Clases

Definición de

Interfaces

Plan de

pruebas

Diseño de la

arquitectura

Diseño de

Clases

Diseño físico

de datos

Preparación

del entorno

Generación

de código

Creación de

interfaces

Ejecución de

pruebas

Defensa del

proyecto

(GP6)

Implantación

(IAS)

Pruebas de

implantación

Pruebas de

aceptación

Diseño de

interfaces

http://es.wikipedia.org/wiki/Proyecto

15

1.7.1. Gestión de proyecto (GP)

El objetivo de este proceso es ordenar las diferentes fases de la creación de la documentación adicional del proyecto.

Actividad GP.1: Gestión de proyecto

o Descripción: Se detalla el plan de trabajo que más adelante será definido en el DOP.

o Tiempo estimado: 15 horas. o Ciclo de vida: Inicio del proyecto.

Actividad G.P.2: Reuniones

o Descripción: Encuentros con el tutor para resolver dudas y mantener un seguimiento del progreso.

o Tiempo estimado: 26 horas. o Ciclo de vida: Durante todo el proyecto.

Actividad G.P.3: Creación del DOP

o Descripción: Creación del Documento de Objetivos del proyecto. o Tiempo estimado: 40 horas. o Ciclo de vida: Inicio del proyecto.

Actividad G.P.4: Memoria

o Descripción: Recopilación de todos los documentos generados durante la creación del proyecto.


Actividad G.P.5: Formación en nuevas tecnologías

o Descripción: Aprendizaje de tecnologías nuevas para la realización del proyecto.


Actividad G.P.6: Preparación y defensa del proyecto

o Descripción: Creación de material para la defensa y preparación de la misma ante el tribunal.

o Tiempo estimado: 10 horas. o Ciclo de vida: Final del proyecto.

16

1.7.2. Análisis del Sistema de Información (ASI)

El objetivo de este proceso es la obtención de una enumeración detallada del sistema de información que satisfaga las necesidades de información de los usuarios y sirva de base para el posterior diseño del sistema.

Actividad ASI.2: Establecimiento de requisitos.

o Descripción: Definición, análisis y validación de los requisitos a partir de la información facilitada por el usuario, para obtener un catálogo detallado de los requisitos.

o Tiempo estimado: 3 horas. o Ciclo de vida: Inicio del análisis.

Actividad ASI.4: Análisis de Casos de Uso.

o Descripción: Identificar las clases cuyos objetos son necesarios para realizar un caso de uso y describir su comportamiento mediante la interacción dichos objetos.

o Tiempo estimado: 12 horas. o Ciclo de vida: Tras los requisitos.

Actividad ASI.5: Análisis de Clases.

o Descripción: Describir cada una de las clases que ha surgido, identificando las responsabilidades que tienen asociadas, sus atributos, y las relaciones entre ellas.

o Tiempo estimado: 24 horas. o Ciclo de vida: Tras el análisis de casos de uso e interfaces.

Actividad ASI.8: Definición de interfaces.

o Descripción: Se especifican las interfaces entre el sistema y el usuario: formatos de pantallas, diálogos, e informes, principalmente. El objetivo es realizar un análisis de los procesos del sistema de información en los que se requiere una interacción del usuario, con el fin de crear una interfaz que satisfaga todos los requisitos establecidos, teniendo en cuenta los diferentes perfiles a quienes va dirigido.

o Tiempo estimado: 8 horas. o Ciclo de vida: Tras el análisis de casos de uso.

Actividad ASI.10: Plan de pruebas.

o Descripción: Se inicia la definición del plan de pruebas, el cual sirve como guía para la realización de las pruebas, y permite verificar que el sistema de información cumple las necesidades establecidas por el usuario, con las debidas garantías de calidad.

o Tiempo estimado: 6 horas. o Ciclo de vida: Final del análisis.

17

1.7.3. Diseño del Sistema de Información (DSI)

El objetivo del proceso de Diseño del Sistema de Información (DSI) es la definición de la arquitectura del sistema y del entorno tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del sistema de información. A partir de dicha información, se generan todas las especificaciones de construcción relativas al propio sistema, así como la descripción técnica del plan de pruebas, la definición de los requisitos de implantación y el diseño de los procedimientos de migración y carga inicial, éstos últimos cuando proceda.

Actividad DSI.1: Definición de la arquitectura del sistema.

o Descripción: En esta actividad se define la arquitectura general del sistema de información, especificando las distintas particiones físicas del mismo, la descomposición lógica en subsistemas de diseño y la ubicación de cada subsistema en cada partición, así como la especificación detallada de las diversas tecnologías con las que trabajaremos.

o Tiempo estimado: 8 horas. o Ciclo de vida: Inicio del diseño.

Actividad DSI.4: Diseño de clases.

o Descripción: Transformar el modelo de clases lógico, que proviene del análisis, en un modelo de clases de diseño. Dicho modelo recoge la especificación detallada de cada una de las clases, es decir, sus atributos, operaciones, métodos, y el diseño preciso de las relaciones establecidas entre ellas, bien sean de agregación, asociación o jerarquía. Para llevar a cabo todos estos puntos, se tienen en cuenta las decisiones tomadas sobre el entorno tecnológico y el entorno de desarrollo elegido para la implementación.

o Tiempo estimado: 24 horas. o Ciclo de vida: Tras la definición de la arquitectura del sistema.

Actividad DSI.5: Diseño de interfaces.

o Descripción: El objetivo de esta tarea es realizar el diseño detallado del comportamiento de la interfaz de usuario a partir de la especificación de la misma, obtenida en el proceso de análisis, y de acuerdo con el entorno tecnológico definido. Además, se incluyen las ventanas alternativas o elementos de diseño surgidos como consecuencia del diseño de los escenarios definidos en la tarea anterior.

o Tiempo estimado: 16 horas. o Ciclo de vida: Tras el diseño de clases.

Actividad DSI.6: Diseño de datos.

o Descripción: Definir los módulos del sistema de información, y la manera en que van a interactuar unos con otros, intentando que cada módulo trate total o parcialmente un proceso específico y tenga una interfaz sencilla.

o Tiempo estimado: 45 horas. o Ciclo de vida: Tras el diseño de clases.

18

1.7.4. Construcción del Sistema de Información (CSI)

En este proceso se genera el código de los componentes del Sistema de Información, se desarrollan todos los procedimientos de operación y seguridad y se elaboran todos los manuales de usuario final y de explotación con el objetivo de asegurar el correcto funcionamiento del Sistema para su posterior implantación.

Actividad CSI.1: Preparación del entorno de generación y construcción.

o Descripción: El objetivo de esta actividad es asegurar la disponibilidad de todos los medios y facilidades para que se pueda llevar a cabo la construcción del sistema de información. Entre estos medios, cabe destacar la preparación de los puestos de trabajo, equipos físicos y lógicos, gestores de bases de datos, bibliotecas de programas, herramientas de generación de código, bases de datos o ficheros de prueba, entre otros.

o Tiempo estimado: 12 horas. o Ciclo de vida: Inicio de la construcción.

Actividad CSI.2: Generación del código de los componentes y procedimientos.

o Descripción: El objetivo de esta actividad es la codificación de los componentes del sistema de información, a partir de las especificaciones de construcción obtenidas en el proceso Diseño del Sistema de Información (DSI), así como la construcción de los procedimientos de operación y seguridad establecidos para el mismo.

o Tiempo estimado: 200 horas. o Ciclo de vida: Tras la preparación del entorno.

Actividad CSI.3: Creación de las interfaces de usuario.

o Descripción: El objetivo de esta actividad es la creación de las interfaces que usará la aplicación.

o Tiempo estimado: 100 horas. o Ciclo de vida: A la vez que la generación de código.

Actividad CSI.5: Ejecución de pruebas del sistema.

o Descripción: En esta actividad se realizan las pruebas unitarias de cada uno de los componentes del sistema de información, una vez codificados, con el objeto de comprobar que su estructura es correcta y que se ajustan a la funcionalidad establecida.

o Tiempo estimado: 8 horas. o Ciclo de vida: Tras acabar la construcción de la aplicación.

19

1.7.5. Pruebas de del Sistema (IAS)

Este proceso tiene como objetivo principal la entrega y aceptación del sistema en su totalidad, y la realización de todas las actividades necesarias para el paso a producción del mismo.

Actividad IAS.5: Pruebas de implantación del sistema.

o Descripción: La finalidad de las pruebas de implantación es la de comprobar el funcionamiento correcto del sistema en el entorno de operación y permitir que el usuario determine, desde el punto de vista de operación, la aceptación del sistema instalado en su entorno real, según el cumplimiento de los requisitos especificados

o Tiempo estimado: 8 horas. o Ciclo de vida: Tras las pruebas unitarias.

Actividad IAS.8: Pruebas de aceptación del sistema.

o Descripción: Las pruebas de aceptación tienen como fin validar que el sistema cumple los requisitos básicos de funcionamiento esperado y permitir que el usuario determine la aceptación del sistema. Por este motivo, estas pruebas son realizadas por el usuario final que, durante este periodo de tiempo, debe plantear todas las deficiencias o errores que encuentre antes de dar por aprobado el sistema definitivamente

o Tiempo estimado: 4 horas. o Ciclo de vida: Tras las pruebas de implantación.

20

1.8. Calendario de trabajo El horario de trabajo es estimado, puesto que la disponibilidad en los meses siguientes al inicio del proyecto puede variar dependiendo de varios motivos personales y profesionales. En principio, se planea un horario de trabajo de cuatro horas diarias, de lunes a viernes, y dos horas los sábados librando domingos y algún día puntual (marcados con fondo gris en el dibujo de abajo). Las fechas recuadradas en rojo indican los días de inicio y final estimado del proyecto. La estimación está hecha en vista a la imposibilidad de dedicar tiempo por las mañanas debido a que posiblemente el alumno realice prácticas de empresa en ese horario. De no ser así, las horas se ampliarían también por la mañana.

Ilustración 1: Calendario

21

1.9. Diagrama de Gantt El diagrama de Gantt es una herramienta gráfica cuyo objetivo es mostrar el tiempo de dedicación previsto para diferentes tareas a lo largo de un tiempo total determinado. A pesar de que, en principio, el diagrama de Gantt no indica las relaciones existentes entre actividades, la posición de cada tarea a lo largo del tiempo hace que se puedan identificar dichas relaciones e interdependencias.

Ilustración 2: Diagrama de GANTT

22

1.10. Riesgos

El riesgo en un proyecto es una condición incierta que si ocurre, tiene un efecto generalmente

negativo sobre el proyecto.

El riesgo está presente en todos los proyectos. Se conoce como factor de riesgo a cada aspecto

particular del riesgo en el proyecto, el cual tiene causas y consecuencias que pueden ser

analizadas con diferente profundidad y detalle.

Estos son algunos de los riesgos más comunes:

Inexperiencia con la tecnología

o Posibilidad: Media.

o Riesgo derivado de tener que lidiar con tecnología novedosa para el usuario y

que requeriría tiempo extra de aprendizaje que retrasaría inevitablemente

algunas tareas. Para solventarlo, se recomienda extender el tiempo estimado

para las tareas que requieran dicho aprendizaje extra.

Lentitud en una toma de decisiones

o Posibilidad: Media.

o Riesgo que surge al tardar excesivamente en tomar decisiones clave, ya sea en

tecnología a usar o en solventar errores o dudas surgidas mientras se realiza el

proyecto.

Cambios en el proyecto

o Posibilidad: Baja.

o Los cambios en una tarea cuando ya está realizada una anterior relacionada

son un riesgo que surge cuando no han quedado claros los requisitos. Los

pequeños cambios son casi inevitables pero hay que definir los requisitos

globales de forma clara para no retrasar el proyecto en exceso.

Cambios en la disponibilidad del tiempo a dedicar

o Posibilidad: Media - Alta

o La estimación del tiempo se realiza teniendo en cuenta algunos factores que

pueden variar según se acerque una fecha. La posibilidad de que factores

como prácticas en empresas o la necesidad de dedicar tiempo para el estudio

de asignaturas pendientes en junio es un factor a tener en cuenta.

23

Agotamiento

o Posibilidad: Media-Baja

o Se puede cometer el error de planificar demasiado trabajo y convertirlo en

algo peor realizado. Para evitar este tipo de casos se puede hacer una

planificación que tenga en cuenta todo tipo de retrasos, extendiendo el

tiempo por exceso a cada tarea por los inconvenientes que puedan surgir.

Accidentes

o Posibilidad: Baja.

o Los proyectos se realizan y guardan generalmente en máquinas físicas

(ordenadores, memorias USB, etc…) que podría sufrir problemas que

requieran mantenimiento o incluso pérdida total de información. Por ello se

recomienda encarecidamente realizar copias de seguridad.

Enfermedades

o Posibilidad: Baja

o La posibilidad de que el encargado de realizar el proyecto pueda caer enfermo

imposibilitándole continuar el proyecto durante algún tiempo no hay forma de

predecirlo por lo que no puede aplicarse ningún método de contingencia

concreto.

24

2. Análisis del Sistema de Información

2.1. Establecimiento de requisitos.

Esta primera fase del análisis tiene como objetivo describir el sistema, delimitar más concienzudamente su alcance para posteriormente poder identificar los casos de uso y las clases necesarias para continuar el desarrollo.

Roles

La aplicación está sustentada en dos roles principales: Usuarios y Administradores. Los

usuarios se distinguirán a su vez tres tipos: Autores, Lectores y Colaboradores.

Para nuestra aplicación contaremos con los siguientes roles:

Usuario: Persona que tiene acceso al sistema y puede realizar las tareas que éste ofrece. Tiene dos extensiones:

o Autor: Usuario que publica un artículo. o Lector: Usuario que ha sido asignado al artículo y que puede únicamente

consultarlo (y descargarlo, si se trata de un archivo). o Colaborador: Usuario que puede consultar y además, realizar comentarios

sobre un artículo al que haya sido asociado por un usuario autor.

Administrador: Rol que es usado para moderar y manejar la aplicación, desde un panel de control exclusivo.

Requisitos funcionales

Un requisito funcional define el comportamiento interno del software, muestra en base a qué deberán actuar los casos de uso y establece los comportamientos del sistema. R.1 Un usuario deberá registrarse en la aplicación para poder usarla, rellenando un

formulario. Usará esos datos para acceder al sistema mediante un nombre de usuario y una

clave.

R.2 Un usuario podrá modificar sus datos, pudiendo cambiar incluso su clave de acceso.

También podrá añadir (o modificar) su avatar de usuario, una imagen representativa.

R.3 Un usuario podrá borrar su cuenta en cualquier momento.

R.4 Un usuario podrá subir un artículo para publicarlo en la aplicación, que podrá ser un

archivo completo desde el disco duro de su ordenador - que se alojará en el servidor del

sistema - o un enlace a un recurso que ya esté subido a Internet.

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Casos_de_uso

25

R.4.1 El usuario deberá rellenar algunos datos comunes sobre el artículo, incluyendo

una categoría para el mismo, que ya esté propuesta en la aplicación o de nueva

creación (se crea automáticamente a la vez que el artículo)

R.4.2 El usuario establecerá qué usuarios registrados en la aplicación pueden ver el

artículo (y descargarlo si es un archivo) y cuáles, además de lo anterior, pueden

comentarlo.

R.4.3 El usuario establecerá una fecha de inicio (a partir de la cual el artículo estará

visible en la aplicación) y una fecha de caducidad, señalando si, pasada esa fecha, el

artículo será borrado del servidor o movido a la sección Historial si lo desea.

R.4.4 Un usuario que ha publicado un artículo con éxito, podrá modificar a posteriori

algunos de los datos que considere oportunos e incluir nuevos usuarios al mismo

siempre que éste aún no haya llegado a su fecha de extinción.

R.4.5 Un usuario que ha publicado un artículo con éxito, podrá subir una nueva

versión del mismo, antes de su fecha de extinción, pasando la versión antigua al

Historial si así lo desea.

R.4.6 En todo momento, el usuario podrá borrar inmediatamente del sistema los

artículos que ha subido.

R.5 Un usuario que ha sido asignado para poder consultar un artículo que corresponde a

un archivo, puede descargárselo a su disco duro.

R.6 Un usuario que ha sido asignado para poder comentar un artículo, puede, además de

descargarlo si se trata de un archivo, dejar comentarios sobre el mismo, hasta su fecha de

extinción. Los comentarios podrán ser también contestaciones a comentarios ya enviados por

otros usuarios.

R.7 Los usuarios pueden consultar en todo momento el Historial de artículos en los que ha

estado asignado y/o ha publicado, siendo únicamente de carácter informativo. No podrán

dejar comentarios pero sí descargar archivos, si es posible.

R.8 En su perfil, los usuarios podrán marcar o desmarcar una casilla para recibir

actualizaciones (nuevos comentarios, nuevas versiones) en su correo electrónico sobre los

artículos a los que tengan acceso (ya sea porque son propietarios o por ser colaboradores).

R.9 Los administradores de la aplicación, podrán borrar y editar datos de usuarios y

artículos subidos.

R.9.1 Los usuarios podrán denunciar comentarios realizados en un artículo por resultar

ofensivos para que sean posteriormente moderados por los administradores.

R.10 Cualquier usuario puede realizar búsquedas de artículos en el sistema.

26

Requisitos no funcionales

Un requisito no funcional es un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema. Se refieren a todos los requisitos que ni describen información a guardar, ni funciones a realizar.

RN.1 Requisitos de tecnologías: o Utilizar técnicas de desarrollo web Ajax y un framework de JavaScript (jQuery o

Mootools), para mejorar la experiencia del usuario en la herramienta y también para aprender a manejarlas.

o El servidor de aplicación donde vamos a montar la herramienta a desarrollar posee PHP y MySQL.

RN.2 Requisitos de apariencia: o La aplicación deberá tener una apariencia cómoda y de fácil comprensión para

los usuarios.

RN.3 Requisitos de interfaz: o El idioma para la aplicación es el castellano.

RN.4 Requisitos de plazos de entrega: o Si hay retrasos, intentar tener finalizado el proyecto para el día 8 de Julio 2011,

puesto que es la fecha límite de entrega para este curso.

RN.5 Requisitos de instalación: o La aplicación final deberá ser instalada y puesta en marcha en un servidor

público para que sea testeada por usuarios reales, considerando estos test como pruebas de aceptación de la aplicación.

27

2.2 Análisis de Casos de Uso.

Un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. Normalmente, en los casos de uso se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas.

Con los requisitos funcionales ya marcados, desglosaremos de cada requisito los casos de uso

(a partir de ahora CDU) que creamos convenientes, indicando en cada uno los actores que

intervienen, su precondición y su postcondición.

Actores Un actor especifica un rol jugado por un usuario o cualquier otro sistema que interactúa con el sujeto (intercambiando signos y datos). Los actores pueden representar roles jugados por usuarios humanos, hardware externo, u otros sujetos. Los actores, en nuestro caso, se identifican con los roles de la aplicación mencionados anteriormente. Los Invitados no son estrictamente un rol del sistema (aunque así esté indicado en los diagramas de CDU), puesto que identifica a todas las personas que aún no tienen cuenta en la aplicación. Cuando el usuario colaborador (el que puede realizar comentarios sobre un artículo, recordemos) hace aparición, distinguiremos entre él y el usuario propietario, que es el que publica la entrada. Si no es necesario, nos referiremos a cualquier usuario validado en el sistema simplemente como Usuario. En un principio se pensó la aplicación sin administración interna, puesto que se planteaba como una herramienta sencilla y que cada usuario podría autoadministrar sus contenidos. Sin embargo, la existencia de un rol que administre globalmente la aplicación se hizo necesaria para marcar una línea visible en los permisos de entrada a la aplicación y también evitar que personas inexpertas accedan directamente a recursos como la base de datos para realizar tareas administrativas (borrado de usuarios conflictivos, artículos fraudulentos, etc…). El administrador, no obstante, no manejará la entrada de usuarios (en otras palabras, no decidirá quién entra en la aplicación y quién no) por lo que ésta seguirá siendo de libre acceso.

28

Desglose de requisitos

CDU 1: Autenticación

CDU.1.1 Registrarse

Descripción: Una persona que no está dada de alta, puede hacerlo rellenando un

formulario.

Actores: Invitado.

Precondición: El nombre de usuario no ha de existir ya en la base de datos de la

aplicación.

Postcondición: El invitado pasa a formar parte de la aplicación como usuario.

Requisito relacionado: R1

29

CDU.1.2 Login

Descripción: Un invitado accede al sistema.

Actores: Invitado

Precondición: El invitado debe tener cuenta en la aplicación.

Postcondición: El invitado pasa a ser usuario.


CDU.1.3 Cerrar sesión

Descripción: Un usuario abandona el sistema.

Actores: Usuario

Precondición: El usuario debe estar identificado en la aplicación.

Postcondición: La sesión se elimina y el usuario vuelve al inicio.


30

CDU 2: Datos usuario

CDU.2 Modificar datos

Descripción: Un usuario cambia datos de su perfil.

Actores: Usuario


Postcondición: El usuario actualiza sus datos en la aplicación.

Requisito relacionado: R2 y R3

CDU.3 Borrar cuenta

Descripción: Un usuario elimina voluntariamente su cuenta del sistema.

Actores: Usuario


Postcondición: El usuario suprime su cuenta y pierde su acceso a la aplicación.

Requisito relacionado: R2 y R3

31

CDU 3: Gestión de entradas

CDU.4.1 Crear artículo

Descripción: Un usuario sube un archivo al servidor de aplicación o publica un enlace,

rellenando un formulario y asignando usuarios que puedan accederlo y fechas

inicio/fin.

Actores: Usuario


Postcondición: El artículo queda publicado en la aplicación (si ha subido el recurso

desde su disco duro, queda alojado en el servidor de la aplicación), con unos usuarios

que pueden verlo/comentarlo y unas fechas de visibilidad establecidas.


32

CDU.4.2 Modificar artículo

Descripción: Un usuario puede modificar datos relacionados de un artículo que ha

publicado, así como añadir/eliminar usuarios y variar fechas de inicio/fin.

Actores: Usuario

Precondición: El usuario debe estar identificado en la aplicación y el artículo debe

existir en el sistema.

Postcondición: Los datos del artículo quedan actualizados.


CDU.4.3 Borrar artículo

Descripción: Un usuario puede eliminar un artículo de la base de datos.

Actores: Usuario

Precondición: El usuario debe estar identificado en la aplicación y el artículo debe

existir en el sistema.

Postcondición: El artículo queda suprimido de la aplicación.


33

CDU 4: Ficha

CDU.5 Descargar archivo

Descripción: Un usuario puede descargarse un archivo en el que colabora, siempre que

el artículo sea de un archivo subido por el autor desde su disco duro.

Actores: Usuario, Usuario colaborador

Precondición: El usuario debe estar identificado en la aplicación. El usuario ha debido

subir el archivo a descargar (ser el creador) o haber sido asignado a él.

Postcondición: El archivo se descarga al disco duro.


CDU.6 Comentar artículo

Descripción: Un usuario asignado puede comentar un artículo.

Actores: Usuario colaborador

Precondición: El usuario debe estar identificado en la aplicación y haber subido el

artículo y/o haber sido asignado para poder escribir comentarios en él.

Postcondición: Un comentario es visible en la página del artículo.


34

CDU 5: Opciones Usuario

CDU.7 Ver Historial

Descripción: Un usuario puede consultar el historial de artículos antiguos (los que él ha

publicado y en los que él ha participado).

Actores: Usuario


Postcondición: Se muestra el historial.


CDU.8 Marcar alertas

Descripción: Un usuario puede decidir si quiere recibir alertas (nuevos comentario,

cambios) sobre sus artículos y/o en los que colabora.

Actores: Usuario


Postcondición: La opción queda actualizada.


35

CDU.10 Buscar

Descripción: Un usuario puede buscar en el sistema tanto artículos como usuarios

filtrando por los campos que crea convenientes.

Actores: Usuario


Postcondición: Se muestra el resultado de la búsqueda del usuario.


36

CDU 6: Administrador

CDU.9.1 Editar datos de usuario

Descripción: Un administrador podrá modificar datos de un usuario.

Actores: Administrador

Precondición: El Administrador debe estar identificado en la aplicación y el usuario

debe existir.

Postcondición: Los datos del usuario quedan actualizados.


CDU.9.2 Borrar usuario

Descripción: Un administrador podrá borrar una cuenta de usuario de la aplicación.


Precondición: El Administrador debe estar identificado en la aplicación y el usuario

debe existir.

Postcondición: El usuario queda eliminado de la base de datos de la aplicación.


37

CDU.9.3 Editar datos del artículo

Descripción: Un administrador podrá modificar datos de un artículo.


Precondición: El Administrador debe estar identificado en la aplicación y el artículo ha

de existir.

Postcondición: Los datos del artículo quedan actualizados.


CDU.9.4 Borrar comentarios

Descripción: Un administrador podrá eliminar comentarios de un artículo.


Precondición: El Administrador debe estar identificado en la aplicación y el comentario

debe existir en el sistema.

Postcondición: El comentario queda suprimido de la base de datos.



Descripción: Un administrador podrá eliminar un artículo.


Precondición: El Administrador debe estar identificado en la aplicación y el artículo

debe existir en el sistema.

Postcondición: el artículo queda suprimido de la base de datos.


38

CDU.9.6 Crear administrador

Descripción: Un administrador podrá crear otra cuenta de administrador con las

mismas funciones que la suya.


Precondición: El Administrador debe estar identificado en la aplicación y el nombre de

usuario administrador elegido no ha de estar ya usado en otra cuenta de la aplicación.

Postcondición: Una nueva cuenta de usuario administrador queda añadida a la base de

datos.


39

2.3. Análisis de Clases.

Tras la realización de los casos de uso a partir de los requisitos, el siguiente paso es deducir el

diagrama de clases de la aplicación.

Listaremos las clases participantes que veamos convenientes de los casos de uso que hemos

extraído.

CDU.1.1 Registrarse

Descripción: Una persona que no está dada de alta, puede hacerlo rellenando un

formulario.

Clases que intervienen:

o Usuario

CDU.1.2 Login

Descripción: Un invitado accede al sistema.


o Usuario

o Acceso

CDU.1.3 Cerrar sesión

Descripción: Un usuario abandona el sistema.


o Usuario

o Acceso

CDU.2 Modificar datos

Descripción: Un usuario cambia datos de su perfil.


o Usuario

40

CDU.3 Borrar cuenta

Descripción: Un usuario elimina voluntariamente su cuenta del sistema.


o Usuario

CDU.4.1 Crear artículo

Descripción: Un usuario sube un artículo al servidor de aplicación, rellenando un

formulario y asignando usuarios que puedan accederlo y fechas inicio/fin.


o Usuario

o Artículo

CDU.4.2 Modificar artículo

Descripción: Un usuario puede modificar datos relacionados de una artículo que ha

subido, así como añadir/eliminar usuarios y varias fechas de inicio/fin.


o Usuario

o Articulo


Descripción: Un usuario puede eliminar un artículo de la base de datos.


o Usuario

o Artículo

CDU.5 Descargar archivo

Descripción: Un usuario puede descargarse un artículo en el que colabora.


o Usuario

o Artículo

o Archivo

41

CDU.6 Comentar artículo

Descripción: Un usuario asignado puede comentar un artículo.


o Usuario

o Artículo

o Comentario

CDU.7 Ver Historial

Descripción: Un usuario puede consultar el historial de artículos antiguos (las que él ha

subido y en los que él ha participado).


o Usuario

o Historial

CDU.8 Marcar alertas

Descripción: Un usuario puede decidir si quiere recibir alertas (nuevos comentario,

cambios) sobre sus artículos y/o en las que colabora.


o Usuario

CDU.10 Buscar

Descripción: Un usuario puede buscar en el sistema tanto artículos como usuarios

filtrando por los campos que crea convenientes.


o Usuario

o Artículo

o Categoría

CDU.9.1 Editar datos de usuario

Descripción: Un administrador podrá modificar datos de un usuario.


o Administrador

42

CDU.9.2 Borrar usuario

Descripción: Un administrador podrá borrar una cuenta de usuario de la aplicación.


o Administrador

CDU.9.3 Editar datos de artículo

Descripción: Un administrador podrá modificar datos de un artículo.


o Administrador

o Artículo

CDU.9.4 Borrar comentarios

Descripción: Un administrador podrá eliminar comentarios de un artículo.


o Administrador

o Artículo

o Comentario


Descripción: Un administrador podrá eliminar un artículo.


o Administrador

o Artículo

CDU.9.6 Crear administrador

Descripción: Un administrador podrá crear otra cuenta de administrador con las

mismas funciones que la suya.


o Administrador

43

Representación del diagrama de clases UML Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Con él se obtiene una herramienta que sirve para visualizar el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargarán del funcionamiento y la relación entre uno y otro. Utilizaremos el lenguaje estándar UML para representar el diagrama.

Ilustración 3: Diagrama de Clases (Análisis)

http://es.wikipedia.org/wiki/Sistema

44

Detalles sobre relaciones

Podemos observar que la clase Artículo extiende en otras dos llamadas Archivo y Enlace, que poseerán su funcionalidad propia. Esto se ha realizado así para poder dotar a la aplicación de ampliaciones en tipos de artículos en el futuro (vídeos, contenido multimedia, presentaciones, etc…)

La clase Comentario deriva de la relación Artículo-Colaborador, surgiendo únicamente

para las relaciones entre Colaboradores y Artículos.

2.4. Definición de interfaces. La interfaz de usuario es el medio interactivo con que el usuario puede comunicarse con la aplicación y comprende todos los puntos de contacto entre el usuario y el sistema, que deben ser fáciles de entender y accionar, además de brindarle tanto comodidad como eficiencia. La interfaz de nuestra aplicación pondrá al usuario a realizar operaciones con la aplicación y a la vez con su servicio hardware. Las tareas en las que se introducirá al usuario de la aplicación comprenden manipulación de archivos y directorios (subir/borrar archivos del sistema), información de estado (conocer actualizaciones), intercambio de datos y control de acceso. Hay varios puntos a tener en cuenta y que nuestra aplicación ha de cumplir o prevenir:

La aplicación no es más que una herramienta con un objetivo: Cuanto menos dificulte su uso la aplicación al usuario, mejor, pues ha de ser muy intuitiva.

La Ley de Fitt: Esta ley dice que cuanto más grande y más cercano al puntero del ratón es un objeto, más sencillo es el hacer clic sobre él.

Debe ser fácil distinguir los elementos y buscarlos Los elementos que aparecen en pantalla (menús, cuadros de texto…) deberán ser fácilmente distinguibles.

Importante la presentación de información: No se deben colocar demasiados objetos en la pantalla, y los que existan deben estar bien distribuidos. Cada elemento visual influye en el usuario no sólo por sí mismo, sino también por su combinación con el resto de elementos presentes en la pantalla.

Análisis de color: El color comunica información, no es sólo decorativo (ejemplo: reforzar mensajes de error) y debe atraer la atención, pero no cansar después de un rato de trabajo. Será interesante diseñar primero en blanco y negro, y luego añadir el color.

45

Control de interferencias innecesarias: Cuando un usuario está trabajando, su atención está centrada en el trabajo que está realizando por lo que se deberá minimizar la cantidad de distracción y de interferencias por parte de la aplicación. En cada momento, la aplicación tiene un elemento clave en el que centrarse así que este elemento debe ser el centro de la interfaz.

Mostrar claramente la traza de una operación: A pesar de lo comentado en el punto anterior, tampoco debemos ignorar completamente las pequeñas interrupciones (Por ejemplo: ventanas de alerta) puesto que necesitaremos mostrar de alguna forma al usuario si una operación ha resultado exitosa o no.

Deben tenerse en cuenta las habilidades cognitivas y de percepción de las personas: Una de las cosas más importantes a tener en cuenta es reducir la dependencia de las personas de su propia memoria, no forzándolas a recordar cosas innecesariamente (por ejemplo, información que apareció en una pantalla anterior) o a repetir operaciones ya realizadas (por ejemplo, introducir un mismo dato repetidas veces) pues sería ideal que la persona aprenda a usar el sistema lo más pronto posible.

Validar la interfaz de usuario: Una vez acabada su construcción, aun deberemos realizar pruebas, a ser posible con los propios usuarios finales de la misma.

2.5. Plan de pruebas.

La definición del plan de pruebas servirá en el futuro como guía para la realización de todas las pruebas del sistema y permite verificar que el sistema cumple las necesidades establecidas por el usuario, con las debidas garantías de calidad.

Pruebas unitarias: Validaciones necesarias para el correcto funcionamiento de cada

componente creado.

Pruebas de integración: Verificaciones asociadas a los grupos de componentes

implementados.

Pruebas del sistema y aceptación: Comprobaciones a realizar con el cliente para

asegurar que la aplicación funciona correctamente y el cliente se encuentra satisfecho.

En este caso el cliente final debería ser un grupo de investigación, que probará la

aplicación.

46

3. Diseño del Sistema de Información (DSI)

3.1. Definición de la arquitectura del sistema.

En esta sección se definirá la arquitectura de programación que se seguirá, el entorno tecnológico en el que se va a trabajar (lenguajes, tecnologías) y los programas que se usarán para el desarrollo de la aplicación.

Arquitectura

Nuestra aplicación será una aplicación web, esto es, el usuario accederá a un servidor web a través de Internet mediante un navegador, que será el ejecutor de la aplicación. Será enteramente web, tanto usuarios como administradores accederán a ella desde un navegador web. Para desarrollar nuestra aplicación, utilizaremos un estilo de programación por capas, con el objetivo de separar la lógica de negocio, capa de datos y capa de presentación al usuario.

Ilustración 4: Arquitectura en 3 capas

Niveles

Capa de presentación o interfaz gráfica: es la que presenta el sistema al usuario, le comunica la información y la captura. Esta capa se comunica únicamente con la capa de negocio.

Capa de lógica de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él.

http://es.wikipedia.org/wiki/Programa_%28computaci%C3%B3n%29

http://es.wikipedia.org/wiki/Base_de_datos

47

Capa de datos o persistencia: es donde residen los datos y es la encargada de acceder a los mismos. Está formada por un gestor de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.

La ventaja principal de este estilo es que el desarrollo se lleva a cabo en varios niveles y, en caso de que sobrevenga algún cambio, sólo se afecta al nivel requerido sin tener que revisar los demás. En nuestro caso, todas estas capas residirán en un único servidor. Se cree, en un principio, que el volumen de datos será soportado por una sola máquina.

Lenguajes a utilizar

La aplicación va a ser principalmente desarrollada en lenguaje PHP1 (PHP Hypertext Pre-processor) en la fase de negocio y lógica. El motivo de utilizar este lenguaje es debido al requisito de dejar la aplicación instalada en un servidor para que sea utilizado por grupos de investigación (Requisito no funcional 5) y se considera que deberá ser accesible desde cualquier ordenador con conexión sin necesidad de instalar software adicional. El servidor de aplicación dónde instalaremos la aplicación posee PHP y MySQL (Requisito no funcional 1). Otro motivo es la preferencia del alumno en trabajar más sobre dicho lenguaje orientado a web. Para su desarrollo, vamos a usar orientación a objetos con el patrón de diseño Modelo-Vista-Controlador (MVC), que será explicado posteriormente.

1 Sitio web de PHP: http://www.php.net

48

En la capa de presentación utilizaremos HTML2 y CSS3, junto con el framework de JavaScript JQuery4 y la técnica AJAX. Se usarán estas dos últimas tecnologías para que la aplicación web sea más vistosa y la experiencia del usuario sea más agradable. A demás de que el alumno pretende aprender sobre ellas.

Para la parte de tratamiento de bases de datos, utilizaremos consultas SQL mediante el sistema de gestión MySQL5. Dicho sistema ya está instalado en el servidor de aplicación (Requisito No Funcional 1), además de que es una tecnología que comulga bien con PHP y el alumno tiene cierta soltura con ella.

2 Sitio web de w3C sobre HTML: http://www.w3.org/html

3 Sitio web de w3C sobre CSS: http://www.w3.org/Style/CSS

4 Sitio web de JQuery: http://jquery.com

5 Sitio web de MySQL: http://www.mysql.com

http://www.w3.org/html

http://www.w3.org/Style/CSS

http://jquery.com/

http://www.mysql.com/

49

3.2. Diseño de interfaces.

3.2.1. Introducción

Nuestra aplicación será construida como un sitio web, que no necesita de excesivas secciones,

sino que éstas sean accesibles e intuitivas rápidamente.

Todas las secciones de la web irán en un marco común, basado en el diseño de las redes

sociales utilizadas día a día por muchos usuarios y que son de fácil entendimiento.

Algunos ejemplos de interfaces en las que nos inspiramos:

Interfaces 1: Ejemplo 1

50

Interfaces 2: Ejemplo 2

La idea primigenia es que nuestra interfaz contará con un menú horizontal arriba en el que se

separarán las cuatro secciones principales, y que creemos engloban perfectamente la

funcionalidad principal de la aplicación: Inicio, Perfil, Artículos y Búsquedas.

A la izquierda se contará con un menú con acciones que se podrán realizar en cada sección y

en el centro estará el contenido relevante de cada apartado.

51

3.2.2. Prototipos de interfaz

A continuación se van a mostrar los prototipos de interfaz más relevantes de la aplicación. Cabe mencionar que los prototipos son realizados antes de la fase de construcción y que, durante ella, es posible que surjan algunos pequeños cambios. No obstante, la funcionalidad pactada no será alterada y los requisitos se verán cumplidos. Las interfaces se interpretarán en un navegador web, programa que permite ver la información que contiene una página web, ya que puede interpretar el código HTML en el que estará escrita la página web y presentarlo en pantalla permitiendo al usuario interactuar con su contenido. Como hemos dicho, la construcción de la interfaces, de las cuales vamos a mostrar sus prototipos, estarán codificadas en HTML, junto con hojas de estilo css y adornado con imágenes. El resto de interfaces, como formularios de edición de datos, serán creados mediante ventanas

emergentes con la librería JQuery de Javascript, sobre la cual hablaremos más detalladamente

en la fase de construcción.

Nuestra aplicación tendrá una estructura en dos columnas en la mayoría de las secciones:

Interfaces 3: Estructura básica

52

Login

Interfaces 4: Prototipo Login

El login es la primera pantalla de la interfaz que aparece al acceder a la aplicación. En ella

podemos introducir nuestro usuario y contraseña y acceder a la aplicación (“Entrar”) o

registrarnos siguiendo un formulario clicando en “Registrarse”.

Al hacer introducir los datos, podemos elegir si queremos acceder a la aplicación de forma

normal, como usuario, o al panel de administración, si poseemos el permiso adecuado.

La barra de navegación

Interfaces 5: Prototipo Barra Navegación

La barra de navegación es el menú principal de la aplicación. Como hemos señalado anteriormente, está inspirada en la barra similar que existe en las redes sociales. La barra de navegación estará presente en todas las secciones de la aplicación, una vez nos hayamos identificado en la misma como Usuario. Desde ella accedemos a las interfaces de Inicio, Perfil de usuario, Artículos y Búsqueda. Igualmente podemos salir de la aplicación y cerrar la sesión clicando en “Salir”.

53

Inicio

Interfaces 6: Prototipo Inicio

La pantalla de inicio es la primera interfaz que visitamos tras realizar satisfactoriamente la identificación en el sistema. Es meramente informativa, pues en ella podemos ver las últimas novedades que han sucedido en nuestros artículos y comprobar las fechas de caducidad de artículos más próximas, a la izquierda.

54

Perfil

Interfaces 7: Prototipo Perfil

El perfil es nuestra ficha de datos y acciones personal. Se accede desde la barra de dirección en

cualquier sección y es donde se muestran nuestros datos personales, que serán los que verán

de nosotros el resto de usuarios de la aplicación.

En el menú de acciones de la izquierda, podemos cambiar nuestro avatar, o imagen personal

de usuario, editar nuestros datos privados (Nombre, contraseña, correo electrónico etc…) y

gestionar el servicio de alertas vía mail.

En el centro se mostrarán nuestros datos privados actuales y una lista de nuestras

interacciones con el sistema.

55

Artículos

Interfaces 8: Prototipo Artículos

La vista Artículos es una sección dónde se accederá a todos nuestros artículos. Se llega a ella

desde la barra de dirección en cualquier sección.

En el menú de la izquierda tendremos la posibilidad de: listar los artículos de los que somos

autores y acceder a sus fichas, listar los artículos de los que somos colaboradores (y acceder a

sus fichas también), consultar un listado del historial de artículos extintos y acceder a la

posibilidad de subir nuevos artículos.

Las diferentes secciones irán apareciendo en la parte central.

56

Ficha de un artículo

Interfaces 9: Prototipo Ficha

La ficha de artículo es donde se muestra su información y las acciones que los usuarios (con

permiso para acceder a él) han realizado sobre él.

Se accede desde cualquier enlace a un artículo que haya en la aplicación, así como desde

formularios de búsqueda.

En el centro se pueden ver los datos del artículo (Nombre, categoría, versión etc…) y un enlace

al mismo (ya sea un enlace web si es tipo enlace o una descarga si es un archivo).

Debajo del artículo, se podrá ver una lista con los comentarios que los usuarios emiten de él.

Los comentarios tendrán un icono para que puedan ser denunciados por los usuarios si los

consideran inapropiados. Si el usuario visitante tiene permiso, también se mostrara el

formulario para enviar un comentario.

A la derecha se verán los usuarios que el creador ha asignado al artículo (incluido el propio

autor, que aparecerá el primero) y la fecha de extinción del archivo. Si somos el usuario que ha

creado el artículo, tendremos la opción de editar los datos del artículo, añadir más

colaboradores, borrar el artículo o subir una nueva versión.

57

Búsquedas

Interfaces 10: Prototipo Búsquedas

La interfaz de búsqueda es donde podremos localizar artículos buscándolos por nombre,

categoría, autor o fecha de finalización.

Se accede desde la barra de herramientas de arriba, igual que al resto de secciones

mayoritarias.

58

Panel de administración

Interfaces 11: Prototipo Administrador

Si al identificarnos elegimos el rol de administrador y poseemos tales permisos, entraremos al

panel de administración.

Es un panel bastante simple, donde podemos listar todos los usuarios para poder gestionarlos

(borrar, editar), listar todos los artículos del sistema (incluidos los extintos, que pertenecen al

historial) y listar los comentarios que han sido denunciados para borrarlos.

59

3.3. Diseño de clases.

Con el fin de separar en capas la programación para separar la presentación de la lógica de negocio y de la persistencia, se va a utilizar un patrón de diseño llamado Modelo Vista Controlador, o Model View Controller (MVC). Separa las clases básicas de la aplicación en tres componentes: los modelos, las vistas y los controladores. El modelo se encarga del acceso a los datos, bien sea una base de datos u otro tipo persistente de almacenaje, en la Vista se incluye todo lo referente a la interfaz de usuario, y en el Controlador se tiene toda la lógica de negocio.

Ilustración 5: Esquema MVC

MVC es considerado un patrón fácil de llevar a la práctica, muy flexible en estructuración de código, hace uso de la reutilización de componentes, es simple en el mantenimiento de los sistemas, posee desarrollos escalables y está orientado para el uso de técnicas como Ajax. Además el alumno tiene experiencia con el desarrollo de aplicaciones en este formato, lo que le dará más tiempo para centrarse en otras tecnologías que le requieren más aprendizaje. El MVC se adapta fácilmente a la vista en tres capas de nuestra aplicación: Interfaz – Vistas,

Lógica de negocio – Controladores y Persistencia – Modelos.

A continuación mostraremos el diagrama de clases adaptado al modelo, añadiéndole algunas

clases-librería (las clases de base y librerías serán marcadas en rojo). Después explicaremos

cada una de las tres capas por separado, identificando las clases auxiliares del patrón MVC:

60

Ilustración 6: Diagrama de Clases

61

3.3.1. Relación con el diagrama del análisis

En esta fase hemos extendido el diagrama para adecuarlo a la visión MVC, aunque esencialmente, el funcionamiento no varía en exceso. Las clases identificadas y analizadas en la fase de análisis coinciden plenamente con los modelos de la aplicación. Las relaciones entre clases que se habían planteado en el análisis pasarán a estar identificadas en el esquema de base de datos que veremos posteriormente, en vez de estar patentes en las clases, siendo los modelos del diagrama los que tomarán los datos respetando dichas relaciones. Se han añadido las clases correspondientes a las Vistas y los Controladores. Éstas se identifican con las secciones de la aplicación, y manejarán (creando objetos Model) las diferentes funcionalidades (se pueden comprobar en los métodos añadidos) de cada parte de la aplicación. Cabe resaltar tres puntos:

Se ha mantenido la especialización de los Artículos en “Archivos” y “Enlaces” explicada en el análisis. Se ha hecho en esta sección también para mantener la genericidad por herencia de la clase ArticuloModel y así poder añadir cualquier otro tipo de dato en un futuro simplemente añadiendo una clase modelo hija. Esto otorga flexibilidad y permite aumentar la funcionalidad de la aplicación de forma sencilla.

Por otro lado, se ha decidido reagrupar la especialización de los usuarios de “Propietario” y “Colaborador” a simplemente “Usuario”. El rol de cada uno permanece intacto pero será tratado en la fase de negocio.

Al ser un diagrama orientado a MVC, las clases tienen una relaciones más simples que

en un diagrama de clases orientado a objetos convencional. Todas las relaciones son

de herencia y asociaciones binarias 1 a 1.

62

3.3.2. Vista concreta

Modelos

Los modelos son las clases extraídas de los diagrama de caso de uso, en nuestro caso clases

básicas que utilizaremos para conseguir datos de la base de datos, mediante los métodos de

consulta.

Ilustración 7: Diagrama de Modelos (Clases)

La clase ModelBase toma únicamente la conexión con la base de datos (clase Conexión) y

funciona como una superclase que únicamente maneja este apartado y la distribuye (por

herencia) a todas las subclases en vez de trabajar con ella en cada una de ellas.

Podríamos decir que las clases básicas (Modelos) necesarias se corresponden a las que hemos

deducido de los diagramas de casos de uso.

63

Controladores

Los controladores serán los que se encarguen de tratar la lógica de negocio con los datos

obtenidos de los objetos Modelo.

Los métodos responden a eventos, usualmente acciones del usuario e invocan peticiones al

modelo.

Ilustración 8: Diagrama de Controladores (Clases)

MainController es el controlador principal de la aplicación que se encarga de gestionarla y que

controlará ModelBase y ViewBase. Al ser un controlador, deriva de ControllerBase.

ControllerBase es una clase abstracta de la que derivan los demás controladores. Los

controladores se encargarán principalmente de la lógica de negocio, sobre todo de la

validación de datos y de conectar la información obtenida en los modelos con las vistas de la

web.

64

Vistas

Las vistas son las encargadas de presenta el modelo en un formato adecuado para interactuar

(interfaz de usuario).

Ilustración 9: Diagrama de Vistas (Clases)

La superclase ViewBase es la encargada de crear la interfaz con los datos enviados por el

controlador y recogidos de los modelos. Maneja la creación de las plantillas Template Sigma de

PERL. Las subclases que heredan de ella utilizan el atributo protegido tpl para mostrar los

datos requeridos.

65

Clases auxiliares

HTML_Template_Sigma:

o Clase librería de las plantillas PEAR (PHP Extensión and Application Repository)

oficiales de PHP. 6

o La Clase ViewBase posee un atributo de esta clase (y por herencia, todas las

clases de la vista).

LazyLoad:

o Clase librería que sirve para no tener que incluir manualmente las clases a utilizar en nuestro proyecto7. La clase se llama sólo cuando se necesita. Al no incluir todas las clases al inicio de cada página php, estamos ahorrando un proceso, ganando un poco de rendimiento y obteniendo un código más limpio en nuestra aplicación.

Nota: Durante la fase de construcción se añadieron y combinaron métodos en el diagrama de clases. En el Anexo I se discuten estos cambios.

6 PEAR http://pear.php.net

7 Más sobre LazyLoad en Wikipedia (inglés) http://en.wikipedia.org/wiki/Lazy_loading

http://pear.php.net/

http://en.wikipedia.org/wiki/Lazy_loading

66

3.4. Diseño de datos. El diseño de los datos describe la metodología para el diseño de la base de datos relacional. En esta etapa, se parte del esquema obtenido durante el diseño de clases y se obtiene una descripción para la implementación de la base de datos. Para la gestión de la base de datos y los esquemas de la misma, utilizaremos MySQL Workbench, un software creado por la empresa informática Sun Microsystems.

Esta herramienta permite modelar diagramas EER (Enhanced Entity Relationship) para bases de datos MySQL. La aplicación elabora una representación visual de las tablas, vistas, procedimientos almacenados y claves foráneas de la base de datos. También es un soporte para realizar consultas SQL sobre la base de datos, puesto que es posible crear una conexión con el servidor dónde está alojada. Hemos decidido crear la base de datos con esta aplicación, entre otras cosas, porque podemos obtener un esquema ya normalizado. Además, durante las primeras fases del proyecto se decidió no realizar un estudio detallado de la estructura física de almacenamiento de las tablas (diseño físico), pues consideramos que es una aplicación que tiene un tamaño pequeño con respecto a otras.

http://es.wikipedia.org/wiki/Inform%C3%A1tica

http://es.wikipedia.org/wiki/Sun_Microsystems

http://es.wikipedia.org/wiki/Diagrama



http://es.wikipedia.org/wiki/MySQL

67

Se va a diseñar un diagrama de entidad relación (EER) y, a partir de él, se generará un script que cree la base de datos físicamente. Utilizando las herramientas de creación de diagramas de Workbench diseñamos el siguiente esquema:

Esquemas BD 1: Esquema Workbench

3.4.1. Descripción del modelo de datos

A continuación se detallarán las características de las tablas, las reglas que siguen y las decisiones tomadas. La mayoría de las tablas cuentan con un campo id que funciona como clave primaria en las tablas con el fin tomar el rol de clave foránea para las diferentes tablas. Estos campos id clave primaria serán índices del tipo UNIQUE para así mantener la integridad de la BD en determinados campos en los que no puede existir un registro con ese valor repetido. Además, en algunos casos será necesario aplicar el índice de la tabla sobre dos atributos, evitando que la asociación de ambos se repita.

PK: Clave primaria.

NN: Nunca ha de ser nula

AI: Es un dato cuya inserción es automática e incremental.

68

Usuario y TipoUsuario

Tabla que identifica a los usuarios y su rol.

Esquemas BD 2: Usuario y TipoUsuario

En Usuario:

idUsuario: Numero identificativo de cada usuario

login y pass: Sirven como datos de acceso.

Nombre, email, país, sitioWeb: Datos triviales.

idTipo: identificador del tipo de usuario. Está relacionado directamente como clave foránea con la tabla tipoUsuario.

En tipoUsuario:

idTipoUsuario: identifica los roles de la aplicación, Administrador y Usuario.

Nombre: Nombre del rol.

69

Artículo y TipoArticulo

Tabla que almacena todos los artículos de la aplicación (incluidos los del Historial). En tipoArticulo se almacenan los tipos de artículos que tiene la aplicación.

Esquemas BD 3: Articulo y TipoArticulo

En Artículo:

IdArticulo: identificador único del artículo.

nombre: Denominación del artículo.

idTipo: id (de la tabla tipoArticulo) del tipo de Artículo al que pertenece.

IdCategoria: categoría a la que pertenece (relacionado con la tabla Categoría)

descripción: pequeño texto explicativo del artículo.

idPropietario: identificador del usuario creador del artículo.

fechaInicio y fechaFin: lapso de vida del artículo. Un artículo de Historial se identificará porque su fechaFin es anterior a la actual.

ultimaModificacion: fecha de la última modificación. En tipoArticulo:

idTipoArticulo: identifica los tipos de Artículo de la aplicación (Enlace y Archivo)

Nombre: Nombre del tipo.

70

Enlace y Archivo

Tablas que heredan de Artículo y que añaden atributos según sea el tipo del mismo.

Esquemas BD 4: Enlace y Archivo

En Archivo:

IdArticulo: identificador único del artículo al que hace referencia.

Extensión: atributo que contiene la extensión del archivo subido.

En Enlace:

idArticulo: identificador único del artículo al que hace referencia.

enlace: dirección URL donde está el recurso.

UsuarioColabora

Tabla que establece la relación entre un Usuario en rol de Colaborador y un Artículo.

Esquemas BD 5: UsuarioColabora

idUsuario: identificador del usuario colaborador.

idArticulo: identificador del artículo implicado.

haceComentarios: bit que indica si el usuario puede o no comentar (1 sí, 0 no)

71

Comentario

Tabla que identifica un comentario de un usuario en un artículo.

Esquemas BD 6: Comentario

idComentario: identificador único del comentario.

idArticulo: identificador del artículo al que pertenece.

idUsuario: identificador del usuario que lo envió.

Fecha: momento del envío.

Contenido: texto del comentario.

Respuesta: identificador del comentario al que responde, NULL si no es respuesta de ninguno.

Versión

Tabla que controla si un artículo es versión de otro.

Esquemas BD 7: Versión

numVersion: número de la versión.

idArticulo: identificador del artículo.

idVersionado: identificador del artículo “padre” o versionado.

72

Categoría

Tabla para identificar y almacenar las categorías de los artículos.

Esquemas BD 8: Categoría

idCategoría: identificador único de la categoría.

Nombre: Denominación de la categoría.

Alerta

Tabla donde se establecen las opciones elegidas por el usuario para las alertas.

Esquemas BD 9: Categoria

Idusuario: Usuario al que hace referencia.

alertaComentario: bit que guarda si el usuario tiene elegidas las alertas por comentario.

alertaSubida: bit que guarda si el usuario tiene elegidas las alertas por asignación en artículo.

alertaVersion: bit que guarda si el usuario tiene elegidas las alertas por nueva versión.

73

Actualización

Tabla que simplemente guarda las actualizaciones sobre los artículos para mostrarlos en la pantalla de Inicio. Cabe mencionar que no posee relaciones puesto que solo es una tabla informativa.

Esquemas BD 10: Actualización

idUsuario: el usuario implicado en la acción.

idArticulo: artículo actualizado.

fecha: momento de la actualización.

acción: descripción de la actualización.

74

3.4.2. Relaciones entre tablas

Vamos a pasar a estudiar las relaciones de las tablas más importantes (Usuario, UsuarioColabora, Comentario y Artículo), que guardan cierto parecido con las relaciones que poseía el diagrama de clases en el análisis:

Usuario

Esquemas BD 11: Relaciones Usuario

Foránea con idTipoUsuario (campo idTipo).

El campo idUsuario aparece en:

o Alerta, pues es una extensión de las características de un usuario.

75

o UsuarioColabora, pues un usuario puede ser colaborador en un artículo.

o Artículo, pues un usuario es autor de un artículo.

o Comentario, puesto que un comentario tiene un usuario como emisor.

UsuarioColabora

Esquemas BD 12: Relaciones UsuarioColabora

Es una tabla que se utiliza para mostrar el rol de Usuario Colaborador, por lo tanto tendrá

unión (mediante clave foránea) con Usuario y Artículo (puesto que trata de un Usuario que

colabora en un Artículo).

76

Comentario

Esquemas BD 13: Relaciones Comentario

Un comentario siempre pertenece a un Usuario y está lanzado sobre un Artículo por lo que

tiene relación con las tablas Usuario y Artículo.

77

Artículo

Esquemas BD 14: Relaciones Artículo

Foránea con tipoArticulo, mediante el campo idTipo.

Foránea con Usuario puesto que un Artículo es propiedad de un usuario

(idPropietario).

Foránea con Categoría, puesto que un Artículo pertenece a una Categoría

(idcategoria).

El atributo identificador idArticulo aparece en:

o UsuarioColabora, por la relación ya mencionada entre un Artículo y un usuario

con rol de colaborador.

o Comentario, puesto que un Comentario es de un Artículo en concreto.

o Versión, porque un Artículo tiene relación con sus versiones.

o Archivo/Enlace, pues el Artículo tiene que pertenecer a una de las dos clases.

78

4. Construcción del Sistema de Información (CSI)

4.1. Preparación del entorno.

Programas a utilizar

Vamos a pasar a describir algunas de las herramientas software que hemos utilizado para realizar la construcción de la aplicación. Para poder tratar los lenguajes que utilizaremos (PHP, JavaScript), se va a usar un entorno de desarrollo llamado Aptana Studio.

Aptana Studio es un entorno para desarrollo web basado en el conocido entorno Eclipse. Nos permite trabajar con diferentes lenguajes y tecnologías de programación web HTML, JavaScript y CSS, además de poder añadirle plugins gratuitos para trabajar con PHP. Aptana Studio es gratuito, de código abierto y multiplataforma. 8 Hemos utilizado este software puesto que, de igual forma que Eclipse, es muy versátil y tiene suficientes utilidades como para trabajar de forma cómoda.

8 Sitio Web de Aptana http://www.aptana.com/

79

Para la ejecución de la aplicación, se usará XAMPP.

XAMPP9 es un programa que maneja un servidor y que consta de una base de datos MySQL, el servidor web Apache y los intérpretes para lenguajes de script: PHP y Perl. Es libre y bajo la licencia GNU. Usaremos este programa porque es uno de los más extendidos y el alumno posee conocimiento previo de él de su trabajo en la asignatura Programación Internet-Intranet. Aprovechamos la ocasión para mencionar otras herramientas que han sido usadas a lo largo del proyecto aunque no directamente en la fase de construcción del mismo. Para la realización del diagrama de GANTT, hemos utilizado OpenProj

OpenProj es una aplicación que sirve para gestionar proyectos y sus características con diagramas como el de GANT, que es el que hemos utilizado en esta documentación. Es una versión alternativa y libre a Microsoft Project. Puesto que Project es de pago, y el alumno no posee esa licencia, se pensó en buscar una alternativa libre y OpenProj fue la mejor opción encontrada. En el trabajo con diagramas, tanto de casos de uso, como de clases, hemos utilizado la herramienta Microsoft Visio.

Microsoft Visio es un software de Microsoft que consta de varias herramientas para realizar dibujo vectorial. En nuestro caso nos sirve para realizar los diagramas de caso de uso y clases.

9 Sitio Web XAMPP: http://www.apachefriends.org/es/xampp.html

http://es.wikipedia.org/wiki/Servidor

http://es.wikipedia.org/wiki/MySQL

http://es.wikipedia.org/wiki/Servidor_HTTP_Apache

http://es.wikipedia.org/wiki/PHP

http://es.wikipedia.org/wiki/Perl

http://es.wikipedia.org/wiki/GNU

80

En la fase de diseño de interfaces hemos utilizado un sencillo programa llamado Pencil

Pencil10 permite realizar esquemas de interfaces de usuario con sencillas formas para hacernos una idea de lo que será la versión final del sistema en nuestras pantallas. En principio se pensó utilizar directamente alguna herramienta de diseño gráfico (InkScape, Photoshop) pero puesto que el alumno posee conocimiento previo de Pencil por su utilización en la asignatura Proyectos de Informatica, se decidió utilizarla, ya que los bocetos de interfaces no requerían de excesivos detalles.

Tecnologías asociadas a la construcción

Durante la construcción, vamos a ayudarnos de una serie de tecnologías para desarrollar y gestionar el proyecto.

Control de versiones: GIT

Una versión es el estado en el que se encuentra un producto en un momento dado de su desarrollo. Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo. Los sistemas de control de versiones facilitan la administración de las distintas versiones de cada producto desarrollado, así como las posibles especializaciones realizadas. Para este proyecto, vamos a utilizar el software GIT.

Git11 es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente. Al principio, Git se pensó como un motor de bajo nivel sobre el cual otros pudieran escribir la interfaz de usuario. Sin embargo, Git se ha convertido desde entonces en un sistema de control de versiones con funcionalidad plena.

10

Sitio Web de Pencil: http://pencil.evolus.vn/en-US/Home.aspx

11 Sitio Web de GIT: http://git-scm.com/

81

En primera instancia se pensó utilizar el clásico SVN (Subversion) pero el alumno prefirió familiarizarse con GIT por ser una tecnología menos frecuente y de la que ya poseía cierta experiencia. Aptana Studio posee un plugin para utilizar GIT. Pequeñas nociones sobre GIT Su funcionamiento es similar a SVN: Se enlaza el directorio (repositorio) del proyecto con su igual en un servidor y se actualiza según se avance. La principal diferencia con SVN es que permite realizar “ramas” en los desarrollos (división de las tareas entre los distintos desarrolladores que se van juntando y entrelazando), aunque en nuestro caso no va a ser utilizada más que una, puesto que sólo una persona actualiza el servidor. Las órdenes básicas de GIT son:

Commit: Utilizado para actualizar los ficheros del servidor de todo lo que haya sido modificado o añadido, aunque no los actualiza definitivamente. GIT permite dividir los cambios en varios commits antes de su subida definitiva al servidor.

Fetch: Sirve para actualizar los ficheros locales con los cambios que se han realizado desde la última edición.

Push: Sirve para actualizar los ficheros del servidor definitivamente con los commits realizados.

82

4.2. Generación del código de los componentes y

procedimientos

En esta sección explicaremos aspectos del desarrollo de la aplicación incluyendo algunas porciones de código relevantes12. Primeramente, cabe mencionar que se ha utilizado el formato de codificación de caracteres UTF-8 (utf8_general_ci13 concretamente) tanto en la base de datos, como en los ficheros, peticiones etc... puesto que es estándar, y contiene todo tipo de símbolos incluyendo tildes y caracteres especiales amén de ser compatible con las peticiones Ajax. Como se ha mencionado con anterioridad, la aplicación será desarrollada en PHP, siguiendo un patrón de Modelo-Vista-Controlador, sobre una base de datos MySQL. Durante esta sección explicaremos alguna de sus peculiaridades.

4.2.1. Estructura de directorios

Previamente a entrar en la codificación, vamos a organizar los archivos de nuestro proyecto en

una serie de directorios, todos dentro de la carpeta de nuestra aplicación.

La división realizada parte de una propuesta del alumno exclusivamente, puesto que la

mayoría de los proyectos donde ha colaborado poseen una organización de directorios similar.

12

Nota: Las porciones de código mostradas pueden diferir ligeramente con sus equivalentes en las

versiones finales de los archivos reales.

13 Más información sobre la codificación UTF-8 Unicode

http://dev.mysql.com/doc/refman/5.0/es/charset-unicode-sets.html

83

App: Carpeta con los archivos .php de la aplicación. A su vez subdividida en tres

directorios: controllers, con los controladores, models, con los modelos y views, con

las vistas.

Documentation: Carpeta de documentación necesaria, como scripts de base de datos

y esquemas.

Estilos: Carpeta que contiene las hojas de estilo (.css).

Files: Carpeta donde irán a parar los archivos subidos a la aplicación por los clientes de

la misma.

Images: Carpeta donde se guardan las imágenes que utiliza la aplicación.

Js: Carpeta que incluye los archivos Javascript (.js)

Libs: Librerías de PHP utilizadas.

Templates: Carpeta con los archivos de las plantillas .tpl de la aplicación. Hablaremos

de ellos en profundidad más adelante.

84

4.2.2. Implementación del modelo de datos

Previamente a la codificación surge la necesidad de implementar el lugar donde los datos van a residir. Como ya hemos mencionado, usaremos una base de datos MySQL a la que accederemos mediante la aplicación MySQL Workbench. En la fase de diseño creamos un esquema definido con las entidades y atributos necesarios, aunque durante la fase de codificación es posible que este esquema sufra variaciones o adiciones, aunque no cambiarán excesivamente el esquema ya visto. Como comentamos al principio de esta sección, nuestra base de datos utilizará la codificación utf8_general_ci. Este hecho hará que sea necesario adaptar algunos caracteres que haya dentro de la aplicación (tildes sobre todo) para que puedan ser interpretados por el navegador. 14 La base de datos utilizará la tecnología de almacenamiento InnoDB, que soporta integridad referencial. Nos será útil este aspecto, cómo mencionamos un poco más adelante. Tras la creación de la base de datos, ejecutando las consultas de creación derivadas del esquema, rellenamos la base de datos con datos triviales generados automáticamente para poder trabajar con una base, siempre atendiendo a que se cumplan las relaciones establecidas.15 Vamos a ver un ejemplo de sentencia SQL de creación de una de las tablas

CREATE TABLE àrticulo` ( ìdArticulo` int(11) NOT NULL AUTO_INCREMENT, `nombre` varchar(45) NOT NULL, ìdCategoria` int(11) DEFAULT NULL, `descripcion` varchar(45) DEFAULT NULL, ìdPropietario` int(11) NOT NULL, `fechaInicio` datetime NOT NULL, `fechaFin` datetime NOT NULL, ùltimaModificacion` datetime DEFAULT NULL, ìdTipo` int(11) NOT NULL, PRIMARY KEY (ìdArticulo`), KEY `fk_articulo_propietario` (ìdPropietario`), KEY `fk_articulo_categoria` (ìdCategoria`), KEY `fk_articulo_tipo` (ìdTipo`), CONSTRAINT `fk_articulo_categoria` FOREIGN KEY (ìdCategoria`) REFERENCES `categoria` (ìdCategoria`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `fk_articulo_propietario` FOREIGN KEY (ìdPropietario`) REFERENCES ùsuario` (ìdUsuario`) ON DELETE CASCADE ON UPDATE CASCADE,

14

Tabla con los cambios en caracteres: http://www.ascii.cl/es/codigos-html.htm

15 GenerateData.com http://www.generatedata.com Sitio web que genera datos aleatorios.

http://www.generatedata.com/

85

CONSTRAINT `fk_articulo_tipo` FOREIGN KEY (`idTipo`) REFERENCES `tipoarticulo` (`idtipoArticulo`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=44 DEFAULT CHARSET=utf8$$

Puesto que InnoDB rechaza cualquier inserción o actualización que intente añadir un valor de clave foránea en una tabla hija sin un valor de clave candidata en la tabla padre que coincida con esta, marcaremos la operación ON UPDATE (cuando se actualiza una tabla) y ON DELETE (cuando se borra una tabla) de la cláusula FOREIGN KEY, con la opción CASCADE. Así, cuando se borra o actualiza el registro en la tabla padre, automáticamente borra o actualiza los registros coincidentes en la tabla hija.

86

4.2.3. Implementación de la lógica

En esta sección explicaremos detalles de la codificación de la capa de lógica de la aplicación.

Como se ha mencionado, el lenguaje de programación utilizado es PHP, siguiendo un patrón

Modelo-Vista-Controlador.

A continuación hablaremos de la capa de acceso a la aplicación, de los controladores, los modelos, la etapa de conexión con la capa de persistencia y el archivo de configuración.

El acceso

Como ya comentamos en secciones anteriores, el patrón Modelo – Vista – Controlador está compuesto por una superclase Modelo (Modelbase), otra para la Vista (ViewBase) y otra para el Controlador (ControllerBase), heredando de ellas el resto de clases. No obstante, se necesita previamente una clase en la zona de negocio que tome las peticiones a la aplicación e instancie el controlador adecuado (quien lanzará el método que se necesite) recogiendo los parámetros enviados en la petición y procesándolos. De esta manera, además, se protege a la aplicación de peticiones erróneas y se administran los permisos más fácilmente. En la fase de diseño, se tuvo en cuenta la existencia de un MainController para ello, sin embargo, llegados a este punto surge la necesidad de crear otra clase similar para controlar las peticiones cuando no se está logueado en la aplicación. De esta forma además se protege a la aplicación de ataques fraudulentos, como inyecciones, y también crece la modularidad de la aplicación. Así pues, nuestra aplicación contará con dos de estos “Supercontroladores”, uno de ellos el principal ya mencionado (MainController), que gestiona las peticiones del usuario autentificado y otro, al que llamaremos frontal (o FrontController) para el login. Ambos son similares, sólo que Main utiliza clases y métodos para los usuarios autentificados y Front permite a cualquier usuario (identificado o no) llamar a cualquier método de la clase Acceso. El flujo de la aplicación es de dos partes: la zona de Acceso que realiza sus peticiones desde el archivo php llamado index y la zona donde reside el resto de la aplicación, que envía peticiones sobre otro .php llamado backend. Hay que mencionar que en nuestra aplicación, si un usuario posee rol de administrador, accede desde la pantalla de login al panel de administración. La única diferencia sería el método al que el controlador principal llamaría.

87

A continuación, vamos a mostrar el código de estos scripts: Index.php <?php

if (0 > version_compare(PHP_VERSION, '5')) {

die('This file was generated for PHP 5');

}

//Inicio de sesion

session_start();

//Cargamos la configuracion

include 'config.php';

//Archivo de constantes

include 'constants.php';

//Arrancamos el controlador principal

include 'app/FrontController.php';

$app = new FrontController();

$app->main();

?>

Este código (es lo primero que ejecutamos tras acceder a la aplicación) llama al controlador frontal. FrontController.php

[…] class FrontController

extends ControllerBase

{

public function main()

{

/***************************************

* ELECCION DE CONTROLADOR Y ACCION

***************************************/

$controller = $_ENV['config']->get('registroController');

//Elegimos la accion a ejecutar

if(empty($_REQUEST['accion'])){

$action = $_ENV['config']->get('registroAction');

}

else{

$action = $_REQUEST['accion'];

}

/***********************************************

* Ejecuto la accion del controlador

***********************************************/

$this->executeController($controller, $action);

}

[…]

88

El controlador frontal toma de la variable $_ENV['config'] (que se crea en un archivo de configuración que veremos posteriormente) el controlador y la acción por defecto que necesitamos cuando accedemos por primera vez (en nuestro caso necesitaremos “pintar” la página de inicio con el login y un enlace al registro de usuarios). Cuando hagamos login estaremos utilizando métodos del controlador de Acceso. Si estos tienen éxito, crearán la sesión cuyas peticiones ya van sobre otro archivo:

backend.php

<?php

if (0 > version_compare(PHP_VERSION, '5')) {

die('This file was generated for PHP 5');

}

//Inicio de sesion

session_start();

//Cargamos la configuracion

include 'config.php';

//Archivo de constantes

include 'constants.php';

//Arrancamos el controlador principal

include 'app/MainController.php';

$app = new MainController();

$app->main();

?>

Podemos observar que apenas hay diferencias con index.php, excepto porque uno recibe peticiones para el controlador frontal y otro para el principal. MainController.php class MainController

extends ControllerBase

{

public function main()

{

/***************************************

* ELECCION DE CONTROLADOR Y ACCION

***************************************/

if(empty($_REQUEST['controlador'])){

$controller = $_ENV['config']->

get('defaultController');

}

else{

$controller = $_REQUEST['controlador'];

}

//Elegimos la accion a ejecutar

if(empty($_REQUEST['accion'])){

89

$action = $_ENV['config']->get('defaultAction');

}

else{

$action = $_REQUEST['accion'];

}

/*************************************************

* COMPRUEBA QUE ESTE LOGEADO

*************************************************/

if(!($controller != $_ENV['config']->get('authController') &&

$action != $_ENV['config']->get('authLogin'))){

//Ejecuto la autenticacion


//Indico el controlador y accion iniciales

switch ($_REQUEST['rol']){

case 1:

$controller = "Inicio";

$action = "index";

break;

case 2:

$controller = "Administrador";

$action = "index";

break;

}

}

/***********************************************

* Ejecuto la accion del controlador

***********************************************/


}

}

MainController elige a qué controlador llamar, según el rol que hayamos elegido y lo ejecuta.

90

Los controladores

Como ya hemos enunciado, los controladores son los encargados de recibir las peticiones y gestionar los datos. Todos heredan de ControllerBase, una clase abstracta más bien simple donde se instancian las variables de la Vista y el Modelo que usarán todos sus “hijos”. La base es abstracta para que no sea instanciada, puesto que nos interesa que se trabaje con sus clases heredadas. ControllerBase.php abstract class ControllerBase

{

protected $view = null;

protected $model = null;

/**

* Comprueba que el controlador y la accion sean correctas

*

* @param $controlador

* @param $accion

* @return unknown_type

*/

public function testController($controllerName, $action){

$controllerPath =

$_ENV['config']->

get('appPath').$_ENV['config']->

get('controllerPath').$controllerName.'.php';

//Compruebo que el contolador exista

if(!is_file($controllerPath)){

trigger_error(_('El controlador no existe - 404 not

found'), E_USER_ERROR);

}

//Si no existe la clase que buscamos y su accion, tiramos

un error 404

if (!method_exists($controllerName, $action))

{

trigger_error ($controllerName . '->' . $action . '`

no existe', E_USER_ERROR);

}

}

/**

* Ejecuta la accion de un controlador

*

* @param $controlador

* @param $accion

* @return unknown_type

*/

public function executeController($controller, $action = NULL){

//Formamos el nombre del fichero del controlador

$controllerName = $controller.$_ENV['config']->

get('sufixController');

//Si la accion no esta definida, ejecuto la de por defecto

if(empty($action)){

91

$action = $_ENV['config']->get('defaultAction');

}

$this->testController($controllerName, $action);

//Si el controlador y la accion es correcta, paso a su ejecucion

$controller = new $controllerName();

$controller->$action();

}

}

ControllerBase posee dos métodos, testController para comprobar que los datos de la petición son correctos y executeController para ejecutar el controlador. Pasaremos a ver un Controlador cualquiera de la aplicación. A pesar de que ya hemos visto FrontController y MainController, ambos son unos controladores especiales y con una funcionalidad diferente a los que vamos a ver. PerfilController.php //////////////////////////////////////////////////////////////////////

CONTROLADOR DEL PERFIL

///////////////////////////////////////////////////////////

class PerfilController extends ControllerBase

{

////////////////////////////////////////////////////////////////

//Funcion que carga la index

//////////////////////////////////////////////////////////////////////

public function index()

{

//Creamos el modelo

$usuarioModel = new UsuarioModel();

//Llamamos al metodo

$usuario = $usuarioModel->

getDatos($_SESSION['usuario']['idUsuario']);

//Mostramos la plantilla

$this->view = new PerfilView();

$this->view->index($usuario);

}

/////////////////////////////////////////////////////////////////////

//Funcion que maneja la edicion de datos

//////////////////////////////////////////////////////////////////////

public function editarDatos()

{

//Creamos el modelo

$usuarioModel = new UsuarioModel();

//Llamamos al metodo

$usuario = $usuarioModel->

getDatos($_SESSION['usuario']['idUsuario']);

//Mostramos la plantilla

$this->view = new PerfilView();

92

$this->view->editarDatos ($usuario);

}

Como se ha mencionado, cada controlador ha sido asociado a una sección de la aplicación (es por eso que algunos tienen el nombre en plural, por ejemplo: ArticulosController). Vemos aquí el controlador que maneja la sección del Perfil de usuario en la aplicación. Podemos observar que hereda del controlador base, por lo tanto, posee sus atributos y métodos. Hemos mostrado dos funciones, una llamada index, que suelen poseer todos los controladores, pues es la que manda la vista a la pantalla inicial. El otro método mostrado es el que carga el formulario para editar los datos de un usuario. Llama al modelo Usuario, que es el que interactúa con la tabla homónima, y recoge los datos en una variable que le es pasada como parámetro a la vista, que los mostrará en la pantalla para posteriormente editarlos. Todos los controladores funcionan de forma similar. Como característica principal de sus métodos hay que mencionar que no poseen parámetros de entrada, puesto que los toman de las variables globales de PHP $_REQUEST.

93

Los modelos

Ya hemos visto que un controlador hace uso de un modelo para conseguir o insertar datos en la base de datos de la aplicación. La clase base abstracta de los Modelos posee una variable para la conexión a la base de datos de la aplicación, que a su vez y por herencia, es usada en todos los Modelos. ModelBase.php abstract class ModelBase

{

protected $db = null;

public function __construct()

{

$this->db = Conexion::singleton(TRUE);

}

}

El constructor es el que crea la conexión, la cual se instancia y se deja almacenada en una variable protegida para que los Modelos que hereden de ella puedan usarla. Se utilizará un patrón Singleton, que explicaremos más adelante, cuando hablemos de la conexión. Pasamos a ver un ejemplo de modelo. UsuarioModel.php //////////////////////////////////////////////////////////////////////

//MODELO DE GESTION DE USUARIOS

//////////////////////////////////////////////////////////////////////

class UsuarioModel extends ModelBase

{

//////////////////////////////////////////////////////////////////////

//Funcion para obtener datos de usuario

//////////////////////////////////////////////////////////////////////

public function getDatos ($id){

$consulta = $this->db->query (

'SELECT idUsuario, login, pass, nombre, email, pais, idTipo

FROM usuario

WHERE idUsuario = \''.$id.'\' LIMIT 1');

$datos = $consulta->fetch_assoc();

$consulta->close();

return $datos;

}

94

Mostraremos el mismo modelo utilizado por el ejemplo de Controlador anterior. Como vemos, posee un método llamado getDatos que dado un atributo $id devuelve los datos requeridos mediante una consulta SQL a la base de datos. Dichas consultas se ejecutan a través de $this->db->, siendo db el atributo instanciado en la clase padre, la cual ya se ha encargado de crear la conexión. En los métodos de un Modelo podremos realizar todo tipo de sentencias SQL: consultas que devuelvan datos, inserciones de nuevos datos o actualizaciones de datos ya existentes. Puesto que estamos en un entorno multi-usuario (muchos usuarios utilizando la aplicación a la vez y accediendo a la misma base de datos), podrían llegar a surgir problemas de concurrencia. No obstante, nuestra aplicación no está pensada (en principio) para grandes confluencias de usuarios y a pesar de que hemos intentado que nuestras transacciones tengan el mínimo de sentencias SQL, los problemas de concurrencia de nuestra aplicación van a delegar en los niveles de aislamiento que nos proporciona el sistema gestor de la base de datos.

95

La conexión

Para conectar con la base de datos, se ha utilizado una clase Conexion, la cual implementa un patrón singleton para evitar que sea instanciada repetidas veces. La clase Conexion es una abstracción de la clase Mysqli, una de las tres interfaces de programación de aplicaciones (o API) que PHP ofrece para utilizar MySQL. La extensión Mysqli posee una interfaz orientada a objetos. Es la extensión más idónea para trabajar con MySQL versión 4.1.3 y superiores. Como hemos comentado, queremos que la instancia sea ejecutada una sola vez en vez de varias, por lo que se ha creado siguiendo un patrón Singleton. El patrón de diseño singleton (ver el método singleton dentro de la propia clase) está, precisamente, diseñado para restringir la creación de objetos pertenecientes a una clase. Esta introducido aquí para que esta clase sólo tenga una instancia (por usuario) y así proporcionar un punto de acceso global a ella. Pasemos a ver fragmentos del código de la clase: Conexion.php <?php

class Conexion

extends mysqli{

//Instancia de esta propia clase

private static $instancia;

private static $connected;

private static $transaction;

private function __construct($transaction){

//Establece si habra o no transacciones

self::$transaction = $transaction;

}

/**

* Destructor de la clase

*/

public function __destruct(){

if(self::$connected && self::$transaction)

$this->commit();

}

/**

* Funcion que implementa el metodo singleton,

* por el cual solo habra una instancia de

* Conexion durante toda la ejecucion

*/

public static function singleton($transaction = TRUE){

if(!isset(self::$instancia)){

//Conecto con la base de datos

self::$instancia = new self($transaction);

}

http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o

http://es.wikipedia.org/wiki/Clase_%28programaci%C3%B3n_orientada_a_objetos%29

96

return self::$instancia;

}

//Funcion para conectar a la BD

public function connect($dbHost = NULL, $dbUser = NULL,

$dbPass = NULL, $dbName = NULL,

$dbPort = NULL, $dbSocket = NULL){

//Si no se han pasado las opciones por parametro, obtengo las de la

configuracion por defecto

if(empty($dbHost)) $dbHost = $_ENV['config']->get('dbHost');

if(empty($dbUser)) $dbUser = $_ENV['config']->get('dbUser');

if(empty($dbPass)) $dbPass = $_ENV['config']->get('dbPass');

if(empty($dbName)) $dbName = $_ENV['config']->get('dbName');

if(empty($dbPort)) $dbPort = $_ENV['config']->get('dbPort');

if(empty($dbSocket)) $dbSocket = $_ENV['config']->get('dbSocket');

//Realizo la conexion real con el servidor

parent::connect($dbHost, $dbUser, $dbPass, $dbName,

$dbPort, $dbSocket);

//Si la conexion falla, envio un error

if ($this->connect_error) {

trigger_error('Connect Error (' . $this->

connect_errno . ') '. $this->connect_error, E_USER_ERROR);

}

//Si las transacciones estan activas,

//desactivo el autocommit

if(self::$transaction){

$this->autocommit(FALSE);

}

//Indico que ya estamos conectados con el servidor

self::$connected = true;

}

/**

* Abstraccion de mysqli::query

*

* Permite comprobar errores en las peticiones

* */

public function query($sql){

//Si aun no he conectado con la base de datos, realizo la

conexion

if(empty(self::$connected)){

$this->connect();

}

//Ejecuto al consulta

$result = parent::query($sql);

//Si la ejecucion ha sido un exito, devuelvo el resultado

if($result){

return $result;

}

//Si no, disparo un mensaje de error

else{

//Genero el mensaje de error

97

$error = 'Query Error (' . $this->errno . ') '.

$this->error;

//Si las transacciones estan activas,

//deshago toda la transaccion actual

if(self::$transaction){

$this->rollback();

}

//Muestro el error al usuario

trigger_error($error, E_USER_ERROR);

}

}

}

?>

Podemos comprobar que el método connect toma los datos de un archivo con variables llamado config, del que hablaremos más adelante. El Modelbase es el encargado de instanciar la clase Conexion, de la siguiente forma: ModelBase.php public function __construct()

{

//Obtengo la abstraccion de la base de datos con transacciones

$this->db = Conexion::singleton(TRUE);

}

98

El archivo de configuración

Con el objetivo de abstraer todos los datos tanto de base de datos como variables para la programación o direcciones de recursos, se creó un archivo de configuración que es de gran utilidad para la construcción del sistema. A continuación mostraremos un pequeño fragmento: config.php

/**

* Librerías necesarias

*/

include 'libs/Config.php';

$_ENV['config'] = new Config(

Array(

/**

* Base de datos

*/

'dbHost' => '127.0.0.1',

'dbPort' => 3306,

'dbName' => 'clint',

'dbUser' => 'root',

'dbPass' => 'memoria',

[…]

));

En el archivo observamos que se incluye un fichero llamado Config (con mayúscula), del directorio de librerías que se encargará de manejar estas constantes, que se declaran en un vector. Config es una clase que maneja atributos clave=valor. En este fragmento, por ejemplo, se declaran las variables de la base de datos utilizadas por el código que hemos visto antes. La abstracción de estos datos nos resultara cómoda si decidimos migrar la aplicación a otra base de datos, por ejemplo.

99

4.2.4. Creación de las interfaces de usuario

Esta sección extiende de la anterior, puesto que se realizan en paralelo. Hablaremos de las principales herramientas y técnicas usadas en la parte de la interfaz de usuario, así como del código de las Vistas del MVC. Se ha usado HTML fraccionado en plantillas TPL, Javascript (en concreto la librería JQuery y su plugin JQuery UI) y la técnica AJAX. En las siguientes subsecciones pasaremos a ver cada una en profundidad.

Las plantillas TPL

Como hemos comentado, esta aplicación funciona en tres capas. Este hecho nos da la ventaja

de abstraer completamente la parte del diseño web y la parte de negocio (la programación).

PHP puede ejecutarse en el mismo fichero que las órdenes HTML (embebido, al igual que JSP

por ejemplo).Sin embargo, consideramos más limpio hacer una separación entre código PHP

de la fase de negocio y el lenguaje HTML de la fase de presentación, para seguir con el espíritu

modular de MVC y la división en tres capas de la aplicación.

Para eso usaremos plantillas TPL16. Nuestras plantillas tendrán una arquitectura “Push”, que quiere decir que los controladores ejecutan todas las acciones necesarias y luego inyectan el contenido recogido en la plantilla. Inicialmente, cargaremos una plantilla “maestra”, llamada plantillaInicio.tpl. Ella contiene los fragmentos inmutables de la interfaz: La barra de herramientas, el div del contenido y el pie. En ella cargaremos los distintos contenidos según sea una sección u otra. Para ello utilizaremos una de las características más destacadas de estas plantillas, que es que permite que identifiquemos zonas que PHP puede manejar y editar. Las marcaremos con un identificador encerrado por llaves "{}". Vamos a ver un fragmento de la aplicación con esta característica: datosUsuario.tpl <div>

<h1>{NOMBRE_USER}</h1>

<h2>{LOGIN_USER}</h2>

<div id="listaDatosUsuario">

<ul>

<li><b>Direccion email:</b> <a>{EMAIL_USER}</a></li>

<li><b>Pais:</b> {PAIS_USER}</li>

<li><b>Sitio Web:</b> <a>{WEB_USER}</a></li>

</ul>

16

Más sobre TPL http://www.cristalab.com/tutoriales/creacion-y-uso-de-plantillas-o-templates-en-php-

c132l/

100

</div>

</div>

Como vemos, los ficheros tpl son simplemente código HTML, PHP se encarga de parsear las variables ({NOMBRE_USER} por ejemplo) y darles un valor, según sea. En este caso, el controlador ejecuta el modelo, que traerá los datos de la base de datos, que serán asignados a esas variables por las vistas (lo veremos en la siguiente sección). Una ventaja de esto es que no sólo podemos insertar en las variables marcadas texto, como en este caso, sino que también podemos insertar otro fichero .tpl, lo que nos da una capacidad para fraccionar el código HTML como queramos. Un ejemplo: Contenido.tpl <div id="contenido">



<div id="menu01">

{MENUIZQUIERDO1}

</div>





<div id="menu02">

{MENUIZQUIERDO2}

</div>



</div>



<div id="indexDivCentro">

{CONTENIDO}

</div>



</div>

Lo que aquí observamos es la plantilla maestra del contenido de la web, que es donde se

cargaran distintos menús y resultados (que serán ficheros .tpl) según la sección que visitemos.

Resulta de utilidad también la idea de ocultar secciones de un fichero. Podemos manejar

código HTML para trabajar con él más concretamente (otorgándole un nombre con una

etiqueta). Esto nos puede servir para mostrar distintos resultados según sea el estado de una

página. Por ejemplo, si nuestra ficha de artículo no posee comentarios, aparecerá una línea

con la leyenda “No hay comentarios”, pero al enviar uno, esa línea desaparecerá (se ocultará,

más bien) dejando su lugar al comentario. Si nuestra intención es ocultar secciones, podremos

hacerlo nombrándolas de la siguiente forma:

101

Ficha.tpl



<tr>

<td align="right">

Nueva version de <a class="datos" name="ficha"

href="?controlador=Articulos&accion=fichaArticulo&id={IDPADRE}">{ARTIC

ULOPADRE}

</td>

</tr>



La nomenclatura <! - - BEGIN tNombre - -> […] <!- - END tNombre - - >, da un nombre a esa

zona del código y nos permitirá ocultar la sección a voluntad según nos interese (Veremos más

adelante cómo).

Vamos a ver un esquema de cómo se organizan las plantillas tpl del interior de nuestra

aplicación:

Ilustración 10: Esquema de los TPL

El marco global será una plantilla base, que será cargada al principio, y que se verá en

cualquier sección de la aplicación. Cuenta con la barra de herramientas, un contenido y el pie

de página, estructura clásica de muchos sitios web.

En el contenido cargaremos el marco de contenido. Será común para casi todas las secciones

(de no ser así su código iría en el marco global) y consta de una variable menú (que aunque no

se muestra en la imagen, también tiene subdivisiones, dos concretamente) y una variable

resultados, que es dónde se mostrarán los múltiples contenidos principales de cada

subsección.

Los resultados son plantillas como datosUsuario.tpl (vista en el primer ejemplo de esta

sección), que muestran los datos obtenidos por una consulta a la aplicación.

102

Es importante esta nomenclatura puesto que luego nos referiremos a ella durante la siguiente

sección.

Las vistas

La vista base abstracta instancia la plantilla tpl “maestra” de PEAR (PHP Extensión and Application Repository) llamada HTML_TEMPLATE_SIGMA (ya la mencionamos en la fase de diseño), y la propaga a las clases que heredan de ella. Usar esta plantilla nos permitirá utiliza los corchetes para determinar donde sustituirá una variable, como por ejemplo {DATO}, y los bloques de código con nombre especifico, ambas funcionalidades de las que ya hemos hablado antes. ViewBase.php abstract class ViewBase

{

protected $tpl = null;

public function __construct()

{

//Indicamos la ruta de las plantillas

$this->tpl = new HTML_Template_Sigma($_ENV['config']->

get('tplPath'), $_ENV['config']->get('tplCachePath'));

//No errors are expected to happen here

$this->tpl->setErrorHandling(PEAR_ERROR_DIE);

}

}

Veamos ahora cómo sería una clase Vista cualquiera: PerfilView.php //////////////////////////////////////////////////////////////////////

//VISTA DE PERFIL

//////////////////////////////////////////////////////////////////////

class PerfilView extends ViewBase

{

////////////////////////////////////////////////////////////////

//Funcion que carga el inicio

////////////////////////////////////////////////////////////////

public function plantilla ($idUsuario)

{

//Cargamos la plantilla

$this->tpl->loadTemplateFile('/perfil/contenido.tpl');

//******************AVATAR

$this->tpl->addBlockfile

('MENUIZQUIERDO1','tMenuIzquierda1','/perfil/avatar.tpl');

103

$this->tpl->setVariable ('IDAVATAR', $idUsuario);

$this->tpl->touchBlock('tCambiarAvatar');

//******************MENU


('MENUIZQUIERDO2','tMenuIzquierda2','/perfil/menuPerfil.tpl');

//Quitamos ocultacion

$this->tpl->parse('tMenuIzquierda2');

$this->tpl->touchBlock('tMenuIzquierda2');

}

////////////////////////////////////////////////////////////////

//Funcion que carga la index

////////////////////////////////////////////////////////////////

public function index($usuario)

{

//Cargamos la plantilla

$this->plantilla($usuario['idUsuario']);

//******************DATOS USUARIO

//Cargamos plantilla externa


('CONTENIDO','tContenido','/perfil/paginaCentral.tpl');

$this->tpl->setVariable ('NOMBRE', $usuario['nombre']);

$this->tpl->setVariable ('PAIS', $usuario['pais']);

$this->tpl->setVariable ('EMAIL', $usuario['email']);

$this->tpl->setVariable ('WEB', $usuario['sitioWeb']);

//Finalmente, mostramos la plantilla.

$this->tpl->show();

}

//////////////////////////////////////////////////////////////////////

//Funcion que maneja la edicion de datos

//////////////////////////////////////////////////////////////////////

public function editarDatos($usuario)

{


$this->tpl->loadTemplateFile('/perfil/editarUsuario.tpl');

$this->tpl->setVariable ('ID', $usuario['idUsuario']);

$this->tpl->setVariable ('LOGIN', $usuario['login']);



$this->tpl->setVariable ('MAIL', $usuario['email']);



$this->tpl->show();

}

104

Podemos observar que hereda de la clase base, por lo que posee su atributo tpl, al que se accederá como $this->tpl. El método plantilla carga la plantilla general (lo que hemos llamado Marco de Contenido en la sección anterior), index carga el contenido (el “Resultado” del Marco de Contenido) que la sección mostrará nada más entrar en ella y la función editarDatos (la que es llamada desde el controlador mostrado en la sección anterior dedicada a los controladores) que corresponde a la subsección del menú del Perfil de usuario que nos ofrece editar nuestros datos, asignará los resultados obtenidos en el modelo de Usuario (también el previamente mostrado) a las variables del tpl (cargado al principio del método) usando un bucle, con lo que obtenemos un formulario rellenado con nuestros datos actuales para poder cambiarlos. Vamos a explicar más en profundidad este último método, puesto que es similar a otros

muchos dentro de las distintas vistas de la aplicación:

public function editarDatos($usuario)

{

//******************DATOS USUARIO



('CONTENIDO','tContenido','/perfil/editarUsuario.tpl');

La plantilla global contenido.tpl (El Marco de Contenido) ya ha sido cargada (en el método plantilla). Lo que tenemos que hacer ahora es asignar a la variable {CONTENIDO} (lo que correspondería a la sección ‘Resultados’ del Marco de Contenido mostrado en la sección anterior) el tpl que nos ocupa en esta sección, el formulario editarUsuario.tpl, que contendrá las variables que queremos asignar.

[…]



$this->tpl->setVariable ('EMAIL', $usuario['email']);


[…]

Una vez cargada, PHP reconocerá las variables de la nueva plantilla (editarDatos.tpl), por lo que podemos darles el valor que deseemos de la forma que se muestra.


$this->tpl->show();

}

Y por último, mostramos la plantilla. Si quisiéramos que una sección del código permaneciese oculta por la razón que sea o des-ocultarla, deberemos accederla por el nombre dado en el fichero TPL encerrado entre etiquetas <!- - BEGIN - - > y <!- - END - - > como vimos en la sección anterior.

105

Se accede de la siguiente forma:

ArticulosView.php

if ($ficha['idTipo'] == 1){

$this->tpl->hideBlock('tArchivo');

$this->tpl->setVariable ('ENLACE',

$ficha['enlace']);

}

else {

$this->tpl->setVariable ('ARCHIVO',

$ficha['idArticulo'].$ficha['extension']);

$this->tpl->hideBlock('tEnlace');

}

Por defecto todos los bloques aparecen visibles. La orden hideBlock ocultará el bloque, mientras que con setVariable podremos acceder a las variables que en él haya. En este caso, existe una variable {ENLACE} dentro del bloque tEnlace (como hemos dicho, visible por defecto) a la que le damos un valor. Si tEnlace es visible, debemos ocultar tArchivo, pues así lo requiere nuestra aplicación ya que tendrá una variable a la que ahora no tiene sentido acceder.

106

Uso de JavaScript

Como ya comentamos con anterioridad, en nuestra aplicación se usará el framework de JavaScript jQuery (con el plugin JQuery UI), que nos permite manejar eventos, desarrollar animaciones y agregar interacción con la técnica AJAX a nuestra aplicación web. Los archivos librería de JQuery serán insertados en la plantilla base plantillaInicio.tpl de la forma que se insertan en HTML.

plantillaInicio.tpl <script type="text/javascript"

src="./js/uploader/jquery.uploadify.v2.1.4.min.js"></script>

<script type="text/javascript"

src="./js/archivos_JQuery/jquery_form.js"></script>

Generalmente, cada sección de la aplicación posee un archivo .js asociado, que maneja todos los eventos y funcionalidad que JQuery añade. Algunas subsecciones (caso de la sección para subir un artículo o editar datos de usuario) también poseen archivos js propios.

¿Por qué usar JQuery?

Uno de los requisitos primarios de la aplicación era utilizar un framework de desarrollo JavaScript para desarrollar la aplicación ya que las aplicaciones web que no hacen uso de él son menos usables y agradables. La disyuntiva estaba bastante acotada a los dos grandes frameworks JavaScript existentes:

JQuery: Cercano al JavaScript “raso”, comunidad enorme, plugins muy agradables (UI) y buena documentación.

Mootools: Usa programación orientada a objetos, tiene una amplia comunidad y una extensa documentación, variedad de plugins y muy buena organización de la codificación.

Puesto que el alumno no era muy sobradamente conocedor de ninguno, al final nos decantamos por utilizar JQuery, sobre todo por lo atractivo que podría resultar utilizar el JQuery UI en nuestro proyecto.

http://es.wikipedia.org/wiki/AJAX

107

JavaScript I: Peticiones Ajax

AJAX es una técnica de desarrollo web que se ejecutará en el navegador de un visitante de nuestra aplicación a la vez que se ejecuta en el servidor en un segundo plano. De esta forma haremos que sea posible realizar cambios sobre las secciones sin necesidad de recargarlas enteras, ganando en interactividad y velocidad en nuestra aplicación. Cargaremos un marco común (ver sección TPL) y usaremos la tecnología para recargar el contenido de la aplicación. JavaScript es el lenguaje interpretado para efectuar las funciones de llamada de AJAX. Poseemos un fichero llamado function.js que usamos a modo de librería con las dos funciones AJAX que necesitamos. Hay que mencionar que estas funciones no han sido codificadas enteramente por el alumno, sino que han sido tomadas de un proyecto en desarrollo paralelo en el que colabora con varios compañeros.17 Function.js (Método cargar) /* Función para cargar contenido por ajax */

function cargar(enlace, div, js, llamada){

//Mostramos el preloader

$("#preloader").css("display", "block");

$.ajax({

url : enlace,

context: document.body,

success: function(data, textStatus, jqXHR){

//Rellenamos el destino

if(div!=''){

div.html(data);

}

//Hacemos el callback

llamada(data, textStatus, jqXHR);

//Ocultamos el preloader

$("#preloader").css("display", "none");

//Cargamos el js

if(js!=''){

$.getScript('./js/'+js);

}

},

error: function(data, textStatus, jqXHR){



//Mostramos un mensaje

$("#dialog-message").html('Error al cargar los datos');

$("#dialog-message").dialog({

modal: true,

17

Proyecto SgCommander http://www.sgcommander.com/

108

resizable: false,

draggable: false,

position: ['center',200],

title: 'Error',

buttons: {

Ok: function() {

$( this ).dialog( "close" );

}

}

});

}

});

}

Esta función sirve para realizar peticiones AJAX: cargar secciones y/o ventanas JavaScript y

realizar peticiones GET; nosotros la usaremos, entre otras cosas, para cargar en la web las

diferentes secciones de la misma.

Los atributos que usa son enlace (la dirección del recurso que cargará en la sección), div

(el hueco donde cargará el resultado), js (el archivo de JavaScript asociado), llamada

(función callback a ejecutar tras ser cargado).

Veamos un ejemplo de llamada a esta función:

Perfil.js

cargar($(this).attr("href"),

$('#formularioDialogo'),

$(this).attr("name")+'.js',

function() {

//Mostramos el dialogo

$( "#formularioDialogo'" ).dialog("destroy");

$( "#formularioDialogo'" ).dialog({

resizable: false,

draggable: true,

width: 550,

height: 400,

modal: true,

position: ['center',200],

});

});

Esta función se llama cuando clicamos en la sección “Editar datos” del menú de nuestro perfil

personal para que se nos muestre un formulario con nuestros datos y podamos enviarlo.

Así pues, los atributos que usa son:

El enlace es el atributo href del botón, en este caso la llamada es

“?controlador=Perfil&accion=editarDatos” que llama al PerfilController y a su

método editardatos, que busca nuestros datos en un modelo y se los manda a la vista,

que los imprime en el tpl que corresponda.

109

El div donde cargará esos datos es el llamado formularioDialogo, que deberá estar en

el mismo tpl que el botón que hemos clicado para llamar a la función (generalmente

será un div vacío y oculto con css).

El js al que llama será, en este caso, uno que posea el mismo nombre que el atributo

del botón. Imaginemos que el botón se llama “botonDatos”, pues el archivo js que

buscará será botonDatos.js (Utilizamos una cadena “$(this).attr("name")” a la que le

añadimos la extensión con “+.js”).

Y la función que cargará, en este caso, será una que convierta el div donde cargaremos

el resultado en una ventana emergente, utilizando órdenes JavaScript (JQuery).

La otra función AJAX que usamos sirve para enviar formularios a través de POST.

Function.js (Método enviarFormulario)

/* Función que envia formulario por ajax */

function enviarFormulario(formulario, llamada){

//Mostramos el preloader

$("#preloader").css("display", "block");

//Lanzamos la peticion

$.ajax({

type: 'POST',

url: formulario.attr('action'),

data: formulario.serialize(),

// Mostramos un mensaje con la respuesta de PHP

success: function(data, textStatus, jqXHR) {

//Hacemos el callback

llamada(data, textStatus, jqXHR);



}

})

}

La función es utilizada para, siguiendo con el espíritu de AJAX, procesar un formulario sin que se tenga que recargar toda la página. Se envían al servidor los datos requeridos en el formulario, se procesan usando PHP y se nos devuelve una salida dependiendo de los datos introducidos, todo sin cambiar la página en la que estaba el usuario. A esta función se le pasa como parámetro un formulario, el que queremos enviar, y la llamada a la respuesta que necesitemos. Con ello usa el método POST ( ‘type’ ), llama al controlador y método de destino del formulario ( ‘url’ ) y si tiene éxito ( ‘success’ ) devuelve la respuesta. Veamos un ejemplo de llamada a esta función. Para seguir en la línea de lo anterior, veremos una llamada a enviarFormulario cuando clicamos en el botón de enviar los datos editados de nuestro perfil.

110

editarDatos.js

//Formulario

$( "#formEditarDatos" ).submit(function(event) {

event.preventDefault();

enviarFormulario(

$(this),

function(data){

//Alerta

$( "#dialog-message" ).dialog( "destroy" );

$( "#dialog-message" ).dialog({

modal: true,

buttons: {

Ok: function() {


}

}

});

$( "#dialog-message" ).html(data);

$( "#dialog-message" ).dialog( "open" );

});

return false;

});

Cuando el formulario es enviado ( .submit() ) se llama a la función enviarFormulario con los dos atributos:

El formulario será el que nos ocupa (formEditarDatos en el ejemplo)

La función a llamar creará un diálogo modal usando jQuery con la respuesta obtenida.

111

JavaScript II: JQuery UI

Como ya hemos mencionado, JQuery nos permite darle mayor vistosidad a la aplicación y mejorar la experiencia del usuario. Con el plugin JQuery UI ampliaremos esta faceta del framework. JQuery UI aporta interactividad del usuario con sus widgets: elementos de la aplicación, tales como ventanas emergentes redimensionables, botones con interactividad o calendarios. Veamos un par de ejemplos de cómo con simples órdenes, JQuery nos crea atractivas interfaces:

Diálogos: Los hemos visto en la sección anterior:

$( "#dialog-message" ).dialog({

modal: true,

buttons: {

Ok: function() {


}

}

});

Usando este código, convertimos un div en un dialogo modal, con un botón de ‘OK’. Así lo vemos:

Botones: Podemos convertir un enlace <a> en un botón de forma muy simple: $( "button.reportarComentario" ).button()

Los veremos así:

112

Calendario: Convierte un input de un formulario en un calendario interactivo que nos permitirá elegir una fecha.

$( "#fechaF" ).datepicker();

Así aparecerá en nuestra aplicación:

Una de las ventajas que nos ofrece es que JQuery aplica un mismo estilo a todos los widgets, sin tener que preocuparnos de aplicarle estilos CSS a cada uno de ellos. En este caso hemos elegido uno que acompaña al resto de la aplicación.

113

La subida de archivos

Nuestra aplicación permite a los usuarios subir archivos desde su disco duro al del servidor

dónde ésta se aloja. Quizá esta funcionalidad suponía el principal reto de la construcción, pues

planteaba ciertas dificultades.

AJAX es una herramienta de gran utilidad pero no nos ayudaba en este aspecto, pues cuenta

con un problema de seguridad que impide la tarea de cargar archivos. Javascript no tiene

acceso a ningunos de los ficheros cuando se envía el formulario, (la información GET / POST) y

no tiene ninguna manera de acceder al contenido de los ficheros locales por razones de

seguridad. 18

Conocido esto, la idea principal era utilizar algún plugin que estuviese en comunión con

nuestro JQuery, dando nuestra búsqueda fin al encontrar Uploadify, una librería flash. 19

Vamos a ver el ejemplo de código de cómo usarlo:

subirArticulo.js

//Para subir articulo

$('#file_upload').uploadify({

'uploader' : './js/uploader/uploadify.swf',

'script' : './backend.php',

'cancelImg' : './js/uploader/cancel.png',

'expressInstall' : './js/uploader/expressInstall.swf',

'folder' : './files/',

'fileExt' : '*.pdf;*.doc;*.odt;*.docx',

'fileDesc' : 'Tipos de archivos para subir',

'displayData' : 'speed',

'auto' : false,

'multi' : false,

'onComplete' : function (evt, queueID, fileObj, response,

data) {

//Alerta

$( "#dialog_message_archivo" ).dialog( "destroy" );

$( "#dialog_message_archivo" ).dialog({

modal: true,

buttons: {

Ok: function() {$( this ).dialog( "close" );}

}

});

$( "#dialog_message_archivo" ).html(data);

$( "#dialog_message_archivo" ).dialog( "open" );

},

18

Blog en el que tratan el tema. Allí utiliza la misma técnica pero con herramientas diferentes.

http://abrahanapaza.wordpress.com/2009/08/17/tutorial-subir-archivo-con-ajax/

19 Sitio web de Uploadify http://www.uploadify.com/

114

'onError' : function (event,ID,fileObj,errorObj) {

alert(errorObj.type + ' Error: ' + errorObj.info);

}

});

Esta llamada maneja el input de carga del archivo. ‘uploader’ contiene el fichero flash que realiza la subida y ‘script’ es la URL de PHP que realiza la subida (en este caso sólo el archivo base, luego veremos cómo añadirle el resto de los parámetros y llamadas). El resto son características de la subida como el directorio de destino y diversas acciones de la ventana de exploración. ‘OnComplete’ es la función callback, que en este caso crea un diálogo JQuery con la respuesta. El código anterior es la definición, ahora pasaremos a ver la ejecución. Como hemos visto, el archivo necesita de una URL de PHP para realizar la subida, pero necesitamos añadirle un controlador y método adecuado. Además surge la necesidad de enviar más datos con el archivo (para subir un archivo necesitamos rellenar su ficha con su nombre, descripción etc…) por lo que habrá que enviarlos a la vez. Llegados a este punto, descubrimos que la petición Flash que sube el archivo tiene el inconveniente de que no propaga la sesión PHP por lo que debemos hacerlo “manualmente”. Veamos cómo: subirArticulo.js $('#file_upload').uploadifySettings('scriptData', {

'controlador': 'Articulos',

'accion' : 'enviarArticulo',

'PHPSESSID' : $('#session').attr('value'),

'tipo' : '0',

'nombre' : $('input#nombre').val(),

'categoria' : $('input#categoria').val(),

'descripcion': $('textarea#descripcion').val(),

'fechaF' : $('input#fechaF').val()});

$('#file_upload').uploadifyUpload();

Añadimos a ‘scriptData’ lo que queremos mandar: en nuestro caso el controlador y método que harán la subida, el id de la sesión PHP y los datos a enviar del formulario. Después ejecutamos la subida que, ya correctamente, llamará al método (ArticulosController -> enviarArticulo) ArticulosController.php […]

//Tratar el archivo

if (!empty($_FILES)) {

if (is_uploaded_file($_FILES['Filedata']['tmp_name'])) {

$dato = substr($_FILES['Filedata']['name'],

strrpos ($_FILES['Filedata']['name'],

'.'));

copy($_FILES['Filedata']['tmp_name'],

115

$_SERVER['DOCUMENT_ROOT'].'/clint/files/'.$id.$dato);

}

}

[…]

En este fragmento de código trataremos el archivo (del lado del servidor) para tomar datos necesarios de él y renombrarlo como queramos. La subida de archivos se aplica también para los avatares de usuario. Allí además de usar Uploadify del lado del cliente, utilizaremos del lado del servidor, una clase llamada Upload para tratar imágenes. La llamada a uploadify es muy similar a la ya mencionada, por ello omito repetirla, pero la llamada al método es distinta: if (!empty($_FILES)) {

$handle = new Upload($_FILES['Filedata']);

if ($handle->uploaded) {

$handle->file_new_name_body=

$_SESSION['usuario']['idUsuario'];

$handle->file_overwrite = true;

$handle->image_resize = true;

$handle->image_x = 125;

$handle->image_y = 125;

$handle->file_force_extension = true;

$handle->file_new_name_ext = 'jpg';

$handle->image_ratio = true;

$handle->process($_SERVER['DOCUMENT_ROOT'].'/clint/images/avatares/');

if ($handle->processed) {

$mensaje = 'Su imagen ha sido subida y redimensionada

a nuestro tamaño estandar.';

$handle->clean();

} else {

$mensaje = 'Error : ' . $handle->error;

}

}

else{

$mensaje = 'Error al subir';

}

echo $mensaje;

}

Se trata la imagen subida haciendo, por ejemplo, que siempre tenga 125x125 pixeles, sea cual sea su origen o tenga el de nombre de archivo el id del usuario, para así facilitar su identificación.

116

Alertas mediante envío de correos

En nuestra aplicación, un usuario puede marcar (en su perfil) si desea recibir un correo cuando se realizan acciones en los artículos donde colabora (nuevo comentario, nueva asignación, nueva versión). Para ello, en el código, utilizaremos la función PHP mail(). Veamos un ejemplo: ArticulosController.php (Método enviarComentario());

//*********Mandamos el mail **************************************

//Obtenemos mails

$usuarios = $articuloModel->

datosColaboradores($_REQUEST['id']);

//Escribimos el mensaje

$articulo = $articuloModel->datosFicha($_REQUEST['id']);

$message =

'Se ha enviado un comentario al articulo '.$articulo['nombre'].'.';

foreach ($usuarios as $datos) {

//Mandamos a los que tienen marcada la casilla

if($datos['alertaComentario'] == 1){

//Preparamos las cabeceras

$headers = 'From: ' . $datos['email'] . "\r\n";

$headers .= 'Reply-To: ' . $datos['email'] . "\r\n";

$headers .= 'MIME-Version: 1.0' . "\r\n";

$headers .= 'Content-type: text/html; charset=utf-8' .

"\r\n";

//Mandar mail

mail($datos['email'], '[CLINT] Nuevo comentario', $message, $headers);

}

}

La función utiliza los siguientes parámetros: destino, título del correo, mensaje y cabeceras. Utilizaremos el correo que el usuario tiene en su perfil. Hay que mencionar que para que esta funcionalidad esté operativa, el servidor ha de tener un servicio SMTP activo y configurado, pues de lo contrario no será posible el envío.

117

4.3. Ejecución de pruebas.

En esta sección vamos a realizar pequeñas pruebas unitarias de los componentes de la aplicación, para así comprobar que su estructura es correcta y que se ajustan a la funcionalidad requerida. Hay que mencionar que la mayoría de pruebas ya se han realizado durante la construcción.

1- Comprobar si el login incorrecto no da acceso a la aplicación. Funciona correctamente. Si no es un login autentico, vuelve de nuevo a la

página inicial. Cabe mencionar que no distingue minúsculas de mayúsculas.

2- Comprobar si se redirigen correctamente a los lugares indicados según los roles seleccionados en la pantalla principal.

Funciona correctamente. Con un login correcto, si seleccionamos Usuario nos lleva a la aplicación y si seleccionamos Administrador nos lleva al Panel de Administrador.

3- Comprobar que el registro de usuarios funciona correctamente. Funciona correctamente. El formulario es enviado y desde ese momento se da

acceso al login.

4- Comprobar que funcionan las funcionalidades de la sección Perfil. Cambiar Avatar funciona correctamente. La edición de datos personales funciona correctamente. La selección de alertas funciona correctamente.

5- Comprobar que los artículos son listados correctamente según sean artículos subidos

por el usuario, artículo en dónde el usuario colabora y artículos del historial (fecha vencida).

Funciona correctamente. Podemos acceder desde la sección Artículos.

6- Comprobar que es posible subir un artículo nuevo. Funciona correctamente. En el momento de la prueba fallaba la subida de

enlaces pero el fallo fue solventado.

7- Comprobar que se pueden editar los datos del artículo si se tiene permiso. Funciona correctamente. Un formulario actualiza los datos.

8- Comprobar que se pueden añadir usuarios para colaborar en un artículo si se tiene

permiso. Funciona correctamente. El creador del artículo puede añadir los usuarios que

crea oportunos al mismo mediante una sencilla interfaz.

9- Comprobar que se pueden subir nuevas versiones de los artículos. Funciona correctamente. Se puede subir un artículo como versión de otro

desde la ficha del artículo padre.

10- Comprobar que se pueden borrar artículos. Funciona correctamente. El artículo y todo su contenido es borrado.

118

11- Comprobar que se pueden enviar comentarios, borrarlos y denunciarlos cuando se tenga los permisos adecuados.

Funciona correctamente. Los usuarios sin permisos para comentar no pueden hacerlo.

12- Comprobar que las búsquedas de artículos son correctas. Funciona correctamente. Un formulario devuelve los valores buscados.

13- El Panel de Administración funciona.

Funciona todo correctamente: Listar usuarios (borrarlos y editarlos), listar artículos (borrarlos y editarlos) y listar comentarios con denuncias (borrarlos).

119

5. Pruebas de implantación Sistema (IAS)

5.1. Pruebas de Implantación Para hacer las pruebas de implantación del sistema vamos a desplegar paso a paso la aplicación en un servidor externo. Hasta el momento se ha desarrollado el proyecto en local y actualizando un servidor personal mediante GIT. La idea de estas pruebas es testear la capacidad del sistema para ser transportado e instalado en un servidor web externo. No necesita requisitos muy específicos, simplemente ha de ser capaz de ejecutar PHP5 y soportar una base de datos MySQL como la nuestra. Para estas pruebas vamos a usar un servidor web que el alumno tiene en co-propiedad con otras personas donde aloja un foro phpBB. El servidor posee una interfaz de administración CPanel 20 (una de las más extendidas que hay aunque no la única). Las líneas básicas a seguir son:

Subir los archivos al servidor por FTP.

Crear una base de datos MySQL con el script que hemos hecho.

Coordinar la aplicación con la base de datos.

Comprobar que funciona. El primer paso es cargar en el servidor los ficheros que componen la aplicación. Para ello usaremos un software de FTP llamado Filezilla, 21que es bastante utilizado. En nuestro caso cargaremos la carpeta de la aplicación en el directorio raíz, para que sea accedido normalmente

20

Web de CPanel en español http://www.cpanel.com.es/

21 Web de Filezilla http://filezilla-project.org/

120

Una vez subidos los archivos crearemos una base de datos vacía en el panel de administración CPanel, a la que asignaremos un nombre y contraseña de acceso.

CPanel nos pedirá un usuario maestro que maneje la base de datos. En este caso usamos uno ya existente, al que damos todos los privilegios.

121

Así pues, ya tenemos una base de datos vacía creada, ahora debemos rellenarla con las tablas de nuestra aplicación.

Para rellenarla, CPanel nos brinda un gestor llamado PHPMyAdmin, que sirve para gestionar en profundidad bases de datos.

PHPMyAdmin posee una interfaz para ejecutar consultas SQL y otra para importar archivos de script de base de datos .sql. Cualquiera de los dos nos sirve para volcar nuestra base de datos, nosotros vamos a usar la segunda. Exportamos el fichero .sql con nuestro esquema desde MySQLWorkbench y lo abriremos desde phpMyAdmin en la pestaña Importar. Debemos estar

122

alerta de cambiar el nombre que de la base de datos figura en el script por el de la base de datos que hemos creado.

Una vez ejecutada, ya poseemos las tablas en nuestra base de datos.

Ahora debemos llenar las tablas con datos, para ello podemos usar webs como GenerateData 22que pone a nuestra disposición de generar datos aleatoriamente dándole unas pautas. Las ejecutaremos en la sección SQL de phpMyAdmin.

22

http://www.generatedata.com/

123

Una vez tengamos los suficientes datos dentro el siguiente paso es hacer que la aplicación se conecte a la base de datos. Para ello editaremos el archivo config.php (ya hablamos de él en la sección relativa a la construcción).

De esta forma, la aplicación trabajará con la base de datos creada y ya podemos utilizarla.

124

Llegados a este punto, la aplicación estaba finalizada pero no testada. Se decidió que estuviera un tiempo en fase de testeo y corrección/reelaboración. Durante el mismo se descubrieron errores y se cambiaron algunos aspectos de la fase de presentación.

- Cambio en el sistema JQuery de asignación de usuarios, para hacerlo más intuitivo.

Anteriormente se tenía una caja de texto donde se añadían usuarios uno a uno según

coincidiesen con los patrones de búsqueda introducidos. Se cambió a una lista

completa con todos los usuarios, dónde se añaden en grupo los elejidos (se hace

presionando la tecla Ctrl).

- Arreglada la creación/asignación de categorías que daba problemas.

- Corregidos algunos errores menores en la interfaz, como los de la siguiente imagen.

- Al subir nueva versión de un artículo, se hacía complicado distinguir la versión nueva

de la antigua. Se arregló para distinguirlas.

- Hubo problemas al borrar artículo cuando éste tenía una segunda versión. Fueron

subsanados.

Todos estos fallos surgieron de un reiterado uso de la aplicación, con hasta cuatro personas

probando la aplicación en línea.

125

5.2. Pruebas de aceptación Las pruebas de esta sección son realizadas para validar que el sistema cumple los requisitos básicos de funcionamiento esperado. Repasaremos los requisitos funcionales propuestos al principio del proyecto y evaluaremos en qué grado han sido cumplidos. R.1 Un usuario deberá registrarse en la aplicación para poder usarla, rellenando un

formulario. Usará esos datos para acceder al sistema mediante un nombre de usuario y una

clave.

Se cumple correctamente. El usuario se registra en la aplicación y utiliza esos datos para acceder a la misma.

R.2 Un usuario podrá modificar sus datos, pudiendo cambiar incluso su clave de acceso.

También puede añadir (o modificar) su avatar de usuario, una imagen representativa.

Funciona correctamente. El usuario puede cambiar su nombre (el nickname de acceso no), su contraseña, su correo electrónico, su sitio web y su avatar de usuario.

R.3 Un usuario podrá borrar su cuenta en cualquier momento.

Esta implementado. El usuario borra su cuenta y todo lo que de ella extiende (los artículos que ha subido y los comentarios que ha dejado).

R.4 Un usuario podrá subir un artículo para publicarlo en la aplicación, que podrá ser un

archivo completo desde el disco duro de su ordenador - que se alojará en el servidor del

sistema - o un enlace a un recurso que ya esté subido a Internet.

Implementado.

R.4.1 El usuario deberá rellenar algunos datos comunes sobre el artículo, incluyendo

una categoría para el mismo, que ya esté en la aplicación o de nueva creación (se crea

automáticamente a la vez que el artículo).

o Funciona.

R.4.2 El usuario establecerá qué usuarios registrados en la aplicación pueden ver el

artículo (y descargarlo si es un archivo) y cuáles, además de lo anterior, pueden

comentarlo.

o Implementado aunque con cambios. El usuario primero sube el artículo y una vez subido, elige los usuarios que quiere introducir y posteriormente les asigna los permisos. No se hace desde el formulario de subida como en un primer momento se pensó realizar.

126

R.4.3 El usuario establecerá una fecha de inicio (a partir de la cual el artículo estará

visible en la aplicación) y una fecha de caducidad, señalando si, pasada esa fecha, el

artículo será borrado del servidor o movido a la sección Historial.

o / Implementado aunque no todo. La fecha de inicio siempre es la de creación. La fecha final puede ser introducida y en efecto, el archivo caduca pasada esa fecha pero ha sido imposible determinar cómo dar la opción de borrado automático.

R.4.4 Un usuario que ha publicado un artículo con éxito, podrá modificar a posteriori

algunos de los datos que considere oportunos e incluir nuevos usuarios al mismo

siempre que éste aún no haya llegado a su fecha de extinción.

o Implementado correctamente. Existe un formulario para editar los datos del artículo (fecha de fin incluida) y, como hemos dicho, se pueden añadir los usuarios a posteriori de la creación del artículo.

R.4.5 Un usuario que ha publicado un artículo con éxito, podrá subir una nueva

versión del mismo, antes de su fecha de extinción, pasando la versión antigua al

Historial si lo desea.

o Funciona correctamente. La nueva versión indicará en su ficha cuál es su artículo padre. En el formulario de la nueva versión, el usuario podrá elegir si quiere que el articulo original siga vigente hasta su fecha de caducidad o pase al Historial (la fecha de fin pasara a ser la de ese momento).

R.4.6 En todo momento, el usuario podrá borrar inmediatamente del sistema los

artículos que ha subido.

o Implementado. Se borrará el artículo y todos sus comentarios. También se suprimirán las posibles relaciones existentes con artículos que sean versiones del eliminado.

R.5 Un usuario que ha sido asignado para poder consultar un artículo que corresponde a

un archivo, puede descargárselo a su disco duro.

Implementado. Si se trata de un enlace, podrá visitarlo en una pestaña nueva del navegador.

R.6 Un usuario que ha sido asignado para poder comentar un artículo, puede, además de

descargarlo si se trata de un archivo, dejar comentarios sobre el mismo, hasta su fecha de

extinción. Los comentarios podrán ser también contestaciones a comentarios ya enviados por

otros usuarios.

127

Implementado. En efecto se pueden mandar comentarios a los artículos. También se pueden enviar comentarios citando otros a modo de respuesta.

R.7 Los usuarios pueden consultar en todo momento el Historial de artículos en los que ha

estado asignado y/o ha publicado, siendo únicamente de carácter informativo. No podrán

dejar comentarios pero sí descargar archivos, si es posible.

Implementado. Los usuarios pueden consultar su Historial de artículos subidos y de los artículos en los que han colaborado (siempre que estuviesen asignados cuando estos caducaron e indistintamente si su colaboración implicaba comentarios o sólo lectura) y descargar los archivos o ver los enlaces.

R.8 En su perfil, los usuarios podrán marcar o desmarcar una casilla para recibir

actualizaciones (nuevos comentarios, nuevas versiones) en su correo electrónico sobre los

artículos a los que tengan acceso (ya sea porque son propietarios o por ser colaboradores).

Implementado. No obstante no ha podido ser probado en profundidad. El código existe y la funcionalidad es correcta pero es necesario que el servidor de la aplicación soporte el envío de mails.

R.9 Los administradores de la aplicación podrán borrar y editar datos de usuarios y

artículos subidos.

o Funciona.

R.9.1 Los usuarios podrán denunciar comentarios realizados en un artículo por resultar

ofensivos para que sean posteriormente moderados por los administradores.

o Funciona. Los usuarios pueden denunciar un comentario que les resulte ofensivo. Este evento funcionará como contador y el administrador podrá listar los comentarios que hayan recibido alguna denuncia y borrarlos si así lo desea.

R.10 Cualquier usuario puede realizar búsquedas de artículos y usuarios en el sistema.

o Funciona. En la sección de búsquedas, los usuarios pueden rellenar un formulario de búsqueda y obtener resultados sobre artículos.

128

6. Valoraciones del proyecto

6.1. Análisis de duración del proyecto En el Documento de Objetivos del proyecto se marcó una planificación de horas y fechas estimadas. Tras la conclusión, al revisar las estimaciones iniciales se observa que se ha producido un desvío en las mismas. Dichas estimaciones fueron generosas puesto que algunos de los riesgos planteados fueron apareciendo durante las diversas fases y, a pesar de que el horario de trabajo semanal pactado fue cumplido en su mayoría, lastraron algunos aspectos del desarrollo. Inicialmente se cumplió el tiempo de creación de la aplicación, pero se necesitaba algo más para testeo de la misma por lo que se alargó el resultado final.

6.1.1. Cumplimiento del horario semanal

El horario de trabajo semanal constaba, en la estimación, de cuatro horas diarias, de lunes a viernes, y dos horas los sábados estando libre los domingos y días puntuales. El horario fue cumplido, como hemos dicho, a pesar de que finalmente el alumno pudo distribuir también las horas diarias a las mañanas puesto que finalmente no realizó prácticas de empresa en ese horario. No obstante este hecho ya se remarcaba en la planificación.

6.1.2. Duración real & Duración estimada

En esta sección estudiaremos las desviaciones de horas surgidas entre las horas pactadas de

trabajo y las horas reales finales tomadas.

Vamos a mostrar unas tablas que indican cada tarea con su estimación acordada en horas y la

aproximación de horas dedicadas. Al final mostraremos una tabla con las horas totales y un

gráfico para poder comprobar el desvío.

Gestión del proyecto

Tarea Horas estimadas Horas reales (aprox.) Desvío

Gestión del proyecto 15 10 -5 Reuniones 26 12 -14 DOP 40 36 -4 Memoria 30 45 15 Formación 15 20 5 Defensa 10 10 0

Total 136 133 -3

129

Análisis


Requisitos 3 4 1 Casos de Uso 12 12 0

Clases 24 12 -12 Interfaces 8 8 0 Pruebas 6 4 -2

Total 53 40 -13

Diseño


Arquitectura 8 8 0 Clases 24 40 16

Interfaces 16 8 -8 Datos 45 60 15

Total 93 116 23

Construcción


Preparación entorno 12 8 -4 Codificación 200 270 70

Interfaces 100 112 12 Pruebas 8 8 0

Total 320 376 56

Pruebas


Implantación 8 4 -4 Aceptación 4 20 16

Total 12 24 12

Total


Gestión 136 133 -3 Análisis 53 40 -13 Diseño 93 116 23

Construcción 320 376 56 Pruebas 12 24 12

Total 614 673 59

130

Ilustración 11: Grafico comparativo de horas

Vamos a ver un par de gráficos de proporción para observar el reparto del tiempo en relación al global con las horas estimadas y las reales.

Ilustración 12: Gráfico tarta de horas estimadas

Ilustración 13: Gráfico tarta de horas reales

131

La conclusión es que las estimaciones realizadas fueron acordes en las fases de gestión y análisis pero se quedaron cortas en las etapas de diseño y construcción. El principal culpable ha sido la inexperiencia, tanto en gestión de proyectos como en las tecnologías, que eran nuevas para el alumno y su implementación ha resultado más costosa de lo que en un principio se pensó. Una decisión muy importante fue la de exponer a la aplicación, ya completada, a una fase de pruebas públicas de aceptación a gran escala. El proyecto en sí estuvo finalizado en julio de 2011, pero se decidió alargar la fecha de entrega con el fin de realizarlas, para hacer la aplicación más robusta y acercarla al usuario final. El plazo se alargó unos meses más (con el coste economico de nueva matricula que ello suponía) pero los resultados fueron satisfactorios, puliendo muchos detalles y funcionalidades que sin duda hubiesen quedado en el tintero de haberse entregado en la fecha marcada inicialmente (en la siguiente sección explicamos el retraso con más detalle).

6.1.3. Riesgos

En el DOP definimos algunos riesgos que podían lastrar de alguna manera el desarrollo del

proyecto. Algunos de ellos aparecieron en efecto durante el proceso aunque no todos con la

misma gravedad.

Inexperiencia con la tecnología

o Aparición: Durante la fase de construcción principalmente.

o Impacto: Algunas tareas se alargaron irremediablemente con respecto al

tiempo estimado.

o Solución: Se dedicaron algunas horas más a la formación. PHP no era un

lenguaje nuevo para el alumno, pero si JQuery y el trabajo con AJAX.

Lentitud en una toma de decisiones

o Aparición: Fase de diseño.

o Impacto: La fase de diseño estuvo unos días en stand by a la espera de la

nueva definición, por lo que se alargó en el tiempo.

o Contingencia: El alumno meditó durante algunos días y decidió cambiar el

diseño que había realizado hasta ese momento por el actual (que utiliza MVC).

Cambios en el proyecto

o Aparición: Durante la construcción se detectó que algunos requisitos (no

vitales) podrían resultar costosos de implementar.

o Contingencia: Se tomaron otras alternativas o directamente no se realizaron.

132

Cambios en la disponibilidad del tiempo a dedicar

o Aparición: Hacia la fase final y durante la fase de pruebas de aceptación

adicional. El alumno necesito dedicar tiempo a asignaturas pendientes durante

el mes de Junio, por lo que el proyecto pasó a un segundo plano. Además,

durante la fase de pruebas de aceptación se decidió tomar el mes de agosto

libre y posteriormente el alumno estuvo ausente durante octubre y parte de

noviembre por estar fuera del país en un curso de idiomas.

o Impacto: El retraso inicial en junio hizo que fuese el proyecto se retrasase un

tiempo, aunque finalmente se cumplieron los tiempos marcados. Durante la

fase adicional de pruebas, los retrasos no significaron mucho puesto que ya no

existía una restricción de fecha de entrega, por lo que la incidencia fue poca.

Enfermedades

o Aparición: Durante la construcción.

o Impacto: El alumno estuvo enfermo algunos días, aunque no resultó ser un

gran problema para el desarrollo del proyecto.

133

6.2. Conclusiones “No se equivoca el ave que ensayando el primer vuelo cae al suelo… Se equivoca aquella que por temor a caerse, renuncia a volar” "La educación formal te permite tener una vida decente; la auto educación te permite ganar una fortuna." Siendo este proyecto el primero al que el alumno se ha enfrentado por sí sólo ha supuesto un gran reto. La inexperiencia tanto en temas de estimación y planificación como de tecnologías ha jugado malas pasadas durante la creación del mismo, pero de igual forma ha supuesto un aprendizaje adicional y ha sentado unas bases de gran interés de cara al trabajo en futuros proyectos. También ha resultado de gran dificultad la toma de decisiones y la búsqueda de soluciones a problemas pero de igual forma que la inexperiencia ha brindado la oportunidad de mejorar en el aprendizaje, estas dificultades que han supuesto la superación de retos de forma autodidacta y la firmeza en la toma de decisiones también han resultado de gran utilidad formativa. Más particularmente, la utilización de herramientas y lenguajes totalmente nuevos para el alumno suponía alargar el aprendizaje (y por ende, el proyecto entero), pero la sensación final es que, a pesar de no haber sacado todo el jugo que el framework JQuery o las funciones AJAX poseen, para ser la primera experiencia y sobre todo sintiendo el alumno preferencia por el trabajo con la capa de la interfaz, el resultado es positivo. También se han afianzado sus conocimientos del lenguaje PHP.

Como conclusión, añadir que la experiencia ha sido gratificante y altamente instructiva para el alumno. Si bien la aplicación podría haber sido mejor y más grande en cualquier aspecto, el resultado final cumple con los requisitos marcados más importantes.

134

6.3. Futuras Implementaciones A continuación se proponen varias vías de mejora y ampliación de la aplicación.

6.3.1. Correcciones

Mejorar la funcionalidad de las actualizaciones del estado de la aplicación. En esta

memoria se han mencionado muy brevemente puesto que es una funcionalidad

meramente decorativa y no estaban en ningún requisito. Actualmente existe una tabla

a modo de “almacén” donde se recogen las actualizaciones de las acciones globales

más relevantes del sistema (Un usuario ha subido un artículo, un usuario ha añadido a

otro a un artículo, etc…) y se muestran en la pantalla de Inicio de la aplicación. Esta vía

cargaría demasiado la base de datos si la aplicación tuviese mucha afluencia de

usuarios. Una posible solución sería el uso de JSON para realizar esta funcionalidad,

pudiendo prescindir de la tabla.

Mejorar el sistema de comentarios para que sea más patente el uso de anidaciones.

El sistema carece de un sistema de paginación de resultados (listados de artículos y

usuarios etc…). Puesto que inicialmente la aplicación no está pensada para grandes

masas de usuarios y artículos y tampoco era un requisito, se dejó en un segundo plano

esta idea, pero sería un interesante añadido, sobre todo de cara a mejorar la

comodidad del uso de la herramienta.

6.3.2. Mejoras y ampliaciones

Uso más aprovechado de JavaScript para validar campos de formularios.

La aplicación se ha diseñado para que sea factible añadir nuevos tipos de archivos para

subir, como por ejemplo videos, fotos o presentaciones.

Una funcionalidad interesante sería la implementación de una mensajería interna que

sustituyese al sistema de alertas.

135

Anexo I

Diagrama de clases modificado

Durante la fase de diseño se dibujó un diagrama de clases como guía para desarrollar el código

de la aplicación (Sección 3.3.). Durante la fase de construcción, y debido a la inexperiencia, se

tuvo que modificar ligeramente.

La estructura sigue siendo la misma, pero se han cambiado, movido o fusionado algunos

métodos y alguna clase ha resultado absorbida por otra.

A pesar de no ser cambios significativamente grandes, el alumno propuso mostrar un anexo

con los cambios realizados.

Modelos

Figuras Anexos 1: Diagrama Modelos final

136

- En la clase ArticuloModel creció el número de métodos, entre otras cosas porque se

decidió que absorbiera la funcionalidad de HistorialModel (puesto que era una clase

que también trataba con la tabla Artículos) y CategoriaModel (por comodidad), que

desaparecieron.

- EnlaceModel y ArchivoModel ganaron métodos que antes no poseían.

- Las demás clases también ganaron métodos o fueron cambiados.

Controladores

Figuras Anexos 2: Diagrama Controladores final

- ArticulosController aumento sus funcionalidades debido a que se encargó de, además

de manejar la sección Artículos de la aplicación, hacer lo propio con las fichas de

artículos y sus funcionalidades.

- IndexController sustituyo a RegistroController, tomando sus métodos y siendo usada

para dotar de funcionalidad a la página principal (login) junto con AccesoController.

137

Vistas

Figuras Anexos 3: Diagrama Vistas Final

- Al igual que en los controladores, RegistroView fue añadida a una nueva vista llamada

IndexView.

- Muchos de los métodos que simplemente mostraban mensajes echo fueron abstraídos

a métodos llamados publicarMensaje() en algunas de las clases.

138

Anexo II

Manual de usuario

En esta sección trataremos de explicar todas las funcionalidades de la aplicación de la forma

más concisa posible.

1.- Registro y Login

La primera pantalla a la que accedemos es la página de bienvenida.

En esta pantalla podremos introducir nuestro usuario y contraseña para acceder a la aplicación

o entrar al formulario de registro y crear una nueva cuenta.

Si pulsamos en el botón de Registro, accederemos a un formulario estándar dónde nos pedirán

datos personales entre los que destaca el nombre de usuario y la contraseña, que serán

nuestra llave para acceder a la aplicación.

139

Una vez relleno el formulario, pulsamos el botón “Enviar Formulario” que aparece debajo del

mismo. Si nuestros datos son válidos, se nos informara de que nuestra cuenta ha sido creada

satisfactoriamente.

Una vez poseamos una cuenta, podremos utilizar nuestro nombre y contraseña para acceder a

la aplicación.

De vuelta en la pantalla de bienvenida, introducimos los datos.

Observamos que podemos elegir dos roles: Administrador y Usuario. Para acceder a la

aplicación entraremos como usuario. Si poseyéramos permisos de Administrador (sólo un

administrador puede otorgarlos), con nuestro login accederíamos al Panel de Administración.

Al pulsar el botón Conectar, y si los datos son correctos, tendremos acceso a la aplicación.

140

2.- Inicio y barra de navegación

Tras acceder a la aplicación nos encontramos con la página de Inicio.

Esta página es meramente informativa:

- A la izquierda, debajo de nuestro avatar de usuario, podremos consultar un calendario

con los cinco artículos cuya fecha de finalización está más próxima.

- En el centro aparecen actualizaciones globales del sistema relacionadas con los

artículos en los que trabajas.

Algo común a todas las secciones es la barra horizontal situada en la parte alta de la pantalla.

Desde esta barra podremos acceder a las cuatro secciones principales de la aplicación, así

como salir de nuestra cuenta (pulsando “Salir”).

Si en cualquier momento pulsamos “Inicio”, accederemos a la pantalla que acabamos de

repasar.

141

3.- Perfil

Pulsando “Perfil” en la barra de navegación accedemos a una sección dónde se nos muestran

nuestros datos personales.

- Arriba en el centro podemos ver nuestros datos personales, introducidos durante el

registro.

- Abajo en el centro podremos ver una lista de las cinco últimas acciones que hemos

realizado.

En el menú de la izquierda tenemos las siguientes funcionalidades:

- Cambiar Avatar: Nos mostrará un formulario donde podremos elegir una imagen de

nuestro disco duro para usarla como avatar de usuario.

- Editar datos: Se nos mostrará un formulario en el que podremos editar nuestros datos

personales, incluida la contraseña.

142

- Alertas: Aparecerá una ventana emergente con un formulario en el que podremos

seleccionar si queremos que nos llegue un mail informativo cuando sucedan algunas

situaciones específicas en la aplicación.

- Borrar cuenta: Al pulsar esta opción se borra la cuenta de usuario. Es un proceso

irreversible.

143

4.- Artículos

Al pulsar “Artículos” en la barra de navegación, accedemos a esta sección:

En el menú de la izquierda podemos acceder a:

- Mis artículos: La lista de los artículos de los que somos creadores (es la lista que sale

por defecto al acceder a la sección).

- Mis colaboraciones: Lista de los artículos de otros usuarios en los que nos han

permitido colaborar (ya sea en modo lectura o también pudiendo dejar comentarios).

- Mi Historial: En esta sección se pueden ver los recursos de artículos cuya fecha de fin

ya ha pasado. La sección esta sección está dividida en dos: Historial de subidas, con los

artículos extintos subidos por el usuario e Historial de colaboraciones, con los artículos

en los que el usuario colaboraba cuando llegaron a su fecha de fin.

- Subir un artículo: Un formulario de creación de un artículo:

144

o Rellenaremos un formulario con detalles sobre el artículo.

o Podemos elegir una categoría nueva (que será insertada en la aplicación para

futuro uso) o elegir una de un desplegable.

o Luego debemos elegir si queremos que el artículo sea un enlace a un recurso

en Internet (en cuyo caso escribiremos la dirección URL al recurso) o un

archivo de nuestro disco duro (que debemos añadir al formulario).

Una vez subido un artículo, podremos acceder a él desde la lista de nuestros artículos en

Artículos->Mis Artículos.

145

Al acceder a su ficha nos encontraremos con algo como esto:

- En el centro están los datos del artículo y una referencia a su recurso (enlace o

archivo).

- Debajo se listan los comentarios que los usuarios emiten sobre el artículo. Más abajo

hablamos de ellos.

- En la parte superior izquierda podemos ver todos los usuarios asignados a un artículo.

- En la parte inferior izquierda, encontraremos un menú con distintas acciones a realizar

sobre el artículo, si somos su creador:

146

o Añadir colaboradores: Una lista de todos los usuarios de la aplicación que sirve

para añadirlos como colaboradores del artículo. Usaremos la tecla Ctrl

presionada para elegir a más de un usuario y añadirlos en bloque.

Una vez añadidos, podremos darles permisos de escritura de comentarios

clicando en el icono , quitarles permisos de escritura (si los tienen) con

o expulsarles del articulo pulsando . Estos iconos aparecen al lado del

nombre en la lista de la parte superior izquierda.

o Editar Datos: un formulario para editar los datos del artículo, incluida su fecha

de finalización.

o Subir nueva versión: Sirve para subir una versión nueva del artículo visitado

Muestra un formulario similar al de la subida de artículos. En él podremos

elegir si queremos que el artículo versionado pase al historial o permanezca

activo.

147

o Borrar artículo: Se suprime un artículo del sistema. Es un proceso irreversible.

En los artículos, los usuarios con suficientes permisos pueden mandar comentarios. Éstos se

listaran en la parte inferior central.

Debajo de todos ellos, los usuarios con permisos de escritura tienen a su disposición una caja

de texto para escribir un comentario.

148

Sobre cada comentario podemos pulsar el botón “Citar” para responderlo.

Nos aparecerá un formulario con la cita y una caja dónde escribir la respuesta.

Al enviarlo, la respuesta aparecerá de la siguiente forma:

149

5.- Búsquedas

Si accedemos a la sección “Búsquedas” de la barra de navegación, encontraremos un

formulario dónde introducir datos sobre los artículos para poder realizar búsquedas.

Si rellenamos el formulario y pulsamos “Enviar Búsqueda” nos aparecerán los artículos que

coincidan con los criterios elegidos.

151

Anexo III

Actas de reunión En este anexo se adjuntan los documentos correspondientes a las actas de reunión mantenidas entre alumno y tutor para el control del desarrollo del proyecto.

152

Wiki para compartición de archivos en grupos de trabajo

2010-2011

Acta de reunión

Proyecto: Wiki para compartición de archivos en grupos de trabajo

Fecha: 30-11-2010

Lugar: Universidad de La Rioja

Hora inicio: 18:30

Hora finalización: 19:15

Asistentes: Jesús María Aransay (Tutor)


Orden del día: Generalidades del proyecto

Documentos

relacionados:

Temas tratados: 1. Primeros pasos del proyecto

2. Aspectos generales del proyecto

153


2010-2011

Acta de reunión


Fecha: 1-2-2011


Hora inicio: 11:30




Orden del día: Primeros pasos de DOP

Documentos

relacionados:

Temas tratados: 1. DOP: Dudas sobre él y primeros pasos.

2. Acordar el sistema de actas

154


2010-2011

Acta de reunión


Fecha: 8-2-2011


Hora inicio: 16:45




Orden del día: Revisión del primer DOP

Documentos

relacionados:

Primer borrador del DOP

Temas tratados: 1. DOP: Corrección del archivo del DOP previamente enviado vía email.

2. Línea a seguir para mejorarlos y corregir pequeños detalles.

155

Wiki para compartición de grupos de trabajo

2010-2011

Acta de reunión


Fecha: 14-2-2011


Hora inicio: 18:00




Orden del día: Finalización del DOP

Documentos

relacionados:

Segundo borrador del DOP

Texto de requisitos del sistema

Temas tratados: 1. DOP: Acordada la finalización con el tutor.

2. Pulidos los requisitos funcionales y no funcionales.

3. Línea a seguir en el trabajo con casos de uso.

156


2010-2011

Acta de reunión


Fecha: 21-2-2011


Hora inicio: 12:00




Orden del día: Revisión de los Casos de uso y clases

Documentos

relacionados:

Texto de Casos de Uso y clases asociadas

Temas tratados: - Revisión y finalización del trabajo con casos de uso.

- Revisión de las clases propuestas.

157


2010-2011

Acta de reunión


Fecha: 24-2-2011


Hora inicio: 12:00




Orden del día: Revisión del diagrama de clases

Documentos

relacionados:

Diagrama de clases

Temas tratados: - Discutidas asociaciones y errores en el diagrama de clases.

- Vislumbradas opciones para corregirlo.

158


2010-2011

Acta de reunión


Fecha: 16-3-2011


Hora inicio: 11:00




Orden del día: Diseño de la arquitectura del sistema

Documentos

relacionados:

Documento de diseño de srquitectura

Temas tratados:

- Correcciones en la sección de Diseño de arquitectura del sistema.

159


2010-2011

Acta de reunión


Fecha: 20-03-2011


Hora inicio: 11:00




Orden del día: Interfaces y diagrama de clases

Documentos

relacionados:

Bocetos de interfaz

Diagrama de clases

Temas tratados: 1. Corregidos bocetos de interfaz

2. Propuesto material para los diagramas

160


2010-2011

Acta de reunión


Fecha: 08-06-2011


Hora inicio: 12:00




Orden del día: Documentación: Sección Construcción

Documentos

relacionados:

Borrador de la sección de construcción de la documentación

Temas tratados: 1. Revisión de la primera versión de la sección de construcción de la documentación.

2. Puesta al día en avance del proyecto.

3. Formas de ampliar la documentación.

161


2010-2011

Acta de reunión


Fecha: 06-07-2011


Hora inicio: 12:00




Orden del día: Documentación: Pruebas unitarias

Primer vistazo a la aplicación.

Documentos

relacionados:

Borrador de la documentación

Temas tratados: 1. Plan a seguir con las pruebas del sistema.

2. Primera demostración de la aplicación.

Tras esta reunión se tomó la decisión de postponer la entrega hasta el primer cuatrimestre de 2011/2012 a fin de realizar las pruebas de aceptación del sistema. Se volvería al trabajo en septiembre de 2011.

162


2011-2012

Acta de reunión


Fecha: 15-09-2011


Hora inicio: 12:00




Orden del día: Muestra de la aplicación ya instalada en el servidor

http://www.campodesuenos.es/clint/

Documentos

relacionados:

Temas tratados: 1. Primer vistazo a la aplicación online.

163


2011-2012

Acta de reunión


Fecha: 23-11-2011


Hora inicio: 12:00




Orden del día: Primera lista de correcciones a realizar

Documentos

relacionados:

Temas tratados: 1. Listado de mejoras para la aplicación derivado de las pruebas de aceptación del tutor

del proyecto, conjunto con las pruebas ya realizadas durante el tiempo en el que el alumno estuvo ausente, realizadas por terceras personas.

164


2011-2012

Acta de reunión


Fecha: 6-12-2011


Hora inicio: 12:00




Orden del día: Vistazo definitivo a la memoria.

Documentos

relacionados:

Memoria final.

Temas tratados: 1. Correcciones sobre la memoria.

2. Rellenado de documentos necesarios para la entrega.

TRABAJO FIN DE ESTUDIOS - biblioteca.unirioja.es · A mi familia, por el apoyo ... El software...

Documents

Transcript of TRABAJO FIN DE ESTUDIOS - biblioteca.unirioja.es · A mi familia, por el apoyo ... El software...