Aplicacin de Tcnicas de Ingeniera Inversa y Reingeniera en Bases de Datos de Sistemas Informticos de Gestin Hotelera

Jos L. Leiva Olivencia

Departamento de Lenguajes y Ciencias de la Computacin Universidad de Mlaga e-mail:jlleivao@lcc.uma.es

Resumen: La reingeniera es una alternativa til para la industria del software, ya que se trata de una actividad que permita incrementar la facilidad de mantenimiento, reutilizacin y evolucin de sistemas software. En concreto, su aplicacin a las bases de datos es una necesidad que surge muy a menudo. Pensamos que en una industria como es la turstica y concretamente en la gestin hotelera, en la que el trabajo con sistemas de informacin es una labor fundamental, y en la que el acceso a los datos de una forma rpida y eficaz es una necesidad, la reingeniera de base de datos es una tarea de gran utilidad para las empresas tursticas, pues su aplicacin conlleva una mejora en los productos y servicios que ofertan. Este artculo estudia la obtencin de un modelo de datos, basndose en dos fuentes de informacin: partiendo de una herramienta automtica capaz de obtener especificaciones de bases de datos y modificar dicho modelo para adaptarlo a las necesidades actuales que surgen. Palabras clave: reingeniera, ingeniera inversa, CSCW, interaccin persona-ordenador, herramientas CASE, bases de datos, modelo entidad-relacin, turismo.

1. Introduccin
Sabemos, que es muy habitual que en los mercados actuales aparezcan nuevos entornos, nuevos sistemas de gestin de datos, ms eficaces y mejores que los anteriores, y ciertamente no es cosa sencilla ir cambiando, pues el hacer un trasvase de un sistema de gestin de bases de datos a otros, no es una tarea trivial. Adems, a veces surgen

253

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004

necesidades que no se llevan a cabo por la dificultad que tendra la modificacin de aplicaciones, modelos de datos, etc. Ciertamente, las empresas tursticas pertenecen a ese grupo de organismos en los que pueden aparecer estas necesidades, pues su objetivo es mantener un servicio de calidad, por lo que la renovacin es un proceso que se debe llevar a cabo las mayoras de las veces para obtener mejoras en el sistema de informacin, y sera muy til aprovechar aspectos ya desarrollados.

Un porcentaje muy elevado de esas mejoras, est muy relacionada con la forma de almacenar los datos. Es un proceso muy costoso tener que desarrollar nuevo software y tener que adaptar todos los datos que se encuentran en un determinado sistema de gestin de bases de datos a otro distinto, cuando prcticamente toda la informacin va a ser la misma. Por tanto, reutilizar lo ya construido aparece como un importante activo a aprovechar (Henry, 1995).

El proceso de reingeniera de bases de datos, consiste en la recuperacin mediante distintos mtodos de toda la informacin de las distintas vistas (fsica, conceptual y lgica) de la base de datos actual (LDB - Base de datos legada) para en posteriores etapas conseguir modificar y redisear el esquema conceptual,

transformando la base de datos anterior (LDB) en otra base de datos (NDB Base de datos nueva). Este proceso conlleva entre otros aspectos de vital importancia, la migracin de datos de la LDB a la NDB.

Se trata de una etapa dentro de una metodologa general de reingeniera de sistemas de informacin, para conseguir especificaciones que permitan un alto grado de satisfaccin y obtener un sistema de informacin basado en un sistema anterior.

Nos basamos en la construccin de una herramienta semi-automtica, en la que los usuarios aportan su conocimiento de las bases de datos existentes, as como de

254

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004

mejoras que pretenden realizar. Dicha informacin es enfrentada con la obtenida en un proceso de ingeniera inversa (Haineaut, 16)

El problema podemos enmarcarlo en una metodologa cooperativa que pretende

la participacin del usuario en la fase de anlisis y diseo del nuevo sistema de informacin. Por tanto, proponemos realizar un cambio organizativo del estilo de trabajo de la empresa turstica facilitando la participacin del usuario en el proceso de reingeniera.

