ESTADO DEL ARTE - LITE - Universidad Rey Juan Carlos

INGENIERÍA INFORMÁTICA
Curso Académico 2003/2004
Proyecto de Fin de Carrera
SerXML
Serialización en XML de objetos Java
Tutores: Víctor Fresno Fernández y
Soto Montalvo Herranz
Autor: David Arbona Navarro

This work is licensed under the Creative Commons Attribution-ShareAlike
License. To view a copy of this license, visit http://creativecommons.org/licenses/bysa/2.0/
or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford,
California 94305, USA.

A Vane, por estar siempre a mi lado.
A Víctor, por su apoyo y ayuda.
A Soto, por su dedicación.
A Mica, por aportarme sus conocimientos.
A toda mi familia por comprenderme y darme todo su apoyo.
Y a todos aquellos, que de una forma u otra
han ayudado y colaborado en este proyecto.

II
Índice general
ÍNDICE DE TABLAS....................................................................................................................V
ÍNDICE DE ILUSTRACIONES................................................................................................. VI
1. INTRODUCCIÓN...........................................................................................................................1
2. ESTADO DEL ARTE.....................................................................................................................6
2.1. HERRAMIENTAS DE SERIALIZACIÓN EN XML DE OBJETOS JAVA ......................................7
2.1.1. Criterios de evaluación de un serializador en XML de objetos Java.....................7
2.1.2. Estudio comparativo ..............................................................................................9
2.1.2.1. JSX 2.2.3.2 ..................................................................................................................... 12
2.1.2.2. Castor XML 0.9.5.3........................................................................................................ 14
2.1.2.3. XStream 1.0.2................................................................................................................. 16
2.1.2.4. JOX 1.17......................................................................................................................... 17
2.1.2.5. Koala KOML 1.21.......................................................................................................... 19
2.2. CONCLUSIONES ..............................................................................................................21
3. METODOLOGÍAS Y TECNOLOGÍAS.....................................................................................25
3.1. METODOLOGÍA ...............................................................................................................25
3.1.1. PUD .....................................................................................................................25
3.2. TECNOLOGÍAS SOFTWARE...............................................................................................28
3.2.1. Orientación a objetos ...........................................................................................28
3.2.2. Java ......................................................................................................................30
3.2.3. API JavaCET........................................................................................................31
3.2.4. XML......................................................................................................................33
3.2.5. SAX y DOM..........................................................................................................34
3.2.6. DTD y XML Schema.............................................................................................36
4. EJEMPLO DE USO......................................................................................................................38
5. ESPECIFICACIÓN DE REQUISITOS......................................................................................45
5.1. DESCRIPCIÓN GENERAL ..................................................................................................46
5.1.1. Perspectiva del producto......................................................................................46
5.1.2. Funciones del producto........................................................................................47
5.1.3. Características del usuario ..................................................................................47

III
5.2. REQUISITOS ESPECÍFICOS................................................................................................47
5.2.1. Interfaces..............................................................................................................47
5.2.1.1. Ventana de la aplicación................................................................................................. 48
5.2.1.2. Diálogos.......................................................................................................................... 49
5.2.2. Requisitos funcionales..........................................................................................52
5.2.2.1. Requisitos para generar el documento Java para la serialización/deserialización........... 53
5.2.2.2. Requisitos para generar el documento DTD ................................................................... 58
5.2.2.3. Requisitos para generar el documento XML Schema..................................................... 58
5.2.2.4. Requisitos para el manejo del documento de configuración........................................... 58
5.2.2.5. Requisitos relativos al manejo de la interfaz.................................................................. 60
5.2.3. Requisitos no funcionales.....................................................................................62
5.2.3.1. Fiabilidad........................................................................................................................ 62
5.2.3.2. Documentación............................................................................................................... 63
5.2.3.3. Portabilidad..................................................................................................................... 63
5.2.3.4. Prestación ....................................................................................................................... 63
5.2.3.5. Recursos ......................................................................................................................... 64
5.2.3.6. Seguridad........................................................................................................................ 64
5.3. DIAGRAMAS DE CASOS DE USO .......................................................................................64
5.3.1. Descripción textual del flujo principal y flujos alternativos ................................67
5.3.2. Formalización de la descripción de casos de uso ................................................68
6. ANÁLISIS......................................................................................................................................70
6.1. ANÁLISIS DE LOS CASOS DE USO .....................................................................................71
6.1.1. Caso de uso Abrir documento ..............................................................................71
6.1.2. Caso de uso Generar Java2XML .........................................................................72
6.2. DIAGRAMA DE PAQUETES ...............................................................................................73
7. DISEÑO .........................................................................................................................................74
7.1. DISEÑO DE LA INTERFAZ.................................................................................................75
7.1.1. Obtención de los parámetros de configuración ...................................................76
7.2. DISEÑO DE LA GENERACIÓN DE LOS DOCUMENTOS.........................................................78
7.3. DISEÑO DE LA SERIALIZACIÓN Y DESERIALIZACIÓN........................................................80
7.4. ARQUITECTURA DEL SISTEMA.........................................................................................82
7.5. DISTRIBUCIÓN EN PAQUETES ..........................................................................................83
8. IMPLEMENTACIÓN Y PRUEBAS...........................................................................................84
8.1. RELACIÓN DE APROXIMACIONES UTILIZADAS EN LA IMPLEMENTACIÓN .........................85
8.2. PRUEBAS ........................................................................................................................87
9. CONCLUSIONES Y TRABAJOS FUTUROS...........................................................................90
9.1. PRINCIPALES LOGROS ALCANZADOS...............................................................................90
9.2. TRABAJOS FUTUROS .......................................................................................................91
9.2.1. Integración de SerXML como plugin para los entornos de desarrollo ................92

IV
9.2.2. Utilización de toda la riqueza semántica ofrecida en el lenguaje J2SE 1.5.........92
9.2.3. Uso de SerXML en diversos programas reales ....................................................92
9.2.4. Utilizar la metaprogramación para realizar la serialización ..............................93
BIBLIOGRAFÍA ................................................................................................................................94
ANEXO A............................................................................................................................................96
UTILIZACIÓN DE LA APLICACIÓN.................................................................................................96
FICHERO DE CONFIGURACIÓN......................................................................................................98

V
Índice de tablas
Tabla 1 : Clase Person.java ............................................................................................ 10
Tabla 2 : Objeto Person a serializar................................................................................ 11
Tabla 3: Serialización obtenida con JSX........................................................................ 14
Tabla 4: Serialización obtenida con Castor XML .......................................................... 16
Tabla 5: Serialización obtenida con XStream ................................................................ 17
Tabla 6: Serialización obtenida con JOX ....................................................................... 19
Tabla 7: Serialización obtenida con Koala KOML ........................................................ 21
Tabla 8: Tabla Comparativa. .......................................................................................... 23
Tabla 9: Relación de páginas web con información acerca de las herramientas
analizadas........................................................................................................24
Tabla 10: Ejemplo de documento XML......................................................................... 34
Tabla 11: Ejemplo de XML Schema .............................................................................. 37
Tabla 12: Ejemplo de serialización de listas .................................................................. 55
Tabla 13: Ejemplo de serialización maps....................................................................... 55
Tabla 14: Caso de uso “Abrir documento”..................................................................... 67
Tabla 15: Caso de uso “Generar Java2XML” ................................................................ 68
Tabla 16: Métodos de la InterfazConfiguración............................................................. 77
Tabla 17: Ejemplo clase de prueba (Mesa.java)............................................................. 89

VI
Índice de ilustraciones
Figura 1: Proceso de generación de los documentos........................................................ 4
Figura 2: Referencia circular en el objeto Java .............................................................. 11
Figura 3: Flujos de trabajo.............................................................................................. 27
Figura 4: Proceso generación ProgramaJava.................................................................. 32
Figura 5: Abrir clase Java............................................................................................... 39
Figura 6: Insertar nombre de la clase Java ..................................................................... 40
Figura 7: Clase Java abierta............................................................................................ 40
Figura 8: Obtención del nombre del nodo raíz............................................................... 41
Figura 9: Generación de los archivos Java2XML.java................................................... 42
Figura 10: Generado DTD.............................................................................................. 42
Figura 11: Generado XML Schema................................................................................ 43
Figura 12: Guardando todos los documentos ................................................................. 43
Figura 13: Diagrama de casos de uso – Manejo de la interfaz gráfica........................... 65
Figura 14: Diagrama de casos de uso – Generación del documento para la
serialización/deserialización ...........................................................................66
Figura 15: Diagrama de casos de uso – Generación del documento DTD..................... 66
Figura 16: Diagrama de casos de uso – Generación del documento XML Schema ...... 66
Figura 17: Diagrama de Estado de la interfaz gráfica .................................................... 69
Figura 18: Diagrama de colaboración – Flujo principal (abrir documento)................... 71
Figura 19: Diagrama de colaboración – Flujo alternativo (abrir documento)................ 71
Figura 20: Diagrama de colaboración – Flujo principal (generar Java2XML) .............. 72
Figura 21: Diagrama de colaboración – Flujo alternativo I (generar Java2XML)......... 72
Figura 22: Diagrama de colaboración – Flujo alternativo II (generar Java2XML)........ 72
Figura 23: Diagrama de paquetes de análisis ................................................................. 73
Figura 24: Diagrama de clases – Interfaz ....................................................................... 76
Figura 25: Diagrama de clases – Generación de los documentos .................................. 79
Figura 26: Diagrama de clases – Serialización/deserialización...................................... 80
Figura 27: Arquitectura .................................................................................................. 82

Capítulo 1. INTRODUCCIÓN 1
1
Capítulo 1
INTRODUCCIÓN
Se entiende por Sistema de Gestión de Información al conjunto de recursos físicos
(hardware) y lógicos (software), que conjuntamente dan soporte informático a unos
datos y permiten el proceso o gestión de los mismos.
En estos sistemas la información se encuentra principalmente en dos estados: en
memoria y almacenada en disco. La información en memoria se procesa en el momento,
y se hace mediante las instrucciones del lenguaje de programación en el que está
desarrollado el sistema. La información se almacena en disco para su posterior uso,
para su transmisión o para que sea compartida entre varios sistemas.
A grandes rasgos dos son las formas posibles de almacenar la información en
disco: en un sistema de base de datos o en uno o varios ficheros. Las bases de datos se
usan cuando hay gran cantidad de información, con acceso concurrente de varios
usuarios y gran potencia de búsqueda. Por otro lado, el almacenamiento en ficheros se
usa cuando no se requiere el acceso concurrente a partes de la información y/o cuando
no se requiere una forma centralizada de gestionar la información, sino que cada fichero
ha de ser tratado individualmente.
Es habitual que la información que se procesa en memoria se almacene en disco
para ser compartida o para guardarla una vez finalizada la ejecución del sistema. Al
proceso de almacenamiento de la información de la memoria en un fichero se le
denomina serialización. Al proceso inverso, obtener la información de un fichero y
cargarla en memoria, se le denomina deserialización.
Un lenguaje que permite almacenar la información en ficheros de forma
estructurada es XML (Extensible Markup Language) [1], [2], [3], [4], [5]. La estructura
se basa en el uso de etiquetas dispuestas en forma de árbol y que han de cumplir una

Capítulo 1. INTRODUCCIÓN 2
serie de reglas de validación. Además, los documentos en formato XML pueden ser
editados directamente por el usuario usando un editor de textos. Se ha consolidado
definitivamente como un lenguaje estándar de información. Para definir la estructura de
la información, el modelo de contenido y los tipos de elementos y atributos dentro de un
documento XML, se pueden utilizar lenguajes de definición de documentos como el
XML Schema, o el lenguaje DTD. La tecnología XML está avalada por el Consorcio
para la World Wide Web (W3C) [6].
Por otro lado, uno de los lenguajes más utilizados actualmente es Java [7], [8], [9],
[10], que es un lenguaje de programación Orientado a Objetos. Una de sus
características es que nos ofrece una API estándar de serialización que permite guardar
o transmitir la información representada con objetos que están en memoria.
Dadas las ventajas de la tecnología XML, sería deseable utilizarla como formato
de almacenamiento para programas Java. La API estándar de almacenamiento de Java
tiene unas características que la hacen menos adecuada que XML en ciertas ocasiones:
• Cuando se necesita que el fichero tenga un formato que sea comprensible
por una persona usando cualquier aplicación de texto, es más adecuado
utilizar XML, ya que la serialización de Java se almacena con un formato
binario.
• Cuando se necesita que el fichero tenga un formato que pueda ser tratado
por un aplicación que no esta escrita en Java, es necesario un formato
estándar como XML, ya que el formato de Java sólo es entendible por sus
aplicaciones.
• Cuando se necesita saber si el fichero tiene el formato adecuado, XML
proporciona un sistema de validación del fichero; ya que su estructura
queda definida en un DTD o XML Schema. En cambio, el formato de
serialización de Java no ofrece esta validación hasta el momento de la
recuperación de la información.
Existen formas de serializar objetos Java mediante XML [11], [12], [13], [14],
usando diferentes APIs. Para serializar objetos en XML básicamente se siguen los
siguientes pasos: se obtiene el valor de cada uno de los atributos del objeto y se
representa su valor entre una etiqueta XML. En caso de que el valor no sea de un tipo
primitivo sino de un objeto, habrá que representar también en el documento todos los

Capítulo 1. INTRODUCCIÓN 3
atributos de este objeto. El proceso de deserialización es el inverso, se va leyendo el
documento XML y el valor de las etiquetas se ha de asignar a los atributos.
Además, estos documentos tendrán una estructura que se corresponde con las
clases que definen esos objetos; dicha estructura se puede representar en un DTD o en
un XML Schema.
El proceso de serialización es un proceso mecánico, por lo que es posible generar
automáticamente el código necesario para obtener el documento XML. De esta forma,
se puede mantener sincronizado el objeto Java y el DTD o XML Schema, eliminando al
desarrollador de este trabajo mecánico y propenso a errores.
La finalidad de este Proyecto Fin de Carrera es facilitar al programador el
mantenimiento de esta sincronización. Para ello se quiere conseguir una herramienta
que pueda obtener de manera automática y/o asistida la definición en XML Schema o
DTD de esa información, además del código necesario para obtener la serialización en
XML.
El objetivo no se limita simplemen te a conseguir una persistencia en XML de
objetos Java, sino que los documentos XML que representen la información orientada a
objetos de estos objetos Java, aprovechen toda la riqueza semántica de la tecnología
XML; es decir, que no existan etiquetas y/o sintaxis que hagan ver que el documento
XML parte de una transformación desde código Java. Por ejemplo, al modelar un
atributo de una clase que implementa la interfaz java.util.List de Java, no debería
aparecer en el documento XML el nombre cualificado de la clase (java.util.List) ni nada
que represente al código de Java, sino que se debería utilizar en XML varias etiquetas
que representen la cardinalidad que ofrece XML Schema para conjuntos de elementos
con la misma etiqueta.
Actualmente existen muchas tecnologías de serialización de objetos Java en
XML, algunas de las más representativas se estudian en el capítulo 2 del presente
documento. La mayoría de estas tecnologías, sin embargo, no persiguen el objetivo de
utilizar toda la riqueza semántica de lenguaje XML Schema, como se ha comentado,
sino que simplemente utilizan el documento XML como medida de persistencia,
haciendo explícito el origen de los datos desde Java. Este hecho puede dificultar tanto la
transformación de esta información a otros lenguajes o sistemas, como la comprensión
de dicha información ante el ojo humano.
El proceso de generación de la serialización en XML y el XML Schema,
aprovechando toda su riqueza semántica, no es un proceso trivial, con lo que será

Capítulo 1. INTRODUCCIÓN 4
necesario en algún momento la ayuda del usuario para poder decidir la forma de
representar ciertas construcciones de Java con XML Schema.
En la Figura 1 se puede ver, de forma general, la aplicación que pretendemos
desarrollar, denominada SerXML. Se procesará una clase de Java (Clase.java) para
generar, tanto el documento XML Schema como el DTD (Clase.dtd y Clase.xsd).
Además de estos documentos también, para esta clase y todas aquellas que intervengan
en la serialización (ya sea como tipo de atributos, en las listas, etcétera), se crearán los
documentos Clase2XML.java, donde la palabra Clase es el nombre de la clase que se
serializa.
Clase.dtd / Clase.xsd
Clase.java
SerXML
Clase2XML.java
Figura 1: Proceso de generación de los documentos
Para serializar la clase (Clase.java) se incorporarán las clases Clases2XML.java
mencionadas al proyecto Java donde se encuentra Clase.java. Estas clases incorporadas,
ofrecerán la posibilidad de, mediante una serie de métodos, poder serializar un objeto de
dicha clase o deserializar un documento XML obteniendo el objeto en el mismo estado
en el que se había serializado.

Capítulo 1. INTRODUCCIÓN 5
El resto del contenido de esta memoria se estructura en diferentes capítulos. En el
capítulo 2 se realiza un estado del arte, analizando y comparando las herramientas más
representativas que existen en el mercado para serializar objetos Java en XML, a través
de distintos criterios de evaluación, pudiendo comprobar que ninguna satisface todos
ellos y concluyendo con la necesidad de generar una nueva herramienta que cumpla
todos los objetivos y criterios perseguidos. En el tercer capítulo se presenta la
metodología seguida y se introducen conceptos básicos acerca de las tecnologías
utilizadas en el desarrollo. En el capítulo 4 se ofrece un ejemplo de uso de la aplicación
SerXML, haciendo un seguimiento paso a paso gráfico de le generación de los distintos
documentos, intentando de esta manera facilitar la comprensión del resto de esta
memoria. En el capítulo 5, se muestra la especificación de todos los requisitos que
incorporará la aplicación, así como de algunos de sus casos de uso. En el capítulo sexto
presenta el análisis realizado, donde se muestran los diagramas de análisis
correspondientes a los casos de uso presentados en el capítulo anterior. El séptimo
presenta el diseño de la aplicación SerXML, estructurado en diferentes puntos
correspondientes a diferentes bloques de la aplicación, como son la interfaz gráfica y del
fichero de configuración y las generaciones de los distintos documentos. El capítulo 8
corresponde a la implementación y pruebas realizadas. Y por último, el capítulo 9
dedicado a la conclusión, donde se presentan los objetivos y logros alcanzados y los
distintos trabajos futuros. Para finalizar, la memoria contiene la bibliografía usada como
libros, apuntes de asignaturas y referencias a páginas Web y un anexo donde se describe
la forma de utilizar la herramienta desarrollada.

