UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE FISICA Y MATEMATICAS

TALLER 16
INGENIERIA DIRIGIDA POR MODELOS

ÁREA
METODOLOGIA, DESARROLLO Y CALIDAD EN
INGENIERIA EN SOFTWARE

TEMA
“INGENIERIA DIRIGIDA POR MODELOS”

GRUPO
LSI. CARLOS MARIN SANTANA
LSI. ANDRES GOMEZ CEDEÑO

2020
GUAYAQUIL - ECUADOR
 ÍNDICE

1. INGENIERIA DIRIGIDA POR MODELOS..................................... 3

2. INGENIERIA DIRIGIDA POR MODELOS (MDA) ....................... 44

3. INGENIERIA DIRIGIDA POR MODELOS (OCL) ........................ 46

4. INGENIERIA DIRIGIDA POR MODELOS (DSL) ........................ 49

5. TRANSFORMACIONES DE MODELOS .................................... 50

6. BIBLIOGRAFIA ........................................................................... 52
1. INGENIERIA DIRIGIDA POR MODELOS
Las tecnologías de ingeniería impulsadas por modelos ofrecen un
enfoque prometedor para abordar la incapacidad de la tercera generación
de lenguajes para aliviar la complejidad de las plataformas y expresar
conceptos de dominio de forma eficaz.
En las últimas cinco décadas, los investigadores y desarrolladores de
software han estado creando abstracciones que les ayuda programa en
términos de su intención de diseño en lugar del entorno informático
subyacente, por ejemplo, CPU, memoria, y dispositivos de red y
protegerlos de las complejidades de estos entornos.
Desde los primeros días de la informática, estas abstracciones incluían
tecnologías tanto de lenguaje como de plataforma. Por ejemplo, los
primeros lenguajes de programación, como ensamblador y Fortran,
protegían a los desarrolladores de las complejidades de la programación
con código de máquina. Asimismo, las primeras plataformas de sistemas
operativos, como OS / 360 y Unix, protegían a los desarrolladores de
complejidades de la programación directamente al hardware. Aunque
estos lenguajes y plataformas tempranos elevaron el nivel de abstracción,
todavía tenían un distintivo "orientado a la computación" atención. En
particular, proporcionaron abstracciones del espacio de la solución, es
decir, el dominio de las tecnologías informáticas. en sí mismos, en
lugar de abstracciones del espacio de problemas que expresan diseños
en términos de conceptos en aplicación dominios, como
telecomunicaciones, aeroespacial, salud, seguros y biología.
LECCIONES DE INGENIERÍA DE SOFTWARE ASISTIDA POR
COMPUTADORA
Varios esfuerzos anteriores han creado tecnologías que elevaron aún más
el nivel de abstracción utilizado para desarrollar software. Un esfuerzo
destacado iniciado en la década de 1980 fue la ingeniería de software
asistida por computadora (CASE), que se centró en desarrollar métodos y
herramientas de software que permitieron a los desarrolladores expresar
sus diseños en términos de gráficos de propósito general
representaciones de programación, como máquinas de estado, diagramas
de estructura y diagramas de flujo de datos. Uno de los objetivos de
CASE era para permitir un análisis más completo de programas gráficos
que incurren en menos complejidad que los de propósito general
convencionales lenguajes de programación, por ejemplo, al evitar la
corrupción de la memoria y las fugas asociadas con lenguajes como C.
Otro objetivo era sintetizar artefactos de implementación a partir de
representaciones gráficas para reducir el esfuerzo de manualmente
programas de codificación, depuración y portabilidad. Aunque CASE
atrajo una atención considerable en la literatura de investigación y
comercio, no fue ampliamente adoptado en la práctica. Un problema que
enfrentó fue que las representaciones de lenguaje gráfico de propósito
general para programas de escritura en herramientas CASE mal mapeado
en las plataformas subyacentes, que eran en gran parte sistemas
operativos de un solo nodo, como DOS, OS / 2 o Windows: que
carecía de soporte para propiedades importantes de calidad de servicio
(QoS), como distribución transparente, fallas tolerancia y seguridad. La
cantidad y complejidad del código generado necesario para compensar la
escasez de plataformas subyacentes estaba más allá del alcance
de las tecnologías de traducción disponibles en ese momento, lo que
dificultaba desarrollar, depurar y desarrollar herramientas y aplicaciones
CASE creadas con estas herramientas.
Otro problema con CASE fue su incapacidad de escalar para manejar
sistemas complejos a escala de producción en una amplia gama de
dominios de aplicación. En general, las herramientas CASE no admitían
ingeniería concurrente, por lo que se limitaban a programas escrito
por una sola persona o por un equipo que serializó su acceso a los
archivos utilizados por estas herramientas. Además, debido a la falta de
potentes plataformas de middleware comunes, las herramientas CASE se
dirigían a entornos de ejecución propietarios, lo que dificultaba la integrar
el código que generaron con otros lenguajes de software y tecnologías de
plataforma. Las herramientas CASE tampoco eran compatibles muchos
dominios de aplicación de forma eficaz porque sus representaciones
gráficas de "talla única" eran demasiado genéricas y no personalizable.
En la medida en que las herramientas CASE se aplicaron en la
práctica, se limitaron en gran medida a un subconjunto de herramientas
que permitían a los diseñadores dibujar diagramas de arquitecturas
de software y decisiones de diseño de documentos, que los
programadores luego utilizaron para ayudar a guiar el creación y
evolución de sus implementaciones artesanales. Dado que no hubo una
relación directa entre los diagramas y las implementaciones, sin embargo,
los desarrolladores tendieron a no poner mucho énfasis en la precisión de
los diagramas, ya que rara vez estaban sincronizados con el código
durante las etapas posteriores de los proyectos.

