Migración de Infraestructura Web A Una Nueva Estructura Basada en Frameworks

TRABAJO FIN DE ESTUDIOS
PROYECTO FIN DE CARRERA
Migracin de infraestructura web a una nueva

estructura basada en frameworks
Ana Ruiz Parmo
Tutor: Angel Luis Rubio Garca

Curso 2011-2012
Migracin de infraestructura web a una nueva estructura basada en

frameworks, trabajo fin de estudios
de Ana Ruiz Parmo, dirigido por Angel Luis Rubio Garca (publicado por la Universidad de
La Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.
Permisos que vayan ms all de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.
El autor
Universidad de La Rioja, Servicio de Publicaciones, 2012
publicaciones.unirioja.es
E-mail: publicaciones@unirioja.es
FACULTAD DE CIENCIAS, ESTUDIOS AGROALIMENTARIOS

E INFORMTICA
PROYECTO FIN DE CARRERA

Ingeniera Tcnica en Informtica de Gestin
Migracin de infraestructura web a una nueva

estructura basada en frameworks
Alumno: Ana Ruiz Parmo

Director: D. ngel Luis Rubio Garca
Logroo, 8 Junio 2012
RESUMEN
Esta memoria recoge los aspectos ms relevantes del proyecto desarrollado
Migracin de infraestructura web a una nueva estructura basada en
frameworks. Estos aspectos son desde la planificacin del proyecto, la recogida
de requisitos, el diseo o los problemas surgidos a la hora de la implementacin.
El desarrollo de este proyecto surge de la necesidad de la empresa Digi
International Spain S.A. de portar la infraestructura actual que tenan a una
nueva basada en frameworks.
ndice General
1. Introduccin.................................................................................................................. 11
2. DOP: Documento de Objetivos del Proyecto .............................................................. 13

2.1. Antecedentes ......................................................................................................... 14
2.2. Objetivos ................................................................................................................ 15
2.3. Descripcin ............................................................................................................. 15
2.4. Alcance ................................................................................................................... 16
2.5. Recursos humanos ................................................................................................. 16
2.6. Tecnologa y arquitectura ...................................................................................... 17
2.6.1. Tecnologa ....................................................................................................... 17
2.6.2. Arquitectura .................................................................................................... 19
2.7. Planificacin ........................................................................................................... 20
2.7.1 Estructura de descomposicin del Proyecto (EDP) .......................................... 20
2.7.2. Diccionario de la EDP ...................................................................................... 20
2.7.3. Estimacin del proyecto.................................................................................. 24
2.7.4. Calendario ....................................................................................................... 25
2.7.5. Diagrama de Gantt .......................................................................................... 26
2.8. Riesgos.................................................................................................................... 27
3. Anlisis .......................................................................................................................... 31
3.1. Descripcin de la aplicacin ................................................................................... 32
3.1.1 Zend Framework .............................................................................................. 33
3.1.2 Dojo Toolkit ...................................................................................................... 34
3.2. Anlisis de requisitos .............................................................................................. 35
3.2.1 Requisitos no funcionales ................................................................................ 35
3.2.2 Requisitos funcionales ..................................................................................... 37
3.2.2.1 Actores ..................................................................................................... 37
3.2.2.2 Diagrama de Casos de Uso ....................................................................... 38

3.2.2.3 Especificacin de Casos de Uso ................................................................ 39
3.3. Definicin de mdulos de aprendizaje................................................................... 43
4. Diseo ........................................................................................................................... 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 asncronas con Zend Framework y Dojo ................................................ 53
4.3. Estructura interfaz de usuario y sus componentes ................................................ 56
4.4. Mdulos ................................................................................................................. 59
4.5. Bases de datos........................................................................................................ 64
5. Implementacin ........................................................................................................... 69
5.1. Estructura del proyecto .......................................................................................... 70
5.1.1 Estructura de directorios ................................................................................. 70
5.1.2 Integracin Zend Framework - Dojo ................................................................ 71
5.1.3 Componentes del patrn MVC ........................................................................ 72
5.2. Componentes de Dojo Toolkit................................................................................ 75
5.3. Estructura principal ................................................................................................ 77
5.4. Men principal ....................................................................................................... 80
5.5. Mdulos ................................................................................................................. 82
5.5.1 Mapa de dispositivos ....................................................................................... 82
5.5.2 Servidor Linux................................................................................................... 87
5.5.3 Funciones genricas ......................................................................................... 88
5.6. Pruebas................................................................................................................... 90
6. Gestin del proyecto .................................................................................................... 91

6.2. Duracin real del proyecto ..................................................................................... 92
6.3. Comparacin tiempos estimados tiempos reales ............................................... 94
6.4. Motivos del desfase ............................................................................................... 95
7. Conclusiones ................................................................................................................. 97
8. Bibliografa.................................................................................................................... 99
ndice de imgenes
2.1. Arquitectura de la aplicacin ................................................................................. 19
2.2. Estructura de descomposicin del proyecto .......................................................... 20
2.3. Diagrama circular estimacin 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. Patrn 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. Configuracin Base de Datos ............................................................................... 66
4.15. Zend_db_select .................................................................................................... 67
4.16. Mtodo fetchAll() ................................................................................................. 67
4.17. Mtodo fetchAll() [2]............................................................................................ 68

5.1. Estructura de directorios........................................................................................ 70
5.2. Configurar Dojo. ..................................................................................................... 71
5.3. Ejemplo clase del Modelo. ..................................................................................... 73
5.4. Paso informacin Controlador - Vista. ................................................................... 75
5.5. Creacin widget, declarativa. ................................................................................. 75
5.6. Creacin widget, programtica. ............................................................................. 76
5.7. Creacin estructura con layouts. ........................................................................... 78
5.8. Layout.phtml. ......................................................................................................... 79
5.9. Funcin 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. Accin del controlador mapofdevicesController ................................................. 85
5.15. Funcin genrica llamada Ajax............................................................................. 89
6.1. Diagrama circular estimacin real de horas........................................................... 92
6.2. Calendario de trabajo real...................................................................................... 93
6.3. Tabla comparacin de tiempos .............................................................................. 94
6.4. Diagrama tiempos estimados tiempos reales ..................................................... 95
10
1 INTRODUCCIN
La presente memoria plasma el trabajo llevado a cabo en el desarrollo del
proyecto con nombre Migracin de infraestructura web a una nueva estructura
basada en frameworks.
Se trata de la migracin de una aplicacin web ya existente en la empresa que
propuso el proyecto. Es una aplicacin usada por los propios trabajadores,
llamada Web Interface for Automation of Test Plans. Necesita ser
restructurada basndose en dos frameworks.
No se va a desarrollar una aplicacin nueva, pero si se va a crear una estructura
desde cero y a partir de ese esqueleto se ir desarrollando la aplicacin siempre
basndose en la ya existente.
El aprendizaje de los dos frameworks y de su adaptacin a las necesidades de la
aplicacin son puntos importantes de este proyecto.
11
12
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 descomposicin de
tareas,
13
2.1. Antecedentes
Digi International es una empresa internacional con sede en Minnetonka en el
estado de Minnesota (Estados Unidos). Se dedica a la fabricacin de productos y
tecnologas que facilitan la conexin de dispositivos a la red (LAN), empresa lder
en soluciones ConnectWare. Alguno de estos productos son servidores de
dispositivos integrados, servidores serie, dispositivos para administracin de
consola o mdulos embebidos. Todos estos productos se distribuyen
principalmente a los sectores hospitalario, financiero y mdico.
La nica oficina Espaola se encuentra en Logroo, en ella es en la que he
desarrollado mi proyecto. Consta de un equipo de Ingenieros Electrnicos los
cuales desarrollan los dispositivos propiamente dichos y por otro lado tambin
tienen un equipo de Ingenieros Informticos, 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 dara solucin al problema, tambin 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 ms
rpido desarrollo.
14
2.2. Objetivos
Con este proyecto se pretenden alcanzar varios objetivos, que los describo a
continuacin:
Familiarizarse con hacer un proyecto, ya que a lo largo de la carrera se
estudia mucha teora sobre el desarrollo de un proyecto pero no se lleva
a la prctica con individualidad.
Adquirir conocimientos sobre los temas y herramientas que son
necesarios utilizar para la realizacin 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 migracin 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. Descripcin
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 algn Framework conocido
y preservar la lgica actual de usuario.
El sistema actual tiene caractersticas 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 razn, la infraestructura debe estar
libre de procesos innecesarios, y usar el lado del cliente para realizar la mayora
del trabajo, minimizando la transferencia entre el servidor y el cliente.
15
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 verstil.
En el lado del servidor se eligi el framework Zend Framework, que por el
contrario, es un framework simple y eficiente. Caractersticas necesarias para el
objetivo de minimizar la carga del servidor.
En el apartado de Tecnologas empleadas y arquitectura (2.6 Tecnologa y
arquitectura) se amplia la informacin sobre los dos framework y el porqu de su
eleccin.
2.4. Alcance
Al finalizar este proyecto lo que se tendr es lo siguiente:
La migracin de la antigua infraestructura web a una nueva basada en
frameworks.
Manual de instalacin de los dos frameworks.
Memoria del proyecto
Presentacin del proyecto
En cuanto al alcance de los mdulos de la aplicacin, desde un principio no se
acord la cantidad de mdulos que se iban a realizar. Lo ms importante es
conseguir realizar la estructura bsica, integrar los dos frameworks, y hacer una
separacin entre una parte pblica y otra parte privada.
2.5. Recursos humanos

A continuacin, se exponen las personas implicadas en este proyecto.
o Ana Ruiz Parmo: proyectante y directora del proyecto.
16
o ngel Luis Rubio: tutor del proyecto. Se encarga del asesoramiento y

orientacin sobre los aspectos del proyecto fin de carrera.
o Digi International S.A.: cliente, empresa que propone el proyecto.
o Carlos Marn: tutor de la empresa. Se encarga del seguimiento del
proyecto y la orientacin del mismo.
o Arturo Buzarra: desarrollador de la antigua estructura web. Se encarga de
orientacin sobre los aspectos tcnicos o conceptuales del desarrollo de
la nueva estructura.
o Miembros del tribunal: grupo de profesores encargados de la evaluacin
del proyecto.
2.6. Tecnologa y arquitectura

2.6.1. Tecnologa
Las tecnologas que se van a usar para la realizacin del proyecto se describen a
continuacin:
Apache: es el servidor web escogido para para el desarrollo de la
aplicacin web.
(Apache v2.2.17)
MySQL (v5.5.8)
PHP: lenguaje de programacin elegido para la creacin de la aplicacin
web. Se decidi este lenguaje, a parte de porque la aplicacin que ya
tenan 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 tecnologa
AJAX.
17
Dojo Toolkit se escogi por ser un framework potente, con abundante

contenido y relativamente fcil y rpido de aprender, dentro de lo que
conlleva aprender a manejar un framework.
Zend Framework: es un framework de cdigo abierto para desarrollar
aplicaciones web y servicios web con PHP 5. Los componentes de este
framework tienen una dbil dependencia entre ellos lo que permite
utilizar sus componentes por separado, ZF es una implementacin que
usa cdigo totalmente orientado a objetos. Algo que ofrece este
framework es el uso del patrn MVC, el cual vamos a usar en el proyecto.
Otra caracterstica interesante para la aplicacin es que ZF es simple y no
requiere una estructura demasiado complicada, que involucren una gran
cantidad de archivos, para elaborar una pgina de Hello World.
Los dos frameworks son compatibles con todos los navegadores, requisito
importante a la hora de implementar nuestro sitio web.
Navegadores: la aplicacin se va a usar en distintos navegadores, ya que
no todos los usuarios de la aplicacin (trabajadores de la empresa)
tendrn el mismo navegador como favorito. Los navegadores usados
sern:
o
o
o
o
Internet Explorer 8 y 9
Firefox (ultima versin)
Opera (ltima versin)
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 intrprete para el lenguaje PHP, a parte de phpMyAdmin para el
acceso y gestin 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
18
2.6.2. Arquitectura
En este apartado se quiere explicar la arquitectura de la aplicacin web
(cliente/servidor), donde el framework Dojo va a encargarse de la parte del
cliente, la que vern 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 aplicacin
19
2.7. Planificacin
2.7.1. Estructura de Descomposicin del Proyecto (EDP)
2.2. Estructura de descomposicin del proyecto
2.7.2. Diccionario de la EDP

En este apartado se hace una descripcin mas detallada de los distintos
paquetes de la EDP y cada una de las actividades de estos paquetes.
Direccin del proyecto
Este paquete abarca todas las actividades relacionadas con la gestin del
proyecto y aquellas que sirven de seguimiento del mismo.
20
Aprendizaje e investigacin: En esta actividad se engloban todas las tareas de

formacin y ampliacin de conocimientos necesarios para la realizacin y
comprensin del proyecto.
Estimacin: 30 horas.
Reuniones: Todas las reuniones que se realizarn tanto con el tutor de la

Universidad, ngel Luis Rubio, como con los miembros de la empresa, Carlos
Marn y Arturo Buzarra.
Planificacin: Se trata del desarrollo inicial del proyecto, desarrollar la ligera

idea que me pudo dar el tutor en un principio, ir recopilando ms informacin.
Tambin recoge la realizacin del DOP.
Memoria: Elaboracin del documento que forma parte del Proyecto Fin de
Carrera y bsqueda de informacin para la realizacin de ste.
Defensa: Esta actividad hace referencia a la preparacin de la defensa ante el

tribunal (elaboracin de cualquier material necesario, ensayos,). As como la
presentacin propiamente dicha.
Estimacin: 10 hora.
Anlisis (Iniciacin)
En este paquete se incluyen todas las actividades que sirven para realizar una
descripcin ms detallada del proyecto y una especificacin ms precisa de los
requisitos.
21
Anlisis de Requisitos: Anlisis del comportamiento externo del sistema,

concretar las funciones que espera el usuario.
Estimacin: 4 horas.
Anlisis del sistema: Comprender el sistema existente en la empresa, el que se

va a renovar, analizar todo su esquema y sus componentes.
Estudio mdulos de aprendizaje: Se estudiar la posibilidad de hacer unos

mdulos de prueba para cerciorarse del funcionamiento, sobre todo de los
framework, y as ir aprendiendo sus entresijos. Tambin se mirar qu mdulos
son los idneos para desarrollar en ellos lo que luego se aplicar en el sistema a
realizar.
Estimacin: 6 horas.
Diseo
El paquete de Diseo contiene todas las actividades necesarias para la bsqueda
de soluciones que se ajusten a los requisitos planteados y analizados en el
paquete anterior (Anlisis).
Diseo de la estructura: Se har un anlisis detallado de la estructura que tiene
que tener el sistema aplicando todos los requisitos analizados con anterioridad.
Estimacin: 8 horas.
Diseo de los mdulos: Actividad que estudia cada uno de los mdulos que se
realicen en este proyecto. Y el estudio de las posibles soluciones para su
desarrollo.
22
Revisin del diseo: Abarca todo el paquete. Se realiza a lo largo de todo el

diseo, cualquier cambio de diseo entra en esta actividad.
Implementacin
Actividades que englobar toda la implementacin de las distintas partes del
proyecto.
Implementacin mdulos de aprendizaje: se implementaran los mdulos de
aprendizaje acordados. Estos mdulos no formaran parte de la aplicacin final,
pero sern mdulos de formacin y referencia.
Implementacin de la estructura: se implementar toda la estructura de la

aplicacin, incluyendo el men y la parte de la autenticacin.
Implementacin de los mdulos: se elaborarn todos los mdulos acordados,

tanto su implementacin como su integracin en la estructura ya realizada.
Revisin de la implementacin: se har a lo largo de todo el paquete de

implementacin, revisando el correcto funcionamiento si hay algn error en el
cdigo se proceder a solucionarlo.
Estimacin: 8 horas.
23
Anlisis de Resultados e Integracin

Ejecucin de pruebas: Realizacin de pruebas sobre las partes crticas de la
aplicacin web.
Estimacin: 8 horas.
Integracin: Se ir haciendo una integracin paulatina, de las distintas partes

desarrolladas en local, en el sistema de la empresa.
Estimacin: 4 horas.
Entrega y aprobacin de documentacin: Entrega de toda la documentacin

del proyecto al tutor para que la revise y su aprobacin para su presentacin.
Estimacin: 1 horas.
2.7.3. Estimacin del proyecto
2.3. Diagrama circular estimacin de horas
24
Este grfico representa las horas empleadas en la realizacin del proyecto,

expresadas en tanto por ciento y distribuidas segn los distintos paquetes
definidos en la EDP.
A continuacin se detallan las horas globales:
Direccin del proyecto: 142 horas
Anlisis (Iniciacin): 20 horas
Diseo: 30 horas
Implementacin: 268 horas
Anlisis de Resultados e Integracin: 13 horas
Total: 473 horas
2.7.4. Calendario
2.4. Calendario de trabajo
25
Explicacin ms detallada del calendario:

Empiezo en la empresa el da 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 maanas, menos
los mircoles que acudo por las tardes, ya que tengo practicas de la
asignatura por la maana. 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 documentacin. En el periodo de exmenes (las dos semanas de
Navidad) dejo de lado prcticamente 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 documentacin.
2.7.5. Diagrama de Gantt

En el siguiente diagrama de Gantt se puede apreciar el orden de las actividades
del proyecto y su duracin. Para poder realizar el proyecto en las fechas
previstas.
2.5. Diagrama de Gantt
26
2.8. Riesgos
Es importante identificar los posibles riesgos de un proyecto (la posibilidad de
que se produzcan daos o perdidas) y aportar algn tipo de solucin o plan de
contingencia, as se conseguir cometer un menor numero de errores en el
desarrollo del proyecto.
Seguidamente se exponen los posibles riesgos:
Cancelacin del proyecto
Descripcin: al tratarse de un proyecto real, la empresa que lo
propone puede llegar a decidir en algn momento que no quiere
seguir adelante con l.
o Cuantificacin: probabilidad baja.

o Plan de contingencia: si esto se produce al comienzo del proyecto se
puede pensar en redirigirlo hacia otro proyecto que tambin necesite

o le venga bien a la empresa. Si el proyecto ya est avanzado se
puede plantear su realizacin por nuestra cuenta, sin contar con la
empresa.
Desconocimiento de determinadas herramientas
Descripcin: 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 realizacin del proyecto.
o
o Cuantificacin: probabilidad alta.
Plan de contingencia: buscar informacin, libros o pginas que

aporten una buena documentacin, una buena descripcin de la
herramienta a utilizar.
o
27
Tecnologas mal elegidas

Descripcin: las tecnologas no consigan ofrecer las caractersticas
requeridas por el proyecto o den algn problema a la hora del
desarrollo con ellas.
o Cuantificacin: probabilidad media.
Plan de contingencia: realizar un nuevo estudio sobre otras

tecnologas que puedan emplearse y volver a valorar las
caractersticas que supliran estas nuevas tecnologas escogidas.
Perdida de los archivos del proyecto

Descripcin: prdida de algn archivo del proyecto o de la
informacin del ste.
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

Descripcin: 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 elaboracin del proyecto.
o Cuantificacin: probabilidad alta.
Plan de contingencia: realizar unas estimaciones no demasiado

optimistas ya que no somos expertos y las cosas no saldrn a la
primera sino que habr que darles varias vueltas y se cometern
errores.
28
Errores de diseo
Descripcin: es probable que no se comprendan completamente
ciertos requerimientos que debe cumplir el sistema y esto origine un
diseo poco optimo.
Plan de contingencia: se documentarn los errores cometidos y se

intentaran subsanar antes de empezar la implementacin del sistema
con un rediseo adecuado.
Cambios en los requisitos

Descripcin: durante el transcurso del desarrollo del proyecto
pueden surgir nuevas necesidades con respecto a la funcionalidad que
ofrece el sistema.
Plan de contingencia: hacer los cambios pertinentes en la

documentacin ya efectuada sobre los requisitos y ampliarla
especificando bien los nuevos.
Ausencia del proyectante

Descripcin: ausencia justificada del proyectante, ya sea por
enfermedad, trabajo o viaje, impidindole trabajar sobre el proyecto
en las fechas estimadas.
Plan de contingencia: se harn lo antes posible una replanificacin

de la duracin de todas las actividades afectadas por la ausencia.
29
30
3 ANLISIS
En este apartado se detallaran los requisitos y las especificaciones tanto
funcionales como no funcionales de cada parte de la aplicacin y se definirn los
casos de uso ms representativos.
31
3.1. Descripcin de la aplicacin

Este proyecto consiste en el desarrollo de una aplicacin web, esta aplicacin no
se desarrolla desde cero sino que est basada en una ya existente. La nueva
aplicacin se va a desarrollar migrando la antigua a una nueva basada en dos
frameworks.
La aplicacin web consiste en la automatizacin de planes de prueba para los
distintos dispositivos que se desarrollan en la empresa. Cuando se accede a ella
aparece una primera pgina de autenticacin para que solo trabajadores de la
empresa puedan acceder a la aplicacin mediante la introduccin de su nombre
de usuario y su contrasea, una vez accedido se presenta la estructura con un
men que, aparte de ofrece unas pginas de informacin sobre la web, da la
posibilidad de navegar por los distintos mdulos. No todos los mdulos estn
implementados, alguno de ellos esta en construccin y todava no presenta
ningn tipo de funcionalidad.
Pero los que si estn 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, slo el administrador podr ver
los test de todos los usuarios.
-Dispositivos: aadir, modificar o borrar un dispositivo.
-Modificar el conjunto de pruebas o asignar los test a mltiples
plataformas.
-Mapa de dispositivos: se muestran todos los dispositivos con toda su
informacin y se especifica si estn disponibles o no.
-Servidor de compilacin: se muestran un seguimiento de todas las
pruebas diarias que se han ido realizando.
La nueva aplicacin a realizar no ser una copia exacta de la antigua. Por
ejemplo, la forma de autenticacin variar, ya no har falta autenticarse para
poder entrar en la aplicacin sino que esto solo ser necesario para la visin y el
manejo de alguno de los mdulos, esto significa que la aplicacin tendr una
parte pblica y otra parte privada a la que se acceder mediante una
32
autenticacin. Tambin se pretende dar un lavado de cara a los mdulos

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 migracin de la aplicacin este proyecto tambin
comprende la fase de aprendizaje, de inicio. Ser necesario el diseo y la
creacin de unos pequeos mdulos (explicados con mas detalle en el punto
3.3.Definicin mdulos de aprendizaje), con una funcionalidad muy simple que
sirvan de introduccin al uso de los dos frameworks en los que se va a basar la
aplicacin web final. Estos mdulos no sirven solo para el inicio de este proyecto
sino que tambin servirn como referencia para otros proyectos. Los nuevos
desarrolladores que se encarguen de la ampliacin de la aplicacin, se podrn
beneficiar de estos mdulos. Por ello este punto tambin es parte importante
del proyecto aunque no se vea incluido en la aplicacin web final.
Parte del peso de este proyecto tambin va a recaer en el manejo, aprendizaje,
instalacin y acoplamiento de los frameworks, tanto el asignado al lado del
servidor como el empleado para en el lado del cliente.
Por ello a continuacin se da una explicacin ms detallada de ellos.
3.1.1. Zend Framework

Una de las caractersticas a destacar de este framework es que cada uno de sus
componentes esta construido con baja dependencia de los dems, esto hace que
los desarrolladores puedan utilizar los componentes de forma individual. Aunque
esto es posible, los componentes de la biblioteca estndar de Zend Framework
constituyen, al combinarse, un potente y extensible framework de aplicaciones
web.
Zend Framework consta de una robusta implementacin MVC (Modelo-VistaControlador), eso evita crear grandes estructuras en un proyecto. En nuestro
proyecto queremos sencillez y eficiencia por eso utilizaremos el patrn MVC que
ofrece ZF. El framework tambin consta de una abstraccin de base de datos
fcil de usar.
Los componentes de ZF reducen drsticamente el tiempo de desarrollo, con una
base completamente slida. Algunos componentes a destacar son:
33
-Zend_Auth y Zend_Acl: proveen autentificacin y autorizacin de

usuarios.
-Zend_db: componente que proporciona una interfaz simple de base de
datos SQL.
-Zend_Json: manejo y conversin de datos JSON.
-Zend_Form: simplifica la creacin y manipulacin de formularios.
Los requerimientos de Zend Framework son:
- PHP 5.2.4 (o mayor)
- Un servidor web.
A partir de la versin 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 integracin 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 algn 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 libreras organizadas en paquetes
segn su funcionalidad. Los componentes de estos paquetes son de cdigo
JavaScript, HTML y CSS que pueden ser usados para enriquecer aplicaciones web.
Los widgets (componentes) que ofrece Dojo tienen funcionalidades aadidas a
las que comnmente ofrecen los widgets de HTML. Estas funcionalidades
aadidas dan lugar a interfaces grficas ms potentes, ms completas y ms
fciles de usar para el usuario, a parte de ofrecer una apariencia grfica mucho
mas amigable. Adems Dojo proporciona la opcin de crear nuestros propios
widgets. Algunos de los componentes que se pueden usar con Dojo son los
siguientes:
-Mens, pestaas y descripciones emergentes.
-Tablas.
-Efectos de animacin.
-Formularios y rutinas de validacin.
34
-Calendario.
-Soporte para arrastrar y soltar.
Dojo maneja la comunicacin asncrona con el servidor, sta es una caracterstica
importante para la aplicacin web a realizar ya que necesitaremos realizar varias
comunicaciones asncronas 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 abstraccin, 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. Anlisis de Requisitos

En este apartado se pretende hacer una descripcin abstracta de los servicios
que se espera que aporte la aplicacin web para que realice las funciones
esperadas por el usuario.
Esta descripcin se realizar analizando y explicando los requisitos de la
aplicacin. La clasificacin de los requisitos ser segn requisitos funcionales y
requisitos no funcionales.
3.2.1. Requisitos no funcionales

A continuacin se mencionan los requisitos los cuales, describen aspectos de la
aplicacin visibles por el usuario que no se relacionan en forma directa con el
comportamiento funcional del sistema:
Mantenibilidad
El cdigo 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 aplicacin.
El sistema debe ser construido e implantado de tal manera que un
cambio en los parmetros no obligue a la generacin de una nueva
versin del modulo.
Importancia: media
35
Seguridad
El acceso a ciertos mdulos de la aplicacin tiene que estar restringida a
los visitantes y solo podrn acceder usuarios registrados. Esto debe estar
controlado por la introduccin de un nombre de usuario y una
contrasea. Debe garantizarse que la informacin transmitida no pueda
ser capturada o interpretada.
Importancia: alta
Usabilidad
La aplicacin debe tener una interfaz sencilla para un uso intuitivo.
Debe definirse un estndar de interfaz tomando como referencia los
colores de la empresa, ya que con esto se tiene la probabilidad de que el
usurario este cmodamente trabajando con la aplicacin.
Los mensajes de error deben ser reportados por la propia aplicacin en la
medida de las posibilidades y no por el Sistema Operativo. Los mensajes
del sistema deben estar en el idioma apropiado, ingls.
Importancia: media
Portabilidad
La interfaz de la nueva aplicacin web se debe adaptar a varios
navegadores, ya citados anteriormente.
Por otro lado, la aplicacin tambin se tiene que adaptar a diferentes
plataformas. Se tendr que poder ejecutar en un ordenador de mesa, en
un porttil o incluso, en alguna ocasin, en algn dispositivo con pantalla
ms pequea. Tambin tendr que funcionar corriendo en distintos
sistemas operativos.
Importancia: alta
36
Escalabilidad
La aplicacin tiene que poder adaptarse a un incremento en el tamao de
los datos que maneja.
Importancia: alta
Reutilizacin
Algunas funcionalidades de ciertos mdulos son compartidas por otros
mdulos, en este sentido se especifica este requisito. Habr que crear
cdigo 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
aplicacin y su entorno.
Como mejor se estudian y representan estos requisitos son en el Modelo de
Casos de Uso, por ello a continuacin se muestra un Modelo de Casos de Uso de
la aplicacin.
3.2.2.1. Actores
Visitante: cualquier usuario que acceda a la aplicacin y navegue por ella
sin identificarse. Puede ver las secciones pblicas de la pgina.
Usuario logueado: visitante que se ha identificado en la aplicacin.
Adems de poder ver todas las secciones pblicas, 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 pblica como la parte privada y
adems acceder al men de administrador.
37
3.2.2.2. Diagrama de Casos de Uso

En este diagrama se representa la interaccin de los posibles usuarios con
la aplicacin web, se muestra las distintas funcionalidades que ofrece el
sistema.
3.1. Diagrama de Casos de Uso
38
3.2.2.3. Especificacin 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
Definicin: El usuario puede seleccionar la pgina de noticias y ah ver las
ltimas noticias sobre la aplicacin, nuevos mdulos 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 pgina con las noticias.
Post-condiciones: pgina con las ltimas noticias sobre la aplicacin.
Caso de Uso: Ver documentacin

Definicin: El usuario puede seleccionar la pgina de documentacin y
leer la documentacin de la aplicacin o acceder a cualquier documento
disponible, como puede ser un manual de usuario, o un documento
explicativo de la funcin de la aplicacin web.
Precondiciones: ninguna
Proceso: el usuario selecciona en el men el tem correspondiente a
documentacin y visualiza la documentacin disponible.
Post-condiciones: pgina con documentacin sobre la aplicacin.
39
Caso de uso: Ver anuncios

Definicin: se muestran anuncios interesantes para el usuario, como por
ejemplo el lanzamiento de una nueva versin, la llegada de algn pedido
importante,. Solo se pueden ver tres. Los anuncios constarn de una
descripcin 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 mximo
de tres anuncios, si en la base de datos hay tres o menos anuncios se
muestran todos, pero si hay ms de tres anuncios se escogen para
mostrar los ms prximos a la fecha actual.
Post-condiciones: solo se muestras tres o menos de tres anuncios.
Caso de Uso: Identificarse

Definicin: proceso mediante el cual un usuario introduce su nombre de
usuario y su contrasea 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
contrasea.
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
contrasea es correcta). En caso afirmativo inicia sesin con los datos del
usuario y se aaden nuevos mdulos a los que acceder, si el usuario tiene
el rol de administrador tambin 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.
40
3.2. Diagrama de Actividad (Identificarse)
Caso de Uso: Mapa de dispositivos (Map of Devices)

