Figura 1. Esquema de Transformación a nivel de Metamodelos.
Figure 1. Transformation Scheme at Metamodel Level
Se tiene entonces como Metamodelo Fuente el Metamodelo del Modelo de Clases de UML 2.0, especificado por la OMG, y como Metamodelo Destino u Objetivo una versión Simplificada del Metamodelo de la Plataforma Oracle9i®, elaborado específicamente para esta propuesta.
La metodología a seguir para la transformación de modelos definiendo las reglas a nivel de metamodelo será la siguiente:
- Recolección en lenguaje natural de las reglas de transformación del Modelo de Clases UML al Modelo Objeto-Relacional de Oracle9i®, a partir de diferentes fuentes.
- Estudio y simplificación del Metamodelo Fuente: Metamodelo del Modelo de Clases de UML2.0, extrayendo sus características más recurrentes en los diagramas construidos por los analistas de software como los atributos derivados y las relaciones de asociación, composición y generalización entre Clases.
- Diseño de un Metamodelo simplificado del Sistema Manejador de Bases de Datos Oracle9i® en el que se especifican las características objeto – relacionales de las que se saca provecho en la transformación de modelos.
- Selección de un conjunto básico de reglas verbales para transformar el Modelo de Clases UML al Modelo Objeto-Relacional en las que se contemplan aspectos del Modelo de Clases como atributos derivados y relaciones de asociación y generalización para adaptarlas a nivel del Metamodelo. ]]> Formalización y aplicación de las reglas seleccionadas al caso práctico de estudio. Para estas actividades se toma como entrada una instancia del Metamodelo de Clases de UML, y como salida, se obtiene una instancia del Metamodelo de Oracle9i® considerablemente cercana a su implementación en dicha plataforma, expresada también en UML.
En la sección siguiente se introducen los aspectos fundamentales del Metamodelo de UML, con el fin de iniciar el proceso de transformación.
3. METAMODELO DE UML
UML es el lenguaje unificado de modelamiento propuesto por el OMG para la especificación de sistemas informáticos [5]. Este lenguaje de propósito general, que puede ser utilizado para la descripción de sistemas de diversos dominios, provee simultáneamente mecanismos de extensión, para que pueda adaptarse de manera óptima a un área de aplicación particular.
Ahora, los metamodelos son modelos que especifican la estructura, semántica y restricciones de una familia de modelos [6]. Por ejemplo, el Metamodelo del Diagrama de Clases UML especifica todos los elementos que puede contener este Diagrama (Clases, Operaciones, Clases de Asociación) y las relaciones que se pueden establecer entre ellos (Asociaciones, Composiciones y Generalizaciones). El Metamodelo de UML está especificado en MOF (Meta Object Facility) [7], que corresponde al lenguaje de metamodelamiento estándar del OMG. Este metamodelo provee mecanismos de extensión que permiten añadir elementos (como clases y relaciones) si se considera necesario; además, esos mecanismos permiten el uso de perfiles UML que brindan la posibilidad de extender un metamodelo existente con construcciones propias de un dominio particular sin modificar el Metamodelo original de UML [8].
La especificación de la versión más reciente de UML (versión 2.0) incluye el Metamodelo correspondiente a varios de los diagramas que se pueden representar con este lenguaje como son: El Diagrama de Clases, de Transición de Estados y de Actividades [5].
Este artículo se centra en el Metamodelo del Diagrama de Clases, siendo éste último el Modelo Independiente de la plataforma que se va a transformar en un modelo Dependiente de la Plataforma Oracle9i®. El Metamodelo del diagrama de Clases gira alrededor de la Metaclase Class que describe las características que debe poseer una clase de este Diagrama. En la Figura 2 se presenta la estructura de herencia de la Metaclase UML Class, y en la Figura 3 todas las relaciones con otras Metaclases del Metamodelo del Diagrama de Clases.
Figura 2. Estructura de Herencia de la Metaclase Class ]]>
Figure 2. Inheritance Structure of Metaclass Class.
Figura 3. Relaciones de la Metaclase UML Class
Figure 3. Relationships of UML Metaclass Class
Dada la complejidad del Metamodelo del diagrama de Clases de UML, para este trabajo se toma como Metamodelo Fuente una versión simplificada que incorpora sólo los elementos necesarios para describir la transformación al Modelo Objeto-Relacional. En particular, se describen las Clases, los Atributos, las Operaciones y las diferentes relaciones que se pueden establecer entre las Clases: generalización, asociación, agregación y composición; además de la definición de invariantes o restricciones sobre los Modelos de Clases [5].
En la Tabla 1 se describen los atributos de la Metaclase Class que se tienen en cuenta para la transformación al Modelo Dependiente de la Plataforma Oracle9i® y en la Figura 4 se presenta el Metamodelo Simplificado para la Clase UML Class que los contiene.
Tabla 1. Atributos seleccionados de la Metaclase UML Class
Table 1. Selected Attributes of UML Metaclass Class
Figure 4. Simplified Metamodel of UML Metaclass Class
4. METAMODELO DE Oracle9i®
La especificación de las reglas de transformación de un Modelo de Clases Independiente de la plataforma, a un Modelo Dependiente de esta plataforma, exige la utilización de un Metamodelo que especifique un conjunto de características básicas soportadas por la plataforma; en este artículo se emplea Oracle9i® [9] como Metamodelo de llegada para la aplicación de las reglas de refinamiento. Este Metamodelo representa adecuadamente las características de la plataforma de las que se desea tomar ventaja en el proceso de traducción. Las características objeto-relacionales más relevantes que se describen en el metamodelo simplificado de Oracle9i® son:
- Tipos definidos por el usuario: El usuario puede definir sus tipos de datos complejos y asignarlos a columnas o tablas dentro del esquema de la base de datos.
- Generalización entre Tipos: Definición de relaciones de generalización entre tipos creados por el usuario, de tal manera que el tipo específico hereda todos los atributos y funciones definidas para el tipo general, tal como lo establece la teoría de orientación a objetos.
- Tipos Colección: Se tiene nuevos tipos de datos que permiten almacenar varios elementos de un tipo dado, bien sea predefinido dentro de Oracle o creado por el usuario. Estos tipos de datos son los arreglos o Varray y las Tablas Anidadas. Esta característica en particular, hace posible la definición de atributos multivaluados y se convierte en una opción a tener en cuenta al momento de decidir la implementación de asociaciones entre Clases con cardinalidad muchos.
- Referenciación de Tipos: El tipo de una columna de una tabla puede ser una referencia a un tipo creado por el usuario asociado a otra tabla de la misma base de Datos.
El Metamodelo simplificado de Oracle9i® que se elaboró para este trabajo está conformado por un Diagrama de Clases que especifica sus componentes fundamentales, tales como Tablas, Columnas, Tipos y Vistas, entre otros. El Diagrama, que se muestra en la Figura 5, va acompañado por una explicación relativa a sus Metaclases y sus atributos siguiendo el mismo esquema de definición del Metamodelo de UML 2.0. Las reglas de consistencia de la especificación Oracle9i® se pudieron expresar por medio del (Meta) diagrama de clases, definiéndolas en el lenguaje OCL [10] como restricciones.
]]>
Figura 5. Diagrama de Tablas Oracle9i®
Figure 5. Oracle9i® Tables Diagram
En el Diagrama de la Figura 5 se describe una tabla como una asociación lógica de atributos o columnas, que posee un nombre y es de tipo abstracto.
Ahora, esta metaclase Tabla se especializa en las metaclases Vista y Tabla Persistente. La primera hace referencia a un elemento de Oracle9i® que agrupa un conjunto de atributos de una o varias tablas, mientras que una Tabla Persistente implica una agrupación no sólo lógica sino también física del conjunto de atributos comunes de una entidad del dominio, es decir, exige almacenamiento permanente dentro de la base de datos. Una instancia de la Metaclase Tabla Persistente posee un conjunto de atributos o columnas (atributo_tabla) y también puede tener restricciones asociadas (restricción_tabla) a uno o varios de sus atributos, que corresponden a sus reglas de cálculo o derivación.
Restricción
Las columnas que corresponden al valor del atributo clave_candidata de la Metaclase Tabla Persistente deben ser únicas y obligatorias.
context Tabla Persistente inv: self.clave_candidata->forAll(c I c.obligatorio and c.unico)
5. ADAPTACIÓN Y APLICACIÓN DE LAS REGLAS DE TRANSFORMACIÓN
Las reglas de transformación del Modelo de Clases UML a una especificación en Oracle9i® inicialmente fueron planteadas verbalmente con base en las planteadas en otros trabajos [11], [12], [13], [14], [15] y [16]. Una vez planteadas, estas reglas se deben expresar a nivel meta de tal forma que, al aplicarlas sobre cualquier Modelo de Clases, instancia del Metamodelo de Clases de UML, dicho modelo se transforme en una instancia del Metamodelo de Oracle9i®. En la Figura 6 se presenta un esquema general de la transformación.
]]>
Figura 6. Esquema de la Transformación de Modelos para el Caso de Estudio
Figure 6. Model Transformation Scheme for the Case Study
La estrategia seguida para especificar en el nivel meta las reglas de transformación, consistió en seleccionar un pequeño subconjunto de ellas y aplicarlas primero manualmente al Modelo de Clases del Caso de estudio, visto como una instancia del metamodelo UML, para transformarlo en una especificación Oracle9i®, vista como una instancia de su metamodelo.
Este ejercicio permite identificar:
- Correspondencias entre las Clases del Metamodelo Fuente y Destino.
- Atributos de las Metaclases Fuente cuyos valores determinan los valores de los atributos de las clases destino correspondientes.
A partir de estos dos criterios se pueden adaptar las reglas de transformación llevándolas al nivel Meta y finalmente expresarlas en un formalismo lógico.
Las reglas seleccionadas se orientan a la transformación de cinco elementos básicos del Modelo de Clases de UML:
- ]]>
Clases
- Invariantes
- Atributos Derivados
- Asociaciones, incluyendo la relación de composición
- Generalización
En la Figura 7 se ilustra la Clase UML “Materia” que hace parte del Modelo de Clases del Caso de Estudio que corresponde al Sistema de Registro de asignaturas por parte de los estudiantes de una Universidad.
Figura 7. Clase UML Materia
Figure 7. UML Class Subject
Figura 8. Diagrama de Objetos de la Clase UML Materia
Figure 8. Object Diagram for UML Class Subject
A continuación se describen algunas de las reglas que fueron aplicadas a esta porción del Modelo de Clases para transformarlo en una instancia del metamodelo de la Plataforma Oracle9i®, junto con el planteamiento detallado de su proceso de adaptación a nivel de Metamodelo y posterior formalización.
Transformación de Clases a Tablas
Regla Verbal: Todas las clases no abstractas de un Modelo de Clases se convierten en tablas de un Modelo Objeto-Relacional.
Estudiando los atributos de la Metaclase UML Class (véase Tabla 1) se encuentra que, para transformar una instancia de la Metaclase UML Class a una instancia de la Metaclase Oracle Tabla Persistente (véase Figura 5), la regla de transformación debe verificar que:
- El atributo isAbstract de la instancia de la clase a transformar debe ser falso.
- La instancia de la Metaclase UML Class que se quiere transformar no participa en ninguna relación de generalización, ni como Clase general ni como especialización de otra clase, porque la herencia entre Clases en Oracle9i®, en el marco de este trabajo, se maneja tomando ventaja de la generalización entre tipos creados por el usuario. Por esta razón el atributo generalization de la Metaclase UML Class no puede tener asociado ningún valor. ]]>
- Afinamiento de la formalización de las reglas de transformación para que puedan ser aplicadas automáticamente en la herramienta UN-MetaCASE.
- Desarrollo de un traductor de OCL a PL/SQL como alternativa para incorporar aspectos dinámicos del Modelo de Clases a la generación de código, mas allá de la definición del “esqueleto de los métodos”, como ocurre actualmente en las herramientas CASE tradicionales.
- Aplicación de los lineamientos básicos propuestos por MDA para transformar Modelos Independientes de la Plataforma a Modelos dependientes de otras plataformas (.NET, J2EE) garantizando interoperabilidad a través de la existencia de un lenguaje único de modelado que se puede extender con terminología propia de cualquier plataforma orientada a objetos.
- Ampliación del enfoque propuesto para el refinamiento de modelos a otros modelos UML de entrada como el Diagrama de Transición de Estados y el Diagrama de Colaboración.
- Construcción de un Perfil UML como “puente” entre el Metamodelo Origen y Destino que facilite la especificación de las reglas de transformación entre modelos [8], [17]. ]]>
A partir del Metamodelo Simplificado de la Figura 4 para la instancia de la Metaclase UML Class con nombre Materia se obtiene la Tabla 2.
Tabla 2. Evaluación de la Clase UML Class
Table 2. Evaluation of UML Class Class
La Clase UML “Materia” cumple con las condiciones 1 y 2, transformándose en una instancia de la Metaclase Oracle Tabla Persistente (véase Figura 5), conservando el mismo nombre, como se indica en la Tabla 3.
Tabla 3. Evaluación de la Clase Tabla Persistente.
Table 3. Evaluation of Class Persistent Table.
La aplicación manual de esta regla de transformación permite identificar qué atributos de la instancia de la Metaclase UML Class son relevantes para la transformación y llegar a la siguiente expresión de esta regla a nivel de Metamodelo: Toda instancia de la Metaclase UML Class, que no participe en ninguna relación de generalización se transforma en una instancia de la Metaclase Oracle Tabla Persistente si su atributo isAbstract es falso, conservando el mismo nombre.
]]> En términos de Diagramas de Objetos la aplicación de esta regla a la Clase UML Materia arroja como resultado una instancia de la Metaclase Oracle Tabla Persistente llamada “Materia” tal como se observa en la Figura 9.
Figura 9. Correspondencia entre las Metaclases y las Instancias.
Figure 9. Correspondence between Metaclasses and Instances.
Finalmente, una vez expresada la regla a nivel de Metamodelo se lleva a un formalismo lógico equivalente haciendo uso de la teoría de conjuntos:
Transformación de Atributos a Columnas
Regla Verbal: Los atributos de una Clase se transforman en columnas de la Tabla Correspondiente en el Modelo Objeto-Relacional.
Es importante mencionar que en esta nueva especificación de UML las asociaciones entre clases se establecen a partir de atributos que pertenecen a las Clases o a las Asociaciones según la navegabilidad de las mismas, es decir, el concepto de rol en los extremos de las asociaciones se modela igual que un atributo. En consecuencia, para transformar una propiedad o atributo de una Clase en una columna de una Tabla en el Modelo Objeto – Relacional es necesario verificar que la propiedad pertenezca a una Clase y no a una asociación entre clases.
A nivel de Metamodelo esto implica que el atributo association de la Metaclase Property no toma ningún valor, es decir, la propiedad debe pertenecer a la Clase y no participar en ninguna relación de asociación. En el ámbito de Oracle9i® los atributos de la Metaclase Oracle “Atributo Estructural” a la que se llevan las propiedades que no participan en ninguna asociación se presentan en la Tabla.
]]> Partiendo ahora del Metamodelo de UML y de Oracle9i®, en la Tabla 5 se presentan los valores de los atributos relevantes de la Metaclase UML Property para las instancias código y reemplazada (véase Figura 4) así como los valores de los atributos de las instancias de la Metaclase Oracle Atributo Estructural a la que se llega por la aplicación de esta regla.Tabla 4. Atributos de la Metaclase Oracle “Tabla Persistente”
Table 4. Attributes of the Oracle Metaclass “Persistent Table”
Tabla 5. Atributos de las Metaclases UML “Property” y Oracle “Atributo Estructural”
Table 5. Attributes of Metaclasses “Property” and “Structural Attribute”
A nivel de Metamodelo la regla se expresaría así:
Todas las instancias de la Metaclase UML Property que pertenecen a una Clase y no participan en ninguna relación de asociación se convierten en instancias de la Metaclase Oracle Atributo Estructural pertenecientes a la instancia de la Metaclase Oracle Tabla Persistente, que mapea la clase a la que pertenecen, y conservan el mismo nombre.
La especificación formal de esta regla exige el uso de pre y postcondiciones como restricciones que se deben cumplir antes y después de la aplicación de regla respectivamente.
]]>
En la precondición de esta regla se utiliza la notación t=f(c) para indicar que t es una instancia de una Clase del Metamodelo de Oracle que se obtiene a partir de la aplicación de la función de mapeo f a una instancia de una Metaclase UML c. Esta función de mapeo estará conformada por una o varias reglas de transformación.
Una vez se conoce el procedimiento de adaptación de las reglas a nivel de Metamodelo la siguiente regla se enunciará a nivel de Metamodelo junto con su equivalente en lógica:
Toda restricción asociada a una Clase UML corresponde a una instancia de la Metaclase UML Constraint (véase Figura 4) y se transforma en una instancia de la Metaclase Oracle Restricción_Tabla (véase Figura 5) asociada a la instancia de Tabla Persistente correspondiente, conservando el mismo nombre.
Como resultado de la aplicación de estas reglas a la porción de Modelo de Clases presentada en la Figura 4 se obtienen: el diagrama de objetos (Figura 10), donde se observa la correspondencia de cada elemento de este Diagrama con las Clases del Metamodelo de Oracle9i® que instancian, y su correspondiente Diagrama UML Dependiente de la Plataforma Oracle9i® (Figura 11).
Figura 10. Diagrama de Objetos de la Metaclase Oracle Tabla Persistente
Figure 10. Object Diagram of Oracle Metaclass Persistent Table
Figure 11. UML Oracle9i Platform Dependient Diagram of the Table Subject
En el Diagrama UML Dependiente de la Plataforma Oracle9i® (Figura 11) Los símbolos [CP] y [CC] denotan a una columna de una tabla en Oracle como clave primaria y clave candidata respectivamente y no fueron especificados dentro del Metamodelo como notación sino elegidos como convención en el contexto del trabajo. Posteriormente en el Metamodelo de Oracle9i® pueden añadirse aspectos de notación además de los estructurales presentados en la Sección 4.
En la Figura 10 los atributos de la Metaclase Tabla Persistente cuyo valor corresponde a instancias de otras metaclases, (vinculados en asociaciones), que van acompañados por líneas punteadas son producto de las decisiones de diseño y las reglas para obtenerlas se describen de manera detallada a continuación:
Elección de la clave primaria de la Tabla Persistente
Todas las instancias de la Metaclase UML Property que pertenecen a una Clase y cumplen con ser: únicas, obligatorias, no derivadas y no participar en ninguna asociación se constituyen en claves candidatas para la instancia de Tabla Persistente que mapea la Clase correspondiente. Entre estas propiedades, que se transforman en Columnas Oracle, para cada Tabla Persistente es necesario seleccionar como mínimo una para que se constituya en su identificador o clave primaria.
Dicha decisión se deja al criterio del modelador del sistema, ya que la regla automatizable determina únicamente cuáles instancias de la Metaclase Atributo Estructural pueden desempeñar ese rol.
La instancia o instancias de Atributo Estructural elegidas son los valores del atributo clave_primaria de la Metaclase Oracle Tabla Persistente que las posee (véase Figura 5).
Implementación de columnas derivadas de Oracle por medio de Triggers
]]> La regla de derivación de una columna se implementa en Oracle por medio de un Trigger que verifica o calcula su expresión asociada y pertenece a la instancia de la Metaclase Oracle Tabla Persistente poseedora del atributo o columna derivada.En la Tabla 6 se presentan los atributos de la Metaclase Oracle Trigger observados en la Figura 5.
Tabla 6. Atributos de la Metaclase Oracle Trigger
Table 6. Attributes of Oracle Metaclass Trigger
Para este caso se asume el disparo del trigger después de insertar un registro en la tabla, con la cual se asocia a través de su atributo tabla.
El tiempo y la acción que dispara el trigger, por tratarse de un atributo derivado, se asume que es antes de insertar un registro o actualizar el valor de dicho atributo en la instancia de Tabla Persistente; sin embargo, esta decisión exige un análisis más detallado de la regla de derivación que está por fuera del alcance del trabajo.
6. CONCLUSIONES Y TRABAJO FUTURO
El estudio y aplicación de los conceptos fundamentales que soportan el refinamiento en la Arquitectura Orientada a Modelos, propuesta por el OMG, permitió determinar una estrategia adecuada para incorporar el refinamiento de modelos a las herramientas CASE UN-MetaCASE y AR2CA que consiste en definir las reglas de mapeo a nivel de los Metamodelos Fuente y Objetivo, facilitando su formalización y automatización posterior.
]]> Ahora, la aplicación manual de un conjunto básico de reglas al Modelo de Clases del Caso de Estudio mostró que su especificación en un formalismo lógico constituye una alternativa directa para su posterior automatización en el marco de una herramienta CASE, independientemente de la plataforma objetivo. La formalización de las reglas bien podría realizarse en OCL [10], que es un estándar más cercano al OMG y se constituye en un trabajo futuro que podría derivarse de este artículo.La apropiación de la estrategia de refinamiento de modelos propuesta por el OMG, para llevar Modelos Generales de un dominio de aplicación a modelos del mismo dominio orientados a una plataforma dada, sugiere la posibilidad de generar código en una plataforma a partir de su definición formal, empleando para ello los metamodelos correspondientes. Así, se podría pensar a futuro en desarrollar herramientas para la generación automática de código que reciba como entradas el Metamodelo del Modelo Independiente de la plataforma y la especificación formal de la plataforma en la que se desea obtener una codificación parcial del Sistema modelado.
Por otro lado, se verificó experimentalmente en el Modelo de Clases UML del Caso de estudio, que la utilización de OCL para la definición de invariantes y reglas de derivación de atributos, además de añadir semántica al modelo, es una alternativa para facilitar su automatización o semi-automatización en una plataforma dada. En el caso de Oracle9i®, se plantea la construcción de un traductor de OCL a PL/SQL para lograr que la transformación comprenda no sólo aspectos estructurales sino también aspectos dinámicos del Modelo de Clases UML. En lo que tiene que ver con los métodos de las Clases, resultaría interesante expresarlos en OCL en términos de pre y postcondiciones para la generación parcial de código PL/SQL en Oracle9i® o en cualquier otra plataforma, aspecto que no fue contemplado en esta etapa del trabajo.
En general, la transformación de un Modelo de Clases a un modelo dependiente de la plataforma requiere la elección de la manera como se van a implementar aspectos semánticos de modelado de UML, tales como relaciones de agregación y generalización entre clases, atributos derivados e invariantes, entre otros. Naturalmente, existen varias alternativas de implementación posible para estos aspectos y la elección de la opción más adecuada constituye un problema de optimización que será objeto de un trabajo posterior.
Como trabajos futuros a partir de esta exploración inicial de la Arquitectura Orientada a Modelos se tiene:
AGRADECIMIENTOS
Este artículo se realizó dentro del marco del proyecto 479 de COLCIENCIAS denominado “Extensiones en herramientas CASE con énfasis en formalismos y reutilización”
REFERENCIAS BIBLIOGRAFICAS [ Links ]
[2] Object Management Group. Disponible en: http://www.omg.org [Citado 12 de Noviembre de 2004] [ Links ]
[3] ANAYA, RAQUEL. AR2CA: Una Herramienta para la Construcción de componentes reutilizables a través de niveles de refinamiento. Memorias de 3das Jornadas Iberoamericanas de Ingeniería de Requisitos y Ambientes de Software IDEAS2000, 2000. [ Links ]
[4] ARANGO, F. Áreas y Líneas de Investigación, Grupo de Investigación en Informática Universidad Nacional de Colombia Sede Medellín.2003 [ Links ]
[5] Unified Modeling Language: Superestructure versión 2.0. OMG Final Adopted Specification,2002. [ Links ]
[6] MELLOR J., SCOTT K., UHL A., Y WEISE D. “MDA Distilled: Principles of Model-Driven Architecture”.Addison Wesley. 2002 [ Links ]
[7] Meta Object Facility (MOF) Specification. OMG Document: formal/2002-04-03, 2003. [ Links ]
[8] FUENTES L., VALLECILLO A . , Using UML Profiles:A case study. Workshop on Automating Object-Oriented Software Development Methods. 2002 [ Links ]
[9] Oracle Technology Network. Disponible en: http://www.otn.oracle.com [Citado 12 de Noviembre de 2004] [ Links ]
[10] UML2.0 OCL Specification. OMG Final Adopted Specification.2002 [ Links ]
[11] DUITAMA, J. FREDDY. “Transformación Automática de Especificaciones expresadas bajo un Paradigma Objetual al Esquema Relacional”. Tesis de Maestría Universidad Nacional, Sede Medellín, 1998. [ Links ]
[12] DORSEY P. , HUDICKA R. “Oracle 8 Diseño de Bases de Datos con UML” . Mc Graw-Hill. México. 1999 [ Links ]
[13] DIETRICH S. , URBAN S. Using UML Class Diagram for a Comparative Analysis of Relational, Object-Oriented, and Object-Relational Database Mappings. Arizona State University. 2002 [ Links ]
[14] MOK W. Y. , PAPER D. , On Transformations from UML Models to Object – Relational Databases. 34th Hawaii International Conference on System Sciences.2001 [ Links ]
[15] CHENNAMANENI R., GRANT E.S. Comparison and Evaluation of Methodologies for Transforming UML Models to Object-Relational Databases. University of North Dakota. 2002 [ Links ]
[16] CAVERO J., MARCOS E. Y VELA B. A methodological Approach for Object-Relational Database Design using UML . Informatik- Forschung und Entwicklung. 2004 [ Links ]
[17] BORDELEAU F., ZAMORA J. P., Defining UML Profiles and Model Mappings in the context of MDA. Worshop on Model-Driven Embedded Systems. Washington. 2003 [ Links ] ]]>