Izpack PDF

TRABAJO FIN DE ESTUDIOS
PROYECTO FIN DE CARRERA
Instalador configurable a travs de ficheros XML
Miguel Maran Grandes
Tutor: Julio Rubio Garca
Curso 2009-2010
Instalador configurable a travs de ficheros XML, trabajo fin de estudios
de Miguel Maran Grandes, dirigido por Julio 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
UNIVERSIDAD DE LA RIOJA
Facultad de Ciencias, Estudios Agroalimentarios e Informtica
PROYECTO FIN DE CARRERA

Ingeniera Tcnica en Informtica de Gestin
Un instalador configurable a travs de ficheros

XML
Alumno: Miguel Maran Grandes

Director: Julio Jess Rubio Garca
Logroo, julio de 2010

1. Resumen
La instalacin de programas computacionales (software) es el proceso por el cual nue-
vos programas son transferidos a un computador y, eventualmente, configurados, para
ser usados con el fin para el cual fueron desarrollados. Un instalador es un programa
que realiza el proceso de instalacin de un determinado software.
Pues bien, en este proyecto se explicar cmo construir un creador de instaladores; es

decir, una aplicacin que permita elaborar instaladores de todo tipo, configurables me-
diante los datos almacenados en un fichero XML.
Adems, la aplicacin que desarrollaremos deber ser capaz de permitir al usuario que
ejecutar en ltima instancia la instalacin cambiar algunos parmetros del instalador,
as como proporcionar un desinstalador que revierta las modificaciones producidas
por el instalador.
Es necesario remarcar que la metodologa empleada a la hora de desarrollar la aplica-

cin se alej ligeramente de algunos de los procedimientos habituales en Ingeniera
del Software. Para dar un carcter ms experimental al proyecto, se consider conve-
niente no determinar completamente desde el comienzo los requisitos que deba cum-
plir el creador de instaladores. De este modo, ha sido necesario ir modificando los re-
quisitos poco a poco, a medida que implementbamos nuevas funcionalidades.
2
2. ndice
2.1. ndice de contenidos
1. Resumen......................................................................................................... 2
2. ndice.............................................................................................................. 3
2.1. ndice de contenidos ......................................................................................... 3
2.2. ndice de figuras y tablas .................................................................................. 5
3. Introduccin.................................................................................................... 6
4. Memoria......................................................................................................... 8
4.1. Documento de Objetivos del Proyecto (D. O. P.) .............................................. 8
4.1.1. Definicin del proyecto ................................................................................ 8
Antecedentes.......................................................................................................... 8
Objetivos del proyecto ........................................................................................... 9
Descripcin del producto ....................................................................................... 9
4.1.2. Alcance del proyecto .................................................................................. 10
Informe del alcance .............................................................................................. 10
Entregables ........................................................................................................... 10
Actividades de apoyo............................................................................................ 11
4.1.3. Recursos humanos, personal y plan de comunicaciones ........................... 11
Conexiones del proyecto ...................................................................................... 11
Plan de direccin del personal ............................................................................. 11
Plan de comunicaciones ....................................................................................... 12
4.1.4. Direccin de riesgos.................................................................................... 12
Fuentes de riesgo.................................................................................................. 12
Sntomas de riesgo ............................................................................................... 13
Cuantificacin de los riesgos ................................................................................ 13
Plan de contingencia............................................................................................. 14
4.1.5. Planificacin del proyecto .......................................................................... 14
Estructura de Descomposicin del Proyecto (EDP).............................................. 15
Listado de actividades .......................................................................................... 16
Calendario de trabajo ........................................................................................... 18
Diagrama de Gantt ............................................................................................... 19
4.2. Anlisis ............................................................................................................ 21
4.2.1. Anlisis de requisitos .................................................................................. 21
4.2.2. Casos de uso ............................................................................................... 23
Definir nombre instalador .................................................................................... 23
Definir archivos a copiar....................................................................................... 24
Definir accesos directos........................................................................................ 25
Definir paquetes ................................................................................................... 26
Definir accesos directos men Inicio y escritorio................................................. 27
Definir usuarios finales ......................................................................................... 28
Definir iconos........................................................................................................ 29
Definir ruta instalacin ......................................................................................... 30
Definir grupo programas ...................................................................................... 31
3
Definir modificacin registro................................................................................ 32
Definir archivos auto-ejecutables......................................................................... 33
Ejecutar instalador................................................................................................ 34
4.2.3. Diagrama de casos de uso .......................................................................... 35
4.3. Diseo ............................................................................................................. 36
4.3.1. Descripcin de la clase Creador_instaladores............................................ 37
4.3.2. Descripcin de la clase Construct............................................................... 38
4.3.3. Descripcin del archivo Make.bat .............................................................. 45
4.3.4. Relaciones entre los archivos de la aplicacin ........................................... 46
4.3.5. Interfaz del usuario creador ....................................................................... 46
Descripcin ........................................................................................................... 46
Precondiciones ..................................................................................................... 48
Poscondiciones ..................................................................................................... 48
4.3.6. Interfaz del usuario final............................................................................. 49
Captura de pantalla .............................................................................................. 49
Descripcin ........................................................................................................... 49
Precondiciones ..................................................................................................... 51
Poscondiciones ..................................................................................................... 51
Diagrama de estados ............................................................................................ 52
4.3.7. Interfaz para el desinstalador..................................................................... 53
4.4. Implementacin .............................................................................................. 54
4.5. Pruebas ........................................................................................................... 60
4.5.1. Pruebas de comprobacin de la funcionalidad .......................................... 60
4.5.2. Pruebas de la interfaz de usuario ............................................................... 64
4.6. Gestin del proyecto....................................................................................... 66
4.7. Conclusiones ................................................................................................... 68
4.7.1. Concordancia entre resultados y objetivos................................................ 68
4.7.2. Lecciones aprendidas ................................................................................. 68
4.7.3. Lneas de ampliacin posibles .................................................................... 69
4.8. Bibliografa ..................................................................................................... 70
4.9. Anexos............................................................................................................. 71
4.9.1. ANEXO I: Manual de instrucciones del usuario creador............................. 71
4.9.2. ANEXO II: Cronologa del Proyecto Fin de Carrera ..................................... 74
4.9.3. ANEXO III: Actas de reuniones.................................................................... 79
4
2.2. ndice de figuras y tablas
Figura 1: Esquema global de la aplicacin........................................................................ 9
Figura 2: Modelo de planificacin .................................................................................. 15
Figura 3: Diagrama EDP .................................................................................................. 16
Figura 4: Calendario de trabajo ...................................................................................... 19
Figura 5: Diagrama de Gantt del trabajo planificado ..................................................... 20
Figura 6: Diagrama de casos de uso ............................................................................... 35
Tabla 1: Elementos y atributos para modificar el registro ............................................. 40
Tabla 2: Claves del fichero de configuracin y su descripcin ....................................... 45
Figura 7: Diagrama de colaboracin entre los ficheros de la aplicacin........................ 46
Figura 8: XML-Schema del fichero Instalador.xml.......................................................... 47
Figura 9: XML-Schema del elemento lugaresInstalacion ............................................... 47
Figura 10: Prototipo de la interfaz del usuario final....................................................... 49
Figura 11: Prototipo de interfaz para cancelar la instalacin ........................................ 50
Figura 12: Prototipo de interfaz para confirmar la instalacin ...................................... 51
Figura 13: Diagrama de estados de la interfaz del usuario final .................................... 52
Figura 14: Prototipo de interfaz para ejecutar el desinstalador .................................... 53
Figura 15: Prototipo de interfaz para confirmar la desinstalacin................................. 53
5
3. Introduccin
El proyecto que queremos desarrollar consiste en la construccin de un creador de
instaladores configurable a travs de un fichero XML, de modo que parte de la confi-
guracin inicial dada por este fichero pueda ser modificada posteriormente por el
usuario que a la postre instalar la aplicacin para la que se construy el instalador.
Las funciones del creador de instaladores no se limitarn a proporcionar el instalador

del programa que queremos que se instale, sino tambin a crear los archivos y proce-
sos necesarios para desinstalarlo del equipo (es decir, un desinstalador de ese mismo
programa). Adems, deber dar la opcin de que el instalador creado permita configu-
rar la instalacin en los aspectos ms usuales: creacin de accesos directos, eleccin
del directorio de instalacin, etctera.
Para la construccin de este creador de instaladores nos fijaremos en las caractersti-

cas de algunos productos de software similares ya existentes. Si bien uno de los objeti-
vos del proyecto ser emularlos en lo ms bsico, se intentar mejorarlos en la medida
de lo posible.
Las razones por las que he elegido este tema para realizar el Proyecto Fin de Carrera
son tres: por un lado, la posibilidad de colaborar con el Departamento de Matemticas
y Computacin; por otro, la opcin de formar parte del equipo de desarrollo de la
aplicacin para alumnos de matemticas de secundaria TutorMates (este aspecto lo
explicaremos con ms detalle en el siguiente prrafo); y finalmente, mi deseo de em-
barcarme en un proyecto eminentemente tecnolgico y de investigacin que me pro-
porcione una formacin de garantas para el desarrollo de la profesin de ingeniero
informtico.
Centrndonos en TutorMates, AddLink Research, S.L. es la empresa encargada del de-

sarrollo y comercializacin de esta aplicacin, dirigida a los alumnos y profesores que
forman parte de la enseanza de las matemticas en secundaria. Al igual que la mayo-
ra de las aplicaciones informticas, TutorMates necesitaba un instalador de modo que
fuera ms fcil incorporar el programa al equipo del usuario que lo utilizara. As, el
equipo de desarrollo de TutorMates decidi incluir en el proyecto un creador de insta-
ladores desarrollado en Java y de cdigo abierto para cubrir sus necesidades iniciales
y poder contar con l desde el primer da. Es posible que la herramienta que vamos a
construir se encargue de la elaboracin de este instalador.
6
Existen determinadas funcionalidades del creador de instaladores que finalmente no
se considerarn en el proyecto, como es la incorporacin de un soporte multilinge
(hay que tener en cuenta que TutorMates es una herramienta pensada para ser usada
en todo el territorio nacional, por lo que debera estar traducida, al menos, al gallego,
vasco y cataln), una interfaz para el usuario creador de la instalacin o un soporte
multiplataforma, de modo que no slo funcione en Windows. La razn por la que no se
considerarn tales requisitos es la falta de tiempo: la fecha tope de entrega de la me-
moria se ha establecido en julio de 2010, siendo la fecha de inicio octubre de 2009.
7
4. Memoria
En este apartado desarrollaremos el cuerpo de la memoria, uno de los entregables ms
importantes del proyecto.
4.1. Documento de Objetivos del Proyecto (D. O. P.)

En este captulo se especificarn asuntos relativos al proyecto tales como sus objeti-
vos, descripcin, entregables principales, plan de trabajo y otros aspectos.
4.1.1. Definicin del proyecto
En este punto se explicarn, entre otras cosas, los antecedentes en los que viene en-
marcado el proyecto, los objetivos que se pretenden y una descripcin del producto
que se desea elaborar con l.
Antecedentes
El proyecto se enmarca dentro de la construccin de una aplicacin que servir como

herramienta de apoyo a los estudiantes de matemticas de secundaria: TutorMates.
En concreto, lo que se pretende con dicho proyecto es la construccin de un creador
de instaladores que pueda ser aprovechado por la empresa que desarrolla este pro-
ducto con el fin de no utilizar programas de instalacin externos a ella y, de este modo,
fabricar el instalador definitivo de la aplicacin.
Este proyecto se realiza para la empresa Addlink Research, S.L., propietaria de la marca
TutorMates, en colaboracin con el Ministerio de Educacin, Geogebra y las universi-
dades de Cantabria y La Rioja. El profesor de la UR Julio Rubio Garca actu como tutor
acadmico del proyecto, mientras que el papel de director del proyecto (y, por tanto,
responsable de todas las decisiones tomadas en l) recay en mi persona.
Se trata de un proyecto clave dentro de este marco, porque de l depende que la ela-
boracin del instalador de la aplicacin utilice herramientas ajenas a la empresa. Por
otro lado, el producto que se espera obtener debera emular (y si fuera posible, mejo-
rar) a alguno de los creadores de instaladores ya existentes (en concreto, a IzPack, ba-
sado precisamente en la configuracin de la instalacin a travs de ficheros XML). Este
hecho permitira la opcin de realizar (si la empresa lo creyera conveniente) el instala-
dor definitivo de TutorMates bajo mi responsabilidad, como algo fuera de proyecto pe-
ro con una cierta remuneracin econmica.
8
4.1.2. Alcance del proyecto
En este apartado se detallar qu se har y qu no se har en el proyecto, as como los

entregables que se depositarn.
Informe del alcance
Este proyecto est englobado en otro ms grande, basado en la realizacin de una apli-
cacin que sirva como herramienta de aprendizaje matemtico a los alumnos y profe-
sores de la educacin secundaria: TutorMates. Esta aplicacin deber cumplir los si-
guientes requisitos:
El desarrollo multiplataforma: Windows, Linux y Mac OS X.

El motor de clculo reposar en herramientas de uso libre y gratuito, como
MAXIMA y Geogebra.
La interfaz de usuario desarrollada en Java tendr como principales referentes
la facilidad de uso y la interaccin con el usuario final (el alumno).
El soporte multilinge.
El creador de instaladores no cumplir, en un principio, todas estas caractersticas.

Concretamente, slo ser vlido para Windows, ya que se usarn mandatos propios y
exclusivos de este sistema operativo, y por falta de tiempo no dispondr del soporte
multilinge. Sin embargo, s que se esperar que cumpla los requisitos relativos a la fa-
cilidad de uso de su interfaz.
Por otro lado, como hemos explicado ms arriba, la aplicacin deber imitar (o mejo-
rar, en la medida de lo posible) a las herramientas de construccin de instaladores ms
conocidas hoy en da. En concreto, estar inspirada por IzPack, de modo que ambas es-
tn desarrolladas en lenguaje Java y recojan las opciones que puedan estar disponibles
en las instalaciones mediante la lectura de ficheros XML. Un aspecto que nuestra apli-
cacin mejorar con respecto a IzPack es dar la opcin al usuario que instalar el pro-
grama de instalar en su equipo la mquina virtual de Java, necesaria para el correcto
funcionamiento del creador de instaladores, en caso de no disponer de ella.
Entregables
Una vez que el proyecto est terminado y listo para entregar, tendrn que estar finali-
zados los siguientes entregables:
Ficheros en Java de la aplicacin (creador de instaladores), junto con un script

que ponga en ejecucin los archivos compilados, las instrucciones de uso en un
fichero en formato de texto y el resto de archivos necesarios para su correcta
ejecucin. Todo esto ser entregado, precisamente, en forma de un instalador
creado por la misma aplicacin.
Memoria del proyecto.
Presentacin del proyecto preparada.
10
Actividades de apoyo
Ser valiosa una buena documentacin sobre:
XML.
Java y C++.
JDom.
Swing/AWT (para la interfaz grfica del instalador).
4.1.3. Recursos humanos, personal y plan de comunicaciones
En este punto se explicar qu roles desempean las personas que participan en el

proyecto, as como las obligaciones que deben cumplir y las decisiones que deben
tomar.
Conexiones del proyecto

Estas son las personas que participarn en el proyecto, de forma directa o indirecta:
Miguel Maran: Director y desarrollador del proyecto.

o Decisiones a tomar: todas.
o Dedicacin: completa.
Julio Rubio: Tutor de la Facultad.

o Decisiones a tomar: cualquiera, en caso de que lo estime oportuno.
o Dedicacin: espordica (solo en caso de que su intervencin en el Proyecto
Fin de Carrera de aqu en adelante, PFC sea necesaria).
Jnathan Heras Vicente: Miembro del Departamento de Matemticas y Com-

putacin de la Universidad de La Rioja.
o Decisiones a tomar: ninguna que afecte al desarrollo del proyecto, pues co-
laborar desinteresadamente como consejero y supuesto cliente de mi
aplicacin.
o Dedicacin: espordica, siempre que l quiera.
Miembros del tribunal evaluador: Grupo de profesores que evaluarn el PFC.

o Decisiones a tomar: la nota final del proyecto.
o Dedicacin: solamente lo necesario para evaluar el proyecto y acudir a la
defensa del PFC.
Plan de direccin del personal
Yo soy el director del proyecto; por consiguiente, las decisiones finales sern tomadas
por m, sea cual sea su naturaleza. No obstante, Julio Rubio aconsejar cuando l lo
considere oportuno o cuando yo lo solicite.
11
Plan de comunicaciones
Las herramientas que se emplearn para la comunicacin dentro del PFC son:
Reuniones: Servirn de comunicacin entre Julio Rubio (tutor acadmico) y yo.

En ellas se tomarn las decisiones relativas al proyecto y se tratarn los aspec-
tos ms trascendentes.
Correo electrnico.
Defensa: Se utilizar una presentacin de 30 minutos de duracin mxima para
comunicar al Tribunal evaluador los aspectos ms relevantes del proyecto. En
ella se utilizarn medios como transparencias y una demostracin en vivo de
las caractersticas de la aplicacin.
4.1.4. Direccin de riesgos
En este apartado se identificarn las fuentes principales de riesgo y se crear un plan a

seguir.
Fuentes de riesgo
A continuacin se enumerarn las fuentes de riesgo identificadas para este proyecto.
1. La poca experiencia en el desarrollo de proyectos es una fuente de riesgo poten-