Definicin: en este mdulo el usuario puede ver todos los dispositivos sobre
los cuales realizar los test. Tambin se muestran los clientes a los que estn
asociados los dispositivos, cada cliente puede tener uno, varios o ningn
dispositivo asociado. Se puede ver toda la informacin de cada dispositivo y
de cada cliente (esta informacin se recoge de la base de datos). La
informacin de los clientes es: nombre del cliente, identificador, direccin ip
publica y privada, descripcin, sistema operativo, dispositivos disponibles
(numero de dispositivos que tiene disponibles), localizacin (lugar fsico de la
41
empresa donde est instalado ese cliente) y disponibilidad (si esta disponible
o no). La informacin que se puede ver de cada dispositivo es: nombre del
dispositivo, nombre de su plataforma, identificador, modulo, descripcin,
sistema operativo soportado, informacin 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 mdulo Map of devices a travs del men.
Visualiza todos los dispositivos con su informacin y la informacin de los
clientes de los cuales penden los dispositivos.
El usuario puede elegir ver slo los clientes disponibles (opcin 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: mdulo con informacin sobre los dispositivos.
Caso de Uso: Servidor Linux (Linux Server)

Definicin: el usuario puede visualizar todas las compilaciones que se han
realizado en el servidor Linux, servidor de compilacin, de las diferentes
versiones de distintos mdulos. Podr ver las compilaciones programadas y
hechas en la fecha actual como tambin todas las realizadas en das
anteriores. La informacin de la que dispone el usuario es:
Nombre de los mdulos.

Etiqueta de cada versin.
Fecha y hora de inicio de la compilacin.
Si ha ido bien o por el contrario se ha producido algn error.
Si la versin es una versin definitiva o no.
Resultado de la compilacin

Precondiciones: Ninguna.
42
Post-condiciones: mdulo con informacin sobre la compilacin de versiones

de mdulos, en un servidor de compilacin Linux.
3.3 Definicin mdulos de aprendizaje

A continuacin, se explican detalladamente los tres mdulos que se realizarn
antes de empezar a desarrollar la aplicacin web final.
Estos mdulos consistirn en crear mini-proyectos con conceptos bsicos y
esenciales para luego poder empezar con la aplicacin web. Los mdulos
constaran de toda la estructura necesaria para la creacin de proyectos con Zend
Framework y utilizaran todo lo necesario del framework Dojo Toolkit para su
interfaz grfica.
En un principio, los mdulos se crearn por separado, cada uno en un proyecto
distinto. Pero posiblemente cuando los tres estn finalizados se juntaran en un
solo proyecto.
Formulario
Con este mdulo se pretende familiarizarse y dejar reflejado el uso de
formularios.
El formulario constar de dos campos: nombre y fecha. Estos campos
tendrn validadores y ambos sern campos requeridos. El campo nombre
solo admitir caracteres alfanumricos.
Despus 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
alfanumricos, entonces se mostrar un mensaje indicando que
todo ha ido bien y mostrando el nombre y la fecha introducida.
Si algo va mal: si algn campo ha quedado vaco o en el campo
nombre se ha introducido algn smbolo (algn carcter no
alfanumrico) se proceder a mostrar un mensaje de error.
43
Pgina de login
En este mdulo se va a realizar un logeo bsico para ver el
funcionamiento de las herramientas de autenticacin que proporciona
Zend Framework.
Para la interfaz de usuario se usar un formulario, aprendido ya su
funcionamiento en el mdulo anteriormente realizado. En este formulario
habr dos campos usuario y contrasea. El campo usuario solo admitir
caracteres alfabticos y el campo contrasea exigir la introduccin de 6
caracteres como mnimo. Ambos campos son requeridos.
Al enviar los datos:
Si los datos han sido introducidos segn los requisitos
mencionados, se comprueban los datos (usuario y contrasea) 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 pgina,
esta pgina contendr un mensaje indicando que el usuario
correspondiente se ha logueado con xito y tendr la
opcin 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 contrasea
introducidos no son vlidos.
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
asncronas al servidor mediante la tcnica AJAX. Esta llamada asncrona,
desde el cliente no se va a realizar de la manera tradicional que podamos
conocer sino que se har a travs de los mecanismos que ofrece Dojo, y
los datos enviados al servidor sern tratados como convenga Zend
Framework.
En la pgina aparecern dos combobox, Pases y Ciudades.
El primero, pases, contendr un listado con varios pases, por defecto no
estar seleccionado ninguno, para ver los pases disponibles habr que
desplegar el combobox.
44
El segundo estar deshabilitado y no se podr ver su contenido.

En el momento que se seleccione en el primer combobox algn pas el
segundo pasara a estar habilitado y mostrar una serie de ciudades
correspondientes al pas seleccionado. En el instante en el que se cambie
el pas seleccionado cambiar por completo el contenido del combobox
ciudades que pasara a tener el nombre de las ciudades del nuevo pas
seleccionado.
45
46
4 DISEO
Captulo que trata de exponer las decisiones tomadas sobre el diseo de la
aplicacin, explicar toda la arquitectura del proyecto, detenindose sobre todo
en los frameworks. Tambin se mostrarn prototipos de las secciones ms
relevantes.
47
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 pequea orientacin de como empezar a trabajar con ellos.
4.1.1. Arquitectura de Zend Framework

En este proyecto se va a usar el patrn de arquitectura software MVC (ModeloVista-Controlador) que nos ofrece Zend Framework. Siguiendo este patrn
conseguimos una divisin de la aplicacin web en tres partes, una de ellas se
encarga de la interfaz de usuario, otra del tratamiento de los datos y la lgica 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 mdulo o pieza de la
aplicacin 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 algn caso pueda llegar a controlar varias
tablas que tengan mucho en comn.
Vista (View): es la parte que maneja lo que ver el usuario de la aplicacin
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 asignacin de variables.
48
Con el siguiente esquema se muestra el comportamiento de MVC en Zend

Framework.
4.1. Patrn MVC en Zend Framework
Para poder trabajar con Zend Framework lo primero es descargar la ltima

versin 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
49
Esta estructura tiene tres carpetas principales a destacar: application, library y

public.
La carpeta application es donde reside todo el cdigo de la aplicacin y es
la encargada de manejar el patrn MVC, explicado anteriormente, a
travs de sus tres carpetas principales models, controllers y views:
controllers: en esta carpeta irn alojados los distintos
controladores que se creen para la aplicacin. Un controlador es
una clase que extiende de Zend_Controller_Action y esta clase
contiene mtodos llamados acciones (actions), estos mtodos
especiales tienen el nombre con el sufijo Action. Los
controladores son archivos con extensin .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 ningn controlador entonces este es el
que se ejecuta. El controlador Error se ejecutar cada vez que
queramos acceder a una pgina que no existe o se produzca algn
error en la aplicacin. Las Urls en ZF tienen la forma
/{controlador}/{accin}, esta url ejecutar la accin del
controlador indicada.
Ejemplo de un controlador:
4.3. Controlador ZF
models: aqu irn todas las clases que creemos como modelos de
nuestra aplicacin.
views: carpeta encargada de guardar las vistas, las pginas 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
mtodos que se van a emplear en varios lugares, en varias vistas
50
distintas, es una manera de no repetir cdigo. Los view helpers se

ejecutan dentro de las vistas.
-scripts: donde encontramos las vistas propiamente dichas,
todas las pginas 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 extensin
.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 tambin se le puede aadir una llamada
layouts, aqu se puede generar una plantilla para la vista de la
aplicacin web. Creando un layout se consigue poder incluir una
vista dentro de otra.
Aparte de estas tres carpetas tambin contiene el archivo bootstrap.php
donde se definen los recursos y los componentes a inicializar en la
aplicacin, y la carpeta configs con el archivo de configuracin
application.ini, en este archivo se guarda la configuracin inicial de la
aplicacin, por ejemplo la configuracin de la base de datos a usar.
La carpeta library ser la que albergue la librera de Zend. Tambin este
es el lugar para incluir las libreras que creemos.
Por ltimo la carpeta public es el root del sitio, es decir, la carpeta que
debe contener solo los documentos que sern accesibles a travs del
navegador, todas las imgenes, 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).
Tambin 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 libreras de Zend (/library) y ejecutar la
aplicacin, el segundo archivo es el destinado a la configuracin del
mdulo mod-rewrite, mdulo para hacer las URLs mas amigables.
51
4.1.2. Arquitectura de Dojo Toolkit

