trabajo fin de estudios - unirioja · 2012-10-25 · diagrama de gantt ..... 26 3.1. diagrama de...

TRABAJO FIN DE ESTUDIOS

Migración de infraestructura web a una nuevaestructura basada en frameworks

Ana Ruiz Parmo

PROYECTO FIN DE CARRERA

Tutor: Angel Luis Rubio García

Curso 2011-2012

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

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

Migración de infraestructura web a una nueva estructura basada enframeworks, trabajo fin de estudios

de Ana Ruiz Parmo, dirigido por Angel Luis Rubio García (publicado por la Universidad deLa 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.

FACULTAD DE CIENCIAS, ESTUDIOS AGROALIMENTARIOS E INFORMÁTICA

PROYECTO FIN DE CARRERA

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

Migración de infraestructura web a una nueva

estructura basada en frameworks

Alumno: Ana Ruiz Parmo

Director: D. Ángel Luis Rubio García

Logroño, 8 Junio 2012

3

RESUMEN Esta memoria recoge los aspectos más relevantes del proyecto desarrollado

“Migración de infraestructura web a una nueva estructura basada en

frameworks”. Estos aspectos son desde la planificación del proyecto, la recogida

de requisitos, el diseño o los problemas surgidos a la hora de la implementación.

El desarrollo de este proyecto surge de la necesidad de la empresa Digi

International Spain S.A. de portar la infraestructura actual que tenían a una

nueva basada en frameworks.

5

Índice General

1. Introducción .................................................................................................................. 11

2. DOP: Documento de Objetivos del Proyecto .............................................................. 13

2.1. Antecedentes ......................................................................................................... 14

2.2. Objetivos ................................................................................................................ 15

2.3. Descripción ............................................................................................................. 15

2.4. Alcance ................................................................................................................... 16

2.5. Recursos humanos ................................................................................................. 16

2.6. Tecnología y arquitectura ...................................................................................... 17

2.6.1. Tecnología ....................................................................................................... 17

2.6.2. Arquitectura .................................................................................................... 19

2.7. Planificación ........................................................................................................... 20

2.7.1 Estructura de descomposición del Proyecto (EDP) .......................................... 20

2.7.2. Diccionario de la EDP ...................................................................................... 20

2.7.3. Estimación del proyecto .................................................................................. 24

2.7.4. Calendario ....................................................................................................... 25

2.7.5. Diagrama de Gantt .......................................................................................... 26

2.8. Riesgos.................................................................................................................... 27

3. Análisis .......................................................................................................................... 31

3.1. Descripción de la aplicación ................................................................................... 32

3.1.1 Zend Framework .............................................................................................. 33

3.1.2 Dojo Toolkit ...................................................................................................... 34

3.2. Análisis de requisitos .............................................................................................. 35

3.2.1 Requisitos no funcionales ................................................................................ 35

3.2.2 Requisitos funcionales ..................................................................................... 37

3.2.2.1 Actores ..................................................................................................... 37

6

3.2.2.2 Diagrama de Casos de Uso ....................................................................... 38

3.2.2.3 Especificación de Casos de Uso ................................................................ 39

3.3. Definición de módulos de aprendizaje ................................................................... 43

4. Diseño ........................................................................................................................... 47

4.1. Arquitectura de los frameworks ............................................................................ 48

4.1.1 Arquitectura de Zend Framework .................................................................... 48

4.1.2 Arquitectura de Dojo Toolkit ........................................................................... 52

4.2. Llamadas asíncronas con Zend Framework y Dojo ................................................ 53

4.3. Estructura interfaz de usuario y sus componentes ................................................ 56

4.4. Módulos ................................................................................................................. 59

4.5. Bases de datos ........................................................................................................ 64

5. Implementación ........................................................................................................... 69

5.1. Estructura del proyecto .......................................................................................... 70

5.1.1 Estructura de directorios ................................................................................. 70

5.1.2 Integración Zend Framework - Dojo ................................................................ 71

5.1.3 Componentes del patrón MVC ........................................................................ 72

5.2. Componentes de Dojo Toolkit................................................................................ 75

5.3. Estructura principal ................................................................................................ 77

5.4. Menú principal ....................................................................................................... 80

5.5. Módulos ................................................................................................................. 82

5.5.1 Mapa de dispositivos ....................................................................................... 82

5.5.2 Servidor Linux ................................................................................................... 87

5.5.3 Funciones genéricas ......................................................................................... 88

5.6. Pruebas ................................................................................................................... 90

6. Gestión del proyecto .................................................................................................... 91

6.2. Duración real del proyecto ..................................................................................... 92

6.3. Comparación tiempos estimados – tiempos reales ............................................... 94

6.4. Motivos del desfase ............................................................................................... 95

7

7. Conclusiones ................................................................................................................. 97

8. Bibliografía .................................................................................................................... 99

9

Índice de imágenes

2.1. Arquitectura de la aplicación ................................................................................. 19

2.2. Estructura de descomposición del proyecto .......................................................... 20

2.3. Diagrama circular estimación de horas .................................................................. 24

2.4. Calendario de trabajo ............................................................................................. 25

2.5. Diagrama de Gantt ................................................................................................. 26

3.1. Diagrama de Casos de Uso ..................................................................................... 38

3.2. Diagrama de Actividad (Identificarse) .................................................................... 41

4.1. Patrón MVC en Zend Frameworks ......................................................................... 49

4.2. Estructura de directorios ZF ................................................................................... 49

4.3. Controlador ZF........................................................................................................ 50

4.4. Componentes de Dojo Toolkit................................................................................ 53

4.5. Prototipo de la estructura ...................................................................................... 56

4.6. Prototipo AccordionContainer ............................................................................... 57

4.7. Prototipo TabContainer ......................................................................................... 57

4.8. Prototipo modulo Mapa de Dispositivos ............................................................... 60

4.9. Prototipo Build Server List...................................................................................... 62

4.10. Prototipo Release Tags ......................................................................................... 63

4.11. Tabla builds .......................................................................................................... 65

4.12. Tabla Client (Cliente) ............................................................................................ 65

4.13. Tabla Dut (Dispositivo) ......................................................................................... 66

4.14. Configuración Base de Datos ............................................................................... 66

4.15. Zend_db_select .................................................................................................... 67

4.16. Método fetchAll() ................................................................................................. 67

10

4.17. Método fetchAll() [2]............................................................................................ 68

5.1. Estructura de directorios. ....................................................................................... 70

5.2. Configurar Dojo. ..................................................................................................... 71

5.3. Ejemplo clase del Modelo. ..................................................................................... 73

5.4. Paso información Controlador - Vista. ................................................................... 75

5.5. Creación widget, declarativa. ................................................................................. 75

5.6. Creación widget, programática. ............................................................................. 76

5.7. Creación estructura con layouts. ........................................................................... 78

5.8. Layout.phtml. ......................................................................................................... 79

5.9. Función Ajax en el Controlador .............................................................................. 81

5.10. Cambiando estilo Menú principal ........................................................................ 82

5.11. Menú principal ..................................................................................................... 82

5.12. Incluir un archivo .js en una vista ......................................................................... 83

5.13. Consulta a la tabla Dut de la BD ........................................................................... 84

5.14. Acción del controlador mapofdevicesController ................................................. 85

5.15. Función genérica llamada Ajax ............................................................................. 89

6.1. Diagrama circular estimación real de horas ........................................................... 92

6.2. Calendario de trabajo real ...................................................................................... 93

6.3. Tabla comparación de tiempos .............................................................................. 94

6.4. Diagrama tiempos estimados – tiempos reales ..................................................... 95

11

1 INTRODUCCIÓN La presente memoria plasma el trabajo llevado a cabo en el desarrollo del proyecto con nombre “Migración de infraestructura web a una nueva estructura basada en frameworks”. Se trata de la migración de una aplicación web ya existente en la empresa que propuso el proyecto. Es una aplicación usada por los propios trabajadores, llamada “Web Interface for Automation of Test Plans”. Necesita ser restructurada basándose en dos frameworks.

No se va a desarrollar una aplicación nueva, pero si se va a crear una estructura

desde cero y a partir de ese esqueleto se irá desarrollando la aplicación siempre

basándose en la ya existente.

El aprendizaje de los dos frameworks y de su adaptación a las necesidades de la

aplicación son puntos importantes de este proyecto.

13

2 DOP: Documento de Objetivos del Proyecto Documento muy importante en cualquier proyecto. Se realiza al comienzo del

Proyecto y se especifican puntos como los antecedentes del proyecto, el alcance,

los riesgos, el plan de trabajo estimado, la estructura de descomposición de

tareas,…

14

2.1. Antecedentes

Digi International es una empresa internacional con sede en Minnetonka en el

estado de Minnesota (Estados Unidos). Se dedica a la fabricación de productos y

tecnologías que facilitan la conexión de dispositivos a la red (LAN), empresa líder

en soluciones ConnectWare. Alguno de estos productos son servidores de

dispositivos integrados, servidores serie, dispositivos para administración de

consola o módulos embebidos. Todos estos productos se distribuyen

principalmente a los sectores hospitalario, financiero y médico.

La única oficina Española se encuentra en Logroño, en ella es en la que he

desarrollado mi proyecto. Consta de un equipo de Ingenieros Electrónicos los

cuales desarrollan los dispositivos propiamente dichos y por otro lado también

tienen un equipo de Ingenieros Informáticos, ellos se encargan de desarrollar

software para testear esos dispositivos.

La oficina tiene una infraestructura web interna, para el uso exclusivo de los

trabajadores, esta infraestructura ofrece un control sobre los test realizados,

herramientas para programar test, control sobre las tareas efectuadas o las

tareas por efectuar, entre otras actividades. De ahí surge el proyecto ya que el

sistema existente tenia una sobrecarga de trabajo en el lado del servidor, por ello

se pensó migrar la infraestructura a una nueva basada en frameworks. A parte

de que esto daría solución al problema, también se beneficiaria de todas las

mejoras o ventajas que aporta el uso de frameworks, por ejemplo: la

compatibilidad con todos los exploradores, el mantenimiento o un mejor y más

rápido desarrollo.

15

2.2. Objetivos

Con este proyecto se pretenden alcanzar varios objetivos, que los describo a

continuación:

� Familiarizarse con hacer un proyecto, ya que a lo largo de la carrera se

estudia mucha teoría sobre el desarrollo de un proyecto pero no se lleva

a la práctica con individualidad.

� Adquirir conocimientos sobre los temas y herramientas que son

necesarios utilizar para la realización del proyecto y que no se han

estudiando en la universidad.

� Aplicar los conocimientos adquiridos en el transcurso de la carrera.

� Crear y desarrollar una nueva infraestructura basada en los frameworks

Dojo Toolkit y Zend Framework, para realizar la migración del sistema

existente en la empresa.

� Realizar la defensa del proyecto en fecha estimada.

� Aprobar el proyecto para así poder terminar la carrera y seguir ampliando

conocimientos o poder empezar en el mundo laboral.

2.3. Descripción

Este proyecto consiste en portar una infraestructura web actual en una nueva

infraestructura basada en frameworks. Para realizar esto es necesario conocer e

investigar como podemos adaptar nuestro sistema a algún Framework conocido

y preservar la lógica actual de usuario.

El sistema actual tiene características particulares que implican una sobre carga

de trabajo en el lado del servidor (como ya he explicado anteriormente), ya que

el sistema utiliza un servidor central. Por esta razón, la infraestructura debe estar

libre de procesos innecesarios, y usar el lado del cliente para realizar la mayoría

del trabajo, minimizando la transferencia entre el servidor y el cliente.

16

Por eso se decidió el uso de dos frameworks no comerciales, uno destinado al

lado del cliente y otro destinado al lado del servidor, los cuales suplieran las

carencias del sistema.

Para la parte del cliente se escogió el framework “Dojo toolkit”, un framework

potente, robusto y versátil.

En el lado del servidor se eligió el framework “Zend Framework”, que por el

contrario, es un framework simple y eficiente. Características necesarias para el

objetivo de minimizar la carga del servidor.

En el apartado de Tecnologías empleadas y arquitectura (2.6 Tecnología y

arquitectura) se amplia la información sobre los dos framework y el porqué de su

elección.

2.4. Alcance

Al finalizar este proyecto lo que se tendrá es lo siguiente:

� La migración de la antigua infraestructura web a una nueva basada en

frameworks.

� Manual de instalación de los dos frameworks.

� Memoria del proyecto

� Presentación del proyecto

En cuanto al alcance de los módulos de la aplicación, desde un principio no se

acordó la cantidad de módulos que se iban a realizar. Lo más importante es

conseguir realizar la estructura básica, integrar los dos frameworks, y hacer una

separación entre una parte pública y otra parte privada.

2.5. Recursos humanos

A continuación, se exponen las personas implicadas en este proyecto.

o Ana Ruiz Parmo: proyectante y directora del proyecto.

17

o Ángel Luis Rubio: tutor del proyecto. Se encarga del asesoramiento y

orientación sobre los aspectos del proyecto fin de carrera.

o Digi International S.A.: cliente, empresa que propone el proyecto.

o Carlos Marín: tutor de la empresa. Se encarga del seguimiento del

proyecto y la orientación del mismo.

o Arturo Buzarra: desarrollador de la antigua estructura web. Se encarga de

orientación sobre los aspectos técnicos o conceptuales del desarrollo de

la nueva estructura.

o Miembros del tribunal: grupo de profesores encargados de la evaluación

del proyecto.

2.6. Tecnología y arquitectura

2.6.1. Tecnología

Las tecnologías que se van a usar para la realización del proyecto se describen a

continuación:

� Apache: es el servidor web escogido para para el desarrollo de la

aplicación web.

(Apache v2.2.17)

� MySQL (v5.5.8)

� PHP: lenguaje de programación elegido para la creación de la aplicación

web. Se decidió este lenguaje, a parte de porque la aplicación que ya

tenían estaba desarrollada con PHP, ZF (Zend Framework) es un

framework para desarrollar aplicaciones con PHP 5.

(PHP v.5.3.5)

� Dojo Toolkit: es un framework que contiene APIs y widgets (controles)

para facilitar el desarrollo de aplicaciones Web que utilicen tecnología

AJAX.

18

Dojo Toolkit se escogió por ser un framework potente, con abundante

contenido y relativamente fácil y rápido de aprender, dentro de lo que

conlleva aprender a manejar un framework.

� Zend Framework: es un framework de código abierto para desarrollar

aplicaciones web y servicios web con PHP 5. Los componentes de este

framework tienen una débil dependencia entre ellos lo que permite

utilizar sus componentes por separado, ZF es una implementación que

usa código totalmente orientado a objetos. Algo que ofrece este

framework es el uso del patrón MVC, el cual vamos a usar en el proyecto.

Otra característica interesante para la aplicación es que ZF es simple y no

requiere una estructura demasiado complicada, que involucren una gran

cantidad de archivos, para elaborar una página de ‘Hello World’.

Los dos frameworks son compatibles con todos los navegadores, requisito

importante a la hora de implementar nuestro sitio web.

� Navegadores: la aplicación se va a usar en distintos navegadores, ya que

no todos los usuarios de la aplicación (trabajadores de la empresa)

tendrán el mismo navegador como “favorito”. Los navegadores usados

serán:

o Internet Explorer 8 y 9

o Firefox (ultima versión)

o Opera (última versión)

o Chrome 8 o superior

� XAMPP: es el servidor independiente de plataforma que he seleccionado

para el proyecto, ya que cuenta con servidor web Apache, base de datos

MySQL e intérprete para el lenguaje PHP, a parte de phpMyAdmin para el

acceso y gestión de la base de datos.

� Zend Studio: entorno de desarrollo integrado para el lenguaje PHP,

escrito en Java y basado en el entorno de desarrollo Eclipse. En un

principio iba a usar Eclipse como IDE, pero opte por Zend Studio ya que

este IDE es una propuesta de Zend Technologies y da la oportunidad de

crear proyectos Zend Framework.

� HTML y CSS

19

2.6.2. Arquitectura

En este apartado se quiere explicar la arquitectura de la aplicación web

(cliente/servidor), donde el framework Dojo va a encargarse de la parte del

cliente, la que verán los usuarios, y de la parte del servidor lo hará Zend

Framework. Los datos necesarios se obtienen de una base de datos que se

encuentra en un servidor aparte.

2.1. Arquitectura de la aplicación

20

2.7. Planificación

2.7.1. Estructura de Descomposición del Proyecto (EDP)

2.2. Estructura de descomposición del proyecto

2.7.2. Diccionario de la EDP

En este apartado se hace una descripción mas detallada de los distintos

paquetes de la EDP y cada una de las actividades de estos paquetes.

Dirección del proyecto

Este paquete abarca todas las actividades relacionadas con la gestión del

proyecto y aquellas que sirven de seguimiento del mismo.

21

Aprendizaje e investigación: En esta actividad se engloban todas las tareas de

formación y ampliación de conocimientos necesarios para la realización y

comprensión del proyecto.

Estimación: 30 horas.

Reuniones: Todas las reuniones que se realizarán tanto con el tutor de la

Universidad, Ángel Luis Rubio, como con los miembros de la empresa, Carlos

Marín y Arturo Buzarra.


Planificación: Se trata del desarrollo inicial del proyecto, desarrollar la ligera

idea que me pudo dar el tutor en un principio, ir recopilando más información.

También recoge la realización del DOP.


Memoria: Elaboración del documento que forma parte del Proyecto Fin de

Carrera y búsqueda de información para la realización de éste.


Defensa: Esta actividad hace referencia a la preparación de la defensa ante el

tribunal (elaboración de cualquier material necesario, ensayos,…). Así como la

presentación propiamente dicha.

Estimación: 10 hora.

Análisis (Iniciación)

En este paquete se incluyen todas las actividades que sirven para realizar una

descripción más detallada del proyecto y una especificación más precisa de los

requisitos.

22

Análisis de Requisitos: Análisis del comportamiento externo del sistema,

concretar las funciones que espera el usuario.


Análisis del sistema: Comprender el sistema existente en la empresa, el que se

va a renovar, analizar todo su esquema y sus componentes.


Estudio módulos de aprendizaje: Se estudiará la posibilidad de hacer unos

módulos de prueba para cerciorarse del funcionamiento, sobre todo de los

framework, y así ir aprendiendo sus entresijos. También se mirará qué módulos

son los idóneos para desarrollar en ellos lo que luego se aplicará en el sistema a

realizar.


Diseño

El paquete de Diseño contiene todas las actividades necesarias para la búsqueda

de soluciones que se ajusten a los requisitos planteados y analizados en el

paquete anterior (Análisis).

Diseño de la estructura: Se hará un análisis detallado de la estructura que tiene

que tener el sistema aplicando todos los requisitos analizados con anterioridad.


Diseño de los módulos: Actividad que estudia cada uno de los módulos que se

realicen en este proyecto. Y el estudio de las posibles soluciones para su

desarrollo.


23

Revisión del diseño: Abarca todo el paquete. Se realiza a lo largo de todo el

diseño, cualquier cambio de diseño entra en esta actividad.


Implementación

Actividades que englobar toda la implementación de las distintas partes del

proyecto.

Implementación módulos de aprendizaje: se implementaran los módulos de

aprendizaje acordados. Estos módulos no formaran parte de la aplicación final,

pero serán módulos de formación y referencia.


Implementación de la estructura: se implementará toda la estructura de la

aplicación, incluyendo el menú y la parte de la autenticación.


Implementación de los módulos: se elaborarán todos los módulos acordados,

tanto su implementación como su integración en la estructura ya realizada.


Revisión de la implementación: se hará a lo largo de todo el paquete de

implementación, revisando el correcto funcionamiento si hay algún error en el

código se procederá a solucionarlo.


24

Análisis de Resultados e Integración

Ejecución de pruebas: Realización de pruebas sobre las partes críticas de la

aplicación web.


Integración: Se irá haciendo una integración paulatina, de las distintas partes

desarrolladas en local, en el sistema de la empresa.


Entrega y aprobación de documentación: Entrega de toda la documentación

del proyecto al tutor para que la revise y su aprobación para su presentación.


2.7.3. Estimación del proyecto

2.3. Diagrama circular estimación de horas

25

Este gráfico representa las horas empleadas en la realización del proyecto,

expresadas en tanto por ciento y distribuidas según los distintos paquetes

definidos en la EDP.

A continuación se detallan las horas globales:

Dirección del proyecto: 142 horas

Análisis (Iniciación): 20 horas

Diseño: 30 horas

Implementación: 268 horas

Análisis de Resultados e Integración: 13 horas

Total: 473 horas

2.7.4. Calendario

2.4. Calendario de trabajo

26

Explicación más detallada del calendario:

Empiezo en la empresa el día 5 de Septiembre. Durante el primer

cuatrimestre tengo que cursar una asignatura en la universidad, por lo

que voy a la empresa de lunes a viernes 4 horas por las mañanas, menos

los miércoles que acudo por las tardes, ya que tengo practicas de la

asignatura por la mañana. Por las tardes dedico el tiempo a la asignatura

y los fines de semana al Proyecto, tanto al aprendizaje sobre todo las

primeras semanas (ya que en casa no puedo realizar nada del proyecto) y

a la documentación. En el periodo de exámenes (las dos semanas de

Navidad) dejo de lado prácticamente en su totalidad el proyecto. A partir

del 11 de Enero ya no tengo ninguna asignatura que cursar, por lo tanto

le dedico al Proyecto 4 horas en la empresa de lunes a viernes, y por las

tardes tiempo opcional para dedicarlo a la documentación.

2.7.5. Diagrama de Gantt

En el siguiente diagrama de Gantt se puede apreciar el orden de las actividades

del proyecto y su duración. Para poder realizar el proyecto en las fechas

previstas.

2.5. Diagrama de Gantt

27

2.8. Riesgos

Es importante identificar los posibles riesgos de un proyecto (la posibilidad de

que se produzcan daños o perdidas) y aportar algún tipo de solución o plan de

contingencia, asó se conseguirá cometer un menor numero de errores en el

desarrollo del proyecto.

Seguidamente se exponen los posibles riesgos:

� Cancelación del proyecto

o Descripción: al tratarse de un proyecto real, la empresa que lo

propone puede llegar a decidir en algún momento que no quiere

seguir adelante con él.

o Cuantificación: probabilidad baja.

o Plan de contingencia: si esto se produce al comienzo del proyecto se

puede pensar en redirigirlo hacia otro proyecto que también necesite

o le venga bien a la empresa. Si el proyecto ya está avanzado se

puede plantear su realización por nuestra cuenta, sin contar con la

empresa.

� Desconocimiento de determinadas herramientas

o Descripción: desconocimiento total o parcial de algunas

herramientas a utilizar. Eso conlleva una curva de aprendizaje mayor,

por lo tanto un aumento en el tiempo de realización del proyecto.

o Cuantificación: probabilidad alta.

o Plan de contingencia: buscar información, libros o páginas que

aporten una buena documentación, una buena descripción de la

herramienta a utilizar.

28

� Tecnologías mal elegidas

o Descripción: las tecnologías no consigan ofrecer las características

requeridas por el proyecto o den algún problema a la hora del

desarrollo con ellas.

o Cuantificación: probabilidad media.

o Plan de contingencia: realizar un nuevo estudio sobre otras

tecnologías que puedan emplearse y volver a valorar las

características que suplirían estas nuevas tecnologías escogidas.

� Perdida de los archivos del proyecto

o Descripción: pérdida de algún archivo del proyecto o de la

información del éste.


o Plan de contingencia: ir guardando con frecuencia (cada hora)

cualquier documento o archivo que se esté elaborando y cada cierto

tiempo crear una copia de todo el trabajo hecho hasta ese momento.

� Estimaciones poco realistas

o Descripción: debido a la poca experiencia del proyectante las

estimaciones pueden no acercarse a la realizar y producirse un

desequilibrio en el plazo previsto de las tareas. Este desequilibrio

puede alargar el plazo previsto para la elaboración del proyecto.

o Cuantificación: probabilidad alta.

o Plan de contingencia: realizar unas estimaciones no demasiado

optimistas ya que no somos expertos y las cosas no saldrán a la

primera sino que habrá que darles varias vueltas y se cometerán

errores.

29

� Errores de diseño

o Descripción: es probable que no se comprendan completamente

ciertos requerimientos que debe cumplir el sistema y esto origine un

diseño poco optimo.


o Plan de contingencia: se documentarán los errores cometidos y se

intentaran subsanar antes de empezar la implementación del sistema

con un rediseño adecuado.

� Cambios en los requisitos

o Descripción: durante el transcurso del desarrollo del proyecto

pueden surgir nuevas necesidades con respecto a la funcionalidad que

ofrece el sistema.


o Plan de contingencia: hacer los cambios pertinentes en la

documentación ya efectuada sobre los requisitos y ampliarla

especificando bien los nuevos.

� Ausencia del proyectante

o Descripción: ausencia justificada del proyectante, ya sea por

enfermedad, trabajo o viaje, impidiéndole trabajar sobre el proyecto

en las fechas estimadas.


o Plan de contingencia: se harán lo antes posible una replanificación

de la duración de todas las actividades afectadas por la ausencia.

31

3 ANÁLISIS En este apartado se detallaran los requisitos y las especificaciones tanto

funcionales como no funcionales de cada parte de la aplicación y se definirán los

casos de uso más representativos.

32

3.1. Descripción de la aplicación

Este proyecto consiste en el desarrollo de una aplicación web, esta aplicación no

se desarrolla desde cero sino que está basada en una ya existente. La nueva

aplicación se va a desarrollar migrando la antigua a una nueva basada en dos

frameworks.

La aplicación web consiste en la automatización de planes de prueba para los

distintos dispositivos que se desarrollan en la empresa. Cuando se accede a ella

aparece una primera página de autenticación para que solo trabajadores de la

empresa puedan acceder a la aplicación mediante la introducción de su nombre

de usuario y su contraseña, una vez accedido se presenta la estructura con un

menú que, aparte de ofrece unas páginas de información sobre la web, da la

posibilidad de navegar por los distintos módulos. No todos los módulos están

implementados, alguno de ellos esta en construcción y todavía no presenta

ningún tipo de funcionalidad.

Pero los que si están en funcionamiento son los siguientes:

-Asistente para un nuevo test: asistente para crear nuevas listas de test,

configurarlas y programarlas.

-Mis pruebas: ver los test de un usuario, sólo el administrador podrá ver

los test de todos los usuarios.

-Dispositivos: añadir, modificar o borrar un dispositivo.

-Modificar el conjunto de pruebas o asignar los test a múltiples

plataformas.

-Mapa de dispositivos: se muestran todos los dispositivos con toda su

información y se especifica si están disponibles o no.

-Servidor de compilación: se muestran un seguimiento de todas las

pruebas diarias que se han ido realizando.

La nueva aplicación a realizar no será una copia exacta de la antigua. Por

ejemplo, la forma de autenticación variará, ya no hará falta autenticarse para

poder entrar en la aplicación sino que esto solo será necesario para la visión y el

manejo de alguno de los módulos, esto significa que la aplicación tendrá una

parte pública y otra parte privada a la que se accederá mediante una

33

autenticación. También se pretende dar un “lavado de cara” a los módulos

utilizando las ventajas que nos puede aportar el uso del framework Dojo Toolkit.

Así como renovar un poco toda la estructura.

Antes de ponerse con la migración de la aplicación este proyecto también

comprende la fase de aprendizaje, de inicio. Será necesario el diseño y la

creación de unos pequeños módulos (explicados con mas detalle en el punto

3.3.Definición módulos de aprendizaje), con una funcionalidad muy simple que

sirvan de introducción al uso de los dos frameworks en los que se va a basar la

aplicación web final. Estos módulos no sirven solo para el inicio de este proyecto

sino que también servirán como referencia para otros proyectos. Los nuevos

desarrolladores que se encarguen de la ampliación de la aplicación, se podrán

beneficiar de estos módulos. Por ello este punto también es parte importante

del proyecto aunque no se vea incluido en la aplicación web final.

Parte del peso de este proyecto también va a recaer en el manejo, aprendizaje,

instalación y acoplamiento de los frameworks, tanto el asignado al lado del

servidor como el empleado para en el lado del cliente.

Por ello a continuación se da una explicación más detallada de ellos.

3.1.1. Zend Framework

Una de las características a destacar de este framework es que cada uno de sus

componentes esta construido con baja dependencia de los demás, esto hace que

los desarrolladores puedan utilizar los componentes de forma individual. Aunque

esto es posible, los componentes de la biblioteca estándar de Zend Framework

constituyen, al combinarse, un potente y extensible framework de aplicaciones

web.

Zend Framework consta de una robusta implementación MVC (Modelo-Vista-

Controlador), eso evita crear grandes estructuras en un proyecto. En nuestro

proyecto queremos sencillez y eficiencia por eso utilizaremos el patrón MVC que

ofrece ZF. El framework también consta de una abstracción de base de datos

fácil de usar.

Los componentes de ZF reducen drásticamente el tiempo de desarrollo, con una

base completamente sólida. Algunos componentes a destacar son:

34

-Zend_Auth y Zend_Acl: proveen autentificación y autorización de

usuarios.

-Zend_db: componente que proporciona una interfaz simple de base de

datos SQL.

-Zend_Json: manejo y conversión de datos JSON.

-Zend_Form: simplifica la creación y manipulación de formularios.

Los requerimientos de Zend Framework son:

- PHP 5.2.4 (o mayor)

- Un servidor web.

A partir de la versión 1.6.0, Zend Framework trae incorporado Dojo Toolkit para

ofrecer un apoyo al desarrollo de aplicaciones sin necesidad de instalar nada

adicional. Los puntos de integración con Dojo incluyen: Soporte JSON-RPC,

compatibilidad con algunos componentes de paquetes Dojo, ayudantes de vista

para contribuir a establecer el medio ambiente de Dojo, elementos y

decoradores de algún paquete Dojo.

3.1.2. Dojo Toolkit

Dojo es un framework que contiene APIs y widgets para facilitar el desarrollo de

aplicaciones web. Consta de una serie de librerías organizadas en paquetes

según su funcionalidad. Los componentes de estos paquetes son de código

JavaScript, HTML y CSS que pueden ser usados para enriquecer aplicaciones web.

Los widgets (componentes) que ofrece Dojo tienen funcionalidades añadidas a

las que comúnmente ofrecen los widgets de HTML. Estas funcionalidades

añadidas dan lugar a interfaces gráficas más potentes, más completas y más

fáciles de usar para el usuario, a parte de ofrecer una apariencia gráfica mucho

mas amigable. Además Dojo proporciona la opción de crear nuestros propios

widgets. Algunos de los componentes que se pueden usar con Dojo son los

siguientes:

-Menús, pestañas y descripciones emergentes.

-Tablas.

-Efectos de animación.

-Formularios y rutinas de validación.

35

-Calendario.

-Soporte para arrastrar y soltar.

Dojo maneja la comunicación asíncrona con el servidor, ésta es una característica

importante para la aplicación web a realizar ya que necesitaremos realizar varias

comunicaciones asíncronas entre el servidor y el cliente. Tradicionalmente, se

realizaba con el comando JavaScript XMLHttpRequest, de hecho es el objeto que

utiliza Dojo, pero el framework proporciona una capa de abstracción, es decir,

abstraer al desarrollador del uso a bajo nivel de AJAX. Por lo que pueden usar

otros transportes y diferentes formatos de datos, como por ejemplo texto plano,

xml, JavaScript, JSON,…

3.2. Análisis de Requisitos

En este apartado se pretende hacer una descripción abstracta de los servicios

que se espera que aporte la aplicación web para que realice las funciones

esperadas por el usuario.

Esta descripción se realizará analizando y explicando los requisitos de la

aplicación. La clasificación de los requisitos será según requisitos funcionales y

requisitos no funcionales.

3.2.1. Requisitos no funcionales

A continuación se mencionan los requisitos los cuales, describen aspectos de la

aplicación visibles por el usuario que no se relacionan en forma directa con el

comportamiento funcional del sistema:

� Mantenibilidad

El código se debe estructurar de una manera consistente, predecible y

ordenada. Tiene que ser lo mas legible posible ya que va a ser utilizador

por otros desarrolladores cuando quieran ampliar la aplicación.

El sistema debe ser construido e implantado de tal manera que un cambio en los parámetros no obligue a la generación de una nueva versión del modulo.

Importancia: media

36

� Seguridad

El acceso a ciertos módulos de la aplicación tiene que estar restringida a

los visitantes y solo podrán acceder usuarios registrados. Esto debe estar

controlado por la introducción de un nombre de usuario y una

contraseña. Debe garantizarse que la información transmitida no pueda

ser capturada o interpretada.

Importancia: alta

� Usabilidad

La aplicación debe tener una interfaz sencilla para un uso intuitivo.

Debe definirse un estándar de interfaz tomando como referencia los

colores de la empresa, ya que con esto se tiene la probabilidad de que el

usurario este cómodamente trabajando con la aplicación.

Los mensajes de error deben ser reportados por la propia aplicación en la

medida de las posibilidades y no por el Sistema Operativo. Los mensajes

del sistema deben estar en el idioma apropiado, inglés.

Importancia: media

� Portabilidad

La interfaz de la nueva aplicación web se debe adaptar a varios

navegadores, ya citados anteriormente.

Por otro lado, la aplicación también se tiene que adaptar a diferentes

plataformas. Se tendrá que poder ejecutar en un ordenador de mesa, en

un portátil o incluso, en alguna ocasión, en algún dispositivo con pantalla

más pequeña. También tendrá que funcionar corriendo en distintos

sistemas operativos.

Importancia: alta

37

� Escalabilidad

La aplicación tiene que poder adaptarse a un incremento en el tamaño de

los datos que maneja.

Importancia: alta

� Reutilización

Algunas funcionalidades de ciertos módulos son compartidas por otros

módulos, en este sentido se especifica este requisito. Habrá que crear

código reutilizable o alguna biblioteca de clases que contenga funciones

reutilizables.

Importancia: media

3.2.2. Requisitos funcionales

En este apartado se mencionan y explican los requisitos que describen los

servicios que se espera que el sistema provea, las interacciones entre la

aplicación y su entorno.

Como mejor se estudian y representan estos requisitos son en el Modelo de

Casos de Uso, por ello a continuación se muestra un Modelo de Casos de Uso de

la aplicación.

3.2.2.1. Actores

� Visitante: cualquier usuario que acceda a la aplicación y navegue por ella

sin identificarse. Puede ver las secciones públicas de la página.

� Usuario logueado: visitante que se ha identificado en la aplicación.

Además de poder ver todas las secciones públicas, puede ver los datos y

las secciones privadas.

� Administrador: usuario que se ha identificado y tiene los privilegios de

administrador. Puede ver tanto la parte pública como la parte privada y

además acceder al menú de administrador.

38

3.2.2.2. Diagrama de Casos de Uso

En este diagrama se representa la interacción de los posibles usuarios con

la aplicación web, se muestra las distintas funcionalidades que ofrece el

sistema.

3.1. Diagrama de Casos de Uso

39

3.2.2.3. Especificación de Casos de Uso

En este sub-apartado se explica con detalle cada Caso de Uso representado en el

diagrama de Casos de Uso anterior.

� Caso de Uso: Ver noticias

Definición: El usuario puede seleccionar la página de noticias y ahí ver las

últimas noticias sobre la aplicación, nuevos módulos implementados,

secciones por implementar, modificaciones realizadas,….

Actores: Visitante, Usuario identificado y Administrador.

Precondiciones: ninguna

Proceso: el usuario selecciona en el menú el ítem correspondiente a

noticias y visualiza la página con las noticias.

Post-condiciones: página con las últimas noticias sobre la aplicación.

� Caso de Uso: Ver documentación

Definición: El usuario puede seleccionar la página de documentación y

leer la documentación de la aplicación o acceder a cualquier documento

disponible, como puede ser un manual de usuario, o un documento

explicativo de la función de la aplicación web.


Precondiciones: ninguna

Proceso: el usuario selecciona en el menú el ítem correspondiente a

documentación y visualiza la documentación disponible.

Post-condiciones: página con documentación sobre la aplicación.

40

� Caso de uso: Ver anuncios

Definición: se muestran anuncios interesantes para el usuario, como por

ejemplo el lanzamiento de una nueva versión, la llegada de algún pedido

importante,…. Solo se pueden ver tres. Los anuncios constarán de una

descripción y una imagen y fecha si procede.


Precondiciones: tiene que haber anuncios insertados en la base de datos.

Proceso: el usuario puede visualizar los anuncios. Se muestran un máximo

de tres anuncios, si en la base de datos hay tres o menos anuncios se

muestran todos, pero si hay más de tres anuncios se escogen para

mostrar los más próximos a la fecha actual.

Post-condiciones: solo se muestras tres o menos de tres anuncios.

� Caso de Uso: Identificarse

Definición: proceso mediante el cual un usuario introduce su nombre de

usuario y su contraseña y confirma su identidad.

Actores: Visitante

Precondiciones: usuario registrado en la base de datos.

Proceso: El usuario introduce su nombre de usuario, su identificador, y su

contraseña.

El sistema comprueba si los datos son correctos

Post-condiciones: el sistema comprueba en la base de datos que los datos

introducidos por el usuario son correctos (existe el nombre de usuario y la

contraseña es correcta). En caso afirmativo inicia sesión con los datos del

usuario y se añaden nuevos módulos a los que acceder, si el usuario tiene

el rol de administrador también puede acceder al menú de administrador.

En caso de que los datos introducidos no sean correctos se muestra un

mensaje de error y se deja volver a introducir los datos.

41

3.2. Diagrama de Actividad (Identificarse)

� Caso de Uso: Mapa de dispositivos (Map of Devices)

Definición: en este módulo el usuario puede ver todos los dispositivos sobre

los cuales realizar los test. También se muestran los clientes a los que están

asociados los dispositivos, cada cliente puede tener uno, varios o ningún

dispositivo asociado. Se puede ver toda la información de cada dispositivo y

de cada cliente (esta información se recoge de la base de datos). La

información de los clientes es: nombre del cliente, identificador, dirección ip

publica y privada, descripción, sistema operativo, dispositivos disponibles

(numero de dispositivos que tiene disponibles), localización (lugar físico de la

42

empresa donde está instalado ese cliente) y disponibilidad (si esta disponible

o no). La información que se puede ver de cada dispositivo es: nombre del

dispositivo, nombre de su plataforma, identificador, modulo, descripción,

sistema operativo soportado, información adicional sobre la plataforma y la

disponibilidad del dispositivo (si está disponible, no disponible u ocupado

realizando un test).


Precondiciones: Ninguna.

Proceso: el usuario accede al módulo ‘Map of devices’ a través del menú.

Visualiza todos los dispositivos con su información y la información de los

clientes de los cuales penden los dispositivos.

El usuario puede elegir ver sólo los clientes disponibles (opción por defecto),

con sus dispositivos disponibles o ver todos los clientes cada uno con todos

sus dispositivos, tanto disponibles, como no disponibles, como ocupados.

Post-condiciones: módulo con información sobre los dispositivos.

� Caso de Uso: Servidor Linux (Linux Server)

Definición: el usuario puede visualizar todas las compilaciones que se han

realizado en el servidor Linux, servidor de compilación, de las diferentes

versiones de distintos módulos. Podrá ver las compilaciones programadas y

hechas en la fecha actual como también todas las realizadas en días

anteriores. La información de la que dispone el usuario es:

º Nombre de los módulos.

º Etiqueta de cada versión.

º Fecha y hora de inicio de la compilación.

º Si ha ido bien o por el contrario se ha producido algún error.

º Si la versión es una versión definitiva o no.

º Resultado de la compilación


Precondiciones: Ninguna.

43

Post-condiciones: módulo con información sobre la compilación de versiones

de módulos, en un servidor de compilación Linux.

3.3 Definición módulos de aprendizaje

A continuación, se explican detalladamente los tres módulos que se realizarán

antes de empezar a desarrollar la aplicación web final.

Estos módulos consistirán en crear mini-proyectos con conceptos básicos y

esenciales para luego poder empezar con la aplicación web. Los módulos

constaran de toda la estructura necesaria para la creación de proyectos con Zend

Framework y utilizaran todo lo necesario del framework Dojo Toolkit para su

interfaz gráfica.

En un principio, los módulos se crearán por separado, cada uno en un proyecto

distinto. Pero posiblemente cuando los tres estén finalizados se juntaran en un

solo proyecto.

� Formulario

Con este módulo se pretende familiarizarse y dejar reflejado el uso de

formularios.

El formulario constará de dos campos: nombre y fecha. Estos campos

tendrán validadores y ambos serán campos requeridos. El campo nombre

solo admitirá caracteres alfanuméricos.

Después de introducir los datos se podrá “Enviar” el formulario.

º Si todo ha ido bien, en los dos campos se ha introducido algo y en

el campo nombre solo se han introducido caracteres

alfanuméricos, entonces se mostrará un mensaje indicando que

todo ha ido bien y mostrando el nombre y la fecha introducida.

º Si algo va mal: si algún campo ha quedado vacío o en el campo

nombre se ha introducido algún símbolo (algún carácter no

alfanumérico) se procederá a mostrar un mensaje de error.

44

� Página de ‘login’

En este módulo se va a realizar un logeo básico para ver el

funcionamiento de las herramientas de autenticación que proporciona

Zend Framework.

Para la interfaz de usuario se usará un formulario, aprendido ya su

funcionamiento en el módulo anteriormente realizado. En este formulario

habrá dos campos usuario y contraseña. El campo usuario solo admitirá

caracteres alfabéticos y el campo contraseña exigirá la introducción de 6

caracteres como mínimo. Ambos campos son requeridos.

Al enviar los datos:

º Si los datos han sido introducidos según los requisitos

mencionados, se comprueban los datos (usuario y contraseña) en

una base de datos, se creará una base de datos ficticia solo para

este ejemplo.

-Si los datos son correctos se redirecciona a otra página,

esta página contendrá un mensaje indicando que el usuario

correspondiente se ha logueado con éxito y tendrá la

opción de desloguearse, volviendo así a la pagina de ‘login’.

-Si los datos son incorrectos se mostrará por pantalla un

mensaje de error indicando que el usuario o la contraseña

introducidos no son válidos.

º Si los datos no han sido introducidos correctamente se

visualizaran los mensajes de error correspondientes.

� Combobox dependientes

En este proyecto de ejemplo se pretende plasmar el uso de llamadas

asíncronas al servidor mediante la técnica AJAX. Esta llamada asíncrona,

desde el cliente no se va a realizar de la manera tradicional que podamos

conocer sino que se hará a través de los mecanismos que ofrece Dojo, y

los datos enviados al servidor serán tratados como convenga Zend

Framework.

En la página aparecerán dos combobox, Países y Ciudades.

El primero, países, contendrá un listado con varios países, por defecto no

estará seleccionado ninguno, para ver los países disponibles habrá que

desplegar el combobox.

45

El segundo estará deshabilitado y no se podrá ver su contenido.

En el momento que se seleccione en el primer combobox algún país el

segundo pasara a estar habilitado y mostrará una serie de ciudades

correspondientes al país seleccionado. En el instante en el que se cambie

el país seleccionado cambiará por completo el contenido del combobox

ciudades que pasara a tener el nombre de las ciudades del nuevo país

seleccionado.

47

4 DISEÑO Capítulo que trata de exponer las decisiones tomadas sobre el diseño de la

aplicación, explicar toda la arquitectura del proyecto, deteniéndose sobre todo

en los frameworks. También se mostrarán prototipos de las secciones más

relevantes.

48

4.1. Arquitectura de los frameworks

Con este apartado se quiere describir la arquitectura de cada framework, lo que

nos encontramos en cada uno cuando lo descargamos, sus partes, su estructura

y una pequeña orientación de como empezar a trabajar con ellos.

4.1.1. Arquitectura de Zend Framework

En este proyecto se va a usar el patrón de arquitectura software MVC (Modelo-

Vista-Controlador) que nos ofrece Zend Framework. Siguiendo este patrón

conseguimos una división de la aplicación web en tres partes, una de ellas se

encarga de la interfaz de usuario, otra del tratamiento de los datos y la lógica de

negocio y por ultimo, la tercera es la encargada de comunicar las otras dos

partes:

� Modelo (Model): esta parte es la encargada de los datos, la que se va a

comunicar con la base de datos. Existen varias formas de gestionar esta

parte, una de ellas es crear un Modelo por cada módulo o pieza de la

aplicación web, de esta forma un mismo Modelo controlará varias tablas.

Otra forma es crear para cada tabla de la base de datos una clase que

será su Modelo, aunque en algún caso pueda llegar a controlar varias

tablas que tengan mucho en común.

� Vista (View): es la parte que maneja lo que verá el usuario de la aplicación

web. Transforma todos los datos recibidos por el controlador, para que

tengan un formato y una estructura adecuados para el usuario. En esta

parte entrará en juego el otro framework, Dojo Toolkit.

� Controlador (Controller): parte que comunica las otras dos, ya que éstas

deben estar aisladas. Se encarga de recibir las acciones del usuario e

invocar peticiones al Modelo. Procesa todos los datos necesarios y los

manda a la vista mediante asignación de variables.

49

Con el siguiente esquema se muestra el comportamiento de MVC en Zend

Framework.

4.1. Patrón MVC en Zend Framework

Para poder trabajar con Zend Framework lo primero es descargar la última

versión desde el sitio oficial. Una vez descargado, el siguiente paso es crear una

estructura de directorios. Esta estructura ira colgada de la carpeta ‘webDigi’,

nombre de nuestro proyecto, y a su vez ésta se encontrará en la carpeta htdocs

de xampp. La estructura inicial será la siguiente:

4.2. Estructura de directorios ZF

50

Esta estructura tiene tres carpetas principales a destacar: application, library y

public.

� La carpeta application es donde reside todo el código de la aplicación y es

la encargada de manejar el patrón MVC, explicado anteriormente, a

través de sus tres carpetas principales models, controllers y views:

controllers: en esta carpeta irán alojados los distintos

controladores que se creen para la aplicación. Un controlador es

una clase que extiende de Zend_Controller_Action y esta clase

contiene métodos llamados acciones (actions), estos métodos

especiales tienen el nombre con el sufijo “Action”. Los

controladores son archivos con extensión .php. En el ejemplo de la

imagen hay dos controladores creados: IndexController.php y

ErrorController.php. El controlador Index es el controlador por

defecto, si no se indica ningún controlador entonces este es el

que se ejecuta. El controlador Error se ejecutará cada vez que

queramos acceder a una página que no existe o se produzca algún

error en la aplicación. Las Url’s en ZF tienen la forma

/{controlador}/{acción}, esta url ejecutará la acción del

controlador indicada.

Ejemplo de un controlador:

4.3. Controlador ZF

º models: aquí irán todas las clases que creemos como modelos de

nuestra aplicación.

º views: carpeta encargada de guardar las vistas, las páginas con

HTML. Aquí es donde se genera la fachada de la interfaz de

usuario, lo que ve el usuario. Esta carpeta tiene dos subcarpetas:

-helpers: encargada de almacenar los view helpers, clases con

métodos que se van a emplear en varios lugares, en varias vistas

51

distintas, es una manera de no repetir código. Los view helpers se

ejecutan dentro de las vistas.

-scripts: donde encontramos las vistas propiamente dichas,

todas las páginas que hacen referencia a los controladores. Hay

que tener en cuenta que las vistas se generan a partir de los

controladores, por ello se crea una carpeta por cada controlador y

dentro de esa carpeta se encuentran los archivos con extensión

.phtml los cuales hacen referencia a las acciones del controlador.

Por ello en la imagen anterior, dentro de la carpeta scripts

aparece: /index/index.phtml y /error/error.phtml

(/{controler}/{action}.phtml), esto indica que hay dos

controladores creados: index y error (vistos en la carpeta

controllers) y estos controladores tienen las acciones index y error

respectivamente.

A esta carpeta views también se le puede añadir una llamada

layouts, aquí se puede generar una plantilla para la vista de la

aplicación web. Creando un layout se consigue poder incluir una

vista dentro de otra.

Aparte de estas tres carpetas también contiene el archivo bootstrap.php

donde se definen los recursos y los componentes a inicializar en la

aplicación, y la carpeta configs con el archivo de configuración

application.ini, en este archivo se guarda la configuración inicial de la

aplicación, por ejemplo la configuración de la base de datos a usar.

� La carpeta library será la que albergue la librería de Zend. También este

es el lugar para incluir las librerías que creemos.

� Por último la carpeta public es el root del sitio, es decir, la carpeta que

debe contener solo los documentos que serán accesibles a través del

navegador, todas las imágenes, las hojas de estilo (.css), los archivos

javascript,… En esta carpeta es donde se debe incluir Dojo, el otro

framework (carpeta con todos los componentes de Dojo).

También cabe destacar dos archivos importantes .htaccess y index.php. El

primero es un archivo simple donde solo hay que indicar la ruta donde

hayamos depositado las librerías de Zend (/library) y ejecutar la

aplicación, el segundo archivo es el destinado a la configuración del

módulo mod-rewrite, módulo para hacer las URL’s mas “amigables”.

52

4.1.2. Arquitectura de Dojo Toolkit

Dojo consta de una arquitectura con varios componentes principales que se

describen a continuación:

� Dojo Base: es la base de Dojo Toolkit, es el fundamento de utilidades

como AJAX, DOM (interfaz de programación de aplicaciones para

acceder, añadir y cambiar dinámicamente contenido de documentos

HTML, XML,…) y manejo de eventos, entre otros. Se trata de una

biblioteca compacta que se recoge en un único documento llamado

dojo.js.

� Dojo Core: como el nombre lo dice Dojo Core es el núcleo de Dojo. Es un

conjunto más amplio de componentes construidos sobre la base de Dojo

Base. Ofrece componentes mas avanzados como por ejemplo: arrastrar y

soltar un elemento (Drag&Drop), efectos de animación, almacén de

datos,… Cualquier recurso externo a dojo.js que se quiere utilizar, que se

quiere importar se hará desde Dojo Core.

� Dijit: biblioteca de widgets para crear interfaces gráficos. Esta biblioteca

requiere Dojo Base y varios módulos de Dojo Core. Estos widgets son

altamente portables, fáciles de utilizar y simples en diseño, alguno de

estos widgets son: menús, tablas, contenedores,…

� Dojox: paquete de extensiones para Dojo. Es una colección independiente

de subproyectos. Contiene gráficos, herramientas de dibujo,

componentes móviles,.... en definitiva, componentes un poco mas

avanzados.

� Util: es una colección de utilidades que incluye herramientas para crear

versiones personalizadas de Dojo y una unidad de prueba. Las

herramientas que ofrece pueden llegar a disminuir el tamaño del código e

incluir capas con distintos archivos JavaScript.

53

4.4. Componentes de Dojo Toolkit

En esta imagen se resumen todos los componentes principales de Dojo, ya

explicados. Y se añade algo más, tus propios componentes, ya que Dojo ofrece al

desarrollador la opción de crear sus propios componentes.

Cuando nos descargamos el framework obtenemos simplemente una carpeta

que contiene las componentes en otras subcarpetas.

Se han descrito cinco componentes principales de Dojo, sin embargo las carpetas

físicas que contiene solo son tres: Dojo, Dijit y Dojox; ya que en la carpeta Dojo

se incluyen las componentes Dojo Base y Dojo Core, y el componente útil esta a

parte, usa otro directorio distinto.

4.2. Llamadas asíncronas con Zend Framework y Dojo

Se van a realizar llamadas asíncronas en la aplicación web a través de la

utilización de AJAX. Por lo que en este apartado se hace una pequeña

introducción y una descripción de su uso con los frameworks.

Utilizando AJAX se consigue que cuando el usuario pide mas información de una

página, ésta no se refresque entera para mostrarla sino que añada la información

requerida directamente. O también, que en un principio, una página muestre lo

mínimo e imprescindible y poco a poco se vaya añadiendo lo que el usuario pida.

Para todo esto se utiliza una combinación de HTTP, JavaScript y en algunos casos

XML; AJAX envuelve todo esto.

54

Con el uso de AJAX vamos a conseguir que la parte del cliente se comunique

asíncronamente con el servidor. En la parte del cliente se recogerán los datos

necesarios y se enviaran al servidor, de esto se encarga Dojo. El servidor recibirá

los datos, los tratará y los volverá a mandar al cliente, de todo esto se encargará

Zend.

Aunque el formato más habitual en AJAX para el envió de datos y su tratamiento

es el lenguaje XML, se ha decidido utilizar el formato JSON como alternativa. A

parte de ser un formato sencillo y ligero también resulta mucho más sencillo

escribir un analizador semántico de JSON. En JavaScript, un texto JSON se puede

analizar fácilmente usando el procedimiento eval().

Un ejemplo simple de formato JSON sería el siguiente:

{“nombre”: “Miguel”, “apellido”: “Peña”}

Dojo ofrece unas funciones que permiten las interacciones de Ajax, estos

métodos se encuentran en el componente Dojo Base y son dojo.xhrGet y

dojo.xhrPost. La primera función es para llevarla a cabo en una comunicación

HTTP según el método “Get”, orientada a recoger información del servidor. La

otra función implementa una solicitud asíncrona para HTTP POST, mas enfocada

en el envío de datos al servidor.

Ambas funciones incluyen varios campos, varias propiedades descritas a

continuación:

º content: campo que contiene un objeto JavaScript con pares de

valores clave/valor (nombre/cadena). Estos datos son los que se

van a mandar al servidor. Este parámetro es opcional.

º url: url para dirigir la solicitud.

º handleAs: designa el formato con el que manejar los datos

devueltos por el servidor (“text”, “json”,”javascript”, “xml”,…). Es

conveniente asignar un formato que coincida con el devuelto

desde el servidor ya que sino puede dar error.

º load: con esta propiedad se define una función que será llamada

en una respuesta satisfactoria. Es opcional.

55

º error: se establece una función que será llamada en caso de error.

Es otro campo opcional.

º headers: cabeceras HTTP adicionales para incluir en la solicitud.

Propiedad opcional.

º timeout: numero de milisegundos que se esperará hasta que se

agote el tiempo de la solicitud. Este campo es opcional, si no se

pone nada el valor por defecto es ‘0’, es decir no hay tiempo de

espera.

La función dojo.xhrPost aparte de la propiedad content añade dos

propiedades más: form y postData.

La propiedad form ofrece la posibilidad de enviar al servidor los datos

de un formulario, se pueden proporcionar a través del nodo DOM del

formulario o a través de la ID de este. Si por un casual no se ha

definido url en los argumentos de dojo.xhrPost, se extraerá la url del

atributo ‘action’ del formulario.

El campo postData permite el envío de un String, una cadena de

caracteres, al servidor sin la necesidad de más procesos.

Estas tres propiedades, content, form y postData son excluyentes, es

decir, en una misma función dojo.xhrPost sólo se puede usar una de

ellas.

Zend Framework también tiene implicación en estas llamadas asíncronas, como

parte del servidor, aunque no tiene tanta participación como Dojo (parte del

cliente). Zend Framework únicamente se encarga de tratar los datos, recibirlos,

manipularlos y devolverlos. Anteriormente ya se ha determinado que el formato

de los datos en los envíos iba a ser JSON.

ZF recibe los datos en formato JSON, los tiene que pasar a lenguaje PHP para

poder entenderlos, ya que es el lenguaje con el que trabaja. Una vez hecho esto

los tratará y antes de devolverlos volverá a transformarlos al formato JSON. Para

todo esto Zend Framework posee una librería llamada Zend_Json. Esta librería

ofrece métodos para la serialización desde PHP a JSON y la decodificación de

JSON a PHP.

Recuperar un valor, de JSON a PHP:

$valorPhp = Zend_Json::decode($dato)

Codificar un valor para devolverlo al cliente:

$datoJson = Zend_Json::encode($datoPhp)

56

Para enviar algún dato PHP al cliente en formato JSON también se puede usar el

ayudante de acción, action helper, de la siguiente forma:

$this->_helper->json($dato)

4.3. Estructura interfaz de usuario y sus componentes

Tras plantear los componentes esenciales que requería la aplicación web, y tener

en cuenta la distribución de parte pública y parte privada, se llego a un acuerdo,

con ayuda de mi tutor de empresa y con el desarrollador de la antigua aplicación

web, de como estructurar la interfaz de usuario. A continuación se muestra un

prototipo de esta estructura:

4.5. Prototipo de la estructura

Constará de cinco partes: cabecera, menú, contenedor principal, menú lateral

derecho y pie. Existe la posibilidad de crear esta estructura tan solo usando

HTML y CSS, pero vamos a aprovechar lo que nos ofrece Dojo.

Dojo ofrece un conjunto de widgets alojados en su componente dijit, estos

componentes están destinados a la gestión del diseño y están agrupados en

dijit.layout. Los principales layouts de los que podemos disponer son los

siguientes:

57

� BorderContainer: con este widget se crea un contenedor en el que se

pueden definir como máximo cinco regiones, parte superior, inferior,

lateral derecho, lateral izquierdo y parte central. Dentro de cada una de

estas partes se pueden crear otros layouts.

� AccordionContainer: su propio nombre lo explica “contenedor de

acordeones”. Este layout permite definir una serie de paneles de los

cuales solo se puede visualizar su titulo y de todos ellos solo se verá un

panel completo a la vez (titulo y contenido). Al hacer clic en un título del

panel, este se desplegará mostrando su contenido y el que estaba abierto

pasara a encogerse, ocultando su contenido. Se puede especificar,

mediante una propiedad del widget, que panel aparecerá desplegado por

defecto. Si no se define ninguno será el primer panel el que aparezca

desplegado.

4.6. Prototipo AccordionContainer

� TabContainer: con este widget se pueden crear varios contenedores, pero

solo se mostrará uno a la vez. El resto de contenedores se quedarán

reflejados a través de una pestaña con un titulo. Pulsando esas pestañas

se puede ir cambiando de contenedor, de panel. Mediante una propiedad

del widget se puede definir un botón de cierre en cada pestaña para

cerrar el panel con solo clicarlo.

4.7. Prototipo TabContainer

58

� StackContainer: contenedor que consta de varios contenedores hijos,

pero solo se muestra uno a la vez. Se puede pasar de uno a otro mediante

flechas, hacia delante y hacia atrás.

� ContentPane: es la pieza más básica, es un panel de contenido.

Generalmente este widget se utiliza para crear los paneles de los otros

widgets de este tipo.

Para nuestra estructura se creará un borderContainer, como contenedor

principal, en el cual se definirá un contentPane para la parte superior (cabecera),

otro para la parte inferior (pie), otro más para la parte central (contenido

principal de la aplicación), uno final para lateral derecha y por último en la parte

lateral izquierda se creará un accordionContainer para definir el menú de la

aplicación.

En la parte de la cabecera irá a la izquierda el logo de la empresa, en el centro el

título de la aplicación web y a la izquierda se presentará el formulario para la

autenticación.

La estructura de la aplicación no variará en ningún momento, lo único que irá

cambiando será el contenedor principal que será el encargado de mostrar los

distintos módulos por los que vaya navegando el usuario. El menú también se

verá modificado dependiendo del usuario que este accediendo a la aplicación.

En cuanto a la parte de logueo de usuario, constará de un formulario con un

campo para ingresar el nombre de usuario (username), otro campo para la

contraseña (password) y un botón para enviar la información.

Muchas veces podemos mezclar términos, pero hay que diferenciar

autenticación de autorización. En este proceso de logeo se van usar los dos

términos. Se recogerán los datos introducidos por el usuario y mediante el

proceso de autenticación se validarán en la base de datos para comprobar si son

correctos. Luego se producirá la autorización, una vez que el usuario y la

contraseña sean correctos, se autorizará al usuario poder acceder a unos datos u

otros dependiendo del rol que tenga.

La autenticación se va a realizar con la ayuda de la librería que ofrece Zend

Framework, llamada Zend_Auth.

59

4.4. Módulos

El usuario puede acceder a los distintos módulos de la aplicación a través del

menú lateral, una vez seleccionado un módulo éste aparecerá en al parte central

de la página.

A continuación se detallan los detalles de diseño de cada módulo:

� Mapa de dispositivos (Map of Decives)

En este módulo existen dos objetos principales: los clientes y los

dispositivos. Cada cliente se va a crear con el widget titlePane que ofrece

Dojo.

El widget titlePane pertenece al componente principal dijit

(dijit.titlePane). Consiste en un panel que se puede abrir o colapsar, con

un título en la parte superior. La visibilidad del contenido del panel se

activa pinchando sobre su título. Por defecto al crear este widget aparece

desplegado, pero mediante una propiedad poder especificar que

aparezca colapsado.

En el titulo de cada componente de un cliente se muestra la información

más relevante: el nombre del cliente, la ip, su identificador, los

dispositivos disponibles que tiene asociados y una pequeña descripción, a

parte también se puede visualizar una imagen del cliente diferenciando si

esta disponible o no.

En su contenido se alojan los dispositivos a su cargo, estos dispositivos

también se muestran a través de un titlePane. En el titulo de los

dispositivos se muestra el nombre, la plataforma del dispositivo, su

identificador, y una imagen de él. En el contenido aparece el módulo del

dispositivo, su estado y una descripción.

Los clientes van a aparecen colapsados, es decir, en un primer vistazo el

usuario solo podrá ver los clientes. Al desplegar cada cliente aparecen los

dispositivos, y estos ya aparecerán expandidos.

Toda la información referente a cada cliente y cada dispositivo no

aparece en el mismo, por ello, se creará un objeto para mostrar toda la

60

información, tanto la ya especificada en cada titlePane como la

información no reflejada. El componente elegido para mostrar esa

información adicional es el toolTip (dijit.toolTip).

El widget toolTip es una etiqueta que se asocia a un objeto. Cuando se

pase el ratón por encima del objeto aparecerá esta etiqueta con el

contenido que hayamos especificado. Mediante propiedades se puede

definir la posición del toolTip respecto a su objeto asociado y el tiempo

que permanecerá visible.

Cuando el usuario pase el ratón por encima de algún cliente o algún

dispositivo el toolTip aparecerá a su derecha. El toolTip de cada cliente

mostrará: el nombre, la ip, su identificador, descripción, sistema

operativo, si esta disponible o no, su localización y una imagen. En el

toolTip de cada dispositivo se revelará la siguiente información: nombre,

id, tipo, puerto de la consola, sistema operativo soportado, información

adicional sobre el módulo del dispositivo, información adicional sobre la

plataforma, estado del dispositivo y una imagen.

Prototipo del módulo:

4.8. Prototipo módulo Mapa de Dispositivos

61

Por defecto aparecerán solo los clientes disponibles, conteniendo solo los

dispositivos disponibles. El usuario a través de un checkbox podrá desmarcar la

opción de ver solo los clientes disponibles y así poder ver todos los clientes con

todos sus dispositivos correspondientes. En cualquier momento puede volver a

marcar esa casilla y así aparecerán solo los clientes que estén disponibles en ese

momento.

Los clientes disponibles se representarán mediante un círculo verde en su

imagen y un círculo rojo en caso de no estar disponible. Con los dispositivos lo

mismo, verde si están disponibles, rojo si no lo están y amarillo si están ocupados

realizando un test.

� Servidor Linux (Linux Server)

El módulo Linux Server va a estar dividido en dos partes: Build Server List y

Release Tags. Esta división se hará mediante el componente TabContainer

(explicado en el punto anterior: 4.3. Estructura interfaz de usuario y sus

componentes). Por lo que cada una de las partes será un panel de este

componente. Por defecto el panel abierto, la parte que verá el usuario al acceder

al módulo, será la de Build Server List.

Build Server List mostrará toda la lista del servidor de compilación. Esa

información se dispondrá de la siguiente manera:

Existirá un calendario creado a través del widget de Dojo dijit.Calendar, la fecha

que aparecerá por defecto señalada será el día actual. Debajo del calendario se

situará una tabla, creada mediante el componente dataGrid. Las columnas de la

tabla son:

º Indicador de si la compilación ha ido bien o no. Mediante un tick si ha ido

bien o una cruz si ha habido algún error. º Module. Nombre del módulo. º Tag. Etiqueta de la versión. º Release Tag. Si esta columna tiene el nombre del tag significará que es

una versión definitiva, si aparece vacía significará que no es una versión

definitiva. º Fecha. Fecha y hora del comienzo de la compilación.

También este panel constará de un contenedor para mostrar en él los resultados

de cada compilación. Cuando el usuario pinche sobre una fila de la tabla, en el

contenedor se mostrará el fichero de resultados de esa compilación. Esos

62

ficheros de resultados se muestran a través de una url, uno de los campos de la

tabla de la base de datos.

Prototipo del panel Build Server List:

4.9. Prototipo Build Server List

Los datos que aparezcan en la tabla dependerán del día seleccionado en el

calendario. Los datos aparecen por días. Por ejemplo, si en el calendario se

selecciona la fecha: 16/03/2010, en la tabla aparecerán todas las compilaciones

realizadas ese día.

Los días del calendario estarán pintados en función de las compilaciones de cada

día. Hay tres casos distintos, tres colores distintos para “pintar” un día del

calendario:

º Alguna compilación ha fallado, ha habido algún error.

º Alguna de las versiones se establece como versión final (release tag).

º Todas las compilaciones han ido bien y no ha salido ninguna versión final.

Ante un error y una versión final prevalece el error, a la hora de representarlo en

el calendario.

63

Release Tags será el panel encargado de mostrar solo las compilaciones de

versiones definitivas. Aquí se incluirá una tabla para mostrar todas esas

compilaciones, ahora la información de la tabla no dependerá de fechas sino que

se mostrará todas las versiones definitivas hasta la fecha. Para crear esta tabla

se utilizará el componente EnhancedGrid de Dojo. Como la tabla tendrá

bastantes resultados, abundantes filas, no aparecerá toda la información de

golpe sino que aparecerá por páginas de la tabla. El usuario podrá ir navegando

por esas páginas para así ver toda la información y también podrá seleccionar el

número de filas que desea ver en una misma página de la tabla. También

dispondrá de un contenedor para mostrar los resultados de cada compilación, es

decir, de cada fila de la tabla.

Prototipo del panel Release Tags:

4.10. Prototipo Release Tags

Las tablas que se van a usar pertenecen al componente principal dojox, donde se

alojan los elementos un poco más complejos de Dojo. Dentro de dojox, las dos

tablas cuelgan de los componentes denominados grid.

DataGrid (dojox.grid.DataGrid) se trata de una tabla, muy similar a una hoja de

cálculo, que ofrece posibilidades al usuario como la de cambiar el tamaño de las

columnas, u ordenar los datos por columnas.

64

EnhancedGrid (dojox.grid.EnhancedGrid) este componente es una versión más

compleja y completa que ofrece un conjunto de características más amplias.

Estas características se implementan como plugins separados, que deberán

declararse antes de ser usados. Algunos de los plugins son:

º Filter: filtrar los datos de la tabla por un conjunto de condiciones.

º Exporter: exportar el contenido de la tabla a varios formatos.

º Pagination: divide el contenido de la tabla en páginas. Plugin usado con

conjuntos grandes de datos (como en nuestro caso).

º Printer: proporciona distintas formas para visualizar o para mostrar la

tabla.

4.5. Bases de datos

Todos los datos necesarios en la aplicación van a residir en dos Bases de Datos.

Una de ellas va a ser la principal, llamada web_automation, de la cual se

extraigan o modifiquen casi todos los datos. Pero en concreto, toda la

información del módulo Linux Server (explicado en el punto anterior), se va a

sacar de otra Base de Datos diferente, builserver. Esta segunda Base de Datos

contiene una única tabla llamada builds.

En un principio se va a trabajar solo con la Base de Datos web_automation,

asique para manejar los datos de la BD buildserver será necesario crear una tabla

dentro de web_automation que simule la tabla de la otra Base de Datos. Habrá

que implementar todo de manera que luego sea fácil modificar el código para

acceder a la tabla builds a través de la BD buildserver, en vez de a través de

web_automation, ya que mientras este en local solo se trabajara con una BD

pero cuando se suba la aplicación al servidor correspondiente ya se trabajara con

las dos Bases de Datos.

65

4.11. Tabla builds

Las tablas más importantes, o las que más se van a utilizar de la Base de Datos

web_automation son: client, dut, platform y user. Esta última se usará para la

autenticación y las demás para el módulo ‘Mapa de Dispositivos’.

4.12. Tabla Client (Cliente)

66

4.13. Tabla Dut (Dispositivo)

Para poder usar los datos de las BD en el proyecto Zend Framework hace falta

declarar la BD y especificar sus parámetros, todo esto en el archivo de

configuración config.ini situado en el directorio /application/configuration/.

4.14. Configuración Base de Datos

-db.adapter: adaptador de la BD, por defecto es ‘PDO_MYSQL’.

-db.params.host: dirección ip del servidor donde se encuentra la BD.

-db.params.username: nombre de usuario de acceso a la Base de Datos.

-db.params.password: contraseña de acceso a la BD.

-db.params.dbname: nombre de la BD.

67

Zend Framework ofrece el componente Zend_db, el cual provee de una API para

la creación de sentencias SQL. Se pueden crear sentencias SQL de dos formas

principalmente. La primera es a través de la creación de un objeto select

mediante el método select() del db adapter, desde el que luego se pueden ir

seteando individualmente cada parte de la sentencia (from, where, …). Un

ejemplo de esta forma de crear sentencias sería el siguiente:

4.15. Zend_db_select

La otra forma es a través del método fetchAll(). Se escribe una consulta SQL que

se pasa como parámetro del método y éste devuelve un array con las filas

devueltas por la consulta. Si se quiere obtener toda la información de una tabla

(todas las filas) basta con ejecutar fetchAll(), sin ningún parámetro. Este método

también ofrece la posibilidad de pasarle como parámetros las siguientes

variables: $where, $order, $count, $offset.

Ejemplo del método fetchAll(), pasando como parámetro un String con la sentencia SQL:

4.16. Método fetchAll()

68

Ejemplo del método fetchAll(), pasando como parámetros algunas de las

variables aceptadas:

4.17. Método fetchAll() [2]

69

5 IMPLEMENTACIÓN En este capítulo se explican las principales características de la creación,

propiamente dicha, del proyecto. Las decisiones importantes tomadas en cuanto

a cuestiones de implementación. También se hace referencia a los problemas

surgidos y cuál o cuáles han sido las soluciones.

70

5.1. Estructura del proyecto En este apartado se quiere explicar como se ha implementado o desarrollado

todas las estructuras necesarias para comenzar a implementar el contenido de la

aplicación web. Se mostrará como se organiza toda la información y los datos.

5.1.1. Estructura de directorios

Al inicio del proyecto se pensó en Eclipse como entorno de desarrollo, por lo que

se empezó a crear la estructura de directorios desde ahí. Eclipse no

proporcionaba ninguna facilidad, así que se construyeron las carpetas y los

ficheros principales a mano, desde cero.

Más adelante se consideró la posibilidad de utilizar Zend Studio y se decidió

cambiar a este entorno de desarrollo para implementar todo el código de la

aplicación desde ahí. Zend Studio facilita la posibilidad de crear proyectos

basados en la estructura Zend Framework, explicada en el apartado

4.1.1.Arquitectura de Zend Framework. Al ir a crear un nuevo proyecto en el

menú de Zend Studio hay que elegir ‘Zend Framework Project’ y seleccionar la

opción ‘Zend Framework default Project structure’ (marcada por defecto). La

estructura de directorios queda de la siguiente manera:

5.1. Estructura de directorios

71

Toda la estructura cuelga de la carpeta con el nombre del proyecto. La carpeta

docs y tests no son necesarias para el proyecto ha crear por lo que se pueden

borrar. A parte de crear toda la estructura de directorios también se crean unas

librerías. En concreto, se puede acceder a la librería de Zend (PHP Include

Path/Zend Framework Library/ Zend) para visualizar el código de todos los

componentes, de todas las clases que forman cada componente de Zend.

5.1.2. Integración Zend Framework – Dojo

A la hora de integrar los dos frameworks en realidad lo que se hace es incluir uno

dentro de otro. Una vez creado el proyecto Zend Framework, lo primero es

incluir la carpeta de Dojo, la que contiene todos los componentes, dentro de la

estructura de ZF. Por lo que hay que copiar y pegar la carpeta Dojo dentro de la

carpeta /public de nuestro proyecto y a su vez dentro de la carpeta /js

(/public/js). Una vez hecho este paso lo siguiente es habilitar Dojo dentro de

cada vista del proyecto y configurar las distintas propiedades de Dojo. Todo esto

se realiza escribiendo el siguiente código en cada vista que requiera el uso de

componentes Dojo:

5.2. Configurar Dojo

Primero se habilita Dojo en la vista, luego se indica la ruta donde se encuentra el

archivo dojo.js (archivo principal, desde donde se cargan todos los

componentes). También se indica el estilo de Dojo a utilizar, ya que Dojo ofrece

distintos estilos para sus componentes (llamados temas, themes). Estos temas

son carpetas con diferentes hojas de estilo, una para cada componente.

72

Problemas

La información encontrada en páginas de internet era algo contradictoria sobre

los pasos a seguir para que Zend Framework entendiese Dojo y sus

componentes. Por ello al principio del desarrollo del proyecto hubo varios

problemas con la integración. No se conseguía obtener el código necesario para

el entendimiento ni donde colocarlo.

5.1.3. Componentes del patrón MVC

Zend Framework sigue el patrón de arquitectura MVC, como ya se ha explicado

anteriormente. En este apartado se va a explicar con algo más de detalle cada

uno de los tres componentes del patrón, como implementar cada uno, y la

comunicación entre ellos, es decir, como se puede pasar información de unos a

otros.

Modelo

El modelo de la aplicación va a residir en la carpeta /application/models, en esta

carpeta se guardan todos los modelos (clases) necesarios. La implementación de

los modelos escogida ha sido mezcla de los dos tipos distintos que se pueden

realizar (explicados en el punto 4.1.1 Arquitectura de Zend Framework). Por un

lado se crea un archivo .php por cada tabla a usar de la Base de Datos, cada

archivo se nombra con el de la tabla al que hace referencia. Por otro lado

también se crea un archivo por cada controlador establecido en la aplicación,

pero no todos estos modelos serán necesarios.

Cada modelo es una clase que extiende de Zend_Db_Table_Abstract. En cada

clase se definen las funciones necesarias. En los modelos relacionados con las

tablas de la Base de Datos lo primero que hay que definir dentro de la clase es

una variable protegida con el nombre de la tabla de la que vamos a extraer

información y a continuación las funciones.

73

Un ejemplo de modelo sería el siguiente:

5.3. Ejemplo clase del Modelo

Es necesario crear la variable protegida para que así el modelo sepa de qué tabla

de la Base de Datos tiene que coger o modificar información. Así cada vez que

necesitemos referenciar un campo de la tabla basta con escribir el nombre de

ese campo. En el ejemplo anterior está definida la función getNombre() con la

variable $nom pasada como parámetro, a través de una consulta a la tabla

‘tabla1’ se obtienen todas las filas cuyo campo nombre es igual al pasado como

parámetro ($nom), y esas filas devueltas se ordenan por el campo edad de

manera ascendente. Para hacer referencia a los campos nombre y edad basta

con escribir el mismo nombre que tengan en la Base de Datos.

Controlador

Los controladores de la aplicación residen en la carpeta /application/controllers y

sirven para comunicar el modelo con la vista. Al crear el proyecto se crean los

controladores ErrorController.php e IndexController.php, el controlador Error es

donde se detallarán los posibles errores de la aplicación. La aplicación constará

de un controlador por cada parte o por cada módulo de la aplicación, para toda

la estructura general se empleará el controlador por defecto (IndexController),

ahí estará todo lo relacionado con la cabecera, el menú,… y luego un controlador

distinto por cada módulo uno para el módulo Mapa de Dispositivos

(MapofDevicesController.php) y otro para el módulo Servidor Linux

(BuildserverController.php). La parte de autenticación se encuentra dentro de la

estructura general pero se considera lo suficientemente compleja como para

crear un controlador de ella (AuthController.php).

74

En cada controlador se pueden definir dos clases de métodos, aunque todos los

métodos se denominan ‘acciones’ (como ya se explico en el punto 4.1.1.

Arquitectura de Zend Framework). Los definidos como funciones Ajax no tendrá

ninguna vista asociada, sin embargo los demás si que la tendrán, una vista por

cada acción del controlador.

Vista

Las vistas se encuentran en el directorio /application/views/scripts, son archivos

.phtml, ya que ahí se mezcla código php, html y javascript o referencias a

archivos javascript. Las vistas no se generan porque sí, si no que existirá una vista

por cada acción de cada controlador. Para cada controlador se crea una carpeta

en el directorio de las vistas y dentro de cada una de esas carpetas estarán los

archivos .phtml, uno por cada acción. El nombre de las vista es el mismo que el

nombre de la acción a la que hacen referencia.

Un ejemplo de vista sería el siguiente:

Comunicación Modelo - Controlador

El controlador es el encargado de recoger la información que reside en los

modelos por ello es en el controlador donde se referencia a los modelos. Los

controladores son los que utilizan los modelos y no al revés.

Por lo tanto, cada vez que en un controlador queramos hacer uso de un modelo

primero hay que incluir su ruta: require_once(‘../application/models/Modelo.php’),

luego crear una instancia de ese modelo mediante: $model = new Modelo(); y ya

se puede acceder al modelo a través de la variable $model. Para poder usar las

funciones definidas en el Modelo basta con llamarlas mediante la variable

creada: $model->metodoModelo();.

Comunicación Controlador - Vista

En ocasiones es necesario pasar información de la vista al controlador y en otras

ocasiones al revés, del controlador a la vista.

La vista es un objeto Zend_View al que accedemos desde el Controlador con

$this->view.

75

Un ejemplo de como pasar datos del controlador a la vista:

5.4. Paso Información Controlador - Vista

En el ejemplo se pasa un String mediante la variable title. En la vista ‘holamundo’

podremos acceder al String con el código: $this->title;. Se puede pasar cualquier

conjunto de datos, como arrays.

La información que se mande desde la vista al controlador será a través de Ajax,

utilizando el método que nos proporciona Dojo (4.2. Llamadas asíncronas con

Zend Framework y Dojo).

5.2. Componentes de Dojo Toolkit

En la documentación existente en la página oficial de Dojo Toolkit se explican dos

formas distintas de crear un widget, es decir, un componente Dojo.

� Forma declarativa: de esta manera se crea a través de código HTML. Se

usan las etiquetas apropiadas para cada widget, cada uno tiene una

etiqueta asociada. El tipo de widget se detalla añadiendo una propiedad a

la etiqueta HTML (data-dojo-type).

<textarea id="textarea2" name="textarea2" data-dojo-type="dijit.form.Textarea" style="width:2 00px;"> Hello World! </textarea>

5.5. Creación widget, declarativa

76

� Forma programática: de esta manera se crea el widget con código

javascript. En la vista donde se tenga que establecer el componente se

tiene que crear un script o referenciar a un archivo javascript. De esta

forma se crea un objeto mediante el uso de ‘new’ por cada componente a

crear y se pasa como parámetros las distintas propiedades de ese

componente.

dojo.ready(function(){ var textarea = new dijit.form.Textarea({ name: "myarea", value: "Hello World! ", style: "width:200px;" }, "myarea"); });

5.6. Creación widget, programática

Tanto si lo hacemos de forma declarativa o de forma programática, primero hay que cargar el widget de la siguiente forma:

dojo.require("dijit.form.Textarea");

En implementación de la aplicación se va a emplear la creación programática de

widgets. A parte de que así no se carga tanto de código la vista, también se ve

más claro ya que de la otra manera se mezcla con el código HTML.

Otra forma de crear los widgets, que no se explica en la página, y que no se va a

usar con tanta frecuencia como la programática es programarlos con código PHP.

Esto se realiza en la cabecera de las vistas. Se crearán widgets con PHP cuando se

quieran crear en la misma vista y no en un archivo javascript.

Otra cosa a tener en cuenta de los componentes de Dojo es su estilo, su aspecto.

Dojo ofrece sus propios estilos, llamados Temas (themes). Estos themes se

encuentran en el directorio de Dojo /dijit/themes/ y cada tema se representa

mediante una carpeta que ésta contiene todos los archivos .css (las hojas de

estilo) correspondientes a todos los widgets.

Para los widgets que se creen se va a utilizar la base de hojas de estilo que

proporciona Dojo y a eso se le sumará hojas de estilo propias, que se creen

específicamente para los widgets de esta aplicación web. Se ha decidido que el

estilo de los componentes se defina solo en las hojas de estilo, así que no se

detallará ningún estilo en el código HTML, o como propiedad al crear algún

widget.

77

Para hacer referencia a uno de los temas de Dojo basta con especificarlo en las

vistas. Escribiendo el nombre del tema en la propiedad ‘class’ de la etiqueta

<body> del HTML:

<body class ="tundra">

Algo importante es el identificador de cada componente, por ello siempre que se

cree un widget habrá que detallar su identificador (id). A través de ese

identificador es por el cual nos vamos a referir a los widgets implementados.

Dojo proporciona dos funciones para buscar un widget especifico pasándoles

como parámetro su id. Una de ellas es dijit.byId(), lo que devuelve esta función

es un objeto JavaScripts. La otra función es dojo.byId(), tiene las mismas

características que la anterior solo que en vez de devolver un objeto JavaScript

devuelve un nodo DOM (DOMNodes).

5.3. Estructura principal

En este apartado se explica el proceso de creación de la estructura principal,

como empezó a construirse y como quedo estructurada al final.

En un principio se empezó a estructurar la aplicación web utilizando los layouts

que ofrece Dojo (explicados en el punto 4.3. Estructura interfaz de usuario y sus

componentes). Usando un borderContainer como layout principal y definiendo

sus distintas partes. Estos layouts se implementaron en la vista index.phtml, la

vista asociada al controlador por defecto IndexController, que era donde íbamos

a incluir todas las funciones de la estructura. Tras tener varios problemas con la

implementación de esta estructura de layouts, ya que en la página oficial no se

encontraba información completa se llego a tener un resultado óptimo,

utilizando el método captureStart() y captureEnd().

78

Un trozo del código de creación de esos layout es el siguiente:

5.7. Creación estructura con layouts

El contenedor creado para la autenticación hace referencia a una acción del

controlador definido específicamente para albergar la funcionalidad de todo el

login/logout de usuarios. Así como también se crean controladores por cada

módulo de la aplicación. En el contenedor central irá mostrando el módulo que

el usuario escoja en el menú lateral.

De forma paralela se fue implementando el primer módulo, Mapa de

dispositivos. Pero a la hora de integrar en la estructura una primera versión

simple del módulo, empezó a dar problemas. Así como el módulo de

autenticación se había incorporado sin problemas, el módulo de Mapa de

Dispositivos no se lograba ver en el contenedor principal de la estructura.

Tras intentar solucionar este problema de varias formas, sin obtener ningún

resultado positivo, se decidió, tras una reunión, implementar la estructura a

través del concepto ‘two step views’.

El concepto ‘two step views’ hace referencia al hecho de crear una plantilla

(layout de ZF) que contenga la cabecera, el menú lateral derecho, el menú

izquierdo y el pie. Este layout se crea en el directorio /application/views/layouts

con el nombre layout.phtml. En este archivo se incluye la cabecera y el pie,

79

renderizando el archivo _header.phtml y _footer.phtml que también se

encuentran en el directorio /layouts.

La estructura del layout se crea a través de etiquetas <div> de HTML, y en cada

etiqueta se van sacando las distintas partes: menú principal, menú derecho

(anuncios), contenedor principal y menú rápido. Todas estas partes son distintas

vistas.

5.8. Layout.phtml

El quickmenu es un menú horizontal que se decidió añadir con las partes más

utilizadas de la aplicación. En cuando a content ($this ->layout()->content; )

no se refiere a ninguna vista sino que indica el contenedor que va a ir variando

dependiendo del módulo seleccionado por el usuario, el que va a aparecer por

defecto va a ser ’home’, que esta implementado el la vista index del controlador

index. Todos estos elementos del layout se encuentran en el directorio

/views/index, ya que todas están relacionadas con el controlador

IndexController, controlador por defecto.

Todo lo que no este aquí englobado tendrá un controlador aparte y unas vistas

relacionadas a cada controlador. Por ejemplo la autenticación va con otro

controlador aparte (AuthController.php).

80

Mientras se continuaba con la implementación del modulo Mapa de dispositivos,

Arturo terminó la estructura con ‘two step views’ y la parte de autenticación

basándose en la que ya se había hecho y posteriormente descartado por los

problemas que surgieron y que ya se han descrito. La autenticación ya incluye el

control de roles.

5.4. Menú Principal

Con la estructura ya montada se inició la implementación del menú principal. En

un principio se había desarrollado un menú a través del widget de Dojo

AccordionContainer, pero el resultado obtenido no fue el esperado, ya que la

navegación resultaba un poco confusa. Por ellos se decidió implementarlo

mediante el componente de dijit.Tree (para crear árboles de directorios).

En la vista del menú, se crea un contenedor para el árbol, pero el componente

dijit.Tree se crea en un archivo JavaScript referenciado en la vista. En ese archivo

JavaScript, a parte de crear el árbol para el menú también se solicitan los datos

con los que se tiene que rellenar el menú. Esta solicitud se hará a través de una

llamada Ajax al controlador y el controlador solicita los datos al Modelo del

Menú. En el Modelo los datos se crean mediante la declaración de un array.

El contenido del menú no siempre va a ser el mismo, ya que variará del rol del

usuario que este utilizando la aplicación. Esto se controla en el Modelo. Cuando

el controlador pide los datos al Modelo, le pasa como parámetro el rol el usuario,

y el modelo devuelve un array u otro dependiendo del rol.

81

5.9. Función Ajax en el Controlador

Problemas

Algunos de los problemas surgidos a la hora de implementar el menú han sido:

� Surgieron problemas a la hora de definir la llamada Ajax en parte del

controlador, en un principio no sabía donde especificarla. Se intentó

especificar en la misma acción de la vista del menú, pero esto provocaba

errores.

SOLUCIÓN: crear una función específica para la llamada Ajax, esto dentro

del mismo controlador donde estaba la acción asociada a la vista del

menú.

� Problema con las hojas de estilo. El menú se mostraba con el aspecto de

una estructura de directorios, ya que solo estaba utilizando los temas

(themes) de Dojo. Lo que hacía falta era darle un aspecto de menú. Pero

al intentar modificar nuestras propias hojas de estilo se producían

conflictos con las hojas de estilo de Dojo. También se producían errores al

cambiar directamente las propias hojas de estilo de Dojo.

SOLUCIÓN: copiar el código de las hojas de estilo de Dojo en nuestras

propias hojas de estilo y desde ahí modificar los datos necesarios. Esta

solución adoptada fue una solución parcial. Más adelante se explicará la

82

solución definitiva, ya que este problema no solo afectaba al menú, sino

que afectaba a todas las secciones donde se utilizasen elementos de Dojo

y se quisiera cambiar algo de su aspecto.

A continuación se muestra el proceso de cambio de estilo del menú:

5.10. Cambiando estilo Menú Principal 5.11. Menú Principal

5.5. Módulos

5.5.1. Mapa de Dispositivos

Para este módulo es necesario crear un controlador, mapofdevicesController,

este controlador solo necesita una acción, lo demás son funciones Ajax o

funciones internas del propio controlador, por lo que solo tiene una vista

asociada. Respecto a los modelos se han creado uno por cada tabla de la Base de

Datos necesarias para la realización de todo el módulo.

En el archivo de la vista no se ha implementado casi nada del Mapa de

Dispositivos, solo se ha creado un contenedor para alojar todos los clientes y

todos los dispositivos, y también se ha creado el checkbox necesario para

83

controlar que clientes se visualizan (solo los disponibles o todos). Todo lo demás

se realiza en un archivo .js que se incluye en la vista a través del siguiente código:

5.12. Incluir un archivo .js en una vista

Cambios importantes respecto al Diseño

En el apartado de diseño se determinó el uso del widget dijit.toolTip para

mostrar la información adicional tanto de los clientes como de los dispositivos.

Estos dispositivos se llegaron a implementar, con algunos problemas menores,

pero se obtuvo resultado, se mostraba la información adicional dentro de los

toolTip. Una vez implementados, se encontró un inconveniente, no se podía

acceder a la información de los toolTip, si un usuario quería seleccionar esa

información para copiarla (ctrl+c), no podía. Los toolTip solo se mostraban al

pasar el ratón por encima de los clientes o de los dispositivos pero al ponerlo

encima de los toolTip, estos desaparecían. Iba a ser frecuente el uso de esa

información por lo tanto se decidió remplazar los toolTip.

La mejor opción posible que se vio, después de estudiar el caso, fue el uso de

toolTipDialog. ToolTipDialog un widget parecido a toolTip, pero que se mantenía

quieto al pasar el ratón por encima. Lo que se hizo fue crear un evento

“onMouseOver” asociado a los títulos (parte principal de los componente

dijit.TitlePane) de cada cliente y de cada dispositivo. Ese evento lo que hace es

llamar a una función para que se active un pop-up a través del componente que

ofrece Dojo, dijit.popup, y asociado a él un dijit.TooltipDialog.

Partes de código

En la siguiente imagen se muestra el código de una función del Modelo de la

tabla Dut, tabla de dispositivos. La función devuelve el número de dispositivos

disponibles de un cliente con una id determinada como parámetro.

84

5.13. Consulta a la tabla Dut de la BD

El método fetchAll() devuelve las filas seleccionadas por la consulta $select y lo

que devuelve la función es el número de filas.

El controlador de este módulo consta de dos funciones, funciones Ajax las dos,

principales. Una para crear los clientes y otra para crear los dispositivos. No crea

los objetos en sí ya que de esto se encarga la vista, el archivo JavaScript en

concreto. Lo que hacen estas funciones es recoger la información necesaria de

los Modelos, estructurarla y devolverla a la vista.

85

5.14. Acción del controlador mapofdevicesController

Problemas

� Hacer ‘clic’ en los clientes. Al hacer clic en un cliente (en un

dijit.TitlePane), éste se despliega y muestra en su contenedor todos sus

dispositivos asociados. Estos dispositivos se cargan al desplegar el cliente

y se borran cada vez que se colapsa. Las funciones de crear y borrar los

dispositivos, se definían en el evento “onClick” del titlePane cliente. El

problema surgía cuando el cliente estaba desplegado, mostrando sus

dispositivos y el usuario clicaba en uno de ellos, a parte de pinchar en un

dispositivo también estaba clicando en el objeto cliente, por lo tanto se

volvían a crear los dispositivos del cliente y saltaba un error. Se estaba

intentando crear un componente (un dispositivo) con una id que ya

existía.

SOLUCIÓN: La solución era asociar el evento “onClick” sólo a la parte del

título del cliente, no asociarlo a todo el objeto. Tras muchas pruebas y

86

muchos intentos con opciones distintas, ya que la documentación no

daba una solución valida para este caso, se consiguió dar con el objeto

adecuado para referirse al titulo del titlePane de un cliente, titleBarNode.

� En Explorer 9 no se ven los dijit.toolTip. Todos los exploradores

mostraban sin problemas los toolTip de cada cliente y de cada dispositivo

Pero al probarlo en IE9, en concreto, este objeto no se mostraba.

SOLUCIÓN: la versión Dojo 1.6. no es compatible con IE9 y algunos

componentes provocan fallos. Sin embargo la versión Dojo 1.6.1 si es

compatible. Todo se solucionó actualizando la versión de Dojo.

� El menú no se cargaba en la página del Mapa de dispositivos. El menú se

veía bien en cualquier otra página menos en la de Mapa de Dispositivos,

por eso se asoció el problema a este módulo y no al menú.

SOLUCIÓN: había un conflicto con los nombres de las funciones ‘onLoad’

en los archivos JavaScript. Estas funciones eran las encargadas de cargar

todo el menú o todo el Mapa de dispositivos. Para resolver el conflicto se

utilizaron dos maneras distintas de cargar la función principal que

generaba todo el resto de código de los archivos .js.

87

5.5.2. Servidor Linux

Este módulo es un sub-apartado del módulo Build Server, por lo que el

controlador que usa es el creado para el módulo Build Server

(BuildserverController). Este controlador constará de su acción por defecto,

indexAction, y una acción por cada uno de los dos sub-apartados. El resto del

contenido del controlador serán funciones Ajax. Para el módulo Servidor Linux

(Linux Server) estará asociada una vista, la correspondiente a la acción del

controlador. Existirá un único Modelo, la única tabla de la BD necesaria para

implementar Servidor Linux.

La vista se organiza como en el módulo Mapa de Dispositivos, es decir, no se

implementa casi nada en esa parte del cliente sino que se hace prácticamente

todo desde el archivo JavaScript (buildserver.js). En el archivo de la vista no se

implementa la estructura básica de layout, comentada en el diseño, una

estructura usando el componente TabContainer de Dojo.

Problemas

� Problemas con la visualización de las tablas. Después de haber creado la

tabla de Dojo dojox.grid.GridData con todas las propiedades necesarias y

agregando unos datos de prueba, a la hora de visualizarla no parecía una

tabla, el nombre de las columnas estaba desordenado, las celdas no

constaban de ningún tipo de separación, … En definitiva, la tabla se veía

mal.

SOLUCIÓN: para este componente, en concreto, hace falta añadir las

hojas de estilo del componente Grid en la vista del módulo. No vale solo

con hacer referencia al tema en la etiqueta <body>, como para los demás

componentes. Los dos archivos añadidos fueron los siguientes:

../dojox/grid/resource/Grid.css

../dojox/grid/resource/tundraGrid.css

� Problema con fechas. Se producía un error al comparar una fecha del

calendario con una fecha de la BD.

88

SOLUCIÓN: la fecha de la BD es un String, hay que pasarlo a objeto Date a

través de dojo.date.locale.parse() uno de los métodos que proporciona el

objeto dojo.date, objeto para tratar las fechas del calendario. Una vez

convertida la fecha, esta ya se puede comparar con un día del calendario

a través del método dojo.date.ocale.compare().

� Imágenes de la primera columna de las tablas. Al intentar introducir las

imágenes en la primera columna de las tablas (columna para indicar si

todo ha ido bien o no, tick o cruz), aparecía la url de la imagen en vez de

aparecer la propia imagen. Esto ocurría tanto en la tabla del apartado

Build Server List como en la tabla de ReleaseTags.

SOLUCIÓN: en la implementación de la tabla, hay que poner la propiedad

escapeHTMLInData a false para que así pueda entender la etiqueta <img>

utilizada para incluir las imágenes.

5.5.3. Funciones genéricas

No se ha comentado anteriormente pero existe un archivo JavaScript encargado

de contener funciones genéricas, es decir, funciones que se van a utilizar en

varios módulos o que se utilizan varias veces en un mismo módulo. También se

colocarán funciones que sólo se hallan utilizado una vez, pero en un futuro o en

la implementación de otro modulo se puedan llegar a usar.

Una de las funciones que va en este archivo es una función genérica para crear

llamadas Ajax:

89

5.15. Función genérica llamada Ajax

Dentro de esta función, aparte de detallar la llama Ajax con dojo.xhrPost (como

ya se explicó en el punto 4.2. Llamadas asíncronas con Zend Framework y Dojo)

también se crea un sistema opcional para añadir una imagen para mostrar

mientras se esta realizando la llamada Ajax. No todas las llamadas Ajax tienen

que llevar asociada una imagen de loading.

Otras de las funciones incluidas en este archivo son funciones para crear widgets

de Dojo, por ejemplo el widget titlePane se crea varias veces en el módulo Mapa

de dispositivos. Ahí recurriremos a la función genérica para crear un titlePane.

90

5.6. Pruebas

La realización de pruebas sobre una aplicación es algo importante. Proporcionan

una seguridad de que lo desarrollado hasta el momento va por buen camino. Es

una forma de comprobación del código implementado. Cuantas más pruebas se

realicen menos probabilidad de fallos.

Durante la implementación de la aplicación se han ido haciendo abundantes

pruebas, estas pruebas se podrían denominar micro-pruebas. No se han

realizado pruebas sobre conjuntos grandes de código, sino que se han ido

realizando con cada funcionalidad implementada, o pequeña parte desarrollada.

Las pruebas realizadas constantemente, a lo largo de todo el desarrollo de la

aplicación, han sido las de comprobación del funcionamiento en distintos

entornos, distintos navegadores. Tanto para comprobar la distribución de los

componentes, su aspecto visual y su comportamiento.

91

6 GESTIÓN DEL PROYECTO En este apartado se va a tratar la gestión real del proyecto. En el apartado 1 DOP:

Documento de Objetivos del Proyecto se trató la “futura” gestión del proyecto, se

hicieron aproximaciones y estimaciones del tiempo y distribución de actividades,

pero en este capítulo se estudian los tiempos reales, la comparación entre lo

estimado y lo real.

92

6.1. Duración real del proyecto

La duración real del proyecto se ha alargado más de lo previsto, debido a

distintos factores que explicaremos más adelante en el apartado 6.3. Motivos del

desfase. Los paquetes mas afectados en este desfase han sido el paquete de

Dirección del Proyecto y el de Implementación, debido a las actividades de

aprendizaje, documentación e implementación.

6.1. Diagrama circular estimación real de horas

Las horas empleadas han sido:

Dirección del Proyecto: 224 horas

Análisis (Iniciación): 24 horas

Diseño: 28 horas

Implementación: 458 horas

Análisis de Resultados e Integración: 16 horas

Total: 750 horas

El proyecto en sí se realizaba en la empresa y luego se complementaba ese

trabajo en casa. La duración del proyecto se estimó en 6 meses, pero como luego

esa duración se amplió tuve que trabajar desde casa, ya que el contrato de

93

prácticas (por el cual podía trabajar en la empresa) terminaba a los 6 meses y la

universidad no permitía renovarlo debido a que solo se pueden realizar 6 meses

de prácticas por curso académico. Por ello a partir del 5 de Marzo se siguió

desarrollando la aplicación y las demás tareas del proyecto en casa,

manteniendo el contacto con el tutor de la empresa.

Todo esto se refleja en el calendario de trabajo que se detalla a continuación:

6.2. Calendario de trabajo real

94

El proyecto se ha desarrollado principalmente por las mañanas y los fines de

semana debido a la incorporación a un trabajo externo a partir de Enero.

6.2. Comparación tiempos estimados – tiempos reales

En la siguiente tabla se muestran los tiempos (horas) estimados y los reales

correspondientes a las distintas actividades en las que esta dividido el proyecto.

En rojo se marcan las actividades que se habían estimado con optimismo, por lo

que el tiempo real de desarrollo ha sido mayor.

Actividades Horas estimadas Horas reales

Dirección del proyecto 142 horas 224 horas

Aprendizaje e investigación 30 horas 98 horas

Reuniones 12 horas 12 horas

Planificación 20 horas 24 horas

Memoria 70 horas 80 horas

Defensa 10 horas 10 horas

Análisis 20 horas 24 horas

Análisis de Requisitos 4 horas 4 horas

Análisis del sistema 10 horas 10 horas

Estudio módulos de aprendizaje 6 horas 10 horas

Diseño 30 horas 28 horas

Diseño de la estructura 8 horas 10 horas

Diseño de los módulos 12 horas 10 horas

Revisión del diseño 10 horas 8 horas

Implementación 268 horas 458 horas

Implementación módulos de aprendizaje 32 horas 94 horas

Implementación de la estructura 48 horas 80 horas

Implementación de los módulos 180 horas 274 horas

Revisión de la implementación 8 horas 10 horas

Análisis de Resultados e integración 13 horas 16 horas

Ejecución de pruebas 8 horas 11 horas

Integración 4 horas 4 horas

Entrega y aprobación de documentación 1 horas 1 horas

6.3. Tabla comparación de tiempos

95

El total de horas estimadas fueron 473 h. y el total de horas reales son 750 h. por

lo que el desfase del proyecto ha sido de 277 horas. El desfase se ha producido

sobre todo en la etapa de Dirección del Proyecto y la de Implementación, debido

a la poca experiencia en la realización de estimaciones en proyectos y debido a

los problemas surgidos.

A continuación se muestra un diagrama de barras para expresar gráficamente la

comparativa de los tiempos estimados con los tiempos reales:

6.4. Diagrama Tiempos estimados – Tiempos reales

6.3. Motivos del desfase

En este apartado se explican los problemas surgidos o distintas circunstancias

que se han dado a lo largo del proyecto y han provocado un desfase del tiempo

estimado al comienzo de éste.

� Desconocimiento de Tecnologías

El desconocimiento de los frameworks en general y en concreto de los

dos utilizados, Zend Framework y Dojo Toolkit, añadido a la poca

experiencia en el desarrollo de aplicaciones web ha hecho que fueran

96

surgiendo dificultades y esto provocara retrasos. La curva de aprendizaje

de los dos frameworks ha sido mas pronunciada de lo que se había

previsto y de algún modo durante todo el proyecto no se ha dejado el

aprendizaje de éstos.

� Problemas con los frameworks

Problemas a la hora de instalarlos y conseguir la comunicación y el

entendimiento entre ellos. Estos problemas, en gran parte, estaban

debidos al punto anterior, el desconocimiento de la tecnología.

� Estimaciones optimistas

Debido a la poca experiencia del proyectante en proyectos de esta

envergadura las estimaciones han sido poco realistas, en la mayoría de

los casos han sido demasiado optimistas.

� Proyecto real, dependencia de la empresa

Este proyecto no está ideado exclusivamente para un PFC sino que

también era requerido por una empresa. Es un proyecto real y esto

conlleva depender de la empresa para su realización. Por ejemplo, a la

hora de dejar algo terminado, la empresa era bastante exigente, sobre

todo con el aspecto visual final.

� Trabajo por las tardes

A mediados de Enero surgió un trabajo no previsto que impidió la

dedicación al proyecto de prácticamente todas las tarde entre semana.

97

7 CONCLUSIONES Este es uno de los últimos capítulos de la memoria, debido a que en este

apartado se plasman las ideas finales, tanto de la aplicación desarrollada en sí

como también las conclusiones personales.

98

Tras la realización de este proyecto se han podido comprender, más en

profundidad, muchos conceptos relacionados con aplicaciones web, que durante

la carrera no se habían podido ver o experimentar. Sobre todo se ha afianzado y

comprendido mucho mejor el concepto de framework, y su aplicación en

proyectos ya existentes.

La curva de aprendizaje ha sido bastante elevada. Se han dejado varios frentes

abiertos, ya que muchos de los módulos no se han llegado a implementar, pero

se ha creado una estructura sólida. Para que a partir de esto se pueda seguir

desarrollando el resto de módulos e incluso crear algunos nuevos, no existentes.

Durante el desarrollo del proyecto se ha ido viendo la importancia de la

planificación y del estudio previo de todas las características del proyecto, para

así obtener un mejor resultado. También se ha comprendido la importancia de

implementar un código ordenado, con comentarios y sobre todo que es mejor

dividirlo en varias funciones más simples, en vez de implementar funciones muy

extensas y complejas.

El proyecto se ha llevado a cabo en una empresa, esto a supuesto la experiencia

en la realización de un proyecto real y el enriquecimiento en cuanto a

experiencia laboral, algo muy bueno de cara a un futuro más o menos inmediato.

99

8 BIBLIOGRAFÍA En este apartado se van a detallar las distintas fuentes de información utilizadas

a lo largo de todo el proyecto.

100

Una de las fuentes utilizadas han sido los libros, tanto en formato digital como en

formato físico:

� Begining Zend Framework – Armando Padilla

� ZendEnterprise PHP – John Coggeshall, Morgan Tocker

� ZendFramework in Action – Rob Allen, Nick Lo

� Dojo the definitive guide – Matthew A.Russell

� Pro PHP Patterns, Frameworks, Testing and More - Kevin McArthur

� Programación en JavaScript – Jose Manuel Alarcón

� Adding Ajax – Shelley Powers

� PHP 6 – Francisco Charte Ojeda

Mucha otra información se ha obtenido de diferentes paginas web que se detallan a continuación:

º Páginas oficiales:

� http://www.dojotoolkit.org: web oficial de Dojo Toolkit para

descargar el framework y obtener toda la información sobre él.

� http://www.framework.zend.com: web oficial de Zend Framework, desde donde se descargó el framework, y sitio para obtener información.

º Otras páginas web:

� http:// http://angelorum.blogspot.com.es/2010/09/zend-

framework-1-instalacion.html: blog donde se pueden encontrar varios artículos sobre ZF, como instalarlo, explicación de sus componentes, trabajar con Ajax,…

� http://zfdes.com/index.php/Portada: documentación sobre Zend Framework en español.

� http://www.roseindia.net/dojo: tutorial sobre Dojo.

trabajo fin de estudios - unirioja · 2012-10-25 · diagrama de gantt ..... 26 3.1. diagrama de...

Documents