Capítulo 2. ESTADO DEL ARTE 6
2
Capítulo 2
ESTADO DEL ARTE
La creación de este proyecto tiene como principal objetivo serializar objetos Java
utilizando las ventajas que proporciona XML. Para dicha creación es interesante
estudiar otros trabajos, proyectos o herramientas existentes relacionadas con la
serialización en XML de objetos Java o de JavaBeans [16]. Entre los diferentes
enfoques que se ofrecen, la serialización en XML que generan algunos de ellos se
caracteriza por mantener mucha similitud con Java; es decir, existen etiquetas y
atributos que hacen ver que el documento XML parte de una transformación desde
código Java. Debido a esto se pierde una importante faceta del XML: su legibilidad y
portabilidad. Otros, en cambio, intentan ser más independientes de Java, pero para ello
necesitan de una gran cantidad de información y configuración para poder serializar.
La herramienta que se pretende realizar en este Proyecto Fin de Carrera tiene
como finalidad facilitar, en todo lo posible, el trabajo del desarrollador en el proceso de
serialización en XML de objetos Java. Para ello, no será necesario el conocimiento
previo de XML, siendo además posible la modificación de algún aspecto del documento
XML por dicho desarrollador (por ser éste totalmente legible), a diferencia de la
serialización que ofrece la API de Java (que se realiza mediante un flujo de bytes sólo
comprensible para Java).
En este capítulo, en primer lugar, se muestran una serie de criterios para la
evaluación de este tipo de herramientas. A continuación, se presenta un estudio

Capítulo 2. ESTADO DEL ARTE 7
comparativo de dichas herramientas, observando su comportamiento para cada uno de
los criterios. Finalmente, se presenta una breve conclusión acompañada con un resumen
en forma de tabla con las principales características y el resultado obtenido para cada
una ellas; así como las referencias a direcciones de Internet donde encontrar mayor
información sobre las herramientas presentadas.
2.1. Herramientas de Serialización en XML de objetos
Java
2.1.1. Criterios de evaluación de un serializador en XML de
objetos Java
Las herramientas de serialización de objetos Java en XML se pueden evaluar
principalmente atendiendo a los siguientes aspectos:
1. Características de las clases cuyos objetos se serializan: mediante este
aspecto podemos comprobar si soporta cualquier tipo de clase Java; si han de
tener alguna característica especial y cuál es esta; o, finalmente, si únicamente
soporta JavaBeans. Las convenciones de formato son las siguientes:
• Constructor sin argumentos.
• No permitir campos públicos.
• Atributos accesibles mediante métodos get/set/is.
2. Dependencia del documento XML generado con Java: representa el grado
de dependencia con Java que presenta el documento XML generado por la
serialización. En el caso de que este grado sea alto, significa que el
documento mantiene muchas etiquetas correspondientes de Java y, por ello,
supone una mayor dificultad de lectura y comprensión, además de no tener la
posibilidad de exportarlo a otros lenguajes. Si no existe tal dependencia, esto
facilitará la portabilidad a otros lenguajes de programación y a otras
arquitecturas que no utilicen Java.

Capítulo 2. ESTADO DEL ARTE 8
3. Posibilidad de configuración: con ello podemos especificar ciertos aspectos
de la serialización que serían muy complicados de detectar por la herramienta.
En cierta medida va relacionado con el aspecto anterior porque, en el caso de
que no exista tal configuración, hay más posibilidad de dependencia con Java,
ya que hay ciertas características de las clases Java que son ambiguas y no nos
ofrecen toda la información necesaria para su serialización. Por ejemplo, no se
puede obtener en tiempo de compilación las clases de los objetos que albergan
las estructuras de datos que se describirán en el punto 5, ya que el código de
una clase de Java no contiene esta información, que únicamente se puede
obtener en tiempo de ejecución, por lo que es necesario obtenerlo mediante
una cierta configuración.
4. Soporta referencias circulares: un aspecto muy importante es que en los
objetos a serializar, se nos ofrezca la posibilidad de referenciar, mediante los
atributos, a objetos cuyas clases no pertenezcan a la API estándar de Java o a
una API externa y de las cuales tenemos el código Java. En el caso de que
esto no fuera soportado, nos restringiría totalmente la libertad de realizar
clases de Java. Además, puede darse el caso de que algunos atributos de los
objetos Java hagan referencia a otros objetos, y así sucesivamente, hasta
cerrarse la referencia con el objeto inicial (referencia circular) formando
grafos de objetos.
5. Soporta estructura de datos: algo que ha de soportar toda serialización son
las estructuras de objetos pertenecientes al Collection Framework [17] de
Java. Es una característica muy común y que se suele utilizar mucho en todos
los objetos Java. Las estructuras de datos que ofrece el Collection Framework
de Java son las siguientes interfaces:
• java.util.List
• java.util.Map
• java.util.Set
6. Construye DTD y/o XML Schema: algunas herramientas ofrecen la
posibilidad de crear un DTD y/o XML Schema de la clase del objeto que se
va a serializar y, con ello, permiten validar el documento XML creado en la
serialización de un objeto de dicha clase.

Capítulo 2. ESTADO DEL ARTE 9
7. Tecnología que emplea para leer XML: en el proceso de deserialización en
el que se lee el documento XML para transformarlo en un objeto Java, se
pueden utilizar distintas APIs para el procesado de este XML. Las más
conocidas son SAX [18] y DOM, aunque algunas herramientas puedan
utilizar APIs propias.
2.1.2. Estudio comparativo
Para comparar las características de las herramientas, se ha utilizado siempre la
misma clase: Person.java. Esta clase contiene tanto atributos públicos como privados,
de tipos primitivos y de clases de la API estándar de Java de las que no tenemos el
código fuente. También tiene un constructor sin parámetros y otro con un parámetro, así
como métodos get y set, pero no para todos los atributos, para así poder comprobar
como se comportan las herramientas a evaluar en distintas situaciones. En la Tabla 1 se
muestra la clase que se acaba de comentar.
import java.util.Date;
import java.util.ArrayList;
public class Person {
private String nombre;
public int peso;
public Boolean casado;
private Date cumple;
//Es un ArrayList de la clase Person
private ArrayList amigos;
public Person() {
}
public Person(String nombre) {
this.nombre = nombre;
}
public String getNombre() {
return nombre;

Capítulo 2. ESTADO DEL ARTE 10
}
public void setNombre(String string) {
nombre = string;
}
public ArrayList getAmigos() {
return amigos;
}
public void setAmigos(ArrayList list) {
amigos = list;
}
public Date getCumple() {
return cumple;
}
public void setCumple(Date date) {
cumple = date;
}
}
Tabla 1 : Clase Person.java
Se ha utilizado otra clase (Prueba.java) que es ejecutable, para poder realizar las
pruebas de serialización y guardarlas en fichero. Mediante esta clase se ha utilizado un
objeto de la clase anterior (Person.java), con referencias a otro objeto Person, pero que
a su vez hace referencia al objeto original, por lo que se produce referencia circular,
siendo esta característica la más “delicada” a la hora de serializar.
El objeto al que se hace mención se presenta a continuación en la Tabla 2, y el
grafo cíclico del objeto se muestra en la Figura 2.
Person personVane = new Person("Vane");
personVane.peso = 50;
personVane.casado = new Boolean(false);
personVane.setCumple(new Date(1979, 5, 9));
Person personMauri = new Person("Mauri");
personMauri.peso = 80;

Capítulo 2. ESTADO DEL ARTE 11
personMauri.setCumple(new Date(1979,5,12));
Person personSergio = new Person("Sergio");
personSergio.peso = 75;
personSergio.setCumple(new Date(1979,8,3));
ArrayList amigosSergio = new ArrayList();
amigosSergio.add(personVane);
personSergio.setAmigos(amigosSergio);
ArrayList amigosVane = new ArrayList();
amigosVane.add(personMauri);
amigosVane.add(personSergio);
personVane.setAmigos(amigosVane);
Tabla 2 : Objeto Person a serializar
personSergio
personVane
personMauri
Figura 2: Referencia circular en el objeto Java
La clase Person.java, junto con un objeto de la misma, se han realizado teniendo
en cuenta las características expuestas en el apartado 2.1.1., pudiéndose comprobar cada
uno de los aspectos descritos en ella.
A continuación se muestran las herramientas más representativas para la
serialización en XML de objetos Java, junto con una breve descripción de las mismas y
de los resultados obtenidos para cada una de las características comentadas
anteriormente. Destacar, por último, que también se incluye el documento XML
generado tras la serialización.

Capítulo 2. ESTADO DEL ARTE 12
2.1.2.1. JSX 2.2.3.2
Esta herramienta permite almacenar objetos Java en un fichero, para poder leerlo
más tarde y reproducir una copia del objeto original (deserialización).
Características:
1. Es capaz de serializar cualquier objeto de Java, tanto si tienen atributos
públicos como privados, y realiza correctamente la serialización de listas.
2. Se aprecia una clara influencia de Java en la serialización generada, por lo que
su dependencia es alta. Ej: java.lang.String ó . En estos dos ejemplos observamos el resultado de la
serialización de un String y de la clase Person, respectivamente. La influencia
es clara, ya que en el primer ejemplo la serialización de un String no tendría
que mostrar, en ningún momento, el paquete al que pertenece, serializándolo
como una cadena de caracteres únicamente. En el segundo ejemplo se ha
serializado una clase Java especificando claramente que proviene de una clase,
hecho que dificultaría la portabilidad de la serialización generada a un
programa que no comprendiera la programación orientada a objetos.
3. Las pocas posibilidades de configuración que tiene se centran en poder evitar
incluir algún atributo u objeto en la serialización, por motivos diversos como
puede ser la seguridad.
4. Soporta tanto referencias a otras clases como referencias circulares, ya que
serializa un grafo dirigido de objetos y, para ello, utiliza identificadores como
atributo de los elementos.
5. Soporta sin problemas las listas de objetos, aunque el XML resultante no es
claro, provocando así dificultad en su comprensión.
6. No ofrece la posibilidad de generar el DTD o el XML Schema.
7. La tecnología para la lectura del documento XML es propia de la herramienta.

Capítulo 2. ESTADO DEL ARTE 13
En la Tabla 3 se muestra parte (por ser excesivamente extenso) del resultado de la
serialización.

Capítulo 2. ESTADO DEL ARTE 14
… (Omitida el objeto Person de Mauri)
…(Omitido el objeto Date)
…(Omitidas las declaraciones de las clases padres de ArrayList)
…(Omitidas clausulas de cierre de los elementos)
Tabla 3: Serialización obtenida con JSX
2.1.2.2. Castor XML 0.9.5.3
Castor XML es una herramienta que permite mapear objetos tanto a documentos
XML como a bases de datos relacionales. Tiene una funcionalidad muy amplia, por lo
que para casos sencillos puede resultar excesivo.
Características:
1. Únicamente es capaz de serializar objetos de Java cuyas clases sean
JavaBeans, esto se ha podido comprobar en el serialización del ejemplo, en la
que sólo ha añadido aquellos atributos que tuvieran set y get (tomando el
nombre para el elemento XML a partir de estos métodos); los atributos

Capítulo 2. ESTADO DEL ARTE 15
públicos no los ha incluido. Además únicamente ha soportado el constructor
público por defecto (sin argumentos). Estructuras, todas ellas, que
corresponden a las convenciones de formato de los JavaBeans.
2. Se aprecia alguna influencia de Java en la serialización generada, pero en una
mucho menor medida que en el caso anterior. Ej.: xsi:type="Java:Person", en
él se observa que ha serializado una clase introduciendo la palabra Java en
ella.
3. Tiene posibilidades de configuración, los cuales se realizan especificando
determinadas propiedades en el archivo castor.properties (convenciones del
nombre, especificar si los tipos primitivos son tratados como atributos o
elementos, etcétera).
4. Soporta referencias a otras clases pero no referencias circulares, ya que en
nuestro ejemplo vemos claramente que no ha realizado bien la referencia,
además de no mostrar ningún error al encontrarse con una.
5. Soporta sin problemas las listas de objetos.
6. Permite construir el XML Schema a partir de la clase Java y viceversa.
7. Emplea tecnología propia para la lectura del documento XML a través de un
modelo de objeto que representa la información.
Muchas de las características explicadas se pueden apreciar en el resultado de la
serialización del objeto de la clase Person con esta herramienta (Tabla 4).
Mauri
1979-06-09T00:00:00.000+02:00
Sergio
1979-09-03T00:00:00.000+02:00

Capítulo 2. ESTADO DEL ARTE 16
Vane
1979-10-13T00:00:00.000+02:00
Tabla 4: Serialización obtenida con Castor XML
2.1.2.3. XStream 1.0.2
XStream es una simple librería que permite tanto pasar de documentos XML a
objetos Java (de forma muy sencilla), como realizar el proceso inverso; es decir,
serializar objetos Java en formato XML.
Características
1. Es capaz de serializar cualquier objeto Java; en nuestro ejemplo ha introducido
correctamente todos los atributos del objeto sin distinguir la visibilidad ni la
existencia de los métodos get y set, además de soportar cualquier tipo de
constructor.
2. Se ha podido comprobar que no incluye dependencia con Java de ningún tipo.
3. No tiene la posibilidad de configurar la serialización.
4. Soporta referencias a otras clases pero no referencias circulares, ya que en
nuestro ejemplo vemos claramente que no ha realizado bien la referencia. En
este caso, no da ningún error al encontrarse con una, pero en lugar de escribir
correctamente la referencia pone lo siguiente:
.
5. Soporta sin problemas la serialización de listas de objetos con un resultado,
además, muy comprensible.
6. No es posible construir el DTD o el XML Schema.
7. Emplea tecnología propia para la lectura del documento XML.

Capítulo 2. ESTADO DEL ARTE 17
El resultado de la serialización se muestra en la Tabla 5.
1979-06-09 00:00:00.0 AM
Mauri
80
1979-09-03 00:00:00.0 AM
Sergio
75
false
1979-10-13 00:00:00.0 AM
Vane
70
Tabla 5: Serialización obtenida con XStream
2.1.2.4. JOX 1.17
Al igual que el resto de herramientas, que facilitan la transformación entre
documentos XML y objetos Java, JOX, además, puede aceptar como entrada un DTD
para escribir el documento XML valido.

Capítulo 2. ESTADO DEL ARTE 18
Características:
1. Únicamente es capaz de serializar objetos Java cuyas clases sean JavaBeans,
ya que para poder realizar la serialización necesita para todos los atributos sus
métodos set y get, por lo que los atributos públicos que no presentaban estos
métodos no han sido incluidos. Además de existir un constructor sin
argumentos para que realice bien la serialización.
2. Se aprecia alguna influencia de Java en la serialización generada pero en una
mucho menor medida que en el caso de JSX. Ej.: ,
se observa claramente la introducción de la palabra Java y
class.
3. No ofrece la posibilidad de configurar la serialización.
4. Soporta referencias a otras clases pero no referencias circulares, ya que en
nuestro ejemplo al encontrarse con una referencia circular ha fallado y
finalizado bruscamente la ejecución. Por ello, ha sido necesario modificar la
clase de Prueba para eliminar estas referencias. En la especificación de esta
herramienta se comenta que si se usa DTD cuando se escriba el XML son
posibles las referencias circulares.
5. Soporta sin problemas la serialización de listas de objetos.
6. No soporta la generación de DTD o XML Schema.
7. Emplea SAX y DOM para la lectura del documento XML.
El resultado de la serialización del objeto de la clase Person se puede ver en la
Tabla 6.
09-06-1979 00:00:00 CEST
Mauri
03-09-1979 00:00:00 CEST
Sergio

Capítulo 2. ESTADO DEL ARTE 19
13-10-1979 00:00:00 CEST
Vane
Tabla 6: Serialización obtenida con JOX
2.1.2.5. Koala KOML 1.21
Es esta herramienta ha sido necesaria la modificación de las clases de prueba:
Person.java y Prueba.java para poder obtener un documento correcto XML, ya que no
finalizaba correctamente la ejecución. Se ha modificado para eliminar las listas y las
referencias circulares que no lo soportaba.
Características:
1. Es capaz de serializar cualquier objeto de Java, incluso no tratándose de
JavaBean, aunque con algunas restricciones, como por ejemplo, el
impedimento de poner colecciones de objeto (listas).
2. Se aprecia bastante influencia de Java en la serialización generada. Ej.: class
name='java.lang.Boolean', donde la etiqueta java.lang.Boolean es claramente
obtenido de la clase del objeto serializado.
3. La serialización no es configurable con esta herramienta.
4. Soporta referencias a otras clases pero no referencias circulares, ya que en
nuestro ejemplo al encontrarse con una referencia circular ha fallado y
finalizado la ejecución.
5. No ha soportado la serialización de listas de objetos.
6. Es posible construir XML Schema.
7. Emplea SAX para la lectura del documento XML.
la Tabla 7.
El resultado de la serialización realizada mediante esta herramienta se muestra en

Capítulo 2. ESTADO DEL ARTE 20
70
75
60263388000000
Sergio
false
60266844000000
Vane