LIMITACIONES ACTUALES DE LENGUA Y PLATAFORMA

Los avances en lenguajes y plataformas durante las últimas dos décadas
han elevado el nivel de abstracciones de software disponibles a
los
desarrolladores, aliviando así un impedimento para los esfuerzos
anteriores de CASE. Por ejemplo, los desarrolladores de hoy suelen
utilizar lenguajes orientados a objetos más expresivos, como C ++, Java o
C #, en lugar de Fortran o C. Las bibliotecas de clases reutilizables y las
plataformas de marcos de aplicaciones minimizan la necesidad de
reinventar los dominios comunes y específicos. servicios de middleware,
como transacciones, descubrimiento, tolerancia a fallas, notificación de
eventos, seguridad y recursos distribuidos administración. Debido a la
maduración de lenguajes de tercera generación y plataformas
reutilizables, por lo tanto, los desarrolladores de software ahora
están mejor equipados para protegerse de las complejidades asociadas
con la creación de aplicaciones utilizando tecnologías.
A pesar de estos avances, persisten varios problemas
desconcertantes. En el corazón de estos problemas está el crecimiento
de la plataforma complejidad, que ha evolucionado más rápido que la
capacidad de los lenguajes de propósito general para enmascararla. Por
ejemplo, popular las plataformas de middleware, como J2EE, .NET y
CORBA, contienen miles de clases y métodos con muchas
intrincadas dependencias y efectos secundarios sutiles que requieren un
esfuerzo considerable para programar y sintonizar correctamente.
Además, dado que estos las plataformas a menudo evolucionan
rápidamente, y aparecen nuevas plataformas con regularidad, los
desarrolladores realizan un esfuerzo considerable manualmente
portando el código de la aplicación a diferentes plataformas o
versiones más recientes de la misma plataforma.
Un problema relacionado es que la mayoría del código de la aplicación y
la plataforma todavía se escribe y mantiene manualmente utilizando
lenguajes de tercera generación, que implican un tiempo y esfuerzos
excesivos, especialmente para actividades clave relacionadas con la
integración, como implementación, configuración y garantía de calidad del
sistema. Por ejemplo, es difícil escribir código Java o C # que implementa
correcta y óptimamente sistemas distribuidos a gran escala con cientos o
de software interconectado. componentes. Incluso utilizando notaciones
más nuevas, como descriptores de implementación basados en XML
populares entre componentes y las plataformas de middleware de
arquitectura orientada a servicios están plagadas de complejidad. Gran
parte de esta complejidad se debe a la brecha semántica entre la
intención del diseño, por ejemplo, ¿” implementar los componentes 1-
50 en los nodos AG y los componentes 51-100 en los nodos HN de
acuerdo con los requisitos de recursos del sistema y la disponibilidad? "y
la expresión de esta intención en miles de líneas de XML hecho a
mano cuya sintaxis visualmente densa no transmite ni semántica de
dominio ni intención de diseño.
Debido a este tipo de problemas, la industria del software está llegando a
un techo de complejidad donde la plataforma de próxima generación las
tecnologías, como los servicios web y las arquitecturas de líneas de
productos, se han vuelto tan complejas que los desarrolladores pasan
años dominar y luchar con las API de la plataforma y los patrones de
uso, y a menudo están familiarizados con solo un subconjunto de
plataformas que utilizan con regularidad. Además, los lenguajes de
tercera generación requieren que los desarrolladores presten mucha
atención a Numerosos detalles tácticos de programación imperativa que a
menudo no pueden enfocarse en cuestiones arquitectónicas estratégicas
como corrección y rendimiento en todo el sistema.
Estas vistas fragmentadas dificultan a los desarrolladores saber qué
partes de sus aplicaciones son susceptibles de efectos que surgen de los
cambios en los requisitos de los usuarios y los entornos de idioma /
plataforma. La falta de una integrada vista, junto con el peligro de efectos
secundarios imprevistos, a menudo obliga a los desarrolladores a
implementar soluciones subóptimas que duplicar innecesariamente el
código, violar los principios arquitectónicos clave y complicar la evolución
del sistema y la garantía de calidad.

