Concepto: Desarrollo controlado por modelos (MDD) y arquitectura controlada por modelos (MDA)
En esta guía se introducen MDD y MDA, cuyo principal función es enfatizar el rol de los modelos en la ingeniería de software.
Relaciones
Elementos relacionados
Descripción principal

Introducción

Los modelos son un tipo importante de  producto de trabajo  en Rational Unified Process y suelen expresarse (en RUP) mediante el lenguaje unificado de modelado (UML), en una herramienta y de un modo neutral para el entorno, de modo que RUP pueda desplegarse y utilizarse con muchos conjuntos de herramientas en muchos entornos. Material de soporte: Modelado visual explora algunas de las razones para el modelado, las cuales incluyen:

  • Ayudar a comprender los sistemas complejos
  • Explorar y comparar alternativas de diseño a un bajo coste como base para la implementación
  • Capturar requisitos de forma precisa
  • Comunicar decisiones de forma clara

Los modelos se ven como un modo de explicar la estructura y el comportamiento del sistema (tanto el deseado como el real), así como comunicar los resultados de estas deliberaciones a las personas interesadas. MDD y MDA enfatizan el rol de los modelos como elementos básicos para la implementación, esperando que lleguen no sólo patrones en los que se basen los desarrolladores para escribir código, sino que también lleguen a utilizarse y ejecutarse hasta cierto punto en función de la capacidad del conjunto de herramientas de soporte. De este modo, se sigue una tendencia, que empezó hace mucho tiempo, de incrementar el nivel de abstracción en el cual trabajan los desarrolladores. Esto cambia el foco de atención del código tal como lo conocemos, a modelos expresados en un lenguaje gráfico e incluso más elevado. RUP, al identificar determinados artefactos como modelos en lugar de documentos (captando los requisitos y el diseño, por ejemplo) que contiene imágenes de los modelos, da soporte a esta posibilidad de forma implícita.

Puntos de vista y vistas Ir a la parte superior de la página

Un punto de vista, tal como implica su nombre, es una posición nocional desde la que se pueden ver algunos aspectos o asuntos del sistema (o el conjunto de modelos que representan el sistema), lo que supone la aplicación de un conjunto de conceptos y reglas para formar un filtro conceptual. El término "perspectiva" se utiliza de forma similar para describir un modo de ver y comprender modelos que son más útiles para las diferentes orientaciones y preocupaciones de las diferentes personas interesadas.

Las vistas son proyecciones de modelos que muestran entidades importantes desde un punto de vista o perspectiva particular.

En MDD, los puntos de vista y las vistas se utilizan para separar preocupaciones, por ejemplo, para tratar con la estructura lógica independientemente de la estructura física y de la estructura del proceso. Cuanto más cercanos estén los modelos al dominio del problema, más sólidamente se asignarán los puntos de vista y las perspectivas a las preocupaciones empresariales de los interesados. Puesto que los modelos se desarrollan con un formato cercano al ejecutable, las preocupaciones computacionales suponen un obstáculo. En cualquier caso, el objetivo no es simplemente producir ilustraciones pasivas, sino modelos que sean, al menos potencialmente, generadores de implementaciones que satisfagan las diferentes preocupaciones.

Elaboración y conversión (transformación) Ir a la parte superior de la página

Estos términos se utilizan a menudo informalmente para distinguir entre los cambios a modelos realizados a mano (elaboración) y mediante una herramienta (conversión). En RUP, la elaboración tiene un significado formal algo diferente, se trata del nombre de una fase de ciclo de vida, pero en esta sección, la utilizamos de forma informal para ilustrar enfoques aparentemente diferentes a la evolución de los modelos.

También se entiende el tamaño de paso de forma diferente en la conversión y la elaboración, en el sentido que un modelo se elabora en diferentes pasos pequeños hasta que existen detalles suficientes (incluidos el lenguaje, la infraestructura o el sistema operativo) como para generar código a partir de éste, ya sea mediante una herramienta o de forma manual. De forma manual, se refiere a que una persona puede observar el modelo y escribir Java, C++ u otros lenguajes y posiblemente seguirá trabajando en dicho modelo durante el proceso. Por el contrario, en la conversión, el modelo, todavía en el nivel de abstracción no modificado por preocupaciones de lenguaje, infraestructura o sistema operativo, se convierte en algo que ejecuta y produce el resultado deseado con muy poca elaboración. Tenga en cuenta que el resultado deseado incluye el rendimiento y otras características no funcionales. Por lo tanto, en este enfoque se entiende que las preocupaciones de arquitectura transversales se tratan según el modo en que se construya el modelo y el modo en que describe los requisitos de recursos.