Capítulo 2. ESTADO DEL ARTE 21
Tabla 7: Serialización obtenida con Koala KOML
2.2. Conclusiones
El análisis realizado de las distintas herramientas revela que, en función de las
necesidades de cada proyecto, se han desarrollado herramientas con unas características
específicas. Sin embargo, en el desarrollo de una herramienta de serialización en XML,
dicha serialización debería ser independiente a Java, ya que en caso contrario, se pierde
toda la portabilidad y compresión que nos ofrece el lenguaje XML. Ante todo, es
importante que soporte cualquier tipo de objeto Java y numerosas opciones de
configuración.
Además, es aconsejable que la tecnología empleada para procesar documentos
XML sea SAX, debido, entre otros aspectos, a la poca utilización de memoria que
necesita (a diferencia, por ejemplo, de la API DOM que carga todo el árbol del
documento XML en memoria).
En el estudio comparativo, se ha podido observar que la única que no soporta
estructuras de datos en la serialización ha sido Koala KOML. En esta herramienta y en
JOX ha sido necesario (debido a la interrupción brusca del programa) modificar las
clases de prueba para poder obtener la serialización.
Se ha podido observar que JSX utiliza identificadores para resolver las referencias
circulares, además JOX sí que da la posibilidad de procesar estas referencias
especificándolo en la DTD. A diferencia de las demás herramientas que no lo soportan.
De todas las herramientas, en base a las características analizadas, las que mejores
resultados han dado han sido JSX y XStream, la primera de ellas soporta referencias
circulares sin necesidad de configurar la serialización, pero por el contrario, el
documento XML generado es ilegible e incomprensible por cualquier persona que no
entienda de XML o de Java, ya que es el que más dependencia ha mantenido con Java.
El resultado de la serialización de la otra herramienta destacada es comprensible y
fácilmente modificable (sin ninguna dependencia con Java), aunque no ha sido capaz de
resolver las referencias circulares que se ha encontrado. En estas dos herramientas la
tecnología empleada para procesar XML es propia, por lo que no se ha podido

Capítulo 2. ESTADO DEL ARTE 22
comprobar la utilización de memoria de la misma, además, aceptan cualquier tipo de
objeto Java, lo que implica: que debe existir un constructor por defecto, que los
atributos tengan una visibilidad determinada o que exista métodos get y set; facilitando
de esta forma el trabajo al desarrollador.
Por tanto, viendo las conclusiones obtenidas, ninguna de las herramientas
satisface ampliamente todas las características deseables para una herramienta de
serialización:
1. Serializar cualquier característica de las clases de los objetos Java.
2. No mostrar ninguna dependencia con el lenguaje Java.
3. Dar distintas opciones de configuración.
4. Soportar referencias circulares entre los objetos.
5. Soportar cualquier estructura de datos de Java.
6. Construcción tanto del DTD como del XML Schema.
7. Utilización de SAX para la lectura del documento XML.
De esta manera, surge la necesidad de desarrollar SerXML. En la que se ha
querido soportar todos los criterios de evaluación comentados, para obtener una
herramienta íntegra. Para ello, serán necesarias ciertas restricciones, como la existencia
de un fichero de configuración para poder obtener aquellas opciones que son ambiguas
en una clase Java. Por ejemplo, en el caso de las estructuras de datos en Java, es
necesario saber las clases que manejan, ya que en tiempo de compilación no es posible.
En este estudio del estado del arte, se ha observado que muchas herramientas no daban
la posibilidad de configuración, limitando enormemente la serialización.
Además, ninguna de ellas da la opción de generar el documento DTD, y pocas el
XML Schema; la herramienta que se va a desarrollar va a permitir generar tanto uno
como el otro, con las grandes ventajas que esto aporta a la validación de la serialización
generada y, sus posteriores modificaciones realizadas por el usuario.
La tecnología que se va ha emplear en la lectura de los documentos XML será
SAX, que como ya se comentará en el capítulo siguiente, se caracteriza por su eficiencia
y poca utilización de memoria, a diferencia de DOM que resulta menos eficiente con
documentos extensos.
Otra característica muy importante es la dependencia con Java del XML generado.
Que como ya se ha comentado, XStream ha sido la única que no ha tenido tal

Capítulo 2. ESTADO DEL ARTE 23
dependencia; en la herramienta a desarrollar se tomará el ejemplo de esta aplicación y
no se incluirá ninguna dependencia, aprovechando toda la potencia semántica que nos
permite el lenguaje XML.
En la Tabla 8 se muestra un resumen comparativo de las características para cada
herramienta.
Más información sobre cada una de las herramientas se puede obtener accediendo
a las páginas web de la Tabla 9.
Herramientas
Características
1. Características de
las clases cuyos
objetos se serializan
2. Dependencia del
XML generado con
Java
3. Posibilidad de
configuración
4. Soporta referencias
circulares
5. Soporta estructura
de datos
6. Construye DTD y/o
XML Schema
7. Tecnología que
emplea para leer
XML
JSX
2.2.3.2
Cualquier
objeto Java
Castor
XML
0.9.5.3
Sólo
objetos
JavaBean
XStream
1.0.2
Cualquier
objeto Java
JOX 1.17
Sólo
objetos
JavaBean
Koala
KOML
1.21
Cualquier
objeto Java
Muy alta Baja Ninguna Baja Alta
Baja Media Ninguna Ninguna Ninguna
Si No No No No
Si Si Si Si No
No
XML
Schema
No
Propia Propia Propia
Tabla 8: Tabla Comparativa.
No
SAX y
DOM
XML
Schema
SAX

Capítulo 2. ESTADO DEL ARTE 24
Herramientas
JSX 2.2.3.2
Castor XML 0.9.5.3
Xstream 1.0.2
JOX 1.17
Koala KOML 1.21
Referencias
- http://jsx.org
- http://www.castor.org
- http://xstream.codehaus.org/
- http://sourceforge.net/projects/jox
- http://www.wutka.com/jox.html
- http://koala.ilog.fr/koml/
Tabla 9: Relación de páginas web con información acerca de las herramientas analizadas.

Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 25
3
Capítulo 3
METODOLOGÍAS Y TECNOLOGÍAS
En el presente capítulo se va a justificar la metodología seguida en la definición e
implementación de la herramienta desarrollada, así como las tecnologías software
empleadas.
3.1. Metodología
La metodología elegida en la especificación, análisis, diseño e implementación del
sistema ha sido la del Proceso Unificado de Desarrollo de Software (PUD), cuya
descripción se muestra a continuación.
3.1.1. PUD
Se trata de una metodología para acometer el desarrollo de sistemas informáticos,
propuesta por Ivar Jacobson, Grady Booch y James Rumbaugh.
Se ha elegido principalmente por tres razones:
• Se trata de un estándar avalado por OMG (Object Management Group),
consorcio de alrededor de 800 miembros (compañías de la industria del
software) que buscan el desarrollo de especificaciones que sean técnicamente
excelentes, comercialmente viables e independientes del vendedor. OMG
define object management como el desarrollo software que modela el mundo
real mediante su representación como objetos. Estos objetos no son más que el

Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 26
encapsulamiento de atributos, relaciones y métodos de componentes software
identificables.
• Recoge la experiencia de tres grandes metodologías anteriores:
- OMT (Object Modeling Technique) de Rumbaugh.
- OOAD (Object-Oriented Analysis and Design) de Booch.
- Objectory de Jacobson.
• Actualmente, se usa en la mayoría de las empresas para grandes proyectos y se
imparte por muchas instituciones.
El PUD es un proceso de desarrollo de software, definido como un conjunto de
actividades necesarias para transformar los requisitos de un usuario en un sistema
software. Sin embargo, el proceso unificado es más que un proceso de trabajo; es un
marco de trabajo genérico que puede especializarse para una gran variedad de sistemas
software, para diferentes áreas de aplicación, diferentes tipos de organizaciones y
diferentes niveles de aptitud.
El Proceso Unificado está basado en componentes y utiliza el Lenguaje Unificado
de Modelado (Unified Modeling Language, UML) [19], [20], [21], [22].
Está dirigido por casos de uso, porque con éstos se especifican las funcionalidades
que el sistema proporciona al usuario. Los casos de uso representan los requisitos
funcionales y fuerzan a pensar en términos de importancia para el usuario y no sólo en
términos de funciones que serían bueno tener. Los casos de uso no sólo son una
herramienta para especificar los requisitos del sistema, sino que también guían su
diseño, implementación y prueba, es decir, guían el desarrollo software.
El PUD está centrado en la arquitectura, pues la manera en que se organiza el
sistema depende de los casos de uso clave y debe tener en cuenta la comprensibilidad, la
facilidad de adaptación al cambio y la reutilización. Los casos de uso clave son aquéllos
que dotan al sistema con la funcionalidad fundamental para los usuarios y, sin los
cuales, los demás casos de uso no tienen sentido.

Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 27
Es iterativo e incremental. El trabajo se divide en partes más pequeñas o llamadas
iteraciones. En cada iteración se recorren los flujos de trabajo 1 y se obtiene una versión
interna, ver Figura 3.
Análisis
Diseño
Codific.
Figura 3: Flujos de trabajo
Pruebas e
Integración
En síntesis, en cada iteración se amplía el sistema con nuevos casos de uso, se
identifican nuevos riesgos y se mitigan los ya conocidos. Las iteraciones se agrupan en
fases, que por orden secuencial son las siguientes: inicio, elaboración, construcción y
transición. Cada una centra sus esfuerzos más en unos flujos de trabajo que en otros. La
etapa de inicio se centra en la captura de requisitos y el análisis. La etapa de elaboración
lo hace en el análisis y el diseño. Las etapas de construcción y transición se centran en
el diseño, implementación y pruebas.
El trabajo de los requisitos se hace fundamentalmente durante la fase de inicio y la
de elaboración. Durante la fase de inicio se identifican la mayoría de los casos de uso
que delimitan el sistema y el alcance del proyecto, se detallan los más importantes
(menos del 10 por ciento). Durante la fase de elaboración se capturan la mayoría de los
requisitos restantes (el 80 por ciento). En la fase de construcción se capturan e
implementan los requisitos que restan, mientras que en la fase de transición
prácticamente no hay captura a menos que haya requisitos que cambien.
Dadas las limitaciones de esta memoria, se van a presentar conjuntamente los
requisitos obtenidos en las fases de inicio, elaboración y construcción. De la misma
manera, los distintos modelos de casos de uso, modelos de análisis, clases, paquetes,
modelos de despliegue, etcétera, de los flujos de trabajo de requisitos, análisis, diseño,
1 Flujos de trabajo: Requisitos, análisis y diseño, implementación y pruebas. El modelado del
negocio y la implantación no forman parte del desarrollo propiamente dicho. Un flujo de trabajo es un
conjunto de actividades.

Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 28
implementación y pruebas, se expondrán conjuntamente sin reflejar su evolución a
través de las iteraciones.
Debido a las dimensiones del proyecto, existen otras actividades de la
metodología que no tienen cabida, como por ejemplo la gestión de los recursos
humanos, ya que el autor de esta memoria asume todos los roles de un sistema:
arquitecto, jefe de proyecto, analista, diseñador, etcétera. De la misma forma no se hará
un control de versiones, ya que el desarrollo se corresponde con una primera versión.
Tampoco se abordan actividades propias de los sistemas distribuidos como por ejemplo
diagramas de despliegue, ya que no se trata de un sistema distribuido.
3.2. Tecnologías software
A continuación, se enumeran las tecnologías software empleadas en el desarrollo
de este trabajo. En los siguientes párrafos se describen dichas tecnologías desde un
punto de vista general y, posteriormente se presentan las características más relevantes
de las herramientas concretas empleadas en la realización de este proyecto de fin de
carrera:
• Orientación a Objetos.
• Java.
• API JavaCET.
• XML
• DTD y XML Schema
• SAX y DOM
3.2.1. Orientación a objetos
La orientación a objetos es el paradigma de programación más utilizado
actualmente en el desarrollo de aplicaciones. Esto se debe a la existencia de lenguajes
como Java, C# y otros, que aportan otras muchas características que los hacen fáciles de

Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 29
usar, potentes, compatibles con muchas plataformas y, sobre todo, seguros y fáciles de
depurar.
El paradigma de programación orientada a objetos establece una asociación entre
la información y las sentencias encargadas de gestionar dicha información. Desde un
punto de vista de la programación procedimental, la orientación a objetos se puede ver
como la asociación entre funciones y procedimientos a los tipos de datos que manejan.
En programación orientada a objetos una clase es el conjunto formado por la
definición de la estructura de la información y las sentencias que la gestionan. A los
subprogramas que gestionan los datos, se les denomina métodos. A cada uno de los
ítems de información que definen la estructura de la información se les denomina
atributos o campos. En esta forma de organizar el código el módulo mínimo de
programación es la clase.
Cuando ejecutamos un programa orientado a objetos, a la entidad que tiene los
valores de los ítems definidos en una clase se le denomina objeto.
Además de esta organización del código existen primitivas de encapsulamiento,
de forma que los atributos existentes en una clase quedan ocultos a los usuarios de esa
clase. Para comunicar esa información se utilizan los métodos. Al conjunto de métodos
de una clase que pueden ser usados por otras clases se le denomina interfaz pública.
Las principales aportaciones de este paradigma al desarrollo de sistemas software
son:
• Herencia: característica que permite construir una clase (conocida como clase hija)
basándose o teniendo como plantilla otra clase construida previamente (conocida
como clase padre). Al utilizar una clase padre como base para definir una clase
hija, los atributos y métodos definidos en la clase padre están disponibles en la
clase hija. Es decir, los objetos de la clase hija tendrán valores para los atributos
definidos en la clase hija y también tendrán valores para los atributos definidos en
la clase padre. Esta característica permite una mayor reutilización del código, ya
que si dos clases de un programa tienen ciertas características en común, se puede
construir una clase que sea clase padre de las dos clases albergando los atributos y
métodos que sean comunes a ambas.
• Polimorfismo: característica de la programación orientada a objetos, muy
relacionada con la herencia, que solventa un conjunto de problemas típicos que

Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 30
aparecían en la programación procedimental. En multitud de aplicaciones es
necesario gestionar información con distinta estructura de una forma homogénea.
Por ejemplo, en un programa de diseño gráfico hay que gestionar figuras
geométricas de distintos tipos como rectángulos, círculos, triángulos,... En algunos
casos, estas figuras han de gestionarse de forma homogénea, si se quiere cambiar su
color o moverlas por el área de dibujo. En otras ocasiones, cada tipo de figura
tendrá que responder de una forma particular. Si se quiere calcular su área, para
cada tipo de figura hay que usar una expresión distinta. Para tratarlas de forma
homogénea, se crea una clase padre, llamada Figura. En esta clase se definen los
métodos comunes a todas las figuras: cambiar el color o cambiar su posición. En
cambio, el área no se puede definir de una forma común y, por tanto, cada uno de
los tipos de figuras definen su propio método para el cálculo del área. En la clase
padre hay que definir un método que no tiene implementación, llamado abstracto.
La implementación de este método será establecido en cada una de las clases hijas
que representan a cada tipo de figura.
Si declaramos una variable de la clase Figura, puede contener objetos de cada una
de las clases hijas. Cuando sobre el valor de esta variable se ejecuta el método de
cálculo del área, se usa el polimorfismo y se ejecuta la implementación del método
que corresponde a la clase concreta de la figura. Es decir, el código que se va a
ejecutar cuando se llame a un método, depende de la clase del objeto concreto que
reciba el mensaje y no de la clase de la variable en que se llame.
3.2.2. Java
El lenguaje de programación utilizado en el desarrollo de este proyecto ha sido
Java. A continuación, se presentan algunas de las características que han llevado a la
elección de este lenguaje:
• Orientado a objetos: Java trabaja con sus datos como objetos y con interfaces a
esos objetos. Soporta las características propias del paradigma de la orientación a
objetos: abstracción, encapsulamiento, herencia y polimorfismo. Encaja
perfectamente con el proceso unificado de desarrollo, visto anteriormente.

Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 31
• Simple: Posee una curva de aprendizaje muy rápida. Ofrece toda la funcionalidad
de un lenguaje potente, pero sin las características menos usadas y más confusas de
éstos.
• Robusto: Java realiza verificaciones en busca de problemas, tanto en tiempo de
compilación como en tiempo de ejecución. La comprobación de tipos en Java ayuda
a detectar errores lo antes posible, en el ciclo de desarrollo. Java obliga a la
declaración explícita de los tipos de los ítems de información, reduciendo así las
posibilidades de error. Maneja la memoria para eliminar las preocupaciones por
parte del programador de la liberación o corrupción de la misma.
• Portable: La indiferencia de la arquitectura representa sólo una parte de su
portabilidad. Además, Java especifica los tamaños de sus tipos de datos básicos y el
comportamiento de sus operadores aritméticos, de manera que los programas son
iguales en todas las plataformas. Estas dos últimas características se conocen como
la Máquina Virtual Java (JVM).
• Orientado a aplicaciones: Dispone de muchas bibliotecas orientadas al desarrollo
de múltiples aplicaciones, por ejemplo, existen librerías para gestionar bases de
datos, para XML, gráficos, etcétera.
3.2.3. API JavaCET
La API JavaCET alberga un conjunto de clases que permiten analizar el código
fuente de un programa escrito en Java y controlar su ejecución en otra máquina virtual.
Esta API no tiene como objetivo gestionar el ciclo de desarrollo de una aplicación Java,
sino que está preparada para gestionar código Java sin errores de compilación, que
represente una aplicación correcta y permitiendo gestionar todos los aspectos de un
programa escrito en el lenguaje de programación Java.
Esta API representa un programa Java desde dos puntos de vista: su definición,
formada por código y librerías; y su ejecución, la cual se puede ejecutar paso a paso,
consultando el estado del sistema, o bien, permitiendo registrar una traza de la misma.
Está definida e implementada también en lenguaje Java y sus principales ventajas son:

Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 32
• Facilidad de comprensión y manejo.
• Ortogonalidad al representar los conceptos.
• Tratamiento integrado de la definición y la ejecución.
JavaCET hace uso de los principios de la programación orientada a objetos, por
otro lado, es independiente de la implementación, lo que permite que se puedan
desarrollar implementaciones diferentes que obedezcan a distintos criterios.
Como ejemplo de su funcionamiento, para poder analizar y gestionar el código
fuente de un programa y su ejecución desde otro programa Java, existe la clase llamada
ProgramaJava, que en su constructor recibe como parámetro el directorio donde se
encuentran los ficheros fuente del programa Java, las librerías usadas y la ruta del SDK
usado para compilar y ejecutar dicho programa. En dicho constructor se realiza todo el
reconocimiento léxico, sintáctico y semántico de los ficheros fuente y toda esta
información se guarda como atributos de dicho objeto en memoria. En la Figura 4 se
muestra esta transformación.
ClaseA.java
ClaseB.java
:ProgramaJava
ClaseLibreriaA.class
fuentes
ClaseLibreriaC.class
Libreria.jar
librerías
Analisis
léxico
sintáctico
semántico
C:\j2sdk1.4.2_01
sdk
ficheros fuente, librerias
externas y librerias estándar
que componen un programa java
Proceso de
reconocimiento
Estructura de datos
orientada a objetos que representa
al programa java
Figura 4: Proceso generación ProgramaJava.

Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 33
3.2.4. XML
XML o Lenguaje de Marcado Extensible (Extensible Markup Language), fue
creado por el Consorcio para la World Wide Web en 1996 para superar las limitaciones
de HTML (el Lenguaje de Marcado de HiperTexto que es la base para todas las páginas
Web), ya que permite crear etiquetas propias. A pesar de que SGML ha sido usado
durante décadas en la industria para publicación, su complejidad ha intimidado a mucha
gente.
La versión 1.0 de XML proporciona su especificación y los estándares adoptados.
XML utiliza el conjunto de caracteres UNICODE, lo que permite su portabilidad entre
sistemas y herramientas. UNICODE incluye los caracteres existentes en la mayoría de
las lenguas que se utilizan en el mundo.
A continuación se enumeran varias de las características más importantes de
XML:
• Separa el contenido de la presentación.
• Asigna una estructura lógica a la información permitiendo crear un código más
ligero.
• Extensible.
• Facilita el intercambio de documentos entre usuarios y aplicaciones.
• Admite enlaces avanzados entre documentos.
• Admite búsquedas avanzadas, consiguiendo búsquedas más rápidas.
• Permite validar el contenido contra una gramática.
• Da soporte a la Web semántica (extensión de la Web actual en la que el
significado de la información queda bien-definido).
• Es independiente de la plataforma sobre la que trabaja, con lo que simplifica el
intercambio de datos.
Hay dos tipos de documentos XML:

Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 34
• Documento bien/mal formado: en el caso de que sigua las reglas de sintaxis
definidas por la especificación XML el documento se considera bien formado,
en el caso contrario es mal formado.
• Documentos válidos/no válidos: si un documento bien formado sigue las
reglas definidas en un DTD o esquema, ese documento es válido; en el caso de
que no siga las reglas será no válido.
En la Tabla 10 se muestra un ejemplo de documento XML en el que vemos que se
puede asignar algún significado a las etiquetas en el documento; más importante aún,
resulta fácil para una máquina procesar la información, ya que se puede extraer el
código postal de un documento simplemente localizando el contenido rodeado por las
etiquetas y , técnicamente conocido como el
elemento “codigo-postal”.
Mrs.
Mary
McGoon
1401 Main Street
Anytown
NC
34829
Tabla 10: Ejemplo de documento XML
3.2.5. SAX y DOM
Para acceder al contenido de los documentos XML se puede utilizar alguna de las
dos interfaces de programación más empleadas actualmente:
• SAX: API Simple para XML

Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 35
• DOM: Modelo de Objetos de Documento
SAX y DOM utilizan dos enfoques muy diferentes. Ninguno de los dos enfoques
ofrece soluciones para todos los casos que se pueden dar en las aplicaciones que
trabajan con XML. Por tanto, se debe adoptar uno u otro dependiendo del caso
particular del que se trate.
SAX permite analizar documentos XML de forma secuencial, lo que permite que,
aunque los documentos sean de gran tamaño, prácticamente no consuma memoria. Pero
por otra parte, este tipo de procesamiento impide tener una visión global del documento
por la que navegar.
Un analizador que soporta esta interfaz recorre el documento XML que se está
analizando de forma secuencial. Este analizador, según va detectando la ocurrencia de
determinados eventos (comienzo/fin del documento, comienzo/fin de una etiqueta,
etcétera), va realizando llamadas a funciones de retorno predefinidas. Son estas
funciones de retorno en las que el programador introduce el código encargado de
procesar los datos que contiene el documento XML.
En cambio, DOM es una interfaz de programación que permite analizar y
manipular dinámicamente, y de manera global, el contenido, el estilo y la estructura de
un documento. Tiene su origen en el W3C.
Para trabajar con un documento XML, primero se almacena en memoria en forma
de árbol con nodos padre, nodos hijo y nodos finales, que son aquéllos que no tienen
descendientes. En este modelo todas las estructuras de datos del documento XML se
transforman en algún tipo de nodo, organizándose jerárquicamente en forma de árbol
para representar la estructura descrita por el documento XML. Una vez creado el árbol
en memoria, se van recorriendo los diferentes nodos y se analiza a qué tipo particular
pertenecen. En función del tipo de nodo, la interfaz ofrece una serie de funcionalidades
u otras para poder trabajar con la información que contienen.
Para este proyecto, en el que se van a manejar documentos XML de diferentes
tamaños, normalmente bastante grandes y complejos, es conveniente no cargarlos
totalmente en memoria, ya que se reduciría enormemente la eficiencia. En este caso, la
mejor herramienta para procesarlos es de manera secuencial mediante SAX, ya que para
este proyecto no es necesario insertar, borrar, modificar,... estos documentos,
únicamente es necesario su lectura.

Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 36
3.2.6. DTD y XML Schema
Actualmente hay dos tipos posibles de gramáticas:
• DTD, Document Type Declaration
• XML Schema
DTD es un lenguaje de definición de documentos concebido para SGML
(Standard Generalized Markup Language), se puede usar para definir el modelo de
contenido y los tipos de elementos y atributos dentro de un documento. Sin embargo
tiene ciertas limitaciones, como puede ser su sintaxis, el hecho de que no es XML, sino
que es específica y poco clara y no soporta espacios de nombres; su tipado de datos es
extremadamente limitado y sus únicas cardinalidades posibles: 0, 1, infinito.
Por otra parte XML Schema, que al igual que las DTDs describe la estructura de
la información, sí tiene sintaxis XML y ofrece nuevas características sobre las DTDs.
Soporta el tipado de datos, importando todos los tipos de datos de los lenguajes
convencionales y proveyendo al desarrollador de la posibilidad de crear los suyos
propios. También soporta validación de espacios de nombres, de forma que pueden
coexistir múltiples esquemas sin que haya conflictos de nombres entre ellos. Ofrece
características de orientación a objetos. Permite una reutilización sencilla de código y
presenta menor rigidez a la hora de definir cardinalidades para elementos.
Las DTD son una solución parcial a una de las principales carencias de XML: la
posibilidad de definir vocabularios de fabricación propia destinados a cubrir las
necesidades particulares. Se prevé que las DTDs en pocos años desaparezcan o queden
relegadas en un segundo plano, debido sobre todo al trabajo que se está llevando a cabo
en los XML Schema y a todas las ventajas que presentan éstos sobre las DTDs.
Para la aplicación que se va a desarrollar se ha apostado por dar la posibilidad de
generar tanto DTD como XML Schema a partir de una clase Java; este documento
generado con cualquiera de los dos lenguajes nos servirá para validar el fichero XML a
obtener en la serialización, con lo que también aprovechar las posibilidades que ofrecen
multitud de herramientas de edición XML.
De este modo se tendrán dos opciones: crear un XML Schema o un DTD.
A continuación en la Tabla 11 se muestra un ejemplo de un XML Schema.

Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 37
Tabla 11: Ejemplo de XML Schema

