opensheet - Grupo ARCO - Universidad de Castilla-La Mancha

OPENSHEET: LIBRERÍA MULTIPLATAFORMA PARA PROCESAMIENTO
AUTOMÁTICO DE HOJAS DE CÁLCULO

UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
INGENIERÍA
EN INFORMÁTICA
PROYECTO FIN DE CARRERA
OpenSheet: Librería multiplataforma para procesamiento
automático de hojas de cálculo
Carlos Ruiz Ruiz
Junio, 2011

UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
Departamento de Tecnologías y Sistemas de Información
PROYECTO FIN DE CARRERA
OpenSheet: Librería multiplataforma para procesamiento
automático de hojas de cálculo
Autor: D. Carlos Ruiz Ruiz
Director: Dr. David Villa Alises
Junio, 2011

Carlos Ruiz Ruiz
Ciudad Real – Spain
E-mail: Carlos2res@gmail
Web site: http://arco.esi.uclm.es/
c○ 2011 Carlos Ruiz Ruiz
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU
Free Documentation License, Version 1.3 or any later version published by the Free Software
Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy
of the license is included in the section entitled "GNU Free Documentation License".
Se permite la copia, distribución y/o modificación de este documento bajo los términos de la
Licencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada por
la Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida en
el apéndice titulado «GNU Free Documentation License».
Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios son
reclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, y
cuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos en
mayúsculas o como nombres propios.

TRIBUNAL:
Presidente:
Vocal 1:
Vocal 2:
Secretario:
FECHA DE DEFENSA:
CALIFICACIÓN:
PRESIDENTE VOCAL 1 VOCAL 2 SECRETARIO
Fdo.: Fdo.: Fdo.: Fdo.:

Resumen
Las hojas de cálculo gracias a su gran versatilidad, por su gran cantidad de funciones, a
su potencia de cálculo, que permite automatizar operaciones a través de fórmulas, y a su
gran sencillez de uso, han hecho que se conviertan para muchas empresas y organizaciones
en las herramientas utilizadas para realizar cálculos financieros, guardar informes, gráficos
estadísticos, clasificación de datos, etc. Convirtiéndose los documentos de hojas de cálculo
en una fuente importante de datos.
Por tanto son muchas las organizaciones que cuentan con un gran número de hojas de
cálculo que contienen a su vez gran cantidad de datos, por lo que sería deseable el poder contar
con una herramienta que permita la extracción e inserción de datos en hojas de cálculo de
manera automática. Permitiendo así utilizar en otras aplicaciones los datos almacenados en
hojas de cálculo, a través de la extracción de datos; y viceversa, utilizar los datos disponibles
en otras aplicaciones en las hojas de cálculo a través de la inserción de datos.
En este marco se plantea el diseño de OpenSheet, un proyecto cuyo objetivo principal es
la extracción e inserción de datos en hojas de cálculo de manera automática y sencilla, soportando
los principales formatos de los productos Microsoft Excel y OpenOffice.org Calc.
IX

A Natalia y a mis padres

Agradecimientos
Por fin ha llegado este momento del camino, en el que hay que agradecer a todas aquellas
personas que me han apoyado en algún momento para que lograra terminar el proyecto fin
de carrera, a todos ellos gracias.
Primero, quiero dar las gracias a Natalia, mi compañera en este viaje que es la vida, por
darle sentido y por querer compartirla conmigo. Gracias por todo el apoyo que me ha dado
para lograr este objetivo y sobre todo por su paciencia. Espero a partir de ahora poder recuperar
todo el tiempo perdido para compensar mi ausencia en esta etapa tan importante para
ambos.
Después, quiero dar las gracias a mis padres que me han enseñado el valor de las cosas. A
mi madre por ser siempre un apoyo incondicional para mí, y a mi padre que deseaba poder
ver alguna vez esta memoria escrita.
Gracias a Juani, Carmelo y a Mario por darme ánimos constantemente.
Gracias a mis amigos por apoyarme y animarme. En especial, quiero agradecer a Ángel y
a Jose Ántonio todas esas llamadas de ánimo y apoyo.
Pero no puedo terminar, sin agradecer al artífice de que diera el paso definitivo para comenzar
con el proyecto, David mi director. Gracias por tu paciencia, por hacerme ver las
cosas fáciles cuando las veía difíciles y sobre todo por compartir tus conocimientos y tu
tiempo conmigo.
Carlos
XIII

Índice general
Resumen
Agradecimientos
Índice general
Índice de cuadros
Índice de figuras
Índice de listados
Listado de acrónimos
IX
XIII
XV
XXI
XXIII
XXV
XXIX
1. Introducción 1
1.1. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Antecedentes 5
2.1. Hojas de cálculo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Conceptos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Principales aplicaciones de hojas de cálculo . . . . . . . . . . . . . 7
2.2. Alternativas para trabajar con hojas de cálculo . . . . . . . . . . . . . . . . 7
2.2.1. Estudio e implementación de los estándares . . . . . . . . . . . . . 8
2.2.2. Microsoft Office y COM . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3. OpenOffice.org y UNO . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4. Apache POI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.5. Spreadsheet::ParseExcel . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.6. Spreadsheet::Read . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.7. Spreadsheet::WriteExcel . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.8. OpenOffice::OODoc . . . . . . . . . . . . . . . . . . . . . . . . . 23
XV

2.2.9. Java Excel API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.10. GemBox.SpreadSheet . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.11. Spreadsheet SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.12. Comparativa de alternativas . . . . . . . . . . . . . . . . . . . . . 29
3. Objetivos del proyecto 33
3.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.1. Objetivo 1: Formatos soportados . . . . . . . . . . . . . . . . . . . 34
3.2.2. Objetivo 2: Operaciones permitidas . . . . . . . . . . . . . . . . . 34
3.2.3. Objetivo 3: Conversiones entre formatos . . . . . . . . . . . . . . . 35
3.2.4. Objetivo 4: Exportación a pdf . . . . . . . . . . . . . . . . . . . . 35
3.2.5. Objetivo 5: Multiplataforma . . . . . . . . . . . . . . . . . . . . . 35
3.2.6. Objetivo 6: Librería . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.7. Objetivo 7: Comando . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.8. Objetivo 8: Servicio web . . . . . . . . . . . . . . . . . . . . . . . 36
4. Método y entorno de trabajo 37
4.1. Método de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.1. Metodologías Ágiles . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.2. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1.3. Adaptación de Scrum al marco de trabajo . . . . . . . . . . . . . . 43
4.1.4. Desarrollo dirigido por tests . . . . . . . . . . . . . . . . . . . . . 48
4.1.5. Adaptación de TDD al marco de trabajo . . . . . . . . . . . . . . . 49
4.2. Entorno de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.1. Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . . . 50
4.2.2. Lenguajes de programación . . . . . . . . . . . . . . . . . . . . . 52
4.2.3. Herramientas de documentación . . . . . . . . . . . . . . . . . . . 53
4.2.4. Sistemas Operativos . . . . . . . . . . . . . . . . . . . . . . . . . 54
5. Resultados 55
5.1. Análisis y planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.1. Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.2. Estudio de viabilidad de alternativas . . . . . . . . . . . . . . . . . 58
5.1.3. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2. Sprint 1: Creación y almacenamiento de documentos . . . . . . . . . . . . 64

5.2.1. Historia 1.1 - Crear nuevos documentos . . . . . . . . . . . . . . . 65
5.2.2. Historia 1.5 - Convertir el formato del documento . . . . . . . . . . 69
5.2.3. Resumen de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3. Sprint 2: Apertura de documentos y modificación de hojas . . . . . . . . . 70
5.3.1. Historia 1.2 - Abrir documentos . . . . . . . . . . . . . . . . . . . 71
5.3.2. Historia 1.3 - Modificar hojas de cálculo de un documento . . . . . 73
5.3.3. Resumen de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.4. Sprint 3: Modificación de celdas . . . . . . . . . . . . . . . . . . . . . . . 76
5.4.1. Historia 1.4 - Insertar valores en celdas . . . . . . . . . . . . . . . 77
5.4.2. Historia 1.6 - Extraer valores de celdas . . . . . . . . . . . . . . . 79
5.4.3. Resumen de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.5. Sprint 4: Estudio de lenguaje script y comando . . . . . . . . . . . . . . . 81
5.5.1. Historia 2.1 - Estudio de lenguaje script . . . . . . . . . . . . . . . 83
5.5.2. Historia 2.2 - Comando para ejecutar scripts . . . . . . . . . . . . . 84
5.5.3. Resumen de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.6. Sprint 5: Script genérico para el comando . . . . . . . . . . . . . . . . . . 87
5.6.1. Historia 2.3 - Script Genérico . . . . . . . . . . . . . . . . . . . . 87
5.6.2. Resumen de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.7. Sprint 6: Servicio web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.7.1. Historia 3.1 - Operación de listado de scripts . . . . . . . . . . . . 90
5.7.2. Historia 3.2 - Operación de selección y ejecución de un script sobre
un documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.7.3. Resumen de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.8. Sprints 7-10: Documentación . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.8.1. Sprint 7: Documentación 1 - Antecedentes . . . . . . . . . . . . . 95
5.8.2. Sprint 8: Documentación 2 - Objetivos y Método de Trabajo . . . . 96
5.8.3. Sprint 9: Documentación 3 - Resultados . . . . . . . . . . . . . . . 97
5.8.4. Sprint 10: Documentación 4 - Conclusiones e Introducción . . . . . 97
5.9. API OpenSheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.10. Comando OpenSheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.11. Servicio web OpenSheet . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.12. Documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.13. Estadísticas del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6. Conclusiones 105
6.1. Objetivos alcanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.2. Posibles mejoras y ampliaciones . . . . . . . . . . . . . . . . . . . . . . . 107
6.2.1. Uso de OpenOffice.org remoto . . . . . . . . . . . . . . . . . . . . 107
6.2.2. Soporte para fórmulas . . . . . . . . . . . . . . . . . . . . . . . . 107
6.2.3. Añadir nuevos tipos para la inserción de dependencias . . . . . . . 108
6.2.4. Crear nuevos scripts para uso general . . . . . . . . . . . . . . . . 109
6.2.5. Permitir dependencias entre scripts . . . . . . . . . . . . . . . . . 109
6.3. Conclusiones personales . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.3.1. Conclusiones sobre la metodología de planificación . . . . . . . . . 110
6.3.2. Conclusiones sobre la metodología de desarrollo . . . . . . . . . . 110
A. Manual de usuario 115
A.1. OpenSheet Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
A.1.1. Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
A.1.2. Operación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
A.1.3. Formato de fichero de datos . . . . . . . . . . . . . . . . . . . . . 116
A.1.4. Uso del script OpenSheetScript.groovy . . . . . . . . . . . . . . . 118
A.1.5. Ejemplo de uso de OpenSheet Command . . . . . . . . . . . . . . 127
A.2. OpenSheet Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
A.2.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
A.2.2. Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
A.2.3. Fichero web.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
A.2.4. Activar scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
A.2.5. Clientes de OpenSheet Web Service . . . . . . . . . . . . . . . . . 131
B. Manual de desarrollo 133
B.1. Direcciones de interés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
B.1.1. Repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
B.1.2. Gestión de incidencias y peticiones de mejora . . . . . . . . . . . . 134
B.2. OpenSheet API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
B.2.1. Ejemplos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
B.2.2. Clases y métodos principales . . . . . . . . . . . . . . . . . . . . . 138
B.3. OpenSheet Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
B.3.1. Clases y métodos principales . . . . . . . . . . . . . . . . . . . . . 141
B.3.2. Creación de nuevos scripts . . . . . . . . . . . . . . . . . . . . . . 141
B.4. OpenSheet Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
B.4.1. Clases y métodos principales . . . . . . . . . . . . . . . . . . . . . 143

B.4.2. Creación de nuevos scripts . . . . . . . . . . . . . . . . . . . . . . 143
B.4.3. Pasos de la operación executeScript . . . . . . . . . . . . . . . . . 144
B.4.4. Cliente de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . 145
C. GNU Free Documentation License 149
C.0. PREAMBLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
C.1. APPLICABILITY AND DEFINITIONS . . . . . . . . . . . . . . . . . . . 149
C.2. VERBATIM COPYING . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
C.3. COPYING IN QUANTITY . . . . . . . . . . . . . . . . . . . . . . . . . . 150
C.4. MODIFICATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
C.5. COLLECTIONS OF DOCUMENTS . . . . . . . . . . . . . . . . . . . . . 152
C.6. AGGREGATION WITH INDEPENDENT WORKS . . . . . . . . . . . . 152
C.7. TRANSLATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
C.8. TERMINATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
C.9. FUTURE REVISIONS OF THIS LICENSE . . . . . . . . . . . . . . . . . 153
C.10. RELICENSING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Bibliografía 155

Índice de cuadros
2.1. Comparativa de funcionalidades de las distintas alternativas . . . . . . . . . 30
2.2. Comparativa de características generales de las alternativas . . . . . . . . . 31
5.1. Pila de producto inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2. Historias añadidas al Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3. Historias añadidas al Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4. Historias añadidas al Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5. Historias añadidas al Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.6. Historias añadidas al Sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.7. Historias añadidas al Sprint 6 . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.8. Historias añadidas al Sprint 7 . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.9. Historias añadidas al Sprint 8 . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.10. Historias añadidas al Sprint 9 . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.11. Historias añadidas al Sprint 10 . . . . . . . . . . . . . . . . . . . . . . . . 97
5.12. Resultado de ejecución de SLOCCount con src . . . . . . . . . . . . . . . 103
5.13. Resultado de ejecución de SLOCCount test . . . . . . . . . . . . . . . . . 103
XXI

Índice de figuras
4.1. Roles de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2. Representación de un sprint de Scrum . . . . . . . . . . . . . . . . . . . . 43
4.3. Ejemplo de gráfico de burndown de un sprint . . . . . . . . . . . . . . . . 44
4.4. Algoritmo TDD: Rojo, Verde, Refactorizar. . . . . . . . . . . . . . . . . . 49
5.1. Diagrama de casos de uso básico de API . . . . . . . . . . . . . . . . . . . 56
5.2. Diagrama de casos de uso básico del comando y servicio web . . . . . . . . 57
5.3. Gráfico de burndown del sprint 1 . . . . . . . . . . . . . . . . . . . . . . . 70
5.4. Diagrama de clases resultante del sprint 1 . . . . . . . . . . . . . . . . . . 71
5.5. Gráfico de burndown del sprint 2 . . . . . . . . . . . . . . . . . . . . . . . 75
5.6. Diagrama de clases resultante del sprint 2 . . . . . . . . . . . . . . . . . . 76
5.7. Gráfico de burndown del sprint 3 . . . . . . . . . . . . . . . . . . . . . . . 81
5.8. Diagrama de clases resultante del sprint 3 . . . . . . . . . . . . . . . . . . 82
5.9. Gráfico de burndown del sprint 4 . . . . . . . . . . . . . . . . . . . . . . . 86
5.10. Diagrama de clases resultante del sprint 4 . . . . . . . . . . . . . . . . . . 86
5.11. Gráfico de burndown del sprint 5 . . . . . . . . . . . . . . . . . . . . . . . 89
5.12. Gráfico de burndown del sprint 6 . . . . . . . . . . . . . . . . . . . . . . . 95
5.13. Diagrama de clases resultante del sprint 6 . . . . . . . . . . . . . . . . . . 96
5.14. Diagrama de clases de la API de OpenSheet . . . . . . . . . . . . . . . . . 98
5.15. Diagrama de clases del Comando de OpenSheet . . . . . . . . . . . . . . . 100
5.16. Diagrama de clases del Servicio Web de OpenSheet . . . . . . . . . . . . . 101
XXIII

Índice de listados
2.1. Cómo cargar la aplicación Excel para ser usada través de COM . . . . . . . 10
2.2. Cómo hacer que la carga del servicio COM sea en segundo plano . . . . . . 10
2.3. Abrir un fichero Excel a través de COM . . . . . . . . . . . . . . . . . . . 11
2.4. Seleccionar una hoja de cálculo a través de su nombre usando COM . . . . 11
2.5. Arracar OpenOffice.org en modo servicio escuchando en un socket . . . . . 13
2.6. Arracar OpenOffice.org en modo servicio escuchando en una tubería o pipe 13
2.7. Cadena de conexión para conectar con un servicio a través de socket . . . . 13
2.8. Cadena de conexión para conectar con un servicio a través de una tubería o
pipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.9. Ejemplo uso UNO parte 1: Cómo obtener el objeto remoto XComponentLoader 14
2.10. Ejemplo uso UNO parte 2: Cómo crear un nuevo documento de hojas de
cálculo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.11. Ejemplo uso UNO parte 3: Añadir una nueva hoja de cálculo al documento 15
2.12. Ejemplo uso UNO parte 4: Insertar valores a celdas . . . . . . . . . . . . . 16
2.13. Ejemplo uso UNO parte 5: Guardar un documento con formato xls . . . . . 16
2.14. Ejemplo uso Apache POI . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.15. Ejemplo uso Spreadsheet::ParseExcel . . . . . . . . . . . . . . . . . . . . 19
2.16. Ejemplo uso Spreadsheet::Read . . . . . . . . . . . . . . . . . . . . . . . 20
2.17. Ejemplo de la estructura de datos de un documento de Spreadsheet::Read . 21
2.18. Ejemplo uso Spreadsheet::WriteExcel . . . . . . . . . . . . . . . . . . . . 23
2.19. Ejemplo uso OpenOffice::OODoc . . . . . . . . . . . . . . . . . . . . . . 24
2.20. Ejemplo uso Java Excel API . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.21. Ejemplo uso GemBox.SpreadSheet . . . . . . . . . . . . . . . . . . . . . . 27
2.22. Ejemplo uso Spreadsheet SDK . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1. Añadiendo un directorio a Java Library Path . . . . . . . . . . . . . . . . . 66
5.2. Cambio la localización del path del ejecutable en la clase Bootstrap . . . . 67
A.1. Ejecución OpenSheet Command . . . . . . . . . . . . . . . . . . . . . . . 116
A.2. Ejemplo de uso de variable especial @OpenSheetManager; . . . . . . . . . 116
A.3. Ejemplo de uso de variable especial @OpenSheetDocument; para crear un
documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
XXV

A.4. Ejemplo de uso de variable especial @OpenSheetDocument; para abrir un
documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
A.5. Ejemplo de uso de variable especial @number; . . . . . . . . . . . . . . . 117
A.6. Ejemplo de uso de variable especial @list; . . . . . . . . . . . . . . . . . . 118
A.7. Ejemplo de uso de variable especial @list; con escape del separador . . . . 118
A.8. Ejemplo de uso de variable especial @list; con cadenas vacias . . . . . . . 118
A.9. Ejemplo de asignación de nuevo documento a la variable openSheetDocument
de OpenSheetScript . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
A.10.Ejemplo de asignación de un documento a la variable openSheetDocument
de OpenSheetScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
A.11.Ejemplo de uso por defecto de la variable logFileName . . . . . . . . . . . 121
A.12.Ejemplo de asignación de un fichero a la variable logFileName de OpenSheetScript
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
A.13.Ejemplo de asignación de valores a la variable deleteSheets de OpenSheetScript122
A.14.Ejemplo de asignación de valores a la variable deleteSheetsByPosition de
OpenSheetScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
A.15.Ejemplo de asignación de valores repetidos a la variable deleteSheetsByPosition
de OpenSheetScript . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
A.16.Ejemplo de asignación de valores a la variable addSheets de OpenSheetScript 123
A.17.Ejemplo de asignación de valores a la variable insertCellsValues de OpenSheetScript
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
A.18.Ejemplo de asignación de valores a la variable insertCellsValues de OpenSheetScript
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
A.19.Ejemplo de asignación de valores a la variable insertCellsValues de OpenSheetScript
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
A.20.Ejemplo de asignación de valores a la variable insertCellsValues de OpenSheetScript
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
A.21.Ejemplo de asignación de valores a la variable extractCellsValues de OpenSheetScript
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
A.22.Ejemplo de asignación de valores a la variable extractCellsValuesBySheet-
Position de OpenSheetScript . . . . . . . . . . . . . . . . . . . . . . . . . 126
A.23.Ejemplo de uso por defecto de la variable extractCellsValuesFile . . . . . . 126
A.24.Ejemplo de asignación de un fichero a la variable extractCellsValuesFile de
OpenSheetScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
A.25.Ejemplo de uso por defecto de la variable saveDocumentTo . . . . . . . . . 127
A.26.Ejemplo de asignación de un fichero a la variable saveDocumentTo de OpenSheetScript
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
A.27.Ejemplo de asignación de un fichero con extensión PDF a la variable save-
DocumentTo de OpenSheetScript . . . . . . . . . . . . . . . . . . . . . . . 127

A.28.Ejemplo de fichero de datos . . . . . . . . . . . . . . . . . . . . . . . . . . 128
A.29.Ejemplo de fichero Properties para script de servicio web . . . . . . . . . . 131
B.1. Crear un nuevo documento con OpenSheet API . . . . . . . . . . . . . . . 135
B.2. Abrir un documento con OpenSheet API . . . . . . . . . . . . . . . . . . . 135
B.3. Insertar datos a celdas con OpenSheet API . . . . . . . . . . . . . . . . . . 136
B.4. Insertar datos a rangos con OpenSheet API . . . . . . . . . . . . . . . . . 136
B.5. Extraer datos de celdas con OpenSheet API . . . . . . . . . . . . . . . . . 137
B.6. Extraer datos de rangos de celdas con OpenSheet API . . . . . . . . . . . . 137
B.7. Añadir hojas de cálculo con OpenSheet API . . . . . . . . . . . . . . . . . 138
B.8. Borrar hojas de cálculo con OpenSheet API . . . . . . . . . . . . . . . . . 138
B.9. Convertir un documento de un formato a otro con OpenSheet API . . . . . 138
B.10. Exportar un documento a formato PDF con OpenSheet API . . . . . . . . . 139
B.11. Ejemplo de fichero Properties para script de servicio web . . . . . . . . . . 145
B.12. Ejemplo de cliente de OpenSheet Web Service - Parte 1 . . . . . . . . . . . 147
B.13. Ejemplo de cliente de OpenSheet Web Service - Parte 2 . . . . . . . . . . . 148

Listado de acrónimos
GNU
API
OOO
XML
COM
OLE
MFC
UNO
URL
SDK
PDF
GPL
LGPL
CSV
IDE
JDK
EE
JVM
UML
TDD
XP
SLOC
GNU is Not Unix
Application Programming Interface
OpenOffice.org
Extensible Markup Language
Component Object Model
Object Linking and Embedding
Microsoft Fundations Classes
Universal Network Objects
Uniform Resource Locator
Software Development Kit
Portable Document Format
General Public License
Lesser General Public License
Comma-Separated Values
Integrated Development Environment
Java Development Kit
Enterprise Edition
Java Virtual Machine
Unified Modelling Language
Test Driven Development
eXtreme Programming
Source Lines Of Code
XXIX

Capítulo 1
Introducción
LAs aplicaciones de hojas de cálculo son programas que permiten la creación y manipulación
de documentos compuestos por una cuadrícula con múltiples celdas ordenadas
por fila y columna, y que pueden contener datos numéricos, alfanuméricos o fórmulas. Las
fórmulas permiten indicar cómo el contenido de una celda debe ser calculado a partir de otra
celda o grupo de celdas.
Las hojas de cálculo son consideradas por algunos autores como un lenguaje de programación
funcional [RA09], donde el usuario de manera visual y directa genera programas de
cálculo sin necesidad de conocimientos previos de programación. Gracias a su facilidad de
uso, a la gran cantidad de funciones que proporcionan y a la intercomunicación con otras
aplicaciones, las hojas de cálculo ofrecen una gran versatilidad que ha hecho que su uso sea
muy extendido y variado en campos muy diversos. Las hojas de cálculo son usadas como herramienta
en las ingenierías [CTC06, Fre92, Arg93] debido a su gran potencia para realizar
cálculos y a la facilidad para automatizarlos a través de fórmulas; y sobre todo son usadas
por muchas empresas y organizaciones para realizar cálculos financieros, guardar informes,
gráficos estadísticos, clasificación de datos, etc. Convirtiéndose estos documentos en una
fuente importante de datos.
Es debido al papel tan importante que juegan las hojas de cálculo, en las empresas y organizaciones,
que un simple error en una hoja de cálculo puede ocasionar grandes pérdidas [Gro].
Por ello se han realizado diferentes estudios que han dado como resultado, la identificación
de riesgos para cada tipo de organización [BFJLP07], las diferencias de uso entre usuarios
con diferente grado de experiencia [LBPFJ07], y lo más importante un conjunto de buenas
prácticas [NR99] en el diseño y modelado de hojas de cálculo proponiendo un ciclo de vida
que se adapta a las diferentes necesidades según el tipo de modelo.
En el mercado existen diferentes alternativas en lo que a aplicaciones de hojas de cálculo
se refiere, y cada una de ellas con su propio formato, pero la más utilizada y extendida es
Microsoft Excel [SL99], con su formato xls [Mic08b] [Mic08a], que se proporciona dentro
de la suite de aplicaciones de oficina Microsoft Office, y que se impuso en los 90 a la suite
Lotus 1-2-3 de IBM y a su formato [Cor84].
Como alternativa libre, destaca la suite OpenOffice.org [ope], que incluye la aplicación de
1

2 1. INTRODUCCIÓN
hojas de cálculo Calc. Esta suite ha ido ganando cada vez más mercado al permitir la utilización
de otros formatos como los de Microsoft Office, y al utilizar como formato nativo Open
Document Format [OAS07] [OAS10], formato estándar de la organización OASIS [oas],
para garantizar que los documentos generados no queden atados a una única aplicación.
Según lo descrito, son muchas las organizaciones que cuentan con un gran número de
hojas de cálculo que contienen a su vez gran cantidad de datos, por lo que sería deseable el
poder contar con una herramienta que permita la extracción e inserción de datos en hojas
de cálculo de manera automática. Permitiendo así utilizar en otras aplicaciones los datos
almacenados en hojas de cálculo, a través de la extracción de datos; y viceversa, utilizar los
datos disponibles en otras aplicaciones en las hojas de cálculo a través de la inserción de
datos.
Además, a pesar de los estudios mencionados anteriormente sobre buenas prácticas para
el diseño de hojas de cálculo, sigue habiendo un mal uso a la hora de modelar hojas de cálculo
[BFJLP06], y muchas otras hojas de cálculo que ya se encuentran en uso, siendo inviable
volverlas a modelar usando el conjunto de buenas prácticas propuestas; por lo tanto la estrategia
en este caso debe ir encaminada a detectar los posibles errores para eliminarlos, de
manera que dichas hojas de cálculo sean correctas y estén libres de errores. Para ello se deben
realizar pruebas con el objetivo de depurar las hojas de cálculo [RA08] y así poder garantizar
un mínimo de calidad, para evitar riesgos y pérdidas como se comentó anteriormente.
Esta tarea de pruebas se facilitaría mucho si se contara con la herramienta mencionada anteriormente,
puesto que permitiría automatizar las pruebas, usando un conjunto de datos de
entrada que insertaría de manera automática, y extrayendo los datos obtenidos para que otro
programa los comparara con los datos esperados.
Aunque las aplicaciones como Microsoft Excel permiten la automatización de algunas
tareas a través del uso de macros escritas en lenguajes de tipo script como Visual Basic
[Wal10], sería deseable una herramienta que permita trabajar con los principales formatos
de hojas de cálculo, y no sólo con el formato nativo de la aplicación donde se ejecuta la macro;
además, sería deseable que permitiera de manera sencilla automatizar diferentes tareas
sin necesidad de utilizar una interfaz gráfica.
Por todas las necesidades anteriores se plantea el diseño de OpenSheet, un proyecto cuyo
objetivo principal es la extracción e inserción de datos en hojas de cálculo de manera automática
y sencilla, soportando los principales formatos de los productos Microsoft Excel y
OpenOffice.org Calc.
1.1. Estructura del documento
El presente documento se encuentra dividido en los diferentes capítulos establecidos por
la normativa académica para proyectos fin de carrera [dIU07]. El autor recomienda leer cada

1. INTRODUCCIÓN 3
uno de los capítulos de manera secuencial para una mejor comprensión.
Los capítulos que puede encontrar el lector en el documento son los siguientes:
Capítulo 2: Antecedentes En este capítulo primero se definen los principales conceptos
básicos relacionados con los documentos de hojas de cálculo, necesarios para poder
comprender el proyecto. Y después, se explican las alternativas, para trabajar con hojas
de cálculo, analizadas en un estudio comparativo.
Capítulo 3: Objetivos del proyecto En este capítulo se explica de manera detallada qué
se quiere lograr con el proyecto. Para ello se describen todos los objetivos que se
persiguen, tanto el objetivo general como los objetivos específicos.
Capítulo 4: Método y entorno de trabajo En este capítulo se explican los principales conceptos
de las metodologías aplicadas al desarrollo del proyecto, y también se describe
las herramientas o aplicaciones software que han formado parte del entorno de trabajo.
Capítulo 5: Resultados En este capítulo se explica cómo se ha llevado a cabo las metodologías
elegidas, descritas en el capítulo 4, para lograr alcanzar los objetivos marcados
al comienzo del proyecto.
Capítulo 6: Conclusiones En este capítulo se presentan diferentes contenidos relacionados
con las conclusiones del proyecto. Por un lado se describe cómo se han logrado cubrir
los objetivos marcados al comienzo del proyecto. Por otro lado se describen diferentes
propuestas que pueden ser llevadas a cabo en futuros desarrollos, y que han quedado
fuera del alcance del proyecto. Y por último, se incluye una sección donde el autor
comenta sus conclusiones personales acerca de la experiencia adquirida durante el
desarrollo del proyecto.

Capítulo 2
Antecedentes
EN este capítulo se pretende por un lado dar una breve explicación sobre qué es una hoja
de cálculo y los conceptos que incorpora; y por otro lado ofrecer una visión general
de las diferentes alternativas existentes de librerías y APIs de programación que permiten
al desarrollador, mediante su incorporación en aplicaciones, realizar diferentes operaciones
con documentos de hojas de cálculo sin necesidad de utilizar ninguna interfaz gráfica.
2.1. Hojas de cálculo
2.1.1. Introducción
Una aplicación de hojas de cálculo es un programa que permite crear y editar documentos
de hojas de cálculo. Estos documentos están compuestos por una cuadrícula con múltiples
celdas ordenadas por fila y columna, que pueden contener datos de diferentes tipos: numéricos,
alfanuméricos o fórmulas.
Las fórmulas permiten indicar cómo el contenido de una celda debe ser calculado a partir
de otra celda o grupo de celdas. Las fórmulas son uno de los principales causantes que han
hecho que hoy en día las aplicaciones de hojas de cálculo tengan un uso muy extendido en
campos muy diversos. Esto es debido a que las fórmulas permiten realizar y automatizar
cálculos complejos de manera muy sencilla.
Debido a su gran uso y a la potencia de los cálculos permitidos, los documentos de hojas
de cálculo son una fuente importante de datos para empresas y organizaciones.
A continuación, se realizará una breve descripción de los conceptos necesarios para poder
entender mejor qué es una hoja de cálculo.
2.1.2. Conceptos
En este apartado se pretende explicar aquellos conceptos necesarios para entender mejor
el concepto de hoja de cálculo y los elementos que lo componen, y por tanto para facilitar la
comprensión de este documento.
5

6 2. ANTECEDENTES
Hoja de cálculo
Aunque en la introducción de esta sección ya se ha dado una definición de la palabra
hoja de cálculo, en inglés spreadsheet, dicha palabra es usada de manera habitual para hacer
referencia a distintos conceptos, y para evitar confundir al lector, en este documento siempre
se usará un único significado.
Una hoja de cálculo es una cuadrícula con múltiples celdas ordenadas por fila y columna,
que pueden contener datos numéricos, alfanuméricos o fórmulas.
Celda
Una celda, en inglés cell, es el elemento que forma la cuadrícula de una la hoja de cálculo,
y donde se sitúa una fórmula o un dato, ya sea numérico o alfanumérico.
Una celda es identificada por una columna y una fila. Normalmente para nombrar o identificar
las columnas se usan letras y para las filas se utilizan números enteros, por tanto, una
celda cuyo nombre sea A1 hará referencia a la celda con posición fila 0 y columna 0 en la
cuadrícula.
Rango
Un rango, en inglés range, es un conjunto contiguo de celdas identificados mediante el
identificador de la celda superior izquierda y el identificador de la celda inferior izquierda,
normalmente separado por dos puntos.
El rango permite manejar un conjunto de celdas como una única entidad, facilitando operar
con ellas.
Documento de hojas de cálculo
Un documento de hojas de cálculo, en inglés spreadsheet document, como su nombre
indica, es un documento o fichero que se compone de diferentes hojas de cálculo cada una
de ellas identificada por un nombre o una posición lineal.
Es habitual usar la palabra hoja de cálculo, en inglés spreadsheet, para referirse a un documento
de hojas de cálculo. Y puesto que en inglés para referirse a las hojas de cálculo que
componen un documento se utilizan las palabras sheets o worksheets, no existe problema
para distinguir en una misma frase cuando se hace referencia al documento o una hoja propiamente
dicha, el problema existe en castellano pues la traducción de las palabras anteriores
es hoja u hoja de cálculo respectivamente, lo que impide usar esa nomenclatura sin llevar a
confusión; por tanto se evitará en este documento.

2. ANTECEDENTES 7
Aplicación de hojas de cálculo
Una aplicación de hojas de cálculo es programa que opera con tablas formadas por filas y
columnas de celdas que contienen información numérica y fórmulas o texto, y las presenta en
una pantalla. Esta es la definición dada por la Real Academia Española para la palabra hoja
de cálculo pues puede ser usada también para nombrar a la aplicación propiamente dicha,
pero en este documento siempre se hablará de aplicación para evitar ambigüedades.
2.1.3. Principales aplicaciones de hojas de cálculo
En el mercado existen diferentes alternativas en lo que a aplicaciones de hojas de cálculo
se refiere, y cada una de ellas con su propio formato, pero la más utilizada y extendida es
Microsoft Excel [SL99], con su formato xls [Mic08b] [Mic08a], que se proporciona dentro
de la suite de aplicaciones de oficina Microsoft Office, y que se impuso en los 90 a la suite
Lotus 1-2-3 de IBM y a su formato [Cor84].
Como alternativa libre, destaca la suite OpenOffice.org [ope], que incluye la aplicación de
hojas de cálculo Calc. Esta suite ha ido ganando cada vez más mercado al permitir la utilización
de otros formatos como los de Microsoft Office, y al utilizar como formato nativo Open
Document Format [OAS07] [OAS10], formato estándar de la organización OASIS [oas],
para garantizar que los documentos generados no queden atados a una única aplicación.
2.2. Alternativas para trabajar con hojas de cálculo
En esta sección se muestran diferentes alternativas que permiten trabajar con hojas de
cálculo, sin necesidad de utilizar ninguna interfaz gráfica. De cada alternativa se ha analizado
las siguientes características:
Formatos de documentos de hojas de cálculo que soporta.
Operaciones que permite realizar sobre los diferentes elementos del documento de
hojas de cálculo.
Lenguaje de programación que usa.
Plataformas o sistemas operativos dónde se puede utilizar.
Tipo de licencia.
Soporte que se ofrece, decir, la ayuda a resolver fallos o problemas encontrados al utilizar
la solución. Contar con un buen soporte en el caso de se produzcan problemas
técnicos durante el uso de la alternativa puede evitar un retraso elevado en su resolución.

8 2. ANTECEDENTES
Actividad del proyecto, es decir, cada cuanto tiempo se saca una nueva versión con
mejoras y resolución de bugs.
Madurez de la alternativa, es decir, el tiempo y uso que tiene. Normalmente, cuanta
más madurez tiene un proyecto más estable es.
Características de la documentación de uso de la alternativa.
Dificultad de uso. Aunque posiblemente es la característica más subjetiva de todas, se
puede tratar de hacer una valoración lo más objetiva posible a través del análisis del
esfuerzo que requiere realizar un ejemplo que sea lo más parecido posible en todas
las alternativas o en su defecto analizando el esfuerzo a la hora de realizar diferentes
operaciones.
A continuación, se detalla cada una de las alternativas analizadas.
2.2.1. Estudio e implementación de los estándares
Una alternativa que permite poder trabajar con diferentes formatos de hojas de cálculo y
realizar todas las operaciones que se necesiten, es la de implementar los mecanismos necesarios
para modificar directamente los ficheros binarios de cada formato. Para ello es necesario
el estudio completo de las especificaciones de aquellos formatos a los que se desea dar soporte,
y cumplir con los estándares marcados por dichas especificaciones de manera que se
puedan crear nuevos documentos y, que además se puedan realizar modificaciones sobre un
fichero ya creado sin invalidarlo, permitiendo así su uso en otras aplicaciones que también
soporten dicho formato.
Por tanto para trabajar con los principales formatos de documento de hojas de cálculo,
como son los de Microsoft Excel [Mic10b] y de OpenOffice.org Calc [OAS10] necesitaríamos
estudiar sus especificaciones e implementarlas. Por ejemplo, el formato de un fichero
xls [Mic08b] de Microsoft Excel está dividido en diferentes registros binarios, donde algunos
bytes indican el tamaño de los registros que vienen detrás, y otros registros hacen de índices
dentro del propio fichero, por tanto es necesario conocer todos los registros que lo forman
para poder llevar a cabo la implementación de un nuevo documento y cada cambio que se
realice sobre uno ya existente. Otro formato como el ods [OAS10] de OpenOffice.org Calc
es un conjunto de ficheros en XML empaquetados en un sólo fichero, por tanto es necesario
conocer tanto la distribución de los ficheros que intervienen como su estructura interna para
poder generar documentos válidos y permitir su modificación.
En esta alternativa destaca la flexibilidad que ofrece en la mayoría de características a analizar,
permitiendo elegir: el lenguaje de programación, las plataformas donde poder utilizarse
(la propia elección del lenguaje puede proporcionar esta característica), el tipo de licencia y

2. ANTECEDENTES 9
la posibilidad de conversión entre formatos. La característica que si permanece fija es la de
dificultad de implementación que es muy alta.
2.2.2. Microsoft Office y COM
Existe una alternativa que permite utilizar la funcionalidad de las aplicaciones de Microsoft
Office e incorporarla en otras aplicaciones, se llama Automation y en este apartado se
va explicar en qué consiste.
Automation
Segun Microsoft [Mic08c] Automation (antes conocido como OLE Automation) es una
tecnología que permite usar la funcionalidad de otros programas existentes e incorporarla a
nuestras aplicaciones.
Para poder utilizar las funcionalidades de otro programa se hace uso de COM que es la
arquitectura software de componentes de Microsoft, que permite la comunicación entre procesos
y la creación de objetos dinámicos. El programa que quiere ofrecer sus funcionalidades
para ser usadas con COM debe de generarse teniendo en cuenta la especificación de dicha arquitectura
y hacer públicas las interfaces que va a permitir usar.
Microsoft Excel es una aplicación que implementa COM como servicio de manera que
publica sus interfaces para permitir que otras aplicaciones hagan uso de sus funcionalidades,
es través del uso de Automation como se consigue que aplicaciones que no implementen
COM puedan acceder a los servicios de dicha arquitectura.
Formas de usar un componente COM
Existen principalmente 3 formas de utilizar los servicios de un componente COM desde
Visual C++:
1. Usar MFC.
2. Usar la directiva #import.
3. Usar C/C++ Automation.
La primera opción, hace uso de MFC para generar un envoltorio o wrapper de clases de
la aplicación cliente (la que va a usar los servicios de COM) a partir de la librería de tipos
de la aplicación Office a utilizar. De esta manera las clases de la aplicación cliente pasan a
ser también clases de MFC y por tanto facilita su uso con Automation. Para poder generar el
envoltorio o wrapper mencionado se hace uso de una utilidad que proporciona Visual C++
(disponible a partir de su versión 5.0).
La segunda opción, consiste en usar la directiva #import. Al incluir dicha directiva se crean
puntos de entrada a la librería que se desea utilizar, proporcionando una opción sencilla y