Dojo consta de una arquitectura con varios componentes principales que se
describen a continuacin:
Dojo Base: es la base de Dojo Toolkit, es el fundamento de utilidades
como AJAX, DOM (interfaz de programacin de aplicaciones para
acceder, aadir y cambiar dinmicamente 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 ncleo de Dojo. Es un
conjunto ms 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 animacin, almacn 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 grficos. Esta biblioteca
requiere Dojo Base y varios mdulos de Dojo Core. Estos widgets son
altamente portables, fciles de utilizar y simples en diseo, alguno de
estos widgets son: mens, tablas, contenedores,
Dojox: paquete de extensiones para Dojo. Es una coleccin independiente
de subproyectos. Contiene grficos, herramientas de dibujo,
componentes mviles,.... en definitiva, componentes un poco mas
avanzados.
Util: es una coleccin 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 tamao del cdigo e
incluir capas con distintos archivos JavaScript.
52
4.4. Componentes de Dojo Toolkit
En esta imagen se resumen todos los componentes principales de Dojo, ya

explicados. Y se aade algo ms, tus propios componentes, ya que Dojo ofrece al
desarrollador la opcin 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
fsicas 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 asncronas con Zend Framework y Dojo

Se van a realizar llamadas asncronas en la aplicacin web a travs de la
utilizacin de AJAX. Por lo que en este apartado se hace una pequea
introduccin y una descripcin de su uso con los frameworks.
Utilizando AJAX se consigue que cuando el usuario pide mas informacin de una
pgina, sta no se refresque entera para mostrarla sino que aada la informacin
requerida directamente. O tambin, que en un principio, una pgina muestre lo
mnimo e imprescindible y poco a poco se vaya aadiendo lo que el usuario pida.
Para todo esto se utiliza una combinacin de HTTP, JavaScript y en algunos casos
XML; AJAX envuelve todo esto.
53
Con el uso de AJAX vamos a conseguir que la parte del cliente se comunique
asncronamente con el servidor. En la parte del cliente se recogern 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 ms 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 tambin resulta mucho ms sencillo
escribir un analizador semntico de JSON. En JavaScript, un texto JSON se puede
analizar fcilmente usando el procedimiento eval().
Un ejemplo simple de formato JSON sera el siguiente:
{nombre: Miguel, apellido: Pea}
Dojo ofrece unas funciones que permiten las interacciones de Ajax, estos
mtodos se encuentran en el componente Dojo Base y son dojo.xhrGet y
dojo.xhrPost. La primera funcin es para llevarla a cabo en una comunicacin
HTTP segn el mtodo Get, orientada a recoger informacin del servidor. La
otra funcin implementa una solicitud asncrona para HTTP POST, mas enfocada
en el envo de datos al servidor.
Ambas funciones incluyen varios campos, varias propiedades descritas a
continuacin:
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 parmetro 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 funcin que ser llamada
en una respuesta satisfactoria. Es opcional.
54
error: se establece una funcin 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 funcin dojo.xhrPost aparte de la propiedad content aade dos
propiedades ms: form y postData.
La propiedad form ofrece la posibilidad de enviar al servidor los datos
de un formulario, se pueden proporcionar a travs del nodo DOM del
formulario o a travs 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 envo de un String, una cadena de
caracteres, al servidor sin la necesidad de ms procesos.
Estas tres propiedades, content, form y postData son excluyentes, es
decir, en una misma funcin dojo.xhrPost slo se puede usar una de
ellas.
Zend Framework tambin tiene implicacin en estas llamadas asncronas, como
parte del servidor, aunque no tiene tanta participacin 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 envos 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 librera llamada Zend_Json. Esta librera
ofrece mtodos para la serializacin desde PHP a JSON y la decodificacin 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)
55
Para enviar algn dato PHP al cliente en formato JSON tambin se puede usar el
ayudante de accin, 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 requera la aplicacin web, y tener
en cuenta la distribucin de parte pblica y parte privada, se llego a un acuerdo,
con ayuda de mi tutor de empresa y con el desarrollador de la antigua aplicacin
web, de como estructurar la interfaz de usuario. A continuacin 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 estn destinados a la gestin del diseo y estn agrupados en
dijit.layout. Los principales layouts de los que podemos disponer son los
siguientes:
56
BorderContainer: con este widget se crea un contenedor en el que se

