Introduccin.

En 1983 Balzer soaba con un sistema capaz de programar

aplicaciones automticamente, sin fallos y sin tener que realizar un
mantenimiento sobre el cdigo fuente. Hoy en da ese sueo se ha
cumplido.
Durante los ltimos aos grandes lneas de investigacin han
dedicado la mayor parte de sus esfuerzos en convertir en un hecho el
paradigma de prototipacin automtica o de Balzer. Finalmente, se
puede obtener un prototipo automticamente a partir de una
especificacin. Pero... Qu pasa con los datos de esas aplicaciones?
Durante la vida de un sistema de informacin los
requerimientos cambian, y las aplicaciones estn condenadas a
evolucionar para dar soporte a los nuevos requisitos; al mismo
tiempo, y paralelamente, las bases de datos van poblndose con
datos. Estos datos constituyen la parte ms valiosa del sistema de
informacin.
Los sistemas de evolucin actuales soportan la evolucin de
esquemas conceptuales, generando las aplicaciones y las bases de
datos; pero no migran la poblacin de las bases de datos de esos
esquemas. Ver figura 1.

Presentacin

Presentacin

Lgica Negocio

Lgica Negocio

Persistencia

Persistencia

BD
1

BD
2

Figura1: Capas de evolucin en el software.

Actualmente, el problema de la migracin es tratado de forma
manual, mediante ristras de sentencias SQL, o a un nivel ms
elevado, mediante la construccin de aplicaciones que son capaces
de migrar datos entre dos instancias concretas de esquema
conceptual (cuando el sistema vuelve a evolucionar, estas
aplicaciones son inservibles). Otra forma ms reciente de abordar el

problema es la migracin asistida mediante los transformadores

comerciales, los cuales son capaces de migrar datos entre tablas de
distintos formatos; ejemplos de ellos son DTS de SQL Server, FileAid o
ReTarGet. El principal problema de estas herramientas, es que no
tienen en cuenta las restricciones de integridad de las bases de datos,
ni tampoco son capaces de modificar los datos durante la
transformacin.
El problema todava puede complicarse ms cuando hablamos
de los Legacy Systems, los cuales suelen ser sistemas que llevan
funcionando aos, y que por lo tanto tienen sus bases de datos llenas
de informacin. Cuando se habla de evolucionar un sistema legado,
se debe entender que la evolucin debe ser tanto de aplicaciones
como de datos.
Podemos concluir que no tiene sentido abordar el problema de
la prototipacin automtica sin dar soporte a la evolucin paralela de
los datos. Se hace imprescindible para abordar el problema el
establecimiento de un soporte metodolgico para la migracin de
datos.
En el presente trabajo se va a presentar una forma de abordar
el problema de la migracin de datos en un contexto de prototipacin
automtica.
Presentacin del problema.
Vamos dar por hecho gran parte del trabajo y a comenzar
directamente por la migracin de datos. Es decir, vamos a partir de
un sistema capaz de prototipar automticamente una aplicacin y
una base de datos a partir de un esquema conceptual. Partiremos de
OO-Method tal y como se encuentra actualmente en su versin
utilizada en la industria.
OO-Method es capaz de abordar la evolucin de aplicaciones,
pero no lo es tanto en la evolucin de datos. A partir de un esquema
conceptual modelado con OO-Method podemos obtener una
aplicacin y su base de datos automticamente; si los requerimientos
cambian, no hay ms que remodelar el esquema conceptual y
regenerar automticamente la nueva aplicacin con su base de datos.
El problema se produce cuando la aplicacin anterior haba sido
utilizada y su base de datos estaba poblada con informacin. Es
evidente que esta informacin es valiosa y no puede perderse, por
tanto debe migrarse a la nueva base de datos; pero las dos bases de
datos tienen formatos distintos y todava peor restricciones
semnticas distintas. Por tanto, no basta una simple copia de una
base de datos a la otra, sino que se le debe dar un tratamiento a la
migracin.

Un problema tpico se produce cuando se define una nueva

restriccin de integridad sobre los datos. A modo de ejemplo:
Base de datos inicial

Base de datos

final
Nombre
Juan
Luis
Marcos

Edad
22
34
17

Nombre
Juan
Luis

Edad
22
34

Nueva restriccin de integridad: Los clientes deben tener ms