Los Sistemas de Informacin cooperativos tienen como objetivo comunicar varios sistemas para as no solo adquirir y almacenar informacin, sino tambin compartirla. Esta lnea se enmarca dentro del grupo de investigacin SICUMA de la Universidad de Mlaga, que trabaja en el desarrollo de una Metodologa Cooperativa para el desarrollo de Software.

La metodologa para Reingeniera de Sistemas que proponemos facilita la participacin de usuarios, para los cules estamos diseando herramientas lo ms potentes posibles, pero siempre teniendo como objetivo fundamental la facilidad de uso, para que el usuario no se sienta forzado a participar, sino que se vea como un elemento fundamental en el proceso de reingeniera.

En este artculo expondremos inicialmente los aspectos generales de la metodologa orientada a bases de datos (seccin 2), describiendo la etapa de ingeniera inversa (seccin 3), as como la etapa de participacin del usuario en la descripcin del usuario del sistema de informacin (seccin 4). Concluiremos exponiendo nuestro trabajo futuro.

255

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004

2. Metodologa para la obtencin de modelos de datos en sistemas de informacin

Dentro de la metodologa que proponemos, encontramos en primer lugar una etapa de ingeniera inversa, que podemos dividir en dos actividades que se denominan Anlisis de datos y Abstraccin Conceptual (Hausi et al., 2000), y posteriormente una etapa de reingeniera.

La primera fase de anlisis de datos, pretende recuperar un esquema de datos lgico completo, que est lo suficientemente bien documentado y con su semntica correctamente identificada. El esquema lgico que se obtiene en esta fase ser la entrada de la siguiente fase, que como hemos comentado anteriormente, se denomina Abstraccin conceptual, la cual transformar el esquema lgico a un esquema conceptual equivalente basado en modelo entidad-relacin, el cual proporcionar una rica base en la fase de reingeniera de la base de datos (RBD).

Tanto en la etapa de ingeniera inversa como en la etapa de reingeniera, los ingenieros o diseadores van a contar con una importante ayuda que es la que proporcionar el trabajo cooperativo de los usuarios que, por medio de unas herramientas sencillas, conseguirn acumular ms informacin tanto de la LDB como de la NDB. El trabajo de los usuarios se basar en una utilizacin de un trabajo automatizado, interactivo e iterativo para de esa forma conseguir un modelo lo ms correcto y eficiente posible, de tal forma que no solo se obtendr un nuevo modelo sino que sera muy eficiente obtener un modelo que permitiera de forma automatizada realizar una migracin de los datos. Es cierto que muchos de los problemas que vamos a exponer, son tpicos de muchas organizaciones y sistemas de informacin, pero ciertamente en la gestin turstica y hotelera son problemas de envergadura, que hacen que un proceso de

256

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004

ingeniera inversa y/o reingeniera sea una tarea indicada de forma bastante significativa en este tipo de industria. Podemos considerar como problemas comunes:

a) Estructuras implcitas: algunas estructuras no fueron declaradas en el momento de su diseo de forma explcita en la especificacin DDL de la base de datos, sino que para completar la semntica de la base de datos se han utilizado triggers, checks, procedimientos, etc., por lo que para encontrar caractersticas como la integridad no basta con observar las definiciones de las tablas (DDL). b) Diseo pobre o construcciones poco legibles: no todas las bases de datos son perfectas aunque funcionen correctamente, a veces podemos encontrar estructuras pobres o incluso errneas, redundantes o simplemente poco legibles al tener nombres los campos poco clarificadores, etc. c) Poca documentacin: se realiz poca o no existe documentacin sobre el diseo. d) Migrar los datos desde modelos de datos antiguos al modelo relacional. e) f) Cambiar sistema de gestin de base de datos. Deteccin de errores de integridad.

g) Migracin de modelos de datos relacionales a modelo orientado a objetos.

3. Ingeniera inversa de bases de datos

