ESTADO DEL ARTE - LITE - Universidad Rey Juan Carlos
ESTADO DEL ARTE - LITE - Universidad Rey Juan Carlos
ESTADO DEL ARTE - LITE - Universidad Rey Juan Carlos
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
INGENIERÍA INFORMÁTICA<br />
Curso Académico 2003/2004<br />
Proyecto de Fin de Carrera<br />
SerXML<br />
Serialización en XML de objetos Java<br />
Tutores: Víctor Fresno Fernández y<br />
Soto Montalvo Herranz<br />
Autor: David Arbona Navarro
This work is licensed under the Creative Commons Attribution-ShareAlike<br />
License. To view a copy of this license, visit http://creativecommons.org/licenses/bysa/2.0/<br />
or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford,<br />
California 94305, USA.
A Vane, por estar siempre a mi lado.<br />
A Víctor, por su apoyo y ayuda.<br />
A Soto, por su dedicación.<br />
A Mica, por aportarme sus conocimientos.<br />
A toda mi familia por comprenderme y darme todo su apoyo.<br />
Y a todos aquellos, que de una forma u otra<br />
han ayudado y colaborado en este proyecto.
II<br />
Índice general<br />
ÍNDICE DE TABLAS....................................................................................................................V<br />
ÍNDICE DE ILUSTRACIONES................................................................................................. VI<br />
1. INTRODUCCIÓN...........................................................................................................................1<br />
2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong>.....................................................................................................................6<br />
2.1. HERRAMIENTAS DE SERIALIZACIÓN EN XML DE OBJETOS JAVA ......................................7<br />
2.1.1. Criterios de evaluación de un serializador en XML de objetos Java.....................7<br />
2.1.2. Estudio comparativo ..............................................................................................9<br />
2.1.2.1. JSX 2.2.3.2 ..................................................................................................................... 12<br />
2.1.2.2. Castor XML 0.9.5.3........................................................................................................ 14<br />
2.1.2.3. XStream 1.0.2................................................................................................................. 16<br />
2.1.2.4. JOX 1.17......................................................................................................................... 17<br />
2.1.2.5. Koala KOML 1.21.......................................................................................................... 19<br />
2.2. CONCLUSIONES ..............................................................................................................21<br />
3. METODOLOGÍAS Y TECNOLOGÍAS.....................................................................................25<br />
3.1. METODOLOGÍA ...............................................................................................................25<br />
3.1.1. PUD .....................................................................................................................25<br />
3.2. TECNOLOGÍAS SOFTWARE...............................................................................................28<br />
3.2.1. Orientación a objetos ...........................................................................................28<br />
3.2.2. Java ......................................................................................................................30<br />
3.2.3. API JavaCET........................................................................................................31<br />
3.2.4. XML......................................................................................................................33<br />
3.2.5. SAX y DOM..........................................................................................................34<br />
3.2.6. DTD y XML Schema.............................................................................................36<br />
4. EJEMPLO DE USO......................................................................................................................38<br />
5. ESPECIFICACIÓN DE REQUISITOS......................................................................................45<br />
5.1. DESCRIPCIÓN GENERAL ..................................................................................................46<br />
5.1.1. Perspectiva del producto......................................................................................46<br />
5.1.2. Funciones del producto........................................................................................47<br />
5.1.3. Características del usuario ..................................................................................47
III<br />
5.2. REQUISITOS ESPECÍFICOS................................................................................................47<br />
5.2.1. Interfaces..............................................................................................................47<br />
5.2.1.1. Ventana de la aplicación................................................................................................. 48<br />
5.2.1.2. Diálogos.......................................................................................................................... 49<br />
5.2.2. Requisitos funcionales..........................................................................................52<br />
5.2.2.1. Requisitos para generar el documento Java para la serialización/deserialización........... 53<br />
5.2.2.2. Requisitos para generar el documento DTD ................................................................... 58<br />
5.2.2.3. Requisitos para generar el documento XML Schema..................................................... 58<br />
5.2.2.4. Requisitos para el manejo del documento de configuración........................................... 58<br />
5.2.2.5. Requisitos relativos al manejo de la interfaz.................................................................. 60<br />
5.2.3. Requisitos no funcionales.....................................................................................62<br />
5.2.3.1. Fiabilidad........................................................................................................................ 62<br />
5.2.3.2. Documentación............................................................................................................... 63<br />
5.2.3.3. Portabilidad..................................................................................................................... 63<br />
5.2.3.4. Prestación ....................................................................................................................... 63<br />
5.2.3.5. Recursos ......................................................................................................................... 64<br />
5.2.3.6. Seguridad........................................................................................................................ 64<br />
5.3. DIAGRAMAS DE CASOS DE USO .......................................................................................64<br />
5.3.1. Descripción textual del flujo principal y flujos alternativos ................................67<br />
5.3.2. Formalización de la descripción de casos de uso ................................................68<br />
6. ANÁLISIS......................................................................................................................................70<br />
6.1. ANÁLISIS DE LOS CASOS DE USO .....................................................................................71<br />
6.1.1. Caso de uso Abrir documento ..............................................................................71<br />
6.1.2. Caso de uso Generar Java2XML .........................................................................72<br />
6.2. DIAGRAMA DE PAQUETES ...............................................................................................73<br />
7. DISEÑO .........................................................................................................................................74<br />
7.1. DISEÑO DE LA INTERFAZ.................................................................................................75<br />
7.1.1. Obtención de los parámetros de configuración ...................................................76<br />
7.2. DISEÑO DE LA GENERACIÓN DE LOS DOCUMENTOS.........................................................78<br />
7.3. DISEÑO DE LA SERIALIZACIÓN Y DESERIALIZACIÓN........................................................80<br />
7.4. ARQUITECTURA <strong>DEL</strong> SISTEMA.........................................................................................82<br />
7.5. DISTRIBUCIÓN EN PAQUETES ..........................................................................................83<br />
8. IMPLEMENTACIÓN Y PRUEBAS...........................................................................................84<br />
8.1. RELACIÓN DE APROXIMACIONES UTILIZADAS EN LA IMPLEMENTACIÓN .........................85<br />
8.2. PRUEBAS ........................................................................................................................87<br />
9. CONCLUSIONES Y TRABAJOS FUTUROS...........................................................................90<br />
9.1. PRINCIPALES LOGROS ALCANZADOS...............................................................................90<br />
9.2. TRABAJOS FUTUROS .......................................................................................................91<br />
9.2.1. Integración de SerXML como plugin para los entornos de desarrollo ................92
IV<br />
9.2.2. Utilización de toda la riqueza semántica ofrecida en el lenguaje J2SE 1.5.........92<br />
9.2.3. Uso de SerXML en diversos programas reales ....................................................92<br />
9.2.4. Utilizar la metaprogramación para realizar la serialización ..............................93<br />
BIBLIOGRAFÍA ................................................................................................................................94<br />
ANEXO A............................................................................................................................................96<br />
UTILIZACIÓN DE LA APLICACIÓN.................................................................................................96<br />
FICHERO DE CONFIGURACIÓN......................................................................................................98
V<br />
Índice de tablas<br />
Tabla 1 : Clase Person.java ............................................................................................ 10<br />
Tabla 2 : Objeto Person a serializar................................................................................ 11<br />
Tabla 3: Serialización obtenida con JSX........................................................................ 14<br />
Tabla 4: Serialización obtenida con Castor XML .......................................................... 16<br />
Tabla 5: Serialización obtenida con XStream ................................................................ 17<br />
Tabla 6: Serialización obtenida con JOX ....................................................................... 19<br />
Tabla 7: Serialización obtenida con Koala KOML ........................................................ 21<br />
Tabla 8: Tabla Comparativa. .......................................................................................... 23<br />
Tabla 9: Relación de páginas web con información acerca de las herramientas<br />
analizadas........................................................................................................24<br />
Tabla 10: Ejemplo de documento XML......................................................................... 34<br />
Tabla 11: Ejemplo de XML Schema .............................................................................. 37<br />
Tabla 12: Ejemplo de serialización de listas .................................................................. 55<br />
Tabla 13: Ejemplo de serialización maps....................................................................... 55<br />
Tabla 14: Caso de uso “Abrir documento”..................................................................... 67<br />
Tabla 15: Caso de uso “Generar Java2XML” ................................................................ 68<br />
Tabla 16: Métodos de la InterfazConfiguración............................................................. 77<br />
Tabla 17: Ejemplo clase de prueba (Mesa.java)............................................................. 89
VI<br />
Índice de ilustraciones<br />
Figura 1: Proceso de generación de los documentos........................................................ 4<br />
Figura 2: Referencia circular en el objeto Java .............................................................. 11<br />
Figura 3: Flujos de trabajo.............................................................................................. 27<br />
Figura 4: Proceso generación ProgramaJava.................................................................. 32<br />
Figura 5: Abrir clase Java............................................................................................... 39<br />
Figura 6: Insertar nombre de la clase Java ..................................................................... 40<br />
Figura 7: Clase Java abierta............................................................................................ 40<br />
Figura 8: Obtención del nombre del nodo raíz............................................................... 41<br />
Figura 9: Generación de los archivos Java2XML.java................................................... 42<br />
Figura 10: Generado DTD.............................................................................................. 42<br />
Figura 11: Generado XML Schema................................................................................ 43<br />
Figura 12: Guardando todos los documentos ................................................................. 43<br />
Figura 13: Diagrama de casos de uso – Manejo de la interfaz gráfica........................... 65<br />
Figura 14: Diagrama de casos de uso – Generación del documento para la<br />
serialización/deserialización ...........................................................................66<br />
Figura 15: Diagrama de casos de uso – Generación del documento DTD..................... 66<br />
Figura 16: Diagrama de casos de uso – Generación del documento XML Schema ...... 66<br />
Figura 17: Diagrama de Estado de la interfaz gráfica .................................................... 69<br />
Figura 18: Diagrama de colaboración – Flujo principal (abrir documento)................... 71<br />
Figura 19: Diagrama de colaboración – Flujo alternativo (abrir documento)................ 71<br />
Figura 20: Diagrama de colaboración – Flujo principal (generar Java2XML) .............. 72<br />
Figura 21: Diagrama de colaboración – Flujo alternativo I (generar Java2XML)......... 72<br />
Figura 22: Diagrama de colaboración – Flujo alternativo II (generar Java2XML)........ 72<br />
Figura 23: Diagrama de paquetes de análisis ................................................................. 73<br />
Figura 24: Diagrama de clases – Interfaz ....................................................................... 76<br />
Figura 25: Diagrama de clases – Generación de los documentos .................................. 79<br />
Figura 26: Diagrama de clases – Serialización/deserialización...................................... 80<br />
Figura 27: Arquitectura .................................................................................................. 82
Capítulo 1. INTRODUCCIÓN 1<br />
1<br />
Capítulo 1<br />
INTRODUCCIÓN<br />
Se entiende por Sistema de Gestión de Información al conjunto de recursos físicos<br />
(hardware) y lógicos (software), que conjuntamente dan soporte informático a unos<br />
datos y permiten el proceso o gestión de los mismos.<br />
En estos sistemas la información se encuentra principalmente en dos estados: en<br />
memoria y almacenada en disco. La información en memoria se procesa en el momento,<br />
y se hace mediante las instrucciones del lenguaje de programación en el que está<br />
desarrollado el sistema. La información se almacena en disco para su posterior uso,<br />
para su transmisión o para que sea compartida entre varios sistemas.<br />
A grandes rasgos dos son las formas posibles de almacenar la información en<br />
disco: en un sistema de base de datos o en uno o varios ficheros. Las bases de datos se<br />
usan cuando hay gran cantidad de información, con acceso concurrente de varios<br />
usuarios y gran potencia de búsqueda. Por otro lado, el almacenamiento en ficheros se<br />
usa cuando no se requiere el acceso concurrente a partes de la información y/o cuando<br />
no se requiere una forma centralizada de gestionar la información, sino que cada fichero<br />
ha de ser tratado individualmente.<br />
Es habitual que la información que se procesa en memoria se almacene en disco<br />
para ser compartida o para guardarla una vez finalizada la ejecución del sistema. Al<br />
proceso de almacenamiento de la información de la memoria en un fichero se le<br />
denomina serialización. Al proceso inverso, obtener la información de un fichero y<br />
cargarla en memoria, se le denomina deserialización.<br />
Un lenguaje que permite almacenar la información en ficheros de forma<br />
estructurada es XML (Extensible Markup Language) [1], [2], [3], [4], [5]. La estructura<br />
se basa en el uso de etiquetas dispuestas en forma de árbol y que han de cumplir una
Capítulo 1. INTRODUCCIÓN 2<br />
serie de reglas de validación. Además, los documentos en formato XML pueden ser<br />
editados directamente por el usuario usando un editor de textos. Se ha consolidado<br />
definitivamente como un lenguaje estándar de información. Para definir la estructura de<br />
la información, el modelo de contenido y los tipos de elementos y atributos dentro de un<br />
documento XML, se pueden utilizar lenguajes de definición de documentos como el<br />
XML Schema, o el lenguaje DTD. La tecnología XML está avalada por el Consorcio<br />
para la World Wide Web (W3C) [6].<br />
Por otro lado, uno de los lenguajes más utilizados actualmente es Java [7], [8], [9],<br />
[10], que es un lenguaje de programación Orientado a Objetos. Una de sus<br />
características es que nos ofrece una API estándar de serialización que permite guardar<br />
o transmitir la información representada con objetos que están en memoria.<br />
Dadas las ventajas de la tecnología XML, sería deseable utilizarla como formato<br />
de almacenamiento para programas Java. La API estándar de almacenamiento de Java<br />
tiene unas características que la hacen menos adecuada que XML en ciertas ocasiones:<br />
• Cuando se necesita que el fichero tenga un formato que sea comprensible<br />
por una persona usando cualquier aplicación de texto, es más adecuado<br />
utilizar XML, ya que la serialización de Java se almacena con un formato<br />
binario.<br />
• Cuando se necesita que el fichero tenga un formato que pueda ser tratado<br />
por un aplicación que no esta escrita en Java, es necesario un formato<br />
estándar como XML, ya que el formato de Java sólo es entendible por sus<br />
aplicaciones.<br />
• Cuando se necesita saber si el fichero tiene el formato adecuado, XML<br />
proporciona un sistema de validación del fichero; ya que su estructura<br />
queda definida en un DTD o XML Schema. En cambio, el formato de<br />
serialización de Java no ofrece esta validación hasta el momento de la<br />
recuperación de la información.<br />
Existen formas de serializar objetos Java mediante XML [11], [12], [13], [14],<br />
usando diferentes APIs. Para serializar objetos en XML básicamente se siguen los<br />
siguientes pasos: se obtiene el valor de cada uno de los atributos del objeto y se<br />
representa su valor entre una etiqueta XML. En caso de que el valor no sea de un tipo<br />
primitivo sino de un objeto, habrá que representar también en el documento todos los
Capítulo 1. INTRODUCCIÓN 3<br />
atributos de este objeto. El proceso de deserialización es el inverso, se va leyendo el<br />
documento XML y el valor de las etiquetas se ha de asignar a los atributos.<br />
Además, estos documentos tendrán una estructura que se corresponde con las<br />
clases que definen esos objetos; dicha estructura se puede representar en un DTD o en<br />
un XML Schema.<br />
El proceso de serialización es un proceso mecánico, por lo que es posible generar<br />
automáticamente el código necesario para obtener el documento XML. De esta forma,<br />
se puede mantener sincronizado el objeto Java y el DTD o XML Schema, eliminando al<br />
desarrollador de este trabajo mecánico y propenso a errores.<br />
La finalidad de este Proyecto Fin de Carrera es facilitar al programador el<br />
mantenimiento de esta sincronización. Para ello se quiere conseguir una herramienta<br />
que pueda obtener de manera automática y/o asistida la definición en XML Schema o<br />
DTD de esa información, además del código necesario para obtener la serialización en<br />
XML.<br />
El objetivo no se limita simplemen te a conseguir una persistencia en XML de<br />
objetos Java, sino que los documentos XML que representen la información orientada a<br />
objetos de estos objetos Java, aprovechen toda la riqueza semántica de la tecnología<br />
XML; es decir, que no existan etiquetas y/o sintaxis que hagan ver que el documento<br />
XML parte de una transformación desde código Java. Por ejemplo, al modelar un<br />
atributo de una clase que implementa la interfaz java.util.List de Java, no debería<br />
aparecer en el documento XML el nombre cualificado de la clase (java.util.List) ni nada<br />
que represente al código de Java, sino que se debería utilizar en XML varias etiquetas<br />
que representen la cardinalidad que ofrece XML Schema para conjuntos de elementos<br />
con la misma etiqueta.<br />
Actualmente existen muchas tecnologías de serialización de objetos Java en<br />
XML, algunas de las más representativas se estudian en el capítulo 2 del presente<br />
documento. La mayoría de estas tecnologías, sin embargo, no persiguen el objetivo de<br />
utilizar toda la riqueza semántica de lenguaje XML Schema, como se ha comentado,<br />
sino que simplemente utilizan el documento XML como medida de persistencia,<br />
haciendo explícito el origen de los datos desde Java. Este hecho puede dificultar tanto la<br />
transformación de esta información a otros lenguajes o sistemas, como la comprensión<br />
de dicha información ante el ojo humano.<br />
El proceso de generación de la serialización en XML y el XML Schema,<br />
aprovechando toda su riqueza semántica, no es un proceso trivial, con lo que será
Capítulo 1. INTRODUCCIÓN 4<br />
necesario en algún momento la ayuda del usuario para poder decidir la forma de<br />
representar ciertas construcciones de Java con XML Schema.<br />
En la Figura 1 se puede ver, de forma general, la aplicación que pretendemos<br />
desarrollar, denominada SerXML. Se procesará una clase de Java (Clase.java) para<br />
generar, tanto el documento XML Schema como el DTD (Clase.dtd y Clase.xsd).<br />
Además de estos documentos también, para esta clase y todas aquellas que intervengan<br />
en la serialización (ya sea como tipo de atributos, en las listas, etcétera), se crearán los<br />
documentos Clase2XML.java, donde la palabra Clase es el nombre de la clase que se<br />
serializa.<br />
Clase.dtd / Clase.xsd<br />
Clase.java<br />
SerXML<br />
Clase2XML.java<br />
Figura 1: Proceso de generación de los documentos<br />
Para serializar la clase (Clase.java) se incorporarán las clases Clases2XML.java<br />
mencionadas al proyecto Java donde se encuentra Clase.java. Estas clases incorporadas,<br />
ofrecerán la posibilidad de, mediante una serie de métodos, poder serializar un objeto de<br />
dicha clase o deserializar un documento XML obteniendo el objeto en el mismo estado<br />
en el que se había serializado.
Capítulo 1. INTRODUCCIÓN 5<br />
El resto del contenido de esta memoria se estructura en diferentes capítulos. En el<br />
capítulo 2 se realiza un estado del arte, analizando y comparando las herramientas más<br />
representativas que existen en el mercado para serializar objetos Java en XML, a través<br />
de distintos criterios de evaluación, pudiendo comprobar que ninguna satisface todos<br />
ellos y concluyendo con la necesidad de generar una nueva herramienta que cumpla<br />
todos los objetivos y criterios perseguidos. En el tercer capítulo se presenta la<br />
metodología seguida y se introducen conceptos básicos acerca de las tecnologías<br />
utilizadas en el desarrollo. En el capítulo 4 se ofrece un ejemplo de uso de la aplicación<br />
SerXML, haciendo un seguimiento paso a paso gráfico de le generación de los distintos<br />
documentos, intentando de esta manera facilitar la comprensión del resto de esta<br />
memoria. En el capítulo 5, se muestra la especificación de todos los requisitos que<br />
incorporará la aplicación, así como de algunos de sus casos de uso. En el capítulo sexto<br />
presenta el análisis realizado, donde se muestran los diagramas de análisis<br />
correspondientes a los casos de uso presentados en el capítulo anterior. El séptimo<br />
presenta el diseño de la aplicación SerXML, estructurado en diferentes puntos<br />
correspondientes a diferentes bloques de la aplicación, como son la interfaz gráfica y del<br />
fichero de configuración y las generaciones de los distintos documentos. El capítulo 8<br />
corresponde a la implementación y pruebas realizadas. Y por último, el capítulo 9<br />
dedicado a la conclusión, donde se presentan los objetivos y logros alcanzados y los<br />
distintos trabajos futuros. Para finalizar, la memoria contiene la bibliografía usada como<br />
libros, apuntes de asignaturas y referencias a páginas Web y un anexo donde se describe<br />
la forma de utilizar la herramienta desarrollada.
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 6<br />
2<br />
Capítulo 2<br />
<strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong><br />
La creación de este proyecto tiene como principal objetivo serializar objetos Java<br />
utilizando las ventajas que proporciona XML. Para dicha creación es interesante<br />
estudiar otros trabajos, proyectos o herramientas existentes relacionadas con la<br />
serialización en XML de objetos Java o de JavaBeans [16]. Entre los diferentes<br />
enfoques que se ofrecen, la serialización en XML que generan algunos de ellos se<br />
caracteriza por mantener mucha similitud con Java; es decir, existen etiquetas y<br />
atributos que hacen ver que el documento XML parte de una transformación desde<br />
código Java. Debido a esto se pierde una importante faceta del XML: su legibilidad y<br />
portabilidad. Otros, en cambio, intentan ser más independientes de Java, pero para ello<br />
necesitan de una gran cantidad de información y configuración para poder serializar.<br />
La herramienta que se pretende realizar en este Proyecto Fin de Carrera tiene<br />
como finalidad facilitar, en todo lo posible, el trabajo del desarrollador en el proceso de<br />
serialización en XML de objetos Java. Para ello, no será necesario el conocimiento<br />
previo de XML, siendo además posible la modificación de algún aspecto del documento<br />
XML por dicho desarrollador (por ser éste totalmente legible), a diferencia de la<br />
serialización que ofrece la API de Java (que se realiza mediante un flujo de bytes sólo<br />
comprensible para Java).<br />
En este capítulo, en primer lugar, se muestran una serie de criterios para la<br />
evaluación de este tipo de herramientas. A continuación, se presenta un estudio
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 7<br />
comparativo de dichas herramientas, observando su comportamiento para cada uno de<br />
los criterios. Finalmente, se presenta una breve conclusión acompañada con un resumen<br />
en forma de tabla con las principales características y el resultado obtenido para cada<br />
una ellas; así como las referencias a direcciones de Internet donde encontrar mayor<br />
información sobre las herramientas presentadas.<br />
2.1. Herramientas de Serialización en XML de objetos<br />
Java<br />
2.1.1. Criterios de evaluación de un serializador en XML de<br />
objetos Java<br />
Las herramientas de serialización de objetos Java en XML se pueden evaluar<br />
principalmente atendiendo a los siguientes aspectos:<br />
1. Características de las clases cuyos objetos se serializan: mediante este<br />
aspecto podemos comprobar si soporta cualquier tipo de clase Java; si han de<br />
tener alguna característica especial y cuál es esta; o, finalmente, si únicamente<br />
soporta JavaBeans. Las convenciones de formato son las siguientes:<br />
• Constructor sin argumentos.<br />
• No permitir campos públicos.<br />
• Atributos accesibles mediante métodos get/set/is.<br />
2. Dependencia del documento XML generado con Java: representa el grado<br />
de dependencia con Java que presenta el documento XML generado por la<br />
serialización. En el caso de que este grado sea alto, significa que el<br />
documento mantiene muchas etiquetas correspondientes de Java y, por ello,<br />
supone una mayor dificultad de lectura y comprensión, además de no tener la<br />
posibilidad de exportarlo a otros lenguajes. Si no existe tal dependencia, esto<br />
facilitará la portabilidad a otros lenguajes de programación y a otras<br />
arquitecturas que no utilicen Java.
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 8<br />
3. Posibilidad de configuración: con ello podemos especificar ciertos aspectos<br />
de la serialización que serían muy complicados de detectar por la herramienta.<br />
En cierta medida va relacionado con el aspecto anterior porque, en el caso de<br />
que no exista tal configuración, hay más posibilidad de dependencia con Java,<br />
ya que hay ciertas características de las clases Java que son ambiguas y no nos<br />
ofrecen toda la información necesaria para su serialización. Por ejemplo, no se<br />
puede obtener en tiempo de compilación las clases de los objetos que albergan<br />
las estructuras de datos que se describirán en el punto 5, ya que el código de<br />
una clase de Java no contiene esta información, que únicamente se puede<br />
obtener en tiempo de ejecución, por lo que es necesario obtenerlo mediante<br />
una cierta configuración.<br />
4. Soporta referencias circulares: un aspecto muy importante es que en los<br />
objetos a serializar, se nos ofrezca la posibilidad de referenciar, mediante los<br />
atributos, a objetos cuyas clases no pertenezcan a la API estándar de Java o a<br />
una API externa y de las cuales tenemos el código Java. En el caso de que<br />
esto no fuera soportado, nos restringiría totalmente la libertad de realizar<br />
clases de Java. Además, puede darse el caso de que algunos atributos de los<br />
objetos Java hagan referencia a otros objetos, y así sucesivamente, hasta<br />
cerrarse la referencia con el objeto inicial (referencia circular) formando<br />
grafos de objetos.<br />
5. Soporta estructura de datos: algo que ha de soportar toda serialización son<br />
las estructuras de objetos pertenecientes al Collection Framework [17] de<br />
Java. Es una característica muy común y que se suele utilizar mucho en todos<br />
los objetos Java. Las estructuras de datos que ofrece el Collection Framework<br />
de Java son las siguientes interfaces:<br />
• java.util.List<br />
• java.util.Map<br />
• java.util.Set<br />
6. Construye DTD y/o XML Schema: algunas herramientas ofrecen la<br />
posibilidad de crear un DTD y/o XML Schema de la clase del objeto que se<br />
va a serializar y, con ello, permiten validar el documento XML creado en la<br />
serialización de un objeto de dicha clase.
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 9<br />
7. Tecnología que emplea para leer XML: en el proceso de deserialización en<br />
el que se lee el documento XML para transformarlo en un objeto Java, se<br />
pueden utilizar distintas APIs para el procesado de este XML. Las más<br />
conocidas son SAX [18] y DOM, aunque algunas herramientas puedan<br />
utilizar APIs propias.<br />
2.1.2. Estudio comparativo<br />
Para comparar las características de las herramientas, se ha utilizado siempre la<br />
misma clase: Person.java. Esta clase contiene tanto atributos públicos como privados,<br />
de tipos primitivos y de clases de la API estándar de Java de las que no tenemos el<br />
código fuente. También tiene un constructor sin parámetros y otro con un parámetro, así<br />
como métodos get y set, pero no para todos los atributos, para así poder comprobar<br />
como se comportan las herramientas a evaluar en distintas situaciones. En la Tabla 1 se<br />
muestra la clase que se acaba de comentar.<br />
import java.util.Date;<br />
import java.util.ArrayList;<br />
public class Person {<br />
private String nombre;<br />
public int peso;<br />
public Boolean casado;<br />
private Date cumple;<br />
//Es un ArrayList de la clase Person<br />
private ArrayList amigos;<br />
public Person() {<br />
}<br />
public Person(String nombre) {<br />
this.nombre = nombre;<br />
}<br />
public String getNombre() {<br />
return nombre;
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 10<br />
}<br />
public void setNombre(String string) {<br />
nombre = string;<br />
}<br />
public ArrayList getAmigos() {<br />
return amigos;<br />
}<br />
public void setAmigos(ArrayList list) {<br />
amigos = list;<br />
}<br />
public Date getCumple() {<br />
return cumple;<br />
}<br />
public void setCumple(Date date) {<br />
cumple = date;<br />
}<br />
}<br />
Tabla 1 : Clase Person.java<br />
Se ha utilizado otra clase (Prueba.java) que es ejecutable, para poder realizar las<br />
pruebas de serialización y guardarlas en fichero. Mediante esta clase se ha utilizado un<br />
objeto de la clase anterior (Person.java), con referencias a otro objeto Person, pero que<br />
a su vez hace referencia al objeto original, por lo que se produce referencia circular,<br />
siendo esta característica la más “delicada” a la hora de serializar.<br />
El objeto al que se hace mención se presenta a continuación en la Tabla 2, y el<br />
grafo cíclico del objeto se muestra en la Figura 2.<br />
Person personVane = new Person("Vane");<br />
personVane.peso = 50;<br />
personVane.casado = new Boolean(false);<br />
personVane.setCumple(new Date(1979, 5, 9));<br />
Person personMauri = new Person("Mauri");<br />
personMauri.peso = 80;
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 11<br />
personMauri.setCumple(new Date(1979,5,12));<br />
Person personSergio = new Person("Sergio");<br />
personSergio.peso = 75;<br />
personSergio.setCumple(new Date(1979,8,3));<br />
ArrayList amigosSergio = new ArrayList();<br />
amigosSergio.add(personVane);<br />
personSergio.setAmigos(amigosSergio);<br />
ArrayList amigosVane = new ArrayList();<br />
amigosVane.add(personMauri);<br />
amigosVane.add(personSergio);<br />
personVane.setAmigos(amigosVane);<br />
Tabla 2 : Objeto Person a serializar<br />
personSergio<br />
personVane<br />
personMauri<br />
Figura 2: Referencia circular en el objeto Java<br />
La clase Person.java, junto con un objeto de la misma, se han realizado teniendo<br />
en cuenta las características expuestas en el apartado 2.1.1., pudiéndose comprobar cada<br />
uno de los aspectos descritos en ella.<br />
A continuación se muestran las herramientas más representativas para la<br />
serialización en XML de objetos Java, junto con una breve descripción de las mismas y<br />
de los resultados obtenidos para cada una de las características comentadas<br />
anteriormente. Destacar, por último, que también se incluye el documento XML<br />
generado tras la serialización.
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 12<br />
2.1.2.1. JSX 2.2.3.2<br />
Esta herramienta permite almacenar objetos Java en un fichero, para poder leerlo<br />
más tarde y reproducir una copia del objeto original (deserialización).<br />
Características:<br />
1. Es capaz de serializar cualquier objeto de Java, tanto si tienen atributos<br />
públicos como privados, y realiza correctamente la serialización de listas.<br />
2. Se aprecia una clara influencia de Java en la serialización generada, por lo que<br />
su dependencia es alta. Ej: java.lang.String ó . En estos dos ejemplos observamos el resultado de la<br />
serialización de un String y de la clase Person, respectivamente. La influencia<br />
es clara, ya que en el primer ejemplo la serialización de un String no tendría<br />
que mostrar, en ningún momento, el paquete al que pertenece, serializándolo<br />
como una cadena de caracteres únicamente. En el segundo ejemplo se ha<br />
serializado una clase Java especificando claramente que proviene de una clase,<br />
hecho que dificultaría la portabilidad de la serialización generada a un<br />
programa que no comprendiera la programación orientada a objetos.<br />
3. Las pocas posibilidades de configuración que tiene se centran en poder evitar<br />
incluir algún atributo u objeto en la serialización, por motivos diversos como<br />
puede ser la seguridad.<br />
4. Soporta tanto referencias a otras clases como referencias circulares, ya que<br />
serializa un grafo dirigido de objetos y, para ello, utiliza identificadores como<br />
atributo de los elementos.<br />
5. Soporta sin problemas las listas de objetos, aunque el XML resultante no es<br />
claro, provocando así dificultad en su comprensión.<br />
6. No ofrece la posibilidad de generar el DTD o el XML Schema.<br />
7. La tecnología para la lectura del documento XML es propia de la herramienta.
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 13<br />
En la Tabla 3 se muestra parte (por ser excesivamente extenso) del resultado de la<br />
serialización.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 14<br />
… (Omitida el objeto Person de Mauri)<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
…(Omitido el objeto Date)<br />
<br />
…(Omitidas las declaraciones de las clases padres de ArrayList)<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
…(Omitidas clausulas de cierre de los elementos)<br />
<br />
Tabla 3: Serialización obtenida con JSX<br />
2.1.2.2. Castor XML 0.9.5.3<br />
Castor XML es una herramienta que permite mapear objetos tanto a documentos<br />
XML como a bases de datos relacionales. Tiene una funcionalidad muy amplia, por lo<br />
que para casos sencillos puede resultar excesivo.<br />
Características:<br />
1. Únicamente es capaz de serializar objetos de Java cuyas clases sean<br />
JavaBeans, esto se ha podido comprobar en el serialización del ejemplo, en la<br />
que sólo ha añadido aquellos atributos que tuvieran set y get (tomando el<br />
nombre para el elemento XML a partir de estos métodos); los atributos
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 15<br />
públicos no los ha incluido. Además únicamente ha soportado el constructor<br />
público por defecto (sin argumentos). Estructuras, todas ellas, que<br />
corresponden a las convenciones de formato de los JavaBeans.<br />
2. Se aprecia alguna influencia de Java en la serialización generada, pero en una<br />
mucho menor medida que en el caso anterior. Ej.: xsi:type="Java:Person", en<br />
él se observa que ha serializado una clase introduciendo la palabra Java en<br />
ella.<br />
3. Tiene posibilidades de configuración, los cuales se realizan especificando<br />
determinadas propiedades en el archivo castor.properties (convenciones del<br />
nombre, especificar si los tipos primitivos son tratados como atributos o<br />
elementos, etcétera).<br />
4. Soporta referencias a otras clases pero no referencias circulares, ya que en<br />
nuestro ejemplo vemos claramente que no ha realizado bien la referencia,<br />
además de no mostrar ningún error al encontrarse con una.<br />
5. Soporta sin problemas las listas de objetos.<br />
6. Permite construir el XML Schema a partir de la clase Java y viceversa.<br />
7. Emplea tecnología propia para la lectura del documento XML a través de un<br />
modelo de objeto que representa la información.<br />
Muchas de las características explicadas se pueden apreciar en el resultado de la<br />
serialización del objeto de la clase Person con esta herramienta (Tabla 4).<br />
<br />
<br />
<br />
Mauri<br />
1979-06-09T00:00:00.000+02:00<br />
<br />
<br />
Sergio<br />
1979-09-03T00:00:00.000+02:00<br />
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 16<br />
Vane<br />
1979-10-13T00:00:00.000+02:00<br />
<br />
Tabla 4: Serialización obtenida con Castor XML<br />
2.1.2.3. XStream 1.0.2<br />
XStream es una simple librería que permite tanto pasar de documentos XML a<br />
objetos Java (de forma muy sencilla), como realizar el proceso inverso; es decir,<br />
serializar objetos Java en formato XML.<br />
Características<br />
1. Es capaz de serializar cualquier objeto Java; en nuestro ejemplo ha introducido<br />
correctamente todos los atributos del objeto sin distinguir la visibilidad ni la<br />
existencia de los métodos get y set, además de soportar cualquier tipo de<br />
constructor.<br />
2. Se ha podido comprobar que no incluye dependencia con Java de ningún tipo.<br />
3. No tiene la posibilidad de configurar la serialización.<br />
4. Soporta referencias a otras clases pero no referencias circulares, ya que en<br />
nuestro ejemplo vemos claramente que no ha realizado bien la referencia. En<br />
este caso, no da ningún error al encontrarse con una, pero en lugar de escribir<br />
correctamente la referencia pone lo siguiente:<br />
.<br />
5. Soporta sin problemas la serialización de listas de objetos con un resultado,<br />
además, muy comprensible.<br />
6. No es posible construir el DTD o el XML Schema.<br />
7. Emplea tecnología propia para la lectura del documento XML.
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 17<br />
El resultado de la serialización se muestra en la Tabla 5.<br />
<br />
<br />
<br />
1979-06-09 00:00:00.0 AM<br />
Mauri<br />
80<br />
<br />
<br />
<br />
<br />
<br />
1979-09-03 00:00:00.0 AM<br />
Sergio<br />
75<br />
<br />
<br />
false<br />
1979-10-13 00:00:00.0 AM<br />
Vane<br />
70<br />
<br />
Tabla 5: Serialización obtenida con XStream<br />
2.1.2.4. JOX 1.17<br />
Al igual que el resto de herramientas, que facilitan la transformación entre<br />
documentos XML y objetos Java, JOX, además, puede aceptar como entrada un DTD<br />
para escribir el documento XML valido.
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 18<br />
Características:<br />
1. Únicamente es capaz de serializar objetos Java cuyas clases sean JavaBeans,<br />
ya que para poder realizar la serialización necesita para todos los atributos sus<br />
métodos set y get, por lo que los atributos públicos que no presentaban estos<br />
métodos no han sido incluidos. Además de existir un constructor sin<br />
argumentos para que realice bien la serialización.<br />
2. Se aprecia alguna influencia de Java en la serialización generada pero en una<br />
mucho menor medida que en el caso de JSX. Ej.: ,<br />
se observa claramente la introducción de la palabra Java y<br />
class.<br />
3. No ofrece la posibilidad de configurar la serialización.<br />
4. Soporta referencias a otras clases pero no referencias circulares, ya que en<br />
nuestro ejemplo al encontrarse con una referencia circular ha fallado y<br />
finalizado bruscamente la ejecución. Por ello, ha sido necesario modificar la<br />
clase de Prueba para eliminar estas referencias. En la especificación de esta<br />
herramienta se comenta que si se usa DTD cuando se escriba el XML son<br />
posibles las referencias circulares.<br />
5. Soporta sin problemas la serialización de listas de objetos.<br />
6. No soporta la generación de DTD o XML Schema.<br />
7. Emplea SAX y DOM para la lectura del documento XML.<br />
El resultado de la serialización del objeto de la clase Person se puede ver en la<br />
Tabla 6.<br />
<br />
<br />
<br />
09-06-1979 00:00:00 CEST<br />
Mauri<br />
<br />
<br />
03-09-1979 00:00:00 CEST<br />
Sergio
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 19<br />
<br />
13-10-1979 00:00:00 CEST<br />
Vane<br />
<br />
Tabla 6: Serialización obtenida con JOX<br />
2.1.2.5. Koala KOML 1.21<br />
Es esta herramienta ha sido necesaria la modificación de las clases de prueba:<br />
Person.java y Prueba.java para poder obtener un documento correcto XML, ya que no<br />
finalizaba correctamente la ejecución. Se ha modificado para eliminar las listas y las<br />
referencias circulares que no lo soportaba.<br />
Características:<br />
1. Es capaz de serializar cualquier objeto de Java, incluso no tratándose de<br />
JavaBean, aunque con algunas restricciones, como por ejemplo, el<br />
impedimento de poner colecciones de objeto (listas).<br />
2. Se aprecia bastante influencia de Java en la serialización generada. Ej.: class<br />
name='java.lang.Boolean', donde la etiqueta java.lang.Boolean es claramente<br />
obtenido de la clase del objeto serializado.<br />
3. La serialización no es configurable con esta herramienta.<br />
4. Soporta referencias a otras clases pero no referencias circulares, ya que en<br />
nuestro ejemplo al encontrarse con una referencia circular ha fallado y<br />
finalizado la ejecución.<br />
5. No ha soportado la serialización de listas de objetos.<br />
6. Es posible construir XML Schema.<br />
7. Emplea SAX para la lectura del documento XML.<br />
la Tabla 7.<br />
El resultado de la serialización realizada mediante esta herramienta se muestra en<br />
<br />
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 20<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
70<br />
<br />
75<br />
<br />
<br />
<br />
60263388000000<br />
<br />
Sergio<br />
<br />
<br />
false<br />
<br />
<br />
60266844000000<br />
<br />
Vane
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 21<br />
<br />
<br />
Tabla 7: Serialización obtenida con Koala KOML<br />
2.2. Conclusiones<br />
El análisis realizado de las distintas herramientas revela que, en función de las<br />
necesidades de cada proyecto, se han desarrollado herramientas con unas características<br />
específicas. Sin embargo, en el desarrollo de una herramienta de serialización en XML,<br />
dicha serialización debería ser independiente a Java, ya que en caso contrario, se pierde<br />
toda la portabilidad y compresión que nos ofrece el lenguaje XML. Ante todo, es<br />
importante que soporte cualquier tipo de objeto Java y numerosas opciones de<br />
configuración.<br />
Además, es aconsejable que la tecnología empleada para procesar documentos<br />
XML sea SAX, debido, entre otros aspectos, a la poca utilización de memoria que<br />
necesita (a diferencia, por ejemplo, de la API DOM que carga todo el árbol del<br />
documento XML en memoria).<br />
En el estudio comparativo, se ha podido observar que la única que no soporta<br />
estructuras de datos en la serialización ha sido Koala KOML. En esta herramienta y en<br />
JOX ha sido necesario (debido a la interrupción brusca del programa) modificar las<br />
clases de prueba para poder obtener la serialización.<br />
Se ha podido observar que JSX utiliza identificadores para resolver las referencias<br />
circulares, además JOX sí que da la posibilidad de procesar estas referencias<br />
especificándolo en la DTD. A diferencia de las demás herramientas que no lo soportan.<br />
De todas las herramientas, en base a las características analizadas, las que mejores<br />
resultados han dado han sido JSX y XStream, la primera de ellas soporta referencias<br />
circulares sin necesidad de configurar la serialización, pero por el contrario, el<br />
documento XML generado es ilegible e incomprensible por cualquier persona que no<br />
entienda de XML o de Java, ya que es el que más dependencia ha mantenido con Java.<br />
El resultado de la serialización de la otra herramienta destacada es comprensible y<br />
fácilmente modificable (sin ninguna dependencia con Java), aunque no ha sido capaz de<br />
resolver las referencias circulares que se ha encontrado. En estas dos herramientas la<br />
tecnología empleada para procesar XML es propia, por lo que no se ha podido
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 22<br />
comprobar la utilización de memoria de la misma, además, aceptan cualquier tipo de<br />
objeto Java, lo que implica: que debe existir un constructor por defecto, que los<br />
atributos tengan una visibilidad determinada o que exista métodos get y set; facilitando<br />
de esta forma el trabajo al desarrollador.<br />
Por tanto, viendo las conclusiones obtenidas, ninguna de las herramientas<br />
satisface ampliamente todas las características deseables para una herramienta de<br />
serialización:<br />
1. Serializar cualquier característica de las clases de los objetos Java.<br />
2. No mostrar ninguna dependencia con el lenguaje Java.<br />
3. Dar distintas opciones de configuración.<br />
4. Soportar referencias circulares entre los objetos.<br />
5. Soportar cualquier estructura de datos de Java.<br />
6. Construcción tanto del DTD como del XML Schema.<br />
7. Utilización de SAX para la lectura del documento XML.<br />
De esta manera, surge la necesidad de desarrollar SerXML. En la que se ha<br />
querido soportar todos los criterios de evaluación comentados, para obtener una<br />
herramienta íntegra. Para ello, serán necesarias ciertas restricciones, como la existencia<br />
de un fichero de configuración para poder obtener aquellas opciones que son ambiguas<br />
en una clase Java. Por ejemplo, en el caso de las estructuras de datos en Java, es<br />
necesario saber las clases que manejan, ya que en tiempo de compilación no es posible.<br />
En este estudio del estado del arte, se ha observado que muchas herramientas no daban<br />
la posibilidad de configuración, limitando enormemente la serialización.<br />
Además, ninguna de ellas da la opción de generar el documento DTD, y pocas el<br />
XML Schema; la herramienta que se va a desarrollar va a permitir generar tanto uno<br />
como el otro, con las grandes ventajas que esto aporta a la validación de la serialización<br />
generada y, sus posteriores modificaciones realizadas por el usuario.<br />
La tecnología que se va ha emplear en la lectura de los documentos XML será<br />
SAX, que como ya se comentará en el capítulo siguiente, se caracteriza por su eficiencia<br />
y poca utilización de memoria, a diferencia de DOM que resulta menos eficiente con<br />
documentos extensos.<br />
Otra característica muy importante es la dependencia con Java del XML generado.<br />
Que como ya se ha comentado, XStream ha sido la única que no ha tenido tal
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 23<br />
dependencia; en la herramienta a desarrollar se tomará el ejemplo de esta aplicación y<br />
no se incluirá ninguna dependencia, aprovechando toda la potencia semántica que nos<br />
permite el lenguaje XML.<br />
En la Tabla 8 se muestra un resumen comparativo de las características para cada<br />
herramienta.<br />
Más información sobre cada una de las herramientas se puede obtener accediendo<br />
a las páginas web de la Tabla 9.<br />
Herramientas<br />
Características<br />
1. Características de<br />
las clases cuyos<br />
objetos se serializan<br />
2. Dependencia del<br />
XML generado con<br />
Java<br />
3. Posibilidad de<br />
configuración<br />
4. Soporta referencias<br />
circulares<br />
5. Soporta estructura<br />
de datos<br />
6. Construye DTD y/o<br />
XML Schema<br />
7. Tecnología que<br />
emplea para leer<br />
XML<br />
JSX<br />
2.2.3.2<br />
Cualquier<br />
objeto Java<br />
Castor<br />
XML<br />
0.9.5.3<br />
Sólo<br />
objetos<br />
JavaBean<br />
XStream<br />
1.0.2<br />
Cualquier<br />
objeto Java<br />
JOX 1.17<br />
Sólo<br />
objetos<br />
JavaBean<br />
Koala<br />
KOML<br />
1.21<br />
Cualquier<br />
objeto Java<br />
Muy alta Baja Ninguna Baja Alta<br />
Baja Media Ninguna Ninguna Ninguna<br />
Si No No No No<br />
Si Si Si Si No<br />
No<br />
XML<br />
Schema<br />
No<br />
Propia Propia Propia<br />
Tabla 8: Tabla Comparativa.<br />
No<br />
SAX y<br />
DOM<br />
XML<br />
Schema<br />
SAX
Capítulo 2. <strong>ESTADO</strong> <strong>DEL</strong> <strong>ARTE</strong> 24<br />
Herramientas<br />
JSX 2.2.3.2<br />
Castor XML 0.9.5.3<br />
Xstream 1.0.2<br />
JOX 1.17<br />
Koala KOML 1.21<br />
Referencias<br />
- http://jsx.org<br />
- http://www.castor.org<br />
- http://xstream.codehaus.org/<br />
- http://sourceforge.net/projects/jox<br />
- http://www.wutka.com/jox.html<br />
- http://koala.ilog.fr/koml/<br />
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<br />
3<br />
Capítulo 3<br />
METODOLOGÍAS Y TECNOLOGÍAS<br />
En el presente capítulo se va a justificar la metodología seguida en la definición e<br />
implementación de la herramienta desarrollada, así como las tecnologías software<br />
empleadas.<br />
3.1. Metodología<br />
La metodología elegida en la especificación, análisis, diseño e implementación del<br />
sistema ha sido la del Proceso Unificado de Desarrollo de Software (PUD), cuya<br />
descripción se muestra a continuación.<br />
3.1.1. PUD<br />
Se trata de una metodología para acometer el desarrollo de sistemas informáticos,<br />
propuesta por Ivar Jacobson, Grady Booch y James Rumbaugh.<br />
Se ha elegido principalmente por tres razones:<br />
• Se trata de un estándar avalado por OMG (Object Management Group),<br />
consorcio de alrededor de 800 miembros (compañías de la industria del<br />
software) que buscan el desarrollo de especificaciones que sean técnicamente<br />
excelentes, comercialmente viables e independientes del vendedor. OMG<br />
define object management como el desarrollo software que modela el mundo<br />
real mediante su representación como objetos. Estos objetos no son más que el
Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 26<br />
encapsulamiento de atributos, relaciones y métodos de componentes software<br />
identificables.<br />
• Recoge la experiencia de tres grandes metodologías anteriores:<br />
- OMT (Object Modeling Technique) de Rumbaugh.<br />
- OOAD (Object-Oriented Analysis and Design) de Booch.<br />
- Objectory de Jacobson.<br />
• Actualmente, se usa en la mayoría de las empresas para grandes proyectos y se<br />
imparte por muchas instituciones.<br />
El PUD es un proceso de desarrollo de software, definido como un conjunto de<br />
actividades necesarias para transformar los requisitos de un usuario en un sistema<br />
software. Sin embargo, el proceso unificado es más que un proceso de trabajo; es un<br />
marco de trabajo genérico que puede especializarse para una gran variedad de sistemas<br />
software, para diferentes áreas de aplicación, diferentes tipos de organizaciones y<br />
diferentes niveles de aptitud.<br />
El Proceso Unificado está basado en componentes y utiliza el Lenguaje Unificado<br />
de Modelado (Unified Modeling Language, UML) [19], [20], [21], [22].<br />
Está dirigido por casos de uso, porque con éstos se especifican las funcionalidades<br />
que el sistema proporciona al usuario. Los casos de uso representan los requisitos<br />
funcionales y fuerzan a pensar en términos de importancia para el usuario y no sólo en<br />
términos de funciones que serían bueno tener. Los casos de uso no sólo son una<br />
herramienta para especificar los requisitos del sistema, sino que también guían su<br />
diseño, implementación y prueba, es decir, guían el desarrollo software.<br />
El PUD está centrado en la arquitectura, pues la manera en que se organiza el<br />
sistema depende de los casos de uso clave y debe tener en cuenta la comprensibilidad, la<br />
facilidad de adaptación al cambio y la reutilización. Los casos de uso clave son aquéllos<br />
que dotan al sistema con la funcionalidad fundamental para los usuarios y, sin los<br />
cuales, los demás casos de uso no tienen sentido.
Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 27<br />
Es iterativo e incremental. El trabajo se divide en partes más pequeñas o llamadas<br />
iteraciones. En cada iteración se recorren los flujos de trabajo 1 y se obtiene una versión<br />
interna, ver Figura 3.<br />
Análisis<br />
Diseño<br />
Codific.<br />
Figura 3: Flujos de trabajo<br />
Pruebas e<br />
Integración<br />
En síntesis, en cada iteración se amplía el sistema con nuevos casos de uso, se<br />
identifican nuevos riesgos y se mitigan los ya conocidos. Las iteraciones se agrupan en<br />
fases, que por orden secuencial son las siguientes: inicio, elaboración, construcción y<br />
transición. Cada una centra sus esfuerzos más en unos flujos de trabajo que en otros. La<br />
etapa de inicio se centra en la captura de requisitos y el análisis. La etapa de elaboración<br />
lo hace en el análisis y el diseño. Las etapas de construcción y transición se centran en<br />
el diseño, implementación y pruebas.<br />
El trabajo de los requisitos se hace fundamentalmente durante la fase de inicio y la<br />
de elaboración. Durante la fase de inicio se identifican la mayoría de los casos de uso<br />
que delimitan el sistema y el alcance del proyecto, se detallan los más importantes<br />
(menos del 10 por ciento). Durante la fase de elaboración se capturan la mayoría de los<br />
requisitos restantes (el 80 por ciento). En la fase de construcción se capturan e<br />
implementan los requisitos que restan, mientras que en la fase de transición<br />
prácticamente no hay captura a menos que haya requisitos que cambien.<br />
Dadas las limitaciones de esta memoria, se van a presentar conjuntamente los<br />
requisitos obtenidos en las fases de inicio, elaboración y construcción. De la misma<br />
manera, los distintos modelos de casos de uso, modelos de análisis, clases, paquetes,<br />
modelos de despliegue, etcétera, de los flujos de trabajo de requisitos, análisis, diseño,<br />
1 Flujos de trabajo: Requisitos, análisis y diseño, implementación y pruebas. El modelado del<br />
negocio y la implantación no forman parte del desarrollo propiamente dicho. Un flujo de trabajo es un<br />
conjunto de actividades.
Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 28<br />
implementación y pruebas, se expondrán conjuntamente sin reflejar su evolución a<br />
través de las iteraciones.<br />
Debido a las dimensiones del proyecto, existen otras actividades de la<br />
metodología que no tienen cabida, como por ejemplo la gestión de los recursos<br />
humanos, ya que el autor de esta memoria asume todos los roles de un sistema:<br />
arquitecto, jefe de proyecto, analista, diseñador, etcétera. De la misma forma no se hará<br />
un control de versiones, ya que el desarrollo se corresponde con una primera versión.<br />
Tampoco se abordan actividades propias de los sistemas distribuidos como por ejemplo<br />
diagramas de despliegue, ya que no se trata de un sistema distribuido.<br />
3.2. Tecnologías software<br />
A continuación, se enumeran las tecnologías software empleadas en el desarrollo<br />
de este trabajo. En los siguientes párrafos se describen dichas tecnologías desde un<br />
punto de vista general y, posteriormente se presentan las características más relevantes<br />
de las herramientas concretas empleadas en la realización de este proyecto de fin de<br />
carrera:<br />
• Orientación a Objetos.<br />
• Java.<br />
• API JavaCET.<br />
• XML<br />
• DTD y XML Schema<br />
• SAX y DOM<br />
3.2.1. Orientación a objetos<br />
La orientación a objetos es el paradigma de programación más utilizado<br />
actualmente en el desarrollo de aplicaciones. Esto se debe a la existencia de lenguajes<br />
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<br />
usar, potentes, compatibles con muchas plataformas y, sobre todo, seguros y fáciles de<br />
depurar.<br />
El paradigma de programación orientada a objetos establece una asociación entre<br />
la información y las sentencias encargadas de gestionar dicha información. Desde un<br />
punto de vista de la programación procedimental, la orientación a objetos se puede ver<br />
como la asociación entre funciones y procedimientos a los tipos de datos que manejan.<br />
En programación orientada a objetos una clase es el conjunto formado por la<br />
definición de la estructura de la información y las sentencias que la gestionan. A los<br />
subprogramas que gestionan los datos, se les denomina métodos. A cada uno de los<br />
ítems de información que definen la estructura de la información se les denomina<br />
atributos o campos. En esta forma de organizar el código el módulo mínimo de<br />
programación es la clase.<br />
Cuando ejecutamos un programa orientado a objetos, a la entidad que tiene los<br />
valores de los ítems definidos en una clase se le denomina objeto.<br />
Además de esta organización del código existen primitivas de encapsulamiento,<br />
de forma que los atributos existentes en una clase quedan ocultos a los usuarios de esa<br />
clase. Para comunicar esa información se utilizan los métodos. Al conjunto de métodos<br />
de una clase que pueden ser usados por otras clases se le denomina interfaz pública.<br />
Las principales aportaciones de este paradigma al desarrollo de sistemas software<br />
son:<br />
• Herencia: característica que permite construir una clase (conocida como clase hija)<br />
basándose o teniendo como plantilla otra clase construida previamente (conocida<br />
como clase padre). Al utilizar una clase padre como base para definir una clase<br />
hija, los atributos y métodos definidos en la clase padre están disponibles en la<br />
clase hija. Es decir, los objetos de la clase hija tendrán valores para los atributos<br />
definidos en la clase hija y también tendrán valores para los atributos definidos en<br />
la clase padre. Esta característica permite una mayor reutilización del código, ya<br />
que si dos clases de un programa tienen ciertas características en común, se puede<br />
construir una clase que sea clase padre de las dos clases albergando los atributos y<br />
métodos que sean comunes a ambas.<br />
• Polimorfismo: característica de la programación orientada a objetos, muy<br />
relacionada con la herencia, que solventa un conjunto de problemas típicos que
Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 30<br />
aparecían en la programación procedimental. En multitud de aplicaciones es<br />
necesario gestionar información con distinta estructura de una forma homogénea.<br />
Por ejemplo, en un programa de diseño gráfico hay que gestionar figuras<br />
geométricas de distintos tipos como rectángulos, círculos, triángulos,... En algunos<br />
casos, estas figuras han de gestionarse de forma homogénea, si se quiere cambiar su<br />
color o moverlas por el área de dibujo. En otras ocasiones, cada tipo de figura<br />
tendrá que responder de una forma particular. Si se quiere calcular su área, para<br />
cada tipo de figura hay que usar una expresión distinta. Para tratarlas de forma<br />
homogénea, se crea una clase padre, llamada Figura. En esta clase se definen los<br />
métodos comunes a todas las figuras: cambiar el color o cambiar su posición. En<br />
cambio, el área no se puede definir de una forma común y, por tanto, cada uno de<br />
los tipos de figuras definen su propio método para el cálculo del área. En la clase<br />
padre hay que definir un método que no tiene implementación, llamado abstracto.<br />
La implementación de este método será establecido en cada una de las clases hijas<br />
que representan a cada tipo de figura.<br />
Si declaramos una variable de la clase Figura, puede contener objetos de cada una<br />
de las clases hijas. Cuando sobre el valor de esta variable se ejecuta el método de<br />
cálculo del área, se usa el polimorfismo y se ejecuta la implementación del método<br />
que corresponde a la clase concreta de la figura. Es decir, el código que se va a<br />
ejecutar cuando se llame a un método, depende de la clase del objeto concreto que<br />
reciba el mensaje y no de la clase de la variable en que se llame.<br />
3.2.2. Java<br />
El lenguaje de programación utilizado en el desarrollo de este proyecto ha sido<br />
Java. A continuación, se presentan algunas de las características que han llevado a la<br />
elección de este lenguaje:<br />
• Orientado a objetos: Java trabaja con sus datos como objetos y con interfaces a<br />
esos objetos. Soporta las características propias del paradigma de la orientación a<br />
objetos: abstracción, encapsulamiento, herencia y polimorfismo. Encaja<br />
perfectamente con el proceso unificado de desarrollo, visto anteriormente.
Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 31<br />
• Simple: Posee una curva de aprendizaje muy rápida. Ofrece toda la funcionalidad<br />
de un lenguaje potente, pero sin las características menos usadas y más confusas de<br />
éstos.<br />
• Robusto: Java realiza verificaciones en busca de problemas, tanto en tiempo de<br />
compilación como en tiempo de ejecución. La comprobación de tipos en Java ayuda<br />
a detectar errores lo antes posible, en el ciclo de desarrollo. Java obliga a la<br />
declaración explícita de los tipos de los ítems de información, reduciendo así las<br />
posibilidades de error. Maneja la memoria para eliminar las preocupaciones por<br />
parte del programador de la liberación o corrupción de la misma.<br />
• Portable: La indiferencia de la arquitectura representa sólo una parte de su<br />
portabilidad. Además, Java especifica los tamaños de sus tipos de datos básicos y el<br />
comportamiento de sus operadores aritméticos, de manera que los programas son<br />
iguales en todas las plataformas. Estas dos últimas características se conocen como<br />
la Máquina Virtual Java (JVM).<br />
• Orientado a aplicaciones: Dispone de muchas bibliotecas orientadas al desarrollo<br />
de múltiples aplicaciones, por ejemplo, existen librerías para gestionar bases de<br />
datos, para XML, gráficos, etcétera.<br />
3.2.3. API JavaCET<br />
La API JavaCET alberga un conjunto de clases que permiten analizar el código<br />
fuente de un programa escrito en Java y controlar su ejecución en otra máquina virtual.<br />
Esta API no tiene como objetivo gestionar el ciclo de desarrollo de una aplicación Java,<br />
sino que está preparada para gestionar código Java sin errores de compilación, que<br />
represente una aplicación correcta y permitiendo gestionar todos los aspectos de un<br />
programa escrito en el lenguaje de programación Java.<br />
Esta API representa un programa Java desde dos puntos de vista: su definición,<br />
formada por código y librerías; y su ejecución, la cual se puede ejecutar paso a paso,<br />
consultando el estado del sistema, o bien, permitiendo registrar una traza de la misma.<br />
Está definida e implementada también en lenguaje Java y sus principales ventajas son:
Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 32<br />
• Facilidad de comprensión y manejo.<br />
• Ortogonalidad al representar los conceptos.<br />
• Tratamiento integrado de la definición y la ejecución.<br />
JavaCET hace uso de los principios de la programación orientada a objetos, por<br />
otro lado, es independiente de la implementación, lo que permite que se puedan<br />
desarrollar implementaciones diferentes que obedezcan a distintos criterios.<br />
Como ejemplo de su funcionamiento, para poder analizar y gestionar el código<br />
fuente de un programa y su ejecución desde otro programa Java, existe la clase llamada<br />
ProgramaJava, que en su constructor recibe como parámetro el directorio donde se<br />
encuentran los ficheros fuente del programa Java, las librerías usadas y la ruta del SDK<br />
usado para compilar y ejecutar dicho programa. En dicho constructor se realiza todo el<br />
reconocimiento léxico, sintáctico y semántico de los ficheros fuente y toda esta<br />
información se guarda como atributos de dicho objeto en memoria. En la Figura 4 se<br />
muestra esta transformación.<br />
ClaseA.java<br />
ClaseB.java<br />
:ProgramaJava<br />
ClaseLibreriaA.class<br />
fuentes<br />
ClaseLibreriaC.class<br />
Libreria.jar<br />
librerías<br />
Analisis<br />
léxico<br />
sintáctico<br />
semántico<br />
C:\j2sdk1.4.2_01<br />
sdk<br />
ficheros fuente, librerias<br />
externas y librerias estándar<br />
que componen un programa java<br />
Proceso de<br />
reconocimiento<br />
Estructura de datos<br />
orientada a objetos que representa<br />
al programa java<br />
Figura 4: Proceso generación ProgramaJava.
Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 33<br />
3.2.4. XML<br />
XML o Lenguaje de Marcado Extensible (Extensible Markup Language), fue<br />
creado por el Consorcio para la World Wide Web en 1996 para superar las limitaciones<br />
de HTML (el Lenguaje de Marcado de HiperTexto que es la base para todas las páginas<br />
Web), ya que permite crear etiquetas propias. A pesar de que SGML ha sido usado<br />
durante décadas en la industria para publicación, su complejidad ha intimidado a mucha<br />
gente.<br />
La versión 1.0 de XML proporciona su especificación y los estándares adoptados.<br />
XML utiliza el conjunto de caracteres UNICODE, lo que permite su portabilidad entre<br />
sistemas y herramientas. UNICODE incluye los caracteres existentes en la mayoría de<br />
las lenguas que se utilizan en el mundo.<br />
A continuación se enumeran varias de las características más importantes de<br />
XML:<br />
• Separa el contenido de la presentación.<br />
• Asigna una estructura lógica a la información permitiendo crear un código más<br />
ligero.<br />
• Extensible.<br />
• Facilita el intercambio de documentos entre usuarios y aplicaciones.<br />
• Admite enlaces avanzados entre documentos.<br />
• Admite búsquedas avanzadas, consiguiendo búsquedas más rápidas.<br />
• Permite validar el contenido contra una gramática.<br />
• Da soporte a la Web semántica (extensión de la Web actual en la que el<br />
significado de la información queda bien-definido).<br />
• Es independiente de la plataforma sobre la que trabaja, con lo que simplifica el<br />
intercambio de datos.<br />
Hay dos tipos de documentos XML:
Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 34<br />
• Documento bien/mal formado: en el caso de que sigua las reglas de sintaxis<br />
definidas por la especificación XML el documento se considera bien formado,<br />
en el caso contrario es mal formado.<br />
• Documentos válidos/no válidos: si un documento bien formado sigue las<br />
reglas definidas en un DTD o esquema, ese documento es válido; en el caso de<br />
que no siga las reglas será no válido.<br />
En la Tabla 10 se muestra un ejemplo de documento XML en el que vemos que se<br />
puede asignar algún significado a las etiquetas en el documento; más importante aún,<br />
resulta fácil para una máquina procesar la información, ya que se puede extraer el<br />
código postal de un documento simplemente localizando el contenido rodeado por las<br />
etiquetas y , técnicamente conocido como el<br />
elemento “codigo-postal”.<br />
<br />
<br />
Mrs.<br />
<br />
Mary<br />
<br />
<br />
McGoon<br />
<br />
<br />
<br />
1401 Main Street<br />
<br />
Anytown<br />
NC<br />
<br />
34829<br />
<br />
<br />
Tabla 10: Ejemplo de documento XML<br />
3.2.5. SAX y DOM<br />
Para acceder al contenido de los documentos XML se puede utilizar alguna de las<br />
dos interfaces de programación más empleadas actualmente:<br />
• SAX: API Simple para XML
Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 35<br />
• DOM: Modelo de Objetos de Documento<br />
SAX y DOM utilizan dos enfoques muy diferentes. Ninguno de los dos enfoques<br />
ofrece soluciones para todos los casos que se pueden dar en las aplicaciones que<br />
trabajan con XML. Por tanto, se debe adoptar uno u otro dependiendo del caso<br />
particular del que se trate.<br />
SAX permite analizar documentos XML de forma secuencial, lo que permite que,<br />
aunque los documentos sean de gran tamaño, prácticamente no consuma memoria. Pero<br />
por otra parte, este tipo de procesamiento impide tener una visión global del documento<br />
por la que navegar.<br />
Un analizador que soporta esta interfaz recorre el documento XML que se está<br />
analizando de forma secuencial. Este analizador, según va detectando la ocurrencia de<br />
determinados eventos (comienzo/fin del documento, comienzo/fin de una etiqueta,<br />
etcétera), va realizando llamadas a funciones de retorno predefinidas. Son estas<br />
funciones de retorno en las que el programador introduce el código encargado de<br />
procesar los datos que contiene el documento XML.<br />
En cambio, DOM es una interfaz de programación que permite analizar y<br />
manipular dinámicamente, y de manera global, el contenido, el estilo y la estructura de<br />
un documento. Tiene su origen en el W3C.<br />
Para trabajar con un documento XML, primero se almacena en memoria en forma<br />
de árbol con nodos padre, nodos hijo y nodos finales, que son aquéllos que no tienen<br />
descendientes. En este modelo todas las estructuras de datos del documento XML se<br />
transforman en algún tipo de nodo, organizándose jerárquicamente en forma de árbol<br />
para representar la estructura descrita por el documento XML. Una vez creado el árbol<br />
en memoria, se van recorriendo los diferentes nodos y se analiza a qué tipo particular<br />
pertenecen. En función del tipo de nodo, la interfaz ofrece una serie de funcionalidades<br />
u otras para poder trabajar con la información que contienen.<br />
Para este proyecto, en el que se van a manejar documentos XML de diferentes<br />
tamaños, normalmente bastante grandes y complejos, es conveniente no cargarlos<br />
totalmente en memoria, ya que se reduciría enormemente la eficiencia. En este caso, la<br />
mejor herramienta para procesarlos es de manera secuencial mediante SAX, ya que para<br />
este proyecto no es necesario insertar, borrar, modificar,... estos documentos,<br />
únicamente es necesario su lectura.
Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 36<br />
3.2.6. DTD y XML Schema<br />
Actualmente hay dos tipos posibles de gramáticas:<br />
• DTD, Document Type Declaration<br />
• XML Schema<br />
DTD es un lenguaje de definición de documentos concebido para SGML<br />
(Standard Generalized Markup Language), se puede usar para definir el modelo de<br />
contenido y los tipos de elementos y atributos dentro de un documento. Sin embargo<br />
tiene ciertas limitaciones, como puede ser su sintaxis, el hecho de que no es XML, sino<br />
que es específica y poco clara y no soporta espacios de nombres; su tipado de datos es<br />
extremadamente limitado y sus únicas cardinalidades posibles: 0, 1, infinito.<br />
Por otra parte XML Schema, que al igual que las DTDs describe la estructura de<br />
la información, sí tiene sintaxis XML y ofrece nuevas características sobre las DTDs.<br />
Soporta el tipado de datos, importando todos los tipos de datos de los lenguajes<br />
convencionales y proveyendo al desarrollador de la posibilidad de crear los suyos<br />
propios. También soporta validación de espacios de nombres, de forma que pueden<br />
coexistir múltiples esquemas sin que haya conflictos de nombres entre ellos. Ofrece<br />
características de orientación a objetos. Permite una reutilización sencilla de código y<br />
presenta menor rigidez a la hora de definir cardinalidades para elementos.<br />
Las DTD son una solución parcial a una de las principales carencias de XML: la<br />
posibilidad de definir vocabularios de fabricación propia destinados a cubrir las<br />
necesidades particulares. Se prevé que las DTDs en pocos años desaparezcan o queden<br />
relegadas en un segundo plano, debido sobre todo al trabajo que se está llevando a cabo<br />
en los XML Schema y a todas las ventajas que presentan éstos sobre las DTDs.<br />
Para la aplicación que se va a desarrollar se ha apostado por dar la posibilidad de<br />
generar tanto DTD como XML Schema a partir de una clase Java; este documento<br />
generado con cualquiera de los dos lenguajes nos servirá para validar el fichero XML a<br />
obtener en la serialización, con lo que también aprovechar las posibilidades que ofrecen<br />
multitud de herramientas de edición XML.<br />
De este modo se tendrán dos opciones: crear un XML Schema o un DTD.<br />
A continuación en la Tabla 11 se muestra un ejemplo de un XML Schema.
Capítulo 3. METODOLOGÍAS Y TECNOLOGÍAS 37<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Tabla 11: Ejemplo de XML Schema
Capítulo 4. EJEMPLO DE USO 38<br />
4<br />
Capítulo 4<br />
EJEMPLO DE USO<br />
En este capítulo se va a simular una sesión con la herramienta desarrollada<br />
(SerXML). Lo que se pretende es hacer un seguimiento, paso a paso, del proceso de<br />
generación de los archivos para serializar/deserializar.<br />
Puede parecer que este capítulo rompe el orden lógico de la memoria, sin<br />
embargo, la idea es mostrar cómo es la herramienta cuyo desarrollo se explica en los<br />
siguientes capítulos. De esta forma, el lector puede obtener una idea global del resultado<br />
final, y el resto de la memoria le será más comprensible.<br />
Se irán enumerando distintos pasos a seguir en la edición de un documento, con<br />
sus respectivas pantallas y explicaciones. La interfaz ofrece diferentes caminos o formas<br />
de realizar una misma acción, por ejemplo a través de botones, opciones de menús o<br />
menús contextuales, etcétera. Este ejemplo de uso no se va a detener en contar todas las<br />
diferentes posibilidades, ya que eso se explicará en el siguiente capítulo. Una<br />
descripción más detallada de la aplicación, así como el formato del fichero de<br />
configuración se puede consultar en el Anexo A.<br />
1. Antes de abrir la clase Java, se ha de especificar el directorio o ruta donde se<br />
encuentra el Java SDK y, la ruta o directorio raíz del proyecto Java donde se<br />
encuentra la clase a abrir. Estas rutas se pueden especificar en las opciones<br />
“Especificar Ruta Java SDK” y “Especificar Ruta Proyecto” del menú<br />
“Opciones”, también, en el caso de no especificarse de esta forma y pulsar el botón<br />
“Abrir” o la opción “Abrir” del menú “Archivo” (Figura 5), se mostrarán las<br />
distintas ventanas donde seleccionar estos dos directorios. Los ficheros de<br />
configuración han de residir en el mismo directorio que las clases a las que
Capítulo 4. EJEMPLO DE USO 39<br />
corresponden, aunque es posible especificar un directorio distinto mediante la<br />
correspondiente opción en el menú “Opciones”, de esta forma el programa irá a<br />
buscarlas ahí<br />
Figura 5: Abrir clase Java<br />
Una vez especificados los directorios, el botón de apertura se encargará de<br />
preguntar el nombre de la clase, a partir de la cual, se quieren obtener todos los<br />
documentos, tal y como se puede ver en la Figura 6.<br />
El resultado de esta acción se muestra en la Figura 7, donde en el área de texto<br />
superior izquierdo se puede ver el contenido de la clase Java abierta; si ésta es<br />
correcta y no tiene errores de compilación, se activarán los tres botones de<br />
generación de documentos.
Capítulo 4. EJEMPLO DE USO 40<br />
Figura 6: Insertar nombre de la clase Java<br />
Figura 7: Clase Java abierta
Capítulo 4. EJEMPLO DE USO 41<br />
2. Generar los documentos necesarios para serializar/deserializar, pulsando el botón<br />
“Generar Java2XML” o seleccionando la opción “Generar archivos Java2XML”<br />
del menú “Generar”. Únicamente en el caso de que existan referencias circulares,<br />
se preguntará al usuario el nombre del nodo raíz, tal y como se puede apreciar en la<br />
Figura 8. Realizando esto, se generarán todos los documentos (necesarios para la<br />
serialización de la clase abierta), con el nombre Clase2XML, donde Clase es la<br />
clase que serializa. En la Figura 9 se observa el resultado de la ejecución de esta<br />
instrucción.<br />
Figura 8: Obtención del nombre del nodo raíz<br />
3. Generar el documento XML Schema, pulsando el botón “Generar XML Schema” o<br />
seleccionando la opción “Generar XML Schema” del menú “Generar”. Realizando<br />
esto, se generará el documento XML Schema correspondiente a la clase abierta. En<br />
la Figura 11 se observa el resultado de la ejecución de esta instrucción.<br />
4. Una vez generados todos los documentos, es posible guardarlos de distinta forma:<br />
seleccionando uno de la lista y eligiendo el directorio, guardándolos todos en un<br />
directorio elegido o guardándolos todos en el directorio de la clase abierta<br />
inicialmente. En la Figura 12 se puede observar el diálogo abierto una vez se pulsa<br />
el botón o la opción “Guardar Todo” del menú “Archivo”.
Capítulo 4. EJEMPLO DE USO 42<br />
Figura 9: Generación de los archivos Java2XML.java<br />
Figura 10: Generado DTD
Capítulo 4. EJEMPLO DE USO 43<br />
Figura 11: Generado XML Schema<br />
Figura 12: Guardando todos los documentos
Capítulo 4. EJEMPLO DE USO 44<br />
5. Finalmente, una vez guardados todos los documentos, en la Tabla 12 se observa el<br />
resultado de serializar un objeto de la clase Person.java (Tabla 1) que corresponde<br />
con el de la Tabla 2. Se puede apreciar, por un lado, cómo la serialización obtenida<br />
es totalmente independiente de Java y, por otro, la manera de resolver las<br />
referencias circulares, listas, etc.; además, es posible compararlo con los distintos<br />
resultados obtenidos en el capítulo dedicado al Estado del Arte (Capítulo 2), ya que<br />
se corresponde con el mismo ejemplo.<br />
<br />
<br />
Vane<br />
50<br />
false<br />
1979-06-09T00:00:00<br />
<br />
<br />
<br />
<br />
<br />
<br />
Mauri<br />
80<br />
1979-06-12T00:00:00<br />
<br />
<br />
Sergio<br />
75<br />
1979-09-03T00:00:00<br />
<br />
<br />
<br />
<br />
<br />
Tabla 12: Serialización ejemplo con SerXML
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 45<br />
5<br />
Capítulo 5<br />
ESPECIFICACIÓN DE REQUISITOS<br />
El objetivo de la captura de los requisitos es recopilar, clasificar e interpretar<br />
aquella información que debe ser registrada sobre el sistema y que el cliente espera<br />
como solución a sus necesidades, plasmándolo en requisitos claros, concretos y<br />
diferenciados. De esta manera, se mejora la calidad del software y la satisfacción del<br />
usuario, reduciendo los errores y el tiempo de desarrollo.<br />
El resultado de esta actividad es una lista clasificada en categorías, de todos y<br />
cada uno de los requisitos que el sistema debe satisfacer.<br />
Los desarrolladores de software profesionales habitualmente no crean código para<br />
sí mismos, sino para usuarios de software u otros desarrolladores. Los usuarios finales,<br />
con frecuencia, no saben cuáles son los requisitos ni tampoco cómo especificarlos de<br />
una forma precisa, con lo que es importante la tarea de especificar correctamente los<br />
requisitos para abarcar todas las necesidades de éstos. Sirviendo, por un lado al usuario,<br />
para conocer las características del sistema que va a recibir, y por otro lado al grupo de<br />
desarrollo, para el diseño y prueba del sistema.<br />
En este proyecto los clientes o usuarios son los integrantes del departamento y, en<br />
especial, los tutores de dicho proyecto, de esta forma se han podido establecer, mediante<br />
reuniones, los requisitos del sistema.<br />
En cuanto a los requisitos a considerar se pueden distinguir a grandes rasgos entre:<br />
funcionales, aquéllos que especifican las acciones que debe ser capaz de realizar el<br />
sistema; y no funcionales, aquéllos que especifican propiedades del sistema.<br />
La técnica inmediata para identificar los requisitos del sistema se basa en los casos<br />
de uso, los cuales capturan tanto los requisitos funcionales como los no funcionales, que
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 46<br />
son específicos de cada caso de uso. Por otra parte, están los requisitos adicionales, que<br />
son aquellos requisitos no funcionales que no se asocian a un caso de uso concreto.<br />
Un caso de uso especifica el comportamiento de un sistema o una parte del<br />
mismo, y es una descripción de un conjunto de secuencias de acciones, incluyendo<br />
variantes, que ejecuta un sistema para producir un resultado, de valor, observable por un<br />
actor (el cual representa a uno o más usuarios del sistema al que pertenece).<br />
En los siguientes apartados se describe de una forma general la herramienta y se<br />
especifican los requisitos según el estándar IEEE 830-1998. Posteriormente, dentro de<br />
este mismo capítulo, se realiza un estudio de los requisitos mediante la realización de<br />
diagramas de casos de uso y la formalización de dos de los más importantes.<br />
5.1. Descripción general<br />
5.1.1. Perspectiva del producto<br />
Interfaces del sistema<br />
La aplicación es totalmente independiente en cuanto a que no pertenece a ningún<br />
sistema complejo mayor que se sitúe por encima de él.<br />
Interfaces de usuario<br />
La aplicación dispondrá de una interfaz gráfica de usuario a través de la cual se<br />
podrá abrir una clase Java (que se situará en el área de texto de la parte izquierda) y<br />
generar el fichero Java, DTD o XML Schema a través de los menús o botones que se<br />
ofrecen. Una vez creados, se van añadiendo a una lista con todos los demás ficheros<br />
creados y, según la selección, se mostrarán en el área de texto de la parte derecha con la<br />
posibilidad de guardarlo en cualquier unidad.<br />
Interfaces hardware<br />
La aplicación se definirá teniendo en cuenta la tecnología Java. No se consideran<br />
requisitos software adicionales a los que impone la propia tecnología Java.
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 47<br />
Interfaces software<br />
La aplicación se definirá teniendo en cuenta la tecnología Java. No se consideran<br />
requisitos software adicionales a los que impone la propia tecnología Java.<br />
5.1.2. Funciones del producto<br />
Las principales funciones de la aplicación son abrir clase Java; crear una nueva<br />
clase Java, que se utilizará para serializar/deserializar en XML; crear la DTD y/o XML<br />
Schema; guardar la nueva clase Java y cerrar los documentos. En cuanto a la<br />
visualización del documento se muestran dos áreas de texto: la de la izquierda, con la<br />
clase Java abierta y la de la derecha, mostrando el documento seleccionado de una lista<br />
con los documentos generados, que está situada en la parte inferior izquierda.<br />
5.1.3. Características del usuario<br />
Los usuarios que usen la aplicación deberán conocer el lenguaje de programación<br />
Java. Además, si se desea manipular los ficheros XML, DTD o XML Schema, en caso<br />
de generarse, se deberán conocer sus distintos lenguajes a un nivel medio.<br />
5.2. Requisitos específicos<br />
5.2.1. Interfaces<br />
La aplicación se acoge al estándar tradicional de ventanas GUI. La interfaz gráfica<br />
de usuario (GUI, Graphical User Interface), es una alternativa moderna a la E/S por la<br />
terminal que permite a la aplicación comunicarse con su usuario. En una GUI se crea<br />
una aplicación de ventanas.
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 48<br />
5.2.1.1. Ventana de la aplicación<br />
La interfaz gráfica de la aplicación contiene los siguientes elementos:<br />
• Barra de título: con el nombre de la aplicación, llamada serXML, y con<br />
botones para minimizar, restaurar y cerrar la aplicación.<br />
• Barra de menú: con las siguientes opciones y submenús:<br />
o Archivo: opciones para manejar los documentos.<br />
• Abrir: abre una clase Java (después de introducir su nombre) y<br />
lo añade en el área de texto izquierdo. En el caso de que no se<br />
hubieran especificado las rutas de Java SDK y la ruta del<br />
proyecto (donde buscar esta clase), se preguntarán.<br />
• Guardar Seleccionado: guarda el documento seleccionado de la<br />
lista que está contenido en el área de texto derecho, en el<br />
directorio específico.<br />
• Guardar Todo: guarda todos los documentos generados en el<br />
directorio donde se encuentra la clase abierta.<br />
• Guardar Todo en…: guarda todos los documentos generados<br />
en el directorio seleccionado por el usuario.<br />
• Cerrar: cierra todos los documentos, tanto abiertos como<br />
generados.<br />
• Salir: cierra la aplicación.<br />
o Generar: opciones para las distintas generaciones de documentos a<br />
partir del fichero Java abierto.<br />
• Generar archivo Java2XML: genera la clase Java necesaria<br />
para la serialización/deserialización.<br />
• Generar DTD: genera el DTD correspondiente.<br />
• Generar XML Schema: genera el XML Schema.<br />
o Opciones: para especificar las rutas necesarias donde el programa<br />
obtendrá todas la clases y APIs necesarias.<br />
• Especificar Ruta Java SDK: especifica la ruta donde el<br />
programa ha de buscar el Java SDK.
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 49<br />
• Especificar Ruta Proyecto: especifica la ruta del directorio raíz<br />
donde se encuentra la clase para la cual se generarán los<br />
documentos.<br />
• Especificar Ruta Ficheros Configuración: especifica la ruta<br />
donde se encuentran los ficheros de configuración de todas las<br />
clases a procesar.<br />
o Ayuda: ayuda de la aplicación<br />
• Ayuda de SerXML: se muestra una ayuda para el manejo de la<br />
herramienta.<br />
• Acerca de: muestra información acerca de la aplicación.<br />
• Botones: con las mismas funcionalidades que sus correspondientes opciones<br />
de menú. Dispone de los siguientes botones por orden de aparición de<br />
izquierda a derecha y de arriba a abajo:<br />
o Abrir<br />
o Guardar Todo<br />
o Generar Java2XML<br />
o Generar DTD<br />
o Generar XML Schema<br />
• Vistas: la aplicación contiene dos áreas de texto verticales y una lista en la<br />
parte inferior izquierda.<br />
o Área de texto izquierda: vista de texto plano que presenta el contenido<br />
del documento abierto con anterioridad.<br />
o Área de texto derecha: vista de texto plano que presenta el contenido<br />
del documento seleccionado de la lista que se detalla a continuación.<br />
o Lista: vista con la lista de los documentos generados.<br />
5.2.1.2. Diálogos<br />
La aplicación presenta en su ejecución una serie de cuadros de diálogo para llevar<br />
a cabo distintas funcionalidades. Se presentan en las siguientes líneas de forma<br />
esquematizada:
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 50<br />
• Diálogo de apertura<br />
o Barra de título<br />
Contiene el texto “Seleccione Directorio de Java SDK” o “Selección<br />
Directorio Raíz del Proyecto (donde se encuentra la clase Java)” y un<br />
botón de cerrar ventana.<br />
o Descripción<br />
Muestra las distintas unidades de disco y directorios donde poder<br />
seleccionar un directorio.<br />
o Origen<br />
Aparece al seleccionar el usuario la opción “Especificar Ruta SDK” o<br />
“Especificar Ruta Proyecto” del menú “Opciones”, y en el caso de no<br />
haber introducido anteriormente estos datos, al seleccionar “Abrir” del<br />
menú “Archivo” o al pulsar el botón “Abrir”.<br />
o Formato/organización de la ventana<br />
Dentro del marco principal de la ventana contiene, en la parte<br />
superior, el texto “Buscar en” junto con una lista desplegable, para<br />
seleccionar la unidad de disco o directorio donde se encuentra el<br />
directorio a abrir, y una serie de botones con opciones para navegar,<br />
crear y visualizar los distintos directorios. En el centro de la ventana<br />
presenta un área de texto, cuyo contenido es seleccionable, con una<br />
barra de desplazamiento horizontal (en caso de ser necesaria) donde se<br />
muestran todas las carpetas dentro de la unidad o carpeta seleccionada<br />
anteriormente. En la parte inferior presenta un campo de texto donde<br />
aparecerá el nombre del directorio que se seleccione para su apertura;<br />
un campo con una lista desplegable indicando “Todos los<br />
documentos” y por último dos botones para confirmar (“Abrir”) o<br />
cancelar (“Cancelar”) la operación.<br />
• Diálogo de guardar<br />
o Barra de título<br />
Contiene el texto “Guardar Archivo” o “Guardar Todo en…<br />
(seleccione directorio)” y un botón de cerrar ventana.<br />
o Descripción
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 51<br />
Muestra las distintas unidades de disco y directorios donde poder<br />
guardar un documento o clase Java, o todos ellos.<br />
o Origen<br />
Aparece al seleccionar el usuario la opción “Guardar Seleccionado” o<br />
“Guardar Todo en…” del menú “Archivo”.<br />
o Formato/organización de la ventana<br />
Este diálogo, en cuanto a organización, es igual al de apertura, salvo<br />
cambios mínimos como el texto “Buscar en” que se sustituye por<br />
“Guardar en” y el propósito del diálogo simplemente.<br />
• Dialogo de entrada de datos<br />
o Barra de título<br />
Contiene el texto “SerXML” y un botón de cerrar ventana.<br />
o Descripción<br />
Presenta un texto descriptivo y un área donde introducir el nombre de<br />
la clase.<br />
o Origen<br />
Aparece al querer abrir una clase de Java para crear los documentos.<br />
o Formato/Organización de la ventana<br />
Dentro de la ventana contiene únicamente un icono de pregunta, junto<br />
con un mensaje y un área donde introducir el nombre de la clase Java<br />
a abrir, un botón “Aceptar” para confirmar y otro de “Cancelar” para<br />
anular la apertura.<br />
• Diálogo de error<br />
o Barra de título<br />
Contiene el texto “SerXML” y un botón de cerrar ventana.<br />
o Descripción<br />
Presenta un mensaje de error informando de la imposibilidad de<br />
realizar una acción determinada y por qué.<br />
o Origen<br />
Aparece al intentar realizar el usuario una acción concreta y no ser<br />
posible o al haberse encontrado con un error de algún tipo en la<br />
generación de alguno de los documentos.
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 52<br />
o Formato/Organización de la ventana<br />
Dentro de la ventana contiene únicamente un icono asociado al tipo de<br />
mensaje, en este caso de prohibición, junto con el mensaje informativo<br />
y un botón “Aceptar” para confirmar su lectura.<br />
• Diálogo de acerca de<br />
o Barra de título<br />
Contiene el texto “Acerca de SerXML” y un botón de cerrar ventana.<br />
o Descripción<br />
Muestra información general de la aplicación, como es su nombre,<br />
versión, desarrolladores, etcétera.<br />
o Origen<br />
Aparece al seleccionar la opción de menú “Acerca de”.<br />
o Formato/organización de la ventana<br />
Presenta la información típica de una ventana de estas características.<br />
En la parte inferior contiene un botón “Aceptar”.<br />
5.2.2. Requisitos funcionales<br />
Los requisitos funcionales definen qué debe hacer el sistema, incluyendo los<br />
requisitos relativos a la funcionalidad específica del sistema y los relativos a los<br />
servicios generales del sistema.<br />
Para este proyecto, los requisitos funcionales se pueden dividir en cinco bloques,<br />
tres son para el documento que generan:<br />
- Documento Java.<br />
- Documento DTD.<br />
- Documento XML Schema.<br />
Y de los otros dos, uno es para el manejo de la interfaz gráfica y el otro para el<br />
manejo del fichero de configuración.
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 53<br />
5.2.2.1. Requisitos para generar el documento Java para la<br />
serialización/deserialización<br />
REQ.FUN.1. – Generación de la clase Java para serializar<br />
Ofrecer la posibilidad de generar una clase Java que será utilizada para serializar<br />
un objeto Java en un documento en XML. Dicha clase tendrá el nombre de la<br />
clase del objeto Java a serializar más 2XML.java.<br />
REQ.FUN.1.1. – Contener el método toXML<br />
Contener la clase Java a generar el método: toXML, dando la posibilidad de,<br />
con este método y pasándole como parámetros un objeto y un OutputStream,<br />
crear un documento XML correspondiente a la serialización del objeto anterior<br />
y devolverlo a través del flujo de salida (OutputStream).<br />
REQ.FUN.1.2. – Serializar todas las partes de una clase Java<br />
Mediante el fichero generado se serializarán todos los aspectos de la clase Java,<br />
así como de las clases que son atributos y así sucesivamente.<br />
REQ.FUN.1.2.1. – Independiente de Java<br />
La serialización generada será completamente independiente de Java, dando<br />
la posibilidad de exportarla a otros lenguajes de programación.<br />
REQ.FUN.1.2.2. – Serializar atributos<br />
Serializar los atributos de una clase como etiquetas XML.<br />
REQ.FUN.1.2.3. – Serializar el valor de los atributos como caracteres<br />
Serializar el valor del atributo del objeto como valor de la etiqueta<br />
especificado en el requisito REQ.FUN.1.2.2., para dicho atributo, se<br />
almacenará como caracteres.<br />
REQ.FUN.1.2.4. – No serializar los atributos nulos<br />
Los atributos cuyo valor todavía no haya sido inicializado y sean nulos, no<br />
se añadirán a la serialización, con lo que no se incluirá ninguna etiqueta<br />
XML para este.<br />
REQ.FUN.1.2.5. – Clases para la transformación a String<br />
Para clases importadas desde una API externa o de la API de Java, de las<br />
que no tenemos el código y que aparecen como tipos de atributos, será
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 54<br />
necesario que exista una clase Java con el nombre de dicha clase importada<br />
que se va a serializar más 2String, de la forma nombreClase2String.<br />
REQ.FUN.1.2.5.1. – Transformar a caracteres con el método toString<br />
Utilizar de la clase nombreClase2String, mencionada en el requisito<br />
padre (REQ.FUN.1.2.5.), el método toString. Mediante este método se<br />
transformará una clase, de la cual no tenemos el código (importada de<br />
otra API o de la API de Java), a String para poder insertarlo como valor<br />
de una etiqueta XML. A este método se le pasará como atributo un<br />
Object de la clase correspondiente, para poder devolver un<br />
java.lang.String.<br />
REQ.FUN.1.2.6. – Referencias entre clases mediante atributos (incluidas<br />
circulares)<br />
Aquellas referencias entre clases que quieran ser representadas mediante un<br />
atributo identificador en la etiqueta XML, se definirán en el fichero de<br />
configuración (REQ.FUN.1.2.7). Estas referencias serán necesarias en el<br />
caso de referencias circulares, y si éstas no existen, se tomará por defecto<br />
sin el atributo identificador, por lo que en caso de haber referencias se<br />
anidarán las etiquetas XML.<br />
Al identificar una referencia en un atributo a una determinada clase, se<br />
utilizará el fichero (al igual que en REQ.FUN.1) con el nombre de la clase<br />
de dicho atributo más 2XML. De esta forma se serializará el objeto de este<br />
atributo.<br />
REQ.FUN.1.2.7. – Serializar listas<br />
Serializar las listas de una clase como etiquetas XML, tantas como objetos<br />
tenga la lista. Dichas etiquetas tendrán el nombre de la clase que alberga la<br />
lista, y estarán incluidas en una etiqueta con el nombre del atributo de dicha<br />
lista. En la Tabla 13 se muestra un ejemplo, donde coches es el nombre del<br />
atributo y Coches el nombre de la clase que alberga la lista.<br />
Entenderemos como listas aquellas clases que implementan el interfaz<br />
java.util.List o java.util.Set.<br />
En el fichero de configuración será necesario especificar la clase de los<br />
objetos que va a albergar la lista.
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 55<br />
<br />
<br />
M-4567-CH<br />
<br />
…<br />
<br />
Tabla 13: Ejemplo de serialización de listas<br />
REQ.FUN.1.2.8. – Serializar maps<br />
Serializar las clases que implementan la interfaz java.util.Map, identificando<br />
cada par key/value dentro de una etiqueta denominada MapEntry, todas<br />
estas etiquetas MapEntry se incluirán dentro de una etiqueta XML con el<br />
nombre del atributo (cuya clase implementa la interfaz java.util.Map). Los<br />
pares key y value se serializarán como cualquier otro atributo cuyo tipo no<br />
sea primitivo.<br />
En la Tabla 14 se muestra un ejemplo en el que se puede ver su<br />
funcionamiento.<br />
<br />
<br />
<br />
M-4567-CH<br />
<br />
<br />
SEAT Leon<br />
<br />
<br />
<br />
…<br />
<br />
…<br />
<br />
Tabla 14: Ejemplo de serialización maps<br />
Será necesario especificar en el fichero de configuración la clase de los<br />
objetos que va a albergar tanto el key como el value.<br />
REQ.FUN.1.2.9. – Serializar tanto atributos privados como públicos<br />
Se deberán soportar tanto atributos públicos como no públicos. En el caso<br />
de encontrar un atributo que sea no público, deberá existir en la clase el<br />
método get seguido del nombre del atributo con la primera letra mayúscula<br />
(Ej.: para el atributo numLibros el método sería: getNumLibros()). Dicho<br />
método devolverá el valor del atributo.
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 56<br />
Esto no será necesario en el caso de que se vaya a integrar el código<br />
generado en la clase.<br />
REQ.FUN.2. – Generación de la clase Java para deserializar<br />
Dar la posibilidad de generar una clase Java que será utilizada para deserializar un<br />
objeto Java a partir de un documento XML, al igual que en el requisito<br />
REQ.FUN.1., la clase tendrá el nombre del objeto Java a deserializar junto con<br />
2XML.<br />
REQ.FUN.2.1. – Contener el método fromXML<br />
Contener la clase Java a generar el método fromXML, dando la posibilidad de,<br />
con este método y pasándole como parámetro un InputStream, devolver un<br />
objeto que corresponde a la deserialización del documento XML pasado<br />
mediante dicho flujo de entrada (InputStream).<br />
REQ.FUN.2.2. – Deserializar todas las etiquetas y atributos del documento XML<br />
Mediante el fichero generado se deserializarán todas las etiquetas y atributos<br />
del documento XML, a través del método comentado en REQ.FUN.2.1.<br />
REQ.FUN.2.2.1 – Etiquetas XML<br />
Mediante el nombre de la etiqueta se sabrá a qué atributo se hace referencia,<br />
y con el valor de dicha etiqueta asignar el valor al atributo anterior.<br />
REQ.FUN.2.2.2. – Atributos de las etiquetas XML<br />
El atributo en una etiqueta XML tiene la función de identificar el objeto al<br />
que representa la etiqueta para posibles referencias futuras, si estas<br />
referencias no existen, no se añadirá el atributo.<br />
REQ.FUN.2.2.3. – Atributos sin valor en el documento XML<br />
Aquellos atributos para los cuales no existan etiquetas en el documento<br />
XML tendrán valor nulo, de la misma forma que cuando se serializó.<br />
REQ.FUN.2.2.4. – Clases para la transformación desde String<br />
Para clases importadas desde una API externa o de la API de Java, de las<br />
que no tenemos el código y que aparecen como tipos de atributos, será<br />
necesario que exista una clase Java con el nombre de dicha clase importada<br />
que se va a serializar más 2String, de la forma nombreClase2String.
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 57<br />
REQ.FUN.2.2.4.2. – Transformar a caracteres con el método fromString<br />
Utilizar de la clase nombreClase2String, mencionada en el requisito<br />
padre (REQ.FUN.2.2.4.), el método fromString, pasándole como atributo<br />
un java.util.String (caracteres obtenidos del valor de la etiqueta XML),<br />
para poder devolver un objeto de la clase correspondiente.<br />
REQ.FUN.2.2.5. – Referencias entre clases mediante atributos (incluidas<br />
circulares)<br />
En el caso de encontrar una etiqueta XML que haga referencia a un atributo<br />
de otra clase de nuestro proyecto, se utilizará el fichero (al igual que en<br />
REQ.FUN.2) con el nombre de la clase de dicho atributo más 2XML. De<br />
esta forma se deserializará el objeto de este atributo.<br />
REQ.FUN.2.2.6. – Deserializar listas<br />
En el caso de obtener más de una etiqueta XML con el mismo nombre o que<br />
corresponda a la implementación de java.util.List, se procederá a crear el<br />
objeto añadiendo los objetos deserializados en cada etiqueta.<br />
REQ.FUN.2.2.7. – Deserializar maps<br />
Si hay más de una etiqueta XML que corresponde a una serialización de una<br />
clase que implementa la interfaz java.util.Map, se procederá a añadir todos<br />
los objetos mediante el key y value que están dentro de cada etiqueta<br />
MapEntry.<br />
REQ.FUN.2.2.8. – Deserializar tanto atributos privados como públicos.<br />
Se deberán soportar tanto atributos públicos como no públicos. En el caso<br />
de encontrar un objeto cuyo atributo sea no público, deberá existir en la<br />
clase el método set seguido del nombre del atributo con la primera letra<br />
mayúscula (Ej.: para el atributo numLibros el método sería: setNumLibros).<br />
A este método se le debe pasar como parámetro el valor del atributo.<br />
Esto no será necesario en el caso de que se vaya a integrar el código<br />
generado en la clase.<br />
REQ.FUN.2.3. – Utilizar SAX<br />
Para la lectura del documento XML se utilizará SAX, como ya se ha<br />
comentado en el presente documento en el capítulo 3 (apartado 3.2.5. SAX y<br />
DOM).
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 58<br />
REQ.FUN.3. – Fichero de configuración<br />
En caso de querer especificar alguna de las opciones a configurar en la<br />
serialización, será posible utilizar un fichero de configuración, los requisitos para<br />
este fichero se especifican en la sección: Requisitos para leer el documento de<br />
configuración de esta sección.<br />
5.2.2.2. Requisitos para generar el documento DTD<br />
REQ.FUN.4. – Generar DTD<br />
Dar la posibilidad de generar el documento DTD de la clase original Java<br />
transformando las distintas partes de ésta.<br />
5.2.2.3. Requisitos para generar el documento XML Schema<br />
REQ.FUN.5. – Generar XML Schema<br />
Dar la posibilidad de generar el documento XML Schema de la clase original Java<br />
transformando las distintas partes de ésta.<br />
5.2.2.4. Requisitos para el manejo del documento de configuración<br />
REQ.FUN.6. – Utilizar un documento de configuración<br />
A través de un documento de configuración, obtener especificadas claramente las<br />
opciones para la generación de los distintos documentos (Java, DTD y XML<br />
Schema). Acceder al documento de configuración mediante el nombre de la clase<br />
original más 2XML.config, de la forma: nombreClaseOriginal2XML.config.<br />
REQ.FUN.6.1. – Obtener de la configuración el constructor a utilizar para la<br />
deserialización (opcional)<br />
Tomar para la deserialización del objeto Java el constructor que se desea<br />
utilizar y los parámetros de entrada de éste, a los cuales se les asigna valor. Si<br />
no se encuentra esta opción en el documento, tomar el constructor por defecto<br />
(sin parámetros).
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 59<br />
REQ.FUN.6.2. – Obtener de la configuración si el documento generado será<br />
integrado o no en la clase Java original (opcional)<br />
En la configuración se especificará mediante la opción integrado. En el caso de<br />
querer introducir el código Java que se genera, a partir de la clase abierta,<br />
dentro de esta misma clase, sin la necesidad de generar otra nueva clase, esta<br />
opción tendrá el valor de si; y en el caso de querer generar una nueva clase de<br />
nombre: nombreClaseAbierta.java, donde introducir el código generado, el<br />
valor de integrado será no.<br />
REQ.FUN.6.3. – Obtener de la configuración las clases de los objetos que<br />
albergan los tipos java.util.List o java.util.Set (obligatorio)<br />
Para cada uno de los atributos que aparezcan en la clase abierta, que<br />
implementen la interfaz java.util.List o java.util.Set, obtener la clase Java de<br />
los objetos que albergan. Mostrar un mensaje de error en caso de no obtener tal<br />
configuración en el fichero.<br />
REQ.FUN.6.4. – Obtener de la configuración las clases o tipos para los tipos<br />
java.util.Map (obligatorio)<br />
Para cada uno de los atributos que aparezcan en la clase abierta, que<br />
implementen la interfaz java.util.Map, obtener la clase Java de los objetos que<br />
albergan, tanto para la clave como para su valor. Mostrar un mensaje de error<br />
en caso de no obtener tal configuración en el fichero.<br />
REQ.FUN.6.5. – Obtener de la configuración si la clase a procesar ha de soportar<br />
referencias circulares (opcional)<br />
Se podrá definir en el documento de configuración si la clase abierta ha de<br />
soportar referencias circulares, esto ocurre cuando desde otra clase algún<br />
atributo hace referencia circular sobre esta, en este caso se ha de especificar<br />
también el atributo a tener en cuenta en las referencias circulares.<br />
REQ.FUN.6.6. – Obtener de la configuración las referencias circulares existentes<br />
(opcional)<br />
Se podrá definir en el documento de configuración, aquellos atributos que<br />
realizan referencia circular hacia una clase que no pertenezca a la API estándar<br />
de Java o a una API externa (por lo que tenemos su código fuente que se<br />
encuentra en el proyecto). Además se tendrá que configurar la clase a la que<br />
hace referencia este atributo para que soporte la referencia circular.
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 60<br />
REQ.FUN.6.7. – Obtener de la configuración el paquete donde residen las clases<br />
para transformar las clases a String (opcional)<br />
En el documento se podrá identificar el paquete donde residen las clases para<br />
transformar las clases importadas de Java a y desde String (requisitos<br />
REQ.FUN.2.2.4 y REQ.FUN.1.2.5.)<br />
REQ.FUN.6.8. – Obtener de la configuración el paquete donde residirá la clase<br />
(opcional)<br />
En el documento se podrá identificar el paquete donde residirá la clase<br />
Java2XML a generar (requisito REQ.FUN.1.)<br />
5.2.2.5. Requisitos relativos al manejo de la interfaz<br />
REQ.FUN.7. – Abrir documento<br />
Ocurrirá cuando el usuario pulse el botón de abrir documento o seleccione la<br />
opción “Abrir” del menú “Archivo”. En el caso de no haber seleccionado la Ruta<br />
de Java SDK y/o la Ruta Raíz del Proyecto (donde se encuentra la clase a abrir),<br />
se preguntará mediante diálogos de apertura (ver apartado 5.2.1.2, para todas las<br />
referencias a diálogos). Una vez especificadas las rutas, se mostrará un diálogo de<br />
entrada de datos donde se especificará el nombre de la clase a abrir. Antes de abrir<br />
se comprobará que no tenga ningún error de compilación o no existe dicha clase,<br />
en el caso de que tuviera algún error, se avisará con un diálogo de error. Si todo es<br />
correcto, se añadirá al área de texto izquierdo, donde se podrá visualizar su<br />
contenido.<br />
REQ.FUN.8. – Guardar documento<br />
El usuario podrá seleccionar la opción “Guardar Seleccionado” del menú<br />
“Archivo”. Una vez se ejecuta esta acción, se procederá a guardar aquel<br />
documento que estuviera seleccionado en la lista de ficheros generados y<br />
apareciera en el área de texto derecha.<br />
REQ.FUN.9. – Guardar todo<br />
El usuario podrá seleccionar la opción “Guardar Todo” del menú “Archivo” o<br />
pulsar el botón con éste nombre. Una vez se ejecuta esta acción, se procederá a<br />
guardar todos los documentos con su correspondiente nombre, en el directorio<br />
donde se encuentra la clase inicialmente abierta.
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 61<br />
REQ.FUN.10. – Guardar todo en…<br />
El usuario podrá seleccionar la opción “Guardar Todo en…” del menú “Archivo”.<br />
Una vez se ejecuta esta acción, se procederá a guardar todos los documentos con<br />
su correspondiente nombre, en el directorio donde el usuario especifique mediante<br />
una diálogo de guardar.<br />
REQ.FUN.11. – Cerrar documento<br />
La aplicación cerrará el documento abierto y todos los documentos generados tras<br />
seleccionar la opción “Cerrar” del menú “Archivo”. Antes de cerrarlo, se<br />
inicializarán todas las variables del programa, se limpiarán las áreas de texto y la<br />
lista con los ficheros generados.<br />
REQ.FUN.12. – Generar Java2XML<br />
Mediante este botón se generarán todos los documentos necesarios para la<br />
serialización/deserialización, tanto de la clase abierta como de sus referencias a<br />
otras.<br />
REQ.FUN.13. – Generar DTD<br />
Generará mediante este botón el DTD correspondiente a la clase abierta.<br />
REQ.FUN.14. – Generar XML Schema<br />
Generará mediante a este botón el XML Schema correspondiente a la clase<br />
abierta.<br />
REQ.FUN.15. – Especificar ruta donde se encuentra el Java SDK<br />
Mostrará un diálogo de apertura, donde seleccionar el directorio donde se<br />
encuentra el Java SDK necesario.<br />
REQ.FUN.16. – Especificar ruta raíz del proyecto<br />
Mostrará un diálogo de apertura, donde seleccionar el directorio raíz del proyecto<br />
en el que se encuentra la clase a abrir.<br />
REQ.FUN.17. – Especificar ruta ficheros configuración<br />
Mostrará un diálogo de apertura, donde especificar la ruta en la que se encuentran<br />
los ficheros de configuración de todas las clases a procesar.<br />
REQ.FUN.18. – Listado de ficheros generados<br />
En la parte inferior izquierda aparecerá una lista con todos los ficheros generados<br />
(ya sean Java, dtd o xsd). Cada vez que se genere un fichero se añadirá a esta lista,<br />
y en cualquier momento se podrá seleccionar uno para ver su contenido reflejado<br />
en el área de texto derecho.
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 62<br />
REQ.FUN.19. – Área de texto izquierda.<br />
Este área de texto aparecerá en la parte superior izquierda y será posible ver la<br />
clase Java abierta.<br />
REQ.FUN.20. – Área de texto derecha<br />
En el área de texto de la parte derecha de la aplicación aparecerá el contenido del<br />
documento seleccionado en la lista.<br />
REQ.FUN.21. – Mostrar ayuda del manejo de la aplicación<br />
Cuando el usuario pulse la opción “Ayuda de SerXML” del menú “Ayuda”, se<br />
mostrará la información necesaria para la utilización de la aplicación<br />
REQ.FUN.22. – Mostrar información de la aplicación<br />
Una vez el usuario pulsa la opción “Acerca de” del menú “Ayuda”, se le mostrará,<br />
a través del diálogo de acerca de, información sobre de la aplicación.<br />
REQ.FUN.23. – Salir de la aplicación<br />
El usuario dispondrá de dos alternativas para cerrar la aplicación: pulsando el<br />
botón de cerrar de la barra de título o bien seleccionando la opción “Salir” del<br />
menú “Archivo”. En cualquier caso, todas las ventanas de la aplicación se<br />
cerrarán.<br />
5.2.3. Requisitos no funcionales<br />
Una vez especificados los requisitos funcionales del sistema, se especifican los no<br />
funcionales:<br />
5.2.3.1. Fiabilidad<br />
Estos requisitos establecen el tiempo medio entre fallos. Pueden especificar el<br />
tiempo mínimo aceptable así como categorías de fallos permitidos. También<br />
pueden especificar el grado de disponibilidad ante la ocurrencia de fallos en los<br />
componentes del sistema (tolerancia a fallos simples o múltiples).<br />
Para este proyecto no existen requisitos de esta clase.
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 63<br />
5.2.3.2. Documentación<br />
Estos requisitos definen condiciones específicas del proyecto para algún tipo de<br />
documento (por ejemplo, Guía de Usuario o Manual de Operación) además de las<br />
normas estándar de realización de proyectos.<br />
Para este proyecto se ha creado el presente documento, donde se explica<br />
claramente las distintas fases que se han seguido para la realización de dicho<br />
proyecto.<br />
5.2.3.3. Portabilidad<br />
Estos requisitos establecen la posibilidad de exportar la herramienta a otros<br />
sistemas o lenguajes.<br />
REQ.POR.1. Portabilidad de Java<br />
Al ser desarrollada la aplicación mediante Java, facilita la exportación de la<br />
aplicación a otras máquinas y/o sistemas operativos. Ha de ser necesario que<br />
esté disponible la máquina virtual de Java.<br />
REQ.POR.2. Portabilidad de XML<br />
Al realizarse la serialización mediante XML, facilita la exportación de los<br />
documentos generados en la serialización a otras aplicaciones (lenguajes de<br />
programación, procesador de texto,…), sistemas operativos y/o máquinas.<br />
5.2.3.4. Prestación<br />
Estos requisitos especifican valores numéricos para variables del sistema que se<br />
puedan medir (por ejemplo, capacidad, tiempo de respuesta, velocidad).<br />
Cada prestación corresponde a una constante numérica asociada a una función del<br />
sistema y se puede incluir en la especificación de cada función o en este apartado<br />
en sentencias separadas. Los requisitos no han de ser cualitativos sino<br />
cuantitativos (Ej.: respuesta en 10 segundos).<br />
Para este proyecto no existen requisitos de este tipo.
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 64<br />
5.2.3.5. Recursos<br />
Este tipo de requisito especifica restricciones sobre equipamiento hardware y<br />
software sobre el que debe funcionar el sistema. También se especifican los<br />
límites superiores de recursos físicos necesarios para el sistema, tales como<br />
potencia de proceso, memoria principal, espacio en disco, etc.<br />
REQ.REC.1. – Potencia de proceso<br />
La aplicación no necesita de una potencia de proceso elevada, únicamente la<br />
necesaria para poder manejar la máquina virtual de Java.<br />
REQ.REC.2. – Utilización de memoria<br />
La utilización de memoria queda limitada a las necesidades de la máquina<br />
virtual de Java.<br />
5.2.3.6. Seguridad<br />
Estos requisitos especifican condiciones de protección contra intrusismo,<br />
alteración de datos o alteración de las instalaciones. Especifican niveles de acceso,<br />
palabras de paso (password), inhibición de comandos, etc. También definen las<br />
condiciones de seguridad física y las operaciones de mantenimiento preventivo<br />
(backups, pruebas rutinarias, etcétera).<br />
Para este proyecto no existen requisitos de esta clase ya que no se maneja<br />
información importante.<br />
5.3. Diagramas de casos de uso<br />
En esta sección se presentan los distintos casos de uso que forman el sistema (de<br />
la Figura 13 a la Figura 16), que ayudan a una mayor comprensión de los requisitos<br />
descritos en los apartados anteriores.<br />
El primero de ellos es el manejo de la interfaz gráfica, pudiendo observar las<br />
distintas opciones que ofrece al usuario.<br />
En segundo lugar, aparecen 3 diagramas de casos de uso correspondientes a las<br />
distintas generaciones de documentos: generación de la clase Java para la serialización;
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 65<br />
generación del DTD y generación del XML Schema. En estos diagramas se pueden ver<br />
los distintos pasos que realiza la aplicación para obtener los documentos.<br />
Debido a las restricciones de tamaño de esta memoria, únicamente se describirán<br />
los casos de uso más representativos del sistema: Abrir documento y Generar<br />
Java2XML, incluyendo sus descripciones textuales del flujo principal y alternativo<br />
(apartado 5.3.1.). Uno de ellos especifica una funcionalidad del manejo de la interfaz<br />
gráfica y el otro pertenece a la funcionalidad de la generación del documento para la<br />
serialización y deserialización.<br />
Figura 13: Diagrama de casos de uso – Manejo de la interfaz gráfica
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 66<br />
Figura 14: Diagrama de casos de uso – Generación del documento para la<br />
serialización/deserialización<br />
Figura 15: Diagrama de casos de uso – Generación del documento DTD<br />
Figura 16: Diagrama de casos de uso – Generación del documento XML Schema
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 67<br />
5.3.1. Descripción textual del flujo principal y flujos<br />
alternativos<br />
A continuación, en la Tabla 15 y Tabla 16 se van a describir los flujos principales<br />
y alternativos de los casos de uso: Abrir documento y Generar Java2XML, en los que,<br />
además, se especifica una breve descripción, precondiciones, poscondiciones y actores<br />
que participan.<br />
Caso de Uso:<br />
Descripción:<br />
Actor iniciador:<br />
Actores secundarios:<br />
Precondiciones:<br />
Poscondiciones:<br />
Flujo de eventos:<br />
Prioridad:<br />
Estado de desarrollo:<br />
Flujos alternativos:<br />
Abrir documento<br />
El caso de uso se ejecuta cada vez que el usuario desea<br />
abrir un documento Java.<br />
Usuario.<br />
Ninguno.<br />
El usuario ha pulsado el botón de abrir documento de la<br />
aplicación o ha seleccionado la opción “Abrir” del<br />
menú “Archivo”.<br />
El documento Java abierto se añade al área de texto<br />
correspondiente.<br />
1. A través de un diálogo de entrada de datos, se<br />
introducirá el nombre de la clase a abrir.<br />
2. El usuario pulsa el botón “Aceptar” del cuadro del<br />
diálogo.<br />
3. Si el archivo que se quiere abrir no tiene errores de<br />
compilación entonces se abre el documento<br />
mostrando en el área de texto superior izquierda el<br />
contenido de éste.<br />
Alta<br />
Análisis<br />
3.1. Si el usuario pulsa el botón “Cancelar” no se abrirá<br />
la clase introducida.<br />
4.1. Si el documento que se desea abrir tiene errores de<br />
compilación, entonces no se abre, mostrando un<br />
diálogo de error para informar al usuario.<br />
Tabla 15: Caso de uso “Abrir documento”
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 68<br />
Caso de Uso:<br />
Descripción:<br />
Actor iniciador:<br />
Actores secundarios:<br />
Precondiciones:<br />
Poscondiciones:<br />
Flujo de eventos:<br />
Prioridad:<br />
Estado de desarrollo:<br />
Flujos alternativos:<br />
Generar Java2XML<br />
El caso de uso se ejecuta cada vez que el usuario desea<br />
generar las clases Java necesarias para la serialización y<br />
deserialización en XML.<br />
Usuario.<br />
Ninguno.<br />
El usuario ha abierto un documento Java anteriormente<br />
y ha pulsado el botón de “Generar Java2XML” de la<br />
aplicación o ha seleccionado la opción “Generar<br />
Java2XML” del menú “Generar”.<br />
La lista de documentos Java generados se añade a la<br />
lista situada en el marco inferior izquierdo.<br />
1. El sistema lee el archivo de configuración,<br />
obteniendo las opciones necesarias para la creación<br />
de las clases Java.<br />
2. Se genera las clases necesarias para la serialización<br />
y deserialización.<br />
Alta<br />
Análisis<br />
1.1. Si no se encuentra el archivo de configuración se<br />
cargan los valores por defecto.<br />
2.1. En el caso de encontrarse algún error en la<br />
generación de los documentos, se mostrará un<br />
diálogo de error para informar al usuario.<br />
Tabla 16: Caso de uso “Generar Java2XML”<br />
5.3.2. Formalización de la descripción de casos de uso<br />
Se pueden utilizar técnicas de modelado visual para describir los casos de uso,<br />
éstas ayudan a mejorar su comprensión y pueden ser:
Capítulo 5. ESPECIFICACIÓN DE REQUISITOS 69<br />
• Diagramas de estado, para describir los estados de los casos de uso y las<br />
transiciones entre éstos. Pueden asociarse a clases, casos de uso, o a<br />
sistemas completos.<br />
• Diagramas de actividad, para describir las transiciones entre estados con<br />
más detalle como secuencias de acciones.<br />
• Diagramas de interacción, para describir cómo interactúa una instancia de<br />
caso de uso con la instancia de un actor.<br />
Para este proyecto se presenta un diagrama de estado asociado a la interfaz gráfica<br />
del sistema, Figura 17.<br />
Figura 17: Diagrama de Estado de la interfaz gráfica
Capítulo 6. ANÁLISIS 70<br />
6<br />
Capítulo 6<br />
ANÁLISIS<br />
Durante este flujo de trabajo se analizan los requisitos que se describieron en la<br />
captura de requisitos, refinándolos y estructurándolos, y para ello se hace uso del<br />
modelo de análisis, que ofrece un mayor poder expresivo y una mayor formalización.<br />
El modelo de análisis es una jerarquía de paquetes de análisis que contienen clases<br />
de análisis y realizaciones de casos de uso. Para entender esta definición es necesario<br />
también definir: un paquete de análisis como el mecanismo para organizar los elementos<br />
del análisis; una clase de análisis como una abstracción de una o varias clases y/o<br />
subsistemas del diseño del sistema; una realización de caso de uso como una<br />
colaboración que describe cómo se lleva a cabo y se ejecuta un caso de uso<br />
determinado, en términos de las clases de análisis y de sus objetos de análisis en<br />
interacción.<br />
Las clases de análisis siempre encajan en uno de tres estereotipos básicos: de<br />
interfaz, de control o de entidad. Las clases de interfaz se utilizan para modelar la<br />
interacción entre el sistema y sus actores (es decir, usuarios y sistemas externos). Las<br />
clases de entidad se utilizan para modelar información que posee una larga vida y que es<br />
a menudo persistente. Por último, las clases de control representan coordinación,<br />
secuencia, transacciones y control de otros objetos, y se usan con frecuencia para<br />
encapsular el control de un caso de uso en concreto.<br />
En los siguientes apartados se presenta un análisis de algunos casos de uso y un<br />
diagrama de paquetes que ayuda a organizar lo analizado hasta el momento.
Capítulo 6. ANÁLISIS 71<br />
6.1. Análisis de los casos de uso<br />
A continuación, de la Figura 18 hasta la Figura 22, se presentan los diagramas de<br />
colaboración correspondientes a los casos de uso descritos en el capítulo anterior.<br />
6.1.1. Caso de uso Abrir documento<br />
Figura 18: Diagrama de colaboración – Flujo principal (abrir documento)<br />
Figura 19: Diagrama de colaboración – Flujo alternativo (abrir documento)
Capítulo 6. ANÁLISIS 72<br />
6.1.2. Caso de uso Generar Java2XML<br />
Figura 20: Diagrama de colaboración – Flujo principal (generar Java2XML)<br />
Figura 21: Diagrama de colaboración – Flujo alternativo I (generar Java2XML)<br />
Figura 22: Diagrama de colaboración – Flujo alternativo II (generar Java2XML)
Capítulo 6. ANÁLISIS 73<br />
6.2. Diagrama de paquetes<br />
Los paquetes de análisis proporcionan un medio para organizar los artefactos del<br />
modelo de análisis en piezas manejables. Un paquete de análisis puede constar de clases<br />
de análisis, de realizaciones de casos de uso y de otros paquetes de análisis.<br />
A continuación se presenta, en la Figura 23, un diagrama de paquetes que<br />
organiza algunas de las clases recapituladas hasta el momento.<br />
Figura 23: Diagrama de paquetes de análisis
Capítulo 7. DISEÑO 74<br />
7<br />
Capítulo 7<br />
DISEÑO<br />
En este capítulo se van a describir los diferentes aspectos que se han tenido en<br />
cuenta para diseñar la aplicación. En dicho diseño se modela el sistema y se encuentra<br />
su forma, incluida la arquitectura, para que soporte todos los requisitos especificados en<br />
el capítulo anterior. El resultado de este diseño es el modelo de clases que sirve como<br />
esquema para la implementación.<br />
El modelo de clases es un modelo que describe la realización física de los casos de<br />
uso centrándose en cómo los requisitos funcionales y no funcionales, junto con otras<br />
restricciones relacionadas con el entorno de implementación, tienen impacto en el<br />
sistema a considerar.<br />
En este capítulo no se va a definir ninguna implementación, sino que simplemente<br />
se van a determinar las interfaces que proporciona dicha implementación y, con ello,<br />
obtener los servicios de las mismas. Para la generación de dichas interfaces del diseño,<br />
se ha tenido que realizar varias iteraciones de las fases de elaboración y construcción,<br />
dentro del ciclo de vida. Aunque, debido al tamaño de este documento, únicamente se<br />
va a mostrar el resultado final de dichas iteraciones.<br />
En primer lugar, se va a especificar el diseño, mediante diagramas de clases,<br />
referente a la interfaz que la aplicación ofrece al usuario, más adelante se especificará el<br />
referente a la generación de los documentos, tanto los necesarios para la serialización<br />
(que los denominaremos Java2XML, ya que transforman un objeto Java a XML), como<br />
para la generación del DTD y el XML Schema. También se explica el diseño de las<br />
clases que son utilizadas para obtener la serialización y la deserialización una vez<br />
generados todos los documentos. Finalmente, se detalla la arquitectura del sistema.
Capítulo 7. DISEÑO 75<br />
7.1. Diseño de la interfaz<br />
Para la realización del diseño de esta parte de la aplicación se han tenido en cuenta<br />
los requisitos funcionales de la sección Requisitos relativos al manejo de la interfaz<br />
dentro del apartado 5.2.2.5.<br />
Se ha hecho uso, para el diseño de la interfaz, de la librería gráfica que ofrece<br />
Java: java.swing, la cual presenta muchas comodidades a la hora de construirla. Dentro<br />
de este paquete de Java se pueden observar numerosos componentes como: áreas de<br />
texto, listas, barras de desplazamiento, botones, diálogos, menús, frames, etc., que han<br />
sido de gran ayuda a la hora de desarrollar la aplicación.<br />
También, como ya se ha comentado en el capítulo 3, la clase Generador ha<br />
empleado la librería JavaCET, que permite el acceso detallado a cada una de las partes<br />
que componen un fichero fuente de Java (clase), un ejemplo de dichas partes son:<br />
• Atributos: nombre, tipo (incluyendo referencias a otras clases, listas,<br />
etcétera), visibilidad, …<br />
• Métodos: get y set.<br />
• Constructores que ofrece, etcétera.<br />
Gracias a la obtención de la estructura de la clase, es posible conocer<br />
completamente todos aquellos aspectos a serializar y, de esta forma, obtener una<br />
serialización completa y portable mediante XML.<br />
En la Figura 24 se puede observar como la clase SerXMLGrafico hace uso de la<br />
librería comentada, y también utiliza la clase ManejarFichero para generar los diálogos<br />
de abrir y guardar con sus correspondientes filtros, tanto de apertura como de guardado<br />
(FiltroFicheros).<br />
Además, mediante la clase Generador la aplicación obtiene los distintos<br />
documentos. El diagrama de las diferentes generaciones se podrá ver en el apartado 7.2.<br />
Se puede también apreciar en la Figura 24 como esta clase utiliza la interfaz<br />
InterfazConfiguracion, que se explica detalladamente en el apartado siguiente (7.1.1.<br />
Obtención de los parámetros de configuración).
Capítulo 7. DISEÑO 76<br />
Figura 24: Diagrama de clases – Interfaz<br />
7.1.1. Obtención de los parámetros de configuración<br />
Para la gestión de los parámetros de configuración se ha definido una interfaz<br />
(InterfazConfiguracion) que contiene los métodos que se muestran en la Tabla 17.<br />
public interface InterfazConfiguracion {<br />
public abstract void inicilizarConstructor();<br />
public abstract boolean perteneceConstructor(String nombre);<br />
public abstract boolean integrarCodigo();<br />
public abstract void vaciarConstructorParams();<br />
public abstract int getConstructor();<br />
public abstract boolean correspondeNumParams(int numParams);<br />
public abstract Vector getConstructorParams();<br />
public abstract String getClasefromLista(String nameLista);<br />
public abstract String getClaseCualifFromLista(String nameLista);<br />
public abstract boolean isLista(String nameAtributo);<br />
public abstract String getClaseKeyfromMap(String nameMap);<br />
public abstract String getClaseKeyCualifFromMap(String nameMap);<br />
public abstract String getClaseValuefromMap(String nameMap);
Capítulo 7. DISEÑO 77<br />
}<br />
public abstract String getClaseValueCualifFromMap(String nameMap);<br />
public abstract boolean isMap(String nameAtributo);<br />
public abstract String getPackage_class();<br />
public abstract String getPackageClases2String();<br />
public abstract Properties getProp();<br />
public abstract String getSoportarRefCirc();<br />
public abstract String refCircAtributo(String nameAtributo);<br />
Tabla 17: Métodos de la InterfazConfiguración<br />
Mediante esta interfaz se ofrece la posibilidad de obtener parámetros adicionales<br />
gracias a un fichero de configuración, que se ha diseñado teniendo en cuenta los<br />
requisitos funcionales de la sección Requisitos para el manejo del documento de<br />
configuración en el apartado 5.2.2.4., dicho fichero ofrecerá lo posibilidad de<br />
especificar diversas opciones, tales como:<br />
• El paquete al que pertenecerán las clases creadas, (opcional).<br />
• La clase cualificada de los objetos que alberga cada atributo cuya clase<br />
implementa la interfaz java.util.List o java.util.Set,(obligatorio).<br />
• Las clases cualificadas de los objetos (del key y del value), que alberga<br />
cada atributo, cuya clase implementa la interfaz Java.util.Map,<br />
(obligatorio).<br />
• La integración o no del código en la clase de los objetos a serializar,<br />
(opcional, por defecto no se integra).<br />
• La posición del constructor a utilizar para inicializar el objeto en la<br />
deserialización, al igual que los atributos que inicializa, (opcional, por<br />
defecto se toma el constructor sin parámetros).<br />
• Si la clase a procesar ha de soportar referencias circulares sobre ella.<br />
• Los atributos que intervienen en referencias circulares.<br />
• Paquete en el que aparecen las clases que transformarán las clases que<br />
pertenecen a la API de Java a String, (opcional).
Capítulo 7. DISEÑO 78<br />
7.2. Diseño de la generación de los documentos.<br />
En el diseño realizado para la generación de documentos se han utilizado los<br />
requisitos funcionales que aparecen en las secciones Requisitos para generar el<br />
documento Java para la serialización/deserialización (Java2XML), Requisitos para<br />
generar el documento DTD y Requisitos para generar el documento XML Schema,<br />
presentes en las secciones 5.2.2.1., 5.2.2.2. y 5.2.2.3. del anterior capítulo,<br />
respectivamente<br />
En la Figura 25 se puede comprobar que la clase Generador, también presente en<br />
el anterior diagrama, sirve de enlace entre la interfaz gráfica y la generación de los<br />
diferentes documentos. Mediante esta clase la aplicación genera los documentos, ya que<br />
se encarga de llamar a las correspondientes clases, según la petición de dicha interfaz,<br />
para generar uno u otro documento. Una vez la clase Generador ha obtenido los<br />
resultados, se plasman tanto en la lista gráfica como en las áreas de texto.<br />
Todas las clases que generan los diferentes documentos obtienen las opciones de<br />
configuración a través de Generador, así, por ejemplo, si aparece un atributo cuyo tipo<br />
es una clase que implementa la interfaz java.util.List, entonces necesitará obtener de la<br />
configuración la clase los objetos que van a ser insertados en dicha lista; con lo que, a<br />
través de la clase Generador, la clase JavaWriter obtendrá dicha opción de<br />
configuración (el nombre de la clase, cualificado).<br />
En el diagrama de la Figura 25 se puede observar que existen principalmente tres<br />
clases las cuales se utilizan para generar los tres tipos de documentos:<br />
• GeneradorJava2XM: clase encargada de generar un documento para la clase<br />
Java (que ha sido abierta y va ha ser serializada) mediante la clase JavaWriter.<br />
En el caso de ser necesario generar otra clase, porque existe algún atributo<br />
cuyo tipo es una clase que no pertenece al estándar de Java (con lo que<br />
proviene de la clase que va a ser serializada), entonces se volverá a llamar a la<br />
clase GeneradorJava2XML, que se encargará de generar la correspondiente<br />
clase Java2XML (donde Java es el nombre de la clase).<br />
La clase JavaWriter utiliza otras tres (ClaseSimple, ClaseList y ClaseMap):<br />
- la primera de ellas procesa todos los atributos en los que su tipo es<br />
primitivo o una clase que no pertenece al Collection Framework de<br />
Java; es decir, que contiene un único objeto.
Capítulo 7. DISEÑO 79<br />
- Mediante ClaseList se procesan los atributos cuyo tipo implementa la<br />
interfaz java.util.List o java.util.Set, y que contiene un conjunto de<br />
objetos, con lo que se ha deserializar mediante más de una etiqueta.<br />
- La última clase se utiliza para procesar los atributos cuyo tipo<br />
implementa la interfaz Java.util.Map, con lo que contiene más de un<br />
objeto y se serializa mediante más de una etiqueta, al igual que la clase<br />
anterior.<br />
• GeneradorDTD: se encarga de generar el documento DTD a partir de la clase<br />
abierta.<br />
• GeneradorXMLSchema: al igual que la anterior, a partir de la clase abierta<br />
genera el documento XML Schema.<br />
Figura 25: Diagrama de clases – Generación de los documentos
Capítulo 7. DISEÑO 80<br />
7.3. Diseño de la serialización y deserialización<br />
Una vez se han generado las clases necesarias para realizar la serialización<br />
(Java2XML.java, donde Java es el nombre de la clase), éstas se han de situar en un<br />
paquete del proyecto donde se va a proceder a la serialización del objeto. Una vez en<br />
ese paquete, es necesario que importen o estén en ese mismo paquete una serie de clases<br />
necesarias para la serialización (creación del documento XML), o deserialización<br />
(lectura del documento XML mediante SAX); además de las ya generadas.<br />
En la siguiente Figura 26 se observa el diagrama de clases correspondiente para<br />
serializar o deserializar. Para poder entender claramente éste, se ha de tener en cuenta<br />
que existen tres clases: Clase, UtilizaObjectsClase y Clase2XML, donde la palabra<br />
“Clase” depende de la clase del objeto que se va a serializar. Si por ejemplo tuviéramos<br />
que serializar una clase denominada Mesa, Clase sería Mesa y la clase Clase2XML sería<br />
Mesa2XML y, finalmente, la clase UtilizaObjectsClase se podría llamar de cualquier<br />
manera y sería aquella desde la que se instanciaría un objeto de la clase Mesa, y se<br />
serializaría o deserializaría mediante la utilización de los métodos estáticos toXML y<br />
fromXML de la clase Mesa2XML.<br />
Figura 26: Diagrama de clases – Serialización/deserialización
Capítulo 7. DISEÑO 81<br />
Para realizar la serialización, desde la clase UtilizaObjectsClase se llama al<br />
método estático toXML de la clase Clase2XML, a este método se le pasa como<br />
parámetros un objeto de la clase a serializar (Clase) y un flujo de salida donde se<br />
almacenará el documento XML a generar. La clase Clase2XML utilizará el XMLWriter<br />
para escribir las distintas etiquetas y atributos del XML con su valor. La clase<br />
XMLGeneralPersistenceManager será utilizada para serializar el contenido de una<br />
etiqueta XML (correspondiente a un objeto de una clase que no pertenece a la API<br />
estándar de Java o a otra API externa y de la que sí tenemos el código fuente de Java),<br />
delegándola a otra clase cuyo nombre será buscada mediante el nombre de la clase<br />
seguido por 2XML. Por ejemplo, si estamos serializando una clase Mesa mediante la<br />
clase Mesa2XML y, en un momento dado, nos encontramos con un atributo que alberga<br />
objetos de la clase Silla, entonces se buscará la clase Silla2XML para que, al delegar a<br />
esta, generase la serialización de su etiqueta.<br />
En el caso de la deserialización, desde la clase UtilizaObjectsClase se llama al<br />
método estático fromXML de la clase Clase2XML (Figura 26), este método devolverá el<br />
objeto de la clase correspondiente que proviene de la deserialización del documento<br />
XML, el cual se pasa como parámetro en un flujo de entrada. Para la lectura del<br />
documento XML se utiliza SAX, como ya se ha comentado, redefiniendo en la clase<br />
SAXParserManager los métodos startElement(…), endElement(…), characters(…), etc.<br />
que llamarán a los métodos con el mismo nombre de Clase2XML. De esta manera, para<br />
cada nueva aparición de una etiqueta se procesará como corresponda, almacenando su<br />
valor en el atributo correspondiente del objeto a deserializar.<br />
Al igual que en el caso de la serialización, si se obtiene una etiqueta XML de un<br />
atributo delegado en la serialización, se procederá a delegar (mediante el método<br />
delegateParsing(…)) la lectura del documento XML a la correspondiente clase<br />
Clase2XML (obtenida de la misma forma que en la serialización) de ese atributo. Al<br />
terminar su procesado, esta clase devolverá el control a la clase padre mediante la<br />
instrucción finishedParsing(), y el padre obtendrá el valor del objeto creado en la<br />
delegación mediante el método getObject(), para luego asignar el valor al atributo del<br />
objeto que estamos deserializando.<br />
Gracias a esta delegación del proceso, la serialización y deserialización se realizan<br />
de una forma más simple y estructurada, ya que se organizan por módulos que pueden<br />
ser utilizados en otras serializaciones donde intervengan las clases.
Capítulo 7. DISEÑO 82<br />
7.4. Arquitectura del sistema<br />
La arquitectura es un conjunto de decisiones significativas acerca de la<br />
organización de un sistema software, la selección de los elementos estructurales a partir<br />
de los cuales se compone el sistema, y las interfaces entre ellos, junto con el<br />
comportamiento.<br />
Se necesita la arquitectura para:<br />
• Comprender el sistema. Todos los que intervengan en el sistema deben<br />
comprenderlo.<br />
• Organizar el desarrollo. A más organización en el desarrollo, más<br />
comunicación entre los desarrolladores del proyecto.<br />
• Fomentar la reutilización. Una buena arquitectura ofrece a los desarrolladores<br />
un andamio estable sobre el que trabajar.<br />
• Hacer evolucionar el software. Todo sistema software evoluciona, por lo tanto<br />
debe ser fácil de modificar, y eso se consigue con una buena arquitectura.<br />
La arquitectura se desarrolla durante iteraciones, principalmente durante la fase de<br />
elaboración, donde su resultado final es una línea base de la arquitectura.<br />
La línea base es una versión interna del sistema, centrada en la descripción de la<br />
arquitectura, la cual debe mantenerse actualizada a lo largo de la vida del sistema para<br />
reflejar los cambios y adiciones relevantes para la arquitectura.<br />
Nuevamente y, debido a la limitación de tamaño de esta memoria, se presenta la<br />
arquitectura resultante, de manera muy simple (Figura 27), sin describir su evolución a<br />
través de las distintas iteraciones y flujos de trabajo.<br />
Figura 27: Arquitectura
Capítulo 7. DISEÑO 83<br />
7.5. Distribución en paquetes<br />
Para una mejor organización y estructuración de las clases, se han creado distintos<br />
paquetes y se han distribuido las clases en éstos, facilitando su modularidad al utilizar<br />
las estructuras definidas en el diseño:<br />
• interfaz.interfazGrafica: paquete donde se encuentran todas las clases e<br />
interfaces que son necesarios para crear la interfaz gráfica.<br />
• interfaz.interfazgenerador: paquete donde están las clases e interfaces<br />
para organizar la generación de todos los documentos.<br />
• generador.java2XML: paquete donde se encuentran todas las clases e<br />
interfaces necesarias para generar el documento para serializar.<br />
• generador.dtd: paquete donde se encuentran todas las clases e interfaces<br />
necesarias para generar el DTD.<br />
• generador.xmlSchema: paquete donde se encuentran todas las clases e<br />
interfaces necesarias para generar el XML Schema.
Capítulo 8. IMPLEMENTACIÓN Y PRUEBAS 84<br />
8<br />
Capítulo 8<br />
IMPLEMENTACIÓN Y PRUEBAS<br />
En el presente capítulo se van a explicar las distintas aproximaciones seguidas<br />
para realizar la completa implementación de la aplicación. Éstas han ayudado a<br />
disminuir la dificultad en la implementación y poder así avanzar de manera correcta en<br />
el desarrollo.<br />
La implementación de la aplicación SerXML ha producido 7103 líneas de código,<br />
distribuido en 35 clases organizadas en diferentes bloques dedicados a la creación de la<br />
interfaz, de los generadores y del procesador SAX para la serialización/deserialización.<br />
El lanzamiento de la aplicación hace uso de unos 26 MB de memoria. Durante la<br />
ejecución, este tamaño varía dependiendo del tamaño del proyecto donde se encuentra<br />
la clase abierta y de los documentos generados.<br />
Lo más destacable de este flujo de trabajo se resume en lo siguiente:<br />
• Se han respetado los paradigmas de: la programación orientada a objetos<br />
(abstracción, encapsulación, modularidad y jerarquía); de la programación<br />
orientada a eventos (cada componente reacciona ante los eventos producidos<br />
cuando el usuario interactúa con la aplicación, con métodos asociados para cada<br />
evento) y de la programación estructurada dentro de los métodos de las clases.<br />
• Se ha cuidado la codificación, las normas de estilo de la comunidad Java:<br />
nombres de clases comienzan en mayúsculas, nombres de variables y métodos<br />
en minúsculas,…<br />
• Sin disponer de las herramientas necesarias, se ha cuidado por parte del autor, el<br />
cumplir los umbrales recomendados por las métricas del software en cuanto al
Capítulo 8. IMPLEMENTACIÓN Y PRUEBAS 85<br />
tamaño de clases y métodos, relaciones entre clases, amplitud y profundidad de<br />
las jerarquías de herencia . . .<br />
• Existe un predominio de estructuras de clase y algoritmos de los métodos<br />
eminentemente recursivos, consiguiendo así una mayor limpieza de código.<br />
En los apartados siguientes se describen las distintas aproximaciones tomadas, se<br />
explican las pruebas realizadas y la manera de utilizar la herramienta de manera<br />
correcta.<br />
8.1. Relación de aproximaciones utilizadas en la<br />
implementación<br />
Se ha decidido realizar la implementación de la aplicación en distintas fases, que<br />
denominaremos aproximaciones. La decisión de dividir la implementación en fases es<br />
debido al enorme número de aspectos a tener en cuenta al serializar, con lo que de esta<br />
forma se consigue facilitar la implementación y conseguir un desarrollo más óptimo.<br />
Las aproximaciones a las que se ha hecho referencia son:<br />
• Primera aproximación, realización de las siguientes implementaciones:<br />
- Inicio del desarrollo de la interfaz gráfica.<br />
- Solo se crea un único fichero Clase2XML.java, donde Clase es el<br />
nombre de la clase Java (Ej.: para la clase Coche, sería<br />
Coche2XML.java).<br />
- Procesar el documento XML mediante SAX.<br />
Únicamente se ha contemplado para la serialización y la creación del fichero<br />
arriba nombrado clases con determinadas características:<br />
- Sólo atributos públicos.<br />
- Sin constructores.<br />
- Sin métodos.<br />
- Sólo tipos primitivos: int, doble, char,…<br />
- Admitir tipo String.<br />
• Segunda aproximación, se implementó la posibilidad de procesar clases<br />
además de con las características anteriores, con las siguientes:
Capítulo 8. IMPLEMENTACIÓN Y PRUEBAS 86<br />
- Atributos no públicos.<br />
- Utilizar los métodos get y set para los anteriores atributos.<br />
- Cualquier Clase que pertenezca o no a la API estándar de Java (o a una<br />
externa); en el primer caso no tendremos el código fuente y en el<br />
segundo sí.<br />
- En el caso de tener que serializar una clase que pertenece a la API<br />
estándar de Java o a una externa (por lo que no tendremos su código<br />
fuente), es necesario de la existencia de una clase para transformar a y<br />
desde un String (ver en el capítulo 5 los requisitos REQ.FUN.1.2.5. y<br />
REQ.FUN.2.2.4.).<br />
Debido a las nuevas características, se introdujo la posibilidad de generar más<br />
de un fichero Clase2XML.java, generándose tantos como clases intervengan<br />
en la serialización y que no pertenezcan a una API externa o estándar de Java<br />
(del que sí tenemos el código fuente).<br />
- Mejorar la funcionalidad de la interfaz gráfica, añadiendo entre otras<br />
cosas el listado de documentos generados.<br />
• Tercera aproximación, se añadieron grandes mejoras, entre ellas:<br />
- Añadir la posibilidad de utilizar un fichero de configuración para cada<br />
clase con las siguientes opciones para la serialización:<br />
• Paquete del proyecto en el que se va a añadir la clase generada.<br />
• Paquete del proyecto en el que aparecen las clases que<br />
transformarán las clases que pertenecen a la API de Java a<br />
String (ver en el capítulo 5 los requisitos REQ.FUN.1.2.5. y<br />
REQ.FUN.2.2.4.).<br />
• Constructor a utilizar y atributos a los que asigna valor. Por<br />
defecto se utiliza el constructor sin parámetros.<br />
• Si se integra el código o no. Por defecto no se integra.<br />
• Clase de los objetos que serán utilizados en las Listas (atributos<br />
cuya clase implementa la interfaz java.util.List).<br />
• Clase de los objetos que serán utilizados en los Maps (atributos<br />
cuya clase implementa la interfaz Java.util.Map).<br />
• Si la clase a procesar ha de soportar referencias circulares sobre<br />
ella.
Capítulo 8. IMPLEMENTACIÓN Y PRUEBAS 87<br />
• Los atributos que intervienen en referencias circulares<br />
Gracias al fichero de configuración expuesto, se pudieron introducir las<br />
siguientes mejoras a las clases Java a serializar:<br />
- Aceptar constructores a parte del de por defecto.<br />
- Admitir como tipos de atributos clases que implementen la interfaz<br />
java.util.List.<br />
- Admitir como tipos de atributos clases que implementen la interfaz<br />
Java.util.Map.<br />
• Cuarta aproximación y última, en la que se terminó de desarrollar la<br />
aplicación, con las siguientes mejoras:<br />
- Generación del DTD de la clase.<br />
- Generación del XML Schema de la clase.<br />
- Capacidad de procesar clases que mantengan entre sí referencias<br />
circulares.<br />
8.2. Pruebas<br />
A medida que se ha ido realizando la implementación de la aplicación en cada una<br />
de sus aproximaciones, se han ido probando las nuevas características implementadas<br />
con todas las diversas variantes que podía ofrecer una clase Java, tal y como se ha<br />
detallado en la sección anterior. De esta manera, cualquier error o problema que pudiera<br />
surgir se ha ido solucionando y, en el caso de ser necesario, se han ido modificando<br />
pequeños detalles del análisis y/o diseño.<br />
Las pruebas consistían en generar manualmente una clase a serializar con distintos<br />
atributos, constructores, etcétera; según el nivel de implementación alcanzado hasta el<br />
momento, y se creaba otra clase que era la encargada, una vez generados los<br />
documentos, de instanciar la clase anterior y llamar a las funciones toXML y fromXML<br />
(de estos documentos generados). El objeto correspondiente a la instancia ha sido<br />
creado con distintas características, albergando en las estructuras de datos tanto clases<br />
de la API de Java como del proyecto, de las que sí tenemos su código y podemos<br />
serializar.
Capítulo 8. IMPLEMENTACIÓN Y PRUEBAS 88<br />
En el ejemplo de la Tabla 18 se observan los distintos tipos de atributos utilizados<br />
en este ejemplo de prueba, intentando abarcar todas las posibles variantes: atributos<br />
públicos y privados, estos últimos con sus correspondientes métodos get y set;<br />
constructor por defecto y constructor con un parámetro de entrada; así como dos<br />
estructuras de datos representadas como ArrayList y Hashmap. También se ha<br />
comprobado el correcto funcionamiento con atributos primitivos (char, byte,…);<br />
atributos de la API de Java (String y Date) y atributos del proyecto de los que sí<br />
tenemos su código Java (Silla), utilizados en la estructura de datos ArrayList.<br />
import java.util.Date;<br />
import java.util.ArrayList;<br />
import java.util.HashMap;<br />
public class Mesa{<br />
public String nombre;<br />
public Date fecha;<br />
public char material;<br />
private byte altura;<br />
public short profundidad;<br />
public long anchura;<br />
public int numeroPatas;<br />
public HashMap existe;<br />
private ArrayList sillas;<br />
public Mesa()<br />
{<br />
}<br />
public Mesa(String nom)<br />
{<br />
this.nombre = nom;<br />
}<br />
public byte getAltura() {<br />
return altura;<br />
}<br />
public void setAltura(byte altura) {
Capítulo 8. IMPLEMENTACIÓN Y PRUEBAS 89<br />
}<br />
this.altura = altura;<br />
}<br />
public ArrayList getSillas() {<br />
return sillas;<br />
}<br />
public void setSillas(ArrayList sillas) {<br />
this.sillas = sillas;<br />
}<br />
Tabla 18: Ejemplo clase de prueba (Mesa.java)<br />
El ejemplo anterior se ha ido modificando incorporando nuevas funcionalidades<br />
implementadas y comprobando a lo largo de la implementación el correcto<br />
funcionamiento de todas ellas. Por ejemplo, poner estructuras de datos privadas o<br />
públicas, introducir todos los atributos primitivos de Java, incluir referencias circulares,<br />
introducir estructuras de datos que alberguen distintos tipo de objetos, etc.
Capítulo 9. CONCLUSIONES Y TRABAJOS FUTUROS 90<br />
9<br />
Capítulo 9<br />
CONCLUSIONES Y TRABAJOS FUTUROS<br />
Este capítulo se evalúa los resultados de todo el desarrollo, se divide en dos<br />
partes: por un lado se enumeran los logros alcanzados y, por otro lado, se tratan los<br />
posibles trabajos futuros.<br />
Cabe mencionar que este proyecto se ha publicado como código abierto bajo<br />
licencia GPL y se encuentra disponible en la dirección http://vido.escet.urjc.es/serxml/.<br />
9.1. Principales logros alcanzados<br />
A lo largo del presente documento se han expuesto los objetivos, así como la<br />
especificación de requisitos que la herramienta debía cumplir. Una vez desarrollada y<br />
probada la herramienta, en este punto se puede decir que se cumplen todos los requisitos<br />
especificados.<br />
Se cumple la posibilidad de serializar cualquier objeto Java, aceptando los<br />
siguientes aspectos o características en las clases:<br />
- Cualquier visibilidad y tipo de los atributos, se aceptan atributos tanto privados<br />
como públicos. También es posible que el tipo del atributo sea primitivo, de<br />
una API o de una clase del proyecto y de la cual tenemos su código fuente.<br />
- Constructores sin parámetros, o con algún parámetro que correspondan a<br />
atributos de la clase.<br />
- Cualquier estructuras de datos del Collection Framework de Java<br />
(java.util.List, java.util.Set, java.util.Map).
Capítulo 9. CONCLUSIONES Y TRABAJOS FUTUROS 91<br />
- Referencias circulares entre objetos, identificándolas mediante los atributos<br />
que las realizan.<br />
Otra característica del documento XML que se genera es su total independencia<br />
con Java, donde no se aprecian etiquetas que hagan ver que el documento proviene de la<br />
serialización de un objeto Java.<br />
La aplicación desarrollada permite, a través de un fichero de configuración,<br />
definir características particulares para cada serialización, lo cual es un valor añadido de<br />
cara a una serialización más flexible.<br />
Se ofrece la posibilidad de generar el documento XML Schema, transformando la<br />
clase Java de manera estructurada. Aprovechando la riqueza semántica que ofrece el<br />
XML Schema se han podido representar los tipos de datos de cada atributo primitivo,<br />
así como las referencias circulares. Además es posible generar el documento DTD de la<br />
clase Java.<br />
Mediante SerXML se han mejorado en ciertos aspectos las distintas aplicaciones<br />
analizadas en el capítulo 2; es decir, de los requisitos estudiados para cada aplicación en<br />
dicho capítulo, SerXML cumple todos, mientras que las herramientas analizadas sólo<br />
cumplían parte de ellos.<br />
En definitiva, se ha obtenido una herramienta que hace uso de dos tecnologías<br />
totalmente portables como son Java y XML, eliminando el trabajo de la serialización al<br />
desarrollador y ofreciéndole la posibilidad de utilizar la serialización con cualquier<br />
aplicación, lenguaje de programación o sistema.<br />
9.2. Trabajos futuros<br />
La herramienta desarrollada es una primera versión. En los trabajos futuros a<br />
realizar se pretenderá mejorarla y completarla añadiendo más funcionalidades. La<br />
aplicación SerXML se puede mejorar en ciertos aspectos, tanto en su implementación<br />
como en su definición. Este Proyecto Fin de Carrera es el comienzo de una serie de<br />
proyectos que están siendo desarrollados dentro del grupo ViDo 2 . Por tanto seguirá<br />
desarrollándose hasta que se consiga proporcionar todas las funcionalidades requeridas.<br />
2 Grupo ViDo: Grupo de Visualización y Documentación electrónica de la ESCET en la<br />
<strong>Universidad</strong> <strong>Rey</strong> <strong>Juan</strong> <strong>Carlos</strong>, Área de Lenguajes y Sistemas Informáticos. http://vido.escet.urjc.es.
Capítulo 9. CONCLUSIONES Y TRABAJOS FUTUROS 92<br />
En los siguientes apartados se describen cada una de las líneas en las que se tiene<br />
previsto seguir trabajando en SerXML.<br />
9.2.1. Integración de SerXML como plugin para los entornos<br />
de desarrollo<br />
Uno de los mayores objetivos en la construcción de software es la reutilización, la<br />
cual es necesaria para no tener que reinventar la rueda cada vez que se necesite<br />
introducir alguna funcionalidad adicional. En nuestro caso, uno de los trabajos futuros<br />
que se pueden llevar a cabo consistiría en implementar SerXML como un plugin de un<br />
entorno de desarrollo, de forma que las aplicaciones que usen SerXML puedan<br />
desarrollarse en dicho entorno de desarrollo, facilitando el trabajo al desarrollador. En<br />
concreto, se está pensando en implementar SerXML como plugin para el entorno de<br />
desarrollo de código abierto Eclipse 3 .<br />
9.2.2. Utilización de toda la riqueza semántica ofrecida en el<br />
lenguaje J2SE 1.5<br />
SerXML es una aplicación diseñada para el lenguaje de programación Java versión<br />
1.4 de la tecnología Java 2 Standard Edition. No obstante, al finalizar este Proyecto de<br />
Fin de Carrera la nueva versión 1.5 está en fase beta. Esta nueva versión incorporará<br />
modificaciones en el lenguaje de programación, por lo tanto, es muy recomendable<br />
incluirla y utilizar todas las nuevas posibilidades semánticas que ofrecerá esta versión.<br />
9.2.3. Uso de SerXML en diversos programas reales<br />
En SerXML se han tomado decisiones acerca de cómo serializar las construcciones<br />
Java desde un punto de vista teórico, ideando ejemplos prototípicos para cada una de<br />
dichas construcciones. Sin embargo, el uso de la herramienta en programas reales<br />
3 Eclipse: http://www.eclipse.org.
Capítulo 9. CONCLUSIONES Y TRABAJOS FUTUROS 93<br />
mostrará las necesidades concretas de serialización de cada uno de ellos. Las diferentes<br />
formas de serializar en XML dependen del uso concreto que se hace de cada una de las<br />
construcciones de Java. Por tanto, usando la herramienta con programas reales se<br />
podrán tener mejores criterios a la hora de determinar cuál es la mejor serialización<br />
posible; es decir, la que está semánticamente más ajustada a las necesidades de la<br />
aplicación concreta.<br />
9.2.4. Utilizar la metaprogramación para realizar la<br />
serialización<br />
Para realizar la serialización en SerXML se han de generar unas clases en Java que<br />
ofrecen, mediante métodos, la posibilidad de serializar objetos Java. Se quiere también<br />
ofrecer la posibilidad de serializar sin la necesidad de generar este código intermedio.<br />
Para evitar la generación de este código puede usarse la metaprogramación.
94<br />
Bibliografía<br />
[1] Aaron Skonnard, Martin Gudgin. Essential XML Quick Reference, Ed.:<br />
Addison-Wesley, 2002.<br />
[2] Cliff Binstock, Dave Peterson, Mitchell Smith, Mike Wooding, Chris Dix,<br />
Chris Galtenberg. The XML Schema Complete Reference, Ed.: Addison-<br />
Wesley, 2002.<br />
[3] http://www.osmosislatina.com/xml/. Osmosis Latina - XML, último acceso:<br />
19-8-2004.<br />
[4] http://www.xml.com/. O’REILLY XML.com, XML from de inside out,<br />
último acceso: 10-9-2004.<br />
[5] Apuntes asignatura Ofimática Avanzada, URJC.<br />
[6] http://www.w3c.org. World Wide Web Consortium, último acceso: 1-9-<br />
2004.<br />
[7] Joshua Bloch. Effective Java: Programming Language Guide, Ed.:<br />
Addison Wesley, 2001.<br />
[8] Eckel, B. Thinking in Java, Ed.: Prentice Hall 1998.<br />
[9] http://www.programacion.com/java/. Programación en Castellano, Java.<br />
[10] http://www.javahispano.org/. javaHispano, último acceso: 6-9-2004.<br />
[11] Brett McLaughlin. Java & XML 2nd Edition, Ed.: O’Reilly, 2001.<br />
[12] Brett McLaughlin. Java and XML Data Binding, Ed.: O’Reilly, 2002.<br />
[13] http://java.sun.com/j2se/1.4.2/docs/guide/serialization/. Serialización de<br />
objetos en Java, último acceso: 28-7-2004.<br />
[14] http://java.sun.com/xml/. Java Technology XML, último acceso: 10-9-<br />
2004.<br />
[15] http://vido.escet.urjc.es/javacet/. JavaCET, último acceso: 11-9-2004.
95<br />
[16] http://java.sun.com/products/javabeans/. JavaBeans, último acceso: 2-9-<br />
2004.<br />
[17] http://java.sun.com/j2se/1.4.2/docs/guide/collections/. The Collection<br />
Framework, último acceso: 4-9-2004.<br />
[18] http://www.saxproject.org. The oficial website for SAX, último acceso: 4-<br />
8-2004.<br />
[19] Pierre-Alain Muller. Instant UML, Ed.:Wrox Press, 2001.<br />
[20] http://www.omg.org/uml. UML, último acceso: 2-8-2004.<br />
[21] Booch G., Jacobson I., Rumbaugh J. El lenguaje Unificado de Modelado,<br />
Ed.: Addison-Wesley, 1999.<br />
[22] Booch, G; Jacobson, I; Rumbaugh, J, El Proceso Unificado de Desarrollo<br />
de Software, Ed.: Addison-Wesley, 2000.
96<br />
Anexo A<br />
En este anexo se describe la utilización de la aplicación con los distintos pasos<br />
que hay que seguir para poder utilizarla correctamente y el fichero de configuración que<br />
se encarga de obtener distintas opciones de serialización.<br />
Utilización de la aplicación<br />
Para realizar la instalación y el correcto uso de la aplicación se han de seguir los<br />
siguientes pasos:<br />
1. Lanzar la aplicación.<br />
2. Una vez se hayan introducido los directorios de la ruta del Java SDK y del<br />
directorio raíz del proyecto donde se encuentra la clase a abrir (mediante el<br />
menú “Opciones” o al pulsar “Abrir”), se ha de introducir el nombre de la clase<br />
Java de la que se quiera obtener los documentos para la serialización.<br />
3. En caso de no desear que se aplique la configuración por defecto o de que<br />
existan atributos cuyo tipo implementa la interfaz java.util.List o Java.util.Map,<br />
se tendrá que crear un fichero con el nombre de la clase anterior más<br />
2XML.config (Ej.: si la clase se llama Coche el fichero se llamará<br />
Coche2XML.config), donde se especificarán las distintas opciones de<br />
configuración. El fichero de configuración ha de tener un determinado formato<br />
que se explica en el apartado siguiente.<br />
4. Si existieran atributos cuyo tipo es de una clase que no pertenece a nuestro<br />
proyecto, entonces habrá que generar (si no se ha realizado todavía) una clase,<br />
para cada clase distinta que exista, con el nombre de la clase más 2String.java<br />
(Ej.: Date2String.java). Ésta ha de ofrecer de modo público y estático los
97<br />
métodos: toString y fromString. Mediante estos métodos será posible<br />
transformar una clase de este tipo a String, para poderla añadir a la serialización,<br />
y desde un String a la clase de nuevo (deserialización). Todo esto se realiza ya<br />
que el documento XML sólo trabaja con etiquetas cuyo valor ha de ser<br />
únicamente de caracteres, para poder serializarlo y mejorar su comprensión.<br />
5. Generar el fichero para la serialización (Java2XML), con ello aparecerán los<br />
ficheros generados en la lista gráfica de la parte inferior izquierda; habrá un<br />
fichero con el nombre de la clase abierta más 2XML (Ej.:Clase2XML.java).<br />
Además de otros ficheros dependiendo de la relación de algunos atributos de la<br />
clase abierta con otras clases de nuestro proyecto, por lo que se generarán tantas<br />
nuevas clases de Java como relaciones diferentes existan.<br />
6. En caso de querer obtener el DTD y/o XML Schema, se tendrá que pulsar el<br />
correspondiente botón de generación, tras el cual aparecerá el documento en la<br />
lista gráfica.<br />
7. Una vez generados los documentos se pueden guardar de diferentes formas:<br />
seleccionando cualquiera de ellos de la lista antes mencionada y pulsar la opción<br />
“Guardar” del menú “Archivo”, guardarlos todos en un directorio determinado<br />
mediante el opción “Guardar Todo en” del menú “Archivo”, o guardarlos todos<br />
en el directorio donde reside la clase abierta pulsando “Guardar Todo” tanto del<br />
menú “Archivo” como del botón.<br />
Una vez generados los ficheros y almacenados en nuestro proyecto Java, se va a<br />
proceder a explicar cómo, mediante éstos, obtener la serialización:<br />
8. Añadir las clases Java generadas al correspondiente paquete del proyecto al que<br />
pertenece la clase abierta inicialmente.<br />
9. Añadir justo en el punto donde se quiere serializar el objeto Java (de la clase<br />
abierta) la instrucción siguiente: Clase2XML.toXML(…), donde la palabra Clase<br />
corresponde a la clase abierta inicialmente y desde donde se han generado todos<br />
los ficheros. Además, al método toXML se le ha de pasar como primer parámetro<br />
un objeto de dicha clase y como segundo un objeto de la clase OuputStream<br />
donde se almacenará el objeto serializado.<br />
En el caso de querer deserializar el objeto, se ha de ejecutar la siguiente<br />
instrucción: Clase2XML.fromXML(…), donde Clase tiene el mismo significado que en
98<br />
el punto anterior. Además, al método se le ha de pasar por parámetro un objeto de la<br />
clase InputStream, desde donde se leerá el documento XML de la serialización anterior;<br />
este método devolverá un objeto de la clase Clase que será el objeto tal y como se<br />
serializó anteriormente.<br />
Fichero de configuración<br />
El nombre del fichero de configuración ha de ser el nombre de la clase a la que<br />
pertenece concatenado con 2XML.config (Ej.: Person2XML.config). Las diferentes<br />
configuraciones se insertan mediante el nombre de la opción asignando el valor que se<br />
desea (Ej.: integrado=si). A continuación se muestran todas las posibles configuraciones<br />
que se pueden realizar a la serialización:<br />
• Definir paquetes y otras opciones:<br />
- package: Especifica el package al que va a pertenecer la clase creada<br />
(opcional).<br />
- packageClases2String: Especifica el package donde se encuentran los<br />
Clases2String para realizar las transformaciones (opcional).<br />
- integrado: Especifica si el código generado será integrado en una clase ya<br />
existente (si) o se creara una nueva clase (no), por defecto “no” (opcional).<br />
• Definir constructor:<br />
- constructor: posición en la clase del constructor que se tomara para la<br />
creación de la clase serializada, por defecto constructor sin parámetros<br />
(opcional).<br />
- constructorParamsi: atributos que se usan el la llamada al constructor. El<br />
valor de i va de uno hasta el número de parámetros (opcional).<br />
• Definir Listas: se utiliza obligatoriamente en el caso de que exista algún atributo<br />
que implementa la interfaz java.util.List o java.util.Set, y sirve para asociar el<br />
nombre de una lista a la clase de los objetos que alberga.<br />
- NombreListai: El valor de i es un entero que va de uno hasta el número de<br />
atributos cuyo tipo es una lista o conjunto. Se especifica el nombre del<br />
atributo.
99<br />
- ClaseListai: El valor de i es un entero que va de uno hasta el número de<br />
atributos cuyo tipo es una lista o conjunto. Se especificará la clase<br />
cualificada de los elementos que alberga la lista.<br />
• Definir Maps: se utiliza obligatoriamente en el caso de que exista algún atributo<br />
que implementa la interfaz java.util.Map, y sirve para asociar el nombre de una<br />
Map a la clase de los objetos que alberga el key y el value.<br />
- NombreMapi: El valor de i es un entero que va de uno hasta el número de<br />
atributos de tipo map. Se especifica el nombre del atributo.<br />
- ClaseKeyMapi: El valor de i es un entero que va de uno hasta el número de<br />
atributos de tipo map. Se especificará la clase cualificada de las claves que<br />
alberga el map.<br />
- ClaseValueMapi: El valor de i es un entero que va de uno hasta el número de<br />
atributos de tipo map. Se especificará la clase cualificada de los valores que<br />
alberga el map.<br />
• Definir referencias circulares:<br />
- soportarRefCirc: define si soporta referencias, por defecto “no”.<br />
- nombreAtributoi: atributos con referencias.<br />
Los comentarios en el fichero de configuración se especifican mediante una #<br />
delante del texto. En la Tabla 19 se muestra como ejemplo un fichero de configuración<br />
para la clase Mesa.java.<br />
package=pruebasMesa<br />
packageClases2String=clases2String<br />
integrado=no<br />
constructor=1<br />
constructorParams1=nombre<br />
#Lists<br />
NombreLista1=sillas<br />
ClaseLista1=Silla<br />
#Maps<br />
NombreMap1=existe<br />
ClaseKeyMap1=java.lang.String<br />
ClaseValueMap1=Silla<br />
Tabla 19: Ejemplo de fichero de configuración