pueden definir como mximo 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 ttulo 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 quedarn
reflejados a travs de una pestaa con un titulo. Pulsando esas pestaas
se puede ir cambiando de contenedor, de panel. Mediante una propiedad
del widget se puede definir un botn de cierre en cada pestaa para
cerrar el panel con solo clicarlo.
4.7. Prototipo TabContainer
57
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 atrs.
ContentPane: es la pieza ms bsica, 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 ms para la parte central (contenido
principal de la aplicacin), uno final para lateral derecha y por ltimo en la parte
lateral izquierda se crear un accordionContainer para definir el men de la
aplicacin.
En la parte de la cabecera ir a la izquierda el logo de la empresa, en el centro el
ttulo de la aplicacin web y a la izquierda se presentar el formulario para la
autenticacin.
La estructura de la aplicacin no variar en ningn momento, lo nico que ir
cambiando ser el contenedor principal que ser el encargado de mostrar los
distintos mdulos por los que vaya navegando el usuario. El men tambin se
ver modificado dependiendo del usuario que este accediendo a la aplicacin.
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
contrasea (password) y un botn para enviar la informacin.
Muchas veces podemos mezclar trminos, pero hay que diferenciar
autenticacin de autorizacin. En este proceso de logeo se van usar los dos
trminos. Se recogern los datos introducidos por el usuario y mediante el
proceso de autenticacin se validarn en la base de datos para comprobar si son
correctos. Luego se producir la autorizacin, una vez que el usuario y la
contrasea sean correctos, se autorizar al usuario poder acceder a unos datos u
otros dependiendo del rol que tenga.
La autenticacin se va a realizar con la ayuda de la librera que ofrece Zend
Framework, llamada Zend_Auth.
58
4.4. Mdulos
El usuario puede acceder a los distintos mdulos de la aplicacin a travs del
men lateral, una vez seleccionado un mdulo ste aparecer en al parte central
de la pgina.
A continuacin se detallan los detalles de diseo de cada mdulo:
Mapa de dispositivos (Map of Decives)
En este mdulo 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 ttulo en la parte superior. La visibilidad del contenido del panel se
activa pinchando sobre su ttulo. 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 informacin
ms relevante: el nombre del cliente, la ip, su identificador, los
dispositivos disponibles que tiene asociados y una pequea descripcin, a
parte tambin 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
tambin se muestran a travs 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 mdulo del
dispositivo, su estado y una descripcin.
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 aparecern expandidos.
Toda la informacin referente a cada cliente y cada dispositivo no
aparece en el mismo, por ello, se crear un objeto para mostrar toda la
59
informacin, tanto la ya especificada en cada titlePane como la