INGENIERÍA IMPULSADA POR MODELOS

Un enfoque prometedor para abordar la complejidad de la plataforma y la
incapacidad de los lenguajes de tercera generación para aliviar esto
complejidad y expresar conceptos de dominio de manera efectiva:
es desarrollar tecnologías de ingeniería impulsada por modelos (MDE)
que combinar lo siguiente:
Lenguajes de modelado específicos de dominio cuyos sistemas de tipos
formalizan la estructura, el comportamiento y requisitos dentro de
dominios particulares, como radios definidas por software, informática de
misión de aviónica, en línea servicios financieros, gestión de almacenes o
incluso el dominio de las plataformas de middleware. Se describen los
DSML utilizando metamodelos, que definen las relaciones entre
conceptos en un dominio y especifican con precisión la clave semántica y
restricciones asociadas con estos conceptos de dominio. Los
desarrolladores utilizan DSML para crear aplicaciones usar elementos del
sistema de tipos capturados por metamodelos y expresar la intención del
diseño de manera declarativa en lugar de imperativamente.
Motores de transformación y generadores que analizan ciertos aspectos
de modelos y luego sintetizan varios tipos de artefactos, como código
fuente, entradas de simulación, descripciones de implementación XML o
modelo alternativo representaciones. La capacidad de sintetizar artefactos
a partir de modelos ayuda a garantizar la coherencia entre aplicaciones
implementaciones e información de análisis asociada con los requisitos
funcionales y de QoS capturados por modelos.
Este proceso de transformación automatizado a menudo se denomina "
correcto por construcción “, en contraposición a procesos de desarrollo de
software convencionales hechos a mano de " construcción por
corrección " que son tediosos y erróneos propenso.
Las tecnologías MDE existentes y emergentes aplican las lecciones
aprendidas de esfuerzos anteriores para desarrollar plataformas de alto
nivel y abstracciones del lenguaje. Por ejemplo, en lugar de notaciones de
propósito general que rara vez expresan conceptos de dominio de
aplicación la intención del diseño y, dsmls se pueden adaptar a través de
meta modelado de ajustar con precisión el dominio ' s semántica y
sintaxis. Teniendo
Los elementos gráficos que se relacionan directamente con un dominio
familiar no solo ayudan a aplanar las curvas de aprendizaje, sino que
también ayudan a una amplia gama de expertos en la materia, como
ingenieros de sistemas y arquitectos de software experimentados,
garantizan que el software los sistemas satisfacen las necesidades del
usuario. Además, las herramientas MDE imponen restricciones
específicas de dominio y realizan la verificación del modelo que puede
detectar y prevenir muchos errores al principio del ciclo de vida.
En las décadas de 1980 y 1990, los generadores de herramientas MDE
no necesitan ser tan complicados, ya que pueden sintetizar artefactos que
se asignan a API y marcos de plataforma de middleware de nivel superior,
a menudo estandarizados, en lugar de API de SO de nivel inferior. Como
resultado, que ' es a menudo mucho más fácil de desarrollar, depurar y
evolucionar herramientas MDE y las aplicaciones creadas con estas
herramientas.
2. INGENIERIA DIRIGIDA POR MODELOS (MDA)