Capítulo 4. EJEMPLO DE USO 38
4
Capítulo 4
EJEMPLO DE USO
En este capítulo se va a simular una sesión con la herramienta desarrollada
(SerXML). Lo que se pretende es hacer un seguimiento, paso a paso, del proceso de
generación de los archivos para serializar/deserializar.
Puede parecer que este capítulo rompe el orden lógico de la memoria, sin
embargo, la idea es mostrar cómo es la herramienta cuyo desarrollo se explica en los
siguientes capítulos. De esta forma, el lector puede obtener una idea global del resultado
final, y el resto de la memoria le será más comprensible.
Se irán enumerando distintos pasos a seguir en la edición de un documento, con
sus respectivas pantallas y explicaciones. La interfaz ofrece diferentes caminos o formas
de realizar una misma acción, por ejemplo a través de botones, opciones de menús o
menús contextuales, etcétera. Este ejemplo de uso no se va a detener en contar todas las
diferentes posibilidades, ya que eso se explicará en el siguiente capítulo. Una
descripción más detallada de la aplicación, así como el formato del fichero de
configuración se puede consultar en el Anexo A.
1. Antes de abrir la clase Java, se ha de especificar el directorio o ruta donde se
encuentra el Java SDK y, la ruta o directorio raíz del proyecto Java donde se
encuentra la clase a abrir. Estas rutas se pueden especificar en las opciones
“Especificar Ruta Java SDK” y “Especificar Ruta Proyecto” del menú
“Opciones”, también, en el caso de no especificarse de esta forma y pulsar el botón
“Abrir” o la opción “Abrir” del menú “Archivo” (Figura 5), se mostrarán las
distintas ventanas donde seleccionar estos dos directorios. Los ficheros de
configuración han de residir en el mismo directorio que las clases a las que

Capítulo 4. EJEMPLO DE USO 39
corresponden, aunque es posible especificar un directorio distinto mediante la
correspondiente opción en el menú “Opciones”, de esta forma el programa irá a
buscarlas ahí
Figura 5: Abrir clase Java
Una vez especificados los directorios, el botón de apertura se encargará de
preguntar el nombre de la clase, a partir de la cual, se quieren obtener todos los
documentos, tal y como se puede ver en la Figura 6.
El resultado de esta acción se muestra en la Figura 7, donde en el área de texto
superior izquierdo se puede ver el contenido de la clase Java abierta; si ésta es
correcta y no tiene errores de compilación, se activarán los tres botones de
generación de documentos.

Capítulo 4. EJEMPLO DE USO 40
Figura 6: Insertar nombre de la clase Java
Figura 7: Clase Java abierta

Capítulo 4. EJEMPLO DE USO 41
2. Generar los documentos necesarios para serializar/deserializar, pulsando el botón
“Generar Java2XML” o seleccionando la opción “Generar archivos Java2XML”
del menú “Generar”. Únicamente en el caso de que existan referencias circulares,
se preguntará al usuario el nombre del nodo raíz, tal y como se puede apreciar en la
Figura 8. Realizando esto, se generarán todos los documentos (necesarios para la
serialización de la clase abierta), con el nombre Clase2XML, donde Clase es la
clase que serializa. En la Figura 9 se observa el resultado de la ejecución de esta
instrucción.
Figura 8: Obtención del nombre del nodo raíz
3. Generar el documento XML Schema, pulsando el botón “Generar XML Schema” o
seleccionando la opción “Generar XML Schema” del menú “Generar”. Realizando
esto, se generará el documento XML Schema correspondiente a la clase abierta. En
la Figura 11 se observa el resultado de la ejecución de esta instrucción.
4. Una vez generados todos los documentos, es posible guardarlos de distinta forma:
seleccionando uno de la lista y eligiendo el directorio, guardándolos todos en un
directorio elegido o guardándolos todos en el directorio de la clase abierta
inicialmente. En la Figura 12 se puede observar el diálogo abierto una vez se pulsa
el botón o la opción “Guardar Todo” del menú “Archivo”.

Capítulo 4. EJEMPLO DE USO 42
Figura 9: Generación de los archivos Java2XML.java
Figura 10: Generado DTD

Capítulo 4. EJEMPLO DE USO 43
Figura 11: Generado XML Schema
Figura 12: Guardando todos los documentos