10 2. ANTECEDENTES
potente. El inconveniente es que la propia Microsoft [Mic08c] desaconseja su uso por problemas
existentes con el control del número de referencias en aplicaciones como Microsoft
Office.
La tercera y última opción, consiste en usar directamente la API de COM con C/C++,
haciendo un uso a más bajo nivel de Automation del que se realiza a través de MFC, lo que
da mayor versatilidad y evita el tener que realizar envoltorios o wrappers de la clase, pero
que a su vez tiene el inconveniente de ser más complejo su uso.
Ejemplos de operaciones con hojas de cálculo en C/C++
A continuación, se muestran algunos fragmentos de código con la idea de ilustrar la dificultad
de uso de esta alternativa a través de la tercera de las opciones mostradas en el apartado
anterior, es decir, haciendo uso de C++ Automation. Para que el código sea más sencillo, Microsoft
[Mic07] en sus ejemplos hace uso de una función llamada AutoWrap que facilita el
uso de Automation.
// 1) Buscamos el identificador del programa Excel para COM
CLSID clsid;
HRESULT hr = CLSIDFromProgID(L"Excel.Application", &clsid);
if(FAILED(hr)) {
::MessageBox(NULL, "CLSIDFromProgID() failed", "Error", 0x10010);
return -1;
}
// 2) Arrancamos el servico Excel a traves de su indetificador
IDispatch *pXlApp;
hr = CoCreateInstance(clsid, NULL, CLSCTX_LOCAL_SERVER, IID_IDispatch, (
void **)&pXlApp);
if(FAILED(hr)) {
::MessageBox(NULL, "Excel not registered properly", "Error", 0
x10010);
return -2;
}
Listado 2.1: Cómo cargar la aplicación Excel para ser usada través de COM
{
}
VARIANT x;
x.vt = VT_I4;
x.lVal = 0; //Con 0 sera invisible (segundo plano) y con 1 se
hara visible
AutoWrap(DISPATCH_PROPERTYPUT, NULL, pXlApp, L"Visible", 1, x);
Listado 2.2: Cómo hacer que la carga del servicio COM sea en segundo plano
Como se puede ver en el listado 2.1 la carga del programa Excel como servicio COM para
usarlo en otra aplicación es medianamente sencilla. Si se quiere usar dicha aplicación en

