Integración de Rational Software Architect y Rational Data Architect

Logre que su modelo de aplicación y de datos funcionen juntos

El Desarrollo de software dirigido por modelos generalmente comienza con el modelado de aplicaciones o de datos. Ambos están estrechamente relacionados y se complementan entre sí. IBM ha reconocido la importancia de integrar estos modelos en el desarrollo de software dirigido por modelos y ha desarrollado las transformaciones de Lenguaje Unificado de Modelado (Unified Modeling Language, UML) a Modelo de Datos Lógicos (Logical Data Model, LDM) y las transformaciones de LDM a UML. Estas transformaciones integran el modelado de aplicaciones utilizando Rational Software Architect (RDA) y el modelado de datos utilizando Rational Data Architect (RDA). Este artículo brinda una rápida descripción general de RSA y RDA, explica los pasos clave en tres escenarios de integración RSA-RDA y describe las transformaciones de UML a LDM y de LDM a UML y el UML Logical Data Model Profile. [2009 Abr. 17: Nota agregada sobre el cambio de nombre del producto Rational Data Architect a InfoSphere Data Architect. --Ed.]

Daniel T. Chang, Senior Software Engineer, Information Management, Data Tools, IBM

Daniel T. Chang es Senior Software Engineer en IBM Silicon Valley Lab. Trabaja en el equipo principal de RDA desde el año 2006.



08-08-2011 (Primera publicación 09-08-2007)

El enfoque de model-driven es cada vez más utilizado en el desarrollo de software. Aunque el modelado de aplicaciones y el modelado de datos son similares, el primero captura información clave del negocio como clases y asociaciones en forma de modelos de clase en Unified Modeling Language (UML). Los modelos de clase se pueden usar luego como base para obtener los modelos de datos lógicos para el modelado de datos que se encarga, además, de capturar entidades empresariales, sus relaciones y restricciones en modelos de datos lógicos (LDMs) que luego se pueden utilizar para obtener los modelos de clase para el modelado de aplicaciones.

Un LDM bien constituido puede brindar una representación verdadera de la información clave del negocio de una empresa. Puede abarcar y durar más que otras aplicaciones y fuentes de datos físicos. La semántica precisa, exacta y completa de LDM ofrece una base perfecta para los modelos de clase cuando una organización ejecuta la tarea de modelado de aplicaciones.

Ya sea que se comience por el modelado de aplicaciones o el modelado de datos, cuando estas dos formas distintas de modelado se combinan de manera holística, se manifiesta la potencia del desarrollo de software dirigido por modelos porque habremos:

  • obtenido la interoperabilidad de modelos en toda la empresa y en todas las capas de arquitectura de la empresa,
  • creado modelos de información reutilizable útiles para múltiples aplicaciones,
  • desacoplado semántica de datos e implementación física, y
  • permitido separar temas entre el modelador de aplicaciones y el modelador de datos.

IBM es líder en brindar herramientas para el modelado de aplicaciones y recientemente ha incorporado herramientas para el modelado de datos. Los usuarios pueden diseñar aplicaciones en Rational Software Architecture (RSA) y diseñar datos en Rational Data Architect (RDA). IBM reconoce la importancia de integrar los modelados en el desarrollo de software dirigido por modelos, y ha desarrollado la transformación de UML a LDM y la transformación de LDM a UML para vincular a estas dos herramientas entre sí. La transformación de UML a LDM es una función opcional de RSA V7, y la transformación de LDM a UML es una función opcional de RDA V7. La documentación en línea de cada uno de estos productos detalla el procedimiento paso por paso para instalar y usar cada transformación y también incluye información sobre mapeo de objetos.

Este artículo incluye primero una rápida descripción general de RSA y RDA y luego describe los pasos clave en tres escenarios de integración de RSA-RDA. Para los escenarios UML a LDM (descendente) y LDM a UML (ascendente) además recomienda a las empresas en qué casos usar cada uno de ellos. Este artículo continúa describiendo el modelado de aplicaciones en RSA, el modelado de datos en RDA y las transformaciones de UML a LDM (descendente) y de LDM a UML (ascendente). También explica UML Logical Data Model Profile que permite el modelado de datos en RSA y mejora las transformaciones de UML a LDM y de LDM a UML.

Obsérvese que aunque las transformaciones de UML a LDM y de LDM a UML son fundamentales en la integración de RSA y RDA, hay otros aspectos importantes para mencionar con respecto a la integración de RSA y RDA:

  • instalación y shell en común para facilitar su implementación y uso
  • repositorio de modelos en común utilizando Clearcase
  • kit de herramientas en común para desarrollo dirigido por modelos (modelo EMF, infraestructura de transformación, extensibilidad, etc.)