cial. Hasta este momento, el alumno slo tiene experiencia en realizar trabajos de
ndole informtica a menor escala, no habiendo ninguno que alcance la magnitud
de este proyecto. Con mucha seguridad, esta inexperiencia ocasionar diversos fa-
llos en todos los aspectos relativos al proyecto: planificacin, diseo, anlisis
2. La estimacin de las fechas para las actividades que conforman el proyecto puede
no ser la adecuada, ya que el alumno no podr tener dedicacin exclusiva al mismo
hasta mediados del mes de junio de 2010. Esto har que el alumno slo pueda tra-
bajar una media de 15 horas semanales, las cuales pueden llegar a ser insuficien-
tes, provocando el consiguiente retraso en las tareas programadas.
3. El diseo realizado por el alumno puede no ser ptimo. Puede haber algunos cam-
bios en el diseo que ocasionen rehacer necesariamente el trabajo.
4. Puede haber problemas software ocasionados por la incorrecta manipulacin de
las herramientas disponibles. Dicho riesgo se centra sobre todo en la utilizacin de
las variables de entorno del sistema PATH y CLASSPATH. El uso indebido de estas
variables puede ocasionar la incorrecta ejecucin de algunos comandos, tanto de
Java como del sistema operativo Windows.
5. Al disponer el alumno de un periodo relativamente pequeo de tiempo (que no lle-
ga a los 9 meses), hay riesgo de que el alumno caiga enfermo o sufra algn percan-
ce que le impida trabajar en el proyecto dentro de los plazos estimados.
12
Sntomas de riesgo
Al detectar alguno de estos sntomas se activar inmediatamente el plan de

contingencia.
1. Continuos errores que impiden avanzar en el desarrollo del proyecto en las fechas
planificadas.
2. A medida que el proyecto avanza, puede haber un continuo retraso en la finaliza-
cin de paquetes de trabajo que nos haga pensar que tal vez la estimacin de las
fechas que se haba realizado no era la correcta.
3. En tiempo de diseo se realizar una exhaustiva revisin del mismo. Es entonces
cuando se decidir si remodelar el diseo o dejarlo como est.
4. Es sencillo percatarse del incorrecto funcionamiento de las herramientas utilizadas,
pues esto impide por completo la ejecucin de la aplicacin.
5. Sntomas de enfermedad, aparte de los propios sntomas mdicos, pueden ser el
descenso de la productividad y el uso continuo de trabajo excesivo sin poder llegar
a tiempo a las fechas planificadas.
Cuantificacin de los riesgos
Cada fuente de riesgo tendr una diferente evaluacin: desde una fuente de riesgo po-
tencial cuyo dao se considerar elevado hasta una fuente de riesgo cuyo dao se con-
siderar mnimo.
1. El rumbo del proyecto, debido a los continuos informes semanales del alumno, va a
estar siempre bajo la supervisin de Julio Rubio, por lo que el riesgo en este aspec-
to es pequeo: si Julio Rubio detectara alguna anomala lo suficientemente grave
como para poner en compromiso toda la estimacin realizada, informar de inme-
diato con el fin de que el alumno pueda corregir a tiempo.
2. La estimacin de fechas realizada para las actividades que conforman el proyecto
puede no ser la apropiada. Hay que recordar que el alumno no puede trabajar a
tiempo completo en el proyecto hasta el mes de junio de 2010, de modo que las
horas que dedique al proyecto durante el curso acadmico pueden no ser
suficientes.
3. Un cambio en el diseo a destiempo es un riesgo bastante grave, ya que puede su-
poner que el trabajo de varios meses caiga en saco roto.
4. Podemos suponer que el riesgo relacionado con el uso indebido de las variables de
entorno es de tipo medio-alto, ya que podra suponer la imposibilidad de poder
ejecutar en la mquina afectada el proyecto hasta no descubrir el origen real del
error.
5. Ya que la incapacidad fsica del alumno puede ser prolongada o no, este punto ser
considerado de riesgo medio en el proyecto.
13
Plan de contingencia
Para cada fuente de riesgo identificada se actuar segn lo descrito en este punto.
1. Se pedir una reunin con Julio Rubio con el fin de que pueda reorientar al alumno
segn crea conveniente.
2. Se realizar un cambio en la estimacin de las fechas en el plan del proyecto, inten-
tando que las nuevas sean ms acordes a la realidad que se est observando. Los
motivos por los cuales se habr realizado el cambio sern tomados en cuenta en un
futuro, con el fin de evitar caer en los mismos errores.
3. Si se detectara que el diseo es incorrecto, el alumno realizar los cambios que
estime oportunos antes de comenzar la implementacin.
4. Si se detectaran problemas con las herramientas de software, el alumno deber
tratar de resolverlos en primera instancia, siendo consciente de las posibles fuen-
tes de origen del error. Si despus de un tiempo considerable el alumno no hubie-
ra conseguido solventar sus problemas y adems stos le supusieran un grave im-
pedimento para seguir con la realizacin del proyecto, ser al fin Julio Rubio el que
tomar cartas en el asunto.
5. La principal medida de contingencia frente al agotamiento consistir en ir redu-
ciendo paulatinamente todas las funciones que no se consideren crticas para el
sistema.
4.1.5. Planificacin del proyecto
En primer lugar, es necesario indicar que la evolucin de este proyecto se basar en la

sucesiva repeticin de dos actividades mientras se est elaborando, a saber:
1. Estudio de una de las funcionalidades del creador de instaladores IzPack.

2. Desarrollo de una nueva versin del generador de instaladores que incluya es-
ta nueva funcionalidad, de modo que se realicen para dicha versin las perti-
nentes fases de anlisis, diseo e implementacin.
Por tanto, el mtodo de trabajo que seguir consistir en la elaboracin de prototipos

un poco ms completos en cada iteracin, los cuales incluirn o mejorarn alguna de
las caractersticas que proporciona IzPack. Este mtodo de trabajo es muy similar al co-
nocido como AGILE Extreme Programming, que se basa ms en la adaptabilidad que
en la previsibilidad y que busca acercarse al producto final a travs de sucesivas aproxi-
maciones y continuos cambios en los requisitos.
La razn por la que se eligi este modo de trabajo es el desconocimiento a priori de las
funcionalidades del IzPack, pues no olvidemos que el objetivo final es la elaboracin de
un creador de instaladores que emule o mejore a ese programa. Estas funcionalidades
se irn descubriendo a lo largo del desarrollo del proyecto, de modo que cada pequea
iteracin dentro de su ciclo de vida deba su existencia a la nueva funcionalidad.
14
PT003 Documentacin
Este paquete contendr toda la documentacin que se precisa para realizar el proyec-
to. En ocasiones, ser necesario realizar alguna investigacin o ser partcipe de algn
tipo de aprendizaje; en esos casos, las actividades de este paquete realizarn dicha
labor.
A0030 Identificacin de fuentes y bsqueda de los datos necesarios.
A0031 Lectura y aprendizaje.
PT010 Captura / Identificacin de requisitos y anlisis

Este paquete incluye el estudio y el anlisis de las caractersticas y funcionalidades de
IzPack para que puedan ser diseadas e implementadas ms adelante. Actividades:
A0100 Estudio de las funcionalidades de IzPack.
A0101 Extraccin de los requisitos que se deben implementar.
A0102 Anlisis de los requisitos.
PT020 Diseo de la implementacin

Este paquete de trabajo realizar el diseo de los requisitos para estudiar el modo en
el que sern implementados. Actividades:
A0200 Realizacin o modificacin de la estructura de las clases.
A0201 Estudio de los flujos de actividad.
PT021 Revisin del diseo

Revisin de los modelos realizados por si existen errores o irregularidades en ellos, con
el fin de que puedan ser corregidos. Actividades:
A0210 Estudio de los diseos.
A0211 Correccin e introduccin de los cambios (si fuese necesario).
PT030 Eleccin de las herramientas

Este paquete incluye el estudio que determina las herramientas de desarrollo que se
van a utilizar a lo largo del PFC. Actividades:
A0300 Consulta y estudio de posibles herramientas.
A0301 Eleccin de las herramientas.
PT031 Desarrollo de la implementacin

El paquete se encargar de la implementacin de los diseos realizados para cada fun-
cionalidad que se desea aadir a la aplicacin. Ser sin duda uno de los ms costosos
en el tiempo y esfuerzo invertidos, puesto que podran aparecer errores de programa-
cin inesperados o que sean debidos a una causa difcil de detectar.
A0310 Implementacin de las nuevas funcionalidades.
PT032 Revisin de la implementacin

Se considera imprescindible una revisin de la implementacin que se ha hecho, con el
fin de corregir los errores que se hayan podido encontrar en el cdigo de la aplicacin
o mejorarlo. Actividades:
A0320 Anlisis del funcionamiento de los requisitos implementados.
A0321 Realizacin de los cambios y/o mejoras oportunos (si procede).
17
PT040 Eleccin de las pruebas
Diseo de las pruebas que se realizarn para comprobar el buen funcionamiento del
sistema, escogiendo los casos ms susceptibles de poseer fallos. Se realizar un listado
de pruebas, detallando en cada una los posibles datos de entrada con sus correspon-
dientes salidas esperadas. Actividades:
A0400 Estudio de los requisitos.
A0401 Listado de las pruebas.
PT041 Ejecucin de las pruebas

Ejecucin de las pruebas diseadas y enumeradas en el paquete PT040. Actividades:
A0410 Ejecucin funcional de las pruebas.
A0411 Registro de los resultados obtenidos en las pruebas.
Calendario de trabajo
Puesto que durante el curso 2009/2010 estar estudiando el ltimo curso de la doble
titulacin (Ingeniera Tcnica en Informtica de Gestin + Licenciatura en Matemti-
cas), no podr dedicarme de forma exclusiva al proyecto hasta, por lo menos, el da 21
de junio, momento en el que terminan los exmenes del segundo cuatrimestre. Hasta
esa fecha, mi dedicacin al PFC ser parcial, combinndola con el estudio de las asigna-
turas de los cursos a los que me he referido antes. De hecho, habr periodos en los
que incluso deje de invertir tiempo en el PFC ante la proximidad de los exmenes. Esto,
por tanto, hace que sea muy probable que no pueda terminar el proyecto hasta media-
dos de julio.
La Figura 4 representa el esquema del calendario de trabajo. En naranja se represen-

tan los das de dedicacin parcial al proyecto, en azul los das de dedicacin comple-
ta, en blanco los das en los que, presumiblemente, no pueda dedicarme al proyecto y
en verde los das a los que se puede extender la elaboracin del PFC (durante los que
se supone que mi dedicacin ser total).
18
4.2. Anlisis
4.2.1. Anlisis de requisitos
Se pretende construir un creador de instaladores que sea capaz de permitir la cons-

truccin y configuracin de cualquier tipo de instalador, independientemente del pro-
grama para el que se quiera fabricar. Es deseable que el creador de instaladores pro-
porcione una funcionalidad similar a la que tiene la aplicacin IzPack (otro creador de
instaladores de cdigo abierto); esto es, que sea capaz de permitirle al usuario:
Indicar el nombre que tendr el archivo de instalacin.

Definir el directorio en el que se instalar el programa.
Indicar los archivos de la instalacin que se copiarn en el directorio de destino, sin
importar su ubicacin u organizacin dentro del sistema en el momento de la crea-
cin del instalador.
Ordenar la creacin de un nuevo grupo de programas dentro del men Inicio de
Windows con los accesos directos a los archivos de la instalacin que se deseen,
cuyo nombre tambin podr ser definido.
Crear accesos directos durante la instalacin a cualquier directorio o archivo en el
escritorio, en la carpeta de programas, en la carpeta de aplicaciones o en la carpeta
de inicio del men Inicio.
Indicar si la instalacin ser vlida para todos los usuarios del equipo o slo para el
que ha iniciado la sesin.
Proporcionar un desinstalador que gestione la eliminacin de los archivos de la
aplicacin del sistema y de los valores del registro de Windows relacionados con
ella cuando ste se ejecute, as como incorporar un icono que aparezca en el acce-
so directo de este desinstalador (y otros iconos que estn vinculados a otros acce-
sos directos).
Modificar el registro de Windows con los datos pertinentes relativos a la aplicacin
durante la instalacin, o usando opciones por defecto o bien dando la posibilidad
de hacerlo de forma libre, a gusto del usuario.
Incluir ejecutables (archivos leme, instalaciones externas, etctera) que se pongan
en funcionamiento al finalizar la instalacin.
Definir los paquetes (grupos) de archivos que crea oportunos, definindose paque-
te de archivos como un conjunto de archivos que se instalan como un todo: si uno
de ellos se acaba instalando, los dems tambin.
Adems, el creador de instaladores tendr que ser capaz de proporcionar el instalador

en forma de ejecutable auto-extrable, el cual deber gestionar la descompresin de
los archivos incluidos en la instalacin, ejecutarla, modificar adecuadamente el registro
de Windows y posteriormente eliminar los archivos descomprimidos (como consigue
hacer IzPack). Tambin se requiere que el instalador incorpore la instalacin de la JRE
de Java, con el fin de instalarla en caso de que el equipo del usuario que ejecutar la
instalacin final no disponga an de ninguna versin de ella.
21
Por otro lado, el usuario que ejecute la instalacin al final deber ser igualmente capaz
de modificar ciertos parmetros para definirlos como l prefiera, a saber:
La ruta de instalacin de la aplicacin.

La ubicacin de los accesos directos en el escritorio.
Qu paquetes (grupos de archivos) debern instalarse.
La creacin y el nombre del grupo de programas dentro del men Inicio en el que
se crearn los accesos directos.
Los usuarios para los cuales se instalar la aplicacin (slo el actual o todos los
usuarios del equipo).
La modificacin de esta informacin deber hacerse posible mediante la interaccin

con una interfaz sencilla de manejar y eficaz, que adems muestre los parmetros por
defecto elegidos por el usuario creador de la instalacin.
Tanto el proceso de creacin del instalador como la instalacin en s debern ejecutar-

se en un tiempo no excesivamente largo, que sea razonablemente corto.
Por ltimo, el desinstalador creado deber revertir los cambios producidos en el equi-
po por el instalador de la misma aplicacin, proporcionando al usuario la posibilidad de
conservar el directorio de instalacin y las propiedades de su configuracin incluidas
en los archivos de desinstalacin (en cuyo caso no sern eliminados).
22
4.2.2. Casos de uso
Definir nombre instalador
Caso de uso: Definir nombre instalador

Objetivo: Permitir al usuario creador la posibilidad de indicar el nombre que llevar el
instalador.
Actores: Usuario creador (UC)
Precondiciones: El usuario est en condiciones de editar un fichero de nombre
instalador.xml, que debe ser acorde a lo especificado en el fichero instalador.dtd o
instalador.xsd.
Poscondiciones: El nombre del instalador creado deber ser el especificado por el
usuario.
Pasos:
1. UC: Escribe el nombre del instalador en el atributo nombre del elemento
instalador del fichero instalador.xml.
2. Sistema: Guarda el nombre elegido por el usuario para asignrselo al instalador.
23
Definir archivos a copiar
Caso de uso: Definir archivos a copiar

Objetivo: Ofrecer al usuario creador la posibilidad de definir los paquetes de archivos
que se podrn instalar.
Precondiciones: El UC est en condiciones de editar un fichero de nombre
instalador.xsd.
Poscondiciones: Los archivos declarados por el UC estarn en disposicin de ser insta-
lados por la aplicacin, dependiendo de las decisiones de los usuarios creador y final,
de forma que sern copiados en el propio directorio de la instalacin.
Pasos:
1. UC: Escribe las rutas de las carpetas o archivos que se deben instalar dentro del
elemento instalador/fuentes/origen/archivo del fichero instalador.xml.
2. Sistema: Guarda y trata la informacin introducida por el UC.
Extensiones:
1.1. El UC desea copiar los archivos que ha declarado en un subdirectorio de la carpe-
ta de instalacin cuando el instalador se ponga en funcionamiento.
1.1.1. UC: Escribe la ruta relativa del subdirectorio dentro de la carpeta de instalacin
al que desea que se copien los archivos en el elemento
instalador/fuentes/origen/destino del fichero instalador.xml.
1.1.2. Vuelve al paso 2 del flujo normal.
24
Definir accesos directos
Caso de uso: Definir accesos directos

Objetivo: Permitir al usuario creador del instalador indicar qu ficheros de la instala-
cin podrn tener un acceso directo, as como los lugares dentro del sistema en los
que se podr ubicar.
instalador.xsd. Adems, se han debido especificar en el XML los archivos o carpetas
para los que se desean hacer los accesos directos.
Pasos:
1. Extends al caso de uso Definir archivos a copiar.
2. UC: Indica si desea que se cree por defecto un nuevo grupo de programas, para la
aplicacin que se va a instalar, en el men Inicio, dentro el atributo incluir del
elemento instalador/lugaresInstalacion/programas del fichero instalador.xml.
3. UC: Define qu accesos directos quiere que se creen mediante los atributos del
elemento instalador/fuentes/origen del paquete de archivos correspondiente,
dentro del fichero instalador.xml.
4. Sistema: Guarda y trata la informacin introducida por el usuario.
25
Definir paquetes
Caso de uso: Definir paquetes

Objetivo: Permitir al usuario creador definir qu paquetes de archivos tendr la opor-
tunidad de instalar opcionalmente el usuario final, y permitir instalarlos a ste ltimo.
Actores: Usuario creador (UC), Usuario final (UF)
instalador.xsd. Adems, se ha debido especificar en el XML qu carpetas y/o archivos
podrn ser copiados en el directorio de instalacin.
Poscondiciones: Los paquetes de archivos que hayan sido elegidos finalmente por el
usuario final y aquellos archivos que no estuvieran incluidos en ningn paquete sern
instalados en el equipo, mientras que el resto no.
Pasos:
1. Extends al caso de uso Definir archivos a copiar.
2. UC: Define los paquetes que el usuario final tendr la opcin de instalar mediante
el subelemento paquete del elemento instalador/fuentes/origen, dentro del
fichero instalador.xml.
3. UC: Indica si el paquete declarado ser instalado por defecto mediante el atributo
defecto del elemento instalador/fuentes/origen/paquete, dentro del fichero
instalador.xml.
5. Sistema: Muestra en una interfaz al UF un formulario que le permita elegir los pa-
quetes de archivos que desea instalar, mostrando la configuracin por defecto ele-
gida por el usuario creador.
6. UF: Selecciona (o deselecciona) los paquetes de archivos.
7. Detecta y guarda la informacin introducida por el UF.
26
Definir accesos directos men Inicio y escritorio
Caso de uso: Definir accesos directos men Inicio y escritorio