informacin no reflejada. El componente elegido para mostrar esa
informacin adicional es el toolTip (dijit.toolTip).
El widget toolTip es una etiqueta que se asocia a un objeto. Cuando se
pase el ratn por encima del objeto aparecer esta etiqueta con el
contenido que hayamos especificado. Mediante propiedades se puede
definir la posicin del toolTip respecto a su objeto asociado y el tiempo
que permanecer visible.
Cuando el usuario pase el ratn por encima de algn cliente o algn
dispositivo el toolTip aparecer a su derecha. El toolTip de cada cliente
mostrar: el nombre, la ip, su identificador, descripcin, sistema
operativo, si esta disponible o no, su localizacin y una imagen. En el
toolTip de cada dispositivo se revelar la siguiente informacin: nombre,
id, tipo, puerto de la consola, sistema operativo soportado, informacin
adicional sobre el mdulo del dispositivo, informacin adicional sobre la
plataforma, estado del dispositivo y una imagen.
Prototipo del mdulo:
4.8. Prototipo mdulo Mapa de Dispositivos
60
Por defecto aparecern solo los clientes disponibles, conteniendo solo los
dispositivos disponibles. El usuario a travs de un checkbox podr desmarcar la
opcin 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 aparecern solo los clientes que estn disponibles en ese
momento.
Los clientes disponibles se representarn mediante un crculo verde en su
imagen y un crculo rojo en caso de no estar disponible. Con los dispositivos lo
mismo, verde si estn disponibles, rojo si no lo estn y amarillo si estn ocupados
realizando un test.
Servidor Linux (Linux Server)

El mdulo Linux Server va a estar dividido en dos partes: Build Server List y
Release Tags. Esta divisin 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 mdulo, ser la de Build Server List.
Build Server List mostrar toda la lista del servidor de compilacin. Esa
informacin se dispondr de la siguiente manera:
Existir un calendario creado a travs del widget de Dojo dijit.Calendar, la fecha
que aparecer por defecto sealada ser el da actual. Debajo del calendario se
situar una tabla, creada mediante el componente dataGrid. Las columnas de la
tabla son:
Indicador de si la compilacin ha ido bien o no. Mediante un tick si ha ido

bien o una cruz si ha habido algn error.
Module. Nombre del mdulo.
Fecha. Fecha y hora del comienzo de la compilacin.
Tag. Etiqueta de la versin.

Release Tag. Si esta columna tiene el nombre del tag significar que es
una versin definitiva, si aparece vaca significar que no es una versin
definitiva.
Tambin este panel constar de un contenedor para mostrar en l los resultados

de cada compilacin. Cuando el usuario pinche sobre una fila de la tabla, en el
contenedor se mostrar el fichero de resultados de esa compilacin. Esos
61
ficheros de resultados se muestran a travs 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 dependern del da seleccionado en el

calendario. Los datos aparecen por das. Por ejemplo, si en el calendario se
selecciona la fecha: 16/03/2010, en la tabla aparecern todas las compilaciones
realizadas ese da.
Los das del calendario estarn pintados en funcin de las compilaciones de cada
da. Hay tres casos distintos, tres colores distintos para pintar un da del
calendario:
Alguna compilacin ha fallado, ha habido algn error.
Alguna de las versiones se establece como versin final (release tag).
Todas las compilaciones han ido bien y no ha salido ninguna versin final.
Ante un error y una versin final prevalece el error, a la hora de representarlo en
el calendario.
62
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 informacin 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 informacin de
golpe sino que aparecer por pginas de la tabla. El usuario podr ir navegando
por esas pginas para as ver toda la informacin y tambin podr seleccionar el
nmero de filas que desea ver en una misma pgina de la tabla. Tambin
dispondr de un contenedor para mostrar los resultados de cada compilacin, 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 ms 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
clculo, que ofrece posibilidades al usuario como la de cambiar el tamao de las
columnas, u ordenar los datos por columnas.
63
EnhancedGrid (dojox.grid.EnhancedGrid) este componente es una versin ms