La descripción de estos temas escapa al alcance de este artículo.

Rational Software Architect

Rational Software Architect (RSA) es una herramienta para modelado de aplicaciones que permite a las organizaciones modelar, analizar, diseñar y generar aplicaciones. Potencia el desarrollo dirigido por modelos con UML creando aplicaciones y servicios bien diseñados. RSA:

  • Amplía el entorno de desarrollo de software abierto y extensible Eclipse.
  • Utiliza lo último en tecnología de lenguaje de modelado permitiendo un modelado flexible en una amplia gama de dominios diferentes que incluyen UML 2, notación similar a UML para Java y otros.
  • Permite una gestión de modelos flexible para desarrollo paralelo y refactoring de arquitectura; por ejemplo se puede dividir, combinar, comparar y fusionar modelos y fragmentos de modelos.
  • Facilita la transición entre arquitectura y código en las transformaciones de modelo a modelo y de modelo a código, esto incluye transformaciones inversas.
  • Facilita la experiencia de diseño a código para Java™/J2EE™, servicios web, SOA y C/C++ aplicaciones.
  • Incluye todas las funciones de IBM Rational Application Developer para una experiencia integrada de diseño y desarrollo.

Clases en RSA puede ser todo aquello que se crea, ensambla, inspecciona, testea, modifica o se trabaja en las aplicaciones. La Figura 1 que aparece a continuación muestra unos pocos ejemplos de clases y sus asociaciones, – Invoice, InvoiceItem, ProductInvoice y ServiceInvoice de un proyecto de muestra llamado RSAInvoice. Se muestran tres tipos diferentes de asociaciones: composición (invoice – item), añadidura (main (principal) – associate (asociado)) y asociación simple (product (producto – service (servicio)). Estas asociaciones se describen más adelante en este artículo.

Figura 1. Ejemplo de modelo de clase en RSAInvoiceproyecto
Ejemplo de modelo de clase en RSAInvoiceproyecto

Rational Data Architect

Rational Data Architect (RDA) es una herramienta de modelado de datos empresariales y de diseño de integración que, permite a los arquitectos descubrir, modelar, visualizar y relacionar diversos activos de datos. Utilizar RDA permite:

  • Crear modelos de datos lógicos y físicos.
  • Comparar y sincronizar las estructuras y los elementos de dos modelos de datos.
  • Analizar modelos de datos para verificar que estén correctos y se ajusten a los estándares de la empresa.
  • Descubrir, explorar y visualizar la estructura de las fuentes de datos.
  • Usar el mapeo para descubrir relaciones potenciales e identificar relaciones entre distintas fuentes de datos.

La Figura 2 que aparece a continuación muestra un ejemplo de LDM del proyecto de muestra llamado RDA Invoice. Obsérvese que hay tres tipos de relaciones: identificación (ítem (artículo) – invoice (factura)), no identificación (main (principal) – associate (asociado)) y de varios a varios (servicio (service) – producto (product)). Obsérvese además que herencia de clave aparece para la generalización y migración de clave aparece para relaciones de identificación y no identificación. Esto se describe más adelante en este artículo.

Figura 2. Modelo de Datos Lógicos de muestra de proyecto en RDA “Factura”.
Modelo de Datos Lógicos de muestra de proyecto en RDA “Factura”.

Frecuentemente los Modelos de Datos Lógicos (LDM) han sido obviados en el ciclo de vida del desarrollo de software, pero se han tornado cada vez más importantes por varios motivos. LDM ofrece la visualización de las entidades de datos de un negocio o una empresa sin exponer detalles de implementación; separa la semántica de datos de la implementación y es especialmente útil para manejar los entornos de IT cada vez más complejos y heterogéneos de la actualidad. Otros modelos lógicos o físicos como los modelos de servicio, modelos de mensaje, modelos de clase y modelos de almacenamiento de datos se pueden rastrear en un único LDM. Con herramientas de desarrollo dirigido por modelos de última tecnología como Rational Data Architect y Rational Software Architect, el usuario hasta puede generar modelos de flujo descendente e implantaciones físicas basadas en LDM. No es una exageración decir que LDM es el eje de la información de una organización. LDM permite una visualización global de los datos de una empresa, lo cual ayuda a disminuir la redundancia de datos, mejorar la calidad de los datos y acelerar la integración.

Escenarios de integración

Hay tres escenarios principales para la integración del modelado de aplicaciones y el modelado de datos: descendente, ascendente y convergente en el punto medio. Las siguientes secciones describen más detalladamente cada uno de estos escenarios. Se asume que participan dos roles principales de IT: el Application Modeler realiza el modelado de las aplicaciones y el Data Modeler efectúa el modelado de datos.

Descendente: de modelado de aplicaciones a modelado de datos.

En el escenario descendente, los elementos de modelado de clase (clases, propiedades y asociaciones) en RSA se transforman en elementos de modelado LDM (entidades, atributos y relaciones) para su uso en RDA.

En este escenario se realizan los siguientes pasos:

  1. El Application Modeler modela las aplicaciones en RSA. Los datos del negocio o de las aplicaciones se capturan como modelos de clase.
  2. El Application Modeler transforma parte o la totalidad de un modelo de clase en un LDM usando la transformación de UML a LDM.
  3. El Data Modeler accede a LDM y lo importa a RDA.
  4. El Data Modeler transforma el LDM en un Modelo de Datos Físicos (Physical Data Model, PDM) y luego genera un esquema de base de datos usando RDA.

El siguiente diagrama muestra la interacción entre el Application Modeler y el Data Modeler en el escenario descendente:

Figura 3. Escenario de integración descendente: de modelado de aplicaciones a modelado de datos.
Escenario de integración descendente: de modelado de aplicaciones a modelado de datos.

Recomendamos a las organizaciones que consideren utilizar el escenario descendente cuando se presenten algunas de las siguientes condiciones:

  • El modelado de aplicaciones impulsa la iniciativa del proyecto.
  • Las aplicaciones pasan por unidades de negocios o silos.
  • Las aplicaciones están centradas en objetos y tienen requerimientos limitados para la gestión de datos excepto la persistencia.
  • No hay LDM.
  • No existe esquema de base de datos físico.

No obstante, algunas personas a veces adoptan el escenario descendente por motivos equivocados. A continuación se citan (entre comillas) algunas razones poco sólidas por las cuales se utiliza el escenario descendente; al lado de cada una se incluye el argumento en contra para adoptar dicho escenario:

  • “Hasta ahora nunca aplicamos LDM.” Siempre hay una primera vez. Si en el pasado su organización tomó atajos con respecto a LDM, cuando antes comiencen los esfuerzos por implementar LDM más se beneficiará la organización a largo plazo.
  • “No estamos capacitados para manejar LDM.” Vale la pena invertir en un buen Data Modeler, por lo tanto debería contratar a alguien o capacitar a su personal internamente para que aprenda a utilizar LDM.
  • “Sólo necesitamos conservar los datos que utiliza esta aplicación.” La mayoría de las aplicaciones empresariales necesitarán compartir datos persistentes con otras aplicaciones empresariales. LDM reducirá el coste total de propiedad.

Por último, deberán afrontarse las consecuencias de utilizar el enfoque descendente:

  • Los modelos de datos pueden llegar a acoplarse estrechamente con algunas aplicaciones en particular.
  • Probablemente los modelos de clase no se puedan reutilizar fácilmente debido a la desestandarización y al modelado centrado en objetos que implica el modelado de aplicaciones.

Ascendente: de modelado de datos a modelado de aplicaciones

En el escenario ascendente, los elementos de modelado de LDM (entidades, atributos y relaciones) se transforman en elementos de modelado de clase (clases, propiedades y asociaciones) para utilizar en RSA. Desde el punto de vista empresarial, a largo plazo, es preferible usar el enfoque ascendente que el descendente debido a las limitaciones del enfoque descendente y los múltiples beneficios que brinda LDM, según lo mencionado en las secciones anteriores. Además, el enfoque ascendente permite separar temas, el Data Modeler se concentra en desarrollar modelos de datos y vocabulario para toda la empresa y el Application Modeler se focaliza en el modelado de las aplicaciones.

Este escenario implica los siguientes pasos:

  1. El Data Modeler modela los datos en un LDM en RDA. En aquellos casos en los cuales hubiera un esquema de base de datos existente, pero no un modelo físico o lógico, el Data Modeler obtiene un PDM del esquema existente, y transforma el PDM en un LDM.
  2. El Data Modeler transforma una parte o todo el LDM en un modelo de clase utilizando la transformación de LDM a UML.
  3. El Application Modeler accede al modelo de clase y lo importa en RSA.

El siguiente diagrama muestra la interacción entre el Application Modeler y el Data Modeler en un escenario ascendente:

Figura 4. Escenario de integración ascendente: de modelado de datos a modelado de aplicaciones
Escenario de integración ascendente: de modelado de datos a modelado de aplicaciones

Recomendamos a las organizaciones que consideren utilizar el escenario ascendente cuando se presenten algunas de las siguientes condiciones:

  • Ya existe un LDM en ese dominio.
  • Hay varias fuentes de datos existentes (bases de datos relacionales u otras).
  • La organización desea desacoplar datos de las aplicaciones y administrar los datos desde el nivel empresarial.
  • La organización desea crear información reutilizable en toda la empresa.
  • Hay múltiples iniciativas involucradas; por ejemplo, reescritura de aplicaciones del negocio, sumado a un requerimiento para empalmarse a un almacén de datos.
  • Las aplicaciones son complejas y frecuentemente en flujo.
  • Las aplicaciones están centradas en datos.
  • El proyecto necesita considerar, al menos parcialmente, los modelos de datos existentes. Esto puede ocurrir si se poseen aplicaciones legadas, aplicaciones de terceros o interfaces basadas en estándares que se deban cumplir.

Por último, el enfoque ascendente también implica un costo:

  • Se puede perder alguna semántica durante la transformación de un LDM a un modelo de clase porque los LDMs tienen una semántica de datos más abundante (como en las claves primarias) que los modelos de clase.
  • Como los LDM tienden a ser más completos que los modelos de clase, si los LDMs se impulsan hacia los modelos de clase sin una comunicación apropiada, los detalles podrían abrumar a los Application Modelers. Si el Application Modeler no comprende los LDM, podrían llegar a reinventar la rueda y definir entidades o atributos que ya están en los LDMs. Por ello, es esencial una correcta formación y comunicación entre el Data Modeler y el Application Modeler. Idealmente debería capacitarse a los Application Modelers para interpretar y aprovechar los modelos de datos lógicos.

Convergente en el punto medio

Las secciones anteriores describen los escenarios descendente y ascendente, que se focalizan principalmente en los desarrollos nuevos. Sin embargo, el cambio es la única constante en el desarrollo de software. El modelado de aplicaciones y el modelado de datos rara vez serán operaciones estáticas. Para evitar la obsolescencia, el modelado de aplicaciones y el modelado de datos necesitan ser iterativos y brindar valor empresarial de manera rápida. Por lo tanto, las herramientas de modelado de deberán admitir la actualización de habilidades. Por ejemplo, que los cambios en el modelo de clase se puedan actualizar y se reflejen en LDM ya sea mediante métodos automáticos (para cambios simples) o manuales (cuando se requieran heurísticos complejos) para modelar convergencia y viceversa de LDM a modelo de clase.

En realidad, administrar la sincronización y cambiar la administración de modelos de clase y LDM no es una tarea fácil ya que se alojan en herramientas diferentes y usualmente son realizados por dos roles distintos, el Application Modeler y el Data Modeler. No obstante, mediante un planeamiento meticuloso, una comunicación excelente y una gestión de cambios disciplinada se pueden utilizar eficazmente las funciones de las herramientas y lograr una gestión de datos integral.

Hay dos casos de uso en el escenario convergente en el punto medio según se quiera actualizar los modelos de clase o los LDMs:

  1. Una vez que los modelos de clase se transforman en LDM y se usan en RDA, los Application Modelers realizan ciertos cambios en los modelos de clase como agregar nuevas propiedades. Queremos actualizar los LDM en RDA para reflejar los modelos de clase actualizados. Este caso de uso es una ampliación del escenario descendente, con la complejidad adicional de sincronizar los LDM existentes en RDA con la información nueva o modificada.

Los pasos a seguir en el primer caso de uso son:

  1. El Data Modeler usa LDM versión 1 en RDA, que se transformó previamente de modelo de clase versión 1 en RSA.
  2. El Application Modeler modifica el modelo de clase versión 1 en RSA, luego transforma el modelo de clase actualizado (versión 2) como LDM versión 1+.
  3. El Data Modeler accede a LDM versión 1+ y lo importa en RDA.
  4. El Data Modeler compara y fusiona LDM versión 1+ y versión 1 con LDM versión 2 en RDA.

El diagrama siguiente muestra la interacción entre el Application Modeler y el Data Modeler en el primer caso de uso:

Figura 5. Escenario de integración convergente en el punto medio: de modelado de aplicaciones a modelado de datos
Escenario de integración convergente en el punto medio: de modelado de aplicaciones a modelado de datos
  1. Una vez que los LDM se transforman en modelos de clase y se usan en RSA, los Data Modelers realizan algunas modificaciones a los LDM, como por ejemplo agregar columnas nuevas. Se deberán actualizar los modelos de clase en RSA para reflejar los LDM actualizados. Este caso de uso es muy similar al escenario ascendente, con la complejidad adicional de sincronizar los modelos de clase existentes en RSA con la información nueva o modificada.

Los pasos a seguir en el segundo caso de uso son:

  1. El Application Modeler usa el modelo de clase versión 1 en RSA, que se transformó previamente de LDM versión 1 en RDA.
  2. El Data Modeler modifica el LDM versión 1 en RDA, luego transforma el LDM actualizado (versión 2) en modelo de clase versión 1+.
  3. El Application Modeler accede a modelo de clase versión 1+ y lo importa en RSA.
  4. El Application Modeler compara y fusiona modelo de clase versión 1+ y versión 1 en modelo de clase versión 2 en RSA.

El siguiente diagrama muestra la interacción entre el Application Modeler y el Data Modeler en el segundo caso de uso:

Figura 6. Escenario de integración convergente en el punto medio: de modelado de datos a modelado de aplicaciones
Escenario de integración convergente en el punto medio: de modelado de datos a modelado de aplicaciones

Transformaciones de modelos

Las transformaciones de modelos son fundamentales en el proceso de integrar el modelado de aplicaciones con el modelado de datos. En el escenario descendente que se describió anteriormente, los modelos de clase se transforman en modelos de datos lógicos utilizando la transformación de UML a LDM; en el escenario ascendente, los modelos de datos lógicos se transforman en modelos de clase usando la transformación de LDM a UML.

Modelo de clase UML

Un modelo de clase define:

  • Modelo y paquetes: estos sirven como componentes estructurales y espacio de nombres para otros elementos del modelos. Un paquete puede contener paquetes, diagramas, clases, asociaciones, clases de asociaciones y tipos de datos.
  • Clases: representan conceptos dentro del sistema que está siendo modelado. Las instancias de una misma clase comparten características comunes. Una clase tiene:
    • Propiedades: descripciones de características de una clase. Una propiedad tiene, entre otras cosas, un tipo que define el valor que puede tener.
    • Generalizaciones: una clase puede tener generalizaciones, como en las relaciones taxonómicas entre ella y clases más generales. La clase concuerda totalmente con la clase más general y contiene propiedades adicionales.
  • Asociaciones: representan relaciones semánticas entre dos clases que involucran conexiones entre sus instancias. Además de la forma de asociación simple, hay otras dos formas adicionales:
    • Agregación: forma que especifica una relación completa entre un acumulado (un total) y una parte constitutiva.
    • Composición: forma de agregación con fuerte dominio sobre las partes por el compuesto (el total) y el tiempo de vida de las partes que coincide con el compuesto. Una parte puede pertenecer solamente a un compuesto por vez.
  • Clases de asociaciones: una clase de asociación es una asociación que también es una clase. Conecta a dos clases y tiene propiedades.
  • Tipos de datos: el tipo de datos es un descriptor de un conjunto de valores e incluyen:
    • Tipos primitivos predefinidos: Booleano, Número, Cadena, Natural infinito
    • Tipos de datos definidos por el usuario: tipos primitivos o enumeraciones

Sírvase volver a la Figura 1 para consultar el modelo de caso de muestra.

RDA Logical Data Model

Un modelo de datos lógicos define:

  • Paquetes: sirven como componentes estructurales para otros elementos de modelos. Un paquete puede contener paquetes, diagramas, entidades y dominios.
  • Entidades: representan conceptos, eventos, personas, lugares o cosas sobre las cuales se guarda información. Las instancias de una misma entidad comparten características comunes. Las entidades pueden ser independientes o dependientes. Una entidad cuyas instancias no se puedan identificar por separado sin determinar su relación con otra entidad o entidades es una identidad dependiente; de lo contrario, es una entidad independiente. Una entidad tiene:
    • Atributos: descripciones de las características de una entidad. Un atributo tiene, entre otras cosas, un tipo que define el tipo de valor que puede tener.
    • PrimaryKey: un atributo o atributos que identifican exclusivamente una instancia de una identidad.
    • Generalización: una entidad puede tener generalizaciones, es decir relaciones taxonómicas entre ella y otras entidades más generales. La entidad coincide totalmente con aquella más general y contiene atributos adicionales.
  • Relaciones: representan conexiones, enlaces o asociaciones entre dos entidades. Hay tres clases de relaciones:
    • Relación de identificación: relación mediante la cual se identifica una instancia de entidad secundaria a través de su asociación con una entidad principal. Los atributos de clave primaria de la entidad principal se convierten en atributos de clave primaria de la entidad secundaria.
    • Relación de no identificación: relación mediante la cual no se identifica una instancia de entidad secundaria a través de su asociación con una entidad principal. Los atributos de clave primaria de la entidad principal no se convierten en atributos de clave de la entidad secundaria.
    • Relación varios a varios: asociación entre dos entidades en las cuales cada instancia de la primera entidad se asocia con cero, uno o varias instancias de la segunda entidad y cada instancia de la segunda entidad está asociada con cero, uno, o varias instancias de la primera entidad.
  • Tipos de datos: el tipo de dato es un descriptor de un grupo de valores. Los tipos de datos incluyen:
    • Tipos de datos predefinidos: BINARIO, BLOB, BOOLEANO, CHAR, CLOB, VÍNCULO DE DATOS, FECHA, DECIMAL, DOBLE, FLOAT, ENTERO, INTERVALO, LARGO, IDENTIFICADOR DE FILA, CORTO, HORA, MARCA DE TIEMPO, VARBINARY, VARCHAR, XML
    • Tipos de datos definidos por el usuario: dominios atómicos

Sírvase volver a la Figura 2 para consultar el modelo de datos lógicos de muestra.

Descendente: de modelo de clase a modelo de datos lógicos

Según lo comentado anteriormente se puede observar que el modelo de clase UML y el modelo de datos lógicos RDA se complementan muy bien para modelar construcciones y semánticas. Por lo tanto, transformar un modelo de clase en un modelo de datos lógicos es generalmente sencillo y no se producen pérdidas de información.

La Tabla 1 muestra el mapeo de un modelo de clase (origen) a un modelo de datos lógicos (destino). En la tabla es importante observar que:

  • Una clase no tiene clave primaria; tiene un OID (identificador de objeto) implícito. Esto se transforma en una clave sustituta.
  • Una asociación simple se transforma en una relación de no identificación si cualquier extremo de la asociación tiene una multiplicidad de 0.1 o 1; de lo contrario se transforma en una relación varios a varios.
  • Una propiedad puede tener la referencia de clase como tipo, la cual tiene la misma semántica que una agregación. Por lo tanto la referencia de clase se transforma en una relación de no identificación.
  • La clase de asociación es un concepto que no existe en el modelo de datos lógicos. Se transforma en una entidad y dos relaciones para preservar la semántica de la clase de asociación.
Tabla 1. Mapeo de UML a LDM
Mapeo de UML a LDM

La Figura 7 muestra el modelo de datos lógicos final generado por la transformación de UML a LDM usando modelo de clase de muestra que aparece en la Figura 1. Al comparar los modelos de origen y destino obsérvese que:

  • Se ha generado una clave sustituta (como en, Invoice ID para Invoice) para cada entidad.
  • Se produce la herencia de clave (como en, Invoice ID de Invoice a ProductInvoice) para la generalización.
  • Se produce una migración de clave (como en, Invoice Id a invoiceInvoice Id de Invoice a InvoiceItem) para la composición.
  • Se produce una migración de clave (como en, Invoice Id a MainInvoiceID de Invoice a Invoice) para la agregación.
  • Para la migración de clave, de manera predeterminada, el nombre del atributo de la clave secundaria externa se genera agregando como prefijo el nombre de rol de la clave principal al nombre de atributo de la clave primaria principal.
Figura 7. Modelo de datos lógicos generado por transformación de UML a LDM
Modelo de datos lógicos generado por transformación de UML a LDM

UML Logical Data Model Profile

No todas las clases definidas durante el modelado de aplicaciones necesariamente se relacionan con el modelado de datos o tiene datos persistentes; asimismo, no todos los tipos primitivos o enumeraciones necesariamente correspondan a los tipos de datos requeridos para el modelado de datos o los datos persistentes. Se puede utilizar UML Logical Data Model Profile para:

  • Permitirle al usuario controlar qué clases, tipos primitivos o enumeraciones transformar a un modelo de datos lógicos.
  • Especificar conceptos importantes para el modelado de datos lógicos pero que faltan en el UML. Esto incluye:
    • Atributo/s de clave primaria
    • Tipos de datos definidos por el usuario: más información de la que se puede especificar con tipos primitivos o enumeraciones
    • Integridad referencial: como en, regla de eliminación principal

Esencialmente, UML Logical Data Model Profile le permite al usuario realizar el modelado de datos lógicos utilizando el UML en RSA.

La Tabla 2 muestra los estereotipos y atributos que brinda Logical Data Model Profile. Obsérvese que:

  • La enumeración o los tipos primitivos se pueden estereotipar como Dominio. De ser así, se puede especificar información adicional (como en, el tipo base).
  • Las clases se pueden estereotipar como Entidad. De manera predeterminada, son persistentes y no utilizan clave sustituta.
  • Las propiedades se estereotipan siempre como Atributo. De manera predeterminada, no son requeridas.
  • Las propiedades se pueden estereotipar como PrimaryKey.
  • Las asociaciones y las clases de asociaciones siempre se estereotipan como Relación. De ser así, se pueden especificar los nombres de atributo de la clave externa (en forma de nombre de atributo de clave primaria, pares de nombres de atributos de clave externa) y la regla de eliminación principal (NINGUNO / RESTRINGIR / CASCADA / CONFIGURAR NULO / CONFIGURAR DE MANERA PREDETERMINADA). En adelante, también se puede especificar la regla de eliminación secundaria.
Tabla 2. UML Logical Data Model Profile
UML Logical Data Model Profile

La Tabla 3 muestra el mapeo de un modelo de clase (origen) a un modelo de datos lógicos (destino) cuando se aplica Logical Data Model Profile al modelo de clase. Cabe destacar que:

  • Sólo las clases estereotipadas como Entidad se transforman en entidades. De manera predeterminada, son persistentes y no utilizan clave sustituta.
  • Las propiedades estereotipadas como PrimaryKey se transforman en atributos de clave primaria, en cuyo caso se requieren los atributos generados.
  • Para asociaciones y clases de asociaciones, si se especifican los nombres de atributos de clave y la regla de eliminación principal, se utilizan para la relación generada. En adelante también se utilizará la regla de eliminación secundaria, si se hubiera especificado.
  • Sólo los tipos primitivos / enumeraciones estereotipadas como Dominio se transforman a dominios atómicos.
Tabla 3. Mapeo de UML a LDM con Logical Data Model Profile
Mapeo de UML a LDM con Logical Data Model Profile

La Figura 8 muestra el modelo de clase de muestra con el Logical Data Model Profile aplicado. Obsérvese que:

  • Todos los tipos primitivos se han estereotipado como Dominio.
  • Todas las clases se han estereotipado como Entidad.
  • Los atributos de ID de Invoice e InvoiceItem se han estereotipado como PrimaryKey.
Figura 8. Modelo de clase de muestra con Logical Data Model Profile
Modelo de clase de muestra con Logical Data Model Profile

La Figura 9 muestra el modelo de datos lógicos de destino generado por la transformación de UML a LDM. La fuente del modelo de clase de muestra usado en esta transformación es el de la Figura 8. Al comparar los modelos de origen y destino, obsérvese que:

  • No se ha generado clave sustituta. En cambio se han generado atributos de clave primaria (el Invoice ID a Invoice ID de Invoice a Invoice Item).
  • Se produce la herencia de clave (el ID de Invoice a ProductInvoice) para la generalización.
  • Se produce la migración de clave (el Invoice Id a InvoiceID de Invoice a InvoiceItem) para la composición.
  • Se produce la migración de clave (el ID a mainID de Invoice a Invoice) para la agregación.
  • Para la migración de clave, de manera predeterminada, el nombre de atributo de la clave secundaria externa se genera agregando como prefijo el nombre de rol de la clave principal al nombre de atributo de la clave primaria principal.
Figura 9. Modelo de datos lógicos generado por la transformación de UML a LDM con Logical Data Model Profile
Modelo de datos lógicos generado por la transformación de UML a LDM con Logical Data Model Profile

Ascendente: de modelo de datos lógicos a modelo de clase

Similar a la transformación descendente, transformar un modelo de datos lógicos en un modelo de clase es fácil y no se produce pérdida de información. La Tabla 4 muestra el mapeo de modelo de datos lógicos (fuente) a modelo de clase (destino).

Tabla 4. Mapeo de LDM a UML
Mapeo de LDM a UML

La Figura 10 muestra el modelo de clase de destino generado por la transformación de LDM a UML. La fuente del modelo de datos lógicos de muestra utilizado en esta transformación es el de la Figura 2. Al comparar los modelos de origen y destino, obsérvese que:

  • La información de la clave primaria (el ID de Invoice) se pierde en el modelo de clase ya que el modelo de clase de UML no admite el concepto de clave primaria.
  • Los atributos de la clave externa (el InvoiceID de InvoiceItem) no se transforman al modelo de clase ya que se generan por migración de clave en el modelo de datos lógicos y no son inherentes al modelo.
Figura 10. Modelo de clase generado por transformación de LDM a UML
Modelo de clase generado por transformación de LDM a UML

Para preservar los conceptos del modelado de datos lógicos y la información en el modelo de clase de destino, se puede aplicar Logical Data Model Profile al modelo de clase de destino durante la transformación de LDM a UML. La Tabla 5 muestra el mapeo de un modelo de datos lógicos (origen) a un modelo de clase (destino) con el Logical Data Model Profile aplicado. Obsérvese que:

  • Las entidades se transforman en clases estereotipadas como Entidad.
  • Los atributos de clave primaria se transforman en propiedades estereotipadas como PrimaryKey.
  • Los dominios atómicos se transforman en tipos primitivos y enumeraciones estereotipadas como Dominio.
Tabla 5. Mapeo de LDM a UML con Logical Data Model Profile
Mapeo de LDM a UML con Logical Data Model Profile

La Figura 11 muestra el modelo de clase de destino generado por la transformación de LDM a UML con el Logical Data Model Profile aplicado al modelo de clase de destino. La fuente del modelo de datos lógicos de muestra, utilizada en esta transformación, es el de la Figura 2. Al comparar los modelos de origen y destino, obsérvese que:

  • La información de clave primaria (el ID de Invoice) se preserva en el modelo de clase.
  • Los atributos de clave externa (el InvoiceID de InvoiceItem) no se transforman en el modelo de clase ya que son generados por migración de clave en el modelo de datos lógicos y no son inherentes al modelo.
Figura 11. Modelo de UML generado por la transformación de LDM a UML con Logical Data Model Profile
Modelo de UML generado por la transformación de LDM a UML con Logical Data Model Profile

Conclusión

Este artículo brinda una descripción general de RSA y RDA y su integración. Usted ha observado tres escenarios de integración y ha aprendido criterios de adopción para los escenarios descendente y ascendente respectivamente. Para crear modelos de aplicaciones y de datos bien constituidos, no alcanza solamente con conocer cómo se usan las herramientas. Es igualmente importante conocer los motivos por los cuales es conveniente adoptar un determinado escenario, para definir un proceso de gestión de cambios sólido y recurrente y para delinear una estrategia que potencie la sinergia entre el modelado de aplicaciones y el modelado de datos. Además, la integración exitosa del modelado de aplicaciones y de datos puede requerir cambios en la organización y en la cultura empresarial. Esperamos que este artículo lo ayuden a fortalecer sus esfuerzos de integración de modelado de aplicaciones y modelado de datos.

El artículo también ofrece una descripción detallada de las transformaciones de UML a LDM y de LDM a UML, como así también de UML Logical Data Model Profile. En general es beneficioso aplicar el Modelo de Datos Lógicos al modelo de clase ya sea que el modelo de clase se utilice como origen o se genere como destino. En el caso formal, permite al usuario controlar qué clases, tipos primitivos o enumeraciones transformar en un modelo de datos lógicos y especificar información y conceptos importantes para el modelado de datos lógicos pero que faltan en UML. En este último caso, hace que la transformación se pueda revertir ya que se preservan la información y los conceptos principales del modelado de datos lógicos en el modelo de clase generado.

Como ilustra la Figura 12, el modelado de datos lógicos es una pieza clave en la integración del modelado de datos. Usted vio en este documento cómo se puede integrar el modelado de aplicaciones en RSA con el modelado de datos lógicos en RDA. La integración entre el modelado de datos lógicos y el modelado relacional es una función estándar de RDA. Ya se está desarrollando la integración entre el modelado empresarial en WBM y el modelado de datos lógicos en RDA, así como también la integración del modelado de datos lógicos y el modelado de datos de XML en RDA y se describirá en un próximo artículo de developerWorks.

Figura 12. Modelado de datos lógicos como pieza clave para la integración del modelado de datos
Modelado de datos lógicos como pieza clave para la integración del modelado de datos

Agradecimiento

Agradecemos a Der Ping Chou, Davor Gornik, Gary Robinson y Hong-Lee Yu por revisar y brindar sus comentarios sobre este artículo. Gracias a Andreas Drasdos (GAD) por sus valiosos comentarios sobre la transformación de UML a LDM y UML Logical Data Model Profile.


Recursos

Conocer

Obtener productos y tecnologías

Debatir

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt, Rational
ArticleID=963205
ArticleTitle=Integración de Rational Software Architect y Rational Data Architect
publish-date=08082011