Objetivo: Permitir al usuario que ejecutar la instalacin indicar si quiere que aparez-
can accesos directos en el escritorio de aquellos ficheros que los admitan, segn la
decisin del usuario creador, y si desea que se cree un nuevo grupo de programas que
incluya los accesos directos a los ficheros de la misma aplicacin que deban aparecer
all.
Actores: Usuario final (UF)
Precondiciones: El usuario creador ha definido previamente los archivos para los que
el instalador crear accesos directos.
Poscondiciones: El instalador deber crear en las ubicaciones indicadas por el UF (es-
critorio, men Inicio, ambas o ninguna) los accesos directos definidos por el usuario
creador. Si se eligi la opcin men Inicio, adems tendr que crear el grupo de pro-
gramas correspondiente dentro del men Inicio.
Pasos:
1. Herencia del caso de uso Definir accesos directos.
2. Sistema: Muestra en una interfaz al UF un formulario que le permita elegir instalar
accesos directos en el escritorio o en el men Inicio (o en ambas ubicaciones),
mostrando la configuracin por defecto elegida por el usuario creador.
3. UF: Selecciona (o deselecciona) las ubicaciones en las que desea que se creen los
accesos directos.
4. Detecta y guarda la informacin introducida por el UF.
27
Definir usuarios finales
Caso de uso: Definir usuarios finales

Objetivo: Permitir al usuario creador elegir por defecto qu usuarios del equipo en el
que se llevar a cabo la instalacin tendrn a su disposicin la aplicacin que se desea
instalar, as como facilitar la eleccin definitiva al usuario final.
Precondiciones: El UC est en condiciones de editar un fichero de nombre
instalador.xsd.
Poscondiciones: La instalacin afectar a los usuarios definidos por el UF.
Pasos:
1. UC: Define los usuarios por defecto de la instalacin mediante el atributo todos
del elemento instalador/usuarios del fichero instalador.xml.
3. Sistema: Muestra en una interfaz un formulario que permita al UF decidir para qu
usuarios (el actual o todos) se instalar la aplicacin, mostrando la configuracin
por defecto elegida por el usuario creador.
4. UF: Selecciona los usuarios de la instalacin.
5. Sistema: Detecta y guarda los usuarios de la instalacin.
28
Definir iconos
Caso de uso: Definir iconos

Objetivo: Permitir al usuario creador declarar los iconos que acompaarn a los acce-
sos directos que se hayan definido previamente.
instalador.xml, que debe ser acorde a lo especificado en el fichero instalador.dtd.
Adems, se han debido especificar en el XML qu carpetas y/o archivos tendrn aso-
ciado un acceso directo.
Poscondiciones: Los iconos definidos por el usuario acompaarn a los accesos direc-
tos a los que estn vinculados tras la instalacin.
Pasos:
1. Extends al caso de uso Definir accesos directos.
2. UC: Define los iconos que acompaarn a los accesos directos mediante el subele-
mento icono del elemento instalador/fuentes/origen del paquete de archivos
correspondiente, dentro del fichero instalador.xml.
3. UC: Define el icono que acompaar al acceso directo del desinstalador mediante
el subelemento icono del elemento instalador/desinstalador, dentro del fiche-
ro instalador.xml.
Extensiones:
3.1. El UC no define ningn icono para el acceso directo del desinstalador.
3.1.1. UC: Deja vaco el subelemento icono del elemento instalador/desinstalador.
29
Definir ruta instalacin
Caso de uso: Definir ruta instalacin

Objetivo: Permitir al usuario creador elegir la ruta de instalacin en la que por defecto
se copiarn los archivos de la aplicacin que se desea instalar, as como facilitar al
usuario final la eleccin definitiva de esta ruta.
Precondiciones: El usuario creador est en condiciones de editar un fichero de nom-
bre instalador.xml, que debe ser acorde a lo especificado en el fichero instalador.dtd
o instalador.xsd.
Poscondiciones: El instalador deber copiar los archivos de la instalacin en el direc-
torio indicado.
Pasos:
1. UC: Define la ruta en la que se copiarn los archivos de la instalacin en el subele-
mento destino del elemento instalador/lugaresInstalacion del fichero
instalador.xml.
2. Sistema: Guarda y trata la ruta introducida por el UC.
3. Sistema: Muestra en una interfaz al UF un campo con el nombre de la ruta elegida
por defecto por el UC, de modo que el UF pueda cambiarla si lo desea.
4. UF: Cambia, si as lo desea, la ruta de instalacin.
5. Sistema: Detecta y guarda la ruta de la instalacin.
30
Definir grupo programas
Caso de uso: Definir grupo programas

Objetivo: Permite al usuario creador asignar un nombre por defecto al nuevo grupo
de programas en el que se instalarn los accesos directos que se hayan definido para
los ficheros de la instalacin en caso de que el usuario final ordene crearlo, as como
al usuario final elegir el nombre definitivo de este grupo de programas en el que se
copiarn finalmente los accesos directos. El nombre seleccionado ser tambin el del
directorio de instalacin.
Precondiciones: El usuario creador est en condiciones de editar un fichero de nom-
bre instalador.xml, que debe ser acorde a lo especificado en el fichero instalador.dtd
o instalador.xsd.
Poscondiciones: El instalador crear los accesos directos especificados en el grupo de
programas determinado por el UF.
Pasos:
1. UC: Indica el nombre que llevar por defecto el grupo de programas que se crea-
r durante la instalacin en el men Inicio (que ser el mismo que el de la carpe-
ta de instalacin) en el elemento instalador/lugaresInstalacion/programas del
fichero instalador.xml.
2. Sistema: Guarda y trata los datos introducidos por el UC.
3. Sistema: Muestra al UF el grupo de programas elegido por defecto, de tal forma
que lo pueda cambiar.
4. UF: Elige el nombre del grupo de programas (bien sea uno nuevo u otro existen-
te) del men Inicio en el que se instalarn los accesos directos.
5. Detecta y guarda el grupo de programas seleccionado.
31
Definir modificacin registro
Caso de uso: Definir modificacin registro

Objetivo: Permitir al usuario creador definir el modo en el que se modificar el regis-
tro de Windows tras la instalacin de la aplicacin.
instalador.xsd.
Poscondiciones: El instalador deber modificar el registro de Windows de acuerdo a
la informacin suministrada por el UC.
Pasos:
1. UC: Escribe Yes en el atributo modificar del elemento
instalador/lugaresInstalacion/registro del fichero instalador.xml.
2. UC: Define las modificaciones que se debern llevar a cabo en el registro de
Windows durante la instalacin mediante los atributos y subelementos pertenecien-
tes a los subelementos instalacion y desinstalacion del elemento
3. Sistema: Guarda y trata los datos introducidos por el UC.
Extensiones:
1.1. El UC no desea realizar ninguna modificacin en el registro.
1.1.1. UC: Escribe No en el atributo modificar del elemento
1.1.2. Fin del caso de uso.
2.1. El UC desea personalizar la modificacin del registro.
2.1.1. UC: Define las modificaciones que se debern llevar a cabo en el registro de
Windows durante la instalacin mediante los atributos pertenecientes al subelemento
customize del elemento instalador/lugaresInstalacion/registro del fichero
instalador.xml.
32
Definir archivos auto-ejecutables
Caso de uso: Definir archivos auto-ejecutables

Objetivo: Dar la oportunidad al usuario creador de incluir en la instalacin aquellos ar-
chivos externos auto-ejecutables que se debern ejecutar en el transcurso de sta
(otras instalaciones, ficheros de texto, etctera).
instalador.xsd.
Poscondiciones: El instalador deber ejecutar al final de la instalacin los auto-
ejecutables definidos por el UC.
Pasos:
1. UC: Define los archivos que se ejecutarn al final de la instalacin mediante el ele-
mento instalador/ejecutable del fichero instalador.xml.
2. UC: Para cada uno de los archivos ejecutables, indica (si fuera necesario) con qu
programa se abre mediante el atributo prog del elemento
instalador/ejecutable.
33
Ejecutar instalador
Caso de uso: Ejecutar instalador

Objetivo: Llevar a cabo la instalacin de la aplicacin, de modo que se cree un archivo
que gestione su posible desinstalacin posterior.
Actores: Usuario final (UF)
Precondiciones: El instalador ha sido creado con las caractersticas definidas por el
usuario final y el usuario creador.
Poscondiciones: Se llevar a cabo la instalacin.
Pasos:
1. UF: Hace doble clic sobre el fichero auto-ejecutable de la instalacin.
2. Sistema: Descomprime los archivos a copiar, lleva a cabo la instalacin y gestiona
la eliminacin de los archivos que fueron necesarios durante el proceso.
34
4.2.3. Diagrama de casos de uso
Figura 6: Diagrama de casos de uso
35
4.3. Diseo
En este apartado se describirn las soluciones y los procedimientos que se van a adop-
tar para satisfacer los requisitos descritos en el anlisis, referentes a la aplicacin que
estamos desarrollado: el creador de instaladores. La solucin propuesta ser vlida so-
lo para algunos de los sistemas operativos ms recientes de Windows.
Esta solucin est basada en la construccin de dos clases Java: Creador_instaladores

y Construct. La primera clase es la que contiene al mtodo main, por lo que deber ha-
cer referencia a la clase Construct (cuyos mtodos servirn para llevar a cabo la ejecu-
cin completa del programa) y ser la encargada de dirigir el flujo principal del progra-
ma. Adems, esta clase tendr que leer los datos que se encuentren en el fichero
Instalador.xml, los cuales definirn la configuracin de la instalacin que haya elegido
el usuario creador. Por otro lado, la clase Construct se encargar de la construccin,
compilacin y ejecucin de los ficheros necesarios para poner en marcha el instalador.
Estas dos clases sern descritas con mucho ms detalle posteriormente en esta
seccin.
La filosofa de trabajo consiste en la creacin y compilacin del cdigo necesario a par-

tir de estos ficheros iniciales para conseguir la construccin del instalador, en forma de
archivo auto-extrable fcilmente utilizable por el usuario final. Esto significa que los fi-
cheros descritos hasta ahora elaborarn otros ficheros y archivos extra, cuya compi-
lacin y ejecucin dar lugar a la ejecucin del instalador definitivo. A pesar de que el
lenguaje de programacin preferido para realizar este proyecto es Java (debido a que
es fcil de compilar y ejecutar, adems de ser muy conocido), el lenguaje del cdigo
generado variar en funcin de la necesidad o la comodidad de lo que se quiera hacer
en cada momento: cuando una tarea sea inviable o muy difcil de realizar en Java, se
crear cdigo en otros lenguajes de programacin que nos proporcionen alternativas
posibles o ms sencillas con el fin de conseguir su ejecucin sin ms problema. Adems
del lenguaje Java (el predeterminado), se utilizar C++ y el propio lenguaje de la shell
de Windows (pudindose de este modo construir archivos .bat, ejecutables por lotes).
Adems de estos archivos, se debern aportar otros tres ms para obtener la correcta
y completa ejecucin del proyecto. Uno de ellos ya ha sido mencionado: el
Instalador.xml, que se encargar de recoger la informacin de la configuracin de la
instalacin definida por el usuario creador. Puesto que es el propio usuario creador el
que debera encargarse de su edicin, debido a nuestra decisin de no implementar
ninguna interfaz para este usuario, nos veremos obligados a incluir en nuestra aplica-
cin una plantilla (de nombre plantilla.xml) que muestre con la mayor fidelidad posi-
ble la estructura del XML asociado a este archivo (la cual se describe con los ficheros
Instalador.dtd e Instalador.xsd, y con el esquema XML-Schema correspondiente).
36
Otro archivo extra que se incluir es el llamado Make.bat, archivo ejecutable por
lotes de Windows que aadir al CLASSPATH las rutas requeridas para que se ejecute
el programa, ejecutar los archivos iniciales antes descritos (Creador_instaladores.class
y Construct.class) y completar la ejecucin de algunas tareas de creacin y compre-
sin de archivos necesarias para la creacin del archivo que llevar a cabo la instala-
cin definitiva.
El tercer archivo, InterfazGrafica.java, proporcionar el cdigo fuente de la interfaz

del usuario final. Este cdigo se encargar de guardar en las variables de la clase
Instalador la informacin introducida por el usuario que ejecuta el instalador, de modo
que le permitir cambiar algunos aspectos de la configuracin elegida por defecto por
el usuario creador del instalador de forma cmoda. La clase InterfazGrafica se compila-
r a la vez que la clase Instalador, por lo que no es necesario incluir en la carpeta de
nuestra aplicacin los ficheros binarios referentes a la clase InterfazGrafica.
Sin ms dilacin, pasemos a estudiar con ms detenimiento las funciones desempea-

das por las clases mencionadas, as como las de los archivos construidos a partir de
ellas.
4.3.1. Descripcin de la clase Creador_instaladores
Clase que contendr al mtodo principal y leer los datos almacenados en el fichero
Instalador.xml. Por esto ltimo, es necesario que importe las libreras org.jdom,
org.jdom.input y org.jdom.output. Adems, usar la clase SAXBuilder con el fin de car-
gar en memoria el rbol de elementos del fichero XML que necesita leer.
Despus de cargar el XML, la clase gestionar la lectura de los datos pertinentes. stos
sern almacenados en diferentes variables para ser utilizados posteriormente en el
constructor de la clase Construct. Una vez creado un objeto de esta clase, se invocar a
los mtodos que posea, ya que stos sern los encargados de construir el cdigo del
instalador y del desinstalador, as como del resto de archivos que se precisan para
compilarlos, comprimirlos, ejecutarlos, etctera.
Los mtodos de esta clase se describen a continuacin:

leerOrigen (Document) devuelve List: devuelve una lista que contiene a los archi-
vos que se desean instalar, as como la ruta dentro del directorio de instalacin en
la que se copiarn, el icono asociado a su acceso directo (si existe) y el paquete de
archivos al que pertenecen (en caso de que se declare).
leerDestino (Document) devuelve String: devuelve la ruta por defecto en la que el
directorio de la instalacin ser creado.
leerInstalador (Document) devuelve String: devuelve el nombre que tendr el
instalador.
leerPrograma (Document) devuelve String: devuelve el nombre que tendr por de-
fecto el grupo de programas dentro del men Inicio en el que se crearn los acce-
sos directos del programa que se instalar. Adems, tambin ser el nombre que
recibir la carpeta de instalacin.
37
incluirPrograma (Document) devuelve String: devuelve Yes si el usuario creador
desea ordenar por defecto la creacin de un grupo de programas en el men Inicio
en el que incluir accesos directos; No, en otro caso.
leerUsuarios (Document) devuelve String: devuelve Yes si se desea que la aplica-
cin se instale por defecto para todos los usuarios del equipo; No, si tan solo se
requiere para el usuario que ha iniciado la sesin.
leerDesinstalador (Document) devuelve String: devuelve la ubicacin del icono
con el que se representar el acceso directo del instalador. En caso de que el usua-
rio creador no haya definido ningn icono para el desinstalador, devolver null.
leerRegistro (Document) devuelve List: devuelve una lista con toda la informacin
relativa a la modificacin que se har del registro una vez haya sido iniciada la
instalacin.
leerEjecutables (Document) devuelve List: devuelve una lista con los ejecutables
que se debern inicializar una vez finalizada la instalacin. Estos ejecutables pue-
den ser instalaciones de programas complementarios, ficheros de texto (estilo
readme), etc. Para cada ejecutable, se incluye el programa con el que se deben
abrir dichos archivos (si fuese necesario).
4.3.2. Descripcin de la clase Construct
Esta es la clase ms importante de la aplicacin. Sus funciones son las que a continua-
cin se muestran:
Generar el cdigo de los archivos Instalador.java y Desinstalador.java.

Generar el ejecutable .exe que comprimir todos los archivos y ejecutar la instala-
cin. Para ello, crear complementariamente un archivo que colabore en la crea-
cin del ejecutable: temp.bat.
Generar los ficheros manifest. Estos ficheros son muy tiles cuando se van a cons-
truir ficheros .jar que contendrn las clases que se ejecutarn. Su funcin es indicar
cul es la clase que contiene el mtodo principal para que sea ejecutada cuando se
invoque al jar (bien mediante doble clic o por lnea de comandos).
Compilar los archivos Instalador.java y Desinstalador.java. Esto provocar la apari-
cin de dos ficheros .class, con el cdigo binario de estas dos clases.
Generar el archivo install.properties, necesario para guardar las preferencias de ins-
talacin del usuario final. Esto permitir al desinstalador encontrar la informacin
necesaria para revertir los cambios producidos en el sistema durante la instalacin.
El archivo install.properties tambin servir para mostrar al usuario final los par-
metros de la instalacin elegidos por defecto por el usuario creador.
Vamos a describir qu hace exactamente cada mtodo de esta clase, comenzando por
el constructor.
38
Constructor:
Se encarga de recoger la informacin proveniente de la clase Creador_instaladores