2. ANTECEDENTES 11
segundo plano evitando que sea visible para el usuario, basta con asignar el valor cero a la
propiedad de visibilidad como se puede ver en el listado 2.2.
En [Mic07] se puede ver un ejemplo completo de uso donde se crea un nuevo documento
de hoja de cálculo, se añade una nueva hoja de cálculo, se selecciona la hoja activa, se
selecciona un rango y a cada celda del mismo le asigna un valor distinto, por último salva el
documento y lo cierra.
//El objeto donde se carga el documento es un puntero a IDispatch.
{
VARIANT result, fileName;
fileName.vt = VT_BSTR;
fileName.bstrVal = ::SysAllocString(OLESTR("c:\\fichero_prueba.
xls"));
VariantInit(&result);
AutoWrap(DISPATCH_PROPERTYGET, &result, pXlBooks, L"Open", 1,
fileName);
pXlBook = result.pdispVal; //IDispatch *pXlBook;
}
Listado 2.3: Abrir un fichero Excel a través de COM
//El objeto donde se carga la hoja de calculo es un puntero a IDispatch.
{
VARIANT result, parm;
parm.vt = VT_BSTR;
parm.bstrVal = ::SysAllocString(L"Hoja1");
VariantInit(&result);
AutoWrap(DISPATCH_PROPERTYGET, &result, pXlBook, L"Sheets", 1,
parm);
pXlSheet = result.pdispVal; //IDispatch *pXlSheet;
}
Listado 2.4: Seleccionar una hoja de cálculo a través de su nombre usando COM
Otras operaciones como la de abrir un documento con formato Excel (listado 2.3) u obtener
una determinada hoja del documento a partir de su nombre (listado 2.4) también son
operaciones medianamente sencillas una vez se conoce el mecanismo de su uso. El principal
problema es conocer el nombre y cómo usar determinadas operaciones, siendo en muchas
ocasiones necesario crear una macro en Excel con la operación que se quiere realizar para
poder entender como funciona dicha operación y poder usarla en COM.
Características de la alternativa
Una vez introducida la alternativa, se van a analizar las diferentes características comentadas
en la introducción del capítulo.
Esta alternativa permite trabajar con cualquier formato que soporte Microsoft Excel, permitiendo
además realizar cualquier operación que se pueda realizar con dicha aplicación.

12 2. ANTECEDENTES
En realidad se soportarán todas aquellas versiones y formatos válidos para la versión de
Microsoft Excel usada como servicio.
La necesidad de uso de la arquitectura COM impide su uso en otras plataformas distintas
de Windows. Los lenguajes que se pueden usar para la aplicación, son todos aquellos que
permitan el uso de COM.
La licencia de la aplicación que implemente esta alternativa puede ser del tipo que se desee,
pero al necesitar hacer uso del programa Microsoft Excel siempre será necesario contar con
una licencia del mismo.
La dificultad de su uso es alta, aunque a primera vista viendo los ejemplos del apartado
anterior pueda parecer un uso algo más sencillo, este se complica a la hora de buscar cómo
realizar las diferentes operaciones, pues no existe un índice de todas las operaciones disponible
online, y por tanto a veces es necesario buscar en ejemplos más complejos para localizar
un uso concreto del mismo y la mayoría de las veces la única posibilidad es realizar una
macro en la aplicación Microsoft Excel para analizar el código generado por la misma y así
usarlo de guía para conocer cómo realizar la operación.
Esta alternativa al hacer uso de la tecnología de componentes de Windows y existir multitud
de aplicaciones que hacen uso de ella tiene como resultado una alternativa con una
madurez y actividad muy alta. Además, el soporte también es muy alto.
2.2.3. OpenOffice.org y UNO
Existe una alternativa que permite utilizar la funcionalidad de las aplicaciones de OpenOffice.org
e incorporarla en otras aplicaciones, al igual que ocurre con COM y Microsoft Office
como se ha visto en el apartado anterior, esta se llama UNO y en este apartado se va explicar
en qué consiste.
UNO Universal Network Objects
UNO [Ora10] es la base de la tecnología de componentes de OpenOffice.org que permite
utilizar objetos entre diferentes plataformas y lenguajes a través de la definición de una serie
de interfaces que deben de ser implementadas.
UNO tiene soporte para la siguientes plataformas: GNU/Linux, Solaris, Windows, Power
PC, FreeBSD, MacOS. Y también permite usarse con los lenguajes: Java, C++, OpenOffice.org
Basic, .Net, Python.
La suite de ofimática OpenOffice.org implementa a su vez las interfaces de UNO necesarias
para permitir incorporar las funcionalidades de sus aplicaciones en otras aplicaciones.

2. ANTECEDENTES 13
Formas de conectar a OpenOffice.org con UNO
Existen principalmente 2 formas de utilizar los servicios de OpenOffice.org a través de
UNO:
1. Usar una comunicación local a través de una tubería o pipe.
2. Usar una comunicación remota a través de sockets.
soffice -headless -accept="socket,port=8100;urp;"
Listado 2.5: Arracar OpenOffice.org en modo servicio escuchando en un socket
La primera opción requiere que el ejecutable soffice sea arrancado con unas opciones
determinadas para que se inicie en modo servicio escuchando en un puerto. En el listado 2.5
se muestra como arrancar el proceso de OpenOffice.org como servicio para que se quede
a la escucha de peticiones por socket en el puerto 8100. Esto permite poder usar toda la
funcionalidad de OpenOffice.org Calc, y del resto de aplicaciones de la suite ofimática, sin
necesidad de tener instalado el programa en la misma máquina donde se va a usar, pues
proporciona una comunicación remota a través de un puente o bridge de UNO.
soffice -headless -accept=pipe,name=uno2;urp;"
Listado 2.6: Arracar OpenOffice.org en modo servicio escuchando en una tubería o pipe
La segunda opción requiere que el ejecutable soffice sea arrancando con la opciones de
servicio escuchando en una tubería o pipe con un determinado identificador. Esto permite la
comunicación con otros procesos en local a través de UNO para hacer uso de la funcionalidad
de OpenOffice.org. En el listado 2.6 se muestra como arrancar el proceso OpenOffice.org
como servicio para que escuche en una tubería o pipe de proceso identificada con el nombre
«uno2».
String sConnect =
"uno:socket,host=localhost,port=8100;urp;StarOffice.ComponentContext";
Listado 2.7: Cadena de conexión para conectar con un servicio a través de socket
Una vez se ha arrancado el servicio de OpenOffice.org para conectar con él desde otra
aplicación, en ambas opciones, es necesario resolver la cadena de conexión o URL correspondiente
en cada caso (listado 2.7 y listado 2.8) a través del objeto XUnoUrlResolver, que
devolverá el objeto XComponentContext del servicio remoto a través del cuál se pueden
obtener el resto de objetos necesarios para trabajar con OpenOffice.org Calc.

14 2. ANTECEDENTES
String sConnect = "uno:pipe,name=uno2;urp;StarOffice.ComponentContext";
Listado 2.8: Cadena de conexión para conectar con un servicio a través de una tubería o pipe
Método bootstrap
En el SDK de OpenOffice.org se proporciona la clase Bootstrap con un método estático
llamado bootstrap que permite en una sola llamada ejecutar el servicio de OpenOffice.org
y recuperar el objeto XComponentContext. Esto facilita mucho la conexión con el servicio,
pues proporciona directamente el objeto necesario para trabajar con OpenOffice.org Calc
ocultando todos los pasos necesarios para establecer la comunicación. Este método por dentro
realiza los siguientes pasos:
1. Localiza el directorio donde se encuentra el ejecutable soffice (según el sistema donde
se ejecuta sea GNU/Linux o Windows usa distintos mecanismos).
2. Ejecuta el fichero soffice con los parámetros necesarios para que actúe como servicio
y escuche en una tubería o pipe.
3. Conecta con el servicio a través de la tubería abierta.
4. Recupera el XComponentContext y lo devuelve.
Este método sólo puede ser utilizado cuando la instalación de OpenOffice.org está en la
misma máquina que la clase que va a usar el método bootstrap.
Ejemplo de operaciones con hojas de cálculo usando UNO
En este apartado se va a explicar un ejemplo completo de método que hace uso de Calc
para crear un nuevo documento de hojas de cálculo al que le añade una nueva hoja de cálculo
y asigna valores a dos celdas, para finalmente guardar el documento con formato xls de
Excel. El objetivo de este ejemplo es el de ilustrar el nivel de complejidad de uso de la
alternativa.
XComponentContext xContext = Bootstrap.bootstrap();
XMultiComponentFactory xServiceManger = xContext.getServiceManager();
Object desktop =
xServiceManger.createInstanceWithContext("com.sun.star.frame.Desktop",
xContext);
XComponentLoader xComponentLoader =
(XComponentLoader) UnoRuntime.queryInterface(XComponentLoader.class,
desktop);
Listado 2.9: Ejemplo uso UNO parte 1: Cómo obtener el objeto remoto XComponentLoader

2. ANTECEDENTES 15
El primer paso (listado 2.9) es obtener el objeto remoto XComponentLoader, para ello
se utiliza el método bootstrap comentado en el apartado anterior, y mediante el XComponentContext
recuperado se crear una instancia remota del tipo com.sun.star.frame.Desktop
que permite hacer un casting a la clase del objeto esperado. Los castings en el entorno UNO
se realizan a través de una consulta al runtime que comprueba primero que el objeto puede
realizar el casting a una determinada clase y además que el enlace al objeto remoto sigue
activo.
PropertyValue[] loadProps = new PropertyValue[1];
loadProps[0] = new PropertyValue();
loadProps[0].Name = "Hidden";
loadProps[0].Value = new Boolean(true);
XComponent xSpreadsheetComponent =
xComponentLoader.loadComponentFromURL("private:factory/scalc", "_blank",
0, loadProps);
XSpreadsheetDocument xSpreadsheetDocument =
(XSpreadsheetDocument) UnoRuntime.queryInterface(
XSpreadsheetDocument.class, xSpreadsheetComponent);
Listado 2.10: Ejemplo uso UNO parte 2: Cómo crear un nuevo documento de hojas de
cálculo
El segundo paso (listado 2.10) es cargar un nuevo documento de hojas de cálculo haciendo
uso del objeto remoto XComponentLoader, para ello se le pasa una lista de propiedades
con la propiedad que hace que se realice la operación de creación en segundo plano, y por
tanto de manera transparente al usuario. Como resultado de la creación obtenemos un objeto
XSpreadsheetDocument.
XSpreadsheets xSpreadsheets = xSpreadsheetDocument.getSheets();
xSpreadsheets.insertNewByName("Hoja_prueba", (short) 0);
Object sheet = xSpreadsheets.getByName("Hoja_prueba");
XSpreadsheet xSpreadsheet =
(XSpreadsheet) UnoRuntime.queryInterface(XSpreadsheet.class, sheet);
Listado 2.11: Ejemplo uso UNO parte 3: Añadir una nueva hoja de cálculo al documento
El tercer paso (listado 2.11) consiste en añadir una nueva hoja de cálculo y para ello es
necesario recuperar el objeto XSpreadsheets que representa la lista de hojas de cálculo del
documento. Puesto que el método que añade hojas de cálculo no devuelve nada, para poder
operar después con la hoja creada, es necesario recuperarla antes a través de su nombre. Al
final como resultado obtenemos un objeto XSpreadsheet.

16 2. ANTECEDENTES
XCell xCell = xSpreadsheet.getCellByPosition(0, 0); //celda A1
xCell.setValue(16.6);
xCell = xSpreadsheet.getCellByPosition(1, 1); //celda B2
xCell.setValue(199);
Listado 2.12: Ejemplo uso UNO parte 4: Insertar valores a celdas
El siguiente paso (listado 2.12) consiste en insertar valores a dos celdas del objeto XSpreadsheet
recuperado en el paso anterior. Para ello es necesario primero obtener el objeto
XCell, que se recupera a través de la posición que ocupa en la hoja de cálculo, y después
usar el método que permite asignarle un valor.
XStorable xStorable =
(XStorable)UnoRuntime.queryInterface(XStorable.class,
xSpreadsheetComponent);
PropertyValue[] storeProps = new PropertyValue[1];
storeProps[0] = new PropertyValue();
storeProps[0].Name = "FilterName";
storeProps[0].Value = "MS Excel 97";
File outputFile = new File("salida.xls");
xStorable.storeAsURL("file:///"+outputFile.getAbsolutePath(), storeProps)
;
Listado 2.13: Ejemplo uso UNO parte 5: Guardar un documento con formato xls
El último paso (listado 2.13) consiste en salvar el documento y las modificaciones realizadas
en él en un fichero con formato de Microsoft Excel concretamente el formato xls. Para
ello es necesario obtener a partir del XComponent, que representa el documento cargado en
memoria, un objeto XStorable que permite realizar el salvado a fichero. Como se desea guardar
el documento con un formato distinto al nativo de la aplicación OpenOffice.org Calc, es
necesario definir una lista de propiedades con un filtro que indique al método de salvado en
qué formato se desea guardar el documento.
Características de la alternativa
Una vez introducida la alternativa, se van a analizar las diferentes características comentadas
en la introducción del capítulo.
Esta alternativa permite trabajar con cualquier formato que soporte OpenOffice.org Calc
que incluye los formatos de Microsoft Excel, permitiendo realizar cualquier operación permitida
en dicha aplicación, incluyendo la conversión entre los formatos permitidos y la exportación
a PDF.
Como ya se comentó en apartados anteriores UNO permite el uso de diferentes lenguajes
y plataformas.

2. ANTECEDENTES 17
La licencia de la aplicación que implemente esta alternativa puede ser libre y seguir haciendo
uso de OpenOffice.org sin necesidad de tener ningún tipo de licencia.
La dificultad de su uso de esta alternativa es alta debido a la compleja jerarquía de objetos
que deriva en una gran cantidad de interfaces que siempre debe ser recuperadas en tiempo
de ejecución lo que obliga a conocer dicha estructura previamente.
La documentación para usar UNO es completa y existen gran cantidad de ejemplos, sobre
todo para el desarrollo en Java.
Esta alternativa hace uso de la tecnología de componentes diseñada para usarse directamente
con la suite ofimática OpenOffice.org y forma parte de ella, eso unido al uso extendido
de esta suite desde hace varios años y a la salida con frecuencia de versiones da como resultado
una alternativa con una madurez y actividad muy alta. Además, el soporte ofrecido
tanto por la comunidad como por los desarrolladores también es muy alto.
2.2.4. Apache POI
Existe un grupo de proyectos con el nombre de Apache POI [Foua] que proporcionan
una serie de APIs en Java para trabajar con los diferentes formatos de Microsoft Office.
Concretamente la API que proporciona el soporte para acceder a los formatos de Microsoft
Excel, es decir, a los documentos de hojas de cálculo, es la compuesta por los proyectos
POI-HSSF and POI-XSSF [Foud].
Estas APIs están escritas totalmente en Java e implementan los estándares de los formatos
que soportan que son xls y xlsx, es decir, llevan a cabo lo mencionado en la primera de las
alternativas y por tanto no necesitan hacer uso de otras aplicaciones como si ocurre en las
dos alternativas anteriores.
Ejemplo de operaciones con hojas de cálculo usando Apache POI
En este apartado se va a explicar un ejemplo completo de método que hace uso de la
librería Apache POI para crear un nuevo documento de hojas de cálculo al que le añade una
nueva hoja de cálculo y le asigna valores a dos celdas, para finalmente guardar el documento
con formato xls de Excel.
En el listado 2.14 se puede ver el código resultante de realizar las operaciones sobre un
nuevo documento de hojas cálculo. Los pasos seguidos han sido los siguientes:
1. Se ha creado un nuevo documento xls a partir de un objeto HSSFWorkbook.
2. Se ha añadido al documento una nueva hoja de cálculo, usando el método correspondiente
para ello createSheet. Este método nos devuelve el objeto HSSFSheet que
representa la hoja creada.

18 2. ANTECEDENTES
HSSFWorkbook wb = new HSSFWorkbook();
HSSFSheet sheet = wb.createSheet("Hoja_prueba");
HSSFRow row0 = sheet.createRow((short)0);
row0.createCell(0).setCellValue(16.6); //Celda A1
HSSFRow row1 = sheet.createRow((short)1);
row1.createCell(1).setCellValue(199); //Celda B2
FileOutputStream fileOut = new FileOutputStream("workbook.xls");
wb.write(fileOut);
fileOut.close();
Listado 2.14: Ejemplo uso Apache POI
3. Para poder asignar un valor a una celda, antes es necesario crear un objeto Row que
representa la fila.
4. Una vez se tiene el objeto Row simplemente se usa el método para asignarle un valor
a la celda indicando el índice de la columna.
5. El último paso consiste en guardar el contenido del documento, para ello se hace uso
del método write proporcionado, al que es necesario pasarle un objeto FileOutputStream
con el nombre que se desea dar al fichero.
Características de la alternativa
Una vez introducida la alternativa, se van a analizar las diferentes características comentadas
en la introducción del capítulo.
Esta alternativa permite trabajar con los formatos xls y xlsx de Microsoft Excel, permitiendo
realizar la mayoría de las operaciones con las siguientes limitaciones:
No permite crear gráficos, aunque si el fichero con el que trabaja ya tiene alguno creado
con otro programa, se pueden modificar las celdas que son usadas como datos de dicho
gráfico.
No permite crear macros ni modificarlas, pero si el fichero tiene macros las mantiene.
No permite crear tablas dinámicas, en inglés pivot tables, pero las mantiene si el documento
las incluye.
El lenguaje de programación usado es Java, y al estar la librería escrita completamente
en dicho lenguaje, hace que la solución sea multiplataforma, pudiendo usarse en cualquier
sistema que tenga una implementación de máquina virtual de Java.
La librería tiene una licencia Apache 2.0 por tanto la aplicación que implemente esta
alternativa puede ser libre o con licencia privativa.

2. ANTECEDENTES 19
La dificultad de su uso es más sencilla que otras alternativas al no necesitar conectar con
otras aplicaciones para operar con hojas de cálculo si no que se usan directamente los objetos
que representan cada elemento de un documento de hojas de cálculo.
Apache POI cuenta con una documentación en línea completa y con gran cantidad de
ejemplos que muestran cómo utilizar la mayoría de las funcionalidades que ofrece.
Esta alternativa lleva en usándose en diferentes proyectos tanto libres como privativos
desde hace varios años, esto unido a la publicación frecuente de nuevas versiones y al soporte
proporcionado por Apache y su comunidad da como resultado una solución con una
actividad, soporte y madurez muy altas.
2.2.5. Spreadsheet::ParseExcel
Spreadsheet::ParseExcel [Tak] es un módulo en Perl que permite extraer información de
ficheros de Excel en las versiones 95 y 97-2000 a través de la implementación de los estándares
de dichos formatos. No permite insertar información en los documentos de hojas
de cálculo y tampoco permite extraer fórmulas generadas con el módulo de Perl Spreadsheet::WriteExcel.
Ejemplo de código usando ParseExcel
En este apartado se muestra un ejemplo [Tak], extraído de la documentación del módulo,
con el objetivo de ilustrar el nivel de complejidad de uso del mismo. En el ejemplo se recorren
las celdas de un documento y se imprimen .
use strict;
use Spreadsheet::ParseExcel;
my $oBook =
Spreadsheet::ParseExcel::Workbook->Parse(’Excel/Test97.xls’);
my($iR, $iC, $oWkS, $oWkC);
foreach my $oWkS (@{$oBook->{Worksheet}}) {
print "--------- SHEET:", $oWkS->{Name}, "\n";
for(my $iR = $oWkS->{MinRow} ;
defined $oWkS->{MaxRow} && $iR {MaxRow} ; $iR++) {
for(my $iC = $oWkS->{MinCol} ;
defined $oWkS->{MaxCol} && $iC {MaxCol} ; $iC++) {
$oWkC = $oWkS->{Cells}[$iR][$iC];
print "( $iR , $iC ) =>", $oWkC->Value, "\n" if($oWkC);
}
}
}
Listado 2.15: Ejemplo uso Spreadsheet::ParseExcel
En el listado 2.15 se puede ver el código resultante de realizar la operación de lectura de
las celdas de un documento.

20 2. ANTECEDENTES
Características de la alternativa
Una vez introducida la alternativa, se van a analizar las diferentes características comentadas
en la introducción del capítulo.
Esta alternativa sólo permite trabajar con las versiones antiguas del formato xls, y solamente
para la lectura de la información, es decir, no permite su modificación.
El lenguaje de programación usado es Perl, y al estar el módulo escrito completamente en
dicho lenguaje, el módulo es multiplataforma, permitiendo su uso en cualquier sistema que
tenga una implementación del intérprete de Perl.
La librería tiene una licencia GNU GPL y por tanto la aplicación que implemente esta
alternativa debe ser libre y usar el mismo tipo de licencia.
La dificultad de esta alternativa es alta al no disponer de una documentación completa.
Spreadsheet::ParseExcel lleva en desarrollo desde el 2000 sacando versiones con frecuencia,y
ofreciendo soporte a través de un grupo creado en Google, por tanto este módulo tiene
una madurez y actividad altas, con un soporte medio.
2.2.6. Spreadsheet::Read
Spreadsheet::Read [Bra] es un módulo en Perl que permite extraer los datos de diferentes
formatos de documentos de hoja de cálculo como los formatos sxc y ods de OpenOffice.org,
xls y xlsx de Microsoft Excel, CSV y otros.
Este módulo en lugar de implementar los diferentes formatos, hace uso de diferentes módulos
para obtener la información de cada tipo de documento de hoja de cálculo, ofreciendo
un mecanismo homogéneo de acceso a los datos de un documento independientemente de su
formato.
Ejemplo de código usando Read
En este apartado se muestra un ejemplo [Bra], extraído de la documentación del módulo,
en el que se abre un documento de formato xls y se obtiene el valor de una celda. Además, se
muestra un ejemplo de la estructura usada para almacenar la información de un documento
de hojas de cálculo. El objetivo principal de mostrar el código usado es el de ilustrar el nivel
de complejidad de uso del componente.
use Spreadsheet::Read;
my $ref = ReadData ("test.xls");
my $a3 = $ref->[1]{A1}, "\n";
Listado 2.16: Ejemplo uso Spreadsheet::Read

2. ANTECEDENTES 21
En el listado 2.16 se puede ver el código resultante para abrir un documento de hojas de
cálculo que tiene formato xls, y después obtener el valor de la celda A1 de la primera hoja
de cálculo.
$ref =
[
# Elemento 0: contiene la informacion general del documento
{ sheets => 2,
sheet => {
"Sheet 1" => 1,
"Sheet 2" => 2,
},
type => "xls",
parser => "Spreadsheet::ParseExcel",
version => 0.26,
},
# Elemento 1: contiene la informacion de la primera hoja
{ label => "Sheet 1",
maxrow => 2,
maxcol => 4,
cell => [ undef,
[ undef, 1 ],
[ undef, undef, undef, undef, undef, "Nugget" ],
],
A1 => 1,
B5 => "Nugget",
},
# Elemento 2: contiene la informacion de la segunda hoja
{ label => "Sheet 2",
:
: }
Listado 2.17: Ejemplo de la estructura de datos de un documento de Spreadsheet::Read
En el listado 2.17 obtenido de la documentación del módulo [Bra] se puede ver como toda
la información recuperada al leer un documento de hojas de cálculo se almacena en array
donde el primer elemento contiene los datos referentes al documento completo, tales como el
número y nombre de las hojas que contiene, el tipo de documento y el parser utilizado junto
con su versión; el resto de elementos contienen los datos de cada una de las hojas de cálculo
(nombre, número de filas, número de columnas, valores de las celdas). Como el módulo no
está programado con orientación a objetos, basta con conocer las estructuras que contienen
la información para trabajar con ellas.
Características de la alternativa
Una vez introducida la alternativa, se van a analizar las diferentes características comentadas
en la introducción del capítulo.
Esta alternativa permite trabajar con múltiples formatos de hojas de cálculo pero solamente

22 2. ANTECEDENTES
para la lectura de la información como el nombre del módulo indica, por lo tanto no permite
modificación ni creación de documentos.
El lenguaje de programación usado es Perl, y al estar el módulo escrito completamente en
dicho lenguaje, incluyendo los módulos que utiliza, es multiplataforma, pudiendo usarse en
cualquier sistema que tenga una implementación del intérprete de Perl.
La librería tiene una licencia GNU GPL y la aplicación que implemente esta alternativa
debe ser libre y usar el mismo tipo de licencia.
La dificultad de uso es sencilla al disponer de una documentación donde se muestran las
estructuras completas en las que se carga la información a utilizar, como ya se ha ilustrado
en el apartado anterior, y las funciones principales de uso. En este caso como el módulo no
está programado con orientación a objeto, basta con conocer las estructuras que contienen la
información para trabajar con ellas.
Spreadsheet::Read lleva en desarrollo desde el 2005 sacando versiones con frecuencia pero
no ofrece soporte directamente a través de algún canal directo salvo la gestión de bugs que
ofrece CPAN [CPA] por defecto, lo que hace que tenga una madurez y actividad altas, sin
soporte directo, puesto que no existe ninguna actividad en el sistema ofrecido por CPAN.
2.2.7. Spreadsheet::WriteExcel
Spreadsheet::WriteExcel [McN] es un módulo en Perl que permite crear nuevos ficheros
de Excel en las versiones 97-2000, 2002, 2003 y 2007 a través de la implementación de los
estándares de dichos formatos. No tiene soporte para modificar ficheros Excel generados con
Microsoft Excel, y en caso de modificarlo todos aquellos elementos como macros, gráficos
y otras funcionalidades que no se soportan se perderán.
Ejemplo de código usando WriteExcel
En este apartado se muestra un ejemplo que adapta el primer ejemplo [McN] de la documentación
para que se realicen las mismas operaciones que se han hecho con otras alternativas.
El ejemplo consiste en crear un nuevo documento de hojas de cálculo al que le añade
una nueva hoja de cálculo y le asigna valores a dos celdas. El objetivo de este ejemplo es el
de ilustrar el nivel de complejidad de uso de la alternativa.
En el listado 2.18 se puede ver el código resultante de realizar la creación del documento
de hojas de cálculo, al que se le añade una nueva hoja de cálculo y se asignan valores a dos
de sus celdas.

2. ANTECEDENTES 23
use Spreadsheet::WriteExcel;
my $workbook = Spreadsheet::WriteExcel->new(’workbook.xls’);
$worksheet = $workbook->add_worksheet(’Hoja_prueba’, 1);
$worksheet->write(’A1’, 16.6);
$worksheet->write(’B2’, 199);
$workbook->close();
Listado 2.18: Ejemplo uso Spreadsheet::WriteExcel
Características de la alternativa
Una vez introducida la alternativa, se van a analizar las diferentes características comentadas
en la introducción del capítulo.
Esta alternativa permite trabajar con las diferentes versiones del formato xls, para su creación,
pero la modificación de ficheros generados con Microsoft Excel puede provocar pérdida
de diferentes funcionalidades.
El lenguaje de programación usado es Perl, y al estar el módulo escrito completamente
en dicho lenguaje es multiplataforma, pudiendo usarse en cualquier sistema que tenga una
implementación del intérprete de Perl.
La librería tiene una licencia GNU GPL y la aplicación que implemente esta alternativa
debe ser libre y usar el mismo tipo de licencia.
La dificultad es sencilla pues los métodos son bastantes explícitos y además se proporciona
una documentación con el listado de todos los métodos disponibles.
Spreadsheet::WriteExcel lleva en desarrollo desde hace más de diez años, sacando versiones
con cierta frecuencia,y ofreciendo soporte a través de un grupo creado en Google, por
tanto este módulo tiene una madurez y un soporte altos, y su actividad es media, al haberse
reducido en el último año los cambios realizados en el módulo.
2.2.8. OpenOffice::OODoc
OpenOffice::OODoc [Gou] es un módulo en Perl que permite trabajar con documentos en
formato Open Document [OAS07], ofreciendo las funcionalidades necesaria para crear nuevos
documentos y modificar documentos ya existentes, siendo compatible con documentos
de texto, documentos de hojas de cálculo y documentos de presentación.
En la documentación de OpenOffice::OODoc, no se recomienda usar dicho módulo para
crear tablas complejas como las usadas para representar una hoja de cálculo. En su lugar se
aconseja usar otras herramientas que también trabajen con Open Document y que permitan
crear este tipo de tablas.

24 2. ANTECEDENTES
Ejemplo de código usando OODoc
En este apartado debido a la limitación del módulo para crear hojas de cálculo, se ha
realizado un ejemplo haciendo uso de los ejemplos mostrados en la documentación del módulo
[Gou] que consiste en crear un nuevo documento de hojas de cálculo y asignarle a la
primera hoja de cálculo valores a dos de sus celdas. El objetivo de este ejemplo es el de
ilustrar el nivel de complejidad de uso de la alternativa.
use OpenOffice::OODoc;
my $workbook = odfContainer("workbook.ods", create => ’spreadsheet’);
my $worksheet = $workbook->expandTable(0, 5, 5);
$workbook->cellValue($worksheet,0,0,16.6);
$workbook->cellValue($worksheet,1,1,199);
$workbook->save;
Listado 2.19: Ejemplo uso OpenOffice::OODoc
En el listado 2.19 se puede ver el código resultante de realizar la creación del documento
de hojas de cálculo, el cuál por defecto es creado con una única hoja de cálculo que contiene
una celda. Para poder aumentar el número de celdas, es necesario hacer uso del método
explandTable, en el ejemplo se añaden varias celdas, y una vez añadidas se asignan valores
a dos de ellas.
Características de la alternativa
Una vez introducida la alternativa, se van a analizar las diferentes características comentadas
en la introducción del capítulo.
Esta alternativa permite trabajar con el formato Open Document proporcionando las funcionalidades
necesarias para la creación y modificación de los diferentes tipos de ficheros,
odt para documentos de texto, ods para documentos de hojas de cálculo y odp para documentos
de presentaciones; con una importante limitación, puesto que no se recomienda usar
sus funciones para crear nuevas hojas de cálculo dentro de un documento.
El lenguaje de programación usado es Perl, y al estar el módulo escrito completamente
en dicho lenguaje hace que la alternativa sea multiplataforma, pudiéndose usar en cualquier
sistema que tenga una implementación del intérprete de Perl.
La librería tiene una licencia GNU LGPL y por tanto la aplicación que implemente esta
alternativa puede ser libre o usar una licencia privativa.
La dificultad es alta puesto que al tratar de manejar de manera uniforme todos los tipos
de documentos del formato Open Document, hay conceptos que desaparecen, por ejemplo
no existe directamente el concepto de hojas de cálculo si no que se representa a través del

2. ANTECEDENTES 25
concepto de tabla, y los diferentes tipos de tablas se tratan igual, ya sea una simple tabla con
texto que se vaya a insertar en un documento de texto o una tabla compleja que representa una
hoja de cálculo; sin embargo, hay acciones que si requieren realizar operaciones adicionales
cuando se trata con tablas que representan hojas de cálculo. Además de todo lo anterior, la
documentación tiende a hablar de los diferentes elementos que existen sin hacer divisiones
de lo permitido para cada uno de los tipos de documento, lo que hace que no sea sencillo
identificar que operaciones están permitidas en cada uno de ellos. Todo lo anterior hace que
el uso del módulo no sea intuitivo ni sencillo a la hora de trabajar con documentos de hojas
de cálculo.
OpenOffice-OODoc lleva en desarrollo desde el 2004, siendo la última versión liberada
de julio de 2010, el soporte se ofrece a través de los foros de CPAN [CPA], por todo ello este
módulo cuenta con una madurez alta, una actividad actual baja y un soporte medio.
2.2.9. Java Excel API
Java Excel API es un API para Java que permite leer, modificar y generar documentos de
hojas de cálculo con formato Excel en las versiones 95 y 97-2000 a través de la implementación
de los estándares de dichos formatos.
Ejemplo de código usando Java Exel API
En este apartado se muestra un ejemplo donde se llevan a cabo las mismas operaciones
que se han realizado en los ejemplos de otras alternativas. El ejemplo consiste en crear un
nuevo documento de hojas de cálculo al que le añade una nueva hoja de cálculo y le asigna
valores a dos celdas. El objetivo de este apartado es el de ilustrar el nivel de complejidad de
uso de la alternativa.
WritableWorkbook workbook = Workbook.createWorkbook(new File("output.xls"
));
WritableSheet sheet = workbook.createSheet("Hoja_prueba", 0);
jxl.write.Number number = new jxl.write.Number(0, 0, 16.6); //Celda A1
sheet.addCell(number);
number = new jxl.write.Number(1, 1, 199);//Celda B2
sheet.addCell(number);
workbook.write();
workbook.close();
Listado 2.20: Ejemplo uso Java Excel API
En el listado 2.20 se puede ver el código resultante de realizar las operaciones sobre un
nuevo documento de hojas cálculo. Los pasos seguidos han sido los siguientes:

26 2. ANTECEDENTES
1. Se ha creado un nuevo documento xls creando un nuevo objeto WritableWorkbook
2. Se ha añadido al documento una nueva hoja de cálculo, usando el método correspondiente
para ello createWorkbook. Este método nos devuelve el objeto WritableSheet
que representa la hoja creada.
3. Para poder asignar un valor a una celda, antes es necesario crear un objeto con el
formato del dato a insertar, es decir, un objeto que representa el contenido de la celda
y su posición; en el ejemplo al insertar un valor numérico se hace uso del objeto
jxl.write.Number. Si se deseará insertar una cadena entonces sería necesario crear un
objeto jxl.write.Label.
4. Una vez creado el objeto que representa al contenido de la celda, se inserta a la hoja
de cálculo deseada a través de su método addCell.
5. El último paso consiste en escribir los cambios que se han realizado en el documento
y cerrarlo para liberar los recursos asociados al mismo.
Características de la alternativa
Una vez introducida la alternativa, se van a analizar las diferentes características comentadas
en la introducción del capítulo.
Esta alternativa trabaja con el formato xls en las versiones 95 y 97-2000 Excel, permitiendo
realizar la mayoría de las operaciones con las limitaciones de que no da la posibilidad
de generar macros ni gráficos, no obstante si el fichero a modificar contiene alguno de estos
elementos los preservará.
El lenguaje de programación usado es Java, y al estar la librería escrita completamente en
dicho lenguaje hace que esta alternativa sea multiplataforma, pudiendo usarse en cualquier
sistema que tenga una implementación de máquina virtual de Java.
La librería tiene una licencia LGPL por tanto la aplicación que implemente esta alternativa
puede ser libre o con licencia privativa.
La dificultad es sencilla pues los objetos y métodos para trabajar con ellos son intuitivos
y están bien organizados, permitiendo coger rápidamente la filosofía seguida por esta API.
Además se proporciona una documentación muy completa con un tutorial que facilita todavía
más su uso.
Java Excel API empezó en 2002 a partir de la implementación basada en ExcelRead,
siendo la última versión liberada de octubre de 2009. Para el soporte cuenta con un grupo
creado en Yahoo. A partir de la información anterior se puede decir que la librería tiene una
madurez alta, con una actividad actual nula y un soporte medio.

2. ANTECEDENTES 27
2.2.10. GemBox.SpreadSheet
GemBox.SpreadSheet [Sof] es un componente .NET que permite a los desarrolladores
escribir, leer y convertir ficheros de documentos de hojas de cálculo a través de una API sin
necesidad de tener instaladas otras aplicaciones. GemBox.SpreadSheet es compatible con
los formatos de Excel 97-2007 (xls y xlsx) y Open Document a través de la implementación
de los estándares de dichos formatos. Tiene las siguientes limitaciones:
Las imágenes y comentarios sólo se soportan en los formatos xlsx y ods.
Sólo se conserva la información de gráficos y de tablas dinámicas , en inglés pivot
tables, para el formato xlsx.
Ejemplo de código usando GemBox.SpreadSheet
En este apartado se muestra cómo realizar el ejemplo ilustrado en otras alternativas esta
vez haciendo uso de la librería GemBox.SpreadSheet. El ejemplo consiste en crear un nuevo
documento de hojas de cálculo, añadirle una nueva hoja de cálculo, asignarle valores a
dos celdas y salvar el documento. El objetivo de este ejemplo es el de ilustrar el nivel de
complejidad de uso de la alternativa.
ExcelFile excelFile = new ExcelFile();
ExcelWorksheetCollection worksheets = excelFile.Worksheets;
ExcelWorksheet ws = worksheets.Add("Hoja_prueba")
ws.Cells["A1"].Value = 16;
ws.Cells["B2"].Value = 199;
excelFile.SaveXls("ejemplo.xls");
Listado 2.21: Ejemplo uso GemBox.SpreadSheet
En el listado 2.21 se puede ver el código resultante del ejemplo, en el que primero se
realizar la creación del documento de hojas de cálculo, en este caso con formato Excel, para
después recuperar la colección de hojas de cálculo del documento a la que se le añade una
nueva hoja de cálculo, que será a la que se le asignen los valores numéricos a dos de sus
celdas.
Características de la alternativa
Una vez introducida la alternativa, se van a analizar las diferentes características comentadas
en la introducción del capítulo.
Esta alternativa permite trabajar con las diferentes versiones del formato Microsot Excel
y Open Document, pero la modificación de ficheros xls que hayan sido creados con otras
herramientas puede provocar pérdida de alguna información como gráficos y tablas dinámicas.

28 2. ANTECEDENTES
El lenguaje de programación a usar puede ser cualquiera de la plataforma .NET. Esta
alternativa sólo se puede usar en sistemas Windows.
GemBox.SpreadSheet tiene licencia privativa, y una licencia gratuita que permite el uso
de la API con limitaciones (un máximo de 150 filas por hoja de cálculo, y 5 hojas por documento).
La dificultad es sencilla pues los métodos son bastantes explícitos, se proporciona un fichero
de ayuda para usarlo con el entorno de desarrollo Visual Studio, y además se proporcionan
varios ejemplos que ilustran las diferentes operaciones que se pueden realizar.
La madurez y actividad de la solución son más difíciles de analizar en productos con licencia
privativa que con alternativas de código abierto en las que se puede acceder al repositorio
para ver ambas características por tanto no se evaluarán. En este caso lo que si es muy alto
es el soporte pues se puede contratar.
2.2.11. Spreadsheet SDK
Spreadsheet SDK [Byt] es un componente .NET que permite a los desarrolladores escribir,
leer y convertir ficheros de documentos de hojas de cálculo a través de una API sin necesidad
de tener instaladas otras aplicaciones. Spreadsheet SDK es compatible con los formatos de
Excel 97-2010 (xls y xlsx) y Open Document a través de la implementación de los estándares
de dichos formatos, y permite la exportación en diferentes formatos incluido PDF.
Ejemplo de código usando Spreadsheet SDK
En este apartado se muestra cómo realizar el ejemplo usado en otras alternativas haciendo
uso de la API Spreadsheet SDK. El ejemplo consiste en crear un nuevo documento de hojas
de cálculo, añadirle una nueva hoja de cálculo, asignarle valores a dos celdas y salvar el
documento. El objetivo de este ejemplo es el de ilustrar el nivel de complejidad de uso de la
alternativa.
Spreadsheet document = new Spreadsheet();
Worksheet worksheet = document.Workbook.Worksheets.Add("Hoja_prueba");
worksheet.Cell(0, 0).Value = 16;
worksheet.Cell(1, 1).Value = 199;
document.SaveAs("ejemplo.xls");
Listado 2.22: Ejemplo uso Spreadsheet SDK
En el listado 2.22 se puede ver el código resultante de realizar la creación del documento
de hojas de cálculo, en este caso con formato Excel, se recupera la colección de hojas de
cálculo del documento para añadir una nueva, y se le asignan valores a dos de sus celdas.

2. ANTECEDENTES 29
Características de la alternativa
Una vez introducida la alternativa, se van a analizar las diferentes características comentadas
en la introducción del capítulo.
Esta alternativa permite trabajar con las diferentes versiones del formato Microsot Excel y
Open Document, permitiendo la modificación de documentos ya creados con Microsoft Excel
sin pérdida de información. Además, permite la exportación a PDF y otros formatos.
El lenguaje de programación permitido para trabajar con esta alternativa puede ser cualquiera
de la plataforma .NET. Este módulo sólo se puede usar en sistemas Windows.
Spreadsheet SDK tiene licencia privativa.
La dificultad es sencilla pues los métodos son bastantes explícitos, y además se proporciona
documentación y varios ejemplos que ilustran las diferentes operaciones que se pueden
realizar.
La madurez y actividad de la solución son más difíciles de analizar en productos con licencia
privativa que con alternativas de código abierto en las que se puede acceder al repositorio
para ver ambas características por tanto no se evaluarán. En este caso lo que si es muy alto
es el soporte pues se puede contratar.
2.2.12. Comparativa de alternativas
En esta sección se pretende dar una visión general de las alternativas estudiadas en el
capítulo a través de la comparación de la características analizadas. Para ello se han creado
dos cuadros comparativos que se analizarán a continuación.
Comparativa de funcionalidades
En el cuadro 2.1 se realiza una comparación de las funcionalidades puramente técnicas,
representadas por las siguientes columnas:
Lenguaje: es el lenguaje de programación con el que permite trabajar la alternativa.
Formatos: son los formatos de documentos de hojas de cálculo que se soportan.
C: representa la operación de Creación de documentos de hojas de cálculo.
M: representa la operación de Modificación de documentos de hojas de cálculo.
E: representa la operación de Exportación de información de documentos de hojas de
cálculo.
Cv: representa la operación de Conversión de documentos de hojas de cálculo a los
formatos soportados.

30 2. ANTECEDENTES
PDF: representa la operación de exportación de documentos de hojas de cálculo al
formato PDF.
Plataforma: es la plataforma o sistema operativo donde se puede utilizar la alternativa.
Una vez se han explicado qué representa cada una de las columnas del cuadro 2.1, vamos
a analizar la información que se puede extraer de él. Existen cuatro alternativas que
permiten trabajar con los formatos más extendidos Excel y Open Document, estas son: OpenOffice.org
con UNO, Spreadsheet::Read, GemBox.SpreadSheet, y Spreadsheet SDK. De
las alternativas anteriores sólo dos permiten realizar todas las operaciones y conversiones:
OpenOffice.org con UNO y Spreadsheet SDK, de las anteriores sólo la primera es multiplataforma.
Nombre Lenguaje Formatos C M E Cv PDF Plataforma
MS Office y COM C++ y otros Excel X X X X Windows
OpenOffice.org y UNO Java y otros Excel y OOO X X X X X Varias
Apache POI Java Excel X X X X Varias
Spreadsheet::ParseExcel Perl xls X Varias
Spreadsheet::Read Perl Excel y OOO X Varias
Spreadsheet::WriteExcel Perl Excel X Varias
OpenOffice::OODoc Perl OOO X X X Varias
Java Excel API Java xls X X X Varias
GemBox.SpreadSheet .Net Excel y OOO X X X X Windows
Spreadsheet SDK .Net Excel y OOO X X X X X Windows
Cuadro 2.1: Comparativa de funcionalidades de las distintas alternativas
Comparativa de características generales
En el cuadro 2.2 se realiza una comparación de las características a tener en cuenta a la hora
de elegir una alternativa y que van más allá de las puramente técnicas. Estas características
son representadas por las siguientes columnas:
Licencia: es la licencia que tiene la alternativa y que debe ser compatible con la licencia
del producto que la vaya a usar.
Doc: Es la documentación y ejemplos con los que cuenta la solución. Normalmente
cuanto mejor es la documentación antes y mejor se puede llevar a cabo la implementación
de un producto.
Soporte: Es el soporte a fallos o problemas encontrados al utilizar la solución. Durante
el desarrollo hay riesgo de que aparezcan problemas y es importante contar con algún
tipo de soporte que pueda reducir los tiempos en solucionarlos.

2. ANTECEDENTES 31
Actividad: representa la actividad que tiene un proyecto, es decir, cada cuanto tiempo
se libera una nueva versión. Esta característica es importante porque se resuelven antes
los problemas encontrados.
Madurez: representa el tiempo y uso que tiene una solución, de manera que cuanto
más tiempo y más uso tenga más madura será. Normalmente cuanto más madura es
una solución mayor estabilidad tiene.
Dif: Dificultad, característica que indica lo fácil o difícil que es usar una determinada
solución; En ella influye entre otros factores la documentación del proyecto.
Una vez se han explicado qué representa cada una de las columnas del cuadro 2.2, vamos
a analizar la información que se puede extraer de él. Existen tres alternativas que tiene una
documentación completa, junto con una madurez, actividad y soporte muy altos, estas son:
Microsoft Office y COM, OpenOffice.org con UNO, y Apache POI. De las alternativas anteriores
sólo las dos últimas tienen licencia libre, puesto que si se usa Microsoft Office se
requiere adquirir una licencia de esta suite ofimática. Además, de las alternativas libres sólo
Apache POI tiene una dificultad baja.
Nombre Licencia Doc. Soporte Actividad Madurez Dif.
MS Office y COM privativa Completa Muy Alto Muy Alta Muy Alta Alta
OpenOffice.org y UNO LGPL Completa Muy Alto Muy Alta Muy Alta Alta
Apache POI Apache Completa Muy Alto Muy Alta Muy Alta Baja
Spreadsheet::ParseExcel GPL Poca Medio Alta Alta Alta
Spreadsheet::Read GPL Completa No Alta Alta Baja
Spreadsheet::WriteExcel GPL Completa Alto Media Alta Baja
OpenOffice::OODoc LGPL Completa Medio Baja Alta Alta
Java Excel API LGPL Completa Medio Muy Baja Alta Baja
GemBox.SpreadSheet privativa Completa Muy Alto - - Baja
Spreadsheet SDK privativa Completa Muy Alto - - Baja
Cuadro 2.2: Comparativa de características generales de las alternativas

Capítulo 3
Objetivos del proyecto
EN la comparativa de alternativas realizada en el capítulo anterior, se puede ver que
de todas las alternativas estudiadas sólo tres (OpenOffice.org y UNO, GemBox.SpreadSheet
y Spreadsheet SDK) permiten la posibilidad de insertar y extraer información de documentos
de hojas de cálculo con los principales formatos del mercado, que son los formatos de
Microsoft Excel y los de OpenOffice.org Calc. De esas tres alternativas sólo OpenOffice.org
tiene una licencia no privativa.
La alternativa de usar OpenOffice.org a través de UNO es la más completa siendo multiplataforma
y ofreciendo a los desarrolladores la posibilidad de incluir toda funcionalidad de
su suite ofimática en sus aplicaciones. Pero esa gran funcionalidad ofrecida hace que su uso
tenga una dificultad elevada y por tanto sea compleja de incluir en otras aplicaciones.
El proyecto OpenSheet a través del objetivo general y de los objetivos específicos pretende
cubrir ese vacío detectado en el estudio realizado de las alternativas. En este capítulo se
describen tanto los objetivos generales como los específicos para determinar así el alcance
del proyecto.
3.1. Objetivo general
El objetivo general que persigue el proyecto es proporcionar mecanismos para poder realizar
la extracción e inserción de datos en los documentos de hojas de cálculo de manera
automática y sencilla, soportando los principales formatos existentes en el mercado.
3.2. Objetivos específicos
Los objetivos específicos que persigue el proyecto son los siguientes:
1. Permitir trabajar con documentos de hojas de cálculo con los siguientes formatos:
xls [Mic08b], xlt y xlsx [Mic10a] [Mic10b] de la aplicación Microsoft Excel; ods y
ots de Open Document Format [OAS07] [OAS10] para hojas de cálculo.
2. Permitir realizar las siguientes operaciones con documentos de hojas de cálculo: crear
33

34 3. OBJETIVOS DEL PROYECTO
un nuevo documento, abrir un documento ya existente, extraer datos de celdas, insertar
datos en celdas, crear nuevas hojas de cálculo y eliminar hojas de cálculo.
3. Permitir conversiones de hojas de cálculo entre los formatos soportados, siempre y
cuando las funciones incorporadas en las hojas de cálculo a exportar existan tanto el
formato origen como en el destino y además sean compatibles.
4. Permitir la exportación de hojas de cálculo al formato pdf.
5. Ser multiplataforma, soportando al menos los sistemas operativos Windows y GNU/-
Linux.
6. Proporcionar una librería que exponga como funcionalidades los objetivos del proyecto,
permitiendo así su incorporación en otras aplicaciones y proyectos.
7. Proporcionar una herramienta o comando que utilice la librería mencionada anteriormente,
preparado para ejecutarse desde un terminal o consola del sistema para poder
ser usado en un procesamiento por lotes.
8. Proporcionar un servicio web que haga uso de la librería mencionada anteriormente,
ofreciendo las funcionalidades de los objetivos del proyecto de forma remota.
A continuación, se detallará cada uno de los ocho objetivos anteriores.
3.2.1. Objetivo 1: Formatos soportados
El primer objetivo consiste en permitir trabajar con aquellos formatos de documentos de
hojas de cálculo de los programas más extendidos: Microsoft Excel y OpenOffice.org Calc.
Concretamente los formatos permitidos serán: xlt, xls, xlsx, ods y odt. Con este objetivo se
pretende que se pueda trabajar de manera homogénea y sencilla con cualquier documento de
hojas de cálculo independientemente de su formato.
3.2.2. Objetivo 2: Operaciones permitidas
El segundo objetivo fija las operaciones que se pretenden ofrecer para trabajar con documentos
de hojas de cálculo que tengan alguno de los formatos soportados, estas operaciones
son:
1. Crear nuevos documentos: se permitirá crear nuevos documentos de hojas de cálculo
para poder trabajar con ellos, y luego poder almacenar las modificaciones realizadas.
2. Abrir documentos: se permitirá abrir documentos de hojas de cálculo creados anteriormente
por OpenSheet o por otros programas siempre y cuando su formato este
soportado.

3. OBJETIVOS DEL PROYECTO 35
3. Extraer datos: se permitirá extraer datos numéricos y textos de las celdas que forman
parte de las distintas hojas de cálculo del documento.
4. Insertar datos: se permitirá insertar datos en las distintas celdas de las hojas de cálculo
del documento, ya sean datos numéricos o textos.
5. Crear hojas de cálculo: se permitirá crear nuevas hojas de cálculo dentro de un documento.
6. Eliminar hojas de cálculo: se permitirá eliminar hojas de cálculo que forman parte de
un documento.
Todas las operaciones deben ofrecer una forma de uso sencilla.
3.2.3. Objetivo 3: Conversiones entre formatos
El tercer objetivo es permitir de manera automática y sencilla la conversión de documentos
de hojas de cálculo entre los diferentes formatos soportados, siempre que los elementos
incluidos en el formato de origen sean compatibles con los elementos del formato destino.
3.2.4. Objetivo 4: Exportación a pdf
El cuarto objetivo consiste en dar la opción de exportar al formato PDF un documento de
hojas de cálculo que tenga alguno de los formatos permitidos.
3.2.5. Objetivo 5: Multiplataforma
El quinto objetivo es conseguir que el proyecto sea multiplataforma, de manera que se permita
su uso en diferentes sistemas operativos, concretamente, se debe soportar los sistemas
operativos GNU/Linux y Windows.
3.2.6. Objetivo 6: Librería
El sexto objetivo consiste en proporcionar una librería o API que cumpla con todos los
objetivos anteriores, de manera que permita incorporar la funcionalidad proporcionada en
otras aplicaciones.
3.2.7. Objetivo 7: Comando
El séptimo objetivo consiste en usar la librería del objetivo anterior para implementar una
herramienta o comando que permita realizar las operaciones de inserción y extracción de datos,
la conversión entre formatos y la exportación a PDF. Este comando debe estar preparado
para ejecutarse desde un terminal del sistema, lo que permitirá automatizarlo fácilmente para
usarlo en trabajo por lotes.

36 3. OBJETIVOS DEL PROYECTO
3.2.8. Objetivo 8: Servicio web
El último objetivo consiste en usar la librería del sexto objetivo para implementar un servicio
web que permita, al igual que el comando, realizar las operaciones de inserción y
extracción de datos, la conversión entre formatos y la exportación a PDF. Al tratarse de un
servicio web permitirá trabajar con los documentos de hojas de cálculo de forma remota.

Capítulo 4
Método y entorno de trabajo
EN este capítulo se va a describir tanto el método como el entorno de trabajo del proyecto.
En el método de trabajo se pretende en primer lugar ofrecer una descripción
de las metodologías utilizadas para conocer en qué consisten, y luego explicar cómo se han
adaptado para poder usarlas en el marco de trabajo de un proyecto fin de carrera. En en el
entorno de trabajo se enumerarán las diferentes herramientas y aplicaciones software usadas
a lo largo del desarrollo, con una breve descripción de para qué sirven y cómo se han usado
en el proyecto.
4.1. Método de trabajo
En esta sección se describe el método de trabajo usado para el desarrollo del proyecto, y
las metodologías en las que se basa dicho método. Concretamente el método de trabajo se
basa en el uso de metodologías ágiles: Scrum que se ha usado para la planificación y gestión
del proyecto, y Test Driven Development (desarrollo dirigido por test) que se ha utilizado
como metodología de desarrollo. A continuación, se describirá con mayor detalle en qué
consisten estas metodologías ágiles utilizadas y cómo se han adaptado para su aplicación en
el proyecto realizado.
4.1.1. Metodologías Ágiles
Si por algo se caracteriza el método de trabajo utilizado es por que se basa en el uso de
metodologías ágiles, por lo que antes de entrar a definir las metodologías concretas que se
han usado es importante conocer el concepto de metodología ágil.
Las metodologías de desarrollo ágiles son metodologías de desarrollo software basadas en
el desarrollo iterativo, donde se considera que los requisitos y las soluciones van evolucionando
a lo largo de todo el desarrollo, y por tanto se da más importancia a la capacidad de
adaptarse rápidamente a esos cambios que a la capacidad para aplicar medidas de contingencia
que eviten que los cambios detectados afecten a la planificación establecida.
37

38 4. MÉTODO Y ENTORNO DE TRABAJO
Manifiesto Ágil
El término de desarrollo ágil de software fue acuñado en el 2001 cuando un grupo de
desarrolladores convocados por Kent Beck se reunió para discutir sobre los métodos de
desarrollo de software ligeros, de esa reunión surgió el manifiesto del desarrollo de software
ágil [BBvB + 01]:
Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.
Los doce principios que sigue el manifiesto ágil [BBvB + 01] son:
1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua
de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana
durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno
y el apoyo que necesitan, y confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo
y entre sus miembros es la conversación cara a cara.
7. El software funcionando es la medida principal de progreso.

4. MÉTODO Y ENTORNO DE TRABAJO 39
8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores
y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación
ajustar y perfeccionar su comportamiento en consecuencia.
Con estos doce principios queda patente qué es un desarrollo ágil y qué persigue. Ahora
se van a analizar las ventajas que se obtienen con estos principios.
El primer principio de entregar al cliente software que funciona a lo largo de todo el desarrollo
tiene varias ventajas. La primera de ellas es que con cada entrega se puede obtener
realimentación continuamente del cliente, de manera que este se implique directamente en
el proyecto al usar dichos artefactos generados, y transmitiendo si lo que se va entregando
corresponde a lo esperado o si se detectan nuevas necesidades. Esto hace que sin asistir a
reuniones periódicas del proyecto, cosa que la mayoría de veces para el cliente no es posible,
el cliente esté implicado durante todo el desarrollo. Otra ventaja es que el cliente puede empezar
a cubrir las necesidades del producto sin tener que esperar a que el proyecto finalice,
que muchas veces son periodos de tiempos excesivamente largos que provocan que se acabe
rechazando el producto en beneficio de otros productos ya terminados existentes en el mercado.
Por último, la ventaja desde el punto de vista económico es que se puede ir facturando
con cada entrega.
El segundo principio que dice que hay que asumir y reaccionar frente a los cambios en los
requisitos en cualquier etapa, es uno de los más importantes puesto que permite adaptarse
rápidamente a nuevas necesidades que surjan en el mercado, ofreciendo a la empresa una
gran ventaja competitiva frente a aquellas que tienen modelos de desarrollo más pesados y
que no podrán llegar a ciertas oportunidades del mercado. Este principio unido al primero,
que habla de ir entregando software con funcionalidad, permite una reacción muy rápida a los
cambios, y por tanto adaptarse al funcionamiento actual del mercado donde las tecnologías
y necesidades cambian muy rápidamente.
En los diferentes principios se puede observar que las metodologías ágiles dan mucha importancia
a las personas que forman el equipo de desarrollo y a su comunicación, y además
que implican a los responsables del negocio. Todo lo anterior unido a la posibilidad de ir
entregando software a lo largo del proyecto hace posible que dichas entregas reflejen completamente
las necesidades comerciales de la empresa. Por ejemplo, si se tiene la necesidad

40 4. MÉTODO Y ENTORNO DE TRABAJO
de disponer de demostraciones técnicas para que el departamento comercial pueda usarlas
mientras el proyecto de desarrollo avanza, y así poder buscar clientes, se pueden enfocar
las entregas para cumplir con ese objetivo. Como las entregas que se van a usar en las demostraciones
siguen siendo el producto, con funcionalidad reducida, y no requieren que se
dedique más tiempo a cumplir este objetivo, el tiempo y coste no varían, lo único necesario
es priorizar los requisitos en función de las necesidades.
Por último, otra ventaja muy importante que se puede obtener de algunos de los objetivos,
es que se persigue el mejorar constantemente el proceso de desarrollo a través de tratar de
maximizar la reutilización, de perseguir el buen diseño y la excelencia técnica, y sobre todo
con las reflexiones colectivas periódicas que permiten analizar que se ha hecho mal para
corregirlo y que se ha hecho bien para potenciarlo.
4.1.2. Scrum
En esta sección no se pretende dar una explicación extensa y profunda de Scrum, para eso
se cuentan con libros y referencias en la web, si no que el objetivo perseguido es dar una
visión global de Scrum y sus principales conceptos para entender en otros capítulos cómo se
ha adaptado su uso en el proyecto, y comprender mejor el capítulo de resultados.
¿Por qué usar Scrum
El escenario de negocio ha cambiado de manera que las necesidades tecnológicas cambian
rápidamente y aparecen otras nuevas, por lo que es necesario que los proyectos cuenten con
una gran velocidad a la hora de reaccionar a esos cambios para dar una respuesta rápida que
se traduzca en los productos reclamados por el mercado.
Algunos autores [Pal07] comentan que puede que estemos en una etapa en la que ha dejado
de existir el concepto de producto final, y en su lugar existen productos en continua evolución
a partir de los incrementos de funcionalidad de las versiones iniciales o versiones beta de un
producto. De esta manera, el producto va cambiando e incorporando los nuevos requisitos
para ofrecer cada poco tiempo nuevas versiones.
Para permitir llevar a cabo proyectos cuyos productos se adapten de manera rápida a las
necesidades del mercado, existe una metodología ágil para la gestión de proyectos llamada
Scrum.
¿Qué es Scrum
Scrum es una metodología ágil que define un marco de trabajo iterativo e incremental
para la gestión de proyectos. Esta metodología gestiona proyectos basándose en un modelo
ágil, cuyo objetivo es permitir adaptarse rápidamente a cambios en los requisitos en lugar de
intentar identificar todos los requisitos necesarios al comienzo del proyecto.

4. MÉTODO Y ENTORNO DE TRABAJO 41
Scrum ofrece un conjunto de prácticas y roles que pueden usarse como modelo de referencia
para definir el proceso de desarrollo concreto que se ejecutará en los proyectos. A
continuación se definen estos roles y conceptos.
Roles
En Scrum se pueden identificar los siguientes roles implicados directamente en el proceso:
Dueño de poducto (product owner): es el responsable de representar y asegurarse que
se cumple con la perspectiva de negocio y los intereses del cliente. Las tareas que
realiza son:
• Añadir nuevos requisitos o historias de usuario en la pila de producto (product
backlog).
• Priorizar las historias de usuario.
• Comprobar al finalizar un período de desarrollo (sprint) que el producto resultante
cumple con los objetivos comprometidos.
Scrum master: es el responsable de que el equipo cumpla sus objetivos al finalizar el
sprint y de que se cumplan las reglas de Scrum. Las tareas que realiza son:
• Convoca y dirige las reuniones para realizar las estimaciones de historias y división
en tareas. Tanto las estimaciones como la división en tareas las realiza
conjuntamente todo el equipo.
• Dirige las reuniones diarias de seguimiento llamadas scrum.
• Asigna a los miembros del equipo aquellas tareas que no han sido seleccionadas
de manera voluntaria.
Miembro de equipo (Scrum member): es el encargado de cumplir con las tareas elegidas
o asignadas para que el equipo logre alcanzar el objetivo marcado en el sprint.
En Scrum los equipos son multidisciplinares por lo que un miembro de equipo puede
ser un desarrollador, diseñador, etc.
En la figura 4.1 se pueden ver los tres roles principales con el elemento del que es responsable
cada uno: el dueño de producto es el responsable de la gestión de la pila de producto,
el Scrum master es el responsable de la gestión de los sprints, y el miembro del equipo es
responsable de implementar las historias y tareas asignadas.
A parte de los roles anteriores, directamente implicados en el proceso de Scrum, existen
otros roles muy importantes que participan a través de la realimentación o feedback a partir
del análisis o uso de los productos generados en los sprints. Algunos de estos roles son:
clientes, usuarios, gerentes, comerciales, etc.

42 4. MÉTODO Y ENTORNO DE TRABAJO
Figura 4.1: Roles de Scrum
Pila de Producto
La pila de producto (product backlog) es una lista priorizada de todos los requisitos o
historias de usuario que se desean implementar en el producto. Estas historias de usuario,
que es como se llaman a los requisitos en Scrum, son definidas usando la terminología del
dueño de producto de modo que pueda trabajar con ellas sin problemas.
La pila de producto es algo muy dinámico, donde se añaden historias conforme se detectan
nuevas necesidades, y donde la priorización va cambiando para que al principio de
la pila estén siempre las historias que se quieren implementar primero. El mantenimiento y
priorización de la pila es llevado a cabo por el dueño de producto.
Sprint
Un sprint es el periodo de tiempo o iteración con un objetivo concreto, durante el cuál se
implementan aquellas historias planificadas dando como resultado un incremento funcional
del producto. Normalmente la duración de los sprints no suele exceder los dos meses de
desarrollo para cumplir con los principios del manifiesto ágil.
Un proyecto implementa las historias de la pila de producto a través de su planificación
en sprints. El número de historias que se pueden planificar para que se implementen en cada
sprint depende por un lado de la estimación en tiempo de cada historia y por otro de la
velocidad del equipo.
En la figura 4.2 se puede ver ilustrado la representación de un sprint, donde primero se
seleccionan en orden las historias que están en la pila de producto y se asignan al sprint
que se va a comenzar, después se inicia el sprint y una vez ha transcurrido el tiempo fijado
para su desarrollo se obtiene como resultado el producto con las nuevas funcionalidades
implementadas.
Antes del comienzo de un sprint se realiza una reunión del equipo con el dueño de producto
para decidir que historias se van a llevar a cabo en ese sprint, para ello las historias deben

4. MÉTODO Y ENTORNO DE TRABAJO 43
Figura 4.2: Representación de un sprint de Scrum
estar estimadas, pues se irán añadiendo al sprint en el orden establecido en la pila, hasta
alcanzar la cantidad máxima de trabajo que puede realizar el equipo, medida dada por la
velocidad de equipo.
Durante el desarrollo del sprint se utiliza un diagrama llamado burn-down, ver figura 4.3
en el que se representa el estado de la implementación de las historias. Con este gráfico se
puede comprobar de manera visual si el sprint sigue con la planificación establecida, o se
está produciendo alguna desviación positiva o negativa, de manera que se pueda corregir
rápidamente.
Al final del sprint se analiza el resultado del mismo y se hace un análisis de todo los
sucedido como por ejemplo si se ha cumplido completamente con la planificación,los factores
que han puesto en peligro el funcionamiento del mismo, qué cosas mejorar o cambiar,
etc.
Scrum
Scrum es una reunión diaria, de no más de quince minutos, que realiza todo el equipo y
donde se analiza el estado de las tareas. Esta reunión, que da nombre a la metodología, es
una potente herramienta de comunicación para todo el equipo, puesto que permite conocer
que está haciendo cada miembro, detectar los problemas encontrados y además analizar la
situación global del sprint.
4.1.3. Adaptación de Scrum al marco de trabajo
En esta sección se va a explicar como se ha adaptado la metodología Scrum para poder
usarse en la gestión de un proyecto fin de carrera.
Para la definición del proceso de Scrum se ha partido de las recomendaciones y experiencias
transmitidas por Henrik Kniberg en su libro [Kni07], y una adaptación posterior debido

44 4. MÉTODO Y ENTORNO DE TRABAJO
Figura 4.3: Ejemplo de gráfico de burndown de un sprint
a las características propias del entorno donde se debían aplicar. Las características a tener
en cuenta en el proyecto son:
Normalmente al aplicar Scrum se habla de un equipo de desarrollo de varias personas
y en este caso sólo existen dos personas para abordar el proyecto: el alumno que debe
realizar el proyecto fin de carrera, y el director que tiene la labor de orientar durante el
desarrollo del mismo.
En este caso concreto, el alumno no se puede dedicar a jornada completa al desarrollo
del proyecto. El motivo es que el alumno trabaja a tiempo completo en otros proyectos,
lo que hace que el número de horas diarias a dedicar sean muy limitadas, aumentando
la dificultad de la gestión y planificación del proyecto.
Roles asignados
Cuando se habla de Scrum se habla de equipos de desarrollo y en el caso de un proyecto
fin de carrera sólo hay un miembro de equipo, el alumno que lo va a realizar, y por otro
lado está el director de proyecto cuyo objetivo es orientar durante el desarrollo del proyecto.
Siguiendo el funcionamiento de Scrum es necesario que los principales roles del proceso
sean asignados, pero en este caso teniendo en cuenta el número tan reducido de personas con
las que se cuenta para que la asignación de los roles encajen lo mejor posible. Los roles se
van a asignar de la siguiente forma:
El dueño del producto será el director del proyecto pues tiene la capacidad de identi-

4. MÉTODO Y ENTORNO DE TRABAJO 45
ficar las prioridades que deben cumplirse para lograr tener un producto con la calidad
suficiente para que sea aceptado por el cliente. En este caso el cliente es el tribunal
que debe evaluar el proyecto, y el producto es el proyecto fin de carrera que siga la
normativa académica establecida.
El rol Scrum master será llevado a cabo por el alumno pues uno de los objetivos del
proyecto fin de carrera debe ser demostrar las aptitudes para la planificación y gestión
de proyectos.
El último rol por asignar es el de miembro de equipo que debe ser llevado a cabo por
el alumno, donde tendrá el papel de desarrollador.
Por tanto el director de proyecto asumirá la responsabilidad de establecer la prioridad de
las tareas siempre en comunicación con el Scrum master y será quién evalúe las entregas o
demostraciones realizadas al finalizar cada sprint.
El alumno a parte de llevar el trabajo de desarrollo deberá gestionar el proyecto, realizando
la estimación de las historias. Además la planificación de los sprints se deberán realizar con
la aprobación del dueño de producto.
Identificación de historias: pila de producto
La pila de producto, siguiendo en parte las indicaciones del libro anteriormente mencionado
[Kni07], se realizará de manera que a cada historia se le van a asignar los siguientes
campos:
ID: Es el identificador único de la historia que permite hacer el seguimiento durante
todo el desarrollo permitiendo así que cambie de nombre en algún momento si se
considera adecuado. El identificador usado será un numero entero para las historias,
y para las subhistorias un número decimal donde la parte entera será el identificador
de la historia padre. Así si una hay dos subhistorias que parten de la historia con id 3,
entonces esas subhistorias tendrán como ids 3.1 y 3.2 respectivamente.
Nombre: Es nombre descriptivo de la funcionalidad que representa, debe ser entendida
por el dueño de producto.
Descripción: Es una pequeña descripción con detalles concretos donde se explica en
qué consiste la historia.
Estimación: Es la estimación inicial del tiempo que va a tardar en realizar la historia.
La estimación se da en puntos historia que se explicarán más adelante.
Cómo probarlo: Es una descripción de los test que se deben realizar con éxito para
entender que la historia ha sido completada. Esto como se verá más adelante se podrá
utilizar como punto de entrada en el desarrollo dirigido por tests.

46 4. MÉTODO Y ENTORNO DE TRABAJO
Notas: Son detalles a tener en cuenta a la hora planificar la historia en algún sprint.
En estos detalles se pueden incluir por ejemplo las dependencias entre historias, de
manera que si el dueño de producto quiere alguna tarea que dependa de otra, ambas
deben ser planificadas en el sprint o esperar a que la dependencia esté terminada.
Importancia: Es valor numérico asignado por el dueño de producto y que prioriza la
pila de producto. No existe un valor máximo, simplemente cuanto mayor sea el número
más importante es la historia. Es recomendable no usar valores secuenciales a la hora
de asignar las prioridades para permitir, en caso de necesitarse, que las historias nuevas
puedan situarse entre medias de historias ya existentes.
Aunque en otros proyectos normalmente no se planifican todas las historias en sprints directamente,
sino que se planifican aquellas que corresponden a un sprint, es decir, se hace
una planificación de sprint en sprint; en este proyecto al tener una fecha límite para su finalización,
es necesario realizar la planificación completa para conocer así el tiempo que
se necesita para completarlo. Para ello se debe realizar la asignación de todas las tareas en
sprints y comprobar así si con esa planificación inicial se dispone del tiempo suficiente.
División en Sprints
En esta adaptación de Scrum se ha asignado a cada sprint una duración de una semana,
de manera que al final de cada semana se haga una reunión de sprint o se envíe un correo al
dueño del producto donde se muestren las historias completadas. El objetivo es analizar la
evolución del proyecto y de los productos semanalmente; de esta manera se permite detectar
las posibles desviaciones de tiempo muy rápidamente, puesto que en este caso concreto el
alumno no puede tener dedicación completa en el proyecto y eso provoca que toda desviación
pueda desembocar en un retraso excesivo. Así en el caso de detectar una desviación una
semana, se usará como medida correctora, siempre que sea posible, el aumento el número de
horas a dedicar en el siguiente sprint; una forma de aumentar el número de horas puede ser
mediante el uso de días de vacaciones del trabajo principal.
Para poder realizar la división en sprints primero hay que establecer la velocidad de desarrollo
del equipo de Scrum, y cómo se miden los puntos por historia. En este proyecto se
ha decidido que 4 puntos de historia corresponde a una semana de desarrollo dedicando 27
horas de trabajo que son las horas que el miembro del equipo puede dedicar sin hacer una
sobre-estimación, por tanto, la velocidad de equipo se establecerá en 4 puntos.
Herramienta para planificación
Para poder llevar la planificación se usará un documento de hojas de cálculo con tres hojas
donde se guardará toda la información necesaria para realizar la planificación siguiendo la
adaptación de Scrum:

4. MÉTODO Y ENTORNO DE TRABAJO 47
Semanas: en esta hoja se muestra la información de todas las semanas disponibles
hasta la fecha límite de entrega del proyecto, y en cada una de ellas toda la información
resumen de la planificación. Esta tabla tiene los siguientes elementos:
• Semana: indica el número de semana.
• Comienzo: indica que día del mes comienza la semana de trabajo.
• Fin: indica que día del mes en el que finaliza esa semana de trabajo.
• Objetivo: es el nombre del objetivo que persigue el sprint planificado esa semana.
• Historias: contiene los identificadores de las historias planificadas para esa semana.
• Velocidad estimada: es la velocidad que se ha estimado que tendrá el equipo.
• Velocidad real: es la velocidad final que el equipo ha tenido en esa semana.
• Completado Fecha: contiene la fecha real en la que se han terminado todas las
historias del sprint.
Historias: en esta hoja se muestra la información en detalle de todas las historias y
subhistorias con todos los elementos que contiene una historia excepto el campo que
indica la importancia. Esta hoja sirve para poder conocer los detalles concretos de
cada historia de manera que tiene como principales usuarios los roles de Scrum master
y miembro de equipo, puesto que será la hoja que usen para estimar y para conocer
que se debe implementar en cada historia.
Product Backlog: es la hoja que representa la pila de producto, y por tanto la que debe
usar el dueño de producto para priorizar las historias. Esta hoja contiene una tabla con
los siguientes elementos:
• ID: indica el identificador de la historia.
• Nombre: indica el nombre de la historia para que el dueño de producto pueda
identificarla mejor.
• Importancia: es el valor numérico que le debe asignar el dueño de producto,
cuanto mayor sea el valor más importancia tendrá. Las historias más importante
están más arriba de la pila siendo las primeras en implementarse.
• Estimación: son los puntos de historia estimados que indican la duración de esa
historia. Hay que tenerlos en cuenta a la hora de poder asignar historias a un
sprint.
• Sprint: Identificador del sprint al que se ha asignado la historia.
• Velocidad estimada: es la velocidad que se ha estimado que tendrá el equipo en
ese sprint.

48 4. MÉTODO Y ENTORNO DE TRABAJO
• Velocidad real: es la velocidad final que el equipo ha tenido en en ese sprint.
• Estado: indica si la historia ha sido completada, es decir, se ha probado que
cumple con lo establecido en el campo de cómo probarlo.
Las tres tablas anteriores en un documento de hojas de cálculo, junto con las opciones
que proporciona OpenOffice.org Calc como son la de reordenar por el valor de un campo,
añadir nuevas historias, mover elementos, etc; es suficiente para llevar la información de
planificación y gestión del proyecto.
4.1.4. Desarrollo dirigido por tests
El desarrollo dirigido por test o TDD es una técnica ágil de diseño y desarrollo de software
que se caracteriza por comenzar primero con la creación de los test unitarios que prueban
los requisitos del proyecto, creando a continuación el código que cumple con esas pruebas,
es decir, que a partir de esas pruebas se realiza la implementación de los requisitos. De esta
característica recibe su nombre, pues son los test unitarios los que dirigen el desarrollo. La
técnica de TDD se basa en tres pilares fundamentales [Car10] :
1. La implementación de sólo aquellas funciones que son necesarias, y ninguna más. Se
trata de evitar el hecho de generar código para tratar de adaptarse a posibles cambios,
cuando en realidad sólo se está tratando de prever futuros cambios, cosa en que las
metodologías ágiles no es necesario, pues frente a la necesidad de predicción está la
de adaptación.
2. Minimizar el número de defectos que se introducen en el software durante la fase de
producción.
3. Hacer que el software sea modular, altamente reutilizable y preparado para el cambio.
Para usar esta técnica hay que seguir un simple algoritmo de tres pasos.
Algoritmo TDD
El algoritmo para utilizar la técnica de TDD es el siguiente:
1. Escribir la especificación del requisito a través de un test.
2. Implementar el código que cumple con dicho requisito, es decir, que haga superar el
test.
3. Refactorizar el código duplicado.

4. MÉTODO Y ENTORNO DE TRABAJO 49
Figura 4.4: Algoritmo TDD: Rojo, Verde, Refactorizar.
A partir de estos simples pasos se consigue un código en el que se reduce mucho el número de
defectos introducidos, y cuyo diseño emerge a partir de las sucesivas refactorizaciones.
En la figura 4.4 se puede ver ilustrado el algoritmo de TDD donde se representan los pasos
usando los colores que suelen mostrar los frameworks de pruebas. Usando la metáfora de los
colores, los pasos son: rojo, verde y refactorizar.
1. El rojo representa el test escrito que falla al ejecutarse puesto que todavía no existe
una implementación del requisito a probar.
2. El verde representa que se supera el test, lo que indica que se ha escrito el código que
implementa el requisito y es correcto.
3. El último paso siempre es refactorizar.
Es muy importante que se siga el algoritmo manteniendo el orden y sin saltarse ningún
paso. La ventaja de definir primero los test es que se comprueban que estos fallan, pues a
veces los test están mal escritos y no fallan nunca por lo que no cumplen con su función. La
refactorización es muy importante pues va generando un diseño emergente más sencillo y
mantenible.
4.1.5. Adaptación de TDD al marco de trabajo
TDD es una técnica definida dentro de la programación extrema o XP que es una metodología
ágil de desarrollo. En el proyecto se adoptará esta técnica directamente como metodología
de desarrollo, sin usar otras técnicas definidas en XP.
El uso de TDD se complementa perfectamente con Scrum, pues cada historia lleva asociado
un campo llamado cómo probarlo que sirve de base para generar los test necesarios
con los que comienza el algoritmo de TDD. Al usar ese campo como base de las pruebas, se
está garantizando que cuando se termina de escribir el código de una historia, siguiendo el
algoritmo de TDD, se termina la historia, es decir, que cumple con lo establecido en el campo
cómo probarlo.

50 4. MÉTODO Y ENTORNO DE TRABAJO
4.2. Entorno de trabajo
Para poder llevar a cabo el proyecto, durante todo el desarrollo del mismo se ha hecho uso
de diferentes recursos software; a continuación, se comentan las más destacables agrupadas
según su tipo.
4.2.1. Herramientas de desarrollo
En esta sección se nombran aquellas herramientas que se han usado para llevar a cabo el
desarrollo del proyecto; entre ellas se encuentran las herramientas con las que se han generado
directamente los artefactos software, las librerías incluidas en el proyecto, las librerías
usadas para las llevar a cabo las pruebas y también el software usado para la gestión y controlar
del desarrollo.
NetBeans IDE
NetBeans IDE [Orab] es un entorno de desarrollo integrado (IDE) multiplataforma con
licencia libre para desarrollos realizados principalmente con el lenguaje de programación
Java, aunque a través de sus plugins también permite ser usado con de otros lenguajes como
C/C++, PHP, Ruby, etc. Gracias a la gran cantidad de plugins disponibles permite la
integración con gran cantidad de aplicaciones y frameworks.
Netbeans ha sido el IDE usado para el desarrollo de todos los artefactos software del proyecto:
librería, comando y servicio web.
Java Development Kit
El JDK o kit de desarrollo de Java [Oraa] es el software que proporciona las herramientas
necesarias para compilar, depurar y ejecutar programas en Java.
Para el desarrollo del proyecto se ha utilizado el JDK con versión 6.
Subversion
Subversion [Foub] es un sistema de control de versiones centralizado con licencia libre.
Subversion se ha usado tanto para el control de versiones de los tres artefactos de software
generados con el proyecto como para la documentación.
OpenOffice.org SDK
OpenOffice.org SDK [Orad] es un kit de desarrollo que proporciona las librerías con las
interfaces necesarias para hacer uso de las funcionalidades de la suite ofimática OpenOffice.org
desde otras aplicaciones, y además, permite crear nuevos componentes o extensiones
para incorporarlos a las aplicaciones que forman parte de la suite.
En el proyecto se ha hecho uso de OpenOffice.org SDK, concretamente de la versión 3.2,

4. MÉTODO Y ENTORNO DE TRABAJO 51
para proporcionar acceso a OpenOffice.org Calc desde la librería creada, y así incorporar
la funcionalidad necesaria para realizar las operaciones con documentos de hojas de cálculo.
JUnit
JUnit [KB] es un framework para realizar pruebas unitarias de aplicaciones escritas en
Java.
En el proyecto se ha usado JUnit con la versión 4.8.2, con el cual se han creado las clases
y método de pruebas unitarias y de integración usados para dirigir el desarrollo de los
diferentes artefactos software creados.
Mockito
Mockito [Fab] es un framework para realizar pruebas con el uso de mocks y objetos espía.
Un mock es un objeto sin funcionalidad que simula ser objeto de una determinada clase,
ofreciendo la posibilidad de ser programado para que frente a determinadas condiciones
tenga un cierto comportamiento, como puede ser el caso de lanzar una excepción si se llama
a un método con ciertos valores o simplemente devolver un valor concreto. Estos objetos
permiten que se registre el uso que se hace de ellos para posteriormente comprobar que se ha
hecho el uso esperado, comprobando los métodos invocados y los valores utilizados en las
llamadas.
Un objeto espía al contrario que un mock tiene la misma funcionalidad que la de cualquier
otro objeto de la clase que va a espiar, pero añadiendo las funcionalidades que proporciona
un mock, es decir, permite programar el comportamiento al realizar la invocación de ciertos
métodos y mantiene un registro del uso realizado del objeto.
Mockito se ha usado en el proyecto, concretamente la versión 1.8.5, para realizar pruebas
unitarias a través de sus mocks y objetos espías que han hecho posible realizar ciertas pruebas
bajo determinadas condiciones controladas y realizar la prueba de componentes de manera
aislada.
PowerMock
PowerMock [Jay] es un framework de pruebas que extiende las funcionalidades de otros
frameworks de mocks, a través de su cargador de clases personalizado y de la modificación
del bytecode, de manera que permite realizar la simulación de métodos estáticos y privados.
PowerMock puede ser usado con los frameworks EasyMock y Mockito.
PowerMock se ha usado en el proyecto, concretamente la versión 1.4.8, para aumentar
la funcionalidad de Mockito, de manera que en la pruebas unitarias fuera posible simular y

52 4. MÉTODO Y ENTORNO DE TRABAJO
espiar métodos estáticos y privados.
Groovy
Groovy [Spr] es un lenguaje de programación interpretado e implementado sobre la plataforma
Java, y que proporciona una librería con el interprete del lenguaje y con todo lo
necesario para permitir el uso de este en otras aplicaciones Java.
En el proyecto se ha usado la librería de Groovy, versión 1.7.9, para incorporar funcionalidades
del interprete del lenguaje tanto en el comando como en el servicio web generados.
JAX-WS
JAX-WS [com] es un API de Java de código abierto para construir servicios web, siendo
la implementación de referencia de la plataforma Java EE.
JAX-WS, versión 2.2.3, se ha utilizado para crear el servicio web del proyecto.
Apache Tomcat
Apache Tomcat [Fouc] es un contenedor de servlets de Java de código abierto. Apache
Tomcat implementa las especificaciones de los servlets y de JavaServer Pages.
En el proyecto se ha usado Apache Tomcat, versión 6.0, como contenedor de pruebas para
el despliegue del servicio web desarrollado.
OpenOffice.org Calc
OpenOffice.org Calc [Orac] es una aplicación libre de hojas de cálculo que pertenece a la
suite ofimática de OpenOffice.org.
En el proyecto se ha usado esta aplicación para dos propósitos diferentes, por un lado
se ha usado para realizar las pruebas de la librería desarrollada, puesto que hace uso de las
funcionalidades de Calc para realizar diferentes operaciones con documentos de hojas de
cálculo; y por otro lado, se ha usado como editor del documento de hoja de cálculos con el
que se ha realizado toda la planificación y gestión de proyecto.
4.2.2. Lenguajes de programación
En esta sección se nombran aquellos lenguajes de programación usados para el desarrollo
del proyecto.
Java
Java es un lenguaje de programación de alto nivel orientado a objetos, que fue desarrollado
por James Gosling en Sun Microsystem y liberado en 1995. Java toma en su sintaxis
muchos elementos de C y C++, e incorpora mecanismos para una gestión automática de la

4. MÉTODO Y ENTORNO DE TRABAJO 53
memoria.
Las aplicaciones Java pueden ser multiplataforma gracias a que son compiladas en un lenguaje
intermedio llamado bytecode y que es interpretado por la Máquina Virtual de Java o
JVM, de manera que pueden ejecutarse en cualquier plataforma que cuente con una implementación
de JVM.
Todos los artefactos software del proyecto: la librería, el comando y el servicio web, han
sido desarrollados usando Java como lenguaje de programación.
Groovy
Groovy [Spr] es un lenguaje de programación, interpretado y orientado a objetos, implementado
sobre la plataforma Java. Este lenguaje tiene una sintaxis muy parecida a Java, y
permite utilizar tanto APIs como librerías de Java desde los scripts; además, las clases de
Groovy pueden ser usadas desde aplicaciones Java, al poder ser compiladas en bytecode
entendible por la Máquina Virtual de Java o JVM.
Groovy ha sido usado en el proyecto para crear los scripts de funcionalidad básica que
ofrecen tanto el comando como el servicio web desarrollados.
4.2.3. Herramientas de documentación
En esta sección se nombran aquellas herramientas utilizadas para llevar a acabo toda la
documentación del proyecto.
L A TEX
L A TEX [Pro] es un sistema de composición de textos usado como estándar de facto para la
publicación de documentos científicos.
Para el desarrollo de la memoria del proyecto se ha utilizado L A TEX.
Eclipse con Texlipse
Eclipse [Foue] es un entorno de desarrollo integrado o IDE multiplataforma y de código
abierto para desarrollos realizados principalmente con el lenguaje de programación Java,
aunque a través de sus plugins también permite ser usado con de otros lenguajes como
C/C++, PHP, etc.
Texlipse [OKvLV] es un plugin de Eclipse IDE para soporte de proyectos en L A TEX.
En el proyecto se ha usado Eclipse con el plugin Texlipse para el desarrollo de la documentación
en L A TEX.

54 4. MÉTODO Y ENTORNO DE TRABAJO
Umbrello UML Modeller
Umbrello UML Modeller [umb] es una herramienta de código abierto que permite crear
diagramas UML.
En el proyecto se ha usado la herramienta Umbrello para la creación de los casos de usos
y el resto de diagramas UML incluidos en la documentación.
Gimp
Gimp [Tea] es una aplicación software para edición de imágenes digitales de código abierto.
Gimp se ha utilizado en el proyecto para la edición de imágenes usadas en la documentación.
Inkscape
Inkscape [ink] es una aplicación libre para la generación de imágenes vectoriales. Inkscape
se ha utilizado en el proyecto para la generación de imágenes usadas en la documentación.
OpenOffice.org Draw
OpenOffice.org Draw [ooo] es una aplicación software para la generación de imágenes
perteneciente a la suite OpenOffice.org.
OpenOffice.org Draw se ha utilizado en el proyecto para la generación de imágenes usadas
en la documentación.
4.2.4. Sistemas Operativos
En esta sección se nombran los sistemas operativos usados durante el desarrollo del proyecto.
Ubuntu GNU/Linux
Para el desarrollo del proyecto y su documentación se ha usado el sistema operativo Ubuntu
GNU/Linux compilado para la arquitectura i386.
Windows Vista
El sistema operativo Windows Vista, en su versión de 32 bits, ha sido utilizado únicamente
para realizar las pruebas que permiten comprobar la compatibilidad con Windows de cada
uno de los artefactos software generados.

Capítulo 5
Resultados
EN este capítulo se van a explicar los resultados obtenidos al aplicar el método de trabajo
descrito en el capítulo anterior. Para explicar los resultados el capítulo se divide
en diferentes secciones, donde en la primera sección se va a explicar la fase de análisis y
planificación, luego a lo largo de diferentes secciones se explicará el desarrollo de los sprints
realizados para cumplir con los objetivos del proyecto, y por último se dedicará una sección
por cada uno de los cuatro artefactos resultantes de la ejecución del proyecto.
5.1. Análisis y planificación
En esta sección se explica el desarrollo de la primera fase del proyecto que se corresponde
con la fase de análisis y planificación en la cual se han realizado las siguientes tareas:
1. Análisis de los requisitos u objetivos del proyecto.
2. Estudio de viabilidad de las alternativas.
3. Planificación del proyecto.
A continuación, se describirá cada una de las tareas.
5.1.1. Análisis de requisitos
A partir del análisis de los objetivos del proyecto, ya explicados con detalle en el capítulo
3, y de los requisitos establecidos por la normativa académica para proyectos fin de carrera
vigente, se pueden extraer 4 historias principales que deben ser abordadas por el proyecto.
1. Librería (API): es la librería que permite la manipulación de documentos de hojas de
cálculo, con las funcionalidades necesarias para crear nuevos documentos, modificarlos,
cambiar el formato y extraer datos.
2. Comando: es un comando preparado para ejecutarse desde un terminal que hace uso
de la librería que permite la manipulación de documentos hojas de cálculo y ofrece su
funcionalidad con la posibilidad de automatizarse.
55

56 5. RESULTADOS
3. Servicio web: es un servicio web que hace uso de la librería que permite la manipulación
de documentos de hojas de cálculo, ofreciendo su funcionalidad para que pueda
ser usada de manera remota.
4. Memoria del proyecto: es la documentación oficial del proyecto exigida por la normativa
académica.
A continuación, se van a realizar un análisis de los requisitos.
Librería (API)
Para analizar este requisito u objetivo y poder identificar los actores con los que debe
interactuar se han generado un diagrama de casos de uso básico.
En la figura 5.1 se puede ver el diagrama de casos de uso básico. En este diagrama se
pueden distinguir dos actores que van a actuar en el escenario de la librería o API:
Aplicación: es la aplicación que va a usar la librería o API de OpenSheet para poder
trabajar con documentos de hojas de cálculo.
Framework o alternativa: es la alternativa que va a usar la librería o API para poder
llevar a cabo la funcionalidad con documentos de hojas de cálculo ofrecida. Es decir,
la librería va a ser una capa de abstracción de alguna de las alternativas estudiadas en
el capítulo de antecedentes.
Figura 5.1: Diagrama de casos de uso básico de API
Además, se pueden distinguir cuatro casos de uso que hacen referencia a los objetivos
específicos 2, 3 y 4 que hacen referencia a las operaciones que se deben permitir:

5. RESULTADOS 57
Crear documento de hojas de cálculo: este caso de uso contempla la operación de
creación de nuevos documentos de hojas de cálculo para poder trabajar con ellos, y
luego poder almacenar las modificaciones realizadas.
Modificar documentos de hojas de cálculo: este caso de uso contempla las siguientes
operaciones:
• Inserción de datos en las distintas celdas de las hojas de cálculo del documento.
• Creación de nuevas hojas de cálculo dentro de un documento.
• Eliminación de hojas de cálculo existentes en un documento.
Extracción de datos de un documento de hojas de cálculo: este caso de uso contempla
la operación de extracción de datos, tanto numéricos como de texto, de las celdas que
forman parte de las distintas hojas de cálculo del documento
Convertir el formato de un documento de hojas de cálculo: este caso de uso contempla
las operaciones que permiten cumplir con los objetivos 3 y 4, es decir, permitir la conversión
de un formato de documento de hojas de cálculo a otro de manera automática,
y además la exportación a PDF.
Comando y servicio web
Estos elementos son las que hacen de actor como aplicación en el diagrama de casos de
uso de la librería, ver figura 5.1, por tanto ambos se pueden incluir en dicho diagrama e
identificar los actores con los que van a interactuar. En la figura 5.2 se puede ver el diagrama
de casos de uso básico.
Figura 5.2: Diagrama de casos de uso básico del comando y servicio web
A partir del diagrama de casos de uso de la librería o API se ha identificado la necesidad
de usar una alternativa o framework que permita trabajar con hojas de cálculo; para ello

58 5. RESULTADOS
se realizará un estudio de viabilidad de las alternativas analizadas en el capítulo de antecedentes
para seleccionar una de ellas como alternativa sobre la que se construirá la librería
OpenSheet.
5.1.2. Estudio de viabilidad de alternativas
Para poder seleccionar una alternativa que sirva para facilitar el trabajo de la API con
documentos de hojas de cálculo y que le permita lograr sus objetivos siendo compatible con
la licencia del proyecto, ha sido necesario realizar un estudio de viabilidad de las diferentes
alternativas, que además ha servido como documentación base para generar el capítulo de
antecedentes.
De entre todas las alternativas estudiadas la única que permite realizar las operaciones
definidas en los requisitos, trabajar con los formatos deseados y además es compatible con el
tipo de licencia del proyecto, es la de usar OpenOffice.org a través de UNO. Esta alternativa
además de ser totalmente viable por cumplir con los requisitos de funcionalidad y licencia,
gracias a la cantidad de documentación de desarrollo y uso que existe, al gran soporte y
actividad que aporta tanto la comunidad como los desarrolladores, es la que se considera la
mejor alternativa para utilizar como base en la creación de la librería OpenSheet.
Por tanto, la librería OpenSheet va a ofrecer una interfaz de uso sencilla que por dentro
realizará todas las operaciones necesarias para hacer uso de las funcionalidades ofrecidas
por OpenOffice.org Calc. De esta manera se aisla a las aplicaciones que usen OpenSheet
de la complejidad de usar directamente las funcionalidades de OpenOffice.org a través de
UNO.
5.1.3. Planificación
Una vez se han identificado las historias principales a partir del análisis de requisitos y
se ha seleccionado la alternativa o framework que se va a utilizar para llevar a cabo las
operaciones con documentos de hojas de cálculo, se puede comenzar la planificación del
proyecto haciendo uso de Scrum.
Preparación de la pila de producto
Lo primero consiste en analizar las cuatro historias identificadas y tratar de estimar los
puntos que les corresponde a cada una, y dividirlas en subhistorias si es necesario, de manera
que se complete la pila de producto inicial.
Las historias son divididas en subhistorias y estimadas por el Scrum master, es decir, por el
alumno. Mientras que la prioridad o importancia de cada una, que indican el orden en el que
tienen que ser implementadas, es una tarea del dueño del producto, es decir, del director del
proyecto; aunque el Scrum master presentar un orden que puede ser tomado como referencia

5. RESULTADOS 59
por el dueño de producto.
Cuadro 5.1: Pila de producto inicial
ID Nombre Descripción Estimación Importancia
1 Librería
(API)
1.1 Crear nuevos
documentos
1.5 Convertir el
formato del
documento
1.2 Abrir documentos
1.3 Modificar hojas
de cálculo
a un documento
1.4 Insertar valores
en celdas
1.6 Extraer valores
de celdas
Librería que permite la manipulación
de hojas de cálculo. Permite
crear nuevos documentos, modificarlos,
cambiar el formato y extraer datos.
13.5 ptos 500
Se debe poder crear nuevos documentos
3 ptos 500
que tengan uno de los forma-
tos permitidos (Excel y OO) a partir
de un path (incluyendo el nombre del
mismo) y permitir guardarlo.
Permitir salvar el documento con 0.5 ptos 492
otro formato diferente (incluyendo
PDF).
Se debe poder abrir un documento
(en segundo plano) ya existente
a partir de su ruta. Además una vez
abierto se debe poder recuperar sus
pestañas u hojas de cálculo.
3 ptos 490
Se debe poder realizar las siguientes
1 ptos 480
operaciones a un documento: 1)
Añadir una nueva hoja de cálculo
(tanto con un nombre como sin nombre).
2) Borrar una hoja de cálculo
(por nombre o posición). 3) Renombrar
una hoja de cálculo.
Se debe permitir insertar valores de 3 ptos 470
la siguiente forma: 1) Insertar un valor
de una celda. 2) Insertar un grupo
de valores en un rango de celdas.
Se debe permitir extraer valores de la
siguiente forma: 1) Extraer un valor
de una celda. 2) Extraer un grupo de
valores de un rango de celdas.
3 ptos 460