Como hemos comentado anteriormente el proceso de Ingeniera Inversa sobre las bases de datos, es comnmente dividido en dos fases claramente diferenciadas (Figura 1): a) Extraccin de las estructuras de datos, obteniendo como resultado el esquema lgico.(Fase I) b) Conceptualizacin de las estructuras de datos, obteniendo como resultado el esquema conceptual. (Fase II)

257

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004

Extraccin automtica Conceptualizacin bsica Extraccin acumulativa Fase I Unin del esquema Fase II Normalizacin

Anlisis de programas

Figura 1. Esquema del proceso de ingeniera inversa en bases de datos

Fase I. En esta fase se va a realizar una extraccin de las estructuras existentes actualmente en el sistema de informacin, dividindose en dos etapas de extraccin de informacin.

Etapa 1: Extraccin automtica. Inicialmente debemos extraer mediante herramientas automticas todas las estructuras de la base de datos cmo fueron diseadas inicialmente por los desarrolladores. Se trata por tanto de una etapa tpica de traduccin inmediata del cdigo para as extraer las estructuras de datos explcitas.

Etapa 2: Extraccin acumulativa. Se trata de una etapa en la que la participacin de los usuarios del modelo de datos con el que trabaja supondr acumular ms informacin de la obtenida en la etapa anterior. Como hemos comentado anteriormente es posible que ciertas reglas no puedan obtenerse directamente en la etapa 1, por lo que aprovechando el conocimiento adquirido por los usuarios en el trabajo diario se podr obtener informacin muy interesante.

258

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004

As, aspectos importantes, sobre los que los usuarios nos pueden ayudar son: a) Anlisis de Nombres: el usuario har una descripcin de aquellos campos en los que es posible que tengamos dudas acerca de su rol, tipos de datos, relacin, etc. b) Extraccin de claves externas: sabemos que en la etapa 1, de forma sencilla se pueden obtener las claves principales, pero la obtencin de claves externas a veces no es tarea sencilla, y la informacin aportada por el usuario es vital. c) Etapa 3: Unin del Esquema: Se trata de una etapa ciertamente compleja, y de la que su xito depende en gran medida el proceso de reingeniera, pues consiste en unir y reconvertir las estructuras y restricciones obtenidas en las dos fases anteriores. As, con la informacin obtenida en la etapa 2 se pretende complementar la informacin obtenida en la etapa 1, ya sea para encontrar estructuras no explcitas o q fueron perdidas cuando la base de datos fue ue diseada. Para ello se localizarn: a) Campos multivaluados. b) Tipos registros e identificadores de campos multivaluados. c) Campos opcionales.

d) Claves. e) f) Redundancias. Dominios.

g) Significado de los campos.

En esta misma etapa y dado que no se le puede dar a los usuarios la responsabilidad de cubrir las posibles lagunas existentes por un mal diseo, es conveniente realizar una etapa posterior para comprobar la correccin de lo realizado en esta etapa.

259

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004

Etapa 4: Anlisis de Programas. En esta fase se realiza un estudio del cdigo fuente existente, para comprobar que las restricciones, forma de procesar los datos, significado, etc. se corresponde con el estudio realizado en las fases anteriores. Es posible que esta etapa modifique el resultado obtenido en las etapas anteriores, pero sera deseable que no existieran cambios, pues de esa forma podramos asegurarnos que lo hecho en las etapas anteriores es correcto y vamos por un buen camino.

En esta misma etapa podramos incluir el anlisis de formularios, consultas, informes, etc. que puedan existir, ya que de esa forma podemos ver si los resultados obtenido con la LBD coinciden con el modelo extraido.

Queremos en este punto describir que la ejecucin de consultas para analizar los datos, puede permitirnos obtener claves externas. As, si en una base de datos con ciertorodaje de trabajo, habitualmente se ejecuta una consulta en una tabla B para encontrar en algn campo el valor de un campo clave de una tabla A, y el resultado obtenido es cero, nos indicara que posiblemente no es una clave externa.

Fase II. En esta fase se extrae el esquema conceptual a partir del esquema lgico. En mucha bibliografa, a esta fase se le denomina Interpretacin de las estructuras de datos, pues se va a realizar una optimizacin del esquema lgico.