Capítulo 4. EJEMPLO DE USO 44
5. Finalmente, una vez guardados todos los documentos, en la Tabla 12 se observa el
resultado de serializar un objeto de la clase Person.java (Tabla 1) que corresponde
con el de la Tabla 2. Se puede apreciar, por un lado, cómo la serialización obtenida
es totalmente independiente de Java y, por otro, la manera de resolver las
referencias circulares, listas, etc.; además, es posible compararlo con los distintos
resultados obtenidos en el capítulo dedicado al Estado del Arte (Capítulo 2), ya que
se corresponde con el mismo ejemplo.
Vane
50
false
1979-06-09T00:00:00
Mauri
80
1979-06-12T00:00:00
Sergio
75
1979-09-03T00:00:00
Tabla 12: Serialización ejemplo con SerXML

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 45
5
Capítulo 5
ESPECIFICACIÓN DE REQUISITOS
El objetivo de la captura de los requisitos es recopilar, clasificar e interpretar
aquella información que debe ser registrada sobre el sistema y que el cliente espera
como solución a sus necesidades, plasmándolo en requisitos claros, concretos y
diferenciados. De esta manera, se mejora la calidad del software y la satisfacción del
usuario, reduciendo los errores y el tiempo de desarrollo.
El resultado de esta actividad es una lista clasificada en categorías, de todos y
cada uno de los requisitos que el sistema debe satisfacer.
Los desarrolladores de software profesionales habitualmente no crean código para
sí mismos, sino para usuarios de software u otros desarrolladores. Los usuarios finales,
con frecuencia, no saben cuáles son los requisitos ni tampoco cómo especificarlos de
una forma precisa, con lo que es importante la tarea de especificar correctamente los
requisitos para abarcar todas las necesidades de éstos. Sirviendo, por un lado al usuario,
para conocer las características del sistema que va a recibir, y por otro lado al grupo de
desarrollo, para el diseño y prueba del sistema.
En este proyecto los clientes o usuarios son los integrantes del departamento y, en
especial, los tutores de dicho proyecto, de esta forma se han podido establecer, mediante
reuniones, los requisitos del sistema.
En cuanto a los requisitos a considerar se pueden distinguir a grandes rasgos entre:
funcionales, aquéllos que especifican las acciones que debe ser capaz de realizar el
sistema; y no funcionales, aquéllos que especifican propiedades del sistema.
La técnica inmediata para identificar los requisitos del sistema se basa en los casos
de uso, los cuales capturan tanto los requisitos funcionales como los no funcionales, que

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 46
son específicos de cada caso de uso. Por otra parte, están los requisitos adicionales, que
son aquellos requisitos no funcionales que no se asocian a un caso de uso concreto.
Un caso de uso especifica el comportamiento de un sistema o una parte del
mismo, y es una descripción de un conjunto de secuencias de acciones, incluyendo
variantes, que ejecuta un sistema para producir un resultado, de valor, observable por un
actor (el cual representa a uno o más usuarios del sistema al que pertenece).
En los siguientes apartados se describe de una forma general la herramienta y se
especifican los requisitos según el estándar IEEE 830-1998. Posteriormente, dentro de
este mismo capítulo, se realiza un estudio de los requisitos mediante la realización de
diagramas de casos de uso y la formalización de dos de los más importantes.
5.1. Descripción general
5.1.1. Perspectiva del producto
Interfaces del sistema
La aplicación es totalmente independiente en cuanto a que no pertenece a ningún
sistema complejo mayor que se sitúe por encima de él.
Interfaces de usuario
La aplicación dispondrá de una interfaz gráfica de usuario a través de la cual se
podrá abrir una clase Java (que se situará en el área de texto de la parte izquierda) y
generar el fichero Java, DTD o XML Schema a través de los menús o botones que se
ofrecen. Una vez creados, se van añadiendo a una lista con todos los demás ficheros
creados y, según la selección, se mostrarán en el área de texto de la parte derecha con la
posibilidad de guardarlo en cualquier unidad.
Interfaces hardware
La aplicación se definirá teniendo en cuenta la tecnología Java. No se consideran
requisitos software adicionales a los que impone la propia tecnología Java.

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 47
Interfaces software
La aplicación se definirá teniendo en cuenta la tecnología Java. No se consideran
requisitos software adicionales a los que impone la propia tecnología Java.
5.1.2. Funciones del producto
Las principales funciones de la aplicación son abrir clase Java; crear una nueva
clase Java, que se utilizará para serializar/deserializar en XML; crear la DTD y/o XML
Schema; guardar la nueva clase Java y cerrar los documentos. En cuanto a la
visualización del documento se muestran dos áreas de texto: la de la izquierda, con la
clase Java abierta y la de la derecha, mostrando el documento seleccionado de una lista
con los documentos generados, que está situada en la parte inferior izquierda.
5.1.3. Características del usuario
Los usuarios que usen la aplicación deberán conocer el lenguaje de programación
Java. Además, si se desea manipular los ficheros XML, DTD o XML Schema, en caso
de generarse, se deberán conocer sus distintos lenguajes a un nivel medio.
5.2. Requisitos específicos
5.2.1. Interfaces
La aplicación se acoge al estándar tradicional de ventanas GUI. La interfaz gráfica
de usuario (GUI, Graphical User Interface), es una alternativa moderna a la E/S por la
terminal que permite a la aplicación comunicarse con su usuario. En una GUI se crea
una aplicación de ventanas.

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 48
5.2.1.1. Ventana de la aplicación
La interfaz gráfica de la aplicación contiene los siguientes elementos:
• Barra de título: con el nombre de la aplicación, llamada serXML, y con
botones para minimizar, restaurar y cerrar la aplicación.
• Barra de menú: con las siguientes opciones y submenús:
o Archivo: opciones para manejar los documentos.
• Abrir: abre una clase Java (después de introducir su nombre) y
lo añade en el área de texto izquierdo. En el caso de que no se
hubieran especificado las rutas de Java SDK y la ruta del
proyecto (donde buscar esta clase), se preguntarán.
• Guardar Seleccionado: guarda el documento seleccionado de la
lista que está contenido en el área de texto derecho, en el
directorio específico.
• Guardar Todo: guarda todos los documentos generados en el
directorio donde se encuentra la clase abierta.
• Guardar Todo en…: guarda todos los documentos generados
en el directorio seleccionado por el usuario.
• Cerrar: cierra todos los documentos, tanto abiertos como
generados.
• Salir: cierra la aplicación.
o Generar: opciones para las distintas generaciones de documentos a
partir del fichero Java abierto.
• Generar archivo Java2XML: genera la clase Java necesaria
para la serialización/deserialización.
• Generar DTD: genera el DTD correspondiente.
• Generar XML Schema: genera el XML Schema.
o Opciones: para especificar las rutas necesarias donde el programa
obtendrá todas la clases y APIs necesarias.
• Especificar Ruta Java SDK: especifica la ruta donde el
programa ha de buscar el Java SDK.

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 49
• Especificar Ruta Proyecto: especifica la ruta del directorio raíz
donde se encuentra la clase para la cual se generarán los
documentos.
• Especificar Ruta Ficheros Configuración: especifica la ruta
donde se encuentran los ficheros de configuración de todas las
clases a procesar.
o Ayuda: ayuda de la aplicación
• Ayuda de SerXML: se muestra una ayuda para el manejo de la
herramienta.
• Acerca de: muestra información acerca de la aplicación.
• Botones: con las mismas funcionalidades que sus correspondientes opciones
de menú. Dispone de los siguientes botones por orden de aparición de
izquierda a derecha y de arriba a abajo:
o Abrir
o Guardar Todo
o Generar Java2XML
o Generar DTD
o Generar XML Schema
• Vistas: la aplicación contiene dos áreas de texto verticales y una lista en la
parte inferior izquierda.
o Área de texto izquierda: vista de texto plano que presenta el contenido
del documento abierto con anterioridad.
o Área de texto derecha: vista de texto plano que presenta el contenido
del documento seleccionado de la lista que se detalla a continuación.
o Lista: vista con la lista de los documentos generados.
5.2.1.2. Diálogos
La aplicación presenta en su ejecución una serie de cuadros de diálogo para llevar
a cabo distintas funcionalidades. Se presentan en las siguientes líneas de forma
esquematizada:

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 50
• Diálogo de apertura
o Barra de título
Contiene el texto “Seleccione Directorio de Java SDK” o “Selección
Directorio Raíz del Proyecto (donde se encuentra la clase Java)” y un
botón de cerrar ventana.
o Descripción
Muestra las distintas unidades de disco y directorios donde poder
seleccionar un directorio.
o Origen
Aparece al seleccionar el usuario la opción “Especificar Ruta SDK” o
“Especificar Ruta Proyecto” del menú “Opciones”, y en el caso de no
haber introducido anteriormente estos datos, al seleccionar “Abrir” del
menú “Archivo” o al pulsar el botón “Abrir”.
o Formato/organización de la ventana
Dentro del marco principal de la ventana contiene, en la parte
superior, el texto “Buscar en” junto con una lista desplegable, para
seleccionar la unidad de disco o directorio donde se encuentra el
directorio a abrir, y una serie de botones con opciones para navegar,
crear y visualizar los distintos directorios. En el centro de la ventana
presenta un área de texto, cuyo contenido es seleccionable, con una
barra de desplazamiento horizontal (en caso de ser necesaria) donde se
muestran todas las carpetas dentro de la unidad o carpeta seleccionada
anteriormente. En la parte inferior presenta un campo de texto donde
aparecerá el nombre del directorio que se seleccione para su apertura;
un campo con una lista desplegable indicando “Todos los
documentos” y por último dos botones para confirmar (“Abrir”) o
cancelar (“Cancelar”) la operación.
• Diálogo de guardar
o Barra de título
Contiene el texto “Guardar Archivo” o “Guardar Todo en…
(seleccione directorio)” y un botón de cerrar ventana.
o Descripción

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 51
Muestra las distintas unidades de disco y directorios donde poder
guardar un documento o clase Java, o todos ellos.
o Origen
Aparece al seleccionar el usuario la opción “Guardar Seleccionado” o
“Guardar Todo en…” del menú “Archivo”.
o Formato/organización de la ventana
Este diálogo, en cuanto a organización, es igual al de apertura, salvo
cambios mínimos como el texto “Buscar en” que se sustituye por
“Guardar en” y el propósito del diálogo simplemente.
• Dialogo de entrada de datos
o Barra de título
Contiene el texto “SerXML” y un botón de cerrar ventana.
o Descripción
Presenta un texto descriptivo y un área donde introducir el nombre de
la clase.
o Origen
Aparece al querer abrir una clase de Java para crear los documentos.
o Formato/Organización de la ventana
Dentro de la ventana contiene únicamente un icono de pregunta, junto
con un mensaje y un área donde introducir el nombre de la clase Java
a abrir, un botón “Aceptar” para confirmar y otro de “Cancelar” para
anular la apertura.
• Diálogo de error
o Barra de título
Contiene el texto “SerXML” y un botón de cerrar ventana.
o Descripción
Presenta un mensaje de error informando de la imposibilidad de
realizar una acción determinada y por qué.
o Origen
Aparece al intentar realizar el usuario una acción concreta y no ser
posible o al haberse encontrado con un error de algún tipo en la
generación de alguno de los documentos.

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 52
o Formato/Organización de la ventana
Dentro de la ventana contiene únicamente un icono asociado al tipo de
mensaje, en este caso de prohibición, junto con el mensaje informativo
y un botón “Aceptar” para confirmar su lectura.
• Diálogo de acerca de
o Barra de título
Contiene el texto “Acerca de SerXML” y un botón de cerrar ventana.
o Descripción
Muestra información general de la aplicación, como es su nombre,
versión, desarrolladores, etcétera.
o Origen
Aparece al seleccionar la opción de menú “Acerca de”.
o Formato/organización de la ventana
Presenta la información típica de una ventana de estas características.
En la parte inferior contiene un botón “Aceptar”.
5.2.2. Requisitos funcionales
Los requisitos funcionales definen qué debe hacer el sistema, incluyendo los
requisitos relativos a la funcionalidad específica del sistema y los relativos a los
servicios generales del sistema.
Para este proyecto, los requisitos funcionales se pueden dividir en cinco bloques,
tres son para el documento que generan:
- Documento Java.
- Documento DTD.
- Documento XML Schema.
Y de los otros dos, uno es para el manejo de la interfaz gráfica y el otro para el
manejo del fichero de configuración.

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 53
5.2.2.1. Requisitos para generar el documento Java para la
serialización/deserialización
REQ.FUN.1. – Generación de la clase Java para serializar
Ofrecer la posibilidad de generar una clase Java que será utilizada para serializar
un objeto Java en un documento en XML. Dicha clase tendrá el nombre de la
clase del objeto Java a serializar más 2XML.java.
REQ.FUN.1.1. – Contener el método toXML
Contener la clase Java a generar el método: toXML, dando la posibilidad de,
con este método y pasándole como parámetros un objeto y un OutputStream,
crear un documento XML correspondiente a la serialización del objeto anterior
y devolverlo a través del flujo de salida (OutputStream).
REQ.FUN.1.2. – Serializar todas las partes de una clase Java
Mediante el fichero generado se serializarán todos los aspectos de la clase Java,
así como de las clases que son atributos y así sucesivamente.
REQ.FUN.1.2.1. – Independiente de Java
La serialización generada será completamente independiente de Java, dando
la posibilidad de exportarla a otros lenguajes de programación.
REQ.FUN.1.2.2. – Serializar atributos
Serializar los atributos de una clase como etiquetas XML.
REQ.FUN.1.2.3. – Serializar el valor de los atributos como caracteres
Serializar el valor del atributo del objeto como valor de la etiqueta
especificado en el requisito REQ.FUN.1.2.2., para dicho atributo, se
almacenará como caracteres.
REQ.FUN.1.2.4. – No serializar los atributos nulos
Los atributos cuyo valor todavía no haya sido inicializado y sean nulos, no
se añadirán a la serialización, con lo que no se incluirá ninguna etiqueta
XML para este.
REQ.FUN.1.2.5. – Clases para la transformación a String
Para clases importadas desde una API externa o de la API de Java, de las
que no tenemos el código y que aparecen como tipos de atributos, será

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 54
necesario que exista una clase Java con el nombre de dicha clase importada
que se va a serializar más 2String, de la forma nombreClase2String.
REQ.FUN.1.2.5.1. – Transformar a caracteres con el método toString
Utilizar de la clase nombreClase2String, mencionada en el requisito
padre (REQ.FUN.1.2.5.), el método toString. Mediante este método se
transformará una clase, de la cual no tenemos el código (importada de
otra API o de la API de Java), a String para poder insertarlo como valor
de una etiqueta XML. A este método se le pasará como atributo un
Object de la clase correspondiente, para poder devolver un
java.lang.String.
REQ.FUN.1.2.6. – Referencias entre clases mediante atributos (incluidas
circulares)
Aquellas referencias entre clases que quieran ser representadas mediante un
atributo identificador en la etiqueta XML, se definirán en el fichero de
configuración (REQ.FUN.1.2.7). Estas referencias serán necesarias en el
caso de referencias circulares, y si éstas no existen, se tomará por defecto
sin el atributo identificador, por lo que en caso de haber referencias se
anidarán las etiquetas XML.
Al identificar una referencia en un atributo a una determinada clase, se
utilizará el fichero (al igual que en REQ.FUN.1) con el nombre de la clase
de dicho atributo más 2XML. De esta forma se serializará el objeto de este
atributo.
REQ.FUN.1.2.7. – Serializar listas
Serializar las listas de una clase como etiquetas XML, tantas como objetos
tenga la lista. Dichas etiquetas tendrán el nombre de la clase que alberga la
lista, y estarán incluidas en una etiqueta con el nombre del atributo de dicha
lista. En la Tabla 13 se muestra un ejemplo, donde coches es el nombre del
atributo y Coches el nombre de la clase que alberga la lista.
Entenderemos como listas aquellas clases que implementan el interfaz
java.util.List o java.util.Set.
En el fichero de configuración será necesario especificar la clase de los
objetos que va a albergar la lista.

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 55
M-4567-CH
…
Tabla 13: Ejemplo de serialización de listas
REQ.FUN.1.2.8. – Serializar maps
Serializar las clases que implementan la interfaz java.util.Map, identificando
cada par key/value dentro de una etiqueta denominada MapEntry, todas
estas etiquetas MapEntry se incluirán dentro de una etiqueta XML con el
nombre del atributo (cuya clase implementa la interfaz java.util.Map). Los
pares key y value se serializarán como cualquier otro atributo cuyo tipo no
sea primitivo.
En la Tabla 14 se muestra un ejemplo en el que se puede ver su
funcionamiento.
M-4567-CH
SEAT Leon
…
…
Tabla 14: Ejemplo de serialización maps
Será necesario especificar en el fichero de configuración la clase de los
objetos que va a albergar tanto el key como el value.
REQ.FUN.1.2.9. – Serializar tanto atributos privados como públicos
Se deberán soportar tanto atributos públicos como no públicos. En el caso
de encontrar un atributo que sea no público, deberá existir en la clase el
método get seguido del nombre del atributo con la primera letra mayúscula
(Ej.: para el atributo numLibros el método sería: getNumLibros()). Dicho
método devolverá el valor del atributo.

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 56
Esto no será necesario en el caso de que se vaya a integrar el código
generado en la clase.
REQ.FUN.2. – Generación de la clase Java para deserializar
Dar la posibilidad de generar una clase Java que será utilizada para deserializar un
objeto Java a partir de un documento XML, al igual que en el requisito
REQ.FUN.1., la clase tendrá el nombre del objeto Java a deserializar junto con
2XML.
REQ.FUN.2.1. – Contener el método fromXML
Contener la clase Java a generar el método fromXML, dando la posibilidad de,
con este método y pasándole como parámetro un InputStream, devolver un
objeto que corresponde a la deserialización del documento XML pasado
mediante dicho flujo de entrada (InputStream).
REQ.FUN.2.2. – Deserializar todas las etiquetas y atributos del documento XML
Mediante el fichero generado se deserializarán todas las etiquetas y atributos
del documento XML, a través del método comentado en REQ.FUN.2.1.
REQ.FUN.2.2.1 – Etiquetas XML
Mediante el nombre de la etiqueta se sabrá a qué atributo se hace referencia,
y con el valor de dicha etiqueta asignar el valor al atributo anterior.
REQ.FUN.2.2.2. – Atributos de las etiquetas XML
El atributo en una etiqueta XML tiene la función de identificar el objeto al
que representa la etiqueta para posibles referencias futuras, si estas
referencias no existen, no se añadirá el atributo.
REQ.FUN.2.2.3. – Atributos sin valor en el documento XML
Aquellos atributos para los cuales no existan etiquetas en el documento
XML tendrán valor nulo, de la misma forma que cuando se serializó.
REQ.FUN.2.2.4. – Clases para la transformación desde String
Para clases importadas desde una API externa o de la API de Java, de las
que no tenemos el código y que aparecen como tipos de atributos, será
necesario que exista una clase Java con el nombre de dicha clase importada
que se va a serializar más 2String, de la forma nombreClase2String.

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 57
REQ.FUN.2.2.4.2. – Transformar a caracteres con el método fromString
Utilizar de la clase nombreClase2String, mencionada en el requisito
padre (REQ.FUN.2.2.4.), el método fromString, pasándole como atributo
un java.util.String (caracteres obtenidos del valor de la etiqueta XML),
para poder devolver un objeto de la clase correspondiente.
REQ.FUN.2.2.5. – Referencias entre clases mediante atributos (incluidas
circulares)
En el caso de encontrar una etiqueta XML que haga referencia a un atributo
de otra clase de nuestro proyecto, se utilizará el fichero (al igual que en
REQ.FUN.2) con el nombre de la clase de dicho atributo más 2XML. De
esta forma se deserializará el objeto de este atributo.
REQ.FUN.2.2.6. – Deserializar listas
En el caso de obtener más de una etiqueta XML con el mismo nombre o que
corresponda a la implementación de java.util.List, se procederá a crear el
objeto añadiendo los objetos deserializados en cada etiqueta.
REQ.FUN.2.2.7. – Deserializar maps
Si hay más de una etiqueta XML que corresponde a una serialización de una
clase que implementa la interfaz java.util.Map, se procederá a añadir todos
los objetos mediante el key y value que están dentro de cada etiqueta
MapEntry.
REQ.FUN.2.2.8. – Deserializar tanto atributos privados como públicos.
Se deberán soportar tanto atributos públicos como no públicos. En el caso
de encontrar un objeto cuyo atributo sea no público, deberá existir en la
clase el método set seguido del nombre del atributo con la primera letra
mayúscula (Ej.: para el atributo numLibros el método sería: setNumLibros).
A este método se le debe pasar como parámetro el valor del atributo.
Esto no será necesario en el caso de que se vaya a integrar el código
generado en la clase.
REQ.FUN.2.3. – Utilizar SAX
Para la lectura del documento XML se utilizará SAX, como ya se ha
comentado en el presente documento en el capítulo 3 (apartado 3.2.5. SAX y
DOM).

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 58
REQ.FUN.3. – Fichero de configuración
En caso de querer especificar alguna de las opciones a configurar en la
serialización, será posible utilizar un fichero de configuración, los requisitos para
este fichero se especifican en la sección: Requisitos para leer el documento de
configuración de esta sección.
5.2.2.2. Requisitos para generar el documento DTD
REQ.FUN.4. – Generar DTD
Dar la posibilidad de generar el documento DTD de la clase original Java
transformando las distintas partes de ésta.
5.2.2.3. Requisitos para generar el documento XML Schema
REQ.FUN.5. – Generar XML Schema
Dar la posibilidad de generar el documento XML Schema de la clase original Java
transformando las distintas partes de ésta.
5.2.2.4. Requisitos para el manejo del documento de configuración
REQ.FUN.6. – Utilizar un documento de configuración
A través de un documento de configuración, obtener especificadas claramente las
opciones para la generación de los distintos documentos (Java, DTD y XML
Schema). Acceder al documento de configuración mediante el nombre de la clase
original más 2XML.config, de la forma: nombreClaseOriginal2XML.config.
REQ.FUN.6.1. – Obtener de la configuración el constructor a utilizar para la
deserialización (opcional)
Tomar para la deserialización del objeto Java el constructor que se desea
utilizar y los parámetros de entrada de éste, a los cuales se les asigna valor. Si
no se encuentra esta opción en el documento, tomar el constructor por defecto
(sin parámetros).

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 59
REQ.FUN.6.2. – Obtener de la configuración si el documento generado será
integrado o no en la clase Java original (opcional)
En la configuración se especificará mediante la opción integrado. En el caso de
querer introducir el código Java que se genera, a partir de la clase abierta,
dentro de esta misma clase, sin la necesidad de generar otra nueva clase, esta
opción tendrá el valor de si; y en el caso de querer generar una nueva clase de
nombre: nombreClaseAbierta.java, donde introducir el código generado, el
valor de integrado será no.
REQ.FUN.6.3. – Obtener de la configuración las clases de los objetos que
albergan los tipos java.util.List o java.util.Set (obligatorio)
Para cada uno de los atributos que aparezcan en la clase abierta, que
implementen la interfaz java.util.List o java.util.Set, obtener la clase Java de
los objetos que albergan. Mostrar un mensaje de error en caso de no obtener tal
configuración en el fichero.
REQ.FUN.6.4. – Obtener de la configuración las clases o tipos para los tipos
java.util.Map (obligatorio)
Para cada uno de los atributos que aparezcan en la clase abierta, que
implementen la interfaz java.util.Map, obtener la clase Java de los objetos que
albergan, tanto para la clave como para su valor. Mostrar un mensaje de error
en caso de no obtener tal configuración en el fichero.
REQ.FUN.6.5. – Obtener de la configuración si la clase a procesar ha de soportar
referencias circulares (opcional)
Se podrá definir en el documento de configuración si la clase abierta ha de
soportar referencias circulares, esto ocurre cuando desde otra clase algún
atributo hace referencia circular sobre esta, en este caso se ha de especificar
también el atributo a tener en cuenta en las referencias circulares.
REQ.FUN.6.6. – Obtener de la configuración las referencias circulares existentes
(opcional)
Se podrá definir en el documento de configuración, aquellos atributos que
realizan referencia circular hacia una clase que no pertenezca a la API estándar
de Java o a una API externa (por lo que tenemos su código fuente que se
encuentra en el proyecto). Además se tendrá que configurar la clase a la que
hace referencia este atributo para que soporte la referencia circular.

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 60
REQ.FUN.6.7. – Obtener de la configuración el paquete donde residen las clases
para transformar las clases a String (opcional)
En el documento se podrá identificar el paquete donde residen las clases para
transformar las clases importadas de Java a y desde String (requisitos
REQ.FUN.2.2.4 y REQ.FUN.1.2.5.)
REQ.FUN.6.8. – Obtener de la configuración el paquete donde residirá la clase
(opcional)
En el documento se podrá identificar el paquete donde residirá la clase
Java2XML a generar (requisito REQ.FUN.1.)
5.2.2.5. Requisitos relativos al manejo de la interfaz
REQ.FUN.7. – Abrir documento
Ocurrirá cuando el usuario pulse el botón de abrir documento o seleccione la
opción “Abrir” del menú “Archivo”. En el caso de no haber seleccionado la Ruta
de Java SDK y/o la Ruta Raíz del Proyecto (donde se encuentra la clase a abrir),
se preguntará mediante diálogos de apertura (ver apartado 5.2.1.2, para todas las
referencias a diálogos). Una vez especificadas las rutas, se mostrará un diálogo de
entrada de datos donde se especificará el nombre de la clase a abrir. Antes de abrir
se comprobará que no tenga ningún error de compilación o no existe dicha clase,
en el caso de que tuviera algún error, se avisará con un diálogo de error. Si todo es
correcto, se añadirá al área de texto izquierdo, donde se podrá visualizar su
contenido.
REQ.FUN.8. – Guardar documento
El usuario podrá seleccionar la opción “Guardar Seleccionado” del menú
“Archivo”. Una vez se ejecuta esta acción, se procederá a guardar aquel
documento que estuviera seleccionado en la lista de ficheros generados y
apareciera en el área de texto derecha.
REQ.FUN.9. – Guardar todo
El usuario podrá seleccionar la opción “Guardar Todo” del menú “Archivo” o
pulsar el botón con éste nombre. Una vez se ejecuta esta acción, se procederá a
guardar todos los documentos con su correspondiente nombre, en el directorio
donde se encuentra la clase inicialmente abierta.

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 61
REQ.FUN.10. – Guardar todo en…
El usuario podrá seleccionar la opción “Guardar Todo en…” del menú “Archivo”.
Una vez se ejecuta esta acción, se procederá a guardar todos los documentos con
su correspondiente nombre, en el directorio donde el usuario especifique mediante
una diálogo de guardar.
REQ.FUN.11. – Cerrar documento
La aplicación cerrará el documento abierto y todos los documentos generados tras
seleccionar la opción “Cerrar” del menú “Archivo”. Antes de cerrarlo, se
inicializarán todas las variables del programa, se limpiarán las áreas de texto y la
lista con los ficheros generados.
REQ.FUN.12. – Generar Java2XML
Mediante este botón se generarán todos los documentos necesarios para la
serialización/deserialización, tanto de la clase abierta como de sus referencias a
otras.
REQ.FUN.13. – Generar DTD
Generará mediante este botón el DTD correspondiente a la clase abierta.
REQ.FUN.14. – Generar XML Schema
Generará mediante a este botón el XML Schema correspondiente a la clase
abierta.
REQ.FUN.15. – Especificar ruta donde se encuentra el Java SDK
Mostrará un diálogo de apertura, donde seleccionar el directorio donde se
encuentra el Java SDK necesario.
REQ.FUN.16. – Especificar ruta raíz del proyecto
Mostrará un diálogo de apertura, donde seleccionar el directorio raíz del proyecto
en el que se encuentra la clase a abrir.
REQ.FUN.17. – Especificar ruta ficheros configuración
Mostrará un diálogo de apertura, donde especificar la ruta en la que se encuentran
los ficheros de configuración de todas las clases a procesar.
REQ.FUN.18. – Listado de ficheros generados
En la parte inferior izquierda aparecerá una lista con todos los ficheros generados
(ya sean Java, dtd o xsd). Cada vez que se genere un fichero se añadirá a esta lista,
y en cualquier momento se podrá seleccionar uno para ver su contenido reflejado
en el área de texto derecho.

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 62
REQ.FUN.19. – Área de texto izquierda.
Este área de texto aparecerá en la parte superior izquierda y será posible ver la
clase Java abierta.
REQ.FUN.20. – Área de texto derecha
En el área de texto de la parte derecha de la aplicación aparecerá el contenido del
documento seleccionado en la lista.
REQ.FUN.21. – Mostrar ayuda del manejo de la aplicación
Cuando el usuario pulse la opción “Ayuda de SerXML” del menú “Ayuda”, se
mostrará la información necesaria para la utilización de la aplicación
REQ.FUN.22. – Mostrar información de la aplicación
Una vez el usuario pulsa la opción “Acerca de” del menú “Ayuda”, se le mostrará,
a través del diálogo de acerca de, información sobre de la aplicación.
REQ.FUN.23. – Salir de la aplicación
El usuario dispondrá de dos alternativas para cerrar la aplicación: pulsando el
botón de cerrar de la barra de título o bien seleccionando la opción “Salir” del
menú “Archivo”. En cualquier caso, todas las ventanas de la aplicación se
cerrarán.
5.2.3. Requisitos no funcionales
Una vez especificados los requisitos funcionales del sistema, se especifican los no
funcionales:
5.2.3.1. Fiabilidad
Estos requisitos establecen el tiempo medio entre fallos. Pueden especificar el
tiempo mínimo aceptable así como categorías de fallos permitidos. También
pueden especificar el grado de disponibilidad ante la ocurrencia de fallos en los
componentes del sistema (tolerancia a fallos simples o múltiples).
Para este proyecto no existen requisitos de esta clase.

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 63
5.2.3.2. Documentación
Estos requisitos definen condiciones específicas del proyecto para algún tipo de
documento (por ejemplo, Guía de Usuario o Manual de Operación) además de las
normas estándar de realización de proyectos.
Para este proyecto se ha creado el presente documento, donde se explica
claramente las distintas fases que se han seguido para la realización de dicho
proyecto.
5.2.3.3. Portabilidad
Estos requisitos establecen la posibilidad de exportar la herramienta a otros
sistemas o lenguajes.
REQ.POR.1. Portabilidad de Java
Al ser desarrollada la aplicación mediante Java, facilita la exportación de la
aplicación a otras máquinas y/o sistemas operativos. Ha de ser necesario que
esté disponible la máquina virtual de Java.
REQ.POR.2. Portabilidad de XML
Al realizarse la serialización mediante XML, facilita la exportación de los
documentos generados en la serialización a otras aplicaciones (lenguajes de
programación, procesador de texto,…), sistemas operativos y/o máquinas.
5.2.3.4. Prestación
Estos requisitos especifican valores numéricos para variables del sistema que se
puedan medir (por ejemplo, capacidad, tiempo de respuesta, velocidad).
Cada prestación corresponde a una constante numérica asociada a una función del
sistema y se puede incluir en la especificación de cada función o en este apartado
en sentencias separadas. Los requisitos no han de ser cualitativos sino
cuantitativos (Ej.: respuesta en 10 segundos).
Para este proyecto no existen requisitos de este tipo.

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 64
5.2.3.5. Recursos
Este tipo de requisito especifica restricciones sobre equipamiento hardware y
software sobre el que debe funcionar el sistema. También se especifican los
límites superiores de recursos físicos necesarios para el sistema, tales como
potencia de proceso, memoria principal, espacio en disco, etc.
REQ.REC.1. – Potencia de proceso
La aplicación no necesita de una potencia de proceso elevada, únicamente la
necesaria para poder manejar la máquina virtual de Java.
REQ.REC.2. – Utilización de memoria
La utilización de memoria queda limitada a las necesidades de la máquina
virtual de Java.
5.2.3.6. Seguridad
Estos requisitos especifican condiciones de protección contra intrusismo,
alteración de datos o alteración de las instalaciones. Especifican niveles de acceso,
palabras de paso (password), inhibición de comandos, etc. También definen las
condiciones de seguridad física y las operaciones de mantenimiento preventivo
(backups, pruebas rutinarias, etcétera).
Para este proyecto no existen requisitos de esta clase ya que no se maneja
información importante.
5.3. Diagramas de casos de uso
En esta sección se presentan los distintos casos de uso que forman el sistema (de
la Figura 13 a la Figura 16), que ayudan a una mayor comprensión de los requisitos
descritos en los apartados anteriores.
El primero de ellos es el manejo de la interfaz gráfica, pudiendo observar las
distintas opciones que ofrece al usuario.
En segundo lugar, aparecen 3 diagramas de casos de uso correspondientes a las
distintas generaciones de documentos: generación de la clase Java para la serialización;

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 65
generación del DTD y generación del XML Schema. En estos diagramas se pueden ver
los distintos pasos que realiza la aplicación para obtener los documentos.
Debido a las restricciones de tamaño de esta memoria, únicamente se describirán
los casos de uso más representativos del sistema: Abrir documento y Generar
Java2XML, incluyendo sus descripciones textuales del flujo principal y alternativo
(apartado 5.3.1.). Uno de ellos especifica una funcionalidad del manejo de la interfaz
gráfica y el otro pertenece a la funcionalidad de la generación del documento para la
serialización y deserialización.
Figura 13: Diagrama de casos de uso – Manejo de la interfaz gráfica

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 66
Figura 14: Diagrama de casos de uso – Generación del documento para la
serialización/deserialización
Figura 15: Diagrama de casos de uso – Generación del documento DTD
Figura 16: Diagrama de casos de uso – Generación del documento XML Schema

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 67
5.3.1. Descripción textual del flujo principal y flujos
alternativos
A continuación, en la Tabla 15 y Tabla 16 se van a describir los flujos principales
y alternativos de los casos de uso: Abrir documento y Generar Java2XML, en los que,
además, se especifica una breve descripción, precondiciones, poscondiciones y actores
que participan.
Caso de Uso:
Descripción:
Actor iniciador:
Actores secundarios:
Precondiciones:
Poscondiciones:
Flujo de eventos:
Prioridad:
Estado de desarrollo:
Flujos alternativos:
Abrir documento
El caso de uso se ejecuta cada vez que el usuario desea
abrir un documento Java.
Usuario.
Ninguno.
El usuario ha pulsado el botón de abrir documento de la
aplicación o ha seleccionado la opción “Abrir” del
menú “Archivo”.
El documento Java abierto se añade al área de texto
correspondiente.
1. A través de un diálogo de entrada de datos, se
introducirá el nombre de la clase a abrir.
2. El usuario pulsa el botón “Aceptar” del cuadro del
diálogo.
3. Si el archivo que se quiere abrir no tiene errores de
compilación entonces se abre el documento
mostrando en el área de texto superior izquierda el
contenido de éste.
Alta
Análisis
3.1. Si el usuario pulsa el botón “Cancelar” no se abrirá
la clase introducida.
4.1. Si el documento que se desea abrir tiene errores de
compilación, entonces no se abre, mostrando un
diálogo de error para informar al usuario.
Tabla 15: Caso de uso “Abrir documento”

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 68
Caso de Uso:
Descripción:
Actor iniciador:
Actores secundarios:
Precondiciones:
Poscondiciones:
Flujo de eventos:
Prioridad:
Estado de desarrollo:
Flujos alternativos:
Generar Java2XML
El caso de uso se ejecuta cada vez que el usuario desea
generar las clases Java necesarias para la serialización y
deserialización en XML.
Usuario.
Ninguno.
El usuario ha abierto un documento Java anteriormente
y ha pulsado el botón de “Generar Java2XML” de la
aplicación o ha seleccionado la opción “Generar
Java2XML” del menú “Generar”.
La lista de documentos Java generados se añade a la
lista situada en el marco inferior izquierdo.
1. El sistema lee el archivo de configuración,
obteniendo las opciones necesarias para la creación
de las clases Java.
2. Se genera las clases necesarias para la serialización
y deserialización.
Alta
Análisis
1.1. Si no se encuentra el archivo de configuración se
cargan los valores por defecto.
2.1. En el caso de encontrarse algún error en la
generación de los documentos, se mostrará un
diálogo de error para informar al usuario.
Tabla 16: Caso de uso “Generar Java2XML”
5.3.2. Formalización de la descripción de casos de uso
Se pueden utilizar técnicas de modelado visual para describir los casos de uso,
éstas ayudan a mejorar su comprensión y pueden ser:

Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 69
• Diagramas de estado, para describir los estados de los casos de uso y las
transiciones entre éstos. Pueden asociarse a clases, casos de uso, o a
sistemas completos.
• Diagramas de actividad, para describir las transiciones entre estados con
más detalle como secuencias de acciones.
• Diagramas de interacción, para describir cómo interactúa una instancia de
caso de uso con la instancia de un actor.
Para este proyecto se presenta un diagrama de estado asociado a la interfaz gráfica
del sistema, Figura 17.
Figura 17: Diagrama de Estado de la interfaz gráfica