y de almacenarla en las variables adecuadas. En primer lugar, construye una lista
que almacenar la informacin de los archivos que se usarn en la instalacin. Para
ello, usar varios vectores de datos:
-Un vector para almacenar qu archivos tendrn acceso directo en el grupo de pro-
gramas que se cree para la aplicacin durante la instalacin, otro para indicar cu-
les lo tendrn en el escritorio y otros tres ms para indicar lo mismo con respecto a
la carpeta de inicio, la carpeta de programas y la carpeta de aplicaciones, todas
pertenecientes al men Inicio. Estos vectores almacenarn un booleano por cada
archivo, que valdr true si el archivo va a tener un acceso directo en el lugar especi-
ficado y false en caso contrario. El orden de representacin de los archivos en estos
vectores coincidir con el que proviene de la lista definida en el constructor; de es-
ta forma, quedar completamente determinado qu booleanos harn referencia a
qu archivos.
-Un vector para almacenar la ruta (en formato String) de los iconos que se usarn
para los accesos directos de estos archivos. Los archivos para los que no se haya
definido ningn acceso directo llevarn un null en su correspondiente componente
del vector.
-Otro vector para indicar la ruta de los archivos dentro del directorio de instalacin.
Esta informacin es til en determinados casos para copiar archivos dentro de un
subdirectorio de la carpeta de instalacin. Nuevamente, si esta informacin no es
necesaria para un determinado archivo, su correspondiente componente en este
vector valdr null.
-Dos vectores ms para almacenar los paquetes de archivos que el usuario final
tendr la opcin de instalar y cules de esos paquetes se instalaran por defecto,
segn la decisin del usuario creador.
Tras esto, el constructor guarda en los atributos de la clase el resto de la informa-

cin de la configuracin del instalador: la ruta de la carpeta de instalacin, el nom-
bre del instalador, el nombre del grupo de programas del men Inicio relativo a la
aplicacin que se desear instalar (que ser el mismo que el que tenga la carpeta
de instalacin), para qu usuarios se instalar la aplicacin (todos o solamente el
que haya iniciado sesin), si se crear un nuevo grupo de programas para la aplica-
cin en el que incluir accesos directos, el icono que acompaar al acceso directo
del desinstalador (null si no existiese tal icono) y los programas que se ejecutarn
como complemento despus de la instalacin (instaladores externos, archivos
readme, etctera). Conviene recordar que algunos de estos parmetros no son de-
finitivos, pues sern revisados por el usuario final (el que ejecute la instalacin en
ltima instancia). Adems, el constructor elaborar a partir de esta informacin las
rutas dentro del sistema del men Inicio, del escritorio y de las carpetas de aplica-
ciones, inicio y del grupo de programas de la aplicacin dentro del men Inicio.
39
Por ltimo, el constructor construye las estructuras que almacenarn la informa-
cin sobre la modificacin del registro de Windows. Para ello, comprueba en pri-
mer lugar que el usuario desea modificar el registro a partir del atributo correspon-
diente al fichero XML ledo: si su valor es Yes, construir las estructuras necesa-
rias para almacenar esta informacin; si es No, terminar en ese momento su la-
bor. En caso de que se desee modificar el registro, el constructor contar con un
vector de cadenas de texto cuyas componentes guardarn los datos relativos a los
siguientes elementos y atributos del fichero Instalador.xml:
Componente Elemento Atributo Valor

0 Instalacion InstallDir Yes/No
1 Desinstalacion NoModify Yes/No
2 Desinstalacion NoRepair Yes/No
3 Desinstalacion DisplayVersion version
4 Desinstalacion DisplayIcon icon
5 Desinstalacion URLInfo url
6 Desinstalacion HelpLink help
7 Desinstalacion Publisher pub
8 Desinstalacion URLUpdate update
Tabla 1: Elementos y atributos para modificar el registro
Esto significa que las componentes 0, 1 y 2 podrn guardar los valores Yes o No
solamente, mientras que el resto almacenarn la cadena que contengan los ele-
mentos del XML indicados en la columna Valor.
El resto de la informacin referente a la modificacin del registro habr quedado

almacenada en un atributo de tipo List junto a lo que acabamos de describir y ser
tratada ms adelante en otros mtodos.
generarInstalador:
Su nica (aunque trascendental) funcin es elaborar el cdigo de la clase

Instalador. Es por eso que el mtodo usa una variable de tipo File, con la cual crea
el fichero de nombre Instalador.java, y otra de tipo BufferedWriter asociada a la
anterior con la que escribe en el fichero que ha creado.
Estudiemos el cdigo que ejecutar la clase Instalador (es evidente que dicho cdi-
go depender de los datos de configuracin almacenados en la clase Construct y en
el fichero de configuracin install.properties, que veremos ms adelante). En pri-
mera instancia, su mtodo principal guarda los paquetes de archivos de instalacin
y genera los valores (true o false) del vector que determinar qu paquetes se ins-
talarn finalmente. Estos valores sern true al principio y nicamente se cambiarn
a false en el momento en el que el usuario final decida no instalar el correspon-
diente paquete. Lo ltimo que hace el mtodo principal es invocar a la interfaz gr-
fica con la que el usuario final interactuar y que veremos con ms detalle en el
apartado 4.3.6. Interfaz del usuario final.
40
La interfaz grfica llamar al mtodo instalar de la clase Instalador, una vez ha mo-
dificado los atributos de esta clase con los datos introducidos por el usuario final.
Inicialmente, el mtodo crea el directorio de instalacin con sus diferentes subcar-
petas: una con los archivos de la aplicacin, otra con los iconos de los accesos di-
rectos (de nombre Iconos) y otra con el desinstalador (de nombre Desinstalador).
Despus, extrae el fichero de configuracin de la instalacin install.properties del
archivo Instalador.jar y lo aade al jar del desinstalador, Desinstalador.jar, con el
nombre desinstall.properties. Acto seguido, procede a copiar los archivos pertinen-
tes en cada subcarpeta, comprobando antes qu paquetes de archivos deben insta-
larse: los iconos, en Iconos; el jar con el desinstalador, en Desinstalador; y el resto
de archivos definidos, en la subcarpeta restante. Para cumplir con todos estos co-
metidos, la clase cuenta con dos mtodos privados: copiarDirectorio y
copiarFichero, de modo que pueda crear o copiar cualquier directorio, incluyendo
sus subdirectorios y ficheros, de forma recursiva. Tras esto, crea los accesos direc-
tos. Para ello, necesita la ayuda de un programa externo, Shortcut.exe, que permite
la creacin de accesos directos desde la lnea de comandos. Este programa ofrece
muchas funcionalidades, por lo que dispone de muchos parmetros de entrada.
Nosotros usaremos tan solo tres: el que indica cul ser la ruta completa del acceso
directo (incluyendo el nombre), el de la ruta del archivo al que apunta el acceso di-
recto y el de la ruta en la que est situado el icono con el que se mostrar el
shortcut (si ste existiera). Puesto que estamos haciendo uso de un programa aje-
no al propio que se est ejecutando en Java (por tanto, en un hilo diferente del
proceso), hemos de obligar al sistema a esperar a la finalizacin del programa
Shortcut.exe para proseguir con la ejecucin del cdigo de la clase cada vez que se
cree un acceso directo.
Posteriormente, la clase Instalador procede con la modificacin del registro de

Windows. Para ello, necesita hacer varias llamadas al sistema, bien para crear nue-
vas entradas en el registro o para cambiar las ya existentes en l. Con este fin, los
parmetros que nuestra aplicacin pasa a la lnea de comandos son: la ruta y la cla-
ve del registro que se modificar, el valor (en forma de cadena de texto) que ten-
dr dicha clave y el tipo de dato que representa al formato del valor asignado a la
clave (por defecto, REG_SZ). Al igual que pasaba con los accesos directos, la llama-
da al sistema implica la ejecucin de un nuevo hilo dentro del proceso, por lo que
vuelve a ser necesario esperar a su finalizacin para continuar con la ejecucin del
cdigo de la clase.
Lo mismo sucede con los ejecutables (instalaciones externas, etctera) que se pon-
drn en marcha tras la instalacin: habr que esperar a que termine su ejecucin.
Este ser el ltimo deber de la clase Instalador.
41
Es preciso indicar que los archivos y accesos directos que se crean, as como la mo-
dificacin del registro, dependen de la informacin almacenada en los vectores de-
finidos por el constructor. No obstante, los datos del registro que el usuario crea-
dor define libremente (relativos al elemento customize del fichero XML) y los pro-
gramas que se ejecutan tras la instalacin (provenientes del elemento ejecutable
de Instalador.xml) no quedan recogidos en ningn vector. Esta informacin, que es
almacenada en dos estructuras de tipo List en el constructor, ser extrada directa-
mente de estas listas en el mtodo generarInstalador que acabamos de estudiar.
La razn por la que se ha tomado esta decisin es que las cadenas de texto almace-
nadas se escribirn sin ningn tipo de tratamiento adicional en el fichero
Instalador.java, por lo que no se necesita de ninguna estructura que las recoja. Es-
to no sucede con los dems datos, debido a motivos de comodidad durante el de-
sarrollo de la programacin o al tratamiento y mutacin de la informacin que
representan.
Hay que recordar que aquellos parmetros que puedan ser modificados por el
usuario final no se escribirn de forma directa en el fichero Instalador.java, sino
que sern parametrizados por diferentes variables que lean en tiempo de ejecucin
la informacin almacenada en el fichero de configuracin que se cre a tal efecto.
Los mtodos que se encargan de dar valores a los atributos de la clase Instalador
sern invocados por la interfaz grfica cuando el usuario final inicie la instalacin.
generarDesinstalador:
Mtodo que genera el fichero Desinstalador.java. Evidentemente, se trata del fi-

chero que contiene a la clase Desinstalador, la cual posee un mtodo cuya labor se-
r eliminar del sistema todos los archivos y registros creados por la clase Instalador
relativos a la aplicacin instalada. Al igual que ocurra con el mtodo
generarInstalador (as como con los dems mtodos que faltan por describir), este
mtodo usa una variable de tipo File, con la cual crea el fichero de nombre
Desinstalador.java, y otra de tipo BufferedWriter asociada a la anterior, con la cual
escribe en el fichero que ha creado de acuerdo a la configuracin establecida por el
usuario creador del instalador.
El mtodo principal se encarga de cargar el fichero desinstall.properties que recoge

la informacin que necesita el desinstalador para revertir los cambios producidos
por el instalador y de recoger esta informacin en los atributos de la clase. Por otro
lado, tambin muestra al usuario final una interfaz para confirmar la desinstalacin
y que le permita indicar si desea que se elimine el directorio de instalacin junto
con los archivos del desinstalador. Esto se recoge en una variable de tipo booleano,
que a su vez se pasa como parmetro al mtodo desinstalar, que es el encargado
de llevar a cabo la desinstalacin propiamente dicha.
42
El mtodo desinstalar borra, en primer lugar, todas las carpetas y archivos creados
previamente durante la instalacin de forma recursiva (de modo que es capaz de
eliminar todas las subcarpetas sin tener que hacer referencia a cada una de ellas
explcitamente en el cdigo). Para ello, se ayuda del mtodo recursivo
borrarDirectorio. Este mtodo recibe como parmetro la ruta de un directorio y
elabora una lista con los archivos y directorios que posee. Despus, va recorriendo
uno a uno los elementos de esta lista, de modo que si es detectado como un archi-
vo, lo borra directamente, y si es un directorio, se invoca a s mismo envindolo co-
mo parmetro.
Tras esto, el mtodo principal se encarga de eliminar las claves del registro relacio-
nadas con la aplicacin que se est desinstalando. Tanto estas claves como los ar-
chivos anteriores se han podido detectar gracias a los vectores atributos de la clase
Construct que fueron definidos en el constructor, as como al fichero de configura-
cin creado previamente.
Por ltimo, si el usuario final as lo quiso, el mtodo desinstalador invoca al mtodo

forzarEliminacion, que es utilizado para borrar la carpeta de instalacin cuando se
han eliminado todos los archivos y subcarpetas que contena, a excepcin del fiche-
ro Instalador.jar y las carpetas en las que se encuentra. La estricta necesidad de es-
te mtodo se debe a que un fichero Java (como Instalador.jar) no puede eliminarse
a s mismo (tendra que cerrarse primero), por lo que se ha de recurrir a la creacin
de un archivo bat (ejecutable por lotes) capaz de auto-borrarse y que, a su vez, bo-
rre a los directorios anteriores; si simplemente intentramos borrar recursivamen-
te la carpeta de instalacin, los archivos que estuvieran abiertos no se podran eli-
minar. De este modo, forzarEliminacion crea un fichero de nombre destruir.bat en
el directorio C:\ que, por este orden,
o Mientras exista, intenta borrar (y al final, borra) el fichero Desinstalador.jar.

o Borra la carpeta contenedora de Desinstalador.jar, Desinstalador.
o Borra la carpeta de instalacin.
o Se borra a s mismo.
Tras la construccin de este archivo, el mtodo forzarEliminacion hace que se eje-

cute en la lnea de comandos. Dicho mtodo finaliza cuando se ha hecho efectiva
esta ltima accin.
Cabe recordar que, al igual que ocurra con el mtodo generarInstalador, ste tam-
poco escribe directamente los parmetros configurables por el usuario final en el
fichero Desinstalador.java; en su lugar, crea variables que harn referencia a esa
informacin, de modo que la clase cuente con ella en tiempo de ejecucin.
generarEjecutable:
Mtodo que genera el ejecutable .exe que comprimir todos los archivos y ejecuta-
r la instalacin cuando el usuario final ponga el fichero auto-ejecutable en funcio-
namiento mediante doble clic.
43
En primer lugar, el mtodo crea un fichero de nombre arch.cpp. ste comprobar
cuando se inicialice la instalacin si est instalada en el equipo alguna versin de la
mquina virtual de Java, de modo que, de no ser as, instale la Versin 6
Actualizacin 18 en este equipo (detenindose la instalacin hasta que este proce-
so termine). Tras esto, iniciar la instalacin, ejecutando el Instalador.jar.
Despus, se genera el archivo temp.bat, que ejecutar el resto de comandos para

construir el ejecutable final: aadir al path la ruta del programa para comprimir
los archivos (que ser el 7-Zip), compilar el archivo .cpp creado anteriormente (el
programa ejecutable resultante de la compilacin se llamar Setup.exe), crear los
jars correspondientes al instalador y al desinstalador (incluyendo como parmetro
los ficheros de manifiesto que se habrn elaborado), crear un fichero comprimido
que incluya a todos los archivos necesarios para la instalacin (de nombre
InstallFiles.7z), eliminar los archivos aadidos al fichero comprimido, crear el eje-
cutable final y borrar el .7z y a l mismo.
La razn por la que se eligi el 7-Zip como programa de compresin de los archivos
se debe a la posibilidad que ofrece de crear un archivo auto-ejecutable y auto-
extrable desde la lnea de comandos. Para la correcta ejecucin de este proceso,
es necesaria la existencia de un par de archivos en el mismo directorio de la aplica-
cin que estamos desarrollando: el 7zS.sfx, para crear el auto-extrable, y el
config.txt, donde se le indica al auto-extrable cul es el fichero que debe ejecutar
(en nuestro caso, el Setup.exe, consecuencia de la compilacin del archivo
arch.cpp). Por otro lado, la explicacin de por qu se determin utilizar el lenguaje
de programacin C++ a la hora de componer el arch.cpp se debe a las facilidades
que proporciona C++ para crear archivos ejecutables (algo que en Java es ms
complicado).
generarManifest:
Los ficheros de manifiesto, o manifest, sirven para ejecutar una aplicacin Java
comprimida en un jar. Estos ficheros contienen el nombre de la clase que contiene
al mtodo principal (es decir, la que debe ejecutarse). El mtodo generarManifest
se encarga de la elaboracin de estos ficheros de manifiesto, as como de la compi-
lacin de los ficheros Instalador.java y Desinstalador.java a los que hacen
referencia.
generarInstallConfig:
Crear el fichero de configuracin; lo que escriba en l depender en primera ins-

tancia de la configuracin que haya elegido inicialmente el usuario creador. Este fi-
chero permitir a la postre que el usuario final sea capaz de cambiar la configura-
cin decidida por el usuario creador (pues no tendr por qu coincidir con la suya).
Todas las claves presentes en este fichero tomarn, en un primer momento, los va-
lores recogidos en la clase Instalador a excepcin de la relativa a los accesos direc-
tos en el escritorio, que tomar siempre por defecto el valor true. Las claves y su
descripcin quedan recogidas en la siguiente tabla.
44
Clave Descripcin
<Nombre_paquete> Paquete a instalar. Puede haber 10 a lo sumo. Tomar valor true
si se desea instalar y false en caso contrario.
Ruta Ruta dentro del sistema en la que se ubicar la carpeta de
instalacin.
Programas Nombre de la carpeta de instalacin y del grupo de programas
de la aplicacin, en caso de que se acabe creando.
Todos Usuarios para los que ser vlida la instalacin. Tomar valor
true si es para todos los usuarios y false en caso contrario.
Inicio Especifica si se crear un nuevo grupo de programas para la apli-
cacin. Tomar valor true si el usuario desea crearlo y false en
caso contrario.
Escritorio Especifica si se crearn accesos directos en el escritorio. Tomar
valor true si as se desea y false en caso contrario. Su valor por
defecto siempre ser true.
Tabla 2: Claves del fichero de configuracin y su descripcin
4.3.3. Descripcin del archivo Make.bat
En los anteriores mtodos hemos creado un archivo, temp.bat, pero en ninguno de

ellos lo hemos ejecutado. Adems, hemos usado cdigo en C++, pero en ningn mo-
mento hemos aadido al path ningn programa que sea capaz de compilarlo. Por otro
lado, el usuario creador del instalador necesitara ejecutar de una manera sencilla la
clase Creador_instaladores, con el fin de, una vez definida la configuracin de la insta-
lacin, crear el archivo auto-ejecutable (y auto-extrable) correspondiente. Pues bien,
esas sern las funciones del archivo Make.bat: lo nico que tendr que hacer el usua-
rio creador para construir su instalador es hacer doble clic sobre este archivo. Estar si-
tuado en el mismo directorio de la aplicacin desarrollada (junto, por ejemplo, a los ar-
chivos Config.txt y 7zS.sfx del programa 7-Zip).
45
4.3.4. Relaciones entre los archivos de la aplicacin
La siguiente ilustracin (Figura 7) muestra todas las relaciones que se darn entre los
diferentes archivos que formarn parte del proceso de creacin del instalador.
Figura 7: Diagrama de colaboracin entre los ficheros de la aplicacin
4.3.5. Interfaz del usuario creador