Etapa 1: Conceptualizacin bsica. As, un ejemplo de conceptualizacin bsica podra ser si tenemos campos que tienen la misma estructura y que se refieren a atributos de la entidad iguales, se transformarn en un atributo multivaluado. Por ejemplo, en la entidad cliente tenemos el campo Telfono1, Telfono2, etc.. Otro ejemplo, podra ser cuando campos con distinta estructura pero que se refieren a subcampos de un campo multivaluado. Por ejemplo, el
260

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004

campo habitacin, puede venir determinado por Planta, Nmero, Orientacin, Nmero de camas,

Etapa 2: Normalizacin. La reforma del esquema conceptual tiene como objeto hacer una comprensin de dicho modelo. En esta etapa de pretende aportar un significado en la semntica de las construcciones explcitas. El objetivo es representar la informacin con una metodologa estndar que sea altamente legible.

El modelo entidad relacin cumple con amplitud el objetivo planteado por lo que existen muchos modelos aplicables a bases de datos relacionales. En la siguiente tabla aparece un listado de distintos mtodos de ingeniera inversa en bases de datos relacionales:
Mtodo Batn et al. (1992) Suposiciones 3FN Consistencia en el nombrado de los atributos. Sin homnimos. Clave principal y clave candidata. 3FN Consistencia en el nombrado de los atributos. Sin errores en los atributos claves. Entradas Dependencias. Esquemas de relacin. Salidas Entidades. Relaciones binarias. Categoras. Generalizaciones. Caractersticas Basado en el mtodo de Navathe de Awongs

Chiang et al. (1994,1996)

Esquemas de relacin. Instancia de datos. Dependencias.

Entidades. Relaciones binarias. Generalizaciones. Agregaciones.

Requiere el conocimiento acerca del nombre de los atributos. Propone un marco de trabajo para la evaluacin de los mtodos de ingeniera inversa. Identifica claramente los casos en los que las entradas de los humanos son necesarias. Apunta a una transformacin reversible desde el esquema relacional al

Davids & Arora (1987)

3FN Sin homnimos ni sinnimos

Esquemas de relacin. Restricciones de claves ajenas.

Conjunto de entidades. Relaciones binarias. Relaciones n-aria

261

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004 esquema conceptual. Basado en los conceptos establecidos de las teora de b.d. relacionales. Proceso de mapeo simple y automtico. Requiere todas las dependencias de clave.

Johannessin(1994)

3FN Consultas de dominio independientes.

Dependencias funcionales y de inclusin. Esquemas de relacin.

Generalizaciones. Entidades. Relaciones binarias.

Markowitz & Makowsky (1990)

FN Boycce-Codd

Navathe & Among (1987)

Petit et al. (1996)

3FN y algunos 2FN. Consistencia en el nombrado de atributos. Sin ambigedades de clave ajena. Claves candidatas especficas. 1FN Atributos nicos.

Esquemas de relacin. Dependencias de claves. Dependencias de integridad referencial. Esquemas de relacin.

Entidades Relaciones binarias. Generalizaciones y agregaciones.

Entidades. Relaciones binarias. Categoras. Cardinalidades.

Es vulnerable a la ambigedad en el reconocimiento de claves ajenas.

Esquemas de relacin. Instancia de datos y cdigo.

Entidades. Relaciones. Generalizaciones.

Premerlani & Blaha (1993,1994)

Sin 3FN Comprensin semntica de aplicacin.

Esquemas de relacin. Observaciones de patrones de datos.

Clases. Asociaciones. Generalizaciones. Multiplicidad Agregacin

Sotou (19971998)

Sin nombres nicos de atributos. Dependencias desconocidas

Esquema de datos. Instancia de datos. Diccionario de datos.

Cardinalidad de las restricciones de relaciones n-arias.

Analiza las consultas en los programas de aplicacin. No pone restricciones en el nombre de los atributos. Requiere un alto nivel de entrada de los humanos. Enfatiza en el anlisis de las claves candidata ms que en el delas principales. Proceso automatizado completamente para SQL