Capítulo 6. ANÁLISIS 70
6
Capítulo 6
ANÁLISIS
Durante este flujo de trabajo se analizan los requisitos que se describieron en la
captura de requisitos, refinándolos y estructurándolos, y para ello se hace uso del
modelo de análisis, que ofrece un mayor poder expresivo y una mayor formalización.
El modelo de análisis es una jerarquía de paquetes de análisis que contienen clases
de análisis y realizaciones de casos de uso. Para entender esta definición es necesario
también definir: un paquete de análisis como el mecanismo para organizar los elementos
del análisis; una clase de análisis como una abstracción de una o varias clases y/o
subsistemas del diseño del sistema; una realización de caso de uso como una
colaboración que describe cómo se lleva a cabo y se ejecuta un caso de uso
determinado, en términos de las clases de análisis y de sus objetos de análisis en
interacción.
Las clases de análisis siempre encajan en uno de tres estereotipos básicos: de
interfaz, de control o de entidad. Las clases de interfaz se utilizan para modelar la
interacción entre el sistema y sus actores (es decir, usuarios y sistemas externos). Las
clases de entidad se utilizan para modelar información que posee una larga vida y que es
a menudo persistente. Por último, las clases de control representan coordinación,
secuencia, transacciones y control de otros objetos, y se usan con frecuencia para
encapsular el control de un caso de uso en concreto.
En los siguientes apartados se presenta un análisis de algunos casos de uso y un
diagrama de paquetes que ayuda a organizar lo analizado hasta el momento.

Capítulo 6. ANÁLISIS 71
6.1. Análisis de los casos de uso
A continuación, de la Figura 18 hasta la Figura 22, se presentan los diagramas de
colaboración correspondientes a los casos de uso descritos en el capítulo anterior.
6.1.1. Caso de uso Abrir documento
Figura 18: Diagrama de colaboración – Flujo principal (abrir documento)
Figura 19: Diagrama de colaboración – Flujo alternativo (abrir documento)

Capítulo 6. ANÁLISIS 72
6.1.2. Caso de uso Generar Java2XML
Figura 20: Diagrama de colaboración – Flujo principal (generar Java2XML)
Figura 21: Diagrama de colaboración – Flujo alternativo I (generar Java2XML)
Figura 22: Diagrama de colaboración – Flujo alternativo II (generar Java2XML)

Capítulo 6. ANÁLISIS 73
6.2. Diagrama de paquetes
Los paquetes de análisis proporcionan un medio para organizar los artefactos del
modelo de análisis en piezas manejables. Un paquete de análisis puede constar de clases
de análisis, de realizaciones de casos de uso y de otros paquetes de análisis.
A continuación se presenta, en la Figura 23, un diagrama de paquetes que
organiza algunas de las clases recapituladas hasta el momento.
Figura 23: Diagrama de paquetes de análisis

Capítulo 7. DISEÑO 74
7
Capítulo 7
DISEÑO
En este capítulo se van a describir los diferentes aspectos que se han tenido en
cuenta para diseñar la aplicación. En dicho diseño se modela el sistema y se encuentra
su forma, incluida la arquitectura, para que soporte todos los requisitos especificados en
el capítulo anterior. El resultado de este diseño es el modelo de clases que sirve como
esquema para la implementación.
El modelo de clases es un modelo que describe la realización física de los casos de
uso centrándose en cómo los requisitos funcionales y no funcionales, junto con otras
restricciones relacionadas con el entorno de implementación, tienen impacto en el
sistema a considerar.
En este capítulo no se va a definir ninguna implementación, sino que simplemente
se van a determinar las interfaces que proporciona dicha implementación y, con ello,
obtener los servicios de las mismas. Para la generación de dichas interfaces del diseño,
se ha tenido que realizar varias iteraciones de las fases de elaboración y construcción,
dentro del ciclo de vida. Aunque, debido al tamaño de este documento, únicamente se
va a mostrar el resultado final de dichas iteraciones.
En primer lugar, se va a especificar el diseño, mediante diagramas de clases,
referente a la interfaz que la aplicación ofrece al usuario, más adelante se especificará el
referente a la generación de los documentos, tanto los necesarios para la serialización
(que los denominaremos Java2XML, ya que transforman un objeto Java a XML), como
para la generación del DTD y el XML Schema. También se explica el diseño de las
clases que son utilizadas para obtener la serialización y la deserialización una vez
generados todos los documentos. Finalmente, se detalla la arquitectura del sistema.

Capítulo 7. DISEÑO 75
7.1. Diseño de la interfaz
Para la realización del diseño de esta parte de la aplicación se han tenido en cuenta
los requisitos funcionales de la sección Requisitos relativos al manejo de la interfaz
dentro del apartado 5.2.2.5.
Se ha hecho uso, para el diseño de la interfaz, de la librería gráfica que ofrece
Java: java.swing, la cual presenta muchas comodidades a la hora de construirla. Dentro
de este paquete de Java se pueden observar numerosos componentes como: áreas de
texto, listas, barras de desplazamiento, botones, diálogos, menús, frames, etc., que han
sido de gran ayuda a la hora de desarrollar la aplicación.
También, como ya se ha comentado en el capítulo 3, la clase Generador ha
empleado la librería JavaCET, que permite el acceso detallado a cada una de las partes
que componen un fichero fuente de Java (clase), un ejemplo de dichas partes son:
• Atributos: nombre, tipo (incluyendo referencias a otras clases, listas,
etcétera), visibilidad, …
• Métodos: get y set.
• Constructores que ofrece, etcétera.
Gracias a la obtención de la estructura de la clase, es posible conocer
completamente todos aquellos aspectos a serializar y, de esta forma, obtener una
serialización completa y portable mediante XML.
En la Figura 24 se puede observar como la clase SerXMLGrafico hace uso de la
librería comentada, y también utiliza la clase ManejarFichero para generar los diálogos
de abrir y guardar con sus correspondientes filtros, tanto de apertura como de guardado
(FiltroFicheros).
Además, mediante la clase Generador la aplicación obtiene los distintos
documentos. El diagrama de las diferentes generaciones se podrá ver en el apartado 7.2.
Se puede también apreciar en la Figura 24 como esta clase utiliza la interfaz
InterfazConfiguracion, que se explica detalladamente en el apartado siguiente (7.1.1.
Obtención de los parámetros de configuración).