Descripcin
El medio mediante el que el usuario creador podr construir su instalador consistir en

un fichero XML que deber ser acorde al XML-Schema representado por el siguiente
esquema (Figura 8).
46
Figura 8: XML-Schema del fichero Instalador.xml
Este otro esquema (Figura 9) recoge la informacin detallada del elemento del XML
lugaresInstalacion presente en el esquema general anterior.
Figura 9: XML-Schema del elemento lugaresInstalacion
47
Para mayor comodidad, el usuario creador dispondr de una plantilla escrita en len-
guaje XML cuyo contenido ser vlido para el XML-Schema anterior. Las modificacio-
nes introducidas por el usuario creador al editar dicho fichero (que deber nombrarse
como Instalador.xml) debern seguir respetando la especificacin del XML-Schema
aqu descrito.
Es necesario indicar que se consider seriamente dentro de este proyecto la realiza-

cin de una interfaz que permitiera al usuario creador construir su instalador sin nece-
sidad de escribir ninguna lnea de cdigo XML, pero finalmente se desech debido
principalmente a dos razones:
Las mejoras que se obtendran en caso de implementar la interfaz no compensan el

gran esfuerzo que supondra su creacin. Hay que tener en cuenta que habra que
crear pantallas que permitieran al usuario la creacin de accesos directos, la posibi-
lidad de modificar el registro de Windows, indicar qu archivos se copiarn en el di-
rectorio de instalacin lo cual se puede indicar de un modo mucho ms sencillo (y
de una sola vez) en el fichero XML.
Adems, no es descabellado suponer que el usuario creador tendr los conocimien-
tos necesarios para editar sin problemas un fichero XML con las caractersticas des-
critas, por lo que la solucin adoptada no supondra un contratiempo demasiado
importante para l.
Precondiciones
El usuario creador encontrar a su disposicin un fichero de nombre plantilla.xml que

cumplir las especificaciones definidas en el archivo Instalador.xsd e Instalador.dtd.
Por tanto, el cdigo XML incluido en este archivo ser acorde al esquema mostrado an-
teriormente en este documento.
Adems, el usuario creador encontrar un pequeo manual de instrucciones que le

permita editar adecuadamente el fichero Instalador.xml y trabajar con el programa.
Poscondiciones
Las modificaciones introducidas por el usuario creador al editar el anterior documento

debern respetar la especificacin del XML-Schema descrito.
Por otra parte, la aplicacin deber recoger la informacin introducida por el usuario
creador y guardarla con el fin de mostrarla al usuario final para que pueda ser modifi-
cada (en unos casos) o usarla directamente como parmetro cuando se construya el
instalador (en otros).
Las caractersticas que deber tener el fichero Instalador.xml una vez haya sido edita-
do estn definidas en el manual de instrucciones del creador de instaladores, el cual se
mostrar en el Anexo I de este proyecto.
48
Diagrama de estados
Figura 13: Diagrama de estados de la interfaz del usuario final

4.4. Implementacin
A continuacin, a lo largo de este apartado, se indicarn cules fueron las principales
dificultades que hubo que superar durante el desarrollo de este proyecto con respecto
a la implementacin de los requisitos segn la estrategia descrita en la fase de diseo,
tanto relativas a la programacin como a las tcnicas especficas empleadas.
En primer lugar, es conveniente comentar que solamente encontrar un diseo adecua-

do para la construccin del creador de instaladores fue un tarea, de por s, compleja,
ya que requiri, desde el primer momento, el estudio del cdigo de otros creadores de
instaladores (como IzPack), as como de las funcionalidades que son capaces de ofre-
cer. Algunas de las soluciones y tcnicas adoptadas en este software fueron tenidas en
cuenta a la hora de construir nuestra aplicacin; sin embargo, la mayora de las ideas
empleadas en la elaboracin del proyecto son completamente originales y son fruto
de la investigacin surgida a raz de los intentos de implementacin de cada requisito.
Es decir, la construccin de gran parte de la aplicacin se debe a un proceso que bien
puede dividirse en dos partes:
1. Estudio del siguiente requisito que se implementar.

2. Obtencin del diseo de la implementacin de este requisito, basada en la in-
vestigacin y en el estudio de la situacin.
En las siguientes lneas especificaremos con detalle los problemas encontrados y las
soluciones que se llevaron a cabo para solventarlos, as como los aspectos ms impor-
tantes a destacar con respecto a la implementacin.
Una de las principales dificultades que se tuvieron que afrontar (adems, de modo
constante) fue todo lo relacionado con las rutas del PATH y del CLASSPATH, debido,
sobre todo, al desconocimiento que tena acerca de ellos al iniciar el proyecto y a la
falta de experiencia con respecto a su manejo y sintaxis. Esto provocaba que, cada
vez que quera ejecutar una clase Java ubicada en cualquier directorio del sistema
o cualquier programa necesario para el correcto funcionamiento de la aplicacin,
acabara obteniendo un error.
Finalmente, la ruta del PATH se modific en el fichero Make.bat con el fin de poder
utilizar el programa Dev-Cpp para la compilacin y ejecucin del cdigo C++ utiliza-
do en la aplicacin, adems de en el fichero temp.bat para la ejecucin del progra-
ma 7-Zip para la comprensin de los archivos de la instalacin y la creacin del fi-
chero auto-ejecutable. Por su parte, la ruta del CLASSPATH se cambi en el propio
Make.bat con el fin de localizar los .class de la aplicacin y el jdom.jar, necesario
para leer el fichero XML de configuracin.
54
Aunque menor, otro de los problemas que me encontr inicialmente fue la lectura
del fichero XML de configuracin. Como he comentado antes, esto se logr gracias
a JDom. Sin embargo, nuevamente el desconocimiento de esta herramienta provo-
c que aparecieran errores en la aplicacin, debidos sobre todo al hecho de que,
en determinadas ocasiones, trataba de leer subelementos del XML no existentes.
Por ejemplo, si no se inclua en el XML el subelemento desinstalador (porque no
se asignaba ningn icono al desinstalador) y la aplicacin trataba de leer dicho sub-
elemento, se produca un error.
Ante este problema se adoptaron tres posibles soluciones, que se pasan a describir
a continuacin:
o Mantener el subelemento en el XML con una cadena vaca de modo que la apli-
cacin pueda leerlo sin que se produzcan errores, aunque no proporcione nin-
guna informacin.
o Incluir en el elemento padre un atributo (de tipo Yes/No) que indique si hay
que tener en consideracin la informacin almacenada en sus hijos.
o Hacer que la aplicacin lea un subrbol del XML que incluya a los elementos
que puedan omitirse en determinadas ocasiones, de modo que sea la propia l-
gica de la aplicacin la que determine qu elementos son los que finalmente se
incluyen.
En funcin de la situacin, se eligi una solucin u otra, atendiendo principalmente

a la probabilidad de que el subelemento se pudiera omitir: si el subelemento iba a
quedar pocas veces vaco (como es el caso del icono del desinstalador), directa-
mente se recurra a la cadena vaca; si eran varios los subelementos que podan
omitirse, se optaba por el atributo en el elemento padre; en otro caso, se conside-
raba la tercera opcin (ntese que es la ms laboriosa, tanto para el programador
como para la mquina).
La utilizacin de ficheros jar para la ejecucin de los archivos Java compilados oca-
sion que se invirtiera cierto tiempo en investigar acerca de cmo ejecutarlos. Los
ficheros de manifiesto, que pueden entenderse simplemente como ficheros en los
que se indica cul es el archivo en el que se encuentra la clase que contiene al m-
todo principal, son los que subsanaron tal dificultad.
El instalador que se va a crear deber ser capaz de determinar para qu usuarios se

tiene que instalar el programa. Esta funcionalidad se implement mediante el uso
de System.getProperties(user.name), lo cual recoge el nombre del usuario ac-
tual del sistema operativo.
Otro gran problema fue la creacin de los accesos directos. Resulta sencillo crear
un acceso directo en Windows de modo directo (con el ratn, por ejemplo), pero
cmo crear un acceso directo de modo programado desde la lnea de comandos?
En Windows no existe ningn mandato que nos permita realizar tal cosa.
Los accesos directos son, en realidad, archivos que hacen referencia a otro archivo
situado en cualquier ubicacin, caracterizndose por tener extensin .lnk. No obs-
tante, es obvio que para crear un acceso directo no basta con aadir esta extensin
a un determinado archivo, sino que habr que referirse al directorio en el que se
encuentran el archivo base y el icono que representar tal acceso directo.
55
Tras largas horas de investigacin, la solucin vino dada por el uso de un programa
externo capaz de crear accesos directos desde la lnea de comandos, llamado
Shortcut.exe, al cual basta con introducirle como parmetros los comentados ms
arriba.
Una dificultad menor, pero difcil de solventar, es la que ocasionaba la eliminacin

del sistema del propio archivo de desinstalacin. Cmo borrar un archivo desde el
mismo archivo que debe ser borrado? Todo desinstalador que se precie debera ser
capaz de eliminar tambin los archivos relativos a la desinstalacin del programa,
incluidos ellos mismos.
Las pruebas e investigaciones iniciales mostraron que era poco probable que, bajo
cualquier circunstancia, un archivo jar se pudiera eliminar a s mismo, y que en ca-
so de que fuera posible, sera difcil de conseguir (habra que esperar a que el archi-
vo se cerrara, o bien cerrarlo nosotros mismos, antes de intentar eliminarlo). Por
tanto, la conclusin que se extrajo de esto fue que deba ser necesariamente otro
archivo el que se encargara de eliminar el archivo jar del desinstalador. Ahora bien,
del mismo modo, dicho archivo deba ser capaz de eliminarse a s mismo.
Pues bien, los archivos ejecutables por lotes de Windows (de extensin .bat) tienen
esta propiedad. Por ello, la solucin consisti en la creacin de un script que espe-
rara el tiempo necesario a que se cerrara el archivo jar de desinstalacin, procedie-
ra a borrarlo y despus, se auto-eliminara del sistema. Este script simplemente in-
tentaba borrar el archivo reiteradas veces hasta que ste se cerraba y lo lograba,
momento en el que proceda con su auto-eliminacin.
Hay que indicar que este script es ubicado durante la desinstalacin en el directorio
C:\, debido a que este directorio es muy probable que exista en el ordenador del
usuario final (se trata de la carpeta que contiene habitualmente los archivos del
disco duro de la mquina). Su nombre es destruir.bat.
No solo la eliminacin del propio desinstalador caus problemas. Tambin otros ar-
chivos intermedios necesarios para el correcto funcionamiento de la aplicacin que
deben ser borrados durante el proceso de instalacin ocasionaron contratiempos a
la hora de ser eliminados, debido de nuevo a que la propia aplicacin intentaba bo-
rrarlos antes de que se cerraran. Por razones desconocidas, con determinados ar-
chivos (no todos), la tctica de esperar hasta que stos se cerraran no funcionaba si
se programaba desde Java, por lo que se recurri a su eliminacin desde otro script
(en este caso, el temp.bat).
La modificacin del registro de Windows es otro de los problemas que hubo que
afrontar, no solo por el desconocimiento inicial acerca de para qu se utilizaba y
cmo se poda cambiar, sino tambin por el peligro que conllevaba realizar tal ac-
cin; es recomendable no cambiar ningn valor del registro de cualquier ordena-
dor, salvo que sea estrictamente necesario.
56
La aplicacin deba ofrecer dos maneras diferentes de modificar el registro: a gusto
del usuario o mediante guas, o pistas, que permitieran al usuario creador cambiar
aquellos registros que ms se suelen utilizar a la hora de realizar instalaciones de
programas. Puesto que lo primero se puede entender desde el punto de vista de la
programacin como una generalizacin de lo segundo (para modificar el registro,
hay que indicar siempre la ruta que se desea cambiar, el atributo a cambiar, el tipo
de dato que se introduce y el nuevo valor que tendr el atributo; y esos son los pa-
rmetros que se consideran en el segundo mtodo), hubo que reestructurar parte
del cdigo (ya que, al principio, no se pens en la posibilidad de modificar el regis-
tro a gusto del usuario), de modo que un mismo mtodo Java sirviera para insertar
en el registro datos mediante cualquiera de las dos opciones anteriores. El mtodo
Java que se encarga de tal tarea es la accin insertarEnRegistro.
Como mejora con respecto a ciertos creadores de instaladores, como IzPack, el

programa aade una nueva funcionalidad: es capaz de proporcionar al usuario final
un ejecutable en lugar de un simple archivo jar, de modo que si el usuario final tie-
ne instalada la JRE de Java en su equipo, el .exe ejecuta directamente el jar, y si no,
instala antes Java. Para lograr este objetivo, la aplicacin crea durante la instala-
cin un archivo C++, llamado arch.cpp, el cual comprueba si existe alguna versin
de la JRE de Java instalada en la mquina haciendo una llamada al sistema con el
mandato:
pid=system("java -version>nul 2>&1");
En caso de que exista alguna versin, system devolver el valor 0; en otro caso, de-
volver un valor distinto de 0. As, podremos distinguir de forma unvoca si real-
mente est instalado Java en el equipo mediante el valor de la variable pid. Note-
mos que el mandato java version muestra la versin actual de Java por consola y,
puesto que esto no debera ser ledo por el usuario final, hemos de redireccionar la
salida a nul.
Tras esto, y solo en caso de que no haya ninguna versin de Java instalada, el cdi-
go C++ ejecuta el instalador de la correspondiente JRE (en el caso de nuestro crea-
dor de instaladores, dicho instalador corresponde a la versin 6 Actualizacin 18).
Por ltimo, independientemente de si Java est instalado, el cdigo C++ ejecuta el
jar del instalador tras esconder la molesta consola que acompaa a sus programas.
Otro aspecto que hubo que corregir est relacionado con el subdirectorio de la car-
peta de instalacin en el que deban copiarse los archivos. En versiones primitivas
del creador de instaladores, los archivos de la instalacin no se podan copiar en
otro sitio que no fuera el directorio de destino, aunque hubiramos querido ubicar-
los en una subcarpeta de dicho directorio al tratarlos de forma individual (por
ejemplo, para hacer un acceso directo a ese archivo en concreto).
El error se corrigi aadiendo a la estructura del XML un subelemento ms al ele-

mento origen, llamado destino, en el cual se indica la ruta dentro del directorio
de destino en la que se va a copiar el archivo. La aplicacin guarda esta ruta en la
variable destShorcut, en caso de que exista en el XML (el subelemento destino
podra omitirse, en cuyo caso el lugar en el que se copia el archivo sera la propia
carpeta de instalacin).
57
La creacin del fichero auto-ejecutable que extrae los archivos de la instalacin y la
ejecuta requiri varias horas de investigacin. En un principio se pens que bastaba
con la creacin de un fichero jar que almacenara todos los archivos del programa
que se deban instalar y que ejecutara el instalador que tuviera dentro (lo cual se
habra podido conseguir con un simple doble clic, gracias a los ficheros de manifies-
to). No obstante, se reconsider tal idea, debido a que es posible que el usuario fi-
nal no tenga ninguna mquina virtual de Java instalada en su mquina, o aunque la
tenga, carezca de la nocin de lo que es un archivo jar.
El archivo auto-ejecutable se consigui gracias al programa 7-Zip, ya que permite

crearlo desde la lnea de comandos. Para construirlo, es necesario completar dos
pasos: creacin del fichero comprimido con los archivos requeridos durante la ins-
talacin y creacin del archivo auto-ejecutable. Para este segundo paso, adems de
conocer la sintaxis especfica del programa, es necesario disponer en la carpeta de
la aplicacin de dos archivos ms, sin contar el fichero de compresin creado en el
primer paso: el 7zS.sfx y el config.txt. ste ltimo fichero de texto es muy impor-
tante, ya que con l se especifica, entre otras cosas, el archivo que se debe ejecutar
nada ms descomprimir el fichero de extensin .7z. Ser el propio programa 7-Zip
el que se encargue de gestionar la eliminacin de los ficheros extrados una vez se
hayan utilizado tras la descompresin.
El continuo tratamiento con cadenas de texto indujo la confeccin de dos mtodos

Java que se encargan de modificar adecuadamente dichas cadenas con el fin de
que la aplicacin funcione sin errores. Estos mtodos son nombreFichero y
cambiarBarra. El primero recibe una ruta determinada y devuelve el nombre del fi-
chero al que hace referencia; este nombre coincidir con el token que se encuentra
en ltimo lugar, tras la ltima doble barra de la cadena inicial (\\). El segundo se
encarga de cambiar cualquier doble barra \\ que le llega en la cadena introducida
como parmetro por una barra simple (/), y es til para ejecutar el mandato espec-
fico que invoca al programa 7-Zip.
En cuanto a la interfaz de usuario, hay bastantes aspectos a destacar de su imple-

mentacin. Uno de ellos es la obtencin de todos los paquetes disponibles para
presentarlos ante el usuario final. Hay que tener en cuenta que los paquetes se
pueden repetir tantas veces como quiera el usuario creador y que pueden existir
archivos que no estn asociados a ningn paquete. Esto se traduce en que nuestro
cdigo se tendr que encargar de copiar en el archivo properties como claves solo
aquellos paquetes que no se hayan copiado ya en este archivo, sin incluir en l nin-
gn valor nulo (pues esa es la representacin de los archivos que no estn asocia-
dos a ningn paquete en el vector que recoge los nombres de los paquetes). El m-
todo que se encarga de esta labor es generarInstallConfig, perteneciente a la clase
Construct.
Otro aspecto a considerar con respecto a la interfaz es la forma de determinar qu