de 20 aos.
En este caso la poblacin migrada de la base de datos inicial a
la final debe ser un subconjunto de los datos; solo debern migrarse
aquellos datos que cumplan las restricciones de integridad. Y que
hacemos con los dems datos? Deber avisarse al usuario de su
inconsistencia, y l decidir si se deben despreciar, o deben ser
tratados para poder cumplir las restricciones de integridad.
Este problema no es ni mucho menos un problema infrecuente,
sino que se da prcticamente en casi todas las evoluciones de
esquemas. Sin embargo, OO-Method no proporciona ningn soporte
metodolgico que resuelva la migracin de datos.
Tratamiento del problema.
Para abordar el problema de la evolucin de datos en el
contexto OO-Method, debemos tener presentes las siguientes
consideraciones:
1) Se dispondr de los esquemas conceptuales inicial y final, y
de las bases de datos generadas automticamente a partir
de esos esquemas. Por lo tanto la migracin consistir en
leer datos de la base de datos inicial e insertarlos en la base
de datos final.
2) Puede ocurrir, y de hecho ser frecuente, que exista una
parte de la poblacin de la base de datos origen que no
pueda ser migrada porque no cumple las restricciones de
integridad.
3) Sera interesante que al mismo tiempo que se migran datos,
se pudiera fijar una funcin de transformacin sobre los
mismos.

4) Del mismo modo que cambian los requisitos sobre las

aplicaciones, cambian los requisitos sobre los datos. Los
datos son de y para el usuario, y el debe decidir que
poblacin debe ser migrada.
La migracin de datos se debera realizar cada vez que se
realiza una evolucin de esquema conceptual (ver figura 2). Pero
puede darse el caso de que se quieran realizar sucesivas migraciones
entre dos cambios de esquemas con el fin de migrar la poblacin
paulatinamente.

Mo
d1

EC1

BD
1

EC2

Mig 1

BD
2

Mod
2

Mig 2

EC3

BD
3

Mod
3

Mig 3

EC4

BD
4

Figura2: Proceso de evolucin de aplicaciones y datos.

Diseo de la solucin.
Vamos a intentar solucionar el problema de una manera
elegante, y que por otro lado es la manera ms sensata posible; esto
es, modelando la solucin con el propio OO-Method, y generando
automticamente la aplicacin que resuelve el problema.
Para poder modelar la solucin, deberamos establecer primero
una metodologa para abordar la migracin de datos. En primer lugar,
toda migracin debera pasar por los siguientes pasos:
-

Comparar dos Esquemas Conceptuales.

Obtener las Diferencias.
Proponer un Plan de Migracin.
Facilidades de Edicin al analista.
Traducir el Plan de Migracin.
Ejecucin.

- Localizacin de Inconsistencias
.
A partir de una comparacin entre los esquemas conceptuales
inicial y final, se obtienen las diferencias y se propone un plan de
migracin entre las bases de datos. Este plan no tiene porque ser el
que el analista quiere, puede ser editado y cambiado. Una vez se
tiene el plan de migracin, se traduce en sentencias de
transformacin (SQL, DTS...) y se ejecuta la migracin. Finalmente,
debe haber una fase de localizacin de inconsistencias, y de aviso al
analista de que poblacin ha sido migrada, y que poblacin queda por
analizar para su posterior migracin.
En segundo lugar, se debe tener en cuenta que, una vez
generada la aplicacin en algn lenguaje de programacin como
pueda ser Visual Basic, quedarn por implementar manualmente los
mtodos algortmicos de comparacin de esquemas, y el compilador
del plan de migracin.
En tercer lugar, est el hecho de que de todos los elementos de
los esquemas conceptuales solo debemos considerar para la
migracin aquellos que tengan una repercusin sobre las bases de
datos.
En nuestro caso esos elementos son los siguientes:
-

Clases
Atributos
Relaciones de Agregacin
Relaciones de Especializacin

Por otro lado, se ha tomado la decisin de diseo de considerar

un esquema conceptual como un rbol etiquetado. De esta manera,
la comparacin de esquemas conceptuales se convierte en una
comparacin de rboles, lo cual simplifica bastante la tarea. En la
figura 3 se puede observar la representacin de un esquema
conceptual en forma de rbol.

ARBOL
EC

Clase
1

Atribu
to 1

..
.

..
.

Atribu
to k

Clase
i

Restri
c. 1

Relaci
n1

..
.

..
.

Restri
c. n

Relaci
Relacin
j nj

Figura3: Representacin de un esquema conceptual en forma de