60 5. RESULTADOS
ID Nombre Descripción Estimación Importancia
2 Comando Comando que hace uso de la librería
que permite la manipulación de
hojas de cálculo. Permite crear nuevos
documentos, modificarlos, cambiar
el formato y extraer datos.
10.5 ptos 400
2.1 Crear nuevos
documentos
2.2 Abrir documentos
2.3 Modificar hojas
de cálculo
a un documento
2.4 Insertar valores
en celdas
2.5 Convertir el
formato del
documento
2.6 Extraer valores
de celdas
4.6 Objetivos
PCF
Se debe poder crear nuevos documentos
que tengan uno de los formatos
permitidos (Excel y OO) a partir
de un path (incluyendo el nombre del
mismo) y permitir guardarlo.
4 ptos 400
Se debe poder abrir un documento
1 ptos 390
(en segundo plano) ya existente
a partir de su ruta. Además una vez
abierto se debe poder recuperar sus
pestañas u hojas de cálculo.
Se debe poder realizar las siguientes
1 ptos 380
operaciones a un documento: 1)
Añadir una nueva hoja de cálculo
(tanto con un nombre como sin nombre).
2) Borrar una hoja de cálculo
(por nombre o posición). 3) Renombrar
una hoja de cálculo.
Se debe permitir insertar valores de 2 ptos 370
la siguiente forma: 1) Insertar un valor
de una celda. 2) Insertar un grupo
de valores en un rango de celdas.
Permitir salvar el documento con
otro formato diferente (incluyendo
PDF).
0.5 ptos 360
Se debe permitir extraer valores de la 2 ptos 350
siguiente forma: 1) Extraer un valor
de una celda. 2) Extraer un grupo de
valores de un rango de celdas.
Realizar el capítulo de objetivos del 2 ptos 320
proyecto.

5. RESULTADOS 61
ID Nombre Descripción Estimación Importancia
3 Servicio Web Servicio web que hace uso de la
librería que permite la manipulación
de hojas de cálculo. Permite
crear nuevos documentos, modificarlos,
cambiar el formato y extraer datos.
9.5 ptos 300
3.1 Crear nuevos
documentos
3.2 Abrir documentos
3.3 Modificar hojas
de cálculo
a un documento
3.4 Insertar valores
en celdas
3.5 Convertir el
formato del
documento
3.6 Extraer valores
de celdas
Se debe poder crear nuevos documentos
que tengan uno de los formatos
permitidos (Excel y OO) a partir
de un path (incluyendo el nombre del
mismo) y permitir guardarlo.
2 ptos 300
Se debe poder abrir un documento
1 ptos 290
(en segundo plano) ya existente
a partir de su ruta. Además una vez
abierto se debe poder recuperar sus
pestañas u hojas de cálculo.
Se debe poder realizar las siguientes
1 ptos 280
operaciones a un documento: 1)
Añadir una nueva hoja de cálculo
(tanto con un nombre como sin nombre).
2) Borrar una hoja de cálculo
(por nombre o posición). 3) Renombrar
una hoja de cálculo.
Se debe permitir insertar valores de 2 ptos 270
la siguiente forma: 1) Insertar un valor
de una celda. 2) Insertar un grupo
de valores en un rango de celdas.
Permitir salvar el documento con
otro formato diferente (incluyendo
PDF).
0.5 ptos 260
Se debe permitir extraer valores de la 2 ptos 250
siguiente forma: 1) Extraer un valor
de una celda. 2) Extraer un grupo de
valores de un rango de celdas.
4 Documentación Se debe realizar la memoria del proyecto
18 ptos 200
necesaria para cumplir con la
normativa académica.

62 5. RESULTADOS
ID Nombre Descripción Estimación Importancia
4.1 Introducción Realizar el capítulo de introducción. 2 ptos 200
4.2 Antecedentes Realizar el capítulo de estudio del estado
4 ptos 190
del arte.
4.5 Método de Realizar el capítulo de método de trabajo.
3 ptos 160
trabajo
4.6 Resultados Realizar el capítulo de método de resultados.
2 ptos 150
4.7 Conclusiones Realizar el capítulo de método de 2 ptos 140
conclusiones.
4.3 Manual de Realizar un manual para uso de 2 ptos x
UNO UNO.
A partir de la presentación de la pila de producto con las subhistorias, el dueño de producto
en función de las estimaciones ha asignado la importancia a cada historia, en la mayoría
de los casos respetando el orden inicial dado, pero en otros el orden ha sido cambiado para
poder incluir en cada sprint el máximo número de historias.
Como se puede ver en la tabla 5.1, cada historia se ha dividido en subhistorias y se ha
estimado de la siguiente manera:
1. Librería (API): se ha estimado en 13.5 puntos y se ha dividido en seis subhistorias.
2. Comando: se ha estimado en 10.5 puntos y se ha dividido en seis subhistorias.
3. Servicio web: se ha estimado en 9.5 puntos y también se ha dividido en seis subhistorias.
4. Documentación: se ha estimado en 18 puntos y se ha dividido en siete subhistorias.
Además, el dueño de producto en principio no ha asignado ningún valor a la importancia
de la historia 4.3 y aunque en principio se mantiene en la pila de producto posiblemente se
elimine pues la generación de un manual de UNO queda fuera de la memoria, y en todo caso
sería incluido a modo de apéndice.
División en sprints
Una vez se tienen estimadas y priorizadas las historias se deben dividir en sprints, puesto
que el dueño de producto las ha priorizado teniendo sobre todo en cuenta el maximizar el

5. RESULTADOS 63
número de historias en cada sprint, simplemente basta con ir cogiendo historias intentando
que la suma de puntos estimados quede lo más cerca posible de 4.
Con la pila de producto inicial, que puesto que es una metodología ágil se permite que
cambie con forme se avance en el desarrollo del proyecto y se detecten nuevas necesidades,
se han planificado todas las historias, excepto la 4.3, en 13 sprints:
Sprint 1: Crear documentos y guardarlos
Historias : 1.1, 1.5
Velocidad estimada : 3.5
Sprint 2: Abrir y modificaciones de hojas
Historias : 1.2, 1.3
Velocidad estimada : 4
Sprint 3: Modificaciones de Celdas
Historias : 1.4
Velocidad estimada : 3
Sprint 4: Extraer información de documentos
Historias : 1.6
Velocidad estimada : 3
Sprint 5: Crear documentos con el comando
Historias : 2.1
Velocidad estimada : 4
Sprint 6: Abrir y modificar documentos con el comando
Historias : 2.2, 2.3, 2.4
Velocidad estimada : 4
Sprint 7: Extraer datos y cambiar formato con el comando
Historias : 2.5, 2.6, 4.4
Velocidad estimada : 4.5
Sprint 8: Web service (crear y abrir documentos)
Historias : 3.1, 3.2

64 5. RESULTADOS
Velocidad estimada : 4
Sprint 9: Web service (modificar documentos y conversiones de formato)
Historias : 3.3, 3.4, 3.5
Velocidad estimada : 3.5
Sprint 10: Web service (extraer valores) y Documentación 1
Historias : 3.6, 4.1
Velocidad estimada : 4
Sprint 11: Documentación 2
Historias : 4.2
Velocidad estimada : 4
Sprint 12: Documentación 3
Historias : 4.5
Velocidad estimada : 3
Sprint 13: Documentación 4
Historias : 4.6, 4.7
Velocidad estimada : 4
Una vez se ha explicado la planificación de comienzo del proyecto, en las siguientes secciones
se describirá el desarrollo de cada sprint, donde han aparecido cambios que han modificado
las historias y por tanto han variado la planificación inicial en duración y en el número
de sprints.
5.2. Sprint 1: Creación y almacenamiento de documentos
En este primer sprint las historias de producto planificadas son:
Historia 1.1: Crear nuevos documentos
Historia 1.5: Convertir el formato del documento
Ambas historias forman parte de la historia 1 que se corresponde con la creación de una librería
o API para la manipulación de documentos de hojas de cálculo. Por tanto como resultado
de este sprint se obtendrá esa librería de la historia 1 pero con funcionalidad reducida, siendo

5. RESULTADOS 65
ID Nombre Descripción Estimación Importancia Notas
1.1 Crear nuevos Se debe poder crear nuevos documentos
3 ptos 500
documentos
que tengan uno de
los formatos permitidos (Excel
y OO) a partir de un path (incluyendo
el nombre del mismo) y
permitir guardarlo.
1.5 Convertir el Permitir salvar el documento 0.5 ptos 492
formato del con otro formato diferente (incluyendo
documento
PDF).
Cuadro 5.2: Historias añadidas al Sprint 1
esta la proporcionada por cada una de las historias planificadas. La información resumen de
las historias planificadas se puede ver en la tabla 5.2.
A la hora de asignar las historias al sprint, se ha tenido en cuenta que coincide con el comienzo
del proyecto y en lugar de tratar de planificar 4 puntos de historia, que es lo definido
como la carga normal, se ha aumentado la prioridad de la historia 1.5 de manera que entre
en este sprint y los puntos de historia totales planificados sean 3.5.
A partir de las historias planificadas se define el objetivo del sprint. El objetivo perseguido
por este sprint es el de proporcionar una API o librería con la funcionalidad necesaria para
crear documentos de hojas de cálculo y almacenarlos.
A continuación, se va a detallar el desarrollo de cada una de las historias planificadas en
este sprint.
5.2.1. Historia 1.1 - Crear nuevos documentos
La historia 1.1 consiste en añadir a la librería la funcionalidad necesaria para crear nuevos
documentos de hojas de cálculo, con uno de los formatos admitidos, y guardarlos a partir del
path con el nombre del fichero.
Esta historia se puede dividir a su vez en dos tareas: implementar el mecanismo de comunicación
con OpenOffice.org Calc, e implementar el código necesario para completar crear
y guardar nuevos documentos.
Mecanismo de comunicación con OpenOffice.org Calc
Al ser la primera subhistoria que se implementa de la historia 1, librería (API), conlleva
la tarea, ya incluida en la estimación, de implementar el mecanismo de comunicación con
OpenOffice.org Calc. Esta tarea es diferente al resto de los requisitos pues no se va a usar el
algoritmo de TDD para llevarla a cabo, si no que se va a implementar directamente a partir del
uso del mecanismo de la clase Bootstrap proporcionada por el SDK de OpenOffice.org.
Al usar el mecanismo de Bootstrap en GNU/Linux se han encontrado dos principales pro-

66 5. RESULTADOS
blemas:
1. No se encuentra el binario de soffice, y se produce el error no office executable found!.
2. Una vez solucionado el problema anterior, al usarse las funciones de UNO para conectarse
con OpenOffice.org Calc dentro de la clase Bootstrap que hacen uso de librerías
dinámicas, estas no se localizan y se produce el error java.lang.UnsatisfiedLinkError:
createJNI at com.sun.star.lib.connections.pipe.PipeConnection.createJNI.
El primer problema se produce porque la clase Bootstrap intenta crear el proceso soffice
usando como directorio la ubicación del fichero de la clase, es decir, donde se encuentra
el fichero juh.jar, y como en GNU/Linux por defecto los jars necesarios para usar UNO no
se distribuyen por defecto con OpenOffice.org y tampoco se instalan en ese directorio, el
usuario debe conocer este problema para poder solucionarlo copiando los jars necesarios en
el directorio donde se encuentre el fichero ejecutable soffice, y luego poner en el classpath
este directorio para que la librería pueda encontrarlos para su uso. Esto complica bastante
al usuario que no le basta sólo con conocer donde tiene el directorio donde se encuentra el
ejecutable de OpenOffice.org.
El segundo problema se produce porque dentro de la clase Bootstrap una vez se ha arrancado
el proceso soffice con los parámetros necesarios para conectarse a través de una tubería
o pipe, al usar el método para crear una conexión desde java, este hace uso de una librería
dinámica que no se encuentra en el directorio del jar ni en el path y esto provoca que se
produzca una excepción java.lang.UnsatisfiedLinkError. Para solucionarlo el usuario debe
poner al ejecutar el jar en la variable java.library.path, el directorio donde se encuentran las
librerías necesarias, tal y como se puede ver en el listado 5.1. Esto también complica todavía
más el uso de la librería.
-Djava.library.path=/usr/lib/ure/lib
Listado 5.1: Añadiendo un directorio a Java Library Path
Para dar una solución a ambos problemas encontrados, haciendo lo más transparente posible
al usuario los problemas de localización de dependencias, se ha modificado la clase
Bootstrap y se han utilizado las clases proporcionadas por el SDK para localizar el directorio
de instalación, de manera que los jars necesarios se sitúan en un directorio lib junto a la librería,
y de forma automática se busca correctamente la ubicación del ejecutable de OpenOffice
y se añade el directorio de las librerías dinámicas al java library path.
Los cambios realizados en la clase Bootstrap han sido los siguientes:

5. RESULTADOS 67
1. Ahora el bootstrap() recupera a partir de la llamada a getPath() de la clase Installation-
Finder 1 la ruta donde se encuentra el ejecutable de OpenOffice.org, y es esa ruta la que
se usa en lugar de coger el path a la clase del Bootstrap. En el listado 5.2 se puede ver
comentada como se obtenida la ruta antes, y a continuación se puede ver como se usa
ahora un array de objetos URL que contienen la ruta recuperada a través de la clase
InstallationFinder.
2. Se ha creado una función setLibraryPath() que se llama en el método bootstrap y
que resetea los valores asignados a la propiedad java.library.path de manera que le
pueda asignar el directorio donde se encuentra el ejecutable y otros directorios donde
se puede encontrar las librerías dinámicas necesarias.
Tanto la clase Bootstrap modificada como las clases para localizar el directorio de instalación
de OpenOffice.org han sido incluidas en un paquete de la librería.
/* File fOffice = NativeLibraryLoader.getResource(
Bootstrap.class.getClassLoader(), sOffice); */
File fOffice = NativeLibraryLoader.getResource(loader, sOffice);
Listado 5.2: Cambio la localización del path del ejecutable en la clase Bootstrap
Crear nuevos documentos
Para poder llevar a cabo esta tarea se ha utilizado el algoritmo de TDD pero con la decisión
de que las pruebas no incluirán el uso de mocks u objetos que simulen el comportamiento
de OpenOffice.org Calc, si no que a pesar de que se aumente un poco los tiempos se va usar
directamente los objetos remotos reales.
Para empezar a crear los test que sirven para realizar la implementación de la tarea, se ha
utilizado como base el campo de la historia cómo probarlo donde se especifican las pruebas
que se deben cumplir para determinar que la historia se ha implementado correctamente:
1. Crear un nuevo documento docNuevo.ods y guardarlo. Comprobar que existe el fichero
y se puede abrir.
2. Repetir la prueba 1 con el documento docNuevo.xls.
3. Repetir la prueba 1 con los documentos plantillas docPlantilla.xlt y docPlantilla.odst.
4. Al abrir estos documentos deben abrirse como cualquier otra plantilla (no deben permitir
su modificación directamente si no generar un nuevo documento).
1 Esta clase viene en el SDK de UNO OpenOffice.org

68 5. RESULTADOS
5. Intentar crear nuevamente el documento docNuevo.ods (debe ya existir), al intentar
crear un documento ya existente debe fallar la creación devolviendo un error.
Las pruebas realizadas basadas en el campo cómo probarlo han sido las siguientes:
Prueba unitarias de creación de documentos para cada uno de los tipos de ficheros
permitidos. A partir de la refactorización en las propias pruebas se ha creado un método
createNewDocument que es el que realmente realiza las comprobaciones dejando en
el resto sólo el nombre y la extensión a probar; de esta manera se evita la repetición de
código innecesaria.
Pruebas para la exportación a PDF.
Pruebas unitarias para provocar excepciones de manera que estás se incluyan en el
código. Estas excepciones son cuando no se soporta la extensión del fichero, cuando
no tiene extensión o cuando se llama a exportar a PDF sin la extensión correcta.
A partir de las pruebas anteriores han emergido los siguientes elementos de diseño:
OpenSheetManager: es una clase que sigue el patrón factoría y que permite recuperar
objetos que implementan la interfaz IOpenSheetDocument de manera transparente.
IOpenSheetDocument: es la interfaz que proporciona el acceso a las funcionalidades
de un documento de hojas de cálculo. En este punto sólo se proporciona el método
para close() cerrarlo.
OpenSheetDocument: es la clase que representa un documento de hojas de cálculo
y que por tanto hace uso de los objetos necesarios de UNO y OpenOffice.org, implementando
además la interfaz IOpenSheetDocument.
OverwriteOpenSheetDocumentException: excepción que se produce cuando se intenta
crear un nuevo documento y ya existe un fichero con ese nombre.
UnsupportedOpenSheetDocumentException: excepción que se produce cuando no
se soporta la extensión del fichero a crear.
Estos elementos creados a partir de las pruebas y la refactorización cumplen con lo especificado
para determinar que la historia está completa, para ello basta con ejecutar las pruebas
usadas en el algoritmo de TDD para su implementación.

5. RESULTADOS 69
5.2.2. Historia 1.5 - Convertir el formato del documento
Para empezar a crear los test que sirven para realizar la implementación de la historia, se ha
utilizado como base el campo de la historia cómo probarlo donde se especifican las pruebas
que se deben cumplir para determinar que la historia se ha implementado correctamente:
1. Abrir un documento en formato ods y guardarlo con el mismo nombre en diferentes
formatos: xls, xlt, odst y pdf.
2. Repetir la prueba 1 con los formatos permitidos.
3. Abrir un documento y salvarlo en un formato no permitido, debe fallar y devolver un
error.
Las pruebas realizadas basadas en el campo cómo probarlo han sido las siguientes:
Prueba unitarias de salvado entre los distintos tipos de ficheros permitidos. A partir
de la refactorización en las propias pruebas se ha creado un método saveAsDocument
que es el que realmente realiza las comprobaciones dejando en el resto el fichero de
origen con su extensión y el fichero al que se quiere convertir; de esta manera se evita
la repetición de código innecesaria.
Pruebas unitarias para provocar excepciones de manera que estás se incluyan en el
código. Estas excepciones son cuando no se soporta la extensión del fichero, cuando
no tiene extensión o cuando ya existe un mismo documento con ese nombre.
A partir de las pruebas anteriores se han añadido los siguientes métodos a las clases IOpenSheetDocument
y a OpenSheetDocument:
saveAs(String documentPath): es el método que permite almacenar el documento y
también guardarlo con otro formato.
exportToPDF(String documenPath): es el método que permite exportar el documento
de hojas de cálculo al formato PDF.
Estos elementos creados a partir de las pruebas y la refactorización cumplen con lo especificado
para determinar que la historia está completa, para ello basta con ejecutar las pruebas
usadas en el algoritmo de TDD para su implementación.
5.2.3. Resumen de sprint
En el sprint se han completado las dos historias planificadas en el plazo establecido. En el
gráfico de burndown, ver la figura 5.3, se puede ver la evolución del mismo.