La ingeniería dirigida por modelos surge como la respuesta de la

ingeniería de software a la industrialización del desarrollo de software,
MDA es la propuesta de la OMG, que centra sus esfuerzos en reconocer,
que la interoperabilidad es fundamental y el desarrollo de modelos
permite la generación de otros modelos que luego al ser juntados
proveerán la solución a todo un sistema e independiza el desarrollo de las
tecnologías empleadas.
El concepto del modelado, como una de las estrategias básicas del
desarrollador para entender un problema y proponer una solución, es
ampliamente aceptado en la ingeniería de software, mucho antes
del surgimiento de MDA. Sin embargo, la aplicación del modelado en la
práctica diaria presenta problemas como los enunciados a continuación:

- Los modelos se usan solo como documentación. Los modelos no

funcionan como un artefacto activo que contribuya en el proceso de
desarrollo.

- Existen vacíos entre el modelo y la implementación de los sistemas. Los

cambios en el modelo no se reflejan en el código y los cambios en el
código no se reflejan en los modelos, sólo se genera el código de los
modelos la primera vez y nunca se actualiza.

- No hay una adecuada mezcla de modelos. Vistas desconectadas de un

sistema (desconexión horizontal) y grupos de modelos
desconectados (desconexión vertical).

- No hay transformación de modelos. Pocos lenguajes de transformación

populares y pocas herramientas que soporten estas transformaciones.

Lo anterior les atribuye a los modelos la fama de una costosa y pesada

carga que complica la labor de los participantes en el proceso de
desarrollo. La MDA rescata la importancia de los modelos como estrategia
clave para entender y especificar una solución de software y
progresivamente obtener la solución final. Las siguientes son
algunas definiciones de modelo de la comunidad de MDA (OMG-MDA,
2003; Kleppe et al., 2003).

- Un modelo es la descripción de un sistema (o de una parte) en un

lenguaje bien definido.
- Un lenguaje bien definido es un lenguaje con una forma definida
(sintaxis) y significado (semántica) que sea apropiado para ser
interpretado automáticamente por un computador (Kleppe et al., 2003).

- Un modelo se presenta con frecuencia como una combinación de

dibujos y de texto (OMG-MDA, 2003).

La MDA aparece como respuesta a dos problemas fundamentales dentro

de la industria informática.

La diversidad de plataformas y tecnologías: en la actualidad se oye hablar

con frecuencia de los objetos distribuidos, los componentes, los
aspectos o los web services, entre otras tantas estrategias tecnológicas
en las que no hay mucha interoperabilidad y que tienen tendencia a
aumentar.

- La acelerada evolución tecnológica: esto ocasiona que las plataformas

muy pronto sean obsoletas. Surgen, entonces, interrogantes como: ¿Cuál
tecnología va a salir mañana? ¿Cuánto va a durar la última versión de
una plataforma? ¿Cómo protejo mi inversión? Por consiguiente, nunca se
tiene un verdadero estándar en el nivel de sistema operativo, servidores,
plataformas o middleware, lo cual dificulta considerablemente el reúso de
los artefactos software, y más aun en etapas tempranas del proceso. Las
estrategias para alcanzar beneficios fundamentales, como productividad,
interoperabilidad, "portabilidad" y facilidad de mantenimiento, se plantean
en las ideas del manifiesto MDA (Booch et al., 2004):
- Representación directa. Esta estrategia se basa en el principio de
abstracción, que hace énfasis en el dominio del problema más que en la
tecnología. Los diferentes tipos de modelos mencionados buscan precisar
una semántica que claramente separe los aspectos relevantes del
problema de las decisiones de tecnología. Esta estrategia parte de la
hipótesis de que los impactos considerables en el desarrollo y
mantenimiento de una solución de software se dan por cambios en el
negocio, más que por la diversidad de plataformas y la evolución
tecnológica.