paquetes se instalarn finalmente y cules no. Para ello, contamos con que en la
clase Instalador disponemos de un vector que recoge el nombre de los paquetes
para cada archivo definido (null para el caso de los archivos que no pertenecen a
ningn paquete) y otro con valores booleanos que indica para cada archivo si se
instala o no.
58
Recordemos que un archivo que no tiene ningn paquete asociado se deber insta-
lar obligatoriamente, por lo que nuestra estrategia consistir en suponer inicial-
mente que todos los archivos se van a instalar (aunque la decisin del usuario crea-
dor sea diferente) para despus cambiar el valor del vector de booleanos en las
componentes correspondientes a los archivos cuyos paquetes no se instalarn por
decisin del usuario final. As, en el momento que se confirma la instalacin, la cla-
se InterfazGrafica busca nicamente aquellos paquetes que no se van a instalar y
sus nombres son pasados como parmetro al mtodo setInstPaq de la clase
Instalador para cambiar a false el valor de aquellas casillas del vector de booleanos
que cumplan que su archivo asociado pertenece al paquete introducido como
parmetro.
Pero sin duda, lo ms complejo de resolver con respecto a la interfaz es de qu mo-

do se podrn mostrar en ella los paquetes a instalar; no slo por los nombres tan
diversos que pueden tener, sino sobre todo por la cantidad indefinida de paquetes
que se pueden definir. Esta ltima circunstancia lleva a la necesidad de tener que
construir en la interfaz casillas de verificacin (checkboxes) para los paquetes de
manera dinmica (en tiempo de ejecucin) en caso de no declarar un nmero m-
ximo de ellos, pues a priori no sabemos cuntos se declararn en el fichero XML.
Sin embargo, debido al tamao limitado de la ventana de la interfaz grfica, cre
poco recomendable permitir la declaracin de un nmero ilimitado de paquetes,
por lo que finalmente se decidi acotar el nmero mximo de paquetes a 10, los
cuales son suficientes para llevar a cabo con xito la inmensa mayora de todas las
posibles instalaciones, adems de construir y aadir las casillas de verificacin a la
interfaz de manera esttica.
Una vez adoptada la decisin de acotar el nmero de paquetes, la solucin pasa

por construir 10 mtodos que aadan cada uno una casilla a la interfaz y por contar
cuntos paquetes hay exactamente de verdad. De esto ltimo se encarga el mto-
do contarPaquetes, el cual adems aade el nombre de estos paquetes a un vector
para facilitar su posterior gestin. Para determinar el nmero de paquetes, este
mtodo cuenta en realidad el nmero de claves del archivo de configuracin
install.properties diferentes a las que siempre aparecern, a saber: Ruta, Inicio,
Escritorio, Todos y Programas. Despus de todo esto, ser fcil determinar
los mtodos getCheck que sern invocados para aadir las correspondientes casi-
llas de verificacin a la interfaz del usuario final (tantos como paquetes hayan sido
declarados).
59
4.5. Pruebas
En este proyecto, debido a sus peculiaridades y a su modo de desarrollo, no ha habido
una nica fase de pruebas, sino que stas han tenido lugar cada vez que se ha disea-
do una solucin para cada nuevo requisito a implementar. En este apartado resumire-
mos los resultados de las pruebas que ms significativas resultaron, as como las modi-
ficaciones que causaron en el cdigo.
4.5.1. Pruebas de comprobacin de la funcionalidad
Estas pruebas se basaron simplemente en determinados cambios que se introdujeron

en el fichero XML de configuracin; los cambios que pueda introducir el usuario final
con respecto a la configuracin inicial son equivalentes a los que pueda introducir el
usuario creador del instalador.
Antes de esto, hay que indicar que el resto de pruebas realizadas tuvieron un resultado
satisfactorio. Fueron pruebas para comprobar que
El nombre que iba a tener el instalador era el deseado. Para ello, se modific el
atributo nombre del elemento instalador del fichero XML. Resultado: el archivo
auto-ejecutable que hace las veces de instalador tena como nombre el especifica-
do, con la extensin .exe.
Los archivos o directorios cuyas rutas se indicaban en el subelemento archivo del

XML y que formaban parte de la instalacin se copiaban en los lugares previstos.
Los accesos directos asociados a algunos de estos archivos se creaban en los luga-
res especificados en los atributos programas, escritorio, inicio, menuInicio
y aplicaciones del elemento origen del XML, as como que estos accesos direc-
tos iban acompaados por el icono cuya ruta quedaba especificada en el subele-
mento icono del elemento origen, siempre que se decidiera que el acceso di-
recto estuviera acompaado por algn icono.
En caso de que se quisiera copiar un archivo que tuviera necesariamente que estar
dentro de alguna carpeta que se hubiera creado en el directorio de la instalacin,
el archivo se copiaba en la ruta adecuada, la cual quedaba completamente deter-
minada por el subelemento destino del elemento origen del XML.
La carpeta de instalacin quedaba ubicada en la ruta que apareca en el subele-

mento destino del elemento lugaresInstalacion, y que esta carpeta tena el
nombre indicado en el subelemento programas del mismo elemento.
Se creaba un nuevo grupo de programas, con el mismo nombre que la carpeta de

instalacin, si el atributo incluir del elemento programas tena el valor Yes, y
que no se creaba en caso contrario.
60
Se modificaba adecuadamente el registro de Windows de acuerdo a los valores de
los atributos de los elementos instalacion y desinstalacion y al texto presente
en los subelementos del elemento desinstalacin en caso de que el valor del atri-
buto modificar del elemento registro fuera Yes, y que no se producan cam-
bios en el registro en caso contrario.
El registro de Windows tambin se modificaba correctamente, considerando la in-

formacin almacenada en el elemento customize, en caso de que existiera en el
fichero XML; es decir, que se cambiaba la ruta del registro indicada en el atributo
ruta, que el tipo del valor cambiado era el especificado en el atributo tipo
(REG_DWORD, en caso de que el valor de este atributo fuese la cadena vaca), que
la clave del registro modificada era la misma que el valor del atributo clave y que
el nuevo valor de esa clave coincida con el del atributo valor.
La instalacin era vlida para todos los usuarios del equipo en caso de que el atri-
buto todos del elemento usuarios valiera Yes, mientras que solo era vlida
para el usuario actual en caso contrario.
El icono que acompaaba al acceso directo del desinstalador se encontraba en la

ruta establecida por el subelemento icono del elemento desinstalador en caso
de que ste tuviera un valor distinto de la cadena vaca, y que el acceso directo ca-
reca de icono en otro caso.
Se ejecutaban los archivos e/o instaladores indicados en el elemento ejecutable,

en caso de que fuese necesaria su puesta en marcha tras completarse la instala-
cin, as como que su ejecucin tena lugar gracias al programa especificado en el
atributo prog del mismo elemento (que contendra a la cadena vaca en caso de
que en realidad no fuera preciso ningn programa).
La aplicacin soportaba que hubiera varios elementos del XML del mismo tipo (co-
mo es el caso de los elementos origen, customize y ejecutable) y que funcio-
naba correctamente atendiendo a la informacin residente en cada uno de ellos.
En pruebas realizadas en equipos diferentes al mo, la aplicacin funcionaba bien,

de modo que se actualizaban adecuadamente las variables del sistema PATH y
CLASSPATH y se ejecutaba la instalacin de la JRE de Java en caso de no disponer
de ella.
Como hemos indicado antes, la ejecucin de ciertas pruebas dieron lugar a la detec-
cin de algunos errores existentes en la aplicacin que tratbamos de desarrollar en
este proyecto. A continuacin, detallaremos tanto los fallos encontrados como la solu-
cin para corregirlos en ese momento.
61
Prcticamente cada vez que se tena la necesidad de que un fichero escribiera una
determinada ruta en otro fichero, o con menos frecuencia cuando el mtodo prin-
cipal tena que leer alguna ruta del fichero XML de configuracin, al ejecutar el ins-
talador apareca un error (en el primer caso) o ni siquiera se llegaban a compilar
correctamente los archivos Instalador.java o Desinstalador.java (en el segundo ca-
so). La causa del error era el tratamiento especial que en Java se le tiene que dar al
smbolo de la contrabarra (\), ya que se trata de un carcter especial, lo cual haca
que no sirviera introducir las rutas en su formato normal (en las que los directorios
aparecen separados por una sola barra invertida).
La solucin que se adopt consisti en aadir contrabarras adicionales a cada una

de las rutas que se escriban en los ficheros creados por la aplicacin, una por cada
fichero en el que se tuviera que escribir dicha ruta. Por ejemplo, si una ruta tena
que escribirse en dos ficheros durante el proceso de compilacin o ejecucin de la
aplicacin, era obligatorio escribir hasta 4 contrabarras entre directorio y directorio
con el fin de evitar tratar a este smbolo como un carcter especial.
Este problema no solo tuvo lugar con la barra invertida, sino tambin con cualquier
carcter especial en Java (las comillas, etctera). Para estos casos, la solucin fue
equivalente a la anterior.
Otro problema surgi con los espacios en blanco. En determinadas ocasiones, era
preciso introducir nombres de directorios o rutas completas como parmetros de
programas ejecutados desde la lnea de comandos (por ejemplo, el Shortcut.exe). Si
estos nombres o rutas tenan espacios en blanco, el programa fallaba, pues enton-
ces deberan haber estado encerrados entre comillas. Es evidente que dichos fallos
no fueron detectados hasta que esta clase de programas no se incorporaron al pro-
ceso de desarrollo, aunque se corrigieron de forma sencilla encerrando entre comi-
llas dichos nombres y rutas en los archivos Java correspondientes (aadiendo las
contrabarras que fuesen necesarias, segn el punto anterior, pues las comillas son
tratadas como caracteres especiales).
En el fichero XML de configuracin existen algunos elementos y atributos que no se

pueden omitir. Si as fuera, ocurrira un error en tiempo de ejecucin dentro de las
clases Instalador y Desinstalador, pues nuestra aplicacin tratar bajo cualquier cir-
cunstancia de leer sus valores, de forma que si no existiesen se producira una
excepcin.
Los encargados de que el fichero XML de configuracin est definido de modo co-
rrecto con el fin de preservar errores de este tipo en nuestra aplicacin es o bien el
fichero DTD o el fichero XML-Schema, ya que ambos estn asociados al XML con
ese fin. Pero, qu ocurrira si esos ficheros estuvieran mal diseados? Qu pasa-
ra si en ellos se declararan atributos opcionales que en realidad debieran ser obli-
gatorios? La respuesta es que el usuario creador de la instalacin podra dejar sin
incluir estos elementos o atributos en el XML sin que los ficheros DTD o XML-
Schema advirtieran nada, y an as producirse excepciones y errores en nuestra
aplicacin, algo no deseable.
62
Las pruebas que detectaron estos errores consistieron en omitir en el XML parte de
los atributos que, en un principio, eran considerados por el DTD y el XML-Schema
como opcionales. La solucin consisti en declarar como obligatorios aquellos atri-
butos que ocasionaban errores o excepciones por su omisin.
Otro error se produca al no declarar ningn icono para el acceso directo del des-
instalador. La forma de especificar esto en el fichero XML es dejar vaco el subele-
mento icono del elemento desinstalador. No obstante, cuando se haca esto, se
produca una excepcin en tiempo de ejecucin que, an as, no impeda que la
aplicacin se comportara de acuerdo a lo especificado (pues finalmente se cons-
trua el acceso directo).
Lo que produca este error, cuyas causas no fueron fciles de deducir, era en reali-
dad un error de programacin que describiremos en las siguientes lneas.
El atributo iconDesinst de la clase Construct.java recoge la ruta relativa en la que se

encuentra el icono que acompaa al acceso directo del jar del desinstalador, de
forma que, para detectar si se ha declarado algn icono que represente al acceso
directo del desinstalador, es necesario comparar su valor con la cadena vaca (pues
el subelemento icono del elemento desinstalador es obligatorio en el fichero
XML): tal icono existir si su valor es distinto de la cadena vaca. Pues bien, en el c-
digo realmente se comparaba su valor con el de null, y puesto que null es distinto
que la cadena vaca, la aplicacin intentaba crear el acceso directo (con el consi-
guiente error). Una vez corregida la errata, todo funcion del modo apropiado.
Por ltimo, apuntaremos en las siguientes lneas un comportamiento inesperado

de nuestra aplicacin que tuvo lugar al probar la creacin de la instalacin de un
programa desarrollado por Jnathan Heras, miembro del Departamento de Mate-
mticas y Computacin de la Universidad de La Rioja. Este comportamiento consis-
ta en que, durante unos segundos despus de completarse la instalacin del pro-
grama en cuestin, aparecan en el escritorio (lugar en el que se precisaba la crea-
cin de un acceso directo a un archivo del programa) hasta 3 accesos directos igua-
les. No obstante, tras esos instantes, desaparecan los accesos directos sobrantes.
El resto de requisitos se cumplan en este caso.
Hasta la fecha no se ha encontrado una explicacin a este fenmeno. Sin embargo,

hay que apuntar que slo se ha producido en el ordenador del miembro colabora-
dor (en el que, por cierto, ya estaba previamente instalado el programa, algo que
jams ocurrira en una situacin normal).
No solo se han realizado pruebas con esta aplicacin (fKenzo). Tambin se ha tra-
bajado con el programa TutorMates de Addlink Research, S.L. Recordemos que es
posible que nuestro programa sea el encargado de construir el instalador de esta
aplicacin en un futuro.
63
4.5.2. Pruebas de la interfaz de usuario
Las pruebas para comprobar el correcto funcionamiento de la interfaz de usuario

se centraron en comprobar que la informacin introducida en ella se tena en cuen-
ta a la hora de realizarse el proceso de la instalacin, en que era capaz de mostrar
la configuracin elegida por defecto por el usuario creador y en que al desinstala-
dor se le proporcionaba realmente la informacin adecuada para revertir los cam-
bios producidos por el instalador. La mayor parte de estas pruebas resultaron satis-
factorias; en las siguientes lneas explicaremos los problemas que surgieron con las
restantes y las soluciones que se adoptaron para solucionarlos.
Las contrabarras volvieron a plantear dificultades en la implementacin de la inter-

faz. En esta ocasin, provocaban que el archivo destruir.bat necesario para borrar
el directorio de instalacin no actuara del modo correcto. En concreto, lo que ocu-
rra consista en que se escriban en este archivo rutas en las cuales parte de algu-
nos de sus directorios se separaban mediante doble barra, cuando deban escribir-
se con barra simple para que los mandatos funcionaran bien. Esto se deba a que,
por la necesidad de escribir esas mismas rutas en otros archivos, se requera que
estuviesen separados sus directorios por la doble contrabarra.
La solucin que se adopt fue recoger en una variable la ruta con sus directorios
separados por una sola contrabarra y escribir esta representacin de la ruta en el
archivo destruir.bat. Dicha representacin poda conseguirse de forma inmediata
leyendo la ruta directamente del fichero de configuracin install.properties.
El fichero properties tambin ocasion varias dificultades. Una de ellas era la ob-
tencin de sus claves para mostrarlas debidamente en la interfaz de usuario. Resul-
ta que al leer una clave formada por varias palabras de un archivo de propiedades
mediante el mtodo keys(), se devuelve nicamente la primera palabra de la clave
(ignorndose el resto). Esto haca que el nombre de los paquetes no se mostrara de
forma correcta en la interfaz y que se perdiera informacin en el proceso de insta-
lacin de los paquetes.
La solucin consisti en escribir el nombre de los paquetes en el archivo de propie-

dades separando las palabras que lo conformaban por guiones bajos _ en lugar de
por espacios en blanco. Despus, el mtodo cambiarBarraBaja de la clase
InterfazGrafica se encargara de hacer los cambios necesarios con el fin de que los
nombres de los paquetes se mostraran separados por espacios en blanco. Esa es la
razn por la cual nunca deberamos nombrar a un paquete con barras bajas.
64
Pero el contratiempo ms importante con respecto al archivo de propiedades fue
el hecho de que, por alguna razn, se aada al jar del desinstalador antes de que
fuera modificado con los cambios producidos por el usuario final tras ejecutar el
instalador, haciendo que el desinstalador nunca obtuviera los parmetros correc-
tos para revertir los cambios en el sistema. Tras algunas pruebas, se comprob que
este error no suceda si los datos del archivo de configuracin se guardaban en otro
archivo distinto al inicial, el install.properties. A este nuevo archivo se le denomin
desinstall.properties, y es realmente este fichero de propiedades el que va a usar
siempre el desinstalador para obtener los datos de la instalacin y llevar a cabo la
desinstalacin de manera correcta.
Por ltimo, apuntaremos que al ejecutarse la interfaz grfica apareca siempre al

fondo y en segundo plano una consola vaca que permaneca abierta durante todo
el proceso de instalacin, hasta el momento en el que sta terminaba. La consola
apareca como consecuencia de la ejecucin del archivo Setup.exe, escrito en C++,
aunque en un principio se pensara que el responsable de que se mostrara era Java.
Puesto que no es deseable la aparicin de tan molesta e innecesaria consola, se to-