70 5. RESULTADOS
Figura 5.3: Gráfico de burndown del sprint 1
En el gráfico se puede observar el poco avance los primeros días, esto es debido al tiempo
dedicado a la resolución de los problemas encontrados en la tarea de la conexión con OpenOffice.org
Calc, como se ha explicado en detalle en la historia 1.1, y la recuperación se
produce una vez se han realizado los primeros tests y su refactorización, que han permitido
aumentar la velocidad del desarrollo.
En este sprint como resultado se ha obtenido una primera versión de la librería que contiene
la funcionalidad de crear documentos de hojas de cálculo y guardarlos. En la figura 5.4
se puede ver el diseño de clases resultante, no se han añadido al diagrama las clases que
representan excepciones para aumentar la legibilidad.
5.3. Sprint 2: Apertura de documentos y modificación de
hojas
En este sprint las historias de producto planificadas son:
Historia 1.2: Abrir documentos
Historia 1.3: Modificar hojas de cálculo de un documento
Ambas historias forman parte de la historia 1, al igual que el sprint anterior, y por tanto
como resultado de este sprint se obtendrá la librería para manipulación de documentos de
hojas de cálculo pero con funcionalidad reducida. La funcionalidad de la librería resultante
será la del sprint anterior más la proporcionada por cada una de las historias planificadas. La
información resumen de las historias planificadas se puede ver en la tabla 5.3.

5. RESULTADOS 71
Figura 5.4: Diagrama de clases resultante del sprint 1
En este caso se las dos tareas asignadas suman 4 puntos de historia a realizar en el sprint,
que es lo que se ha considerado una carga normal.
A partir de las historias planificadas se define el objetivo del sprint. El objetivo perseguido
por este sprint es el de proporcionar a la API o librería del sprint anterior la funcionalidad
necesaria para abrir documentos de hojas de cálculo, y realizar modificaciones en la hojas de
cálculo de los documentos.
A continuación, se va a detallar el desarrollo de cada una de las historias planificadas en
este sprint.
5.3.1. Historia 1.2 - Abrir documentos
Para empezar a crear los test que sirven para realizar la implementación de la historia, se ha
utilizado como base el campo de la historia cómo probarlo donde se especifican las pruebas
que se deben cumplir para determinar que la historia se ha implementado correctamente:
1. Abrir un documento docExample.ods, comprobar tanto el número como el nombre de
sus pestañas u hojas de cálculo.
2. Repetir la prueba 1 con los formatos soportados.

72 5. RESULTADOS
ID Nombre Descripción Estimación Importancia Notas
1.2 Abrir documentomento
Se debe poder abrir un docu-
3 ptos 490
(en segundo plano) ya
existente a partir de su ruta.
Además una vez abierto se debe
poder recuperar sus pestañas
u hojas de cálculo.
1.3 Modificar hojas
de cálculo
a un documento
Se debe poder realizar las siguientes
operaciones a un documento:
1) Añadir una nueva hoja
de cálculo (tanto con un nombre
como sin nombre). 2) Borrar
una hoja de cálculo (por nombre
o posición). 3) Renombrar una
hoja de cálculo.
1 ptos 480
Cuadro 5.3: Historias añadidas al Sprint 2
3. Abrir un documento docUnknow.ods que no existe, debe fallar y devolver un error.
4. Abrir un documento con una extensión no permitida, debe fallar y devolver un error.
5. Recuperar una pestaña a partir de su posición y comprobar su nombre.
6. Recuperar una pestaña a partir de su nombre y comprobar su nombre.
7. Recuperar una pestaña a partir de una posición que no existe, debe fallar y devolver un
error.
8. Recuperar una pestaña a partir de un nombre que no existe, debe fallar y devolver un
error.
Las pruebas realizadas basadas en el campo cómo probarlo han sido las siguientes:
Prueba unitarias de apertura de los distintos tipos de ficheros permitidos. A partir de la
refactorización en las propias pruebas se ha creado un método openNewDocument que
es el que realmente realiza las comprobaciones dejando en el resto la ruta del fichero a
abrir; de esta manera se evita la repetición de código innecesaria.
Pruebas unitarias para provocar excepciones en la apertura de manera que estás se
incluyan en el código. Estas excepciones son cuando no se soporta la extensión del
fichero o cuando no existe un documento con ese nombre.
Pruebas unitarias para la recuperación de hojas de cálculo a partir de una posición o
un nombre.

5. RESULTADOS 73
Pruebas unitarias para provocar excepciones en la recuperación de hojas de cálculo al
usar posiciones inválidas o al usar nombres nulos o inválidos.
A partir de las pruebas anteriores han emergido los siguientes elementos de diseño:
ISpreadSheet: es la interfaz que proporciona el acceso a las funcionalidades de una
hojas de cálculo. En este punto sólo se proporciona el método para getName() para
obtener el nombre.
SpreadSheet: es la clase que representa una hoja de cálculo y que por tanto hace uso de
los objetos necesarios de UNO y OpenOffice.org, implementando además la interfaz
ISpreadSheet.
LoadOpenSheetDocumentException: excepción que se produce cuando se intenta
abrir un nuevo documento y no se puede por algún error.
SpreadSheetNoFoundException: excepción que se produce cuando se intenta recuperar
una hoja de cálculo de un documento y no existe.
Además de los elementos de diseño nuevos, se han añadido nuevos métodos a las clases
existentes:
getSpreadSheetsNames(): es el método de IOpenSheetDocument que permite recuperar
los nombres de todas sus hojas de cálculo en un array de cadenas.
getSpreadSheet(int pos): es el método de IOpenSheetDocument que permite recuperar
una hoja de cálculo u objeto ISpreadSheet a partir de su posición.
getSpreadSheet(String spreadSheetName): es el método de IOpenSheetDocument que
permite recuperar una hoja de cálculo u objeto ISpreadSheet a partir de su nombre.
openDocument(String documentPath): es el método de OpenSheetManager que se encarga
de abrir un documento de hojas de cálculo y devolver el correspondiente objeto
IOpenSheetDocument.
Estos elementos creados a partir de las pruebas y la refactorización cumplen con lo especificado
para determinar que la historia está completa, para ello basta con ejecutar las pruebas
usadas en el algoritmo de TDD para su implementación.
5.3.2. Historia 1.3 - Modificar hojas de cálculo de un documento
Para empezar a crear los test que sirven para realizar la implementación de la historia, se ha
utilizado como base el campo de la historia cómo probarlo donde se especifican las pruebas
que se deben cumplir para determinar que la historia se ha implementado correctamente:

74 5. RESULTADOS
1. Crear un nuevo documento y añadirle dos nuevas hojas de cálculo, una de ellas sin
asignarle un nombre.
2. Repetir la prueba 1 con un documento ya existente.
3. Crear un nuevo documento y borrar dos pestañas, una por nombre y la otra por posición.
4. Abrir un documento y borrar una pestaña por nombre y otra por posición.
5. Crear un nuevo documento y renombrar una pestaña.
6. Abrir un documento y renombrar una pestaña.
7. Repetir las pruebas 1-6 para cada uno de los formatos permitidos.
Las pruebas realizadas basadas en el campo cómo probarlo han sido las siguientes:
Prueba unitarias de renombrado de hojas de cálculo para los diferentes tipos de documentos
permitidos. A partir de la refactorización en las propias pruebas se ha creado
un método renameSheet que es el que realmente realiza las comprobaciones del renombrado;
de esta manera se evita la repetición de código innecesaria.
Pruebas unitarias para provocar excepciones en el renombrado de manera que estás se
incluyan en el código. Para esto también se ha refactorizado los test obteniéndose el
método renameSheetFail.
Prueba unitarias para añadir y borrar hojas de cálculo a un documento, probando para
los diferentes tipos de documentos permitidos. A partir de la refactorización en las propias
pruebas se han creado los métodos addSheetToNewDocument y deleteSheet que
son los que realmente realizan las comprobaciones evitando la repetición de código.
Pruebas unitarias para provocar excepciones al añadir nuevas hojas de cálculo de manera
que estás se incluyan en el código. Para esto también se ha refactorizado los test
obteniéndose el método addSheetToNewDocumentMustFail.
Pruebas unitarias para provocar excepciones al eliminar hojas de cálculo que no existen.
A partir de las pruebas anteriores, se han añadido nuevos métodos a las clases existentes:
rename(): es el método de ISpreadSheet que permite cambiar el nombre de la hoja de
cálculo.

5. RESULTADOS 75
addSpreadSheet(): es el método de IOpenSheetDocument que permite añadir una nueva
hoja de cálculo con un nombre por defecto al documento.
addSpreadSheet(String spreadSheetName): es el método de IOpenSheetDocument que
permite añadir una nueva hoja de cálculo al documento con el nombre dado.
deleteSpreadSheet(int pos): es el método de IOpenSheetDocument que permite borrar
una hoja de cálculo del documento a partir de su posición.
deleteSpreadSheet(String spreadSheetName): es el método de IOpenSheetDocument
que permite borrar una hoja de cálculo del documento a partir de su nombre.
Estos elementos creados a partir de las pruebas y la refactorización cumplen con lo especificado
para determinar que la historia está completa, para ello basta con ejecutar las pruebas
usadas en el algoritmo de TDD para su implementación.
5.3.3. Resumen de sprint
En el sprint se han completado las dos historias planificadas antes del plazo establecido.
En el gráfico de burndown, ver la figura 5.5, se puede ver la evolución del mismo.
Figura 5.5: Gráfico de burndown del sprint 2
En el gráfico se puede observar el avance más rápido durante los primeros días que hace
que antes de lo esperado se termine con las tareas planificadas, esto es debido a que al partir
ya de métodos de pruebas y algunas de las clases de dominio, se ha podido aumentar la
velocidad. Después de este terminar con las historias de este sprint se ha empezado a trabajar
con la siguiente historia de la pila de producto la 1.4 insertar valores en celdas.

76 5. RESULTADOS
En este sprint como resultado se ha obtenido la segunda versión de la librería que contiene
la funcionalidad de abrir documentos de hojas de cálculo ya creados y modificar las hojas
de cálculo de un documento. En la figura 5.6 se puede ver el diseño de clases resultante,
donde han aparecido nuevas clases y en algunos casos para las existentes se han añadido
nuevos métodos, no se han añadido al diagrama las clases que representan excepciones para
aumentar la legibilidad.
Figura 5.6: Diagrama de clases resultante del sprint 2
5.4. Sprint 3: Modificación de celdas
En este sprint la historia de producto planificada es:
Historia 1.4: Insertar valores en celdas
Esta historia forma parte de la historia 1, al igual que los sprints anteriores, y por tanto
como resultado de este sprint se obtendrá la librería para manipulación de documentos de
hojas de cálculo pero con funcionalidad reducida. La funcionalidad de la librería resultante
será la del sprint anterior más la proporcionada por la historia planificada. En este sprint
debido a que en el anterior se terminó antes y se comenzó con esta tarea planificada, se ha
completado también la tarea planificada para lo que iba a ser el siguiente sprint, por tanto la
funcionalidad será además la de esta historia no planificada. La información resumen de la
historia planificada y de la historia no planificada se puede ver en la tabla 5.4.

5. RESULTADOS 77
ID Nombre Descripción Estimación Importancia Notas
1.4 Insertar valores
en celdas
Se debe permitir insertar valores
de la siguiente forma: 1) Insertar
un valor de una celda. 2) Insertar
un grupo de valores en un rango
de celdas.
3 ptos 470
1.6 Extraer valores
de celdas
Se debe permitir extraer valores
de la siguiente forma: 1) Extraer
un valor de una celda. 2) Extraer
un grupo de valores de un rango
de celdas.
3 ptos 460
Cuadro 5.4: Historias añadidas al Sprint 3
En este caso la historia asignada al sprint eran 3 puntos de historia, que es menos de lo
considerado una carga normal, el problema es que la siguiente historia a añadir eran otros
son otros 3 puntos, lo que podía suponer una carga excesiva pudiendo provocar que no se
llegase a completar el sprint. De manera que si se terminaba la tarea se pudiera comenzar
con la siguiente sin necesidad de comprometerse a que se acabara en el mismo sprint, pero
como se ha comentado antes al final esta historia se ha completado en ese tiempo.
A partir de la historia planificada se define el objetivo del sprint. El objetivo perseguido
por este sprint es el de proporcionar a la API o librería del sprint anterior la funcionalidad
necesaria para insertar valores en las celdas de las hojas de cálculo.
A continuación, se va a detallar el desarrollo de cada una de las historias del sprint tanto
la planificada como la no planificada.
5.4.1. Historia 1.4 - Insertar valores en celdas
Para empezar a crear los test que sirven para realizar la implementación de la historia, se ha
utilizado como base el campo de la historia cómo probarlo donde se especifican las pruebas
que se deben cumplir para determinar que la historia se ha implementado correctamente:
1. Insertar 20 valores en celdas diferentes, celda por celda, situadas en distintas pestañas
u hojas de cálculo dentro de un nuevo documento.
2. Insertar 20 grupos de valores en rangos de celdas diferentes, situadas en distintas pestañas
u hojas de cálculo dentro de un nuevo documento.
3. Repetir las pruebas 1 y 2 con documentos ya existentes, y que tengan los diferentes
formatos permitidos.
4. Insertar un valor en una celda cuyo nombre no existe dentro de una pestaña, debe
devolver un error.

78 5. RESULTADOS
5. Insertar valores en un rango de celdas que tiene una celda cuyo nombre no existe dentro
de una pestaña, debe devolver un error.
Las pruebas realizadas basadas en el campo cómo probarlo han sido las siguientes:
Pruebas unitarias de inserción de valores numéricos y cadenas en celdas de hojas de
cálculo de los distintos tipos de ficheros permitidos. A partir de la refactorización en
las propias pruebas se han creado los métodos insertDoubleToCell, insertStringToCell,
insertDoubleToRange e insertStringToRange que son los métodos encargados de realizar
las comprobaciones, dejando al resto las posiciones de celdas y los valores a
insertar, de manera que se evita la repetición de código innecesaria.
Pruebas unitarias para provocar excepciones en la inserción de valores en celdas al usar
CellPosition inválidos o valores no permitidos. Para estás pruebas se han obtenido los
siguientes métodos tras la refactorización: insertDoubleToCellFail e insertStringToCellFail.
Para los rangos se ha definido test diferentes.
Pruebas unitarias para la recuperación de hojas de cálculo a partir de una posición o
un nombre.
Pruebas unitarias para provocar excepciones en la recuperación de hojas de cálculo al
usar posiciones inválidas o al usar nombres nulos o inválidos.
A partir de las pruebas anteriores han emergido los siguientes elementos de diseño:
CellPosition: es el objeto que determina la posición de una celda a través de los valores
X e Y.
CellNoFoundException: excepción que se produce cuando se intenta referenciar a
una celda que no existe dentro de la hoja de cálculo.
Además de los elementos de diseño nuevos, se han añadido nuevos métodos a las clases
existentes:
setCellValue(CellPosition position, double value): es el método de ISpreadSheet que
permite insertar un valor numérico en una celda identificada por su posición X e Y.
setCellValue(CellPosition position, String value): es el método de ISpreadSheet que
permite insertar una cadena en una celda identificada por su posición X e Y.
setRangeValue(CellPosition firstCellPosition, CellPosition lastCellPosition, double value):
es el método de ISpreadSheet que permite insertar en todas la celdas de un rango
un valor numérico.

5. RESULTADOS 79
setRangeValue(CellPosition firstCellPosition, CellPosition lastCellPosition, String value):
es el método de ISpreadSheet que permite insertar en todas la celdas de un rango
una cadena.
save(): es el método de IOpenSheetDocument que permite recuperar salvar los cambios
realizados en un documento de hojas de cálculo.
Para comprobar que la historia está completa en este caso no ha sido suficiente con las
pruebas unitarias usadas en el algoritmo de TDD, si no que ha sido necesario crear una clase
de pruebas a parte, y su ejecución si garantiza que los elementos creados cumplen con lo
pedido. De hecho en este punto hay que destacar que se detectó un fallo en los rangos con la
nueva clase creada para comprobar que la historia estaba completa.
5.4.2. Historia 1.6 - Extraer valores de celdas
Para empezar a crear los test que sirven para realizar la implementación de la historia, se ha
utilizado como base el campo de la historia cómo probarlo donde se especifican las pruebas
que se deben cumplir para determinar que la historia se ha implementado correctamente:
1. Extraer 20 valores de celdas diferentes, celda por celda, situadas en distintas pestañas
u hojas de cálculo dentro de un documento.
2. Extraer 20 grupos de valores de rangos de celdas diferentes, situadas en distintas pestañas
u hojas de cálculo dentro de un documento.
3. Repetir las pruebas 1 y 2 con documentos con documentos de los diferentes formatos
permitidos.
4. Extraer un valor de una celda cuyo nombre no existe dentro de una pestaña, debe
devolver un error.
5. Extraer valores de un rango de celdas que tiene una celda cuyo nombre no existe dentro
de una pestaña, debe devolver un error.
Las pruebas realizadas basadas en el campo cómo probarlo han sido las siguientes:
Pruebas unitarias de extracción de valores numéricos y cadenas en celdas de hojas de
cálculo de los distintos tipos de ficheros permitidos. A partir de la refactorización en
las propias pruebas se han creado los métodos getValueFromNewDocumentCell, get-
TextFromNewDocumentCell, getValuesFromNewDocumentRange, getTextsFromNew-
DocumentRange y getRangeContent que son los métodos encargados de realizar las
comprobaciones que se comparten en diferentes métodos de manera que se evita la
repetición de código innecesaria.

80 5. RESULTADOS
Pruebas unitarias para provocar excepciones en la extracción de valores en celdas al
usar CellPosition inválidos o valores no permitidos.
A partir de las pruebas anteriores, se han añadido nuevos métodos a las clases existentes:
getCellValue(CellPosition position): es el método de ISpreadSheet que permite obtener
el valor numérico contenido en la celda ubicada en la posición indicada.
getCellText(CellPosition position): es el método de ISpreadSheet que permite obtener
el valor de texto contenido en la celda ubicada en la posición indicada.
getCellContent(CellPosition position): es el método de ISpreadSheet que permite obtener
el valor contenido en la celda ubicada en la posición indicada. Este método devuelve
un tipo Object que puede ser un String o un Double según el contenido de la
celda.
getRangeValues(CellPosition firstCellPosition, CellPosition lastCellPosition): es el método
de ISpreadSheet que permite obtener una lista de los valores numéricos contenidos
en las celdas ubicadas en el rango indicado a partir de las posiciones de las dos
celdas que lo definen.
getRangeTexts(CellPosition firstCellPosition, CellPosition lastCellPosition): es el método
de ISpreadSheet que permite obtener una lista de los valores de texto contenidos
en las celdas ubicadas en el rango indicado a partir de las posiciones de las dos celdas
que lo definen.
getRangeContent(CellPosition firstCellPosition, CellPosition lastCellPosition): es el
método de ISpreadSheet que permite obtener una lista de los valores contenidos en las
celdas ubicadas en el rango indicado a partir de las posiciones de las dos celdas que
lo definen. Los valores son de tipo Object pues cada valor puede ser un String o un
Double según el contenido de cada celda.
Para comprobar que la historia está completa en este caso tampoco ha sido suficiente con
las pruebas unitarias usadas en el algoritmo de TDD, si no que ha sido necesario añadir
métodos de prueba a la clase creada para probar la historia 1.4. Por tanto su ejecución prueba
las historias del sprint.
5.4.3. Resumen de sprint
En el sprint se ha completado la historia planificada antes del plazo establecido y además
se ha completado la siguiente historia que iba a ser un sprint completo. En el gráfico de
burndown, ver la figura 5.7, se puede ver la evolución del mismo.

5. RESULTADOS 81
Figura 5.7: Gráfico de burndown del sprint 3
En el gráfico se puede observar que se comenzaba el sprint con la historia bastante avanzada,
lo que ha permitido implementar la siguiente historia, y por tanto adelantar una semana
la planificación.
En este sprint se han completado todas las tareas restantes de la historia 1 y como resultado
se ha obtenido la versión completa de la librería o API para trabajar con documentos de
hojas de cálculo. En la figura 5.8 se puede ver el diseño de clases de la librería, no se han
añadido al diagrama las clases que representan excepciones para aumentar la legibilidad. En
el diagrama de clases se puede ver que es sencillo e intuitivo el uso de la librería, es decir, se
ha simplificado mucho respecto al uso directo de OpenOffice.org a través de UNO.
5.5. Sprint 4: Estudio de lenguaje script y comando
En este punto se ha detectado que los requisitos iniciales del comando pueden ser mejorados
a través del uso de un lenguaje script; de esta manera lo que se persigue es que cuando se
ejecute el comando se le pase por parámetro un script y un fichero de datos, de manera que se
puede cambiar el fichero de datos para que el resultado del script vaya cambiando, o cambiar
la funcionalidad a través del cambio de script. Por tanto en lugar de las seis subhistorias de
la historia 2, se han definido ahora tres subhistorias repartidas en dos sprints, el 4 y el 5.
En este sprint las historias de producto planificadas son:
Historia 2.1: Estudio de lenguaje script
Historia 2.2: Comando para ejecutar scripts

82 5. RESULTADOS
Figura 5.8: Diagrama de clases resultante del sprint 3
Ambas historias forman parte de la historia 2, por tanto como resultado de este sprint se
obtendrá el comando que a través de la librería obtenida en la historia 1 permite la manipulación
de documentos de hojas de cálculo. La funcionalidad del comando como tal será
completa pero no se creará, en este sprint, el script necesario para que cumpla con lo definido
en la planificación inicial. Este comando debe permitir ejecutar scripts en un lenguaje script,
donde a partir de un fichero de datos realiza una inyección de dependencias, permitiendo
definir tipos especiales a inyectar como listas de valores.
La funcionalidad del comando resultante será la proporcionada por cada una de las historias
planificadas. La información resumen de las historias planificadas se puede ver en la
tabla 5.5.
En este caso se las dos tareas asignadas suman 8 puntos de historia a realizar en el sprint,
que es el doble de lo que se ha considerado una carga normal, por tanto este sprint se realizará
en dos semanas, en realidad se podría dividir en dos sprint distintos pero puesto que
la primera historia no da como resultado ningún artefacto se ha decidido agruparlas en un
mismo sprint pero con duración de dos semanas.
A partir de las historias planificadas se define el objetivo del sprint. El objetivo perseguido
por este sprint es el estudiar un lenguaje script para usarlo en el comando y la generación del
comando.
A continuación, se va a detallar el desarrollo de cada una de las historias planificadas en

5. RESULTADOS 83
ID Nombre Descripción Estimación Importancia Notas
2.1 Estudio de Estudiar lenguajes scripts que 3 ptos 400
lenguaje
script
permitan desde Java ejecutarse
con diferentes ficheros de datos
y permitan el uso de clases Java.
2.2 Comando
para ejecutar
Scripts
Crear el comando que permita
ejecutar Scripts y que realice
la inyección de dependencias
a partir de un fichero .properties.
Debe además permitir indicar
en el fichero tipos especiales
de propiedades: Documentos
(debe crear o abrir un documento
e inyectarlo a la propiedad
con el nombre dado), Manager
de la API, Lista de cadenas, Números.
4 ptos 390
Cuadro 5.5: Historias añadidas al Sprint 4
este sprint.
5.5.1. Historia 2.1 - Estudio de lenguaje script
En está historia no se ha aplicado la metodología TDD sino que se ha realizado más una
labor de investigación con pruebas de concepto para buscar un lenguaje script que se pudiera
incorporar fácilmente al comando de manipulación de documentos de hojas de cálculo.
Después de buscar diferentes alternativas se ha seleccionado Groovy como lenguaje a
incorporar debido a las siguientes características:
Permite incorporar fácilmente en una aplicación Java el intérprete de scripts.
El intérprete permite asignarle un objeto Binding para realizar asignaciones a las variables
de un script que se va a interpretar.
Se pueden usar objetos Java en los scripts.
La sintaxis es muy parecida a Java.
Con las características de asignar valores a las variables de un script desde fuera y la posibilidad
de usar objetos Java, y con la realización de una prueba de concepto donde se le ha
asignado a una variable un objeto de la API de OpenSheet, creada en con la historia 1, para
trabajar con un documento de hojas de cálculo; se ha comprobado que es una alternativa
válida para usar, y se ha seleccionado como lenguaje script.

84 5. RESULTADOS
A partir de la prueba de uso de objetos de la API de OpenSheet en scripts de Groovy se
ha detectado que no se liberaba correctamente las conexiones abiertas con OpenOffice.org y
por tanto se ha añadido un método terminate() en la clase OpenSheetManager.
El ejemplo realizado como prueba de concepto es el que ha servido para validar que la
historia ha sido completada según lo especificado en el campo cómo probarlo:
1. Generar un pequeño ejemplo Java que ejecute un script al que se le inyecta un objeto
de la API y lo use para operar con él.
5.5.2. Historia 2.2 - Comando para ejecutar scripts
Para empezar a crear los test que sirven para realizar la implementación de la historia, se ha
utilizado como base el campo de la historia cómo probarlo donde se especifican las pruebas
que se deben cumplir para determinar que la historia se ha implementado correctamente:
1. Si se pasan propiedades especiales sin el formato adecuado se produce un fallo.
2. Si se pasa un fichero de propiedades invalido se produce un fallo.
3. Realizar pruebas con cada uno de los tipos especiales especificados para el fichero de
datos.
4. Ejecutar un fichero de script con datos válidos y comprobar que se usan los valores
inyectados.
Para las pruebas realizas en esta historia se ha hecho uso del framework Mockito y PowerMock
, para permitir comprobar que dentro de un método se realizan sólo las llamadas
que se deben realizar, de manera que se defina y al mismo tiempo se compruebe el correcto
flujo del programa, y además, para generar mocks u objetos que simulan el comportamiento
de objetos de la API de OpenSheet, para generar objetos reales sólo en aquellos casos en los
se considera necesario.
Las pruebas realizadas basadas en el campo cómo probarlo han sido las siguientes:
Pruebas unitarias de los parámetros pasados al comando y de su comportamiento. A
partir de la refactorización de las pruebas se han creado los métodos verifyInvokeShow-
HelpInfo y checkSetParamsCommandInvalidParamsException que realizan las comprobaciones
comunes evitando duplicar código en las pruebas, y se han creado métodos
auxiliares.
Pruebas unitarias para comprobar la operación de ejecución del comando, y el control
de las diferentes excepciones, donde de la refactorización de las pruebas se ha obtenido
el método checkOpenSheetRunScriptException que ha permitido reducir el código en

5. RESULTADOS 85
otros test en los que sólo deben pasar un objeto de una clase de excepción e indicar si
se debe invocar al método de crear el objeto que ejecutará el test.
Pruebas unitarias del comportamiento en la asignación de valores extraídos y objetos
especiales (listas, objetos de la API de OpenSheet) del fichero de datos a variables
de un script de Groovy. Donde la refactorización de los tests ha generado el método
checkBindingPropertiesFile.
Pruebas unitarias de la ejecución de scripts de Groovy y de la recuperación de valores
de variables.
A partir de las pruebas anteriores han emergido los siguientes elementos de diseño:
OpenSheetCommand: es el objeto que representa al comando, y el encargado de comprobar
los parámetros pasados y crear los objetos necesarios para realizar la ejecución
de un script de Groovy.
ScriptExecuter: es el objeto encargado de ejecutar un script de Groovy y de realizar la
inyección de dependencias, es decir, a partir de la lectura del fichero de datos, obtener
los valores y los objetos indicados y asignarlos a las variables del script. También
permite recuperar los valores de las variables una vez finalizada la ejecución del script.
LoadOpenSheetDataFileException: excepción que se lanza cuando hay algún problema
al intentar abrir un fichero de datos.
OpenSheetCommandInvalidParamsException: excepción que se lanza cuando los
parámetros pasados al comando son inválidos.
OpenSheetRunScriptException: excepción que se lanza cuando se produce un error
al ejecutar un script de Groovy.
OpenSheetPropertyFormatException: excepción que se lanza cuando en el fichero
de datos alguna propiedad no tiene el formato correcto.
Estos elementos creados a partir de las pruebas y la refactorización cumplen con lo especificado
para determinar que la historia está completa, para ello basta con ejecutar las pruebas
usadas en el algoritmo de TDD para su implementación.
5.5.3. Resumen de sprint
En el sprint se han completado las dos historias planificadas en el plazo establecido. En el
gráfico de burndown, ver la figura 5.9, se puede ver la evolución del mismo.
En el gráfico se puede observar que al comienzo de cada historia el avance es más lento y
poco a poco se ha ido aumentando la velocidad hasta alcanzar el compromiso establecido.

86 5. RESULTADOS
Figura 5.9: Gráfico de burndown del sprint 4
En este sprint como resultado se ha obtenido la primera versión del comando que tiene
la funcionalidad de necesaria para ejecutar scripts permitiendo la inyección de dependencias
de las variables establecidas en el fichero de datos. Sólo falta el tener scripts en Groovy para
operar. En la figura 5.10 se puede ver el diseño de clases resultante.
Figura 5.10: Diagrama de clases resultante del sprint 4

5. RESULTADOS 87
5.6. Sprint 5: Script genérico para el comando
En este sprint la historia de producto planificada ha sido:
Historia 2.3: Script Genérico
Esta historia forma parte de la historia 2, al igual que el sprint anterior, pero en este caso
no se obtendrá un comando con mayor funcionalidad si no un script en Groovy que permita
realizar las tareas pensadas en un principio para el comando y que será el distribuido por
defecto con el mismo. La información resumen de las historia planificada se puede ver en la
tabla 5.6.
ID Nombre Descripción Estimación Importancia Notas
2.3 Script Genérico
Crear un Script que permita: 1) 4 ptos 380 Necesita
Crear un nuevo documento o
tener antes
abrir uno existente 2) Insertar
las historias
nuevas hojas de cálculo al documento.
2.1 y 2.2
3) Eliminar hojas de
cálculo al documento. 4) Insertar
valores a celdas del documentos.
5) Extraer valores de las
celdas del documento y exportarlos
a un fichero. 6) Guardar el
documento o exportarlo a los ficheros
soportados.
Cuadro 5.6: Historias añadidas al Sprint 5
En este caso se la historia asignada son 4 puntos de historia a realizar en el sprint, que es
lo que se ha considerado una carga normal.
A partir de la historia planificada se define el objetivo del sprint. El objetivo perseguido
por este sprint es el realizar un script genérico en Groovy para dotar al comando de las operaciones
básicas de manipulación con hojas de cálculo cambiando sólo el fichero de datos.
A continuación, se va a detallar el desarrollo de la historias planificada en este sprint.
5.6.1. Historia 2.3 - Script Genérico
Para empezar a crear los test que sirven para realizar la implementación de la historia, se ha
utilizado como base el campo de la historia cómo probarlo donde se especifican las pruebas
que se deben cumplir para determinar que la historia se ha implementado correctamente:
1. Crear un nuevo documento y salvarlo.
2. Abrir un documento y borrar 3 hojas usando su nombre.

88 5. RESULTADOS
3. Abrir un documento, añadir 3 hojas nuevas y borrar 3 hojas por posición.
4. Abrir un documento, añadir 3 hojas nuevas, insertar valores a las celdas, extraer valores
de las celdas (exportándolas a un fichero) y exportar el documento a PDF.
Las pruebas realizadas basadas en el campo cómo probarlo se han realizado parte en otro
script en Groovy y parte en clases de Java, y han sido las siguientes:
Prueba unitarias para las diferentes operaciones básicas para tratar los valores inyectados
a las variables del script. Esto se ha comprobado a través de un script en Groovy.
Pruebas unitarias para los cambios necesarios en la clase CellPosition para permitir
generar objetos a partir del nombre de la celda.
Pruebas unitarias para la ejecución del script.
A partir de las pruebas anteriores han emergido los siguientes elementos de diseño:
OpenSheetScript.groovy: es el script de Groovy resultante de la historia.
Main: es la clase con el método main del jar del comando. El jar autoejecutable simplemente
crea un objeto comando, le asigna los mismos parámetros que se le han pasado
por línea de ordenes y ejecuta el run del comando.
CellNameException: excepción que se produce cuando se un nombre incorrecto para
hacer referencia a la posición de una celda.
OverwriteSpreadSheetException: excepción que se produce cuando se intenta sobreescribir
una hoja de cálculo que ya existe en el documento.
Además de los elementos de diseño nuevos, se han añadido nuevos métodos a las clases
existentes:
CellPosition(String cellName): es un nuevo constructor para la clase CellPosition que
permite crear posiciones de celda a partir de un nombre válido.
equals(Object obj): se ha sobreescrito el método de comparación porque era necesario
en las pruebas.
containsSpreadSheet(String name): es el método de IOpenSheetDocument que indica
si contiene una hoja de cálculo con ese nombre.
addSpreadSheet(String spreadSheetName): se ha modificado este método de IOpenSheetDocument
para que lance una excepción en el caso en el que ya exista una hoja
dentro del documento con el nombre de la nueva hoja de cálculo que se quiere crear.

5. RESULTADOS 89
Estos elementos creados a partir de las pruebas y la refactorización cumplen con lo especificado
para determinar que la historia está completa, para ello basta con ejecutar las pruebas
usadas en el algoritmo de TDD para su implementación.
5.6.2. Resumen de sprint
En el sprint se ha completado las historia con una velocidad de 2 en lugar de 4, lo que ha
hecho que no se cumpla la planificación, tardando el doble de lo estimado. En el gráfico de
burndown, ver la figura 5.11, se puede ver la evolución del mismo.
Figura 5.11: Gráfico de burndown del sprint 5
En el gráfico se puede observar que el avance ha ido muy lento durante todo el sprint lo
que ha hecho que se tarde dos semanas en lugar de una. La principal causa de esto es que
no se estimo correctamente la historia, pues el diseño del script para permitir realizar todas
las operaciones de inserción, modificación y extracción de datos en documentos de hojas de
cálculo según el fichero que se usase era complicado y ha llevado más tiempo del previsto.
Además, el desconocimiento de la sintaxis de Groovy, aunque sea muy parecida a Java, ha
hecho que se necesite más tiempo del esperado. Junto a todo lo anterior el desarrollo usando
el algoritmo de TDD ha resultado más difícil que en puntos anteriores, principalmente debido
a la falta de experiencia con esta metodología.
En este sprint se han completado todas las tareas restantes de la historia 2 y como resultado
se ha obtenido la versión completa del comando que permite a partir de un fichero de
datos (un fichero .properties) y un script, realizar ejecutar el script con la inyección de dependencias
del fichero de datos de manera que se pueda usar la librería o API de OpenSheet
para trabajar con documentos de hojas de cálculo. En este caso el diagrama de clases del

90 5. RESULTADOS
comando coincide con el del sprint anterior, ver figura 5.10.
5.7. Sprint 6: Servicio web
A partir de los cambios en los requisitos iniciales del comando, se han llevado también
hasta la historia 3, el servicio web. Este a partir del uso de la librería o API de OpenSheet debe
permitir la manipulación de hojas de cálculo, basándose en el mismo funcionamiento que el
comando, es decir, debe permitir al usuario seleccionar un script, de entre los disponibles
para usar con el servicio web, y a de esa selección, un fichero de datos y un documento de
hojas de cálculo, sólo cuando sea necesario, realizará las operaciones del script y devolverá
el documento con los cambios realizados.
Aunque se ha aumentado la funcionalidad pues se hace mucho más flexible el servicio
web al permitir ejecutar diferentes scripts, el número de historias se reduce de tres a dos, y
la estimación pasa de 9.5 puntos de historia a 4, pues se va a reutilizar parte de las clases
generadas para el comando.
En este sprint las historias de producto planificadas son:
Historia 3.1: Operación de listado de scripts
Historia 3.2: Operación de selección y ejecución de un script sobre un documento
Ambas historias forman parte de la historia 3, por tanto como resultado de este sprint se obtendrá
el servicio web que a través de la librería obtenida en la historia 1 permite la manipulación
de documentos de hojas de cálculo. La funcionalidad del servicio web será completada
en este sprint, pues se hará uso del script básico generado para el comando.
La funcionalidad del servicio web resultante será la proporcionada por cada una de las
historias planificadas. La información resumen de las historias planificadas se puede ver en
la tabla 5.7.
A partir de las historias planificadas se define el objetivo del sprint. El objetivo perseguido
por este sprint es el de generar el servicio web para trabajar con documentos de hojas de
cálculo.
A continuación, se va a detallar el desarrollo de cada una de las historias planificadas en
este sprint.
5.7.1. Historia 3.1 - Operación de listado de scripts
Para empezar a crear los test que sirven para realizar la implementación de la historia, se ha
utilizado como base el campo de la historia cómo probarlo donde se especifican las pruebas
que se deben cumplir para determinar que la historia se ha implementado correctamente:

5. RESULTADOS 91
ID Nombre Descripción Estimación Importancia Notas
3.1 Operación
de listado de
scripts
3.2 Operación
de selección
y ejecución
de un script
sobre un
documento
Debe existir una operación en la
que se pueda recuperar la información
de todos los scripts que
se pueden utilizar y la descripción
de los mismos. Además,
debe implementarse el mecanismo
necesario para que mediante
configuración se pueda indicar
cuales van ser los scripts permitidos
para usarse y su descripción.
La operación debe recibir siempre
un fichero de datos y el identificador
del script a ejecutar, y
de manera opcional un documento.
Se ejecutará el script y se
devolverá el resultado de la ejecución.
1 ptos 310 Con esta operación
se debe
crear también
el servicio
web.
3 ptos 300
Cuadro 5.7: Historias añadidas al Sprint 6
1. Configurar varios scripts con sus descripciones.
2. Recuperar la lista de scripts permitidos y comprobar que coincide con los publicados.
Para las pruebas realizas en esta historia se ha hecho uso del framework Mockito , para
permitir comprobar que dentro de un método se realizan sólo las llamadas que se deben realizar,
de manera que se defina y al mismo tiempo se compruebe el correcto flujo del programa,
y además, para generar mocks u objetos que simulan el comportamiento de objetos, como
por ejemplos objetos que representan directorios o ficheros.
Las pruebas realizadas basadas en el campo cómo probarlo han sido las siguientes:
Pruebas unitarias de los métodos auxiliares para recuperar información de los scripts.
En este caso la refactorización ha dado lugar a un método checkScriptInfoValue que
permite comprobar si el objeto ScriptInfo y la información esperada coinciden.
A partir de las pruebas anteriores han emergido los siguientes elementos de diseño:
OpenSheetWebService: es el objeto que representa al servicio web, y que pública los
métodos que hacen de operaciones. Para su construcción se ha usado JAX-WS
ScriptInfoUtils: es la clase con los métodos estáticos necesarios para poder recuperar
la información de los scripts a partir de sus ficheros.