- Automatización. La propuesta de MDA fortaleció y dinamizó el papel que

las herramientas CASE tienen en el desarrollo de soluciones.
Surgen nuevas funcionalidades que deben ser soportadas por las
herramientas como el intercambio de modelos, verificación de
consistencia, transformación de modelos y manejo de metamodelos, entre
otras. Desde la perspectiva de MDA, el papel de las herramientas es
esencial para apoyar de forma consistente y sistémica el proceso de
desarrollo visto como un proceso de transformación de modelos.

- Estándares abiertos. El uso de estándares se ha constituido en el medio

que ha posibilitado el reto de integrar herramientas robustas de apoyo al
desarrollo. Por ejemplo, los estándares como UML deben expresarse en
XML, de esta forma resultan de gran utilidad en mecanismos de
transformación de modelos que utilizan otros estándares como XSLT6.

3. INGENIERIA DIRIGIDA POR MODELOS (OCL)

OCL es un lenguaje notacional, subconjunto del UML estándar, industrial,

que permite a los desarrolladores de software escribir restricciones sobre
modelos de objetos (pre y pos condiciones, invariantes, valores
derivados y restricciones sobre operaciones). Estas restricciones son
particularmente útiles, en la medida en que permiten a los desarrolladores
crear un amplio conjunto de reglas que rigen el aspecto de un objeto
individual (Cabot, y otros, 2012).

Es un lenguaje formal para expresar restricciones libres de efectos

colaterales. Los usuarios del Lenguaje Unificado para Modelado (UML) y
de otros lenguajes, pueden usar el OCL para especificar restricciones y
otras expresiones incluidas en sus modelos. Según (Pandey; 2011) el
OCL tiene características de un lenguaje de expresión, de un lenguaje de
modelado y de un lenguaje formal. En el modelado orientado a objetos,
un modelo gráfico como el de clases no es suficiente para lograr
una
especificación precisa y no ambigua. Existe la necesidad de describir
características adicionales sobre los objetos del modelo. Muchas veces
estas características se describen en lenguaje natural. La práctica ha
revelado que muy frecuentemente esto produce ambigüedades. Para
escribir características no ambiguas se han desarrollado los lenguajes
formales (Romero, 2010).

OCL tiene las características de un lenguaje de expresiones, un lenguaje

de modelos y un lenguaje formal:

OCL es un lenguaje de expresiones puro. Esto significa que un estado

del sistema nunca cambiará debido a una expresión OCL, incluso una
expresión OCL podría usarse para describir tal cambio de estado (p.e. en
una postcondición). Los valores de todos los objetos, incluidos los
enlaces, no cambiarán. En cualquier momento en que se evalúa una
expresión OCL, simplemente devuelve un valor (Olivé, y otros, 2007).
OCL es un lenguaje de modelos y no un lenguaje de programación. No
se puede escribir un programa lógico o un flujo de control en OCL.
Especialmente, no se puede invocar procesos o activar operaciones de
consulta en OCL. Debido a que OCL es en primer lugar un lenguaje de
modelos, no se puede asegurar que todo sea directamente ejecutable.
Como lenguaje de modelos, todos los aspectos de implementación están
fuera de alcance y no pueden expresarse en OCL. Cada expresión
OCL es conceptualmente atómica. El estado de los objetos en el sistema
no puede cambiar durante la evaluación.
OCL es un lenguaje formal donde todos los constructores tienen un
significado formal definido. La especificación de OCL es parte de la
especificación de UML. OCL no tiene la intención de reemplazar los
lenguajes formales existentes. Los lenguajes formales tradicionales se
usaban por personas con conocimientos matemáticos, pero dificulta
su uso para la mitad de empresas y modeladores de sistemas. OCL ha
sido desarrollado para llenar este hueco (Casas, y otros, 2010).