m la decisin de tratar de ocultarla despus de la posible instalacin de la JRE de
Java (de la cual tambin se encarga el programa Setup.exe), pues la aplicacin s
que usa la ventana para informar al usuario durante este proceso. El cdigo en C++
que nos proporcion la solucin es el siguiente:
HWND hide;
AllocConsole ();
hide = FindWindowA("ConsoleWindowClass",NULL);
ShowWindow (hide, 0);
Para la ejecucin de este cdigo, es necesario incluir el paquete windows.h de C++.
65
4.6. Gestin del proyecto
Tras la finalizacin del proyecto, podemos decir que se han cumplido los plazos previs-
tos para su entrega, pero no la realizacin del nmero de horas estimado para su ela-
boracin. Es decir, a pesar de que finalmente no ha habido ningn retraso, de forma
paradjica tampoco se ha invertido el tiempo total previsto para la realizacin del PFC
(se ha pasado de dedicarle 540 horas a unas 305; esto es, un poco ms de la mitad).
La explicacin a este hecho radica en la planificacin que se ha seguido durante el de-

sarrollo de nuestra aplicacin, consistente en dos pasos sucesivamente repetidos: es-
tudio de una nueva funcionalidad del creador de instaladores IzPack e implementacin
de la misma. As, puesto que las horas invertidas no alcanzan a las planificadas inicial-
mente, se ha obtenido una aplicacin cuyas prestaciones son menores de lo que se es-
peraba, pues no satisface todos los requisitos que cumple IzPack (porque no ha dado
tiempo a estudiarlos e implementarlos todos). En resumen, se ha completado la labor
que se ha podido realizar en el tiempo estipulado al comienzo del proyecto, hasta lo
que ha dado tiempo a hacer.
Esto no quiere decir que el proyecto sea deficiente en algn sentido. Las funcionalida-
des que se han implementado representan el grueso de la aplicacin, sus entresijos,
siendo por tanto la parte ms difcil del desarrollo. Esto significa que lo no implementa-
do se refiere a detalles de menos importancia en referencia a la programacin, tales
como:
Pantallas de presentacin y cierre de la instalacin.

Incorporacin de una barra de progreso en los procesos de instalacin y desinstala-
cin que informe al usuario del grado de avance en el que se encuentran.
Posibilidad de cancelar la instalacin o la desinstalacin mientras se estn llevando
a cabo.
Incorporacin de una interfaz que sirva para mostrar informacin relativa a la apli-
cacin que se desea instalar.
Presentacin de los paquetes de archivos que se van a instalar seguro.
Descripcin de los paquetes de archivos que se pueden instalar.
Clculo del espacio disponible en el disco duro.
Lo relativo a la barra de progreso y la cancelacin de la instalacin o desinstalacin en

el transcurso de su ejecucin puede resolverse mediante la creacin de hilos de ejecu-
cin (llamados comnmente threads) en Java, y requerira un poco de estudio por mi
parte para implementarlo (conozco el concepto de hilo de ejecucin, pero no la forma
de programarlo en Java). Lo mismo puede decirse con respecto al clculo del espacio
en disco, pero una vez estudiado cmo se puede obtener este dato, sera muy fcil
mostrarlo. Lo dems no supondra ningn esfuerzo adicional. En consecuencia, el es-
fuerzo que debera realizar para incorporar al proyecto estas funcionalidades es neta-
mente menor en comparacin al invertido con las implementadas.
66
La razn por la que se han invertido un poco ms de la mitad de las horas previstas al
inicio en la realizacin del PFC es simple: su elaboracin ha tenido que ser compagina-
da durante todo el ciclo acadmico con el ltimo curso de la doble titulacin; de ah
que las 3 horas que se pensaban dedicar a esta tarea cada da fuesen demasiadas para
lo que se pretenda hacer. Al final, el tiempo real invertido cada semana acab por no
superar las 8 horas, incluyndose la mayor parte de ellas durante los fines de semana.
He de apuntar que, adems, slo he podido disfrutar de una dedicacin exclusiva a la
realizacin del PFC durante el ltimo mes, tras la finalizacin de los exmenes de junio.
Por otro lado, otras razones por las que no ha dado tiempo a realizar todo lo previsto
pueden ser la falta de experiencia ante un proyecto de tal magnitud y el hecho de usar
herramientas desconocidas para m hasta su comienzo, hndicaps que tuvieron una
gran influencia sobre todo al principio, como es natural.
Aunque bien es cierto que exista la posibilidad de retrasar la entrega del proyecto a
septiembre o incluso al siguiente curso acadmico para mejorarlo, se acab desechan-
do tal opcin, pues prefera dar prioridad a la continuidad de mi formacin acadmica
frente a prolongar ms tiempo el PFC. Por otro lado, tanto Julio Rubio como yo consi-
deramos que se han superado con creces los objetivos ms bsicos del proyecto, sien-
do sta la razn ms sustancial por la que se decidi presentarlo en el momento
actual.
67
4.7. Conclusiones
4.7.1. Concordancia entre resultados y objetivos
En lneas generales, los resultados obtenidos satisfacen los objetivos que se determina-
ron al comienzo del proyecto. El creador de instaladores desarrollado es capaz de ofre-
cer al usuario un abanico de posibilidades suficientemente amplio como para crear
cualquier tipo de instalacin con la configuracin que ms le convenga, pues le permi-
te crear accesos directos en los directorios ms utilizados a tal efecto, modificar a su
antojo los valores del registro de Windows (facilitando, incluso, el acceso a las rutas del
registro que cambian con ms frecuencia durante las instalaciones), dar un nombre al
instalador, elegir el directorio de instalacin, crear automticamente un nuevo grupo
de programas, indicar para qu usuarios ser vlida la instalacin, permitir la ejecucin
de instaladores de productos externos inmediatamente despus de la instalacin
Adems de estas funcionalidades y debido al uso que hace de la tecnologa Java, nues-
tro creador de instaladores tambin consigue incorporar una versin de la mquina
virtual de Java (JRE) que se instalar en el equipo del usuario que ejecuta la instalacin
si ste no dispona previamente de ella. Por consiguiente, la aplicacin desarrollada en
este proyecto supera en este aspecto a ciertos creadores de instaladores (como
IzPack), ya que stos no ofrecen esta posibilidad al usuario a pesar de estar implemen-
tados en lenguaje Java. Otro aspecto que consigue mejorar con respecto a IzPack (o,
por lo menos, corregir) est relacionado con la modificacin del registro de Windows:
IzPack tambin satisface este requisito, pero con errores en determinadas ocasiones,
lo que hace que algunos usuarios de este producto desconfen de esa funcionalidad.
Aunque quizs la forma que utiliza nuestro producto para llevar a cabo tal cometido
pueda resultar menos cmoda para el usuario, lo que s se ha comprobado es que es
fiable y libre de errores.
4.7.2. Lecciones aprendidas
Este proyecto me ha servido, sobre todo, para aumentar mis capacidades de trabajo
de investigacin. Se trata de un proyecto eminentemente tecnolgico, basado en la
realizacin de un producto completamente original y novedoso que, aunque en el fon-
do intente emular a un software ya existente y conocido, ha nacido desde el ingenio y
la bsqueda de ideas que resolvieran las dificultades de implementacin a las que me
he ido enfrentando.
68
En cuanto a la planificacin, este proyecto tambin es muy vlido para apreciar en su
verdadera medida las ventajas que proporcionan las metodologas de desarrollo ms
valoradas en la Ingeniera del Software. En este caso, debido a la naturaleza del pro-
yecto, no ha quedado otro remedio que abordar el desarrollo de la aplicacin sin haber
especificado de antemano todas las funcionalidades que era preciso implementar, lo
cual result muchas veces incmodo y arriesgado, pues a la hora de implementar nue-
vos requisitos era muy probable que hubiera que hacer cambios adicionales en el c-
digo, aumentando la probabilidad de que se produjeran errores o de que no los encon-
trramos. Adems, estos cambios en el cdigo suponan un esfuerzo extra difcil de
medir a priori y que causaban demasiada inseguridad en el programador, el cual tena
que disponer de la valenta y el coraje suficientes como para modificar el cdigo escri-
to asumiendo los anteriores riesgos. Todas estas dificultades no habran tenido lugar si
la metodologa usada hubiera especificado todos los requisitos desde el principio.
Otro motivo de aprendizaje fue el hecho de trabajar con herramientas y programas de

software desconocidos para m al comienzo del proyecto. Esto me permiti obtener
una mayor confianza de cara al futuro a la hora de manipular y manejar software de
manera autodidacta. Esta capacidad es importante, pues es posible que me vea obli-
gado a aprender a utilizar nuevos programas y herramientas por m mismo y sin la ayu-
da de nadie que me instruya en determinadas situaciones. Adems, algunas de las he-
rramientas a las que me refiero son frecuentemente utilizadas en el mbito de la pro-
gramacin, hasta el punto que las llegu a estudiar durante el ltimo curso de la carre-
ra (como la modificacin del PATH y el CLASSPATH o el uso de JDom), por lo que la ex-
periencia ha podido resultar muy til para m.
4.7.3. Lneas de ampliacin posibles
Puesto que este proyecto se basa en la emulacin de un creador de instaladores exis-

tente, es probable que no se hayan implementado algunas de las funcionalidades que
proporciona. Otra posible lnea de ampliacin para este proyecto es la incorporacin
de un soporte multilinge, de modo que cada instalacin pueda mostrar interfaces
grficas en diferentes idiomas, as como la implementacin de un soporte multiplata-
forma que permita configurar instalaciones tambin en otros sistemas operativos dis-
tintos de Windows, como Linux o Macintosh. La consecucin de estas mejoras estaran
seguramente basadas en el diseo de una base de datos que recogiera cada uno de los
mensajes mostrados en la interfaz en los diferentes idiomas disponibles y cada uno de
los mandatos utilizados traducidos al lenguaje de programacin propio de los diferen-
tes sistemas operativos considerados. Por ltimo, otra lnea de mejora podra centrar-
se en la construccin de una interfaz para el usuario creador del instalador, de forma
que ya no tendra que verse obligado a construir un fichero XML de configuracin para
realizar su tarea. De hecho, realmente se da la existencia de ciertos creadores de insta-
ladores que incorporan tal interfaz.
Por supuesto, cabe recordar que el proyecto puede mejorarse implementando las fun-
cionalidades que proporciona IzPack y que finalmente no se consideraron por falta de
tiempo. En concreto, estas funcionalidades han quedado recogidas en el apartado 4.6,
Gestin del proyecto.
69
4.8. Bibliografa
1) Juan Diego Gutirrez Gallardo: Manual imprescindible de XML. Anaya Multimedia,
2005.
2) Ejemplos de instaladores creados mediante IzPack:

http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=IzPack.
3) Pgina oficial de IzPack: http://izpack.org.
4) Funcionamiento de CLASSPATH y jar:

http://www.chuidiang.com/java/classpath/classpath.php.
5) Crear un archivo jar ejecutable:

http://login.osirislms.com/index.php?modname=foro&op=message&idThread=28.
6) Pgina oficial de JDom: http://www.jdom.org.
7) Ejemplos de uso de JDom:

http://www.javahispano.org/contenidos/archivo/48/jdom1.pdf.
8) Determinar el usuario actual del sistema:

http://stackoverflow.com/questions/473446/java-current-machine-name-and-
logged-in-user.
9) Pgina para la descarga del programa Shortcut.exe:

http://optimumx.com/download/#Shortcut.
10) Informacin del registro de Windows: http://support.microsoft.com/kb/256986/es.
11) Pgina oficial de 7-Zip: http://www.7-zip.org.
12) Crear un archivo auto-extrable mediante 7-Zip:

http://prudentialscatterbrain.hp.infoseek.co.jp/7z-
4.20_MANUAL/switches/sfx.htm, http://it.megocollector.com/?p=16.
13) Especificacin de la API de Java:

http://download.oracle.com/docs/cd/E17476_01/javase/1.3/docs/api/overview-
summary.html
70
4.9. Anexos
4.9.1. ANEXO I: Manual de instrucciones del usuario creador
INSTRUCCIONES DE USO:
1) En la misma carpeta que se proporciona (la que contiene el Make.bat) se aaden los
archivos que se utilizarn durante la instalacin: iconos, carpetas que se copiarn,
programas o instalaciones externos que se deben ejecutar en el transcurso de la
instalacin...
2) Tambin en la misma carpeta, debe crearse un archivo XML de nombre Instalador.xml.

La estructura que debe tener dicho archivo est especificada en Instalador.dtd y en
Instalador.xsd. A continuacin se indica el significado de cada atributo y elemento:
Elemento instalador: raz del documento.
Atributos:
nombre: lleva el nombre que tendr el instalador.
Elemento fuentes: puede contener varios elementos "origen".
Elemento origen: cada uno contiene un fichero que se copiar en el destino.
Atributos:
programas: indicar "Yes" si se desea instalar el fichero en el grupo de programas de la

aplicacin; "No", en caso contrario.
escritorio: indicar "Yes" si se desea hacer un acceso directo en el escritorio; "No", en

caso contrario.
inicio: indicar "Yes" si se desea que el programa se cargue al arrancar Windows; "No",
en caso contrario.
menuInicio: indicar "Yes" si se desea hacer un acceso directo en la carpeta de

programas del men Inicio; "No", en caso contrario.
aplicaciones: indicar "Yes" si se desea hacer un acceso directo en la carpeta de

aplicaciones del men Inicio; "No", en caso contrario.
Subelementos:
paquete: conjunto de archivos que se instalan como un todo: si se decide que un

archivo de un paquete debe ser instalado, el resto de archivos de ese paquete tambin
se instalarn. Dos archivos diferentes pertenecen al mismo paquete si el valor de este
elemento es el mismo en ambos casos. Incluye el atributo obligatorio "defecto", que
puede tomar como valor "Yes" o "No": "Yes", si se desea instalar por defecto este
paquete; "No", en caso contrario. El nmero mximo de paquetes soportados es 10. El
nombre de los paquetes nunca deber contener ninguna barra baja ('_').
71
archivo: ruta del archivo (dentro de la carpeta del creador de instaladores) que se
copiar en la carpeta de destino. Los subdirectorios se separan mediante \\ (esto ser
vlido para cualquier ruta de aqu en adelante en este documento).
icono: ruta del icono (si existiera) que se asociar al archivo anterior (en caso de que
admitiera un acceso directo). Si un archivo para el que se va a crear un acceso directo
no tiene ningn icono asociado, este elemento puede dejarse vaco u omitirse.
destino: til solamente si se desea copiar un archivo dentro de una carpeta que se
instalar en el directorio de destino. Por ejemplo, si se desea copiar la carpeta
<miCarpeta> en el destino de modo que esta carpeta contiene una subcarpeta llamada
<subCarpeta> que a su vez contiene el archivo <miapp> y deseamos copiar este ltimo
archivo dentro de la anterior subcarpeta, hemos de escribir en "destino" lo siguiente:
<miCarpeta>\\<subCarpeta>. Si no consideramos el subdirectorio <subCarpeta> en el
anterior ejemplo, bastara con escribir <miCarpeta>. Por ltimo, si el archivo <miapp>
no se encuentra dentro de ningn directorio, el subelemento "destino" debe omitirse
(o dejarse en blanco).
Elemento lugaresInstalacion: contiene informacin acerca de los lugares en los que se

instalar la aplicacin. No contiene texto de ningn tipo: solo subelementos.
Elemento destino: contiene la ruta de la carpeta de instalacin.
Elemento programas: contiene el nombre de la carpeta de instalacin.
Atributos:
incluir: "Yes" si se desea crear un grupo de programas dentro del men Inicio. El
nombre del grupo sera el mismo que se indica en el elemento "programas" (es decir,
el de la carpeta de instalacin). "No", en caso contrario.
Elemento registro: contiene solo subelementos que incorporan la informacin de

modificacin del registro de Windows.
Atributos:
modificar: "Yes" si se desea modificar el registro; "No", en caso contrario. Si se indica

"No", se obviar la informacin que puedan contener los subelementos.
Los elementos instalacion y desinstalacion tienen como atributos las claves de registro de
instalacin y desinstalacin de Windows. Adems, desinstalacion incluye subelementos
en los que se muestran los valores de algunas de esas claves (si son distintos de "Yes" o
"No").
Elemento customize: permite modificar el registro libremente, a gusto del usuario.
Atributos:
ruta: guarda la ruta del registro que se va a modificar.
tipo: tipo de dato del valor que se introducir en el registro. El tipo por defecto es
REG_SZ.
clave: guarda la clave de la ruta del registro que se modificar.
72
valor: Cadena que se almacenar en la clave indicada del registro.
Elemento usuarios: indica si la aplicacin se instalar para todos los usuarios o solo para el
actual.
Atributos:
todos: valor "Yes", para todos los usuarios; valor "No", slo para el actual.
Elemento desinstalador: solamente incluye un subelemento.
Subelementos:
icono: Guarda la ruta del icono que se mostrar con el acceso directo del
desinstalador. En caso de no existir tal icono, el elemento debe dejarse vaco.
Elemento ejecutable: incluye la ruta de aquellos programas, ejecutables o instalaciones

externos a la instalacin de nuestra aplicacin que deben ejecutarse durante el transcurso
de sta.
Atributos
prog: guarda el programa con el que debe abrirse el ejecutable o instalador, en caso de
que sea necesario.
NOTA: Para asegurar el correcto funcionamiento de la aplicacin, es necesario que el

documento XML sea completamente acorde a la DTD a la que est asociado; en otro caso,
su comportamiento no tendr por qu ser el esperado.
3) Se modifica la variable del sistema PATH con la ruta del directorio bin de la JDK de Java
que est instalada en su equipo. Por ejemplo, si tiene instalada la versin 1.6.0_17 en el
directorio "Java" de "Archivos de Programa", escriba en la lnea de comandos:
SET PATH=%PATH%;c:\Archivos de programa\Java\jdk1.6.0_17\bin
Es necesario que su equipo disponga de la JDK de Java para que funcione esta aplicacin.
4) Se ejecuta Make.bat.
El resultado es un ejecutable .exe con el nombre del instalador. Dicho ejecutable se