Otro término, Definición de término: transformación, se utiliza de forma regular, para describir el proceso de generación de un modelo de destino a partir de un modelo de origen siguiendo un conjunto de reglas y trabajando según un conjunto de parámetros. Tenga en cuenta que se utiliza el término "modelo" en esta publicación del mismo modo que RUP, de modo que el modelo de destino puede ser los elementos de implementación como, por ejemplo, código o texto. Por descontado, la transformación puede realizarse a mano, con lo cual las transformaciones sucesivas (adición de detalle) equivalen a la elaboración y las reglas pueden llegar a ser muy complejas y enraizadas en experiencia sólida de la tecnología disponible y del dominio. Sin embargo, el significado predeterminado es que la transformación se realiza de forma automática, la cual se vuelve a examinar en la sección siguiente en la que se trata la arquitectura controlada por modelo®.

Tenga en cuenta que la idea de transformar simplemente implica un modelo de origen y un modelo de destino. El caso habitual es que el modelo de destino es menos abstracto que el modelo de origen; es decir, que el destino es, de algún modo, más específico que el origen. De todos modos, esto no está implícito en la idea de transformación. Tenga en cuenta que la transformación también puede añadir detalles a un modelo y producir, de este modo, un modelo de destino más perfeccionado, a la vez que, en términos generales, se mantiene al mismo nivel de abstracción ya que no se introduce ninguna información relevante en otro dominio. Contraste esto con una transformación que cree código a partir de un modelo UML. En tal caso, se introducen muchos datos en el modelo de destino en cuestión; es decir, que aquellos datos que no afectan al interesado en la empresa, siempre que se mantengan el comportamiento necesario y las características no funcionales.

La capacidad de llevar a cabo el ideal de conversión depende de las capacidades de la herramienta y de nuestra habilidad de codificar, capturar y reutilizar los conocimientos empleados por un experto. La cantidad de conocimiento que debe capturarse y codificarse depende del nivel de abstracción a partir del cual se realiza el paso de conversión. Normalmente, cuanto más elevado sea el nivel, mayores serán los conocimientos y la dependencia del dominio.

En MDD, nos esforzamos por elevar el nivel de abstracción desde el cual podemos generar automáticamente un sistema operativo. Un modelo se elabora hasta el punto en que se puede utilizar para generar algo. A continuación, la preferencia es que la salida no tenga que seguir elaborándose para ejecutarla. Además, nuestro objetivo es llevar a cabo la elaboración al máximo a través de transformaciones automáticas. De este modo, los dos enfoques convergen: la conversión se realiza siguiendo pasos de transformación sucesivos que se automatizan hasta la medida de lo posible. La transformación final para ejecutar el sistema se lleva a cabo cuando la descripción del modelo todavía se encuentra en un nivel de abstracción elevado y con la tecnología, la infraestructura y las selecciones de idioma de destino codificados en el motor de transformación, así como las reglas y los datos proporcionados para éste.

Un beneficio adicional de MDD es que esperamos poder reutilizar transformaciones, haciendo que codifiquen la plataforma y el conocimiento de dominio y las recomendaciones a través de la creación realizada por expertos en los dominios correspondientes. De este modo, facilitamos que los desarrolladores menos experimentados reutilicen las transformaciones y evitamos que se tengan que volver a crear desde cero con cada nueva aplicación.

¿En qué consiste un nivel elevado de abstracción? Ir a la parte superior de la página

Esta cuestión puede abordarse desde varios puntos de vista. Uno es que junto al espectro del idioma y vemos la emergencia de formas de UML ejecutables, por ejemplo. Otro es desde la perspectiva de la ingeniería de dominios, en la que los conceptos de lenguaje y modelado pueden ser especializados del dominio. Por ejemplo, UML es un lenguaje de uso general, con lo cual, junto con esta dimensión, encontrará el uso de Definición de término: Perfil UML para especializar el uso de UML. Otro modo de enfocar esta cuestión es por la necesidad de evitar modelos específicos de proveedor e infraestructura para permanecer abiertos a la nueva tecnología.