El mecanismo que proponemos en nuestro modelo est basado en el propuesto por Hainaut[16], el cual consta fundamentalmente en la obtencin de las tablas y/o entidades y sus relaciones.

262

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004

Se genera un modelo completo con la descripcin de las estructuras estticas y dinmicas del sistema real. Se trata de una etapa relativamente fcil respecto a la recuperacin de las estructuras estticas, pero lo realmente complejo y difcil de abordar de una forma totalmente precisa son la recuperacin de las reglas de integridad. Es en este apartado como hemos comentado anteriormente es donde se conjugar la utilizacin de cdigo fuente, para ver estructuras condicionales respectos a datos del modelo, y por supuesto del usuario el cual puede aportarnos informacin muy sensible e importante. Para la obtencin de las estructuras podemos seguir los pasos descritos por Premerlani (Premerlani, 1994), que considera que cada fichero es una posible tabla y cada campo del fichero ser un campo de la tabla.

a) Identificar un conjunto de campos que puedan ser la clave principal para sus respetivos ficheros. En esta fase puede ser de utilidad la participacin del usuario, aunque es cierto que pueden existir ficheros que no pertenezcan al modelo y que se utilicen simplemente como almacn de datos temporales, etc. b) Determinar las llaves externas, que sern habitualmente del mismo tipo que sus correspondientes en la tabla principal. En esta fase es muy interesante apoyarnos en el estudio del cdigo fuente y en las instrucciones donde se asigne a un campo el contenido del campo de otra tabla, o que se comparen campos de distintas tablas, etc. Es una forma de encontrar posibles relaciones y asociaciones entre las tablas. c) Determinar qu ficheros encontrados pueden dejar de considerarse como tablas. Por ejemplo, aquellos que no se haya podido determinar campo clave. d) Buscar y encontrar generalizaciones, que puede hacerse mediante la localizacin de grandes grupos de claves ajenas. As podemos decir que una clave formada nicamente por claves ajenas suele indicar una relacin de esta tabla o entidad con n entidades, formando por tanto una relacin de grado n+1.

263

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004

e)

Encontrar asociaciones mediante la repeticin de campos en una tabla. Si en un determinado campo se encuentra repetido un dato que aparece en otra tabla, podemos indicar que existe una relacin entre ellas.

En todas estas fases es fundamental la ejecucin de consultas para comparar los resultados con los esperados, o incluso con datos que se hayan obtenido en ejecuciones del sistema de informacin anterior.

En este punto, alguien nos podra preguntar qu grado de participacin tiene el usuario. Evidentemente tiene una gran participacin, que es la de determinar si un objeto externo (Leiva, 2003; Leiva, Guevara 1998) es almacenable o no. Estas decisiones no son siempre certeras, pues como hemos comentado en ms de una ocasin el usuario puede cometer errores, pero realmente es una informacin muy valiosa la que nos proporciona. Una vez que hemos detectado las tablas y su estructura, podemos utilizar la siguiente notacin: RESERVA[Nmero, FechaReserva, CodCliente, NmFactura] donde en

maysculas aparece el nombre de la tabla, y entre corchetes los campos de dicha tabla.

4. Participacin del usuario en el proceso de Reingeniera

En nuestra metodologa de reingeniera de sistemas el usuario participa en la primera etapa de Extraccin acumulativa, y utiliza unas herramientas1 para ir

describiendo las distintas interfaces y procesos del sistema de informacin antiguo. El cmo participa en el desarrollo del modelo de datos es lo que vamos a describir brevemente en este punto. Podemos dividir la tarea del usuario en dos etapas: a) Descripcin en las distintas intefaces de qu datos son sensibles de pertenecer al modelo de datos.(Objetos externos) b) Consultar y modificar el modelo de datos obtenido.

Actualmente en fase de mejora 264

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004