encargar de extraer los archivos de instalacin, ejecutar la instalacin, modificar el
registro de Windows y gestionar la posterior eliminacin de los archivos extrados.
Tambin se incluye un desinstalador que eliminar todos los archivos copiados en la
carpeta de instalacin y los accesos directos, el cual adems eliminar las entradas
correspondientes del registro. Adems, en caso de que el equipo en el que tiene lugar la
instalacin no tenga instalada ninguna versin de la JRE de Java, se instalar en l la
versin 6 update 18.
73
4.9.2. ANEXO II: Cronologa del Proyecto Fin de Carrera
1/10/2009: Busco informacin sobre algunos creadores de instaladores, centrndo-

me en aquel al que tendr que emular, IzPack. Por ahora, me interesa conocer su
funcionalidad, por encima del resto de sus caractersticas (4 horas).
Por otro lado, comienzo a estudiar por mi cuenta el lenguaje XML (el cual hasta
ahora es desconocido para m), ya que ser imprescindible para llevar a cabo el PFC
(los creadores de instaladores han de ser configurables precisamente a travs de fi-
cheros XML). (5 horas).
8/10/2009: Siguiendo con mi iniciacin en XML, me hago con un libro que ensea
las nociones ms bsicas: XML: Manual imprescindible, de Juan Diego Gutirrez
Gallardo. Con esto, aprendo la utilidad de XML para guardar y organizar los datos
(7 horas).
24/10/2009: Finalizo mi primer creador de instaladores, el cual simplemente

construye el cdigo necesario para copiar un fichero de texto en cualquier directo-
rio existente. Se trata del creador de instaladores ms sencillo que puede haber,
pero su filosofa es la misma que utilizar la versin definitiva: generar cdigo fuen-
te en un fichero Java, el cual har las veces del instalador tras compilarlo y ejecu-
tarlo (en este sencillo caso, dicho instalador se llama Instalador.java y se limita a
copiar el fichero indicado en la ruta existente especificada). (5 horas).
Durante la elaboracin de esta primitiva versin del creador de instaladores, me

surgieron las primeras dificultades y dudas. Una de ellas fue el modo de compilar el
fichero Instalador.java (esto es, el instalador en s) de un modo automtico y f-
cil; por ejemplo, con doble clic. El problema lo resolv mediante la construccin de
un archivo ejecutable por lotes (.bat), en el cual se incluan las rdenes necesarias
para compilar (mediante javac.exe) y ejecutar (mediante java.exe) el instalador.
Otro problema, muy ligado al anterior, era que el sistema no encontraba la ruta del
javac.exe, debido a una incorrecta configuracin de la variable de entorno
CLASSPATH. Tras resolver esto, el fichero .bat se ejecutaba sin presentar ms difi-
cultades. Por ltimo, apuntar que el modo de copiar el fichero en el directorio fue
a travs de la creacin de un bfer de datos, el cual lea una determinada cantidad
de bytes del fichero para escribirlos en el fichero de destino (3 horas).
25/10/2009: Consigo que la aplicacin lea de un fichero XML tanto el nombre del
archivo que se quiere instalar como la ruta de la instalacin, as como el nombre
que se desea que tenga el instalador. Esto slo fue posible tras la instalacin de
JDom en mi equipo, vlido para facilitar el acceso a ficheros XML que deben ser le-
dos por programas en Java. Adems, consigo crear desde el programa el .bat referi-
do anteriormente, el cual compila y ejecuta el instalador (5 horas).
74
13/11/2009: Realizo mi primer instalador mediante IzPack. Dicho instalador se en-
carga de instalar una pequea aplicacin en Java en los directorios que se le dictan.
El objetivo de aprender a manejar IzPack se debe a dos razones: conocer con ms
profundidad la funcionalidad de este programa para aplicarla a mi creador de insta-
ladores y crear el instalador definitivo de TutorMates, si la empresa decidiera que
lo haga yo (lo cual supondra una remuneracin econmica por esta labor). (6
horas).
Con el fin de crear la primera instalacin en IzPack fue necesario obtener los cono-
cimientos ms bsicos acerca de los ficheros jar (cmo crearlos y cmo ejecutarlos,
por ejemplo), ya que la propia instalacin se ejecuta a travs de estos ficheros (3
horas).
15/11/2009: Consigo que mi aplicacin para crear instaladores construya automti-

camente un desinstalador de la aplicacin que se pretende instalar, basado en un
algoritmo recursivo (con el fin de poder borrar posibles subdirectorios, as como to-
dos los ficheros creados). Del mismo modo, tambin es capaz de construir un
fichero jar en el que se comprimen y empaquetan tanto el instalador como el des-
instalador a los que me he referido anteriormente, lo cual permite la ejecucin de
la aplicacin en cualquier ordenador que tenga instalada la mquina virtual de
Java. Adems, se consigui que ambos se ejecutaran mediante doble clic gracias a
la construccin de los correspondientes ficheros jar ejecutables (acompaados de
sus ficheros manifest, que indican dnde encontrar la clase que contiene al mtodo
principal). (4 horas).
23/11/2009: El creador de instaladores puede hacer que el instalador copie archi-

vos en el escritorio, as como que instale la aplicacin para todos los usuarios o solo
para el usuario actual (mediante el uso de System.getProperties(user.name)). (4
horas).
27/11/2009: La aplicacin permite crear una carpeta con un determinado nombre

tanto en la ruta especificada como en el men Programas, siendo esto ltimo op-
cional. Tambin es opcional la creacin de la copia del archivo de la aplicacin en el
escritorio (3 horas).
1/12/2009: La aplicacin permite instalar varios archivos (no solo uno) tanto en la
ruta especificada como en el men Programas, de modo que en el escritorio,
adems, se pueda instalar una copia del archivo principal de la aplicacin (5 horas).
5/12/2009: Finalizo el Documento de Objetivos del Proyecto (DOP), primer docu-

mento vlido para la memoria del PFC (12 horas).
8/12/2009: El instalador se puede ejecutar mediante un ejecutable .exe. Para ello,

fue necesaria la creacin de un archivo C++ para compilarlo desde el fichero Java,
cuyo cdigo permite la creacin del instalador (haciendo lo mismo que haca el
.bat). (4 horas). Adems, permite que cualquier fichero de los que se desea instalar
pueda aparecer en el escritorio, si as se indica (1 hora).
75
12/12/2009: Las copias de los ficheros en el escritorio o en el men Programas son
sustituidas por accesos directos, lo cual permite ahorrar una gran cantidad de espa-
cio en memoria. Para lograr esto, tuve que investigar acerca de cmo crear en
Windows estos accesos directos. Necesit para ello la ayuda de una herramienta,
llamada shortcut.exe (5 horas de investigacin ms 6 horas de implementacin y
pruebas).
21/12/2009: El desinstalador permite la eliminacin de todas las carpetas y archi-

vos de la instalacin, incluyendo al propio desinstalador. Esto fue posible gracias a
la creacin de un script que es capaz de borrarse a s mismo y que adems ejecuta-
ba los mandatos necesarios para que las carpetas que no eran eliminadas por el
desinstalador fuesen borradas por el propio sistema operativo. El script es creado
desde el desinstalador (15 horas de investigacin ms 3 horas de implementacin y
pruebas).
25/12/2009: El creador de instaladores permite que todos los archivos que se utili-
zarn en la instalacin (iconos, ficheros jar, etctera) puedan estar ubicados en
cualquier subdirectorio de la carpeta en la que se encuentra (y no necesariamente
en la misma carpeta), siempre y cuando esto se indique adecuadamente en el fi-
chero XML del que se leen las caractersticas de la instalacin (2 horas).
26/12/2009: El instalador tambin permite crear accesos directos en el men apli-

caciones (todos los programas), en la carpeta Inicio y en el men Inicio, si as se es-
pecifica (2 horas).
10/01/2010: El creador de instaladores permite definir los datos que se modifica-

rn en el registro de Windows, una vez instalada la aplicacin, as como borrar las
entradas introducidas en el registro al desinstalarla. Las entradas que se aaden y
las claves que se modifican son:
o HKLM\Software\<Programa>
Install_Dir (opcional)
o HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\<Programa>
DisplayIcon (opcional)
DisplayName
DisplayVersion (opcional)
HelpLink (opcional)
InstallLocation
NoModify (opcional)
NoRepair (opcional)
UninstallString
URLInfo (opcional)
(3 horas de investigacin + 6 horas de implementacin).
17/01/2010: El registro de Windows puede modificarse a gusto del cliente. Ade-

ms, el programa mantiene las opciones de modificacin del registro por defecto
(3 horas). Por otro lado, el creador de instaladores permite copiar directorios ente-
ros en el lugar especificado (1 hora).
76
12/02/2010: El creador de instaladores permite ejecutar archivos externos a la ins-
talacin, tales como ficheros de texto (tipo readme) o incluso otros instaladores (de
programas que pueden ser necesarios para que el que queremos instalar funcione
correctamente). (4 horas).
13/02/2010: El programa aade una nueva funcionalidad con respecto a IzPack: es

capaz de proporcionar al usuario final (el que a la sazn instalar la aplicacin) un
ejecutable en lugar de solamente un archivo jar, de modo que si el usuario final tie-
ne instalada la JRE de Java en su equipo, el .exe ejecuta directamente el jar, y si no,
instala antes Java. La versin del JRE de Java que se instala es la 6, actualizacin
18. (3 horas de investigacin + 5 horas de implementacin y pruebas).
16/02/2010: Nueva mejora a la hora de crear accesos directos: el programa permi-

te crear shortcuts a archivos que se encuentran dentro de directorios, y no solo a
archivos que se copian individualmente. Del mismo modo, permite indicar en qu
ubicacin dentro de la carpeta de instalacin se desea copiar el archivo. Esta mejo-
ra surgi a raz de las peticiones de Jnathan Heras como usuario de mi aplicacin
(3 horas).
23/02/2010: El creador de instaladores genera un nico fichero auto-ejecutable

que es capaz de descomprimir los archivos que almacena para llevar a cabo la ins-
talacin, ejecutar el instalador y gestionar la eliminacin de los archivos tras la ins-
talacin. Para este fin, se us el programa 7-zip, que es software open-source (11
horas de investigacin + 5 horas de implementacin y pruebas). Del mismo modo,
se cre un fichero de texto con las instrucciones de uso del creador de instaladores
y se reorganizaron algunos archivos dentro de la carpeta de la aplicacin (2 horas).
25/02/2010: Se genera un manual de instrucciones en formato de texto que permi-

ta conocer al usuario cmo manejar la aplicacin, lo que es capaz de hacer y los re-
quisitos necesarios para su correcto funcionamiento (1,5 horas).
5/03/2010: Se realiza la documentacin del anlisis de requisitos (2 horas).
12/03/2010: Se genera la documentacin de los casos de uso, la cual incluye la des-

cripcin de cada uno de ellos y el diagrama de casos de uso (4 horas).
16/03/2010: Se documenta la interfaz de usuario, en la que se incluyen moment-

neamente algunos prototipos de baja calidad (3 horas). Adems, se mejora la apli-
cacin de modo que la carpeta con los archivos de la instalacin pueda ubicarse en
un directorio nuevo definido por el usuario, y no necesariamente en uno ya exis-
tente (1 hora de implementacin y pruebas).
19/03/2010: Se modela y representa la interfaz de usuario mediante un diagrama

de estados o statechart, de modo que se clarifique su comportamiento y su modo
de ejecucin (2,5 horas).
77
1/04/2010: Se crea un XML-Schema que representa, de un modo ms grfico del
que se podra lograr con un DTD, la estructura que debe tener el fichero XML de
configuracin (2 horas).
5/04/2010: Se termina de documentar la interfaz del usuario creador. Esta nueva

documentacin incluye una descripcin de la estructura que tiene que poseer el fi-
chero XML para que la aplicacin funcione correctamente, las precondiciones y
poscondiciones que debe cumplir y una explicacin de por qu se descart la crea-
cin de una interfaz grfica para el usuario creador (3,5 horas).
7/04/2010: Se realiza la documentacin del diseo (6 horas).
2/05/2010: Se aade a la documentacin del diseo un diagrama de colaboracin

que representa la interaccin entre los archivos que participan durante el proceso
de instalacin y desinstalacin (2,5 horas).
23/06/2010: Se documenta la implementacin del proyecto (5 horas).
24/06/2010: Se modifica el Documento de Objetivos del Proyecto, de acuerdo a los

acontecimientos que se han ido sucediendo durante los meses que ha durado el
proyecto. Bsicamente, los cambios introducidos se refieren a la eliminacin de la
funcionalidad relacionada con el soporte multilinge, que no se considerar por
falta de tiempo. (1 hora).
26/06/2010: Se documentan las pruebas del proyecto (5 horas). Por otro lado, se
realizan las ltimas pruebas, encaminadas a determinar la correcta funcionalidad
de la aplicacin, lo cual causa modificaciones tanto en el cdigo como en los fiche-
ros DTD y XML-Schema (3 horas).
27/06/2010: Se redactan la introduccin y las conclusiones del proyecto (3 horas).
30/06/2010: Se termina la redaccin de la primera versin de la memoria, que in-

cluye toda la documentacin realizada anteriormente (12 horas).
7/07/2010: Se implementa la interfaz del usuario creador. Para ello, fue necesario
hacer el diseo de la interfaz (8 horas); construir la interfaz en Swing (10 horas); in-
vestigar acerca de cmo mostrar un rbol de directorios para que el usuario final
pueda elegir la ruta de la carpeta de instalacin (3 horas), para ocultar la consola
de C++ (3 horas), para centrar en la pantalla la ventana (2 horas) y para incluir una
barra de progreso en la interfaz (aunque despus no se consiguiera poner en mar-
cha) (5 horas); programar la funcionalidad de la interfaz (16 horas); realizar los
cambios pertinentes en el cdigo para crear el archivo de propiedades
install.properties (6 horas) y realizar la fase de pruebas (7 horas).
13/07/2010: Se aade a la memoria la documentacin de la interfaz del usuario fi-

nal (17 horas). Adems, se revisa la memoria y se realizan los cambios pertinentes
en ella, inducidos por la creacin de la interfaz (15 horas).
15/07/2010: Se prepara la presentacin del PFC (6 horas).
78

Izpack PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Izpack PDF

Caricato da

Copyright:

Formati disponibili

TRABAJO FIN DE ESTUDIOS

PROYECTO FIN DE CARRERA

Instalador configurable a travs de ficheros XML

Miguel Maran Grandes

Tutor: Julio Rubio Garca

Facultad de Ciencias, Estudios Agroalimentarios e Informtica

PROYECTO FIN DE CARRERA

Un instalador configurable a travs de ficheros

Alumno: Miguel Maran Grandes

Logroo, julio de 2010

Pues bien, en este proyecto se explicar cmo construir un creador de instaladores; es

Es necesario remarcar que la metodologa empleada a la hora de desarrollar la aplica-

Las funciones del creador de instaladores no se limitarn a proporcionar el instalador

Para la construccin de este creador de instaladores nos fijaremos en las caractersti-

Centrndonos en TutorMates, AddLink Research, S.L. es la empresa encargada del de-

4.1. Documento de Objetivos del Proyecto (D. O. P.)

4.1.1. Definicin del proyecto

El proyecto se enmarca dentro de la construccin de una aplicacin que servir como

En este apartado se detallar qu se har y qu no se har en el proyecto, as como los

Informe del alcance

El desarrollo multiplataforma: Windows, Linux y Mac OS X.

El creador de instaladores no cumplir, en un principio, todas estas caractersticas.

Ficheros en Java de la aplicacin (creador de instaladores), junto con un script

Ser valiosa una buena documentacin sobre:

4.1.3. Recursos humanos, personal y plan de comunicaciones

En este punto se explicar qu roles desempean las personas que participan en el

Conexiones del proyecto

Miguel Maran: Director y desarrollador del proyecto.

Julio Rubio: Tutor de la Facultad.

Jnathan Heras Vicente: Miembro del Departamento de Matemticas y Com-

Miembros del tribunal evaluador: Grupo de profesores que evaluarn el PFC.

Plan de direccin del personal

Reuniones: Servirn de comunicacin entre Julio Rubio (tutor acadmico) y yo.

4.1.4. Direccin de riesgos

En este apartado se identificarn las fuentes principales de riesgo y se crear un plan a

A continuacin se enumerarn las fuentes de riesgo identificadas para este proyecto.

1. La poca experiencia en el desarrollo de proyectos es una fuente de riesgo poten-

Al detectar alguno de estos sntomas se activar inmediatamente el plan de

Cuantificacin de los riesgos

4.1.5. Planificacin del proyecto

En primer lugar, es necesario indicar que la evolucin de este proyecto se basar en la

1. Estudio de una de las funcionalidades del creador de instaladores IzPack.

Por tanto, el mtodo de trabajo que seguir consistir en la elaboracin de prototipos

PT010 Captura / Identificacin de requisitos y anlisis

PT020 Diseo de la implementacin

PT021 Revisin del diseo

PT030 Eleccin de las herramientas

PT031 Desarrollo de la implementacin

PT032 Revisin de la implementacin

PT041 Ejecucin de las pruebas

La Figura 4 representa el esquema del calendario de trabajo. En naranja se represen-

4.2.1. Anlisis de requisitos

Se pretende construir un creador de instaladores que sea capaz de permitir la cons-

Indicar el nombre que tendr el archivo de instalacin.

Adems, el creador de instaladores tendr que ser capaz de proporcionar el instalador

La ruta de instalacin de la aplicacin.

La modificacin de esta informacin deber hacerse posible mediante la interaccin

Tanto el proceso de creacin del instalador como la instalacin en s debern ejecutar-

Caso de uso: Definir nombre instalador

Caso de uso: Definir archivos a copiar

Caso de uso: Definir accesos directos

Caso de uso: Definir paquetes

Caso de uso: Definir accesos directos men Inicio y escritorio