Capítulo 7. DISEÑO 76
Figura 24: Diagrama de clases – Interfaz
7.1.1. Obtención de los parámetros de configuración
Para la gestión de los parámetros de configuración se ha definido una interfaz
(InterfazConfiguracion) que contiene los métodos que se muestran en la Tabla 17.
public interface InterfazConfiguracion {
public abstract void inicilizarConstructor();
public abstract boolean perteneceConstructor(String nombre);
public abstract boolean integrarCodigo();
public abstract void vaciarConstructorParams();
public abstract int getConstructor();
public abstract boolean correspondeNumParams(int numParams);
public abstract Vector getConstructorParams();
public abstract String getClasefromLista(String nameLista);
public abstract String getClaseCualifFromLista(String nameLista);
public abstract boolean isLista(String nameAtributo);
public abstract String getClaseKeyfromMap(String nameMap);
public abstract String getClaseKeyCualifFromMap(String nameMap);
public abstract String getClaseValuefromMap(String nameMap);

Capítulo 7. DISEÑO 77
}
public abstract String getClaseValueCualifFromMap(String nameMap);
public abstract boolean isMap(String nameAtributo);
public abstract String getPackage_class();
public abstract String getPackageClases2String();
public abstract Properties getProp();
public abstract String getSoportarRefCirc();
public abstract String refCircAtributo(String nameAtributo);
Tabla 17: Métodos de la InterfazConfiguración
Mediante esta interfaz se ofrece la posibilidad de obtener parámetros adicionales
gracias a un fichero de configuración, que se ha diseñado teniendo en cuenta los
requisitos funcionales de la sección Requisitos para el manejo del documento de
configuración en el apartado 5.2.2.4., dicho fichero ofrecerá lo posibilidad de
especificar diversas opciones, tales como:
• El paquete al que pertenecerán las clases creadas, (opcional).
• La clase cualificada de los objetos que alberga cada atributo cuya clase
implementa la interfaz java.util.List o java.util.Set,(obligatorio).
• Las clases cualificadas de los objetos (del key y del value), que alberga
cada atributo, cuya clase implementa la interfaz Java.util.Map,
(obligatorio).
• La integración o no del código en la clase de los objetos a serializar,
(opcional, por defecto no se integra).
• La posición del constructor a utilizar para inicializar el objeto en la
deserialización, al igual que los atributos que inicializa, (opcional, por
defecto se toma el constructor sin parámetros).
• Si la clase a procesar ha de soportar referencias circulares sobre ella.
• Los atributos que intervienen en referencias circulares.
• Paquete en el que aparecen las clases que transformarán las clases que
pertenecen a la API de Java a String, (opcional).

Capítulo 7. DISEÑO 78
7.2. Diseño de la generación de los documentos.
En el diseño realizado para la generación de documentos se han utilizado los
requisitos funcionales que aparecen en las secciones Requisitos para generar el
documento Java para la serialización/deserialización (Java2XML), Requisitos para
generar el documento DTD y Requisitos para generar el documento XML Schema,
presentes en las secciones 5.2.2.1., 5.2.2.2. y 5.2.2.3. del anterior capítulo,
respectivamente
En la Figura 25 se puede comprobar que la clase Generador, también presente en
el anterior diagrama, sirve de enlace entre la interfaz gráfica y la generación de los
diferentes documentos. Mediante esta clase la aplicación genera los documentos, ya que
se encarga de llamar a las correspondientes clases, según la petición de dicha interfaz,
para generar uno u otro documento. Una vez la clase Generador ha obtenido los
resultados, se plasman tanto en la lista gráfica como en las áreas de texto.
Todas las clases que generan los diferentes documentos obtienen las opciones de
configuración a través de Generador, así, por ejemplo, si aparece un atributo cuyo tipo
es una clase que implementa la interfaz java.util.List, entonces necesitará obtener de la
configuración la clase los objetos que van a ser insertados en dicha lista; con lo que, a
través de la clase Generador, la clase JavaWriter obtendrá dicha opción de
configuración (el nombre de la clase, cualificado).
En el diagrama de la Figura 25 se puede observar que existen principalmente tres
clases las cuales se utilizan para generar los tres tipos de documentos:
• GeneradorJava2XM: clase encargada de generar un documento para la clase
Java (que ha sido abierta y va ha ser serializada) mediante la clase JavaWriter.
En el caso de ser necesario generar otra clase, porque existe algún atributo
cuyo tipo es una clase que no pertenece al estándar de Java (con lo que
proviene de la clase que va a ser serializada), entonces se volverá a llamar a la
clase GeneradorJava2XML, que se encargará de generar la correspondiente
clase Java2XML (donde Java es el nombre de la clase).
La clase JavaWriter utiliza otras tres (ClaseSimple, ClaseList y ClaseMap):
- la primera de ellas procesa todos los atributos en los que su tipo es
primitivo o una clase que no pertenece al Collection Framework de
Java; es decir, que contiene un único objeto.

Capítulo 7. DISEÑO 79
- Mediante ClaseList se procesan los atributos cuyo tipo implementa la
interfaz java.util.List o java.util.Set, y que contiene un conjunto de
objetos, con lo que se ha deserializar mediante más de una etiqueta.
- La última clase se utiliza para procesar los atributos cuyo tipo
implementa la interfaz Java.util.Map, con lo que contiene más de un
objeto y se serializa mediante más de una etiqueta, al igual que la clase
anterior.
• GeneradorDTD: se encarga de generar el documento DTD a partir de la clase
abierta.
• GeneradorXMLSchema: al igual que la anterior, a partir de la clase abierta
genera el documento XML Schema.
Figura 25: Diagrama de clases – Generación de los documentos

Capítulo 7. DISEÑO 80
7.3. Diseño de la serialización y deserialización
Una vez se han generado las clases necesarias para realizar la serialización
(Java2XML.java, donde Java es el nombre de la clase), éstas se han de situar en un
paquete del proyecto donde se va a proceder a la serialización del objeto. Una vez en
ese paquete, es necesario que importen o estén en ese mismo paquete una serie de clases
necesarias para la serialización (creación del documento XML), o deserialización
(lectura del documento XML mediante SAX); además de las ya generadas.
En la siguiente Figura 26 se observa el diagrama de clases correspondiente para
serializar o deserializar. Para poder entender claramente éste, se ha de tener en cuenta
que existen tres clases: Clase, UtilizaObjectsClase y Clase2XML, donde la palabra
“Clase” depende de la clase del objeto que se va a serializar. Si por ejemplo tuviéramos
que serializar una clase denominada Mesa, Clase sería Mesa y la clase Clase2XML sería
Mesa2XML y, finalmente, la clase UtilizaObjectsClase se podría llamar de cualquier
manera y sería aquella desde la que se instanciaría un objeto de la clase Mesa, y se
serializaría o deserializaría mediante la utilización de los métodos estáticos toXML y
fromXML de la clase Mesa2XML.
Figura 26: Diagrama de clases – Serialización/deserialización

Capítulo 7. DISEÑO 81
Para realizar la serialización, desde la clase UtilizaObjectsClase se llama al
método estático toXML de la clase Clase2XML, a este método se le pasa como
parámetros un objeto de la clase a serializar (Clase) y un flujo de salida donde se
almacenará el documento XML a generar. La clase Clase2XML utilizará el XMLWriter
para escribir las distintas etiquetas y atributos del XML con su valor. La clase
XMLGeneralPersistenceManager será utilizada para serializar el contenido de una
etiqueta XML (correspondiente a un objeto de una clase que no pertenece a la API
estándar de Java o a otra API externa y de la que sí tenemos el código fuente de Java),
delegándola a otra clase cuyo nombre será buscada mediante el nombre de la clase
seguido por 2XML. Por ejemplo, si estamos serializando una clase Mesa mediante la
clase Mesa2XML y, en un momento dado, nos encontramos con un atributo que alberga
objetos de la clase Silla, entonces se buscará la clase Silla2XML para que, al delegar a
esta, generase la serialización de su etiqueta.
En el caso de la deserialización, desde la clase UtilizaObjectsClase se llama al
método estático fromXML de la clase Clase2XML (Figura 26), este método devolverá el
objeto de la clase correspondiente que proviene de la deserialización del documento
XML, el cual se pasa como parámetro en un flujo de entrada. Para la lectura del
documento XML se utiliza SAX, como ya se ha comentado, redefiniendo en la clase
SAXParserManager los métodos startElement(…), endElement(…), characters(…), etc.
que llamarán a los métodos con el mismo nombre de Clase2XML. De esta manera, para
cada nueva aparición de una etiqueta se procesará como corresponda, almacenando su
valor en el atributo correspondiente del objeto a deserializar.
Al igual que en el caso de la serialización, si se obtiene una etiqueta XML de un
atributo delegado en la serialización, se procederá a delegar (mediante el método
delegateParsing(…)) la lectura del documento XML a la correspondiente clase
Clase2XML (obtenida de la misma forma que en la serialización) de ese atributo. Al
terminar su procesado, esta clase devolverá el control a la clase padre mediante la
instrucción finishedParsing(), y el padre obtendrá el valor del objeto creado en la
delegación mediante el método getObject(), para luego asignar el valor al atributo del
objeto que estamos deserializando.
Gracias a esta delegación del proceso, la serialización y deserialización se realizan
de una forma más simple y estructurada, ya que se organizan por módulos que pueden
ser utilizados en otras serializaciones donde intervengan las clases.

Capítulo 7. DISEÑO 82
7.4. Arquitectura del sistema
La arquitectura es un conjunto de decisiones significativas acerca de la
organización de un sistema software, la selección de los elementos estructurales a partir
de los cuales se compone el sistema, y las interfaces entre ellos, junto con el
comportamiento.
Se necesita la arquitectura para:
• Comprender el sistema. Todos los que intervengan en el sistema deben
comprenderlo.
• Organizar el desarrollo. A más organización en el desarrollo, más
comunicación entre los desarrolladores del proyecto.
• Fomentar la reutilización. Una buena arquitectura ofrece a los desarrolladores
un andamio estable sobre el que trabajar.
• Hacer evolucionar el software. Todo sistema software evoluciona, por lo tanto
debe ser fácil de modificar, y eso se consigue con una buena arquitectura.
La arquitectura se desarrolla durante iteraciones, principalmente durante la fase de
elaboración, donde su resultado final es una línea base de la arquitectura.
La línea base es una versión interna del sistema, centrada en la descripción de la
arquitectura, la cual debe mantenerse actualizada a lo largo de la vida del sistema para
reflejar los cambios y adiciones relevantes para la arquitectura.
Nuevamente y, debido a la limitación de tamaño de esta memoria, se presenta la
arquitectura resultante, de manera muy simple (Figura 27), sin describir su evolución a
través de las distintas iteraciones y flujos de trabajo.
Figura 27: Arquitectura

Capítulo 7. DISEÑO 83
7.5. Distribución en paquetes
Para una mejor organización y estructuración de las clases, se han creado distintos
paquetes y se han distribuido las clases en éstos, facilitando su modularidad al utilizar
las estructuras definidas en el diseño:
• interfaz.interfazGrafica: paquete donde se encuentran todas las clases e
interfaces que son necesarios para crear la interfaz gráfica.
• interfaz.interfazgenerador: paquete donde están las clases e interfaces
para organizar la generación de todos los documentos.
• generador.java2XML: paquete donde se encuentran todas las clases e
interfaces necesarias para generar el documento para serializar.
• generador.dtd: paquete donde se encuentran todas las clases e interfaces
necesarias para generar el DTD.
• generador.xmlSchema: paquete donde se encuentran todas las clases e
interfaces necesarias para generar el XML Schema.

Capítulo 8. IMPLEMENTACIÓN Y PRUEBAS 84
8
Capítulo 8
IMPLEMENTACIÓN Y PRUEBAS
En el presente capítulo se van a explicar las distintas aproximaciones seguidas
para realizar la completa implementación de la aplicación. Éstas han ayudado a
disminuir la dificultad en la implementación y poder así avanzar de manera correcta en
el desarrollo.
La implementación de la aplicación SerXML ha producido 7103 líneas de código,
distribuido en 35 clases organizadas en diferentes bloques dedicados a la creación de la
interfaz, de los generadores y del procesador SAX para la serialización/deserialización.
El lanzamiento de la aplicación hace uso de unos 26 MB de memoria. Durante la
ejecución, este tamaño varía dependiendo del tamaño del proyecto donde se encuentra
la clase abierta y de los documentos generados.
Lo más destacable de este flujo de trabajo se resume en lo siguiente:
• Se han respetado los paradigmas de: la programación orientada a objetos
(abstracción, encapsulación, modularidad y jerarquía); de la programación
orientada a eventos (cada componente reacciona ante los eventos producidos
cuando el usuario interactúa con la aplicación, con métodos asociados para cada
evento) y de la programación estructurada dentro de los métodos de las clases.
• Se ha cuidado la codificación, las normas de estilo de la comunidad Java:
nombres de clases comienzan en mayúsculas, nombres de variables y métodos
en minúsculas,…
• Sin disponer de las herramientas necesarias, se ha cuidado por parte del autor, el
cumplir los umbrales recomendados por las métricas del software en cuanto al

Capítulo 8. IMPLEMENTACIÓN Y PRUEBAS 85
tamaño de clases y métodos, relaciones entre clases, amplitud y profundidad de
las jerarquías de herencia . . .
• Existe un predominio de estructuras de clase y algoritmos de los métodos
eminentemente recursivos, consiguiendo así una mayor limpieza de código.
En los apartados siguientes se describen las distintas aproximaciones tomadas, se
explican las pruebas realizadas y la manera de utilizar la herramienta de manera
correcta.
8.1. Relación de aproximaciones utilizadas en la
implementación
Se ha decidido realizar la implementación de la aplicación en distintas fases, que
denominaremos aproximaciones. La decisión de dividir la implementación en fases es
debido al enorme número de aspectos a tener en cuenta al serializar, con lo que de esta
forma se consigue facilitar la implementación y conseguir un desarrollo más óptimo.
Las aproximaciones a las que se ha hecho referencia son:
• Primera aproximación, realización de las siguientes implementaciones:
- Inicio del desarrollo de la interfaz gráfica.
- Solo se crea un único fichero Clase2XML.java, donde Clase es el
nombre de la clase Java (Ej.: para la clase Coche, sería
Coche2XML.java).
- Procesar el documento XML mediante SAX.
Únicamente se ha contemplado para la serialización y la creación del fichero
arriba nombrado clases con determinadas características:
- Sólo atributos públicos.
- Sin constructores.
- Sin métodos.
- Sólo tipos primitivos: int, doble, char,…
- Admitir tipo String.
• Segunda aproximación, se implementó la posibilidad de procesar clases
además de con las características anteriores, con las siguientes:

Capítulo 8. IMPLEMENTACIÓN Y PRUEBAS 86
- Atributos no públicos.
- Utilizar los métodos get y set para los anteriores atributos.
- Cualquier Clase que pertenezca o no a la API estándar de Java (o a una
externa); en el primer caso no tendremos el código fuente y en el
segundo sí.
- En el caso de tener que serializar una clase que pertenece a la API
estándar de Java o a una externa (por lo que no tendremos su código
fuente), es necesario de la existencia de una clase para transformar a y
desde un String (ver en el capítulo 5 los requisitos REQ.FUN.1.2.5. y
REQ.FUN.2.2.4.).
Debido a las nuevas características, se introdujo la posibilidad de generar más
de un fichero Clase2XML.java, generándose tantos como clases intervengan
en la serialización y que no pertenezcan a una API externa o estándar de Java
(del que sí tenemos el código fuente).
- Mejorar la funcionalidad de la interfaz gráfica, añadiendo entre otras
cosas el listado de documentos generados.
• Tercera aproximación, se añadieron grandes mejoras, entre ellas:
- Añadir la posibilidad de utilizar un fichero de configuración para cada
clase con las siguientes opciones para la serialización:
• Paquete del proyecto en el que se va a añadir la clase generada.
• Paquete del proyecto en el que aparecen las clases que
transformarán las clases que pertenecen a la API de Java a
String (ver en el capítulo 5 los requisitos REQ.FUN.1.2.5. y
REQ.FUN.2.2.4.).
• Constructor a utilizar y atributos a los que asigna valor. Por
defecto se utiliza el constructor sin parámetros.
• Si se integra el código o no. Por defecto no se integra.
• Clase de los objetos que serán utilizados en las Listas (atributos
cuya clase implementa la interfaz java.util.List).
• Clase de los objetos que serán utilizados en los Maps (atributos
cuya clase implementa la interfaz Java.util.Map).
• Si la clase a procesar ha de soportar referencias circulares sobre
ella.