En términos de expresión de la dinámica detallada, el trabajo realizado en Semántica de acciones UML ha hecho que las formas ejecutables de UML sean posibles, pero la sintaxis y la notación concretas no están estandarizadas y el nivel de la semántica de acciones está estrechamente relacionado con otros 00 lenguajes. Por lo tanto, es probable que UML y la semántica de acciones no sean la respuesta final, pero existe una indicación acerca de hacia donde se dirigen las cosas.

Concluimos que un modelo expresado en UML o mediante un perfil UML que no contiene elementos dependientes del proveedor, no depende de una plataforma de infraestructura particular como, por ejemplo, J2EE o Microsoft® .NET, y su semántica está completa por lo que se refiere a la estructura y al comportamiento sin que tenga que acudirse a un lenguaje de procedimiento particular (Java, C#, ...) se encuentra en un nivel elevado de abstracción según esta definición, aunque la cuestión del nivel de semántica de acciones sigue sin estar modificada.

Desde la perspectiva de dominio de problemas; es decir, desde el punto de vista del usuario o del cliente empresarial, una posible solución atractiva es la formulación de lenguajes de modelado específicos de dominio. Estos lenguajes son abstractos, en el sentido que se formulan en términos y conceptos familiares a los trabajadores de un dominio particular. De todos modos, tienen todas las facultades de expresar la dinámica de modelo a la vez que siguen basándose en UML.

¿Qué relación tiene esto con RUP? Ir a la parte superior de la página

La relación de los modelos de análisis, implementación y análisis RUP ilustra las ideas siguientes: el modelo análisis representa una primera vista de cómo el comportamiento utilizado en los casos se llevará a cabo. Naturalmente, no se falsea de forma descriptiva por lo que se refiere al dominio del problema que se está tratando y las clases de análisis que contiene se consideran como agrupaciones conceptuales de las responsabilidades y el comportamiento necesarios. El modelo de análisis no suele ser lo suficientemente completo para ejecutarse, excepto, tal vez, en un experimento mental realizado por una persona que lea el modelo y que relleno los espacios, ya que quedan mucha información que relatar. En su lugar, el modelo de análisis deben pasar a través de un proceso de perfeccionamiento, en el que se añade detalles y precisión, con lo cual se obtiene el modelo de diseño.

RUP permite a un proyecto mantener un modelo de análisis separado o considerar dicho modelo como algo que evoluciona hacia el modelo de diseño. El proceso de perfeccionamiento se describe hasta cierto punto en las tareas RUP, con la interpretación predeterminada según la cual los usuarios llevan a cabo roles de arquitecto de software y el diseñador llevará a cabo dicha evolución, probablemente con la ayuda importante de una herramienta. Tenga en cuenta que este perfeccionamiento se puede considerar como una secuencia de transformaciones de modelo, algunas de las cuales pueden llegar a automatizarse, por ejemplo, en la aplicación de patrones Definición de término: patrón de análisis y Definición de término: patrón de diseño en las tareas RUP Análisis de arquitectura y Identificar mecanismos de diseño .

¿Cuándo se completa un modelo de diseño? Ir a la parte superior de la página

El modelo de diseño evoluciona durante la vida del proyecto, por las diferentes repeticiones; por lo tanto, ¿cuándo puede el modelo de diseño (o una parte de éste) convertirse en código? es decir, ¿cuándo podemos empezar a crear elementos de implementación e integrarlos en compilaciones interesantes del sistema? RUP ofrece algunas directrices sobre la correlación de diseño a código, aunque fundamentalmente no existen respuestas rápidas ni definitivas. Se pasa a la implementación cuando, mediante la revisión de un ejemplo, y usted debe valorar si puede, y dicho punto puede variar de forma considerable entre organizaciones y proyectos. RUP ofrece un número de modos de proceder desde el diseño hasta el código, dos de los cuales se tratan aquí para ilustrar el modo en que se toman decisiones sobre la finalización del diseño:

1. Esbozo y código
RUP dice: "Una propuesta común de diseño es un esbozo a nivel bastante abstracto que, posteriormente, se pasa directamente a código. El mantenimiento del modelo de diseño es manual."

Para tener éxito con este enfoque, es necesario que el desarrollador pueda crear un puente del espacio de abstracción entre los niveles de diseño y de implementación. A menudo, el mantenimiento del modelo de diseño es una preocupación secundaria y el código se convierte en el objeto de atención principal.

2. Ingeniería directa e inversa (RTE) con modelo único de diseño en desarrollo
RUP dice: "En esta propuesta, sólo hay un modelo de diseño. Los esbozos iniciales de elementos de diseño evolucionan hasta que se pueden sincronizar con el código."

Aquí, los desarrolladores cierran el espacio de abstracción con una secuencia de pasos de modelado. La diferencia entre este enfoque y "esbozo y código" es que los pasos intermedios son obvios y, al final, la versión abstracta del modelo de diseño desaparece.

En ambos casos, el valor potencial de un modelo de diseño abstracto se pierde. En "esbozo y código" debido a que el modelo de diseño abstracto no suele mantenerse y, con el tiempo, pierda contacto con el código y en "modelo único de diseño en desarrollador" debido a que la versión abstracta desaparece. Aunque se mantenga una versión inicial, normalmente termina igual que el modelo de diseño de esbozo y diseño. Tenga en cuenta que el punto final del modelo de diseño con RTE es, en realidad, la visualización del código y una visualización similar podría tratarse con la ingeniería directa e inversa a partir del código producido en el modelo de esbozo y código con las herramientas adecuadas. En RUP, se mitiga la pérdida del modelo de diseño abstracto, en cierta medida, capturando las vistas de arquitectura significativas y los fundamentos del diseño, en puntos críticos, en el documento de la arquitectura del software.

MDD ofrece la posibilidad de que el modelo de diseño abstracto pueda convertirse en un elemento básico para la generación de código y pueda perdurar. Se convierte en la base principal para el mantenimiento y, de hecho, puede que sea la única base para el mantenimiento. También ofrece una definición clara del punto final para el diseño, es decir, el punto en el que, por lo que se refiere al motor de transformación, el modelo está completo, coherente y precio y puede convertirse en un sistema ejecutable. El nivel de abstracción del modelo depende de la tecnología y el conjunto de herramientas disponibles (para ver un ejemplo al respecto, consulte el icono de publicación Visita guiada: Visión general de Rational Software Architect) y es posible que también dependa del dominio. Tenga en cuenta que por lo que se refiere a MDD, esto es simplemente otra transformación (de diseño a código), aunque importante, ya que pasa por los niveles de abstracción.

En la sección siguiente, se describe un estándar de infraestructura emergente para MDD, una iniciativa del grupo de gestión de objetos (OMG)® (MDA®).

Arquitectura controlada por modelo (MDA) Ir a la parte superior de la página

Motivación Ir a la parte superior de la página

MDA es una iniciativa de OMG, un consorcio del sector formado por unos 800 miembros con el objetivo de establecer directrices y especificaciones estándar para proporcionar una infraestructura neutral de proveedor para el desarrollo de aplicaciones y para fomentar la interoperabilidad entre plataformas de infraestructura de hardware y software importantes. El lenguaje unificado de modelado es un producto de OMG. OMG promueve MDA como su especificación más importantes y ocupando la posición de promulgación de estándares prácticos de OMG con el objetivo de que sean compatibles con IC del sector, la práctica, los productos y las herramientas. Así mismo, vale la pena convertir el éxito de UML y MDA en objeto de estudio. Existe una gran cantidad de información en MDA, incluida la guía MDA más reciente [OMG03], en el sitio web de OMG. También existen varios libros disponibles, como, por ejemplo [FRA03], [KLE03], y [MEL04] y muchos artículos como, por ejemplo, "An MDA Manifesto" por Grady Booch, Alan Brown, Sridhar Iyengar, James Rumbaugh y Bran Selic en The MDA Journal, Mayo de 2004.

Ideas principales de MDA Ir a la parte superior de la página

MDA introduce algunos conceptos y terminología específicos que la distinguen de enfoques más generales a MDD. Dichos enfoques se definen y tratan en las secciones siguientes.

Modificación de estándares existentes Ir a la parte superior de la página

MDA está respaldad por estándares OMG existentes, que incluyen:

  • El recurso de metaobjeto (MOF): además de definir un lenguaje para la construcción de metamodelos, por ejemplo, UML y CWM, el recurso MOF define una infraestructura para la implementación de depósitos para modelos y metamodelos, lo cual permite tener un enfoque coherente para la manipulación de dichos modelos a la hora de utilizar MDA. De este modo, el recurso MOF es una tecnología esencial para MDA.
  • El lenguaje unificado de modelado (UML): los PIMs, PMs y los PSM se definen en UML, que es la notación básica de MDA.
  • Intercambio de metadatos XML (XMI): XMI define el formato de intercambio de un modelo UML basándose en XML.
  • El metamodelo de almacén común (CWM): la relación existente entre UML y el modelado de aplicaciones es la misma que entre CWM y el modelado de datos.

Independencia de plataforma Ir a la parte superior de la página

Una noción intuitiva de una Definición de término: plataforma es que da soporte a una capa de arquitectura superior a través del suministro de servicios con un conjunto de interfaces bien definido que ocultan los detalles de la implementación. La definición de OMG (en la guía MDA) de plataforma es:

"Conjunto de subsistemas o tecnologías que proporcionan un conjunto coherente de funciones a través de interfaces y patrones de uso especificado que cualquier subsistema que depende de plataforma puede utilizar sin preocuparse de los detalles de cómo se implementan las funciones que proporciona la plataforma."

Esto es similar al concepto de una Definición de término: capa tal como se utiliza en RUP.

La idea de la independencia de plataforma no está del todo fijada. Se trata de una calidad o una característica de un modelo, por ejemplo, se puede decir que un modelo es independiente de una plataforma determinada cuando no contiene referencias a servicios ni a la capacidad proporcionada por dicha plataforma. Sin embargo, tal afirmación es relativa, ya que es difícil concebir una forma absoluta de la independencia de la plataforma. en la guía MDA se reconoce esto y también se afirma que existe la posibilidad de que existan grados de independencia de plataforma por lo que se refiere a una plataforma particular en la que, por ejemplo, un modelo utiliza una forma generalizada de una característica en una plataforma determinada.

La consecución de la independencia de plataforma ha sido respaldada por la evolución de plataformas como, por ejemplo J2EE, .NET y WebSphere, con el objeto de incrementar los niveles de abstracción en términos de lo que se expone en las aplicaciones. Esto permite manejar mejor la identificación de construcciones neutrales de plataforma y resulta más simple y fácil escribir las transformaciones específicas de plataforma que las convierten.

Modelo independiente de plataforma (PIM) Ir a la parte superior de la página

A continuación, podemos afirmar que un modelo es un PIM en relación con una plataforma determinada cuando no está destinado a utilizarse en dicha plataforma y puede utilizarse con cualquier plataforma del mismo tipo. En la sección anterior, hemos tratado la idea de un nivel alto de abstracción y hemos concluido en que un modelo expresado en UML (o mediante un perfil UML) que no contiene elementos dependientes de proveedor, no depende de una plataforma de infraestructura determinada y es semánticamente completo por lo que se refiere a estructura. También se ha concluido que el comportamiento sin recurso para un lenguaje de procedimiento particular se podía ejecutar desde el punto de vista de la noción y en un nivel elevado de abstracción. ¿Es este tipo de modelo independiente de plataforma? Sí y no. No, por lo que respecta a una posible máquina virtual UML imaginaria, y sí por lo que respecta a una clase completa de plataformas de la que dicha máquina virtual podría depender.

Modelo de plataforma Ir a la parte superior de la página

El modelo de plataforma es ese conjunto de conceptos (que representan los componentes y servicios), especificaciones, definiciones de interfaces, definiciones de restricciones y otros requisitos que necesita una aplicación para utilizar una plataforma determinada. En MDA, los modelos de plataforma se detallan y formalizan en UML, por ejemplo, y se encuentra disponibles en un depósito compatible con MOF. Por ejemplo, los modelos de plataforma pueden crearse para J2EE o .NET, entre otros.

Modelo específico de plataforma (PSM) Ir a la página superior de la página

Un PIM se transforma en uno o varios PSM mediante la adición de información que lo hacen específico de una o varias plataformas particulares. Los modelos PIM y PSM siguen especificando el mismo sistema, pero el PSM está limitado a una tecnología particular y puede contener elementos específicos de plataforma. Tenga en cuenta que no existe implicación alguna de que un paso de transformación (de PIM a PSM o su plataforma asociada) sea grande o pequeño. Una transformación que implique la aplicación de un pequeño conjunto de patrones perfecciona el modelo y, en cierto modo, lo hace más específico. Esto enfatiza la relatividad de los términos PIM y PSM.

Puntos de vista y vista Ir a la parte superior de la página

Estos términos se utilizan en MDA del mismo modo que se ha descrito para MDD:

  • Un punto de vista, tal como implica su nombre, es una posición nocional desde la que se pueden ver algunos aspectos o asuntos del sistema, lo que supone la aplicación de un conjunto de conceptos y reglas para formar un filtro conceptual. Puesto que se elimina parte de la información del sistema, se trata de una forma de abstracción. El término perspectiva se utiliza de forma similar.
  • Desde un punto de vista, se pueden ver vistas, que son proyecciones de modelos, con entidades que son relevantes desde dicho punto de vista.

MDA especifica tres puntos de vista en un sistema: un punto de vista independiente de computación, un punto de vista independiente de plataforma y un punto de vista específico de plataforma.

Punto de vista independiente de computación Ir a la parte superior de la página

Desde el punto de vista independiente de computación, debe observar el contexto del sistema, los requisitos y limitaciones según los cuales debe operar y los elementos del entorno con los que debe interactuar. Desde este punto de vista, no se ven los detalles de la estructura ni del comportamiento del sistema.

El modelo independiente de cálculo (CIM) es una vista de un sistema desde un punto de vista independiente de computación. El CIM es similar conceptualmente a una combinación del modelo de dominio en RUP, el cual es el conjunto de artefactos, incluido el glosario empresarial y el modelo de análisis empresarial, que es la salida de la tarea Desarrollar un modelo de dominio (en un modelado empresarial), y el modelo de guión de uso, el cual es una descripción independiente computacionalmente del comportamiento del sistema. El CIM, que se expresa en el idioma del tema o de los expertos en el dominio, es un enlace importante en la identificación, durante el análisis y el diseño, de las abstracciones clave en el sistema de creación.

Punto de vista independiente de plataforma Ir a la parte superior de la página

El punto de vista independiente de plataforma está relacionado con una plataforma particular. Desde este punto de vista, puede ver la estructura y el comportamiento de un sistema sin los detalles de dicha plataforma. El PIM es una vista del sistema desde el punto de vista independiente de plataforma.

Punto de vista específico de plataforma Ir a la parte superior de la página

Desde el punto de vista específico de plataforma, que también está relacionado con una plataforma específica, puede ver la información que podía ver desde el punto de vista independiente de plataforma pero con los detalles de utilización de la plataforma. El PSM es una vista del sistema desde un punto de vista específico de plataforma.

Automatización de la transformaciónIr a la parte superior de la página

La idea de la transformación es fundamental para MDA y la transformación de modelos se define simplemente como "el proceso de convertir un modelo en otro modelo del mismo sistema". MDA también define un pequeño patrón para visualizar la conversión y para ilustrar el uso de algunos de los términos que hemos visto hasta ahora:

Patrón MDA, que muestra el PIM y otra información como entrada a una transformación, y PSM y el registro de la transformación como salida.

El patrón MDA

El diagrama tiene la finalidad de mostrar que la transformación es un proceso de calidad: la transformación utiliza el PIM y otra información y los combina para crear el PSM.

Por descontado, la transformación de modelos puede realizarse de forma manual. Esto no varía mucho del modo en que siempre se ha llevado a cabo el diseño de software. Incluso en este caso, MDA resulta útil a la hora de delinear y formalizar la idea de la transformación, el proceso y la información adicional que debe utilizarse. MDA también sugiere la creación de un registro de la transformación. De este modo, se proporciona una rastreabilidad fidedigna del PIM al PSM, ya que debe incluir un mapa desde los elementos del PIM a los elementos del PSM. La mayoría de la optimización se obtiene al poder automatizar transformaciones, aunque sólo sea de forma parcial, obteniendo los mismos beneficios que se derivan de la sustitución de la programación de ensamblador con lenguajes de alto nivel.

¿Cómo se lleva a cabo la transformación? Ir a la parte superior de la página

MDA no prescribe un solo modo de llevar a cabo la transformación: se prepara una correlación, controlada por la plataforma seleccionada, para especificar el modo en que debe transformarse un PIM en PSM para dicha plataforma. Dicha correlación da lugar a una definición de transformación (tal vez expresada como conjunto de reglas de transformación), posiblemente con parámetros de transformación, escritos en un lenguaje de definición de transformación. Tenga en cuenta que el OMG ha emitido un RFP (MOF 2.0 Query/Views/Transformations RFP) esperando la estandarización (para MOF) de lenguajes para la creación de vistas de modelo, la consulta de modelos y la elaboración de definiciones de transformación. La guía MDA describe varios enfoques por lo que se refiere a la transformación, entre los que se incluye:

  • Transformación de metamodelos: este enfoque supone que hay un metamodelo MOF de nivel PIM en el lenguaje en el que se crea el PIM. Igualmente, para la plataforma seleccionada, existe un metamodelo de nivel PSM en el lenguaje en el que puede construirse un PSM. A continuación, se utiliza una correlación entre los dos metamodelos para construir una definición de transformación. Ésta se utiliza para transformar el PIM en PSM.
  • Marcación: se prepara una correlación de la plataforma seleccionada. Esta correlación se utiliza para construir una definición de transformación, la cual incluye un conjunto de marcas que se utilizan para marcar elementos del PIM, con lo cual se obtiene un PIM marcado y una definición de lo que debe hacerse con los elementos marcados. A continuación, se continua transformando el PIM marcado para crear el PSM. El marcado suele ser un proceso manual, pero la transformación subsiguiente puede ser automatizada.
  • Transformación de modelos: el PIM se crea utilizando tipos independientes de plataforma, también especificados en un modelo, donde los elementos del PIM son subtipos de los tipos independientes de plataforma. Se selecciona una plataforma particular, la cual se asocia con un conjunto de tipos específicos de plataforma. Se realiza una correlación entre los dos conjuntos de tipo y se obtiene una definición de transformación, que se aplica al PIM, con lo cual es crea un PSM expresado en subtipos de los tipos específicos de plataforma. Este enfoque es algo similar a la transformación de metamodelos, excepto por el hecho de que la transformación está limitada a tipos de un modelo en lugar de a conceptos de un metamodelo MOF.
  • Aplicación de patrón: el PIM se crea mediante un conjunto de tipos y patrones abstractos que son independientes de la plataforma. Para la plataforma seleccionada, existe un conjunto de tipos y patrones específicos de plataforma. Se crea una correlación entre los dos conjuntos de tipos y patrones, con lo cual se obtiene una definición de transformación que debe aplicarse al PIM. Esto crea un PSM en el que los patrones abstractos se convierten en específicos de plataforma.

Para obtener más detalles, consulte la guía MDA [OMG03].

¿Cómo se aplica la transformación? Ir a la parte superior de la página

El escenario más simple para la aplicación de MDA es:

  1. Preparar un PIM
  2. Seleccionar una plataforma
  3. Preparar una correlación si no existe ninguna
  4. Aplicar la transformación para producir un PSM
  5. Convertir el PSM en código. Si no es necesario seguir perfeccionando el PSM y se puede implementar directamente, se tratará de una implementación, tal como se define en la sección siguiente.

Es posible generar PSM para otras plataformas del mismo modo.

Aplicación repetida del patrón MDA Ir a la parte superior de la página

Sin embargo, el patrón MDA se adapta bien a la aplicación repetida: un PSM generado en un nivel se convierte en PIM para el siguiente; es decir, una selección de plataforma cada vez más especializada. Tenga en cuenta que en MDD, tal como se ha descrito en RUP y su soporte con el conjunto de herramientas Rational de IBM, nuestra preferencia es minimizar el número de pasos de perfeccionamiento; es decir, proceder a partir de una representación que sea cercana a la sentencia de problema del cliente para una forma ejecutable de la forma más directa posible.

Tres aplicaciones repetidas del patrón MDA, para tres plataformas diferentes

Aplicación repetida del patrón MDA

La finalidad del diagrama anterior es mostrar tres aplicaciones del patrón MDA, con el PIM inicial convirtiéndose en un PSM dependiente de la plataforma 1. A continuación, se vuelve a depender de la plataforma 2, luego se vuelve a transformar para que dependa de las plataformas 1, 2 y 3.

Transformación general entre modelos Ir a la parte superior de la página

Los mismos conceptos pueden aplicarse a una transformación general; es decir, de cualquier modelo a cualquier modelo. Si, por ejemplo, existen dos metamodelos cuyos idiomas se utilizan para expresar los modelos, se podrá crear, en principio, una correlación con la que se obtendrá una definición de transformación. Esto se aplica tal como se ha descrito para la transformación de PIM en PSM.

Implementación Ir a la parte superior de la página

La guía MDA utiliza "implementación" de un modo parecido al modelo de implementación de RUP. Se trata de una especificación de todos los Elementos de implementación necesarios para construir, desplegar, instalar y hacer funcionar el sistema.

Un PSM en sí puede ser una implementación o puede que sea necesario perfeccionarlo más para que pueda convertirse en código. Tenga en cuenta que la producción de un PSM de implementación puede omitir el paso en el que se muestra el PSM y puede convertirse directamente en código. En este caso, el PIM más abstracto puede convertirse directamente en código mediante el motor de transformación. Es posible que todavía se proporcione una visualización del código para mejorar la comprensión del desarrollador, aunque se puede revertir la ingeniería de esto a partir del código.

Ventajas supuestasIr a la parte superior de la página

Portabilidad e interoperabilidadIr a la parte superior de la página

MDA ofrece la posibilidad de llegar a controlar los gastos e inconvenientes del avance de la tecnología permitiendo volver a dirigir un conjunto relativamente estable de PIM a la tecnología que sea necesaria. La expectativa es que, con la cada vez mayor aceptación de MDA, los desarrolladores de la nueva tecnología también proporcionarán correlaciones de modo que las transformaciones puedan realizarse rápidamente.

Al ampliar las correlaciones PIM-PSM para dos plataformas, MDA sugiere la creación de "puentes" entre los dos PSM y, en último término, entre las dos implementaciones, de modo que se pueda distribuir un PIM por las plataformas. La mayoría de empresas se enfrentan al hecho de tener que desarrollar entornos heterogéneos con una mezcla de tecnologías antiguas y nuevas; por lo tanto, esta posibilidad de llevar a cabo la interoperabilidad puede llegar a resultar realmente ventajoso.

Coste de ciclo de vida reducido Ir a la parte superior de la página

Productividad Ir a la parte superior de la página

El centro de atención del desarrollo con MDA pasa a ser el PIM más abstracto. Con un conjunto de herramientas potentes para generar un PSM (o código), un entorno de estas características debería ser más productivo de un modo bastante parecido a lo que supone trabajar con un lenguaje de alto nivel es más productivo que trabajar en un ensamblador, particularmente si un PIM, o un elemento parecido, se desarrolla a menudo utilizando un método cualquiera, por ejemplo, para servir como modelo de diseño en RUP. El aumento de la productividad depende principalmente de la intervención manual que sea necesaria en el proceso de transformación.

Calidad Ir a la parte superior de la página

Idealmente, en MDA, el objetivo de mantenimiento es el PIM. En consecuencia, con la condición de que la arquitectura del PIM sea correcta, deberían haber menos defectos en la vida del producto, ya que existen menos ocasiones en las que una persona puede "inyectar" dichos defectos. La reparación de los defectos que se encuentren debería resultar más económica, gracias a las ventajas de la transformación automática. La concentración en el PIM también está más estrechamente alineada con cuestiones del dominio, con lo cual es posible que la probabilidad de satisfacer las necesidades del usuario sea mayor.