92 5. RESULTADOS
ScriptInfo: es el objeto que representa la información necesaria para usar un script: el
nombre, la ruta, la descripción, las variables que hacen referencia a ficheros de salida
y la variable donde se inyecta el directorio temporal.
Estos elementos creados a partir de las pruebas y la refactorización cumplen con lo especificado
para determinar que la historia está completa, para ello basta con ejecutar las pruebas
usadas en el algoritmo de TDD para su implementación.
5.7.2. Historia 3.2 - Operación de selección y ejecución de un script
sobre un documento
Para empezar a crear los test que sirven para realizar la implementación de la historia, se ha
utilizado como base el campo de la historia cómo probarlo donde se especifican las pruebas
que se deben cumplir para determinar que la historia se ha implementado correctamente:
Ejecutar el script de base con las siguientes opciones:
1. Enviar sólo fichero de datos y crear un documento que se devuelva al cliente del servicio
web.
2. Enviar documento sobre el que aplicar modificaciones que se salven y comprobar que
el documento recibido en el cliente es el esperado.
3. Enviar un documento operar sobre él y devolver el resultado de convertir dicho documento
a otro formato.
4. Convertir un documento enviado a formato PDF.
5. Enviar un documento y extraer valores sobre él.
6. Enviar un documento modificarlo y extraer valores sobre él, se debe recibir los valores
extraídos y el documento modificado.
Para las pruebas realizas en esta historia se ha hecho uso del framework Mockito , para
permitir comprobar que dentro de un método se realizan sólo las llamadas que se deben
realizar, de manera que se defina y al mismo tiempo se compruebe el correcto flujo del
programa, y además, para generar mocks u objetos que simulan el comportamiento de objetos
de la API de OpenSheet, para generar objetos reales sólo en aquellos casos en los se considera
necesario.
Las pruebas realizadas basadas en el campo cómo probarlo han sido las siguientes:
Pruebas unitarias de los métodos auxiliares para la operación de ejecutar un script.

5. RESULTADOS 93
Pruebas unitarias para establecer el comportamiento de la operación isEmpty de la
clase Document, que índica si el objeto es un documento vacío.
Pruebas unitarias de la ejecución de scripts, es decir, pruebas de los parámetros pasados,
del parseo inicial de variables del fichero de datos, y del comportamiento en la
ejecución. A partir de la refactorización de las pruebas se ha creado el método checkExecuteScriptWithDocument
que realiza las comprobaciones comunes evitando duplicar
código en las pruebas.
Se ha cambiado las pruebas del ScriptExecuter del comando para cambiar el constructor
y que también permita usar directamente un objeto Properties además de un
fichero de propiedades. Para evitar repetir código en los tests para probar con ambos
constructores se ha hecho uso un mecanismo que ofrece JUnit con las anotaciones
@RunWith(Parameterized.class) y @Parameters de manera que se lancen los tests dos
veces cambiando un parámetro que hace que se elija un constructor primero y luego el
otro, evitando así una gran repetición de código en las pruebas.
A partir de las pruebas anteriores han emergido los siguientes elementos de diseño:
OperationUtils: es la clase con los métodos estáticos auxiliares necesarios para poder
realizar la operación de ejecutar un script.
Document: es el objeto que representa un documento o fichero binario. Este objeto es
el que se usa para poder enviar y recibir ficheros con sus nombres y extensiones, en la
operación del servicio web, para poder trabajar con ellos según su extensión.
ScriptVariable: debido a un problema de JAX-WS para usar mapas de variables, detectado
al crear el cliente de pruebas de integración, ha sido necesario crear este tipo
de objeto que representa un par clave/valor, de manera que a la operación se le pase
una lista de objetos de este tipo en lugar de un mapa de variables.
ExecuteScriptOperation: es el objeto que representa una operación de ejecución de
script. Una vez se le pasan los parámetros necesarios, parsea las variables del fichero
de datos para adaptarlas al ScriptExecuter, y se queda preparado para la ejecución del
script. Cuando se ejecuta el script se devuelve como resultado una lista con todos los
documentos a devolver.
OpenSheetOperationInvalidParamsException: excepción que se lanza cuando los
parámetros pasados a la operación no son válidos.
OpenSheetWebServiceException: excepción genérica que se lanza cuando se produce
un error en alguna operación del servicio web. Esta operación sirve para encapsular
otras excepciones y lanzarlas al cliente.

94 5. RESULTADOS
Además de los elementos de diseño nuevos, se han añadido nuevos métodos a las clases
existentes:
ScriptExecuter(OpenSheetManager openSheetManager, Properties properties): es un
nuevo método constructor de ScriptExecuter que permite crear directamente un objeto
sin necesidad de leer las variables de un ficheros .properties, facilitando su uso desde
el servicio web. Para evitar la repetición de código en el nuevo constructor a partir de
la refactorización, ha surgido un nuevo método privado InitScriptExecuter al que llama
cada constructor.
setCellValue(CellPosition position, String value): es el método de ISpreadSheet que
permite insertar una cadena en una celda identificada por su posición X e Y.
setRangeValue(CellPosition firstCellPosition, CellPosition lastCellPosition, double value):
es el método de ISpreadSheet que permite insertar en todas la celdas de un rango
un valor numérico.
setRangeValue(CellPosition firstCellPosition, CellPosition lastCellPosition, String value):
es el método de ISpreadSheet que permite insertar en todas la celdas de un rango
una cadena.
save(): es el método de IOpenSheetDocument que permite recuperar salvar los cambios
realizados en un documento de hojas de cálculo.
Para comprobar que los elementos creados a partir de las pruebas y la refactorización
cumplen con lo especificado, en este caso ha sido necesario crear un cliente del servicio web
muy básico que llama a las dos operaciones publicadas. Gracias a estas pruebas a través de
un cliente se han detectado diferentes problemas, el primero ha sido la incapacidad de JAX-
WS para manejar mapas de variables, como ya se ha comentado antes, lo que ha obligado
a modificar las interfaces, algunas pruebas y métodos; y además han aparecido problemas
con el despliegue del servicio web en el contenedor de servlets, que se han solucionado y
documentado en el manual de usuario para que si a algún usuario le sucede alguno de esos
problemas sepa como resolverlos.
5.7.3. Resumen de sprint
En el sprint se han completado las dos historias planificadas con tres días de retraso. En el
gráfico de burndown, ver la figura 5.12, se puede ver la evolución del mismo.
En el gráfico se puede observar que en el comienzo del sprint se ha ido más lento de los
esperado, esto es debido a que el diseño y las pruebas para las operaciones que se han realizado
estaban subestimadas, luego una vez se ha definido como llevar a cabo las operaciones
y se han ido realizando más pruebas, se ha ido aumentando la velocidad. El último repunte

5. RESULTADOS 95
Figura 5.12: Gráfico de burndown del sprint 6
en la gráfica casi al final del desarrollo ha sido provocado por los problemas encontrados al
realizar las pruebas con el cliente del servicio web creado para validar que las historias estaban
completas. Esto problemas han sido por un lado con el framework utilizado, JAX-WS, y
por otro con el contenedor de servlets.
En este sprint como resultado se ha obtenido el servicio web completo con sus dos operaciones.
En la figura 5.13 se puede ver el diseño de clases resultante.
5.8. Sprints 7-10: Documentación
En esta sección se va a resumir el desarrollo de la ultima historia del proyecto, la historia
4 que se corresponde con la realización de la documentación o memoria del proyecto. La
documentación se ha dividido en 6 subhistorias, cada correspondiente a un capítulo de la
memoria, con una estimación inicial de 18 puntos planificados en 4 sprints. A continuación
se va a explicar cada uno de los sprints.
5.8.1. Sprint 7: Documentación 1 - Antecedentes
En este sprint se ha planificado la historia 4.2, como se puede ver en la tabla 5.8, puesto
que el dueño de producto ha dado menos prioridad a la historia 4.1 al decidir que debe
completarse una vez se tenga el resto de la memoria completada.
ID Nombre Descripción Estimación Importancia Notas
4.2 Antecedentes Estudio del estado del arte. 4 ptos 290
Cuadro 5.8: Historias añadidas al Sprint 7

96 5. RESULTADOS
Figura 5.13: Diagrama de clases resultante del sprint 6
En completar la historia se ha tardado prácticamente 4 semanas en lugar de una que era lo
planificado. El principal problema que ha provocado este retraso ha sido la subestimación de
la realización de esta historia, donde los puntos reales han sido 11, y la sobrestimación de la
velocidad para realizarla que ha sido de 3 puntos por semana, en lugar de 4 pues el comienzo
de la documentación siempre lleva un esfuerzo adicional, y en este caso más al no conocer
L A TEX.
5.8.2. Sprint 8: Documentación 2 - Objetivos y Método de Trabajo
En este sprint se ha planificado las historia 4.3 y 4.4, como se puede ver en la tabla 5.9.
ID Nombre Descripción Estimación Importancia Notas
4.3 Objetivos
2 ptos 280
PCF
4.4 Método de
3 ptos 270
trabajo
Cuadro 5.9: Historias añadidas al Sprint 8
Este sprint se ha completado en el tiempo planificado debido que se ha podido aumentar
el tiempo a dedicar por un lado, y por otro a que la historia 4.3 se había sobrestimado siendo
su duración real 1 punto, y por tanto la velocidad real y necesaria para completar este sprint
ha sido de 4 puntos.

5. RESULTADOS 97
5.8.3. Sprint 9: Documentación 3 - Resultados
En este sprint se ha planificado la historia 4.5 como se puede ver en la tabla 5.10.
ID Nombre Descripción Estimación Importancia Notas
4.5 Resultado 5 ptos 260
Cuadro 5.10: Historias añadidas al Sprint 9
Esta historia también ha sido subestimada siendo su estimación real de 12 puntos, y para
poder completarla con tan sólo un retraso de 4 días, ha sido necesario gastar varios días de
vacaciones para aumentar el tiempo de dedicación.
5.8.4. Sprint 10: Documentación 4 - Conclusiones e Introducción
En este sprint se ha planificado las historia 4.6 y 4.1 como se puede ver en la tabla 5.11.
ID Nombre Descripción Estimación Importancia Notas
4.6 Conclusiones 2 ptos 200
4.1 Introducción 2 ptos 140
Cuadro 5.11: Historias añadidas al Sprint 10
Esta historia aun no se ha empezado pues corresponde justo al sprint siguiente a la conclusión
del capítulo que se está redactando, pero tras la experiencia de los tiempos y velocidades
anteriores utilizados para las diferentes subhistorias de la historia 4, parece que el tiempo real
de estimación será inferior al calculado en la planificación, pasando de 4 a 2 puntos, lo que
va a permitir completarlo antes de lo esperado.
5.9. API OpenSheet
A partir de la historia 1 y de las mejoras detectadas durante la ejecución de los sprints
de las historias 2 y 3, se ha obtenido una API para trabajar con documentos de hojas de
cálculo.
Para su construcción se han utilizado las siguientes clases de tests:
OpenSheetDocumentTest: es la clase que contiene todas las pruebas relacionadas con
los documentos de hojas de cálculo, es decir, con la interfaz que IOpenSheetDocument
y la clase que la implementa OpenSheetDocument. A través de sus 97 tests se ha
definido el comportamiento que se espera que tenga cada una de las operaciones de
estas clases.
SpreadSheetTest: es la clase que contiene todas las pruebas relacionadas con las hojas
de cálculo de un documento, es decir, con la interfaz que ISpreadSheet y la clase que

98 5. RESULTADOS
la implementa SpreadSheet. A través de sus 64 tests se ha definido el comportamiento
que se espera que tenga cada una de las operaciones de estas clases.
CellPositionTest: es la clase que contiene las pruebas para las operaciones que usan
cadenas como identificadores de la posición de una celda y operaciones de comparación
para la clase CellPositionTest. A través de sus 22 tests se ha definido el comportamiento
que se espera que tengan las operaciones probadas.
Sprint3Test: es una clase usada para comprobar que una vez creada la API se cumplen
con lo pedido en el sprint 3 para demostrar la completitud de la historias planificadas
en ese sprint, por tanto sus 16 test no han sido usados dentro del algoritmo de TDD
para el diseño.
Los tests diseñados hacen uso directo de OpenOffice.org Calc a través UNO, y del sistema
de ficheros, pero se aseguran antes de empezar cada test que no existe ningún fichero que
pueda provocar errores en las pruebas y de restaurar todo una vez finalizan.
Figura 5.14: Diagrama de clases de la API de OpenSheet
La API de OpenSheet permite usar OpenOffice.org Calc de manera transparente al usuario,
de manera que es la librería la que busca la instalación en la máquina y levanta una instancia
del proceso de OpenOffice.org para conectarse a él y poder hacer uso de su funcionalidad.
Para ello el desarrollador que use OpenSheet tan sólo debe usar la factoría OpenSheetManager
tanto para crear un nuevo documento como para abrir uno existente, y a través de las

5. RESULTADOS 99
interfaces ofrecidas IOpenSheetDocument para los documentos e ISpreadSheet para las hojas
de cálculo, realizar las operaciones ofrecidas. El diagrama de clases completo obtenido a
partir de la aplicación del algoritmo de TDD es el que se puede ver en la figura 5.14.
5.10. Comando OpenSheet
A partir de la historia 2 y de las mejoras detectadas durante la ejecución de los sprints de
la historia 3, se ha obtenido una comando que permite ejecutar scripts e inyectarles dependencias
para permitir trabajar con documentos de hojas de cálculo.
Para su construcción se han utilizado las siguientes clases de tests:
OpenSheetCommandTest: es la clase que contiene todas las pruebas relacionadas
con la clase que representa al comando, es decir, OpenSheetCommand. A través de
sus 18 tests se ha definido el comportamiento que se espera que tenga cada una de las
operaciones de esta clase.
ScriptExecuterTest: es la clase que contiene todas las pruebas relacionadas con la
clase encargada de ejecutar scripts de Groovy e inyectarle las dependencias leidas del
fichero de datos, es decir, con la clase ScriptExecuter. A través de sus 44 tests se ha
definido el comportamiento que se espera que tenga cada una de las operaciones de
esta clase.
OpenSheetScriptTest: es la clase que contiene todas las pruebas relacionadas con
el script genérico creado para la manipulación de documentos de hojas de cálculo,
es decir, OpenSheetScript.groovy. A través de sus 4 tests y el script OpenSheetUtilsTest.groovy,
que contiene tests de métodos auxiliares del script, se ha definido el
comportamiento que se espera que tenga cada una de las operaciones de este script.
TestUtils: es una clase con métodos auxiliares estáticos usados para llevar a cabo alguno
de los pasos necesarios en las pruebas.
Los tests diseñados en algunos casos hacen uso directo de OpenOffice.org Calc a través
UNO, y del sistema de ficheros, pero siempre se aseguran antes de empezar cada test que no
existe ningún fichero que pueda provocar errores en las pruebas y de restaurar todo una vez
finalizan.
El comando de OpenSheet permite usar la API de OpenSheet generada en la historia 1
dentro de scripts del lenguaje Groovy. El comando permite ejecutar un script escrito en
Groovy inyectándole las dependencias leídas de un fichero de datos pasado por paramétro
en la llamada al comando; de esta manera un mismo script se puede reutilizar simplemente
cambiando el fichero de datos. El comando al estar preparado para ejecutarse en un terminal

100 5. RESULTADOS
y permitir cambiar su comportamiento según el fichero de datos, permite ser usado para
realizar tareas por lotes. Además también se puede usar para planificar y automatizar ciertas
tareas de manera sencilla a través de las herramientas que ofrecen los sistemas operativos.
Para permitir realizar las operaciones de la API sin necesidad de tener que crear un script,
se ha generado uno, que según el contenido del fichero de datos realiza unas operaciones u
otras, ofreciendo una gran versatilidad.
El diagrama de clases completo, obtenido a partir de la aplicación del algoritmo de TDD
para las historias del comando, es el que se puede ver en la figura 5.15.
Figura 5.15: Diagrama de clases del Comando de OpenSheet
5.11. Servicio web OpenSheet
A partir de la historia 3 se ha obtenido un servicio web que permite de manera remota
seleccionar y ejecutar scripts, a los que se les inyectan las dependencias leídas de las propiedades
pasadas, para permitir trabajar con documentos de hojas de cálculo.
Para su construcción se han utilizado las siguientes clases de tests:
ScriptInfoUtilsTest: es la clase que contiene todas las pruebas relacionadas con los
métodos auxiliares que permiten recuperar la información de los scripts. A través de

5. RESULTADOS 101
sus 5 tests se ha definido el comportamiento que se espera que tenga cada una de las
operaciones usadas como base para la operación del servicio web que devuelve una
lista de objetos ScriptInfo.
OperationUtilsTest: es la clase que contiene todas las pruebas relacionadas con los
métodos auxiliares que permiten realizar parte de las tareas necesarias para llevar a
cabo la operación de ejecución de un script haciendo uso del ScriptExecuter creado en
la historia 2. A través de sus 9 tests se ha definido el comportamiento que se espera
que tenga cada una de las operaciones usadas como base para la operación del servicio
web.
DocumentTest: es la clase que contiene todas las pruebas relacionadas con la operación
que comprueba si un objeto de tipo Document es vacío. A través de sus 5 tests se
ha definido el comportamiento que debe tener dicho método.
ExecuteScriptOperationTest: es la clase que contiene todas las pruebas relacionadas
con las operaciones de ejecución de scripts, es decir, con la clase ExecuteScriptOperation.
A través de sus 17 tests se ha definido el comportamiento que se espera que tenga
cada una de las operaciones de estas clase.
Figura 5.16: Diagrama de clases del Servicio Web de OpenSheet
Los tests diseñados en algunos casos hacen uso directo de OpenOffice.org Calc a través
UNO, y del sistema de ficheros, pero siempre se aseguran antes de empezar cada test que no

102 5. RESULTADOS
existe ningún fichero que pueda provocar errores en las pruebas y de restaurar todo una vez
finalizan.
El servicio web de OpenSheet permite usar la API de OpenSheet generada en la historia 1
dentro de scripts del lenguaje Groovy. Para ello es necesario configurar el directorio donde se
encuentran los scripts y definir un fichero de propiedades con las características de los scripts.
El servicio web permite la misma funcionalidad que el comando de la historia 2 pero a través
de los scripts configurado para ello, así se evitan posibles problemas de seguridad.
El diagrama de clases completo, obtenido a partir de la aplicación del algoritmo de TDD
para las historias del servicio web, es el que se puede ver en la figura 5.16.
5.12. Documentación
A partir de la historia 4 se ha obtenido la memoria del proyecto que debe cumplir con la
normativa académica.
Además de la memoria del proyecto, se ha generado también la siguiente documentación
a lo largo del desarrollo del proyecto:
Documentación de la API de OpenSheet generada con Javadoc
Manual de usuario del comando de OpenSheet.
Manual de usuario del servicio web de OpenSheet.
Los manuales de usuario creados se han añadido como apéndices a la memoria del proyecto.
5.13. Estadísticas del proyecto
Para terminar con el capítulo de resultados, se van a presentar unas estadísticas del proyecto
y a comentar las diferencias entre el esfuerzo invertido y el planificado.
Para medir las líneas de código o SLOC, tanto del código de producción como del de
pruebas, se ha hecho uso de la aplicación SLOCCount. Para ello se ha realizado la ejecución
para medir por separado el código de producción y el código de pruebas.
En la tabla 5.12 se puede ver los resultados de la ejecución de SLOCCount con el código
de producción. En dicha tabla se puede observar entre otros datos obtenidos que el número de
líneas correspondientes a dicho código son 2592. Además, en la tabla también se hace referencia
a las métricas del modelo COCOMO que ha generado la herramienta SLOCCount.
En la tabla 5.13 se puede ver los resultados de la ejecución de SLOCCount con el código de
pruebas. En dicha tabla se puede observar entre otros datos obtenidos que el número de líneas

5. RESULTADOS 103
Medida
Valor
Total Physical Source Lines of Code (SLOC) 2,592
Development Effort Estimate, Person-Years (Person-Months) 0.54 (6.52)
(Basic COCOMO model, Person-Months = 2.4 ∗ (KSLOC∗∗1.05))
Schedule Estimate, Years (Months) 0.42 (5.10)
(Basic COCOMO model, Months = 2.5 ∗ (person-months∗∗0.38))
Estimated Average Number of Developers (Effort/Schedule) 1.28
Total Estimated Cost to Develop $ 73,444
(average salary = $56,286/year, overhead = 2.40)
Cuadro 5.12: Resultado de ejecución de SLOCCount con el código de producción
correspondientes a dicho código son 4047. Además, en la tabla también se hace referencia a
las métricas del modelo COCOMO que ha generado la herramienta SLOCCount.
Entre las dos tablas anteriores podemos ver que el número de líneas de codigo total entre
pruebas y código de producción suman 6639, de las cuales 4047 son las referentes al
código usado en los test. Esto índica que aproximadamente el 61 % de las líneas de código
corresponden a la realización de los test, es decir, ese porcentaje corresponde al esfuerzo del
proyecto dedicado a las pruebas.
Medida
Valor
Total Physical Source Lines of Code (SLOC) 4,047
Development Effort Estimate, Person-Years (Person-Months) 0.87 (10.42)
(Basic COCOMO model, Person-Months = 2.4 ∗ (KSLOC∗∗1.05))
Schedule Estimate, Years (Months) 0.51 (6.09)
(Basic COCOMO model, Months = 2.5 ∗ (person-months∗∗0.38))
Estimated Average Number of Developers (Effort/Schedule) 1.71
Total Estimated Cost to Develop $ 117,255
(average salary = $56,286/year, overhead = 2.40)
Cuadro 5.13: Resultado de ejecución de SLOCCount con el código de pruebas
Al haber usado durante el desarrollo la metodología TDD, el esfuerzo realizado para las
pruebas no sólo ha sido invertido para asegurar que funciona correctamente el código de
producción, si no también ha sido invertido para el diseño y estructura del código, pues este
se genera a partir de cada una de las pruebas realizadas.
También hay que señalar que el código repetido se ha reducido al máximo a través de las
refactorizaciones continuas que se realizan con el algoritmo de TDD, en ambos casos.
El tiempo aproximado invertido en el proyecto han sido de unos 4 meses de trabajo con
una media de 27 horas semanales, por tanto se han empleado 432 horas.
El esfuerzo estimado en la última planificación con los cambios en los requisitos realizados
es de 52.5 puntos, correspondiendo como ya se explicó, 4 puntos a 27 horas semanales. Por

104 5. RESULTADOS
tanto el tiempo estimado ha sido de 354 horas.
Por tanto ha habido una desviación de 78 horas entre el tiempo real y el planificado, en
puntos es una desviación de 11.5 puntos, principalmente debido a la subestimación que se
ha hecho para la realización de la memoria del proyecto.

Capítulo 6
Conclusiones
EN este capítulo se muestran los objetivos alcanzados, es decir, se realiza un análisis
de los resultados obtenidos durante el desarrollo del proyecto, descritos en el anterior
capítulo, y se proponen posibles mejoras y ampliaciones para desarrollar en un futuro. Además
al final se realizará un comentario con las conclusiones personales del autor sobre el
desarrollo del proyecto y las metodologías utilizadas.
6.1. Objetivos alcanzados
Se va a analizar cada uno de los objetivos marcados al comienzo del proyecto y cómo se
han cumplido.
Objetivo general: El objetivo general ha sido ampliamente cubierto a través de los
tres artefactos software generados: la API o librería, el comando y el servicio web;
pues todos ellos proporcionan un mecanismo para insertar y extraer datos de un documento
de hojas de cálculo soportando los principales formatos del mercado, tanto de
Microsoft Excel como de OpenOffice.org.
Objetivo específico 1: Los formatos de documentos de hojas de cálculo permitidos por
los artefactos software generados son: xls, xlt, xlsx, ods y ots. Por tanto se ha cumplido
con el objetivo, y cualquier otro formato ha sido considerado fuera del alcance del
proyecto y por tanto tratado como un formato no válido.
Objetivo específico 2: Las operaciones con documentos de hojas de cálculo establecidas
por este objetivo también se cumplen por los tres artefactos software creados. Las
operaciones son:
1. Creación y apertura de documentos de hojas de cálculo. Estas operaciones se
realizan de manera sencilla al identificarse automáticamente el formato del documento
usando la extensión del fichero.
2. Extracción e inserción de datos en celdas. Estas operaciones se pueden realizar
de manera que se diferencia el tipo de datos (numéricos o texto) a insertar en la
105

106 6. CONCLUSIONES
celda, y además se ofrece la posibilidad de llevar a cabo dichas operaciones con
rangos de celdas.
3. Creación y eliminación de hojas de cálculo. Nuevamente estas operaciones se
permiten tanto en la API como en el comando y en el servicio web, ofreciendo
la posibilidad de referenciar a las hojas con las que se quiere operar usando el
nombre o la posición.
Objetivo específico 3: Se permiten realizar operaciones de salvado con la posibilidad
de realizar conversiones de formato, entre los formatos fijados como válidos por el
objetivo 2, en cada uno de los artefactos software generados. Para ello simplemente
es necesario cambiar la extensión del fichero al guardar el documento, de esta manera
toda la conversión se realiza de manera automática y transparente al usuario.
Objetivo específico 4: La exportación de un documento al formato PDF se permite en
la API a través de una operación específica, y también se soporta en el comando y el
servicio web.
Objetivo específico 5: Al utilizar Java y OpenOffice.org todos los artefactos generados
son multiplataforma, sin diferencia de uso para el desarrollador en caso de usar la API
o para el usuario si usa el comando o el servicio web. Sólo hay que tener en cuenta una
dependencia que en sistemas GNU/Linux no se tiene y si en sistemas Windows, y es
que es necesario tener una dll que permite acceder al registro para buscar el directorio
de instalación OpenOffice.org; no obstante, esta dll se distribuirá siempre por defecto
sea cual sea la plataforma a utilizar.
Objetivo específico 6: El API de OpenSheet generada cumple con este objetivo, y
además su incorporación en las otras dos aplicaciones creadas, comando y servicio
web, validan su uso en otras aplicaciones y proyectos.
Objetivo específico 7: El comando generado está preparado para ser ejecutado desde
un terminal y no sólo permite hacer uso de las operaciones de la API a través del
script básico proporcionado, si no que permite utilizarse para múltiples propósitos,
para ello basta con ampliar su funcionalidad simplemente creando un script escrito
en Groovy, y aprovechando sus capacidades de inyección de dependencias desde un
fichero .properties de datos.
Objetivo específico 8: El servicio web generado no sólo ofrece las funcionalidades
de la librería de manera remota, si no que al igual que el comando, permite ampliar
su funcionalidad a través de scripts escritos en Groovy y registrados. De esta manera
un usuario puede seleccionar que script desea utilizar y enviar una lista de variables
que serán inyectadas como dependencias a dicho script, para una vez finalizada la
ejecución devolver los ficheros resultantes.

6. CONCLUSIONES 107
Como se puede ver se ha cumplido ampliamente tanto con el objetivo general como con
cada uno de los ocho objetivos específicos marcados al comienzo del proyecto.
6.2. Posibles mejoras y ampliaciones
Aunque en la sección anterior se ha visto que se ha cumplido ampliamente con los objetivos
marcados al inicio del proyecto, durante el desarrollo del mismo se han detectado posibles
mejoras y ampliaciones de funcionalidad que no han sido abordadas por estar fuera del
alcance del proyecto, pero que son ahora propuestas como posibles desarrollos futuros.
Las posibles mejoras y ampliaciones detectadas han sido las siguientes:
6.2.1. Uso de OpenOffice.org remoto
Actualmente la API o librería OpenSheet, y por tanto las aplicaciones que la usan, necesitan
que en la máquina donde se vayan a utilizar esté instalada la suite ofimática OpenOffice.org.
Una de las posibilidades que permite la alternativa de usar OpenOffice.org, a través
de UNO, es la de conectarse por socket a un proceso remoto y hacer uso de sus funcionalidades
sin necesidad de tener instalada la suite en la máquina local donde se está ejecutando la
aplicación que la va a usar.
Para permitir usar la API sin necesidad de tener instalada en la misma máquina la suite
ofimática, se podría ampliar la funcionalidad de OpenSheet para que por configuración se
pueda elegir el modo de conectarse a OpenOffice.org, ya sea a través de una tubería o pipe
para una conexión local, o a través de un socket por conexión remota.
Esta ampliación en la funcionalidad es sencilla de implementar pues sólo es necesario
modificar la clase Bootstrap, que se incluye en la API, para que lea de algun fichero de
configuración la opción elegida y ya establezca el mecanismo de comunicación elegido con
OpenOffice.org.
6.2.2. Soporte para fórmulas
A través de OpenSheet se permite insertar y extraer datos de celdas, concretamente se
permite trabajar con datos numéricos y con cadenas de texto; pero OpenOffice.org ofrece
otras posibilidades como trabajar con fórmulas.
Se podría incluir en la API de OpenSheet las operaciones para trabajar con fórmulas, y
luego incorporar los mecanismos necesarios para usarlos en el comando y el servicio web.
Las operaciones que se podrían implementar son:
Inserción de fórmula: permite insertar una fórmula a una celda o rango de celdas.
Extracción de fórmula: permite recuperar de una celda una fórmula asignada. Además,

108 6. CONCLUSIONES
también permitir la recuperación de todas las fórmulas de un rango.
Validación de fórmula: permite realizar la comprobación de si una fórmula es correcta
sintácticamente.
Esta ampliación de funcionalidad tiene un alcance mayor que la propuesta anterior pues es
necesario realizar cambios en el objeto SpreadSheet y en su interfaz ISpreadSheet. Además
si se quiere usar desde el comando y el servicio web es necesario incluir cambios en el script
creado, de manera que se puedan incluir las fórmulas en el fichero de datos para permitir su
uso.
6.2.3. Añadir nuevos tipos para la inserción de dependencias
El objeto ScriptExecuter, usado tanto en el comando como en servicio web, es capaz de
interpretar algunas variables especiales definidas en un objeto Properties para crear objetos e
inyectarlos a un script. Actualmente los tipos de variables especiales que se soportan son:
@number;: se transforma en un objeto de tipo Double.
@list;: genera una lista de cadenas con los valores que le acompañan.
@OpenSheetManager;: inyecta el objeto OpenSheetManager para que sea utilizado
por el script.
@OpenSheetDocument;: permite crear o abrir un documento creando un objeto OpenSheetDocument
que es inyectado a la variable correspondiente del script.
Aunque se puede delegar a los scripts que a partir de la cadena de texto recuperada la
interpreten y generen los objetos que necesiten, sería bueno ampliar los tipos de variables
especiales que se soportan, algunos tipos que podrían ser útiles:
Lista heterogénea: definir una lista que sea capaz de contener a su vez otras variables
especiales de manera que se puedan crear listas heterogéneas. Por ejemplo una lista
que contenga objetos de tipo cadena y de tipo numérico.
Mapa básico: permitir crear mapas de clave/valor donde ambos sean tratados como
cadenas.
Mapa heterogéneo: permitir crear mapas donde la clave sea una cadena y el valor
pueda ser cualquier tipo de las variables especiales.
El implementar estos mecanismos no es complejo, la dificultad viene dada por la necesidad
de diseñar una sintaxis sencilla, que permita escribir como el valor de una propiedad todo lo

6. CONCLUSIONES 109
necesario para crear objetos de esos tipos. La sintaxis sencilla es imprescindible puesto que
estos tipos serán usados en los ficheros de datos o lista de variables que en la mayoría de los
casos serán escritos por usuarios.
6.2.4. Crear nuevos scripts para uso general
La característica más destacada de las aplicaciones generadas, tanto el comando como
el servicio web, son las posibilidades que permiten gracias a la capacidad de ejecución de
scripts de Groovy y la capacidad de inyección de dependencias. Como muestra de esto se ha
creado un script para uso genérico que en función de los datos recibidos realiza una serie de
operaciones sobre hojas de cálculo, pero las posibles funciones de estos artefactos software
van más allá, simplemente creando nuevos scripts en lenguaje Groovy.
Algunas ideas que pueden contener los scripts son:
Envío de correo electrónicos: se puede añadir en los scripts por ejemplo para programar
una tarea que compruebe el contenido de determinadas celdas de documentos de
hojas de cálculo y según ciertos valores enviar correos electrónicos con algún aviso.
Por ejemplo, en una empresa donde el control de gestión o la contabilidad se almacene
en documentos de hojas de cálculo, se programe una tarea que lance el comando con
dicho script de manera que se comprueben las celdas que contienen los valores clave y
que si hay alguna anomalía envíe un correo a los departamentos y personas indicadas.
Consultas a bases de datos: se puede añadir en los scripts la posibilidad de conectarse
a bases de datos para integrar su uso con el de las hojas de cálculo. Por ejemplo, para
realizar una migración en la que se quieren almacenar todos los datos almacenados en
hojas de cálculo a una base de datos.
Conectividad por socket: se puede añadir la manera de comunicarse con otras operaciones
a través de sockets para obtener datos a insertar en documentos y viceversa
para enviar datos leídos.
Ejecución de otras aplicaciones: se puede añadir la posibilidad de que se indique en
el fichero de datos la ruta de las aplicaciones a ejecutar, de manera que haciendo uso
de los objetos de OpenSheet se extraigan datos de documentos de hojas de cálculo y
se usen como argumentos en la ejecución.
6.2.5. Permitir dependencias entre scripts
Actualmente el ScriptExecuter tiene la limitación de que no permite que el script a ejecutar
tenga dependencias de otros scripts, de manera que si existen funciones en otros scripts de
Groovy estos no se resuelven correctamente y falla.

110 6. CONCLUSIONES
El resolver esta limitación permitiría reutilizar con OpenSheet aquellos scripts escritos en
Groovy para otros propósitos que estuvieran divididos en diferentes ficheros.
6.3. Conclusiones personales
A continuación se exponen las conclusiones personales del autor sobre las experiencias
que se han tenido durante el desarrollo del proyecto.
6.3.1. Conclusiones sobre la metodología de planificación
Las conclusiones personales sobre el uso de la adaptación de la metodología ágil Scrum y
de las características del entorno de este proyecto son las siguientes:
1. Utilizar desarrolladores para llevar a cabo un proyecto o las partes principales sin que
tengan una dedicación completa aumenta la dificultad tanto de gestión como de planificación.
2. La metodología de planificación usada permite detectar enseguida las desviaciones de
las planificaciones y actuar en consecuencia.
3. El cambiar los requisitos durante el desarrollo del proyecto se ha realizado de manera
sencilla, permitiendo adaptar rápidamente la planificación a las nuevas necesidades.
Creo que a día de hoy ofrece más posibilidades la rápida adaptación de los requisitos,
que el tratar de prever todas las posibles necesidades cuando no se tiene todo el conocimiento
de la solución, pues normalmente durante el desarrollo se adquieren nuevos
conocimientos que permiten a su vez detectar nuevos requisitos.
6.3.2. Conclusiones sobre la metodología de desarrollo
Las conclusiones personales sobre el uso de TDD como metodología de desarrollo han
sido las siguientes:
1. El uso de TDD es complejo para desarrollares que estén acostumbrados a implementar
primero la solución y a realizar las pruebas después, lo que aumenta en algunos casos
el tiempo de desarrollo.
2. El realizar el diseño a partir de las pruebas garantiza que todo el código va a estar
probado. De esta manera se evita que una vez realizado el código haya que modificarlo
para poder probarlo. Esto sucede cuando es necesario realizar cambios en la visibilidad
de métodos o es necesario añadir nuevos métodos para poder inyectar mocks para poder
realizar pruebas unitarias.

6. CONCLUSIONES 111
3. Todos los tipos de pruebas son importantes, y aunque se cumplan todas las pruebas unitarias
siempre pueden aparecer problemas ocultos a través de la realización de pruebas
de integración o de sistema.
4. La refactorización que define el algoritmo de TDD permite eliminar el código repetido,
y por tanto innecesario, en cuanto se crea, obligando a tener código más limpio y
mantenible. Esta refactorización se aplica tanto en el código de la aplicación como en
las pruebas, donde habitualmente se un uso inadecuado del copiar y pegar.
5. Es imprescindible tener conocimientos de patrones de diseño y tener un buen criterio
para estructurar aplicaciones cuando se realiza el paso de refactorización. Pues es la
manera de poder obtener buenos diseños como resultados de aplicar este paso del
algoritmo de TDD.
6. La refactorización no es un paso automático pues necesita que se apliquen los criterios
necesarios para que de ella de como resultado un buen diseño, pero si es un paso
fundamental.

ANEXOS

Anexo A
Manual de usuario
A.1.
OpenSheet Command
OpenSheet Command es una herramienta escrita en Java que permite operar con documentos
de hojas de cálculo de manera automática a partir de los datos contenidos en un
fichero .properties pasado en la ejecución y de un script de acciones seleccionado. Esta herramienta
esta diseñada para ser ejecutada desde un terminal o consola del sistema, y hace
uso de OpenSheet API y OpenOffice.org Calc.
OpenSheet Commnad, a través del script que proporciona, permite realizar las siguientes
operaciones según los valores asignados en el fichero de datos a usar en la ejecución:
Inserción y extracción de datos de celdas.
Añadir y eliminar hojas de cálculo a un documento.
Conversión de un documento a cualquiera de los formatos de hojas de cálculo soportados
(xls, xlt, xlsx, ods, odt).
Exportar un documento de hojas de cálculo a PDF.
A.1.1. Instalación
La instalación de OpenSheet Command es muy simple pues basta con descomprimir el
fichero distribuido en el directorio deseado. De esa manera se tendrá el propio comando
OpenSheetCommand.jar y otros directorios que necesita el comando, por tanto para garantizar
su correcto funcionamiento es necesario mantener la estructura que genera el fichero tras
su descompresión.
Para poder usar el comando es necesario tener instalados los siguientes requisitos:
Sistema operativo Windows o GNU/Linux
Java JRE 6
OpenOffice.org 3.0 o superior.
115

116 A. MANUAL DE USUARIO
A.1.2. Operación
Para ejecutar el comando se debe escribir en un terminal o consola del sistema lo siguiente:
java -jar OpenSheetCommand.jar -script={script_file} -data={data_file}
Listado A.1: Ejecución OpenSheet Command
En lo indicado en el listado A.1 se deben sustituir los valores entre llaves por los ficheros
que correspondan. La descripción de los argumentos es la siguiente:
-script= : Es el argumento utilizado para indicar el script a ejecutar, en lugar de {script_file}
se debe poner la ruta al script que se desea ejecutar. Este argumento es obligatorio.
-data= : Es el argumento utilizado para indicar el fichero de datos .properties que contienen
nombres de las variables y los valores a inyectar en el script seleccionado. En lugar
de {data_file} se debe poner la ruta al fichero .properties que se desea utilizar. Este
argumento es obligatorio.
A continuación, se describirá el formato genérico de los ficheros de datos.
A.1.3.
Formato de fichero de datos
El fichero de datos es un fichero .properties de Java, es decir, es un fichero con pares
clave/valor sensibles a mayúsculas, donde la clave es el identificador de la variable a la que
se le va a inyectar el valor.
El comando por cada clave definida, asigna una cadena con el valor a la variable del script
que tiene como nombre el mismo que el de la clave.
Existen unos valores reservados para asignar a las claves, de manera que a la variable del
script en lugar de asignarle una cadena con el valor, se le inyecta un objeto. Todo valor reservado
tiene la siguiente sintaxis: @palabra_reservada; seguido de los valores necesarios
según la variable especial a utilizar.
Las variables especiales para inyectar objetos son:
@OpenSheetManager; : Permite inyectar el objeto OpenSheetManager para poder crear y
abrir documentos de hojas de cálculo desde el script. Un ejemplo de uso es:
manager = @OpenSheetManager;
Listado A.2: Ejemplo de uso de variable especial @OpenSheetManager;