compleja y completa que ofrece un conjunto de caractersticas ms amplias.
Estas caractersticas se implementan como plugins separados, que debern
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 pginas. 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 aplicacin 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
informacin del mdulo 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 fcil modificar el cdigo para
acceder a la tabla builds a travs de la BD buildserver, en vez de a travs de
web_automation, ya que mientras este en local solo se trabajara con una BD
pero cuando se suba la aplicacin al servidor correspondiente ya se trabajara con
las dos Bases de Datos.
64
4.11. Tabla builds
Las tablas ms importantes, o las que ms se van a utilizar de la Base de Datos

web_automation son: client, dut, platform y user. Esta ltima se usar para la
autenticacin y las dems para el mdulo Mapa de Dispositivos.
4.12. Tabla Client (Cliente)
65
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 parmetros, todo esto en el archivo de
configuracin config.ini situado en el directorio /application/configuration/.
4.14. Configuracin Base de Datos
-db.adapter: adaptador de la BD, por defecto es PDO_MYSQL.

-db.params.host: direccin ip del servidor donde se encuentra la BD.
-db.params.username: nombre de usuario de acceso a la Base de Datos.
-db.params.password: contrasea de acceso a la BD.
-db.params.dbname: nombre de la BD.
66
Zend Framework ofrece el componente Zend_db, el cual provee de una API para
la creacin de sentencias SQL. Se pueden crear sentencias SQL de dos formas
principalmente. La primera es a travs de la creacin de un objeto select
mediante el mtodo 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 sera el siguiente:
4.15. Zend_db_select
La otra forma es a travs del mtodo fetchAll(). Se escribe una consulta SQL que
se pasa como parmetro del mtodo y ste devuelve un array con las filas
devueltas por la consulta. Si se quiere obtener toda la informacin de una tabla
(todas las filas) basta con ejecutar fetchAll(), sin ningn parmetro. Este mtodo
tambin ofrece la posibilidad de pasarle como parmetros las siguientes
variables: $where, $order, $count, $offset.
Ejemplo del mtodo fetchAll(), pasando como parmetro un String con la sentencia SQL:
4.16. Mtodo fetchAll()
67
Ejemplo del mtodo fetchAll(), pasando como parmetros algunas de las

variables aceptadas:
4.17. Mtodo fetchAll() [2]
68
5 IMPLEMENTACIN
En este captulo se explican las principales caractersticas de la creacin,
propiamente dicha, del proyecto. Las decisiones importantes tomadas en cuanto
a cuestiones de implementacin. Tambin se hace referencia a los problemas
surgidos y cul o cules han sido las soluciones.
69
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
aplicacin web. Se mostrar como se organiza toda la informacin 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.
Ms adelante se consider la posibilidad de utilizar Zend Studio y se decidi
cambiar a este entorno de desarrollo para implementar todo el cdigo de la
aplicacin 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
opcin Zend Framework default Project structure (marcada por defecto). La
estructura de directorios queda de la siguiente manera:
5.1. Estructura de directorios
70
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 tambin se crean unas
libreras. En concreto, se puede acceder a la librera de Zend (PHP Include
Path/Zend Framework Library/ Zend) para visualizar el cdigo de todos los
componentes, de todas las clases que forman cada componente de Zend.
5.1.2. Integracin 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 cdigo 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). Tambin 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.
71
Problemas
La informacin encontrada en pginas 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 integracin. No se consegua obtener el cdigo necesario para
el entendimiento ni donde colocarlo.
5.1.3. Componentes del patrn MVC