rbol.
Tal y como se puede observar en el rbol presentado, las
restricciones de integridad vendrn siempre asociadas a las clases del
modelo. Por otro lado, las relaciones siempre sern entre clases,
puesto que se trata de relaciones de especializacin y de agregacin.
Es obvio que solo con el modelo conceptual no tenemos todo el
trabajo hecho, faltaran por determinar muchos aspectos de la
herramienta. Podemos dividir la herramienta en tres partes con
funcionalidad muy diferente: un comparador de esquemas
conceptuales, un editor de planes de migracin y un compilador
traductor de esos planes de migracin.
Quedaran pues, por determinar los lenguajes de comunicacin
entre las partes, es decir, el comparador de esquemas necesita un
lenguaje de diferencias para comunicarle su resultado al editor de
planes de migracin, y este a su vez necesita un lenguaje que sea
capaz de entender el compilador y que tenga una expresividad
suficiente para especificar cualquier plan de migracin.
Tambin habra que resolver la problemtica de determinar
algoritmos de comparacin de rboles, y criterios de comparacin
para esos algoritmos; esto es, comparacin por nombre, por Oid
(Object Identifier), por similitud de atributos, etc.
En cualquier caso, vamos a pasar por alto todos estos aspectos,
y nos vamos a centrar en la arquitectura de la herramienta y en su
modelado conceptual.
A continuacin se va a presentar el modelo conceptual del
migrador de datos basndonos en las consideraciones anteriores.
Modelado conceptual.
El siguiente diagrama muestra el modelo conceptual del cual
ser generada automticamente la herramienta de migracin. El
esquema ha sido modelado con Rational Rose por razones de
confidencialidad de OO-Method, pero durante la creacin del proyecto
real, este mismo modelo deber ser modelado con OO-Method.

Figura4: Modelo de datos UML generado con Rational Rose.

Ntese que la estructura del modelo viene determinada por la
representacin en rbol del esquema conceptual.
De seguido se presenta la explicacin del modelo de datos
anterior.
Clase Esquema Conceptual:
nicamente tiene un mtodo, Obtener Esquema Conceptual, el cual
es el encargado de inicializar un nuevo esquema conceptual y
cargarlo en las estructuras de datos de memoria para poder ser
comparado. El atributo Nombre indica el nombre del esquema.
Clase Clase:
Representa las clases del esquema conceptual. Sus atributos
relevantes de cara a la comparacin son Oid y Nombre, los cuales
representan el identificador y el nombre de la clase.

Clase Atributo:

Igual que el anterior; representa los atributos de las clases del

esquema conceptual.
Clase Agregacin:
Representa las relaciones de agregacin del esquema conceptual. Sus
atributos relevantes de cara a la comparacin son Oid y las clases
agregada y componente de la agregacin, adems son interesantes
las cardinalidades.
Clase Especializacin:
Representa las relaciones de especializacin del esquema conceptual.
Sus atributos relevantes de cara a la comparacin son Oid y las clases
padre e hija de la especializacin, adems son interesantes las
cardinalidades.
Clase Comparacin:
Representa el comparador de esquemas. Toda la funcionalidad de la
herramienta, es implementada mediante los servicios de esta clase.
Entre ellos estn:
- Comparar por Oid: Establece un mapeo de elementos por Oid.
- Comparar por Nombre: Establece un mapeo de elementos por
nombre.
- Establecer correspondencia: Establece una correspondencia de
Oids entre los
elementos de ambos esquemas. Utilizable
cuando se trata con bases de datos legadas.
- Generar comparacin: Genera las diferencias entre los
esquemas conceptuales, una vez ya se ha establecido un
mapeo con los anteriores servicios.
Como puede apreciarse, una comparacin siempre se realiza entre
dos esquemas conceptuales. Por otro lado, se observa que esta clase
es la clase compuesta de la clase Mapeo, la cual representa el
mapeado entre elementos de los esquemas como veremos a
continuacin.
Clase Mapeo:
Un mapeo viene a ser una tabla de dos columnas con los Oids de los
esquemas que se comparan. En una columna se dispondrn los Oids
del esquema inicial, y en otra los de la final. El resultado es una
perfecta identificacin de los objetos de ambos esquemas.
Esta clase se agrega a su vez en parejas de objetos comparables.
Clase Pareja Oids:
Cada pareja de Oids viene ser una pareja de objetos comparables de
ambos esquemas. Puesto que se utiliza su Oid para comparar,
tenemos asegurado que los objetos estarn perfectamente
identificados.