A. MANUAL DE USUARIO 117
Con el listado A.2 se inyectará el objeto OpenSheetManager a la variable manager del
script que se va a ejecutar.
@OpenSheetDocument;create,ruta_fichero : Crea un nuevo documento de hojas de cálculo
en la ruta indicada, representado por un objeto IOpenSheetDocument que será inyectado
a la variable del script indicada. Un ejemplo de uso es:
documento1 = @OpenSheetDocument;create,contabilidad1.ods
Listado A.3: Ejemplo de uso de variable especial @OpenSheetDocument; para crear un
documento
Con el listado A.3 se creará un documento en la ruta de ejecución de tipo ods con el
nombre indicado y además se inyectará el objeto OpenSheetDocument, que permite
trabajar con dicho documento, a la variable documento1 del script que se va a ejecutar.
@OpenSheetDocument;open,ruta_fichero : Abre un documento de hojas de cálculo que
se encuentra en la ruta indicada, representado por un objeto IOpenSheetDocument que
será inyectado a la variable del script indicada. Un ejemplo de uso es:
documento1 = @OpenSheetDocument;open,movimientos.xls
Listado A.4: Ejemplo de uso de variable especial @OpenSheetDocument; para abrir un
documento
Con el listado A.4 se abrirá el documento movimientos.xls almancenado en la ruta
de ejecución y de tipo xls y además se inyectará el objeto OpenSheetDocument, que
permite trabajar con dicho documento, a la variable documento1 del script que se va a
ejecutar.
@number;numero : Permite crear objetos de tipo Double. Algunos ejemplos de uso son:
interes = @number;2.5
Listado A.5: Ejemplo de uso de variable especial @number;
Con el listado A.5 se creará un objeto de tipo Double con el valor de 2.5 que será
inyectado en la variable interes del script que se va a ejecutar.
@list;valor1,valor2 : Permite crear un objeto List, concretamente una lista de cadenas, donde
cada valor va separado por una coma. Hay que tener en cuenta las siguientes características:
1. Todos los espacios entre los separadores de valores son añadidos a la cadena.

118 A. MANUAL DE USUARIO
2. Para insertar un elemento con la cadena vacía basta con poner el separador sin
ningún contenido dentro.
3. Para usar la coma como valor dentro del elemento cadena a añadir en la lista, se
debe escapar usando //,
Algunos ejemplos de uso:
laborables = @list;lunes,martes,miercoles,jueves,viernes
Listado A.6: Ejemplo de uso de variable especial @list;
Con el listado A.6 se creará un objeto de tipo List con cinco objetos String (“lunes”,
“martes”, “miércoles”, “jueves”, “viernes”) que será inyectado en la variable laborables
del script que se va a ejecutar.
vacaciones = @list;1//,2//,3 y 4 de enero,15//,16 y 17 de agosto
Listado A.7: Ejemplo de uso de variable especial @list; con escape del separador
Con el listado A.7 se inyectará un objeto List con dos objetos String (“1,2,3 y 4 de
enero”, “15,16 y 17 de agosto”) a la variable vacaciones del script que se va a ejecutar.
var1 = @list;,ok,,ok
Listado A.8: Ejemplo de uso de variable especial @list; con cadenas vacias
Con el listado A.8 se inyectará un objeto List con cuatro objetos String (“”, “ok”, “”,
“ok”) a la variable var1 del script que se va a ejecutar.
A.1.4. Uso del script OpenSheetScript.groovy
Con la aplicación OpenSheet Command se distribuye un script, OpenSheetScript.groovy,
preparado para realizar las principales operaciones con documentos de hojas de cálculo, que
permite la API de OpenSheet, a través de la asignación de valores a una variables definidas
por dicho script. Las operaciones que permite realizar el script son:
Inserción y extracción de datos de celdas.
Añadir y eliminar hojas de cálculo a un documento.
Conversión de un documento a cualquiera de los formatos de hojas de cálculo soportados
(xls, xlt, xlsx, ods, odt).

A. MANUAL DE USUARIO 119
Exportar un documento de hojas de cálculo a PDF.
Para indicar al script que operaciones se desean realizar, es necesario hacerlo a través del
fichero de datos .properties. Para ello es necesario que el fichero contenga todas las claves
definidas por el script, aunque a algunas no se les asigne ningún valor. Las claves o variables
definidas por el script son las siguientes:
1. openSheetDocument: Es la variable que contiene el objeto OpenSheetDocument con
el que debe trabajar. Siempre debe llevar valor, y debe ser la variable especial de comando
@OpenSheetDocument; con los parámetros deseados.
2. logFileName: Es la variable donde se le puede especificar la ruta y el nombre del fichero
de log. Si no se le asigna valor, por defecto crea un fichero en la ruta de ejecución
con el nombre opensheet.log.
3. deleteSheets: Es la variable donde se le indica el nombre de las hojas de cálculo que
se quieren borrar en el documento. Si no se asigna valor no realizará la operación de
borrado por nombre.
4. deleteSheetsByPosition: Es la variable donde se le especifica la posición de las hojas
de cálculo que se quieren borrar en el documento. Si no se asigna valor no realizará la
operación de borrado por posición.
5. addSheets: Es la variable donde se le asigna el nombre de las hojas de cálculo que se
quieren añadir al documento. Si no se asigna valor no realizará la operación de añadir
hojas de cálculo.
6. insertCellsValues: Es la variable donde se asigna cada uno de los valores a insertar en
celdas como texto, usando el nombre de las hojas de cálculo para referenciarlas. Si no
se asigna valor a la variable no realizará la operación que representa.
7. insertCellsValuesBySheetPosition: Es la variable donde se asigna cada uno de los
valores a insertar en celdas como texto, usando la posición de las hojas de cálculo
para referenciarlas. Si no se asigna valor a la variable no realizará la operación que
representa.
8. insertCellsNumericValues: Es la variable donde se le asigna cada uno de los valores
a insertar en celdas como valores numéricos, usando el nombre de las hojas de cálculo
para referenciarlas. Si no se asigna valor a la variable no realizará la operación que
representa.
9. insertCellsNumericValuesBySheetPosition: Es la variable donde se le asigna cada
uno de los valores a insertar en celdas como valores numéricos, usando la posición de

120 A. MANUAL DE USUARIO
las hojas de cálculo para referenciarlas. Si no se asigna valor a la variable no realizará
la operación que representa.
10. extractCellsValues: Es la variable donde se le especifica las celdas que de las que se
quiere extraer su valor a un fichero, usando el nombre de las hojas de cálculo para referenciarlas.
Si no se asigna valor a la variable no realizará la operación que representa.
11. extractCellsValuesBySheetPosition: Es la variable donde se le especifica las celdas
que de las que se quiere extraer su valor a un fichero, usando la posición de las hojas de
cálculo para referenciarlas. Si no se asigna valor a la variable no realizará la operación
que representa.
12. extractCellsValuesFile: Es la variable donde se le puede especificar la ruta y el nombre
del fichero donde se deben guardar los valores extraídos de las celdas. Si no se le
asigna valor, por defecto crea un fichero en la ruta de ejecución con el nombre opensheet.out.
13. saveDocumentTo: Es la variable donde se le puede especificar que guarde el documento
modificado con otro nombre y formato. Es decir, se puede usar para realizar
una conversión de formato, para ello basta con usar un nombre de fichero con la extensión
del formato al que se desea convertir. Además, también permite la exportación
a PDF. Si no se le asigna valor entonces realiza el salvado en el fichero de origen
indicado en la variable openSheetDocument.
Hay que tener en cuenta que siempre deben estar definidas todas las variables en el fichero
de datos, en el caso de que no se quiera realizar alguna acción, basta con no asignarle
valor.
A continuación, se explicará en mayor de detalle cada una de las variables del script.
Variable openSheetDocument
Es la variable donde el script espera recibir el objeto de tipo OpenSheetDocument con el
que debe trabajar; es decir, se le debe asignar la variable especial, explicada en el apartado
del formato del fichero de datos, @OpenSheetDocument; con los parámetros adecuados
según si se quiere crear un nuevo documento de hojas de cálculo o abrir uno ya existente.
Es obligatorio que esta variable tenga siempre un valor válido asignado. Unos ejemplos de
asignación de valores a esta variable son:
openSheetDocument = @OpenSheetDocument;create,doc.ods
Listado A.9: Ejemplo de asignación de nuevo documento a la variable openSheetDocument
de OpenSheetScript

A. MANUAL DE USUARIO 121
En el listado A.9 se muestra un ejemplo para asignarle a la variable un nuevo documento
llamado doc.ods para trabajar con OpenSheetScript.
openSheetDocument = @OpenSheetDocument;open,doc.ods
Listado A.10: Ejemplo de asignación de un documento a la variable openSheetDocument de
OpenSheetScript
En el listado A.10 se muestra un ejemplo para asignar a la variable un documento de hojas
de cálculo ya existente llamado doc.ods para trabajar con OpenSheetScript.
Variable logFileName
Es la variable donde se le puede indicar al script el nombre y ruta donde se desea guardar
el fichero de log que genera durante su ejecución. En el caso de que no se asigne valor, por
defecto, crea un fichero de log en el directorio de ejecución con el nombre opensheet.log.
Unos ejemplos de asignación de valores a esta variable son:
logFileName =
Listado A.11: Ejemplo de uso por defecto de la variable logFileName
En el listado A.11 se muestra un ejemplo para usar el fichero de log por defecto, es decir,
que no se ha asignado ningún valor a la variable.
logFileName = prueba.log
Listado A.12: Ejemplo de asignación de un fichero a la variable logFileName de
OpenSheetScript
En el listado A.12 se muestra un ejemplo para asignar a la variable el nombre de fichero
prueba.log que debe utilizar para crear el log; en ese caso se creará en el mismo directorio
de ejecución.
Variable deleteSheets
Es la variable donde el script espera recibir la información para realizar el borrado de
hojas de cálculo a partir de los nombres de estas. Si no se asigna ningún valor a esta variable
no se realizará la acción relacionada con ella. El valor a introducir en el caso de querer
realizar la acción de borrado debe ser cada una de las hojas de cálculo a borrar separadas por
punto y coma. Una cosa a tener en cuenta, es que para permitir borrar todas las hojas de un
documento el script siempre realiza antes la operación de añadir hojas de cálculo, es decir,
si crea un documento de hojas de cálculo nuevo y se desea borrar las tres hojas por defecto,
se puede hacer añadiendo hojas a través de la variable adecuada en el fichero de datos. Un
ejemplo de asignación de valores a esta variable es:

122 A. MANUAL DE USUARIO
deleteSheets = hoja1;facturas enero;borrador
Listado A.13: Ejemplo de asignación de valores a la variable deleteSheets de
OpenSheetScript
En el listado A.13 se muestra un ejemplo para asignarle a la variable los nombres para que
borre tres hojas de cálculo del documento: hoja1, facturas enero y borrador.
Variable deleteSheetsByPosition
Es la variable donde el script espera recibir la información para realizar el borrado de hojas
de cálculo a partir de la posición de estas. Si no se asigna ningún valor a esta variable no se
realizará la acción relacionada con ella. El valor a introducir en el caso de querer realizar la
acción de borrado debe ser cada una de las posiciones de hojas de cálculo a borrar separadas
por punto y coma. Es importante tener en cuenta tres cosas, la primera es que las posiciones
empiezan con el 0; la segunda es que una vez que se borra una hoja de cálculo, todas las
hojas que estaban detrás de la eliminada reducen su posición en uno; la tercera cosa a tener
en cuenta, es que para permitir borrar todas las hojas de un documento el script siempre
realiza antes la operación de añadir hojas de cálculo. Uns ejemplos de asignación de valores
a esta variable son:
deleteSheets = 2;1;0
Listado A.14: Ejemplo de asignación de valores a la variable deleteSheetsByPosition de
OpenSheetScript
En el listado A.14 se muestra un ejemplo para borrar las hojas de las posiciones 2, 1 y
0. Al colocar las variables en el orden inverso, el borrado se puede realizar sin problemas,
puesto que al borrar la 2 no afectará al orden de la 1 y de la 0, y así sucede con la 1.
deleteSheets = 0;0;0
Listado A.15: Ejemplo de asignación de valores repetidos a la variable
deleteSheetsByPosition de OpenSheetScript
En el listado A.15 se muestra un ejemplo que da el mismo resultado que el ejemplo del
listado A.14, es decir, primero se borrará la primera hoja de cálculo, por lo que la segunda
pasará a ser la primera, y la tercera la segunda y así sucesivamente; después, se borrará la
primera hoja de cálculo que en realidad era la segunda en el original, y después se volverá a
borrar la primera que era la tercera en el orden original.
Variable addSheets
Es la variable donde el script espera recibir la información para añadir nuevas hojas de
cálculo a partir de los nombres de estas. Si no se asigna ningún valor a esta variable no se

A. MANUAL DE USUARIO 123
realizará la acción relacionada con ella. El valor a introducir en el caso de querer realizar
la acción de añadir hojas de cálculo debe ser el nombre de cada una de las hojas de cálculo
a añadir separadas por punto y coma. Una cosa a tener en cuenta es que siempre se realiza
antes la operación de añadir hojas de cálculo que las de borrado, esto permite poder borrar
todas las hojas de cálculo existentes o por defecto. Un ejemplo de asignación de valores a
esta variable es:
addSheets = hoja1;facturas enero;borrador
Listado A.16: Ejemplo de asignación de valores a la variable addSheets de OpenSheetScript
En el listado A.16 se muestra un ejemplo para asignarle a la variable los nombres para que
añada tres hojas de cálculo al documento: hoja1, facturas enero y borrador.
Variable insertCellsValues
Es la variable donde el script espera recibir la información para insertar valores de tipo
texto o cadena a celdas de las diferentes hojas de cálculo del documento, referenciadas por
nombre. Si no se asigna ningún valor a esta variable no se realizará la acción relacionada con
ella. El valor a introducir en el caso de querer realizar la acción de insertar valores de tipo
texto es nombre_hoja_calculo:celda1=valor1,celda2=valor2 y separado por punto y coma
para las diferentes hojas de cálculo. Un ejemplo de asignación de valores a esta variable es:
insertCellsValues = hoja1:c6=Resumen mensual,d5=Del 1 al
20;facturas enero:aa1=Diferencial,a2=11/04/2011;listado:b12=Generado
mensualmente
Listado A.17: Ejemplo de asignación de valores a la variable insertCellsValues de
OpenSheetScript
En el listado A.17 se muestra un ejemplo para asignarle a la variable el valor para que añada
diferentes textos a celdas de tres hojas de cálculo, concretamente, en la hoja de cálculo
llamada hoja1 se insertarán en la celda c6 el texto “Resumen mensual” y en la celda d5 el
texto “Del 1 al 20”; en la hoja facturas enero se insertarán en la celda aa1 el texto “Diferencial”
y en la celda a2 “11/04/2011”; por último, en la celda b12 de la hoja listado se insertará
el texto “Generado mensualmente”.
Variable insertCellsValuesBySheetPosition
Es la variable donde el script espera recibir la información para insertar valores de tipo
texto o cadena a celdas de las diferentes hojas de cálculo del documento, referenciadas por
posición. Si no se asigna ningún valor a esta variable no se realizará la acción relacionada
con ella. El valor a introducir en el caso de querer realizar la acción de insertar valores de
tipo texto es posicion_hoja_calculo:celda1=valor1,celda2=valor2 y separado por punto y
coma para las diferentes hojas de cálculo. La primera posición se corresponde con el 0. Un
ejemplo de asignación de valores a esta variable es:

124 A. MANUAL DE USUARIO
insertCellsValuesBySheetPosition = 0:c6=Resumen mensual,d5=Del 1 al
20;2:aa1=Diferencial,a2=11/04/2011;1:b12=Generado
mensualmente
Listado A.18: Ejemplo de asignación de valores a la variable insertCellsValues de
OpenSheetScript
En el listado A.18 se muestra un ejemplo para asignarle a la variable el valor para que
añada diferentes textos a celdas de tres hojas de cálculo, concretamente, en la hoja de cálculo
con la primera posición se insertarán en la celda c6 el texto “Resumen mensual” y en la celda
d5 el texto “Del 1 al 20”; en la hoja con la tercera posición se insertarán en la celda aa1 el
texto “Diferencial” y en la celda a2 “11/04/2011”; por último, en la celda b12 de la hoja con
segunda posición se insertará el texto “Generado mensualmente”.
Variable insertCellsNumericValues
Es la variable donde el script espera recibir la información para insertar valores de tipo numérico
a celdas de las diferentes hojas de cálculo del documento, referenciadas por nombre.
Si no se asigna ningún valor a esta variable no se realizará la acción relacionada con ella. El
valor a introducir en el caso de querer realizar la acción de insertar valores de tipo numérico
es nombre_hoja_calculo:celda1=valor1,celda2=valor2 y separado por punto y coma para
las diferentes hojas de cálculo. Un ejemplo de asignación de valores a esta variable es:
insertCellsNumericValues = hoja1:c6=12.45,d5=1050;facturas
enero:aa1=275589,a2=23;listado:b12=31
Listado A.19: Ejemplo de asignación de valores a la variable insertCellsValues de
OpenSheetScript
En el listado A.19 se muestra un ejemplo para asignarle a la variable el valor para que
añada diferentes valores numéricos a celdas de tres hojas de cálculo, concretamente, en la
hoja de cálculo llamada hoja1 se insertarán en la celda c6 el valor numérico 12.45 y en la
celda d5 1050; en la hoja facturas enero se insertarán en la celda aa1 el valor numérico
275589 y en la celda a2 23; por último, en la celda b12 de la hoja listado se insertará el valor
numérico 31.
Variable insertCellsNumericValuesBySheetPosition
Es la variable donde el script espera recibir la información para insertar valores de tipo numérico
a celdas de las diferentes hojas de cálculo del documento, referenciadas por posición.
Si no se asigna ningún valor a esta variable no se realizará la acción relacionada con ella. El
valor a introducir en el caso de querer realizar la acción de insertar valores de tipo numérico
es posicion_hoja_calculo:celda1=valor1,celda2=valor2 y separado por punto y coma para
las diferentes hojas de cálculo. La primera posición se corresponde con el 0. Un ejemplo de
asignación de valores a esta variable es:

A. MANUAL DE USUARIO 125
insertCellsNumericValuesBySheetPosition = 0:c6=12.45,d5=1050;2:aa1
=275589,a2=23;1:b12=31
mensualmente
Listado A.20: Ejemplo de asignación de valores a la variable insertCellsValues de
OpenSheetScript
En el listado A.18 se muestra un ejemplo para asignarle a la variable el valor para que
añada diferentes valores numéricos a celdas de tres hojas de cálculo, concretamente, en la
hoja de cálculo con la primera posición se insertarán en la celda c6 el valor numérico 12.45
y en la celda d5 1050; en la hoja con la tercera posición se insertarán en la celda aa1 el valor
numérico 275589 y en la celda a2 23; por último, en la celda b12 de la hoja con segunda
posición se insertará el valor numérico 31.
Variable extractCellsValues
Es la variable donde el script espera recibir la información para extraer los de celdas de
las diferentes hojas de cálculo del documento, referenciadas por nombre. Si no se asigna
ningún valor a esta variable no se realizará la acción relacionada con ella. El valor a introducir
en el caso de querer realizar la acción de extracción de valores es nombre_hoja_-
calculo:celda1,celda2 y separado por punto y coma para las diferentes hojas de cálculo. Los
valores extraídos se guardarán en el fichero que contenga la variable extractCellsValuesFile.
Un ejemplo de asignación de valores a esta variable es:
extractCellsValues = hoja1:c6,d5;facturas enero:aa1,a2;listado:b12
Listado A.21: Ejemplo de asignación de valores a la variable extractCellsValues de
OpenSheetScript
En el listado A.21 se muestra un ejemplo para asignarle a la variable el valor para que
extraiga de diferentes celdas los valores que contengan, concretamente de celdas de tres
hojas de cálculo: de la hoja de cálculo llamada hoja1 se extraerán los valores almacenados
en las celdas c6 y d5; de la hoja facturas enero se extraerán los valores de las celdas aa1 y
a2; por último, se extraerá el valor de la celda b12 de la hoja listado.
Variable extractCellsValuesBySheetPosition
Es la variable donde el script espera recibir la información para extraer los de celdas de las
diferentes hojas de cálculo del documento, referenciadas por posición. Si no se asigna ningún
valor a esta variable no se realizará la acción relacionada con ella. El valor a introducir
en el caso de querer realizar la acción de extracción de valores es posicion_hoja_calculo:celda1,celda2
y separado por punto y coma para las diferentes hojas de cálculo; teniendo
en cuenta que la primera posición se corresponde con el 0. Los valores extraídos se guardarán
en el fichero que contenga la variable extractCellsValuesFile. Un ejemplo de asignación
de valores a esta variable es:

126 A. MANUAL DE USUARIO
extractCellsValues = 0:c6,d5;2:aa1,a2;1:b12
Listado A.22: Ejemplo de asignación de valores a la variable
extractCellsValuesBySheetPosition de OpenSheetScript
En el listado A.22 se muestra un ejemplo para asignarle a la variable el valor para que
extraiga de diferentes celdas los valores que contengan, concretamente de celdas de tres
hojas de cálculo: de la hoja de cálculo que se encuentra en la primera posición se extraerán
los valores almacenados en las celdas c6 y d5; de la tercera hojas se extraerán los valores de
las celdas aa1 y a2; por último, se extraerá el valor de la celda b12 de la segunda hoja.
Variable extractCellsValuesFile
Es la variable donde se le puede indicar al script el nombre y ruta donde se desea guardar el
fichero con los datos extraídos de las celdas. En el caso de que no se asigne valor, por defecto,
crea un fichero en el directorio de ejecución con el nombre opensheet.out. El fichero creado
tiene la estructura de un fichero .properties, donde como clave escribe el nombre de la hoja de
cálculo y a continuación la celda, ambas separadas por un punto. Un ejemplo sería “hoja1.d2
= 23” donde se indica que la celda d2 de la hoja 1 tiene un valor de 23. Hay que tener en
cuenta que si el nombre de la hoja de cálculo contiene espacios entonces no se generará un
fichero de propiedades válido. Unos ejemplos de asignación de valores a esta variable son:
extractCellsValuesFile =
Listado A.23: Ejemplo de uso por defecto de la variable extractCellsValuesFile
En el listado A.23 se muestra un ejemplo para usar el fichero de extracción por defecto, es
decir, que no se ha asignado ningún valor a la variable.
extractCellsValuesFile = resultados_doc1
Listado A.24: Ejemplo de asignación de un fichero a la variable extractCellsValuesFile de
OpenSheetScript
En el listado A.24 se muestra un ejemplo para asignar a la variable el nombre de fichero
resultados_doc1 que debe utilizar para crear el fichero donde se almacenarán los datos
extraídos de las celdas del documento; en ese caso se creará en el mismo directorio de ejecución.
Variable saveDocumentTo
Es la variable donde se le puede indicar al script un nuevo nombre y ruta donde se desea
guardar el fichero con el que ha estado trabajando el script. Si el nombre de fichero indicado
tiene otra extensión se realizará la conversión a ese formato, y si la extensión es PDF se

A. MANUAL DE USUARIO 127
realizará la exportación. En el caso de que no se asigne valor, por defecto, realizará la operación
de salvado sobre el fichero pasado a través de la variable openSheetDocument. Unos
ejemplos de asignación de valores a esta variable son:
saveDocumentTo =
Listado A.25: Ejemplo de uso por defecto de la variable saveDocumentTo
En el listado A.25 se muestra un ejemplo para salvar las modificaciones sobre el documento
de entrada, es decir, que no se ha asignado ningún valor a la variable.
saveDocumentTo = doc2.xls
Listado A.26: Ejemplo de asignación de un fichero a la variable saveDocumentTo de
OpenSheetScript
En el listado A.26 se muestra un ejemplo para asignar a la variable el nombre de fichero
doc2.xls, que será el fichero en el que se guardarán los cambios realizados en el fichero de
entrada. Si el fichero de entrada usado tiene una extensión distinta al asignado, de manera
automática se realizará la conversión al formato del fichero asignado.
saveDocumentTo = resultados.pdf
Listado A.27: Ejemplo de asignación de un fichero con extensión PDF a la variable
saveDocumentTo de OpenSheetScript
En el listado A.27 se muestra un ejemplo para asignar a la variable el nombre de fichero
resultados.pdf, de manera que el contenido del documento será exportado a un documento
de tipo PDF, y en el documento de entrada no se guardarán los cambios realizados.
A.1.5. Ejemplo de uso de OpenSheet Command
En este apartado se va a mostrar un ejemplo para usar OpenSheet Command, haciendo
uso del script con el que se distribuye el comando.
Los supuestos del ejemplo son los siguientes: en una empresa se tiene un documento
de Excel que se quiere usar a modo de plantilla, es decir, insertar los datos de facturas y
guardarlos en otro documento sin modificar el que se usa como plantilla.
La plantilla cuenta con una hoja de cálculo por cada mes, y otra más llamada totales. Se
quiere insertar los datos relativos a una factura, concretamente hay que insertar los siguientes
datos:

128 A. MANUAL DE USUARIO
En la hoja enero hay que insertar en la fila 2 desde la columna A hasta la E, el nombre
de la empresa, el NIF, nombre producto, cantidad y precio por unidad.
En la hoja totales hay que insertar el nombre de la empresa concretamente en la celda
aa2.
Además se quieren extraer los datos de la celda A7 de la hoja enero y de la celda ab55 de la
hoja totales.
Si los datos a insertar son de los siguientes:
Nombre empresa : Tapones S.A
NIF : A-762222
Producto : Corchos PAF-QA1
Cantidad : 105000
Precio unidad : 0,015
El fichero de datos que hay que generar es el siguiente:
openSheetDocument = @OpenSheetDocument;open,factura_plantilla.xls
logFileName = factura_plantilla.log
deleteSheets =
deleteSheetsByPosition =
addSheets =
insertCellsValues = enero:a2=Tapones S.A,b2=A-762222,c2=Corchos PAF-QA1;
totales:aa2=Tapones S.A
insertCellsValuesBySheetPosition =
insertCellsNumericValues = enero:d2=105000,e2=0,015
insertCellsNumericValuesBySheetPosition =
extractCellsValues = enero:a7;totales:ab55
extractCellsValuesBySheetPosition =
extractCellsValuesFile = extracto_insercion.txt
saveDocumentTo = factura_enero.xls
Listado A.28: Ejemplo de fichero de datos
En el fichero de datos del listado A.28 se han asignado valores sólo a las acciones que
se desean realizar, por ejemplo no se van a añadir ni borrar hojas de cálculo, ni a insertar
o a extraer valores a través de la posición de hojas de cálculo puesto que en este caso sólo
se conoce el nombre. Además de realizar las inserciones y extracciones correspondientes,
se va a crear un fichero de log con el nombre factura_plantilla.log y otro con los datos
extraídos, llamado extracto_insercion.txt. Además, todas las modificaciones realizadas se
guardarán en un documento del mismo formato llamado factura_enero.xls sin modificar el
fichero original.

A. MANUAL DE USUARIO 129
Por último habría que ejecutar el comando pasandole el fichero de datos generado y el
script OpenSheetScript.groovy.
A.2.
OpenSheet Web Service
OpenSheet Web Service es un servicio web escrito en Java usando JAX-WS que permite
operar con documentos de hojas de cálculo a partir de la selección de un script de Groovy y
una lista de variables o pares clave/valor. Este servicio hace uso de OpenSheet API y OpenOffice.org
Calc.
OpenSheet Web Service proporciona dos operaciones:
Operación listScripts: Esta operación devuelve una lista de objetos ScriptInfo con la
información necesaria para utilizar cada uno de los scripts disponibles.
Operación executeScript: Esta operación permite ejecutar un script pasándole una
lista de variables y un objeto Document que puede ser vacío; y una vez ejecutado el
script se devolverán los objetos Document que indiquen las variables de salida configuradas
en la información del script.
A.2.1.
Requisitos
Para poder usar el comando es necesario tener instalados los siguientes requisitos:
Sistema operativo Windows o GNU/Linux
Java JRE 6
OpenOffice.org 3.0 o superior.
Contenedor de servlets Java (Tomcat por ejemplo)
A.2.2. Despliegue
OpenSheet Web Service se distribuye en un fichero .war que hay que desplegar en el
contenedor de servlets que tenga instalado el usuario. Para más información se debe consultar
el manual del propio contenedor.
A.2.3.
Fichero web.xml
En el fichero web.xml de OpenSheet Web Service se deben configurar dos variables:
OPENSHEET_SCRIPTS_DIRECTORY: es el directorio que escaneará el servicio web
en cada arranque para localizar cada uno de los scripts de Groovy disponibles. Estos

130 A. MANUAL DE USUARIO
scripts deben tener además un fichero de propiedades con el mismo nombre del script
pero con extensión .properties, donde se indiquen las propiedades que necesita el servicio
para construir un ScriptInfo, esto se explicará con más detalle más adelante.
OPENSHEET_CACHE_DIRECTORY: es el directorio donde se guardarán los directorios
temporales creados para cada llamada a la operación de ejecución de un script.
Para evitar que dos llamadas al mismo script en el mismo momento pueda provocar
sobreescrituras, el servicio crea un directorio con un nombre único en el momento de
recibir la llamada y ahí es donde le indica al script que debe guardar todos los recursos.
Este directorio único lo crea dentro del directorio temporal, y lo elimina cuando
termina la operación de ejecución.
A.2.4. Activar scripts
Por motivos de seguridad, sólo se pueden usar aquellos scripts de Groovy que se encuentren
dentro del directorio configurado en el fichero web.xml, y que además tengan un fichero
Properties con el mismo nombre que el script, pero con extensión .properties, con las siguientes
propiedades configuradas:
description: es la propiedad donde se debe explicar qué hace el script y cómo se usa,
para que los clientes sepan que variables deben pasar al ejecutarlo.
outputVariables: son los nombres de variables del script que contienen la ruta de los
ficheros que deben ser devueltos tras la ejecución del script, separados por punto y
coma.
temporalDirectoryVariable: es el nombre de la variable del script donde el servicio
web debe indicarle que directorio temporal tiene asignado para que genere dentro de
él los ficheros que necesite con el fin de evitar conflictos entre diferentes llamadas al
script.
Si un script de Groovy se encuentra en el directorio de scripts pero no existe un fichero con
su nombre y la extensión .properties que contenga la información indicada, entonces no será
considerado un script válido para usarlo desde la operación de ejecución del servicio web.
Esto obliga a que se defina siempre como usar el script, evitando así que se copien scripts
directamente en el directorio sin crear el fichero de información.
Para aquellas variables que contengan nombres de ficheros, puesto que el servicio web
asigna un directorio temporal para cada ejecución, se debe utilizar sólo el nombre y no una
ruta.
Cuando el servicio web lee en las propiedades un valor especial con @OpenSheetDocument;
lo preprocesa y le añade al nombre la ruta al directorio temporal.

A. MANUAL DE USUARIO 131
Ejemplo de activación de script
En este ejemplo se va a configurar el script que se distribuye por defecto con OpenSheet
Command, OpenSheetScript.groovy.
Para usar el script lo primero es copiarlo en el directorio de scripts configurado en el
fichero web.xml, en la variable OPENSHEET_SCRIPTS_DIRECTORY. A continuación, se
debe crear un fichero OpenSheetScript.properties con los siguientes valores:
description=OpenSheetScript es el script por defecto que permite realizar
las
operaciones basicas de la API. Para saber como se debe usar consultar el
manual
de usuario.
outputVariables=saveDocumentTo;extractCellsValuesFile
temporalDirectoryVariable=tempDir
Listado A.29: Ejemplo de fichero Properties para script de servicio web
En el listado A.29 se puede ver que se ha añadido una descripción para explicar qué hace
el script y cómo usarlo, se han indicado que variables contienen los ficheros que se deben
devolver como resultados, en este caso la variable de salvar el fichero y la que contiene el
nombre del fichero con los datos extraídos. Por último, se indica a que variable debe asignar
el servicio web el directorio temporal para que el script lo use.
A.2.5. Clientes de OpenSheet Web Service
No se distribuyen clientes con el servicio web, no obstante es sencillo crear clientes para
este servicio a partir del uso de JAX-WS. Si se desea ampliar la información se debe consultar
el manual de desarrollo.

Anexo B
Manual de desarrollo
Este manual está orientado tanto para aquellos desarrolladores que quieren hacer uso de
la API de OpenSheet en sus aplicaciones como para los que quieren ampliar la funcionalidad
de OpenSheet Command o Web Service a través de la creación de nuevos scripts.
B.1.
Direcciones de interés
B.1.1. Repositorio
El proyecto OpenSheet cuenta con un repositorio donde siempre estará el último código
disponible para ser descargado por cualquier persona que así lo desee. La URL del repositorio
es la siguiente: https://arco.esi.uclm.es/svn/public/prj/opensheet/
En el directorio raíz del repositorio del proyecto se encuentran tres directorios:
trunk: Aquí es donde se puede encontrar el código principal que será usado para sacar
las versiones a distribuir de los diferentes componentes del proyecto. Si se desea tener
el código más actual y que vaya a formar parte de la siguiente versión, se puede coger
el código del trunk.
branches: Aquí es donde se generan diferentes ramas del proyecto para desarrollar en
paralelo funcionalidades que en principio no se desean incorporar directamente al proyecto,
y de hecho puede que no se lleguen a incorporar a ninguna versión del producto.
Si alguno de los desarrollos que se alojan en este directorio se van a usar, entonces se
realizará la operación de merge con el trunk, y por tanto, siempre se recomienda tomar
el código del trunk, dejando el código de este directorio a los desarrolladores del
proyecto.
tags: En este directorio por cada versión sacada se realiza una instantánea del repositorio
y se crea un directorio con el nombre de la versión. Este es el directorio donde se
pueden obtener el código de alguna de las versiones distribuidas.
Dentro del directorio trunk la distribución del proyecto es la siguiente:
133

134 B. MANUAL DE DESARROLLO
doc: Es el directorio que contiene la documentación del proyecto. En este directorio se
encuentra el documento de hojas de cálculo usado para la planificación, el anteproyecto
y los ficheros de latex que corresponden a la memoria del proyecto, en los que se
incluyen los manuales de usuario y de desarrollo.
src: Es el directorio donde se encuentra el código fuente del proyecto dividido en los
diferentes paquetes Java. Dentro del directorio src/org/opensheet/ se encuentra a su vez
un directorio para los componentes del proyecto y para los scripts:
• api: Contiene el código referente a la API de OpenSheet.
• command: Contiene el código referente a OpenSheet Command y la clase para
ejecutar scripts que también es compartida por el servicio web.
• webservice: contiene el código de OpenSheet Web Service, excepto la clase de
ejecución de scripts que se encuentra en el paquete del comando.
• scripts: contiene los scripts escritos en Groovy que se distribuyen con las versiones
del comando y los scripts que sirven de test de estos. Actualmente sólo se ha
generado un script: OpenSheetScript.groovy.
test: Contiene el código de todos los tests del proyecto, y la estructura es la misma que
la del directorio src, salvo porque no tiene el directorio scripts y en su lugar tiene un
directorio utils para las clases de utilidades de las pruebas.
B.1.2. Gestión de incidencias y peticiones de mejora
El proyecto cuenta con una herramienta de seguimiento de errores o bugs, y de peticiones
de mejora para que los usuarios puedan abrir incidencias de los problemas encontrados y
solicitar mejoras. Esta herramienta se encuentra dentro de la aplicación Redmine, la URL es
https://arco.esi.uclm.es:3000/projects/opensheet.
Además, desde la dirección de Redmine se puede ver la actividad del proyecto y realizar
comparación entre versiones desde la propia web.
B.2.
OpenSheet API
La librería o API de OpenSheet permite incorporar al desarrollador la funcionalidad necesaria
para trabajar con documentos de hojas de cálculo en Java de una manera sencilla, tanto
en sistemas Windows como GNU/Linux.
OpenSheet API hace uso de OpenOffice.org Calc por lo que necesita que esté instalado en
la máquina donde se va a usar, es necesario que la versión de la suite ofimática OpenOffice.org
sea 3.0 o superior. Al usar OpenOffice.org Calc se garantiza una gran compatibilidad
entre los formatos soportados, un amplio soporte y madurez.

B. MANUAL DE DESARROLLO 135
OpenSheet API es compatible con los formatos xls, xlt, xlsx, ods y odt. Y permite realizar
las siguientes operaciones:
Crear nuevos documentos con cualquiera de los formatos soportados.
Abrir documentos ya existentes de los formatos soportados.
Insertar datos numéricos o de texto a celdas o rango de celdas.
Extraer datos numéricos y de texto de celdas y rangos.
Crear nuevas hojas de cálculo en un documento.
Eliminar hojas de cálculo de un documento.
Realizar conversiones entre documentos de diferente formato.
Exportar un documento a PDF.
B.2.1. Ejemplos de uso
A continuación se muestran diferentes fragmentos de código donde se muestra como llevar
a cabo las operaciones comentadas más arriba, con la intención de mostrar al desarrollador
la facilidad de uso de OpenSheet API.
OpenSheetManager oSheetManager = new OpenSheetManager();
IOpenSheetDocument oDoc = oSheetManager.createDocument("balance.xls");
Listado B.1: Crear un nuevo documento con OpenSheet API
El listado B.1 se realiza la operación de creación de un nuevo documento, simplemente hay
que crear el OpenSheetManager que se encarga de localizar la instalación de OpenOffice.org,
arrancar el proceso y conectarse a él de manera totalmente transparente y automática; y
después solicitarle al objeto creado que cree un documento con la ruta y el nombre que se
desee. La interfaz IOpenSheetDocument es la que nos permite trabajar con los documentos
de hojas de cálculo.
OpenSheetManager oSheetManager = new OpenSheetManager();
IOpenSheetDocument oDoc = oSheetManager.openDocument("balance.xls");
Listado B.2: Abrir un documento con OpenSheet API
El listado B.2 se muestra como abrir un documento de hojas de cálculo ya existente, donde
al igual que en el ejemplo anterior basta con crear el objeto OpenSheetManager y usar el método
openDocument con la ruta y el fichero que se quiere abrir, de manera que nos devuelve
la interfaz IOpenSheetDocument para trabajar con él.