Zend Framework sigue el patrn de arquitectura MVC, como ya se ha explicado
anteriormente. En este apartado se va a explicar con algo ms de detalle cada
uno de los tres componentes del patrn, como implementar cada uno, y la
comunicacin entre ellos, es decir, como se puede pasar informacin de unos a
otros.
Modelo
El modelo de la aplicacin va a residir en la carpeta /application/models, en esta
carpeta se guardan todos los modelos (clases) necesarios. La implementacin 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
tambin se crea un archivo por cada controlador establecido en la aplicacin,
pero no todos estos modelos sern 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
informacin y a continuacin las funciones.
72
Un ejemplo de modelo sera 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 informacin. 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 funcin getNombre() con la
variable $nom pasada como parmetro, a travs de una consulta a la tabla
tabla1 se obtienen todas las filas cuyo campo nombre es igual al pasado como
parmetro ($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 aplicacin 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 detallarn los posibles errores de la aplicacin. La aplicacin constar
de un controlador por cada parte o por cada mdulo de la aplicacin, 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 mdulo uno para el mdulo Mapa de Dispositivos
(MapofDevicesController.php) y otro para el mdulo Servidor Linux
(BuildserverController.php). La parte de autenticacin se encuentra dentro de la
estructura general pero se considera lo suficientemente compleja como para
crear un controlador de ella (AuthController.php).
73
En cada controlador se pueden definir dos clases de mtodos, aunque todos los
mtodos 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 dems si que la tendrn, una vista por
cada accin del controlador.
Vista
Las vistas se encuentran en el directorio /application/views/scripts, son archivos
.phtml, ya que ah se mezcla cdigo php, html y javascript o referencias a
archivos javascript. Las vistas no se generan porque s, si no que existir una vista
por cada accin de cada controlador. Para cada controlador se crea una carpeta
en el directorio de las vistas y dentro de cada una de esas carpetas estarn los
archivos .phtml, uno por cada accin. El nombre de las vista es el mismo que el
nombre de la accin a la que hacen referencia.
Un ejemplo de vista sera el siguiente:
Comunicacin Modelo - Controlador

El controlador es el encargado de recoger la informacin 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 revs.
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 travs de la variable $model. Para poder usar las
funciones definidas en el Modelo basta con llamarlas mediante la variable
creada: $model->metodoModelo();.
Comunicacin Controlador - Vista

En ocasiones es necesario pasar informacin de la vista al controlador y en otras
ocasiones al revs, del controlador a la vista.
La vista es un objeto Zend_View al que accedemos desde el Controlador con
$this->view.
74
Un ejemplo de como pasar datos del controlador a la vista:
5.4. Paso Informacin Controlador - Vista
En el ejemplo se pasa un String mediante la variable title. En la vista holamundo

podremos acceder al String con el cdigo: $this->title;. Se puede pasar cualquier
conjunto de datos, como arrays.
La informacin que se mande desde la vista al controlador ser a travs de Ajax,
utilizando el mtodo que nos proporciona Dojo (4.2. Llamadas asncronas con
Zend Framework y Dojo).
5.2. Componentes de Dojo Toolkit

En la documentacin existente en la pgina 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 travs de cdigo HTML. Se
usan las etiquetas apropiadas para cada widget, cada uno tiene una
etiqueta asociada. El tipo de widget se detalla aadiendo una propiedad a
la etiqueta HTML (data-dojo-type).
<textarea id="textarea2" name="textarea2"
data-dojo-type="dijit.form.Textarea" style="width:200px;">
Hello World!
</textarea>
5.5. Creacin widget, declarativa
75
Forma programtica: de esta manera se crea el widget con cdigo

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 parmetros 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. Creacin widget, programtica
Tanto si lo hacemos de forma declarativa o de forma programtica, primero hay

que cargar el widget de la siguiente forma:
dojo.require("dijit.form.Textarea");
En implementacin de la aplicacin se va a emplear la creacin programtica de

widgets. A parte de que as no se carga tanto de cdigo la vista, tambin se ve
ms claro ya que de la otra manera se mezcla con el cdigo HTML.
Otra forma de crear los widgets, que no se explica en la pgina, y que no se va a
usar con tanta frecuencia como la programtica es programarlos con cdigo PHP.
Esto se realiza en la cabecera de las vistas. Se crearn 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
especficamente para los widgets de esta aplicacin web. Se ha decidido que el
estilo de los componentes se defina solo en las hojas de estilo, as que no se
detallar ningn estilo en el cdigo HTML, o como propiedad al crear algn
widget.
76
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 travs de ese
identificador es por el cual nos vamos a referir a los widgets implementados.
Dojo proporciona dos funciones para buscar un widget especifico pasndoles
como parmetro su id. Una de ellas es dijit.byId(), lo que devuelve esta funcin
es un objeto JavaScripts. La otra funcin es dojo.byId(), tiene las mismas
caractersticas 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 creacin de la estructura principal,
como empez a construirse y como quedo estructurada al final.
En un principio se empez a estructurar la aplicacin 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
implementacin de esta estructura de layouts, ya que en la pgina oficial no se
encontraba informacin completa se llego a tener un resultado ptimo,
utilizando el mtodo captureStart() y captureEnd().
77
Un trozo del cdigo de creacin de esos layout es el siguiente:
5.7. Creacin estructura con layouts
El contenedor creado para la autenticacin hace referencia a una accin del

controlador definido especficamente para albergar la funcionalidad de todo el
login/logout de usuarios. As como tambin se crean controladores por cada
mdulo de la aplicacin. En el contenedor central ir mostrando el mdulo que
el usuario escoja en el men lateral.
De forma paralela se fue implementando el primer mdulo, Mapa de
dispositivos. Pero a la hora de integrar en la estructura una primera versin
simple del mdulo, empez a dar problemas. As como el mdulo de
autenticacin se haba incorporado sin problemas, el mdulo 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 ningn
resultado positivo, se decidi, tras una reunin, implementar la estructura a
travs 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,
78
renderizando el archivo _header.phtml y _footer.phtml que tambin se

encuentran en el directorio /layouts.
La estructura del layout se crea a travs de etiquetas <div> de HTML, y en cada
etiqueta se van sacando las distintas partes: men principal, men derecho
(anuncios), contenedor principal y men rpido. Todas estas partes son distintas
vistas.
5.8. Layout.phtml
El quickmenu es un men horizontal que se decidi aadir con las partes ms

utilizadas de la aplicacin. 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 mdulo 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 estn 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 autenticacin va con otro
controlador aparte (AuthController.php).
79
Mientras se continuaba con la implementacin del modulo Mapa de dispositivos,

Arturo termin la estructura con two step views y la parte de autenticacin
basndose en la que ya se haba hecho y posteriormente descartado por los
problemas que surgieron y que ya se han descrito. La autenticacin ya incluye el
control de roles.
5.4. Men Principal

Con la estructura ya montada se inici la implementacin del men principal. En
un principio se haba desarrollado un men a travs del widget de Dojo
AccordionContainer, pero el resultado obtenido no fue el esperado, ya que la
navegacin 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 tambin se solicitan los datos
con los que se tiene que rellenar el men. Esta solicitud se har a travs 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 declaracin 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 aplicacin. Esto se controla en el Modelo. Cuando
el controlador pide los datos al Modelo, le pasa como parmetro el rol el usuario,
y el modelo devuelve un array u otro dependiendo del rol.
80
5.9. Funcin 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 saba donde especificarla. Se intent
especificar en la misma accin de la vista del men, pero esto provocaba
errores.
SOLUCIN: crear una funcin especfica para la llamada Ajax, esto dentro
del mismo controlador donde estaba la accin 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 haca falta era darle un aspecto de men. Pero
al intentar modificar nuestras propias hojas de estilo se producan
conflictos con las hojas de estilo de Dojo. Tambin se producan errores al
cambiar directamente las propias hojas de estilo de Dojo.
SOLUCIN: copiar el cdigo de las hojas de estilo de Dojo en nuestras
propias hojas de estilo y desde ah modificar los datos necesarios. Esta
solucin adoptada fue una solucin parcial. Ms adelante se explicar la
81
solucin 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 continuacin se muestra el proceso de cambio de estilo del men:
5.10. Cambiando estilo Men Principal
5.11. Men Principal
5.5. Mdulos
5.5.1. Mapa de Dispositivos

Para este mdulo es necesario crear un controlador, mapofdevicesController,
este controlador solo necesita una accin, lo dems 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 realizacin de todo el mdulo.
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 tambin se ha creado el checkbox necesario para
82
controlar que clientes se visualizan (solo los disponibles o todos). Todo lo dems
se realiza en un archivo .js que se incluye en la vista a travs del siguiente cdigo:
5.12. Incluir un archivo .js en una vista
Cambios importantes respecto al Diseo

En el apartado de diseo se determin el uso del widget dijit.toolTip para
mostrar la informacin 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 informacin adicional dentro de los
toolTip. Una vez implementados, se encontr un inconveniente, no se poda
acceder a la informacin de los toolTip, si un usuario quera seleccionar esa
informacin para copiarla (ctrl+c), no poda. Los toolTip solo se mostraban al
pasar el ratn por encima de los clientes o de los dispositivos pero al ponerlo
encima de los toolTip, estos desaparecan. Iba a ser frecuente el uso de esa
informacin por lo tanto se decidi remplazar los toolTip.
La mejor opcin posible que se vio, despus de estudiar el caso, fue el uso de
toolTipDialog. ToolTipDialog un widget parecido a toolTip, pero que se mantena
quieto al pasar el ratn por encima. Lo que se hizo fue crear un evento
onMouseOver asociado a los ttulos (parte principal de los componente
dijit.TitlePane) de cada cliente y de cada dispositivo. Ese evento lo que hace es
llamar a una funcin para que se active un pop-up a travs del componente que
ofrece Dojo, dijit.popup, y asociado a l un dijit.TooltipDialog.
Partes de cdigo
En la siguiente imagen se muestra el cdigo de una funcin del Modelo de la
tabla Dut, tabla de dispositivos. La funcin devuelve el nmero de dispositivos
disponibles de un cliente con una id determinada como parmetro.
83
5.13. Consulta a la tabla Dut de la BD
El mtodo fetchAll() devuelve las filas seleccionadas por la consulta $select y lo

que devuelve la funcin es el nmero de filas.
El controlador de este mdulo 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 informacin necesaria de
los Modelos, estructurarla y devolverla a la vista.
84
5.14. Accin 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 definan en el evento onClick del titlePane cliente. El
problema surga cuando el cliente estaba desplegado, mostrando sus
dispositivos y el usuario clicaba en uno de ellos, a parte de pinchar en un
dispositivo tambin estaba clicando en el objeto cliente, por lo tanto se
volvan a crear los dispositivos del cliente y saltaba un error. Se estaba
intentando crear un componente (un dispositivo) con una id que ya
exista.
SOLUCIN: La solucin era asociar el evento onClick slo a la parte del
ttulo del cliente, no asociarlo a todo el objeto. Tras muchas pruebas y
85
muchos intentos con opciones distintas, ya que la documentacin no

daba una solucin 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.
SOLUCIN: la versin Dojo 1.6. no es compatible con IE9 y algunos
componentes provocan fallos. Sin embargo la versin Dojo 1.6.1 si es
compatible. Todo se solucion actualizando la versin de Dojo.
El men no se cargaba en la pgina del Mapa de dispositivos. El men se
vea bien en cualquier otra pgina menos en la de Mapa de Dispositivos,
por eso se asoci el problema a este mdulo y no al men.
SOLUCIN: haba 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 funcin principal que
generaba todo el resto de cdigo de los archivos .js.
86
5.5.2. Servidor Linux

Este mdulo es un sub-apartado del mdulo Build Server, por lo que el
controlador que usa es el creado para el mdulo Build Server
(BuildserverController). Este controlador constar de su accin por defecto,
indexAction, y una accin por cada uno de los dos sub-apartados. El resto del
contenido del controlador sern funciones Ajax. Para el mdulo Servidor Linux
(Linux Server) estar asociada una vista, la correspondiente a la accin del
controlador. Existir un nico Modelo, la nica tabla de la BD necesaria para
implementar Servidor Linux.
La vista se organiza como en el mdulo Mapa de Dispositivos, es decir, no se
implementa casi nada en esa parte del cliente sino que se hace prcticamente
todo desde el archivo JavaScript (buildserver.js). En el archivo de la vista no se
implementa la estructura bsica de layout, comentada en el diseo, una
estructura usando el componente TabContainer de Dojo.
Problemas
Problemas con la visualizacin de las tablas. Despus 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 pareca una
tabla, el nombre de las columnas estaba desordenado, las celdas no
constaban de ningn tipo de separacin, En definitiva, la tabla se vea
mal.
SOLUCIN: para este componente, en concreto, hace falta aadir las
hojas de estilo del componente Grid en la vista del mdulo. No vale solo
con hacer referencia al tema en la etiqueta <body>, como para los dems
componentes. Los dos archivos aadidos fueron los siguientes:
../dojox/grid/resource/Grid.css
../dojox/grid/resource/tundraGrid.css
Problema con fechas. Se produca un error al comparar una fecha del

calendario con una fecha de la BD.
87
SOLUCIN: la fecha de la BD es un String, hay que pasarlo a objeto Date a

travs de dojo.date.locale.parse() uno de los mtodos 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 da del calendario
a travs del mtodo dojo.date.ocale.compare().
Imgenes de la primera columna de las tablas. Al intentar introducir las
imgenes en la primera columna de las tablas (columna para indicar si
todo ha ido bien o no, tick o cruz), apareca la url de la imagen en vez de
aparecer la propia imagen. Esto ocurra tanto en la tabla del apartado
Build Server List como en la tabla de ReleaseTags.
SOLUCIN: en la implementacin de la tabla, hay que poner la propiedad
escapeHTMLInData a false para que as pueda entender la etiqueta <img>
utilizada para incluir las imgenes.
5.5.3. Funciones genricas

No se ha comentado anteriormente pero existe un archivo JavaScript encargado
de contener funciones genricas, es decir, funciones que se van a utilizar en
varios mdulos o que se utilizan varias veces en un mismo mdulo. Tambin se
colocarn funciones que slo se hallan utilizado una vez, pero en un futuro o en
la implementacin de otro modulo se puedan llegar a usar.
Una de las funciones que va en este archivo es una funcin genrica para crear
llamadas Ajax:
88
5.15. Funcin genrica llamada Ajax
Dentro de esta funcin, aparte de detallar la llama Ajax con dojo.xhrPost (como
ya se explic en el punto 4.2. Llamadas asncronas con Zend Framework y Dojo)
tambin se crea un sistema opcional para aadir 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 mdulo Mapa
de dispositivos. Ah recurriremos a la funcin genrica para crear un titlePane.
89
5.6. Pruebas
La realizacin de pruebas sobre una aplicacin es algo importante. Proporcionan
una seguridad de que lo desarrollado hasta el momento va por buen camino. Es
una forma de comprobacin del cdigo implementado. Cuantas ms pruebas se
realicen menos probabilidad de fallos.
Durante la implementacin de la aplicacin se han ido haciendo abundantes
pruebas, estas pruebas se podran denominar micro-pruebas. No se han
realizado pruebas sobre conjuntos grandes de cdigo, sino que se han ido
realizando con cada funcionalidad implementada, o pequea parte desarrollada.
Las pruebas realizadas constantemente, a lo largo de todo el desarrollo de la
aplicacin, han sido las de comprobacin del funcionamiento en distintos
entornos, distintos navegadores. Tanto para comprobar la distribucin de los
componentes, su aspecto visual y su comportamiento.
90
6 GESTIN DEL
PROYECTO
En este apartado se va a tratar la gestin real del proyecto. En el apartado 1 DOP:
Documento de Objetivos del Proyecto se trat la futura gestin del proyecto, se
hicieron aproximaciones y estimaciones del tiempo y distribucin de actividades,
pero en este captulo se estudian los tiempos reales, la comparacin entre lo
estimado y lo real.
91
6.1. Duracin real del proyecto

La duracin real del proyecto se ha alargado ms de lo previsto, debido a
distintos factores que explicaremos ms adelante en el apartado 6.3. Motivos del
desfase. Los paquetes mas afectados en este desfase han sido el paquete de
Direccin del Proyecto y el de Implementacin, debido a las actividades de
aprendizaje, documentacin e implementacin.
6.1. Diagrama circular estimacin real de horas
Las horas empleadas han sido:

Direccin del Proyecto: 224 horas
Anlisis (Iniciacin): 24 horas
Diseo: 28 horas
Implementacin: 458 horas
Anlisis de Resultados e Integracin: 16 horas
Total: 750 horas
El proyecto en s se realizaba en la empresa y luego se complementaba ese
trabajo en casa. La duracin del proyecto se estim en 6 meses, pero como luego
esa duracin se ampli tuve que trabajar desde casa, ya que el contrato de
92
prcticas (por el cual poda trabajar en la empresa) terminaba a los 6 meses y la

universidad no permita renovarlo debido a que solo se pueden realizar 6 meses
de prcticas por curso acadmico. Por ello a partir del 5 de Marzo se sigui
desarrollando la aplicacin y las dems 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 continuacin:
6.2. Calendario de trabajo real
93
El proyecto se ha desarrollado principalmente por las maanas y los fines de

semana debido a la incorporacin a un trabajo externo a partir de Enero.
6.2. Comparacin 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 haban estimado con optimismo, por lo
que el tiempo real de desarrollo ha sido mayor.
Actividades
Horas estimadas
Horas reales
Direccin del proyecto

Aprendizaje e investigacin
Reuniones
Planificacin
Memoria
Defensa
142 horas
30 horas
12 horas
20 horas
70 horas
10 horas
224 horas
98 horas
12 horas
24 horas
80 horas
10 horas
Anlisis
Anlisis de Requisitos
Anlisis del sistema
Estudio mdulos de aprendizaje
Diseo
Diseo de la estructura
Diseo de los mdulos
Revisin del diseo
Implementacin
Implementacin mdulos de aprendizaje
Implementacin de la estructura
Implementacin de los mdulos
Revisin de la implementacin
Anlisis de Resultados e integracin
Ejecucin de pruebas
Integracin
Entrega y aprobacin de documentacin
20 horas
4 horas
10 horas
6 horas
30 horas
8 horas
12 horas
10 horas
268 horas
32 horas
48 horas
180 horas
8 horas
13 horas
8 horas
4 horas
1 horas
24 horas
4 horas
10 horas
10 horas
28 horas
10 horas
10 horas
8 horas
458 horas
94 horas
80 horas
274 horas
10 horas
16 horas
11 horas
4 horas
1 horas
6.3. Tabla comparacin de tiempos
94
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 Direccin del Proyecto y la de Implementacin, debido
a la poca experiencia en la realizacin de estimaciones en proyectos y debido a
los problemas surgidos.
A continuacin se muestra un diagrama de barras para expresar grficamente 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 Tecnologas
El desconocimiento de los frameworks en general y en concreto de los
dos utilizados, Zend Framework y Dojo Toolkit, aadido a la poca
experiencia en el desarrollo de aplicaciones web ha hecho que fueran
95
surgiendo dificultades y esto provocara retrasos. La curva de aprendizaje

de los dos frameworks ha sido mas pronunciada de lo que se haba
previsto y de algn 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 comunicacin y el
entendimiento entre ellos. Estos problemas, en gran parte, estaban
debidos al punto anterior, el desconocimiento de la tecnologa.
Estimaciones optimistas
Debido a la poca experiencia del proyectante en proyectos de esta
envergadura las estimaciones han sido poco realistas, en la mayora de
los casos han sido demasiado optimistas.
Proyecto real, dependencia de la empresa
Este proyecto no est ideado exclusivamente para un PFC sino que
tambin era requerido por una empresa. Es un proyecto real y esto
conlleva depender de la empresa para su realizacin. 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
dedicacin al proyecto de prcticamente todas las tarde entre semana.
96
7 CONCLUSIONES
Este es uno de los ltimos captulos de la memoria, debido a que en este
apartado se plasman las ideas finales, tanto de la aplicacin desarrollada en s
como tambin las conclusiones personales.
97
Tras la realizacin de este proyecto se han podido comprender, ms en

profundidad, muchos conceptos relacionados con aplicaciones web, que durante
la carrera no se haban podido ver o experimentar. Sobre todo se ha afianzado y
comprendido mucho mejor el concepto de framework, y su aplicacin en
proyectos ya existentes.
La curva de aprendizaje ha sido bastante elevada. Se han dejado varios frentes
abiertos, ya que muchos de los mdulos no se han llegado a implementar, pero
se ha creado una estructura slida. Para que a partir de esto se pueda seguir
desarrollando el resto de mdulos e incluso crear algunos nuevos, no existentes.
Durante el desarrollo del proyecto se ha ido viendo la importancia de la
planificacin y del estudio previo de todas las caractersticas del proyecto, para
as obtener un mejor resultado. Tambin se ha comprendido la importancia de
implementar un cdigo ordenado, con comentarios y sobre todo que es mejor
dividirlo en varias funciones ms 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 realizacin de un proyecto real y el enriquecimiento en cuanto a
experiencia laboral, algo muy bueno de cara a un futuro ms o menos inmediato.
98
8 BIBLIOGRAFA
En este apartado se van a detallar las distintas fuentes de informacin utilizadas
a lo largo de todo el proyecto.
99
Una de las fuentes utilizadas han sido los libros, tanto en formato digital como en
formato fsico:
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
Programacin en JavaScript Jose Manuel Alarcn
Adding Ajax Shelley Powers
PHP 6 Francisco Charte Ojeda
Mucha otra informacin se ha obtenido de diferentes paginas web que se
detallan a continuacin:
Pginas oficiales:
http://www.dojotoolkit.org: web oficial de Dojo Toolkit para
descargar el framework y obtener toda la informacin sobre
l.
http://www.framework.zend.com: web oficial de Zend
Framework, desde donde se descarg el framework, y sitio
para obtener informacin.
Otras pginas web:
http://
http://angelorum.blogspot.com.es/2010/09/zendframework-1-instalacion.html: blog donde se pueden
encontrar varios artculos sobre ZF, como instalarlo,
explicacin de sus componentes, trabajar con Ajax,
http://zfdes.com/index.php/Portada: documentacin sobre
Zend Framework en espaol.
http://www.roseindia.net/dojo: tutorial sobre Dojo.
100
101

Migración de Infraestructura Web A Una Nueva Estructura Basada en Frameworks

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Migración de Infraestructura Web A Una Nueva Estructura Basada en Frameworks

Uploaded by

Copyright:

Available Formats

TRABAJO FIN DE ESTUDIOS

PROYECTO FIN DE CARRERA

Migracin de infraestructura web a una nueva

Ana Ruiz Parmo

Tutor: Angel Luis Rubio Garca

Migracin de infraestructura web a una nueva estructura basada en

FACULTAD DE CIENCIAS, ESTUDIOS AGROALIMENTARIOS

PROYECTO FIN DE CARRERA

Migracin de infraestructura web a una nueva

Alumno: Ana Ruiz Parmo

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

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

6. Gestin del proyecto .................................................................................................... 91

4.17. Mtodo fetchAll() [2]............................................................................................ 68

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

2.5. Recursos humanos

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

2.6. Tecnologa y arquitectura

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

XAMPP: es el servidor independiente de plataforma que he seleccionado

2.1. Arquitectura de la aplicacin

2.7.1. Estructura de Descomposicin del Proyecto (EDP)

2.2. Estructura de descomposicin del proyecto

2.7.2. Diccionario de la EDP

Aprendizaje e investigacin: En esta actividad se engloban todas las tareas de

Reuniones: Todas las reuniones que se realizarn tanto con el tutor de la

Planificacin: Se trata del desarrollo inicial del proyecto, desarrollar la ligera

Defensa: Esta actividad hace referencia a la preparacin de la defensa ante el

Anlisis de Requisitos: Anlisis del comportamiento externo del sistema,

Anlisis del sistema: Comprender el sistema existente en la empresa, el que se

Estudio mdulos de aprendizaje: Se estudiar la posibilidad de hacer unos

Revisin del diseo: Abarca todo el paquete. Se realiza a lo largo de todo el

Implementacin de la estructura: se implementar toda la estructura de la

Implementacin de los mdulos: se elaborarn todos los mdulos acordados,

Revisin de la implementacin: se har a lo largo de todo el paquete de

Anlisis de Resultados e Integracin

Integracin: Se ir haciendo una integracin paulatina, de las distintas partes

Entrega y aprobacin de documentacin: Entrega de toda la documentacin

2.7.3. Estimacin del proyecto

2.3. Diagrama circular estimacin de horas

Este grfico representa las horas empleadas en la realizacin del proyecto,

2.4. Calendario de trabajo

Explicacin ms detallada del calendario:

2.7.5. Diagrama de Gantt

2.5. Diagrama de Gantt

o Cuantificacin: probabilidad baja.

puede pensar en redirigirlo hacia otro proyecto que tambin necesite

o Cuantificacin: probabilidad alta.

Plan de contingencia: buscar informacin, libros o pginas que

Tecnologas mal elegidas

o Cuantificacin: probabilidad media.

Plan de contingencia: realizar un nuevo estudio sobre otras

Perdida de los archivos del proyecto

o Cuantificacin: probabilidad baja.

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

Estimaciones poco realistas

o Cuantificacin: probabilidad alta.

Plan de contingencia: realizar unas estimaciones no demasiado

o Cuantificacin: probabilidad media.

Plan de contingencia: se documentarn los errores cometidos y se

Cambios en los requisitos

o Cuantificacin: probabilidad baja.

Plan de contingencia: hacer los cambios pertinentes en la