En la primera etapa la participacin del usuario como comentamos en el punto anterior viene a cubrir posibles lagunas que la herramienta automtica que se encarga de la ingeniera inversa pueda tener, mientras que en la segunda el usuario realiza el papel de diseador para adaptar el modelo de datos anterior a las nuevas necesidades que hayan podido surgir. Deteccin de los campos y procesos en una pantalla. La forma en la que el usuario o la herramienta automtica puede detectar los campos de una tabla en alguna pantalla puede realizarse de dos formas distintas: a) Deteccin de los campos mediante los objetos externos: a la hora en la que el usuario tenga que describir la apariencia externa de cada una de las interfaces, lgicamente tendr que expresar aquellos objetos externos que hay en dichas pantallas. Puede darse el caso muy habitual en el que alguno de los objetos externos corresponda con un campo denominado almacenado o calculado-almacenado (Leiva, 2003; Leiva, Guevara ,1998)de alguna tabla en este caso puede que entre la informacin que suministra el usuario venga esta caracterstica. En caso que el usuario no sea capaz de detectar esta caracterstica mediante el cdigo fuente asignaremos a cada uno de los objetos externos que sean del tipo almacenado o calculado-almacenado su pertenencia a cada tabla. As, por ejemplo el usuario puede detectar como campos almacenados datos de cliente como pueden ser DNI, Nombre, Apellidos, etc. y campos calculado-almacenado como puede ser Total Factura. b) Deteccin de campos mediante el objeto tabla: es cierto que en algunas aplicaciones aparece en la pantalla un listado de registros. En este caso podemos hacer que si dicho listado corresponde con valores almacenados en una tabla, utilicemos el objeto tabla en la pantalla, en caso que la lista no corresponda con valores almacenados utilizaremos el objeto lista a la hora de describir la pantalla. Un ejemplo, puede ser una lista de habitaciones con las caractersticas de las habitaciones del hotel, o una lista de bebidas que se ofertan en el servicio de bar, etc.

265

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004

A partir de estas caractersticas podemos indicar que en una pantalla podemos encontrar datos correspondientes a una pantalla o a varias pantallas. Generalmente cuando en una pantalla aparece informacin relativa a ms de una tabla, es que entre ellas existe algn tipo de relacin. Son extraos los casos en los que no sucedera esto, de todas formas dicha casustica debemos tenerla en cuenta, pero lo ms habitual al encontrar en una pantalla informacin relacionada de otras tablas es que exista algn tipo de relacin. Es importante subrayar que esas relaciones pueden haberse ya detectado en la etapa de ingeniera inversa. Por tanto, habr que detectar el tipo de relacin existente (tambin puede detectarse en algunas sentencias de algunos lenguajes) para obtener un modelo entidad/relacin lo ms correcto posible. Esto no solamente ser til para el proceso de ingeniera inversa en s, sino que en caso de necesidad de mejoras ser muy importante, ya que pueden existir nuevas necesidades que puedan implicar la creacin de nuevas tablas, o nuevos campos, etc. Otro aspecto que los usuarios tendrn que determinar son los procesos, entre los cules podemos destacar como ms habituales: Alta u operacin de creacin de nuevo registro. Baja o eliminacin de un registro a partir de una condicin. Baja o eliminacin de un grupo de registros a partir de una condicin. Baja o eliminacin de un registro o registros visibles en pantalla. Consulta de un nico registro a partir de una condicin. Consulta de un grupo de registros a partir de una condicin. Visualizacin de un nico registro. Visualizacin de varios o todos los registros. Modificacin de un registro o registros visualizados en pantalla. Modificacin de un registro o registros a partir de una condicin. Reorganizar archivo (en algunos lenguajes de programacin). Obtencin de resultado a partir de los campos. Descripcin de nuevas caractersticas.
266

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004