136 B. MANUAL DE DESARROLLO
OpenSheetManager oSheetManager = new OpenSheetManager();
IOpenSheetDocument oDoc = oSheetManager.openDocument("balance.xls");
ISpreadSheet sheet1 = oSheetDoc.getSpreadSheet(0);
ISpreadSheet sheetJunio = oSheetDoc.getSpreadSheet("Junio");
sheet1.setCellValue(new CellPosition(0,0), "Revisado");
sheet1.setCellValue(new CellPosition("a2"), "Proyecto A-T");
sheet1.setCellValue(new CellPosition(2,1), 1500.0);
sheetJunio.setCellValue(new CellPosition("a2"), 23.45);
Listado B.3: Insertar datos a celdas con OpenSheet API
El listado B.3 se muestra como insertar datos en celdas de las hojas de cálculo de un documento,
para ello se realiza la apertura de un documento balance.xls y se obtienen las interfaces
ISpreadSheet con la llamada a getSpreadSheet para trabajar con dos hojas de cálculo, la
hoja de la primera posición y otra con el nombre Junio. En las hojas se insertan los datos de
texto o numéricos usando el método setCellValue con el objeto que representa la posición de
la celda. Este objeto CellPosition puede ser creado mediante las posiciones X e Y o mediante
el nombre de columna y fila.
OpenSheetManager oSheetManager = new OpenSheetManager();
IOpenSheetDocument oDoc = oSheetManager.openDocument("balance.xls");
ISpreadSheet sheet1 = oSheetDoc.getSpreadSheet(0);
ISpreadSheet sheetJunio = oSheetDoc.getSpreadSheet("Junio");
sheet1.setRangeValue(new CellPosition(0,0), new CellPosition(0,7), "
Revisado");
sheet1.setRangeValue(new CellPosition("c1"), new CellPosition("d6"), "OK"
);
sheet1.setRangeValue(new CellPosition(1,0), new CellPosition(1,7),
1500.0);
sheetJunio.setCellValue(new CellPosition("aa2"),new CellPosition("aa6"),
23.45);
Listado B.4: Insertar datos a rangos con OpenSheet API
El listado B.4 se muestra como insertar datos en rangos de celdas en las hojas de cálculo
de un documento, para ello se realiza la apertura de un documento balance.xls y se obtienen
las interfaces ISpreadSheet con la llamada a getSpreadSheet para trabajar con dos hojas de
cálculo, la hoja de la primera posición y otra con el nombre Junio. En las hojas se insertan los
datos de texto o numéricos usando el método setRangeValue con los objetos que representan
las posición de las celdas que definen el rango, la superior izquierda y la inferior derecha.
Este objeto CellPosition puede ser creado mediante las posiciones X e Y o mediante el
nombre de columna y fila. La operación setRangeValue inserta el mismo valor a todas las
celdas del rango.

B. MANUAL DE DESARROLLO 137
OpenSheetManager oSheetManager = new OpenSheetManager();
IOpenSheetDocument oDoc = oSheetManager.openDocument("balance.xls");
ISpreadSheet sheet = oSheetDoc.getSpreadSheet("Nominas");
double salario = sheet.getCellValue(new CellPosition("d34"));
String empleado = sheet.getCellText(new CellPosition("c34"));
Object celdaAA1 = sheet.getCellContent(new CellPosition("aa1"));
Listado B.5: Extraer datos de celdas con OpenSheet API
El listado B.5 se muestra como extraer datos de celdas de una hoja de cálculo de un documento,
para ello se realiza la apertura de un documento balance.xls y se obtiene la interfaz
ISpreadSheet con la llamada a getSpreadSheet para trabajar con la hoja de cálculo con el
nombre Nominas. De la hoja se extraen valores de diferentes celdas, usando diferentes métodos:
getCellValue para obtener los valores numéricos, getCellText para extraer las cadenas
de texto y getCellContent que extrae lo que contenga la celda sea un valor numérico o texto
y lo devuelve como un Object.
OpenSheetManager oSheetManager = new OpenSheetManager();
IOpenSheetDocument oDoc = oSheetManager.openDocument("balance.xls");
ISpreadSheet sheet = oSheetDoc.getSpreadSheet("Nominas");
List salarios = sheet.getRangeValues(new CellPosition("d34"), new
CellPosition("d289"));
List empleados = sheet.getRangeTexts(new CellPosition("c34"), new
CellPosition("c289"));
List celdasAA1_AB23 = sheet.getRangeContent(new CellPosition("aa1
"),new
CellPosition("ab23"));
Listado B.6: Extraer datos de rangos de celdas con OpenSheet API
El listado B.6 se muestra como extraer datos de rangos de celdas de una hoja de cálculo
de un documento, para ello se realiza la apertura de un documento balance.xls y se obtiene
la interfaz ISpreadSheet con la llamada a getSpreadSheet para trabajar con la hoja de cálculo
con el nombre Nominas. De la hoja se extraen diferentes listas de valores de los diferentes
rangos de celdas, usando distintos métodos: getRangeValues para obtener la lista con los
valores numéricos, getRangeTexts para extraer una lista con las cadenas de texto de las celdas
y getRangeContent que extrae lo que contenga cada una de las celdas del rango sea un valor
numérico o texto y lo devuelve como una lista de Object.
El listado B.7 se muestra como añadir nuevas hojas de cálculo a un documento, para
ello se realiza la apertura de un documento balance.xls y añaden hojas a través del método

138 B. MANUAL DE DESARROLLO
OpenSheetManager oSheetManager = new OpenSheetManager();
IOpenSheetDocument oDoc = oSheetManager.openDocument("balance.xls");
ISpreadSheet sheetNueva =
ISpreadSheet sheetCierre =
oSheetDoc.addSpreadSheet();
oSheetDoc.addSpreadSheet("Cierre");
Listado B.7: Añadir hojas de cálculo con OpenSheet API
addSpreadSheet. Si se llama al método sin nombre la crea con uno por defecto, y si se le
pasa un nombre crea una nueva hoja con dicho nombre.
OpenSheetManager oSheetManager = new OpenSheetManager();
IOpenSheetDocument oDoc = oSheetManager.openDocument("balance.xls");
oSheetDoc.deleteSpreadSheet(0);
oSheetDoc.deleteSpreadSheet("Balance 2009");
Listado B.8: Borrar hojas de cálculo con OpenSheet API
El listado B.8 se muestra como borrar hojas de cálculo de un documento, para ello se realiza
la apertura de un documento balance.xls y borran las hojas deseadas a través del método
deleteSpreadSheet, bien pasándole la posición de la hoja en el documento o el nombre de la
hoja.
OpenSheetManager oSheetManager = new OpenSheetManager();
IOpenSheetDocument oDoc = oSheetManager.openDocument("balance.xls");
oDoc.saveAs("balance.ods");
Listado B.9: Convertir un documento de un formato a otro con OpenSheet API
El listado B.9 se muestra como convertir un documento de un formato a otro, para ello
basta con salvar un documento de hojas de cálculo a través del método saveAs usando la
extensión deseada.
El listado B.10 se muestra como exportar un documento de un formato a PDF, para ello
basta con llamar al método exportToPDF con la ruta y el nombre del fichero que se desee y
con la extensión .pdf.
B.2.2. Clases y métodos principales
En este apartado se explican las clases y métodos principales que permiten al desarrollador
hacerse una idea de las herramientas de las que dispone, pero para entrar en más detalles se
debe consultar la documentación en Javadoc del proyecto OpenSheet que se distribuye con
la propia OpenSheet API o bien generarlo a partir del código disponible en el repositorio.

B. MANUAL DE DESARROLLO 139
OpenSheetManager oSheetManager = new OpenSheetManager();
IOpenSheetDocument oDoc = oSheetManager.openDocument("balance.xls");
oDoc.exportToPDF("balance.pdf");
Listado B.10: Exportar un documento a formato PDF con OpenSheet API
OpenSheet API tiene las siguientes clases principales:
OpenSheetManager: Es la clase factoría que permite crear objetos con la interfaz
IOpenSheetDocument, es decir, los objetos que representan los documentos de hojas
de cálculo. Cuando se crea un objeto de esta clase, se realiza una búsqueda de la
instalación de OpenOffice.org en la máquina para arrancar el servicio y conectarse
a él, todo de manera automática y transparente, haciendo uso de la clase modificada
Bootstrap del SDK de UNO. Esta clase tiene los siguientes métodos:
• createDocument(String documentPath): Crea un documento con el nombre en la
ruta indicada, y devuelve la interfaz IOpenSheetDocument para trabajar con él.
• openDocument(String documentPath): Abre un documento en el path indicado,
y devuelve la interfaz IOpenSheetDocument para trabajar con él.
• terminate(): Es la operación que permite liberar los recursos de OpenOffice.org.
Al dejar de trabajar con los objetos de OpenSheet API se debe llamar siempre
a este método, por lo tanto se debe guardar la instancia de OpenSheetManager
hasta que se llame a este método.
IOpenSheetDocument: Es la interfaz que permite trabajar con un documento de hojas
de cálculo. Las operaciones que permite son:
• getSpreadSheetsNames(): Devuelve un array con los nombres de todas las hojas
de cálculo del documento.
• getSpreadSheet: Mediante la sobrecarga de métodos permite recuperar el objeto
ISpreadSheet, que representa una hoja de cálculo, bien indicando su posición en
el documento o indicando su nombre.
• addSpreadSheet: Mediante la sobrecarga de métodos permite añadir una nueva
hoja de cálculo con un nombre por defecto o dándole un nombre específico.
• deleteSpreadSheet: Mediante la sobrecarga de métodos permite eliminar una hoja
de cálculo a través de su posición o de su nombre.
• save(): Este método permite salvar los cambios realizados en un documento.
• saveAs(String documentPath): Permite tanto salvar el documento actual con otro
nombre, como realizar una conversión de formato si se usa otra extensión.

140 B. MANUAL DE DESARROLLO
• exportToPDF(String documenPath): Permite exportar un documento al formato
PDF.
• containsSpreadSheet(String name): Permite comprobar si el documento contiene
una hoja de cálculo con el nombre indicado por parámetro.
• close(): Cierra el documento y el fichero asociado. Este método debe llamarse
siempre después de trabajar con un documento.
ISpreadSheet: Es la interfaz que permite trabajar con un hoja de cálculo de un documento
y sus celdas. Las operaciones que permite son:
• setCellValue: A través de la sobrecarga de métodos permite insertar un valor
numérico o un texto a una celda representada por el objeto CellPosition.
• setRangeValue: A través de la sobrecarga de métodos permite insertar un valor
numérico o un texto a un rango de celdas representado por dos objetos CellPosition,
el primero que indica la celda de la esquina superior izquierda, y el segundo
que indica la celda de la esquina inferior derecha.
• getCellValue(CellPosition position): Permite recuperar un double de una celda
representada por el objeto CellPosition.
• getCellText(CellPosition position): Permite recuperar un String de una celda representada
por el objeto CellPosition.
• getRangeValues(CellPosition firstCellPosition, CellPosition lastCellPosition): Permite
recuperar una lista de double de un rango de celdas representado por dos objetos
CellPosition, el primero que indica la celda de la esquina superior izquierda,
y el segundo que indica la celda de la esquina inferior derecha.
• getRangeTexts(CellPosition firstCellPosition, CellPosition lastCellPosition): Permite
recuperar una lista de String de un rango de celdas representado por dos objetos
CellPosition, el primero que indica la celda de la esquina superior izquierda,
y el segundo que indica la celda de la esquina inferior derecha.
• getCellContent(CellPosition position): Permite recuperar un Object que contiene
el valor de una celda, representada por el objeto CellPosition, sea numérico o
texto.
• getRangeContent(CellPosition firstCellPosition, CellPosition lastCellPosition): Permite
recuperar una lista de Object que contiene los valores de las celdas de un
rango representado por dos objetos CellPosition, el primero que indica la celda
de la esquina superior izquierda, y el segundo que indica la celda de la esquina
inferior derecha, independientemente de que el contenido sea numérico o texto.
• getName(): Devuelve el nombre de la hoja de cálculo.

B. MANUAL DE DESARROLLO 141
• rename(String spreadSheetNewName): Permite cambiar el nombre de la hoja de
cálculo.
B.3.
OpenSheet Command
OpenSheet Command es una herramienta escrita en Java que permite operar con documentos
de hojas de cálculo de manera automática a partir de los datos contenidos en un
fichero .properties pasado en la ejecución y de un script, escrito en Groovy, de acciones seleccionado.
Esta herramienta esta diseñada para ser ejecutada desde un terminal o consola
del sistema, y hace uso de OpenSheet API y OpenOffice.org Calc.
La configuración y uso del comando se puede consultar en el manual de usuario. En este
manual se explicará como ampliar su funcionalidad a través de scripts escritos en Groovy.
B.3.1. Clases y métodos principales
Las clases que componen el comando no son necesarias explicarlas para poder ampliar su
funcionalidad, puesto que basta con entender como funciona la inyección de dependencias y
crear un script en Groovy. Si se desea conocer como funciona el comando para realizar mejoras
o modificaciones se debe consultar la documentación en Javadoc del proyecto OpenSheet
que se distribuye con la propia OpenSheet API o bien generarlo a partir del código disponible
en el repositorio.
B.3.2. Creación de nuevos scripts
La principal característica de OpenSheet Command es la posibilidad de ampliar su funcionalidad
a través de scripts a los que se les inyecta las cadenas leídas de un fichero de datos u
objetos si se han usado valores especiales.
El script debe identificar a que variables se les va a inyectar valores del fichero de datos,
y si esperan cadenas o alguno de los objetos que se pueden inyectar al usar los valores
reservados.
Todo valor reservado tiene la sintaxis @palabra_reservada; seguido de los valores necesarios
según la variable especial a utilizar. Existen los siguientes valores reservados:
@OpenSheetManager;: Permite inyectar el objeto OpenSheetManager para poder
crear y abrir documentos de hojas de cálculo desde el script.
@OpenSheetDocument;create,ruta_fichero: Crea un nuevo documento de hojas de
cálculo en la ruta indicada, representado por un objeto IOpenSheetDocument que será
inyectado a la variable del script indicada.
@OpenSheetDocument;open,ruta_fichero: Abre un documento de hojas de cálculo

142 B. MANUAL DE DESARROLLO
que se encuentra en la ruta indicada, representado por un objeto IOpenSheetDocument
que será inyectado a la variable del script indicada.
@list;valor1,valor2: Permite crear un objeto List, concretamente una lista de cadenas,
donde cada valor va separado por una coma.
@number;numero: Permite crear objetos de tipo Double.
Utilizando esos valores y luego mediante el análisis de las cadenas pasadas se puede conseguir
recibir los elementos necesarios para realizar cualquier acción de manera que pueda
cambiar según el fichero de datos utilizado.
Es necesario que las variables a las que se les vaya a inyectar un valor estén definidas y
sean usadas pero sin realizar ninguna asignación, porque la asignación sobreescribe el valor
inyectado.
Se recomienda analizar el script que se distribuye por defecto con el comando, OpenSheetScript.groovy
y leerse el manual de usuario para entender como funciona y así tener un
ejemplo de uso de scripts.
Limitación de uso de scripts
Existe la limitación de que actualmente OpenSheet Command no permite ejecutar scripts
de Groovy con dependencias a otros ficheros.
B.4.
OpenSheet Web Service
OpenSheet Web Service es un servicio web escrito en Java usando JAX-WS que permite
operar con documentos de hojas de cálculo a partir de la selección de un script de Groovy y
una lista de variables o pares clave/valor. Este servicio hace uso de OpenSheet API y OpenOffice.org
Calc.
OpenSheet Web Service proporciona dos operaciones:
Operación listScripts: Esta operación devuelve una lista de objetos ScriptInfo con la
información necesaria para utilizar cada uno de los scripts disponibles.
Operación executeScript: Esta operación permite ejecutar un script pasándole una
lista de variables y un objeto Document que puede ser vacío; y una vez ejecutado el
script se devolverán los objetos Document que indiquen las variables de salida configuradas
en la información del script.
OpenSheet Web Service por tanto permite ejecutar scripts de Groovy de manera remota
para operar con documentos de hojas de cálculo, al igual que se hace con el comando pero en
este caso hay teniendo en cuenta la problemática de la invocación desde fuera del sistema:

B. MANUAL DE DESARROLLO 143
1. Los scripts que se pueden ejecutar son aquellos que se encuentran en el directorio
configurado y que además tienen un fichero .properties con su mismo nombre, que
contiene las variables con la información necesaria para generar objetos ScriptInfo
necesarios para la operación listScripts, y las variables que necesita el servicio web.
Al impedir que se puedan ejecutar scripts enviados por el usuario y limitarlos a un
directorio donde se además se añada un fichero con la información de uso, se evitan
problemas de seguridad.
2. Ahora existe el problema de que el mismo script puede ser invocado a la vez y que
los documentos que envía el cliente del servicio web deben almacenarse sin sobreescribir
otros y además que se puedan identificar desde la lista de variables enviada, que
sustituye al fichero de datos. Para ello el servicio web en el directorio temporal, crea
un nuevo directorio para cada llamada a la operación de ejecución donde se almacena
el documento enviado, y que se le asigna al script para que lo use cuando tenga que
guardar ficheros.
3. Antes de enviar las variables para ejecutar el script, el servicio web debe parsear los
valores de la variables especiales @OpenSheetDocument; tanto create como open
para que el nombre del documento incluya el directorio temporal creado por el servicio
web.
4. Se deben identificar todos los ficheros de salida que el servicio web debe enviar al
cliente, y no borrar dichos ficheros. Estos deben almacenarse en el directorio temporal
haciendo uso de la valor que el servicio web inyectará a la variable configurada para
ello, de esta forma una vez leídos los ficheros de salida, el servicio web puede borrar
todo el contenido del directorio temporal.
B.4.1. Clases y métodos principales
Las clases que componen el servicio web no son necesarias explicarlas para poder ampliar
su funcionalidad, puesto que basta con entender como funciona la inyección de dependencias
y crear un script en Groovy. Si se desea conocer como funciona el servicio web para
realizar mejoras o modificaciones se debe consultar la documentación en Javadoc del proyecto
OpenSheet que se distribuye con la propia OpenSheet API o bien generarlo a partir del
código disponible en el repositorio.
B.4.2. Creación de nuevos scripts
La principal característica de OpenSheet Web Service es que permite la posibilidad de
ampliar su funcionalidad a través de scripts, al igual que OpenSheet Command, a los que se
les inyecta las cadenas leídas de una lista de variables enviadas como parámetros u objetos
si se han usado valores especiales.

144 B. MANUAL DE DESARROLLO
El script debe identificar a que variables se les va a inyectar valores del fichero de datos,
y si esperan cadenas o alguno de los objetos que se pueden inyectar al usar los valores
reservados.
Todo valor reservado tiene la sintaxis @palabra_reservada; seguido de los valores necesarios
según la variable especial a utilizar, estos son los mismos que los usados en OpenSheet
Commnad.
Para los scripts creados para usar desde el servicio web hay que tener en cuenta que es
necesario tener una variable donde se inyecte la ruta del directorio temporal creado para
cada ejecución, y que será donde se deben almacenar los ficheros que se generen. Además,
las variables que se ha configurado en la variable outputVariables del fichero .properties
deben contener la ruta a los ficheros que el servicio web debe devolver al cliente que invocó
la operación, y estos ficheros no deben ser borrados, si no que serán eliminados junto con el
directorio temporal por el servicio web.
Se recomienda analizar el script que se distribuye por defecto con el comando, OpenSheetScript.groovy
y leerse el manual de usuario para entender como funciona y como se
debe configurar para usarse desde el servicio web.
A continuación se explican los pasos de una ejecución de un script para que se comprenda
mejor el proceso.
B.4.3. Pasos de la operación executeScript
El servicio web cuando tiene recibe una petición a la operación executeScript para ejecutar
un script realiza los siguientes pasos:
1. Se Genera el directorio temporal único para esa llamada.
2. Si se envía un documento con datos, este se guarda en el directorio temporal creado.
3. Se preprocesan las variables de la lista enviada, añadiendo al nombre del documento
asignado a las directivas @OpenSheetDocument;create y @OpenSheetDocument;open
la ruta del directorio temporal creado.
4. Se crea la instancia de ScriptExecuter, que es el mismo objeto que ejecuta scripts en el
comando, con los valores preprocesados del paso anterior.
5. Se inyecta el valor del directorio temporal a la variable temporalDirectoryVariable
configurada en el fichero .properties del script.
6. Se ejecuta el script.
7. Se leen todos los ficheros a los que apuntan las variables configuradas en el fichero
.properties del script a través de la variable outputVariables.

B. MANUAL DE DESARROLLO 145
8. Se borra el directorio temporal.
9. Se envía la respuesta.
Con la ejecución de estos pasos se entiende mejor la necesidad de configurar en el fichero
de .properties del script las variables temporalDirectoryVariable y outputVariables.
B.4.4. Cliente de ejemplo
En este apartado se muestra un ejemplo muy básico de un cliente del servicio web que
hace uso del script OpenSheetScript.groovy usando siempre el mismo valor de las variables
al estar escritas directamente en el código.
Para poder configurar OpenSheetScript.groovy para poder ser usado como script del servicio
web es necesario añadir un fichero .properties junto a él dentro del directorio de scripts
configurado en el web.xml. El fichero .properties debe contener la información del listado
B.11.
description=OpenSheetScript es el script por defecto que permite realizar
las
operaciones basicas de la API. Para saber como se debe usar consultar el
manual
de usuario.
outputVariables=saveDocumentTo;extractCellsValuesFile
temporalDirectoryVariable=tempDir
Listado B.11: Ejemplo de fichero Properties para script de servicio web
Al usar el saveDocumentTo como variable de salida, si se quiere recuperar ese documento
tras la ejecución se le debe asignar un valor en la lista de variables en cada llamada.
A continuación, se muestra un ejemplo de cliente del servicio web generado automáticamente
a partir del WSDL del servicio usando un plugin que trae Netbeans para trabajar
con aplicaciones web. Concretamente se muestran los métodos añadidos al código generado
automáticamente.
En el listado B.12 se puede en el método main que primero se llama a la operación listScripts()
del servicio web, imprimiendo por pantalla la información recibida. A continuación,
se construye un mapa de propiedades que se transformará posteriormente en una lista de
ScriptVariable; en esas propiedades se meten los valores para realizar las siguientes operaciones:
1. Crear un nuevo documento llamado salida.ods
2. Añadir al documento tres hojas de cálculo One_Sheet, tab1 y spread.1

146 B. MANUAL DE DESARROLLO
3. Insertar valores diferentes celdas de las hojas de cálculo del documento, referenciándolas
tanto por nombre como por posición.
4. Extraer los valores insertados a un fichero.
Después de crear las propiedades se llama a la operación executeScript del servicio web,
pasándole un documento vacío, puesto que se va a crear en el servidor, la lista de variables
comentada antes y el nombre del primer script encontrado al listarlos, en este caso al configurar
sólo uno sería el OpenSheetScript.groovy. Con los documentos recibidos se ejecuta
una operación que permite salvarlos a disco. En el listado B.13 se pueden ver los métodos auxiliares
empleados para pasar las propiedades a lista de variables que necesita la operación,
y para almacenar los objetos Document como ficheros.

B. MANUAL DE DESARROLLO 147
public class Main {
public static void main(String[] args) throws Exception
{
OpenSheetWebServiceService service = new
OpenSheetWebServiceService();
OpenSheetWebService port = service.getOpenSheetWebServicePort();
List listScripts = port.listScripts();
for (ScriptInfo sInfo : listScripts)
{
System.out.println("name:"+sInfo.getName());
System.out.println("descr:"+sInfo.getDescription());
System.out.println("output size:"+sInfo.getOutputVariables().
size());
if (sInfo.getOutputVariables().size() > 0)
System.out.println("output 0:"+sInfo.getOutputVariables()
.get(0));
}
HashMap propertiesData = new HashMap();
propertiesData.put("openSheetDocument", "@OpenSheetDocument;
create,salida.ods");
propertiesData.put("logFileName", "");
propertiesData.put("deleteSheets", "");
propertiesData.put("deleteSheetsByPosition", "");
propertiesData.put("addSheets", "One_Sheet;tab1;spread.1");
propertiesData.put("insertCellsValues", "tab1:c6=hola mundo!,d5=
hello world!;spread.1:aa1=Welcome,a2=11/04/2011");
propertiesData.put("insertCellsValuesBySheetPosition", "0:a1=
sheet with position 0;1:a2= Bienvenido,c7=OpenSheet;2:cc1=Nat"
);
propertiesData.put("insertCellsNumericValues", "tab1:a11=2.45;
One_Sheet:b2=10.0,c1=345.678");
propertiesData.put("insertCellsNumericValuesBySheetPosition", "0:
a11=11.12;3:b22=23.0,c2=987.6543");
propertiesData.put("extractCellsValues", "tab1:c6,d5,a11;spread
.1:aa1,a2;One_Sheet:b2,c1");
propertiesData.put("extractCellsValuesBySheetPosition", "0:a1,a11
;1:a2,c7;2:cc1;3:b22,c2");
propertiesData.put("extractCellsValuesFile", "");
propertiesData.put("saveDocumentTo", "salida1.ods");
}
}
List documents = port.executeScript(new Document(),
getScriptVariables(propertiesData), listScripts.get(0).getName
());
saveDocuments(documents);
Listado B.12: Ejemplo de cliente de OpenSheet Web Service - Parte 1

148 B. MANUAL DE DESARROLLO
public static List getScriptVariables(Map variablesMap)
{
List list = new ArrayList();
}
for (String key : variablesMap.keySet())
{
ScriptVariable var = new ScriptVariable();
var.setName(key);
var.setValue(variablesMap.get(key));
list.add(var);
}
return list;
private static void saveDocuments(List documents) throws
IOException
{
for (Document doc : documents)
{
System.out.println("\nSave document ’"+doc.getName()+"’");
saveDocument(doc);
}
}
public static void saveDocument(Document document) throws IOException
{
FileOutputStream fos = null;
try
{
File documentFile = new File(document.getName());
fos = new FileOutputStream(documentFile);
fos.write(document.getContent());
}
finally
{
fos.close();
}
}
Listado B.13: Ejemplo de cliente de OpenSheet Web Service - Parte 2

Anexo C
GNU Free Documentation License
Version 1.3, 3 November 2008
Copyright c○ 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful document “free” in the sense of freedom: to
assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially.
Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible
for modifications made by others.
This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It
complements the GNU General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a
free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software
manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this
License principally for works whose purpose is instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be
distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work
under the conditions stated herein. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee,
and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright
law.
A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.
A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of
the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall
directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any
mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial,
philosophical, ethical or political position regarding them.
The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice
that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed
to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections
then there are none.
The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says
that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25
words.
A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the
general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels)
generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for
149

150 C. GNU FREE DOCUMENTATION LICENSE
automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format
whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent.
An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”.
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format,
SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification.
Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read
and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available,
and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.
The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material
this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text
near the most prominent appearance of the work’s title, preceding the beginning of the body of the text.
The “publisher” means any person or entity that distributes copies of the Document to the public.
A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses
following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements”,
“Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Document
means that it remains a section “Entitled XYZ” according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These
Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other
implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other
conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of
the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number
of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and
the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover
Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify
you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible.
You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the
Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on
the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable
Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general
network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free
of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in
quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you
distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to
give them a chance to provide you with an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you
release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing
distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the

C. GNU FREE DOCUMENTATION LICENSE 151
Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions
(which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous
version if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified
Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five),
unless they release you from this requirement.
C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version
under the terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s license
notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled “History”, Preserve its Title, and add to it an item stating at least the title, year, new authors, and
publisher of the Modified Version as given on the Title Page. If there is no section Entitled “History” in the Document, create one
stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified
Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and
likewise the network locations given in the Document for previous versions it was based on. These may be placed in the “History”
section. You may omit a network location for a work that was published at least four years before the Document itself, or if the
original publisher of the version it refers to gives permission.
K. For any section Entitled “Acknowledgements” or “Dedications”, Preserve the Title of the section, and preserve in the section
all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent
are not considered part of the section titles.
M. Delete any section Entitled “Endorsements”. Such a section may not be included in the Modified Version.
N. Do not retitle any existing section to be Entitled “Endorsements” or to conflict in title with any Invariant Section.
O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material
copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the
list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.
You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various
parties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a
standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end
of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by
(or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by
you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on
explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert
or imply endorsement of any Modified Version. 5. COMBINING DOCUMENTS

152 C. GNU FREE DOCUMENTATION LICENSE
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for
modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified,
and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single
copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make
the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled
“History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete all
sections Entitled “Endorsements”.
5. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace the individual
copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of
this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy
of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
6. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a
storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights
of the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does
not apply to the other works in the aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half
of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the
electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole
aggregate.
7. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4.
Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations
of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this
License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English
version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the
original version of this License or a notice or disclaimer, the original version will prevail.
If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve its
Title (section 1) will typically require changing the actual title.
8. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense, or distribute it is void, and will automatically terminate your rights under this License.
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally,
unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to
notify you of the violation by some reasonable means prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation
by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright
holder, and you cure the violation prior to 30 days after your receipt of the notice.
Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you
under this License. If your rights have been terminated and not permanently reinstated, receipt of a copy of some or all of the same material

C. GNU FREE DOCUMENTATION LICENSE 153
does not give you any rights to use it.
9. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time.
Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See
http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of
this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version
or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version
number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. If the Document
specifies that a proxy can decide which future versions of this License can be used, that proxy’s public statement of acceptance of a version
permanently authorizes you to choose that version for the Document.
10. RELICENSING
“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any World Wide Web server that publishes copyrightable works and
also provides prominent facilities for anybody to edit those works. A public wiki that anybody can edit is an example of such a server. A
“Massive Multiauthor Collaboration” (or “MMC”) contained in the site means any set of copyrightable works thus published on the MMC
site.
“CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0 license published by Creative Commons Corporation, a notfor-profit
corporation with a principal place of business in San Francisco, California, as well as future copyleft versions of that license
published by that same organization.
“Incorporate” means to publish or republish a Document, in whole or in part, as part of another Document.
An MMC is “eligible for relicensing” if it is licensed under this License, and if all works that were first published under this License
somewhere other than this MMC, and subsequently incorporated in whole or in part into the MMC, (1) had no cover texts or invariant
sections, and (2) were thus incorporated prior to November 1, 2008.
The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before
August 1, 2009, provided the MMC is eligible for relicensing.

Bibliografía
[Arg93]
D. Arganbright. Practical Handbook of Spreadsheet Curves and Geometric Constructions.
CRC Press, 1993.
[BBvB + 01] K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler,
J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. C. Martin, S. Mellor,
K. Schwaber, J. Sutherland, y D. Thomas. Manifesto for Agile Software Development.
2001. Disponible en: http://agilemanifesto.org/.
[BFJLP06] K. R. Baker, L. Foster-Johnson, B. Lawson, y S. G. Powell. A Survey of
MBA Spreadsheet Users. Spreadsheet Engineering Research Project, 2006. Disponible
en: http://mba.tuck.dartmouth.edu/spreadsheet/product_
pubs_files/SurveyPaper.doc.
[BFJLP07] K. R. Baker, L. Foster-Johnson, B. Lawson, y S. G. Powell. Spreadsheet Risk,
Awareness, and Control. Spreadsheet Engineering Research Project, 2007. Disponible
en: http://mba.tuck.dartmouth.edu/spreadsheet/product_
pubs_files/SSrisk.doc.
[Bra]
H.Merijn Brand. Spreadsheet::Read. Disponible en: http://search.cpan.org/
~hmbrand/Spreadsheet-Read-0.41/Read.pm.
[Byt] ByteScout. Spreadsheet SDK. Disponible en: http://www.bytescout.com/
products/developer/spreadsheetsdk/bytescoutspreadsheetsdk.
html.
[Car10] Carlos Blé. Diseño Ágil con TDD. jan 2010. Disponible en: http://www.
dirigidoportests.com/el-libro.
[com]
GlassFish community. JAX-WS. Disponible en: http://jax-ws.java.net/.
[Cor84] Lotus Development Corporation. Worksheet File Format From LOTUS. Diciembre
1984. Disponible en: http://www.schnarff.com/file-formats/index.
html.
[CPA]
[CTC06]
CPAN. CPAN. Disponible en: http://search.cpan.org/.
P.E. Craig T. Christy. Engineering with the Spreadsheet: Structural Engieering Templates
Using Excel. ASCE, 2006.
155

156 BIBLIOGRAFÍA
[dIU07] Escuela Superior de Informática (UCLM). Normativa del Proyecto Fin de Carrera.
2007. Disponible en: http://www.esi.uclm.es:8081/www/documentos/
Normativas/NormativaPFC2007.pdf.
[Fab]
[Foua]
S. Faber. Mockito. Disponible en: http://mockito.org/.
The Apache Software Foundation. The Apache POI Project. Disponible en: http:
//poi.apache.org/.
[Foub] The Apache Software Foundation. Apache Subversion. Disponible en: http://
subversion.apache.org/.
[Fouc]
The Apache Software Foundation. Apache Tomcat. Disponible en: http://tomcat.
apache.org/.
[Foud] The Apache Software Foundation. POI-HSSF and POI-XSSF - Java API To Access
Microsoft Excel Format Files. Disponible en: http://poi.apache.org/
spreadsheet/index.html.
[Foue]
[Fre92]
[Gou]
[Gro]
[ink]
The Eclipse Foundation. Eclipse. Disponible en: http://www.eclipse.org/.
H. Freiser. Concepts & Calculations in Analytical Chemistry: A Spreadsheet Approach.
CRC Press, 1992.
J.M. Gouarne. OpenOffice::OODoc. Disponible en: http://search.cpan.org/
~jmgdoc/OpenOffice-OODoc-2.125/OODoc/Intro.pod.
European Spreadsheet Risks Interest Group. Spreadsheet Horror Stories. Disponible
en: www.eusprig.org/stories.htm.
Inkscape. Disponible en: http://inkscape.org/.
[Jay] Jayway. PowerMock. Disponible en: http://code.google.com/p/
powermock/.
[KB]
E. Gamma K. Beck. JUnit. Disponible en: http://www.junit.org/.
[Kni07] H. Kniberg. Scrum y XP desde las Trincheras. Cómo hacemos Scrum. C4Media, 2007.
[LBPFJ07] B. Lawson, K. R. Baker, S. G. Powell, y L. Foster-Johnson. A comparison
of spreadsheet users with different levels of experience. Omega, 2007. Disponible
en: http://mba.tuck.dartmouth.edu/spreadsheet/product_
pubs_files/Comparison.pdf.
[McN] J. McNamara. Spreadsheet::WriteExcel. Disponible en: http://search.
cpan.org/~jmcnamara/Spreadsheet-WriteExcel-2.37/lib/
Spreadsheet/WriteExcel.pm.
[Mic07] Microsoft. How to automate Excel from C++ without using MFC or #import. may 2007.
Disponible en: http://support.microsoft.com/kb/216686/en-us.

BIBLIOGRAFÍA 157
[Mic08a] Microsoft. Microsoft Office Excel 2007 Binary File Format Specification [*.xlsb].
Junio 2008. Disponible en: http://www.microsoft.com/interop/docs/
officebinaryformats.mspx.
[Mic08b] Microsoft. Microsoft Office Excel 97-2007 Binary File Format Specification [*.xls
(97-2007) format]. Junio 2008. Disponible en: http://www.microsoft.com/
interop/docs/officebinaryformats.mspx.
[Mic08c]
[Mic10a]
Microsoft. Office Automation Using Visual C++. mar 2008. Disponible en: http:
//support.microsoft.com/kb/196776/EN-US/.
Microsoft. MS-OODF2: Office Implementation Information for ODF 1.1 Version 2 Standard
Compliance. Junio 2010. Disponible en: http://msdn.microsoft.com/
en-us/library/ee908651(v=office.12).aspx.
[Mic10b] Microsoft. MS-XLSX: Excel Extensions to the Office Open XML SpreadsheetML
File Format (.xlsx) Specification. Junio 2010. Disponible en: http://msdn.
microsoft.com/en-us/library/dd922181(v=office.12).aspx.
[NR99] J. Batson N. Read. Spreadsheet Modelling Best Practice. Business Dynamics, apr 1999.
Disponible en: http://www.eusprig.org/smbp.pdf.
[oas]
[OAS07]
OASIS Consortium. Disponible en: http://www.oasis-open.org.
OASIS. Open Document Format for Office Applications (OpenDocument) Specification
v1.1. Febrero 2007. Disponible en: http://docs.oasis-open.org/office/
v1.1/OS/OpenDocument-v1.1.pdf.
[OAS10] OASIS. Open Document Format for Office Applications (OpenDocument)
Version 1.2 (Committee Draft 04-Rev 09). Junio 2010. Disponible en:
http://www.oasis-open.org/committees/download.php/38239/
OpenDocument-v1.2-part1-cd04-rev09.odt.
[OKvLV]
O. Ojala, K. Karlsson, B. von Loesch, y T. Arne Vestb. Texlipse. Disponible en: http:
//texlipse.sourceforge.net/.
[ooo] OpenOffice.org Draw. Disponible en: http://www.openoffice.org/
product/draw.html.
[ope]
[Oraa]
[Orab]
[Orac]
OpenOffice.org. Disponible en: http://www.openoffice.org.
Oracle. JDK Java Development Kit. Disponible en: http://www.oracle.com/
technetwork/java/javase/downloads/index.html.
Oracle. NetBeans IDE. Disponible en: http://netbeans.org/.
Oracle. OpenOffice.org Calc. Disponible en: http://www.openoffice.org/
product/calc.html.

158 BIBLIOGRAFÍA
[Orad]
Oracle. OpenOffice.org SDK. Disponible en: http://download.openoffice.
org/sdk/.
[Ora10] Oracle. OpenOffice.org Developer’s Guide. aug 2010. Disponible en:
http://wiki.services.openoffice.org/wiki/Documentation/
DevGuide/OpenOffice.org_Developers_Guide.
[Pal07]
[Pro]
J. Palacio. Flexibilidad con Scrum. safe creative, oct 2007. Disponible en: http:
//www.navegapolis.net/files/Flexibilidad_con_Scrum.pdf.
The LaTex3 Project. LaTex. Disponible en: http://www.latex-project.org/.
[RA08] M. Erwig R. Abraham. Test-Driven Goal-Directed Debugging in Spreadsheets.
2008. Disponible en: http://web.engr.oregonstate.edu/~erwig/
papers/TestDrivenDebugging_VLHCC08.pdf.
[RA09] M. Erwig R. Abraham, M. M. Burnett. Spreadsheet Programming. 2009.
Disponible en: http://web.engr.oregonstate.edu/~erwig/papers/
SpreadsheetProgramming_ECSE09.pdf.
[SL99]
S.E. Margolis S.J. Liebowitz. Winners, Losers, and Microsoft: How Technology Markets
Choose Products. Independent Institute, may 1999.
[Sof] GemBox Software. GemBox.Spreadsheet. Disponible en: http://www.
gemboxsoftware.com/GBSpreadsheet.htm.
[Spr] Groovy Community SpringSource. Groovy. Disponible en: http://groovy.
codehaus.org/.
[Tak] K. Takanori. Spreadsheet::ParseExcel. Disponible en: http://search.cpan.
org/~kwitknr/Spreadsheet-ParseExcel-0.2602/ParseExcel.pm.
[Tea]
[umb]
The Gimp Team. Gimp. Disponible en: http://www.gimp.org/.
Umbrello UML Modeller. Disponible en: http://uml.sourceforge.net/.
[Wal10] J. Walkenbach. Excel 2010 Power Programming with VBA. Wiley Publishing, 2010.