Puesto que en un proyecto hay muchas personas involucradas (usuario,

expertos, encargados del mantenimiento y demás.) los modelos deben
ser entendidos por una amplia y variada audiencia. OCL es fácil de
aprender y usar por los desarrolladores sin amplios conocimientos
matemáticos. OCL tiene ciertas características que permiten a los
desarrolladores adoptarlo a su ritmo y sólo donde lo necesiten. Hace
accesibles las especificaciones formales con un trasfondo matemático
limitado (Cabot, y otros, 2012).

Según OMG (del inglés, Object Managment Group) (OMG, 2006), OCL
puede ser usado con distintos propósitos:
Para especificar características estáticas sobre clases y tipos en
un modelo de clases.
Para especificar características estáticas de tipo para Estereotipos.
Para especificar pre y post-condiciones sobre Operaciones y
Métodos. Como lenguaje de navegación.
Para especificar restricciones sobre operaciones.

Dentro de la semántica del UML, el OCL es usado en la sección reglas,

como constantes estáticas sobre las meta-clases en la sintaxis abstracta.
Varios diseñadores también lo utilizan para definir operaciones
'adicionales', que son tomadas en cuenta en la formación de
reglas.

DEFINICION DE RESTRICCIONES CON OCL

Usualmente se debe definir otras restricciones a instancias,

independientemente de las ya existentes en UML y otros lenguajes de
modelado conceptual. Para ello OMG propone el uso de OCL (Cabot, y
otros, 2005).

En OCL quedaría de la siguiente manera:

context Persona
inv: padre.FechaN < self.FechaN
and mother.FechaN < self.FechaN
Según las definiciones de RI vistas anteriormente esta se podría clasificar
como; de fuente empírica, alcance estático y la causa de la violación es
evento-violable.

Esta restricción posteriormente debería ser portada a SQL estándar al

pasar al esquema físico, mediante el uso de la cláusula CHECK o
TRIGGERS, quedando esto en manos del administrador de la BD.

La definición correcta de las RI pasa por conocer las diversas

clasificaciones de estas atendiendo fundamentalmente a la fuente,
alcance y la causa de la violación.

El chequeo de RI desde el modelo conceptual optimiza el diseño, al ser

este semánticamente más preciso que dejar la responsabilidad de
chequear la integridad a la etapa del modelado físico, al introducir el
modelo en el gestor de base de datos escogido, cambiando por tanto lo
modelado en los pasos anteriores; conceptual y lógico. La mayoría de los
lenguajes de modelación no traen implícitos un chequeo de las RI sino
que agregan otros lenguajes, extenciones o herramientas para lograr este
propósito. El lenguaje UML integra el sub lenguaje OCL para describir las
restricciones. Es un lenguaje formal, fácil de leer y de escribir.

OCL no carece de deficiencias a la hora de su implementación y

definición de RI y para solucionar estos problemas existen otras
alternativas como las propuestas en (Miliauskaite, 2005) y otros trabajos
que plantean el chequeo de RI en el modelo entidad relación (Saura,
2013), aun así OCL es una sólida opción, especialmente si se modela
utilizando UML como lenguaje para el modelado conceptual.

4. INGENIERIA DIRIGIDA POR MODELOS (DSL)