Clase Objeto Comparable:

Como ya se haba especificado anteriormente, los objetos
comparables de ambos esquemas sern aquellos que tengan una
repercusin directa sobre los datos; esto es las clases, los atributos,
las relaciones de especializacin y las relaciones de agregacin.
Una vez generada automticamente la aplicacin tan solo
quedara refinar el cdigo generado y aadir la parte puramente
algortmica a los mtodos correspondientes.
Conclusiones.
Los sistemas estn condenados al cambio y a la evolucin. Por ello
deben ser diseados con el pensamiento constante de que hoy el
sistema es completo pero maana no lo ser porque habrn
cambiado los requerimientos que sobre l pesaban.
Durante la vida de un sistema de informacin, las bases de datos
van poblando con datos, y estos datos son la parte ms valiosa del
sistema de informacin. Por ello, parece poco sensato tratar la
evolucin de sistemas de informacin olvidando la evolucin de la
propia informacin: los datos.
Para tratar el problema de la evolucin de datos en un contexto de
prototipacin automtica, debemos preguntarnos hasta que punto es
posible automatizar el trasvase de informacin entre bases de datos
de sistemas con distinto esquema conceptual. Es evidente que
siempre pueden existir datos que, por su naturaleza, solo tenan
sentido en el sistema antiguo, y que por tanto no podrn ser
migrados al nuevo sistema si no sufren una transformacin. Esta
transformacin en algunos casos no podr ser generalizada sino que
deber darse un trato especial a cada dato o tipo de dato del sistema.
Por todo ello, se hace necesaria la interaccin del usuario con la
herramienta para resolver el problema; con lo cual, la migracin en
algunos casos no podr ser totalmente automatizada. En este
documento se ha presentado una manera de abordar el problema
teniendo en cuenta todos estos aspectos.
Aunque el problema que aqu se ha tratado, ha sido resuelto
mediante la herramienta OO-Method, debe quedar patente que
cualquier otro generador de cdigo como OmTroll, OBLOG, etc. podra
haber resuelto el problema de la misma forma. Con esto se quiere
decir que cualquier herramienta que desarrolle software siguiendo el
paradigma de prototipacin automtica, presenta el mismo problema
de la evolucin de datos, y dicho problema debera ser resuelto de la
misma manera que se resuelve el de la evolucin de esquemas.
En cualquier caso, no podemos pensar que el problema queda
totalmente resuelto, puesto que siempre podramos pensar en
posibles mejoras, como puede ser la automatizacin de la reparacin

de inconsistencias que se producen al migrar datos que no cumplen

ciertas restricciones de integridad; o como contemplar la posibilidad
de que existan datos migrados en estado inconsistente, y este hecho
est contemplado en el modelo dinmico del esquema conceptual. De
esta forma, podra definirse una transicin de estado entre un estado
inconsistente y uno consistente, y los datos solamente podran ser
utilizados en el consistente...
Por otro lado quedan los Legacy Systems. La herramienta podra
llegar a ser poderossima si se consiguiera generar un esquema
conceptual a partir de una base de datos legada. Si as fuera,
podramos llegar a migrar poblacin entre sistemas de distinta
naturaleza. Los sistemas evolucionaran, y los datos seguiran el
mismo curso consiguiendo que los programas se adaptaran a los
cambios de requerimientos, conservando la valiosa informacin. Pero
este es otro sueo como el que tuvo Blazer en 1983 y que seguro que
en un futuro ser el presente.
Referencias.
[1]Ramos I., OASIS/OO-METHOD: Un Mtodo Orientado a Objetos para
la produccin automtica de cdigo. DSIC 1996.
[2]Letelier P., Snchez P., Ramos I., Pastor O. OASIS 3.0: Un enfoque
formal para el modelado conceptual orientado a objeto. Servicio de
Publicaciones, Universidad Politcnica de Valencia, SPUPV
-98.4011, ISBN 84-7721-663-0, 1998.
[3]Cars J.A., OASIS como marco conceptual para la evolucin del
software, Tesis Doctoral, Departamento de Sistemas Informticos y
Computacin, Universidad Politcnica de Valencia, 1999.
[4] Letelier P., Generacin de Cdigo a partir de Modelos de Objetos:
Estado del Arte. DSIC 1999.