Capítulo 8. IMPLEMENTACIÓN Y PRUEBAS 87
• Los atributos que intervienen en referencias circulares
Gracias al fichero de configuración expuesto, se pudieron introducir las
siguientes mejoras a las clases Java a serializar:
- Aceptar constructores a parte del de por defecto.
- Admitir como tipos de atributos clases que implementen la interfaz
java.util.List.
- Admitir como tipos de atributos clases que implementen la interfaz
Java.util.Map.
• Cuarta aproximación y última, en la que se terminó de desarrollar la
aplicación, con las siguientes mejoras:
- Generación del DTD de la clase.
- Generación del XML Schema de la clase.
- Capacidad de procesar clases que mantengan entre sí referencias
circulares.
8.2. Pruebas
A medida que se ha ido realizando la implementación de la aplicación en cada una
de sus aproximaciones, se han ido probando las nuevas características implementadas
con todas las diversas variantes que podía ofrecer una clase Java, tal y como se ha
detallado en la sección anterior. De esta manera, cualquier error o problema que pudiera
surgir se ha ido solucionando y, en el caso de ser necesario, se han ido modificando
pequeños detalles del análisis y/o diseño.
Las pruebas consistían en generar manualmente una clase a serializar con distintos
atributos, constructores, etcétera; según el nivel de implementación alcanzado hasta el
momento, y se creaba otra clase que era la encargada, una vez generados los
documentos, de instanciar la clase anterior y llamar a las funciones toXML y fromXML
(de estos documentos generados). El objeto correspondiente a la instancia ha sido
creado con distintas características, albergando en las estructuras de datos tanto clases
de la API de Java como del proyecto, de las que sí tenemos su código y podemos
serializar.

Capítulo 8. IMPLEMENTACIÓN Y PRUEBAS 88
En el ejemplo de la Tabla 18 se observan los distintos tipos de atributos utilizados
en este ejemplo de prueba, intentando abarcar todas las posibles variantes: atributos
públicos y privados, estos últimos con sus correspondientes métodos get y set;
constructor por defecto y constructor con un parámetro de entrada; así como dos
estructuras de datos representadas como ArrayList y Hashmap. También se ha
comprobado el correcto funcionamiento con atributos primitivos (char, byte,…);
atributos de la API de Java (String y Date) y atributos del proyecto de los que sí
tenemos su código Java (Silla), utilizados en la estructura de datos ArrayList.
import java.util.Date;
import java.util.ArrayList;
import java.util.HashMap;
public class Mesa{
public String nombre;
public Date fecha;
public char material;
private byte altura;
public short profundidad;
public long anchura;
public int numeroPatas;
public HashMap existe;
private ArrayList sillas;
public Mesa()
{
}
public Mesa(String nom)
{
this.nombre = nom;
}
public byte getAltura() {
return altura;
}
public void setAltura(byte altura) {

Capítulo 8. IMPLEMENTACIÓN Y PRUEBAS 89
}
this.altura = altura;
}
public ArrayList getSillas() {
return sillas;
}
public void setSillas(ArrayList sillas) {
this.sillas = sillas;
}
Tabla 18: Ejemplo clase de prueba (Mesa.java)
El ejemplo anterior se ha ido modificando incorporando nuevas funcionalidades
implementadas y comprobando a lo largo de la implementación el correcto
funcionamiento de todas ellas. Por ejemplo, poner estructuras de datos privadas o
públicas, introducir todos los atributos primitivos de Java, incluir referencias circulares,
introducir estructuras de datos que alberguen distintos tipo de objetos, etc.

Capítulo 9. CONCLUSIONES Y TRABAJOS FUTUROS 90
9
Capítulo 9
CONCLUSIONES Y TRABAJOS FUTUROS
Este capítulo se evalúa los resultados de todo el desarrollo, se divide en dos
partes: por un lado se enumeran los logros alcanzados y, por otro lado, se tratan los
posibles trabajos futuros.
Cabe mencionar que este proyecto se ha publicado como código abierto bajo
licencia GPL y se encuentra disponible en la dirección http://vido.escet.urjc.es/serxml/.
9.1. Principales logros alcanzados
A lo largo del presente documento se han expuesto los objetivos, así como la
especificación de requisitos que la herramienta debía cumplir. Una vez desarrollada y
probada la herramienta, en este punto se puede decir que se cumplen todos los requisitos
especificados.
Se cumple la posibilidad de serializar cualquier objeto Java, aceptando los
siguientes aspectos o características en las clases:
- Cualquier visibilidad y tipo de los atributos, se aceptan atributos tanto privados
como públicos. También es posible que el tipo del atributo sea primitivo, de
una API o de una clase del proyecto y de la cual tenemos su código fuente.
- Constructores sin parámetros, o con algún parámetro que correspondan a
atributos de la clase.
- Cualquier estructuras de datos del Collection Framework de Java
(java.util.List, java.util.Set, java.util.Map).

Capítulo 9. CONCLUSIONES Y TRABAJOS FUTUROS 91
- Referencias circulares entre objetos, identificándolas mediante los atributos
que las realizan.
Otra característica del documento XML que se genera es su total independencia
con Java, donde no se aprecian etiquetas que hagan ver que el documento proviene de la
serialización de un objeto Java.
La aplicación desarrollada permite, a través de un fichero de configuración,
definir características particulares para cada serialización, lo cual es un valor añadido de
cara a una serialización más flexible.
Se ofrece la posibilidad de generar el documento XML Schema, transformando la
clase Java de manera estructurada. Aprovechando la riqueza semántica que ofrece el
XML Schema se han podido representar los tipos de datos de cada atributo primitivo,
así como las referencias circulares. Además es posible generar el documento DTD de la
clase Java.
Mediante SerXML se han mejorado en ciertos aspectos las distintas aplicaciones
analizadas en el capítulo 2; es decir, de los requisitos estudiados para cada aplicación en
dicho capítulo, SerXML cumple todos, mientras que las herramientas analizadas sólo
cumplían parte de ellos.
En definitiva, se ha obtenido una herramienta que hace uso de dos tecnologías
totalmente portables como son Java y XML, eliminando el trabajo de la serialización al
desarrollador y ofreciéndole la posibilidad de utilizar la serialización con cualquier
aplicación, lenguaje de programación o sistema.
9.2. Trabajos futuros
La herramienta desarrollada es una primera versión. En los trabajos futuros a
realizar se pretenderá mejorarla y completarla añadiendo más funcionalidades. La
aplicación SerXML se puede mejorar en ciertos aspectos, tanto en su implementación
como en su definición. Este Proyecto Fin de Carrera es el comienzo de una serie de
proyectos que están siendo desarrollados dentro del grupo ViDo 2 . Por tanto seguirá
desarrollándose hasta que se consiga proporcionar todas las funcionalidades requeridas.
2 Grupo ViDo: Grupo de Visualización y Documentación electrónica de la ESCET en la
Universidad Rey Juan Carlos, Área de Lenguajes y Sistemas Informáticos. http://vido.escet.urjc.es.

Capítulo 9. CONCLUSIONES Y TRABAJOS FUTUROS 92
En los siguientes apartados se describen cada una de las líneas en las que se tiene
previsto seguir trabajando en SerXML.
9.2.1. Integración de SerXML como plugin para los entornos
de desarrollo
Uno de los mayores objetivos en la construcción de software es la reutilización, la
cual es necesaria para no tener que reinventar la rueda cada vez que se necesite
introducir alguna funcionalidad adicional. En nuestro caso, uno de los trabajos futuros
que se pueden llevar a cabo consistiría en implementar SerXML como un plugin de un
entorno de desarrollo, de forma que las aplicaciones que usen SerXML puedan
desarrollarse en dicho entorno de desarrollo, facilitando el trabajo al desarrollador. En
concreto, se está pensando en implementar SerXML como plugin para el entorno de
desarrollo de código abierto Eclipse 3 .
9.2.2. Utilización de toda la riqueza semántica ofrecida en el
lenguaje J2SE 1.5
SerXML es una aplicación diseñada para el lenguaje de programación Java versión
1.4 de la tecnología Java 2 Standard Edition. No obstante, al finalizar este Proyecto de
Fin de Carrera la nueva versión 1.5 está en fase beta. Esta nueva versión incorporará
modificaciones en el lenguaje de programación, por lo tanto, es muy recomendable
incluirla y utilizar todas las nuevas posibilidades semánticas que ofrecerá esta versión.
9.2.3. Uso de SerXML en diversos programas reales
En SerXML se han tomado decisiones acerca de cómo serializar las construcciones
Java desde un punto de vista teórico, ideando ejemplos prototípicos para cada una de
dichas construcciones. Sin embargo, el uso de la herramienta en programas reales
3 Eclipse: http://www.eclipse.org.

Capítulo 9. CONCLUSIONES Y TRABAJOS FUTUROS 93
mostrará las necesidades concretas de serialización de cada uno de ellos. Las diferentes
formas de serializar en XML dependen del uso concreto que se hace de cada una de las
construcciones de Java. Por tanto, usando la herramienta con programas reales se
podrán tener mejores criterios a la hora de determinar cuál es la mejor serialización
posible; es decir, la que está semánticamente más ajustada a las necesidades de la
aplicación concreta.
9.2.4. Utilizar la metaprogramación para realizar la
serialización
Para realizar la serialización en SerXML se han de generar unas clases en Java que
ofrecen, mediante métodos, la posibilidad de serializar objetos Java. Se quiere también
ofrecer la posibilidad de serializar sin la necesidad de generar este código intermedio.
Para evitar la generación de este código puede usarse la metaprogramación.

94
Bibliografía
[1] Aaron Skonnard, Martin Gudgin. Essential XML Quick Reference, Ed.:
Addison-Wesley, 2002.
[2] Cliff Binstock, Dave Peterson, Mitchell Smith, Mike Wooding, Chris Dix,
Chris Galtenberg. The XML Schema Complete Reference, Ed.: Addison-
Wesley, 2002.
[3] http://www.osmosislatina.com/xml/. Osmosis Latina - XML, último acceso:
19-8-2004.
[4] http://www.xml.com/. O’REILLY XML.com, XML from de inside out,
último acceso: 10-9-2004.
[5] Apuntes asignatura Ofimática Avanzada, URJC.
[6] http://www.w3c.org. World Wide Web Consortium, último acceso: 1-9-
2004.
[7] Joshua Bloch. Effective Java: Programming Language Guide, Ed.:
Addison Wesley, 2001.
[8] Eckel, B. Thinking in Java, Ed.: Prentice Hall 1998.
[9] http://www.programacion.com/java/. Programación en Castellano, Java.
[10] http://www.javahispano.org/. javaHispano, último acceso: 6-9-2004.
[11] Brett McLaughlin. Java & XML 2nd Edition, Ed.: O’Reilly, 2001.
[12] Brett McLaughlin. Java and XML Data Binding, Ed.: O’Reilly, 2002.
[13] http://java.sun.com/j2se/1.4.2/docs/guide/serialization/. Serialización de
objetos en Java, último acceso: 28-7-2004.
[14] http://java.sun.com/xml/. Java Technology XML, último acceso: 10-9-
2004.
[15] http://vido.escet.urjc.es/javacet/. JavaCET, último acceso: 11-9-2004.

95
[16] http://java.sun.com/products/javabeans/. JavaBeans, último acceso: 2-9-
2004.
[17] http://java.sun.com/j2se/1.4.2/docs/guide/collections/. The Collection
Framework, último acceso: 4-9-2004.
[18] http://www.saxproject.org. The oficial website for SAX, último acceso: 4-
8-2004.
[19] Pierre-Alain Muller. Instant UML, Ed.:Wrox Press, 2001.
[20] http://www.omg.org/uml. UML, último acceso: 2-8-2004.
[21] Booch G., Jacobson I., Rumbaugh J. El lenguaje Unificado de Modelado,
Ed.: Addison-Wesley, 1999.
[22] Booch, G; Jacobson, I; Rumbaugh, J, El Proceso Unificado de Desarrollo
de Software, Ed.: Addison-Wesley, 2000.

96
Anexo A
En este anexo se describe la utilización de la aplicación con los distintos pasos
que hay que seguir para poder utilizarla correctamente y el fichero de configuración que
se encarga de obtener distintas opciones de serialización.
Utilización de la aplicación
Para realizar la instalación y el correcto uso de la aplicación se han de seguir los
siguientes pasos:
1. Lanzar la aplicación.
2. Una vez se hayan introducido los directorios de la ruta del Java SDK y del
directorio raíz del proyecto donde se encuentra la clase a abrir (mediante el
menú “Opciones” o al pulsar “Abrir”), se ha de introducir el nombre de la clase
Java de la que se quiera obtener los documentos para la serialización.
3. En caso de no desear que se aplique la configuración por defecto o de que
existan atributos cuyo tipo implementa la interfaz java.util.List o Java.util.Map,
se tendrá que crear un fichero con el nombre de la clase anterior más
2XML.config (Ej.: si la clase se llama Coche el fichero se llamará
Coche2XML.config), donde se especificarán las distintas opciones de
configuración. El fichero de configuración ha de tener un determinado formato
que se explica en el apartado siguiente.
4. Si existieran atributos cuyo tipo es de una clase que no pertenece a nuestro
proyecto, entonces habrá que generar (si no se ha realizado todavía) una clase,
para cada clase distinta que exista, con el nombre de la clase más 2String.java
(Ej.: Date2String.java). Ésta ha de ofrecer de modo público y estático los

97
métodos: toString y fromString. Mediante estos métodos será posible
transformar una clase de este tipo a String, para poderla añadir a la serialización,
y desde un String a la clase de nuevo (deserialización). Todo esto se realiza ya
que el documento XML sólo trabaja con etiquetas cuyo valor ha de ser
únicamente de caracteres, para poder serializarlo y mejorar su comprensión.
5. Generar el fichero para la serialización (Java2XML), con ello aparecerán los
ficheros generados en la lista gráfica de la parte inferior izquierda; habrá un
fichero con el nombre de la clase abierta más 2XML (Ej.:Clase2XML.java).
Además de otros ficheros dependiendo de la relación de algunos atributos de la
clase abierta con otras clases de nuestro proyecto, por lo que se generarán tantas
nuevas clases de Java como relaciones diferentes existan.
6. En caso de querer obtener el DTD y/o XML Schema, se tendrá que pulsar el
correspondiente botón de generación, tras el cual aparecerá el documento en la
lista gráfica.
7. Una vez generados los documentos se pueden guardar de diferentes formas:
seleccionando cualquiera de ellos de la lista antes mencionada y pulsar la opción
“Guardar” del menú “Archivo”, guardarlos todos en un directorio determinado
mediante el opción “Guardar Todo en” del menú “Archivo”, o guardarlos todos
en el directorio donde reside la clase abierta pulsando “Guardar Todo” tanto del
menú “Archivo” como del botón.
Una vez generados los ficheros y almacenados en nuestro proyecto Java, se va a
proceder a explicar cómo, mediante éstos, obtener la serialización:
8. Añadir las clases Java generadas al correspondiente paquete del proyecto al que
pertenece la clase abierta inicialmente.
9. Añadir justo en el punto donde se quiere serializar el objeto Java (de la clase
abierta) la instrucción siguiente: Clase2XML.toXML(…), donde la palabra Clase
corresponde a la clase abierta inicialmente y desde donde se han generado todos
los ficheros. Además, al método toXML se le ha de pasar como primer parámetro
un objeto de dicha clase y como segundo un objeto de la clase OuputStream
donde se almacenará el objeto serializado.
En el caso de querer deserializar el objeto, se ha de ejecutar la siguiente
instrucción: Clase2XML.fromXML(…), donde Clase tiene el mismo significado que en

98
el punto anterior. Además, al método se le ha de pasar por parámetro un objeto de la
clase InputStream, desde donde se leerá el documento XML de la serialización anterior;
este método devolverá un objeto de la clase Clase que será el objeto tal y como se
serializó anteriormente.
Fichero de configuración
El nombre del fichero de configuración ha de ser el nombre de la clase a la que
pertenece concatenado con 2XML.config (Ej.: Person2XML.config). Las diferentes
configuraciones se insertan mediante el nombre de la opción asignando el valor que se
desea (Ej.: integrado=si). A continuación se muestran todas las posibles configuraciones
que se pueden realizar a la serialización:
• Definir paquetes y otras opciones:
- package: Especifica el package al que va a pertenecer la clase creada
(opcional).
- packageClases2String: Especifica el package donde se encuentran los
Clases2String para realizar las transformaciones (opcional).
- integrado: Especifica si el código generado será integrado en una clase ya
existente (si) o se creara una nueva clase (no), por defecto “no” (opcional).
• Definir constructor:
- constructor: posición en la clase del constructor que se tomara para la
creación de la clase serializada, por defecto constructor sin parámetros
(opcional).
- constructorParamsi: atributos que se usan el la llamada al constructor. El
valor de i va de uno hasta el número de parámetros (opcional).
• Definir Listas: se utiliza obligatoriamente en el caso de que exista algún atributo
que implementa la interfaz java.util.List o java.util.Set, y sirve para asociar el
nombre de una lista a la clase de los objetos que alberga.
- NombreListai: El valor de i es un entero que va de uno hasta el número de
atributos cuyo tipo es una lista o conjunto. Se especifica el nombre del
atributo.

99
- ClaseListai: El valor de i es un entero que va de uno hasta el número de
atributos cuyo tipo es una lista o conjunto. Se especificará la clase
cualificada de los elementos que alberga la lista.
• Definir Maps: se utiliza obligatoriamente en el caso de que exista algún atributo
que implementa la interfaz java.util.Map, y sirve para asociar el nombre de una
Map a la clase de los objetos que alberga el key y el value.
- NombreMapi: El valor de i es un entero que va de uno hasta el número de
atributos de tipo map. Se especifica el nombre del atributo.
- ClaseKeyMapi: El valor de i es un entero que va de uno hasta el número de
atributos de tipo map. Se especificará la clase cualificada de las claves que
alberga el map.
- ClaseValueMapi: El valor de i es un entero que va de uno hasta el número de
atributos de tipo map. Se especificará la clase cualificada de los valores que
alberga el map.
• Definir referencias circulares:
- soportarRefCirc: define si soporta referencias, por defecto “no”.
- nombreAtributoi: atributos con referencias.
Los comentarios en el fichero de configuración se especifican mediante una #
delante del texto. En la Tabla 19 se muestra como ejemplo un fichero de configuración
para la clase Mesa.java.
package=pruebasMesa
packageClases2String=clases2String
integrado=no
constructor=1
constructorParams1=nombre
#Lists
NombreLista1=sillas
ClaseLista1=Silla
#Maps
NombreMap1=existe
ClaseKeyMap1=java.lang.String
ClaseValueMap1=Silla
Tabla 19: Ejemplo de fichero de configuración