Estos lenguajes se denominan DSLs (por su nombre en inglés: Domain-

Specific Language) y permiten especificar la solución usando
directamente conceptos del dominio del problema. Los productos finales
son luego generados desde estas especificaciones de alto nivel. Esta
automatización es posible si ambos, el lenguaje y los generadores, se
ajustan a los requisitos de un único dominio. Definimos como dominio
a un área de interés para un esfuerzo de desarrollo en particular. En
la práctica, cada solución DSM se enfoca en dominios pequeños porque
el foco reductor habilita mejores posibilidades para su automatización
y estos dominios pequeños son más fáciles de definir. Usualmente,
las
soluciones en DSM son usadas en relación a un producto particular, una
línea de producción, un ambiente específico, o una plataforma.
El desafío de los desarrolladores y empresas se centra en la definición de
los lenguajes de modelado, la creación de los generadores de código y la
implementación de frameworks específicos del dominio, elementos clase
ves de una solución DSM. Estos elementos no se encuentran demasiado
distantes de los elementos de modelado de MDD. Actualmente puede
observarse que las discrepancias entre DSM y MDD han comenzado a
disminuir. Podemos comparar el uso de modelos así como la
infraestructura respectiva en DSM y en MDD. En general, DSM usa los
conceptos dominio, modelo, metamodelo, meta-metamodelo como MDD,
sin mayores cambios y propone la automatización en el ciclo de vida
del software. Los DSLs son usados para construir modelos. Estos
lenguajes son frecuentemente -pero no necesariamente- gráficos. Los
DSLs no utilizan ningún estándar del OMG para su infraestructura,
es decir no están basados en UML, los metamodelos no son
instancias de MOF, a diferencia usan por ejemplo MDF, el framework
de Metadatos para este propósito.
Finalmente, existe una familia importante de herramientas para crear
soluciones en DSM que ayudan en la labor de automatización. En tal
sentido, surge el término “Software Factories”, que ha sido acuñado por
Microsoft. Su descripción en forma detallada puede encontrarse en el libro
de Greenfields [GS04] del mismo nombre. Una Software Factory es una
línea de producción de software que configura herramientas de desarrollo
extensibles tales como Visual Studio Team System con
contenidoempaquetado como DSLs, patrones y frameworks, basados en
recetas para construir tipos específicos de aplicaciones. Visual Studio
provee herramientas para definir los metamodelos así como su sintaxis
concreta y editores.

5. TRANSFORMACIONES DE MODELOS

La transformación de modelos se considera el proceso central de MDA.

Con el propósito de lograr un estándar para la transformación, OMG inicia
un proceso de estandarización que favorece la presentación de
propuestas (RFP Request for Proposal) por parte de toda la comunidad
informática alrededor del estándar denominado QVT (Queries/Views/
Transformations). Este estándar está basado en MOF y pretende
establecer un lenguaje para la transformación de modelos (T), un
lenguaje para consulta de modelos (Q) y un lenguaje para la
definición y generación de vistas (V) que facilite el análisis de modelos
desde diferentes perspectivas de los desarrolladores. En esta
sección se
presentan las consideraciones más importantes alrededor del proceso de
transformación.

La transformación es el proceso que, basado en una serie de reglas,

define los mecanismos para el paso de un modelo origen a un modelo
destino. A partir de la estandarización promovida por QVT y atendiendo a
las necesidades prácticas de la transformación de modelos, surgen
diversas estrategias de transformación que van más allá del uso de
elementos del metamodelo y definen mecanismos de transformación
basados en tipos de elementos, patrones, información de la plataforma y
otros modelos e información adicional (OMG-MDA, 2003).

La figura 7 ilustra la arquitectura de transformac.ión de modelos; en

ella se muestra cómo se definen y aplican las transformaciones que se
basan en el uso de metamodelos (Jezequel, 2005).

Una de las ventajas de esta arquitectura

es

lograr que de un mismo PIM se pueda generar más de un PSM. Para

permitir la interoperabilidad entre los diferentes PSM o las diferentes
porciones de código generados, surgen los llamados puentes (bridges).
Estos puentes podrían, por ejemplo, definir las relaciones entre un PSM
que representa una solución en una base de datos relacional y un PSM
que representa una solución en una plataforma J2EE; el puente estaría
representado por la lógica de acceso a datos de la aplicación, y de esta
manera se podrían coordinar y tener en cuenta en cada uno de los
modelos los cambios realizados en el otro. A continuación se describen
las dos principales operaciones que deben ser realizadas sobre los
modelos en su proceso de transformación.
6. BIBLIOGRAFIA

https://www.youtube.com/watch?v=vhSoren2bJA

http://di002.edv.uniovi.es/~cueva/asignaturas/masters/2008/MDE_udistritl.
pdf

http://www.scielo.org.co/pdf/dyna/v78n169/a05v78n169.pdf

https://www.youtube.com/watch?v=idDfo126BOk

https://www.youtube.com/watch?v=bNUwOUEYphk

https://modeling-languages.com/ocl-tutorial/

https://modelinglanguages.com/wpcontent/uploads/2012/03/OCLChapter.
pdf

https://www.omg.org/spec/OCL/2.4/PDF