Un aspecto muy interesante a resaltar es el proceso de reingeniera apoyado en los usuarios. En este punto suministramos a los usuarios una herramienta de anlisis y diseo, que permita a los usuarios (en concreto a aquellos que pertenecen al sistema de informacin que esta siendo sometido a proceso de ingeniera inversa y/o reingeniera) expresar sus ideas de informacin en un conjunto de formularios interrelacionados entre s, y que se apoyarn en una base de datos que contendr la informacin obtenida en los procesos anteriores y que redundar en unos formularios, los cules podrn ser modificados por los usuarios. Esta tarea redundar en una mayor comunicacin entre los usuarios en base a formatos electrnicos. El usuario puede proponer no solamente nuevos campos en formularios (tablas) ya existentes, sino que incluso puede disear entidades nuevas e interrelacionarlas con otras, etc. El sistema que proponemos converge a ser totalmente correcto por refinamientos sucesivos, ya que en el peor de los casos, se comporta como los formularios normales. La solucin al problema de la comunicacin entre usuarios se dar mediante la comparticin de informacin, y una visin cooperativa de toda la labor de diseo de los usuarios. La herramienta que lo soporta, permite que el usuario pueda no solo definir estructuras, sino tambin imponer restricciones. Una vez incorporada las nuevas funciones al modelo de datos obtenido de la herramienta de ingeniera inversa y las aportaciones de los usuarios, podemos tener un modelo de datos del que puedan obtenerse sus especificaciones, y tambin las sentencias para crearlas en el nuevo sistema. Se crearn tambin rutinas automticas que permitan realizar tambin el trasvase de datos. Es fundamental que se pruebe el nuevo sistema y que cumpla todas las caractersticas deseadas.

5. Conclusiones
La utilizacin de una herramienta que permita que el usuario vuelque informacin sobre la aplicacin original, es de vital importancia en el proceso de
267

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004

reingeniera, pues no solo se obtienen unas especificaciones formales del modelo de datos, sino que debe potenciarse el que los usuarios puedan modificar el modelo de datos para adaptarlo a nuevas necesidades. Pensamos, que el trabajo cooperativo en la participacin del usuario puede ser un elemento de gran trascendencia, pues conlleva muchas ventajas, entre las que destacamos: Modelado formal de interfaces, procesos y modelos de datos, que permitir una reingeniera del sistema de informacin. Simulacin de los procesos, modelos de datos e interfaces. Aumento de la calidad. Disminucin de costes. Incremento en el cumplimiento de los requisitos de los clientes.

Bibliografa
G.PIATTINI, CALVO-MANZANO, CERVERA, FERNNDEZ (1996). Aplicaciones Informticas de Gestin. Ed. Rama LEIVA, J.L., GUEVARA A (1998). Metodologa para reingeniera de Sistemas. Actas IV Jornadas de Informtica. GUEVARA A., AGUAYO A., FALGUERAS J., TRIGUERO F. (1995) User participation in information systems development techniques and tools. ACM SIGOIS Bolletin, vol. 16, n1, , pp14-21. CSABA LSZL.(1997) Experience with User Interface Reengineering. IEEE 4th Working Conference on Reverse Engineering pp 150-155 PEA, R.(2000) Diseo de Programas. Prentice-Hall BABURIN, D.(2002) Using Graph Bases Representations in Reengineering. CSMR Sixth European C oference on Software Maintenance and Reengineering. pp.203-207 HENRY, E. et al. (1995) Large-scale Industrial reuse to reduce cost and cycle time. Matra Cap System. IEEE Software, pp.47 LEIVA, J.L.(2003) Construccin de especificaciones de interfaces en un modelo de reingeniera. CISCI 2003, Orlando, USA. HAINAUT, J.L., HENRAD, J.(1994) Database design recovery. Proceedings of the entity-relationship Approach, ER94. Loucopoulos (ed). PREMERLANI, WILLIAM.(1994) An approach for reverse engineering of relational databases. Communications of the ACM, vol n37.

268

V Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones TuriTec 2004 GLVEZ, SERGIO. (2000)Tesis Doctoral. Participacin del usuario en el diseo cooperativo de bases de datos. Metodologa y herramientas. Universidad de Mlaga. HAUSI, A. MLLER, JENS H. JAHNKE, DENIS B. SMITH, MARGARET-ANNE D. STOREY, SCOTTR. TILLEY, KENNY WONG (2000): Reverse Engineering: A Road map. The future of Software Engineering Track at the 22 nd International Conference on Software Engineering (ICSE 2000), Limerick, Ireland.

269