La ingeniera basada en modelos abstractos (MDE) puede Ingeniera de dominio,

ofreciendo soporte a la variabilidad compleja Y la implementacin automtica. Sin

embargo, poca atencin es El proceso de diseo de una arquitectura de dominio
que Se adapta bien a las tcnicas del MDE, como las Idiomas y transformaciones de
software. Un dominio especfico La arquitectura del software se desarrolla
normalmente sobre la base de unos pocos requisitos seleccionados e importantes,
llamados drivers de arquitectura. Este documento presenta tres tipos de
conductores de arquitectura que Puede utilizarse para construir una arquitectura de
software que Ventaja de los beneficios de MDE. Tambin presenta algunos
Patrones que se pueden utilizar para ayudar en el diseo arquitectnico. Un
Tambin se presenta una evaluacin, que muestra que, cuando se En un proyecto
de ingeniera de dominio impulsado por modelos, estos controladores Y los patrones
pueden conducir a algunos beneficios en trminos de reutilizacin
Y complejidad, pero que en algunos casos hay inconvenientes Que deben ser
considerados en un anlisis de trade-off.

Introduccin
Una de las principales tareas de la ingeniera de dominio es definir una arquitectura
de software de dominio especfico que apoya la comunidad y la variabilidad [1]. La
arquitectura no slo debe predecir los puntos de variacin, sino tambin
proporcionar el apoyo necesario, normalmente en forma de componentes
reutilizables [2]. La ingeniera impulsada por el modelo (MDE)
Este proceso con lenguajes especficos de dominio y transformaciones que
proporcionan soporte para una variabilidad ms compleja y una implementacin
automatizada.
Para hacer posible este escenario de ingeniera de dominio impulsado por modelos
(MDDE), la arquitectura de software debe construirse alrededor del concepto de
MDE, estar consciente y dar soporte
A sus tecnologas, para que el proceso de desarrollo de aplicaciones pueda
aprovechar al mximo sus beneficios.
Sin embargo, la mayora de los enfoques basados en modelos para la ingeniera de
dominios y la ingeniera de lneas de productos se centran en la tarea de derivacin
del producto, despus de que la arquitectura ya est definida (dos ejemplos son [3],
[4]). En general, no se da suficiente atencin al proceso de diseo de una
arquitectura que sea adecuada para MDE. Tratamos de abordar esta cuestin de dos
maneras: (i) mediante la identificacin de tres tipos de conductores de arquitectura
MDE-especficos [2]; Y (ii) presentando algunos patrones para tratar con ellos.

Cuando se usan juntos, facilitan la tarea de disear arquitecturas para MDE. Los conductores
guan al arquitecto del dominio a travs de la identificacin de las diferentes posibilidades de
variabilidad del dominio, mientras que los patrones ayudan proporcionando soluciones a
algunos de los problemas involucrados en el diseo de dominio basado en modelos. Tambin
presentamos los resultados de una evaluacin realizada para demostrar la viabilidad, los
beneficios y los inconvenientes del uso de estos conductores y patrones.

II. VARIABILIDAD DE DOMINIO E INGENIERA MODELO

Variabilidad es el concepto clave detrs de una arquitectura de dominio exitosa [1].

Hay dos tipos de variabilidad de dominio [6]: configuracin de rutina - un subconjunto
de caractersticas se selecciona para configurar un producto, utilizando estructuras
parecidas a un rbol; Y la construccin creativa - los modelos describen la variacin
Estructuras grficas. La mayora de los enfoques de diseo de dominio se basan en la
identificacin de la variabilidad, tal como se describe en trminos de rasgos [7] - las
caractersticas observables externamente de un producto. El modelado de la
caracterstica est situado en alguna parte entre la configuracin rutinaria y la
construccin creativa [6], y se ha utilizado ya en muchos casos acertados. Sin
embargo, hay otros tipos de variacin, como en los modelos de entidad [8], que son
ms complejos de lo que es posible capturar en los modelos de caractersticas, porque
son demasiado genricos [3]. Estos requieren un mecanismo ms rico, con ms poder
expresivo para capturar relaciones detalladas y restricciones entre entidades. La
tecnologa de eleccin para esto es normalmente un dominio de Lenguaje Especfico
(DSL) [3], [6]. Junto con las transformaciones de modelos y generadores de cdigo,
Las DSL forman la base de la ingeniera impulsada por modelos (MDE). Por ejemplo,
considere un dominio de autora web que incluya aplicaciones publicar-navegar. Un
administrador publica informacin, como noticias, publicaciones, mensajes, etc., a las
que pueden acceder los usuarios. Los sitios web, los foros y los blogs de las noticias
son algunas aplicaciones del ejemplo de este dominio.
La Figura 1A muestra un modelo de entidad para este dominio. Utilizando este modelo,
es Es posible, por ejemplo, configurar un producto seleccionando funciones opcionales
como bsqueda simple y sumisin de contenido de usuario (Figura 1B). Sin embargo,
las cuatro caractersticas de tecnologa de dominio en la parte inferior de la figura 1A
no pueden seleccionarse o deseleccionarse simplemente. En su lugar, deben
combinarse de forma creativa para configurar un producto (Figura 1C).

Aqu es donde un DSL viene en la mano. Es un lenguaje que describe los conceptos
de dominio y cmo se pueden relacionar entre s. Usando una DSL, se pueden crear
modelos que captan una variabilidad ms detallada. En el ejemplo anterior, un
diseador de dominio podra usar un DSL de creacin web para especificar Los tipos
de documentos estarn presentes en una aplicacin, y cmo se relacionan entre s, o
qu pginas estarn disponibles y cmo se produce la navegacin entre ellas. Dado
que un dominio suele comprender ambos tipos de variabilidad, , Se puede dividir en
subdominios [9], cada uno descrito en trminos de variabilidad basada en
caractersticas (configuracin de rutina) o variabilidad basada en DSL (construccin
creativa). Adems, estos diferentes subdominios deben cooperar efectivamente con el
fin de apoyar la variabilidad, es decir, los modelos de caractersticas individuales y las
DSL deben ser integrados [10, 11].

III. DISEO DE UNA ARQUITECTURA DE SOFTWARE ESPECFICA DE DOMINIO

PARA MDE:

El proceso de diseo de una arquitectura de software especfica de dominio suele

ser llevado a cabo por un arquitecto, junto con las partes interesadas, que pueden
identificar los principales atributos de calidad
Que son importantes para un dominio particular [2]. Estos son llamados drivers de
arquitectura - una combinacin de requisitos funcionales y de calidad que
"moldean" la arquitectura. A iden-
Los objetivos empresariales ms importantes deben ser analizados, y los que tienen
mayor impacto en la arquitectura deben ser elegidos como conductores [2]. Para
Ingeniera de Dominio Modelada, definimos tres
Tipos de conductores de arquitectura que deben ser identificados: (i) variabilidad
basada en caractersticas, (ii) variabilidad basada en DSL y (iii) integracin de
subdominio. En las siguientes secciones discutiremos algunas tcnicas para ayudar
a identificarlas. En las discusiones siguientes, suponemos que el anlisis de dominio
ya se ha realizado, por lo que un modelo de entidad est disponible en este
momento.

A. Identificacin de controladores de variabilidad basados en caractersticas:

La identificacin de caractersticas de dominio y el anlisis de variabilidad son

Normalmente realizado durante el anlisis de dominio [12], [13]. Por lo tanto, en este
punto el arquitecto de dominio ya tiene una buena idea acerca de las similitudes entre
las aplicaciones de dominio y cmo pueden diferir entre s. Pero para que el diseo
arquitectnico comience, se necesita informacin ms concreta. El arquitecto necesita
conocer detalles acerca de lo que sucede cuando una caracterstica particular est
presente o ausente, cuando se combinan dos caractersticas relacionadas, etc. Una
tcnica comn para esta tarea en particular es utilizar escenarios. Un escenario es una
breve descripcin del comportamiento que ilustra Ciertas condiciones como la
presencia de una caracterstica particular y sirve para probar la capacidad de una
arquitectura para satisfacer Uno o ms atributos de calidad [2]. Hay diferentes
maneras de mapear la variabilidad en el nivel de caractersticas en escenarios que
describen la variabilidad. Por ejemplo, pueden usarse casos de uso con relaciones de
inclusin y exclusin o etiquetas especiales que definen puntos de variacin [14]. Aqu
proponemos el uso de otro concepto para derivar estos escenarios, llamados casos de
cambio [15].
Un caso de cambio es un escenario que describe un punto de variacin
considerando la presencia de una o ms variantes. Por ejemplo, considere un
dominio que ofrezca opciones de bsqueda simples y avanzadas. La Figura 2A
describe el caso de uso para la bsqueda simple, y la Figura 2B describe la
bsqueda avanzada. Tenga en cuenta que,
En la Figura 2B, los pasos 2, 3 y 4 sustituyen el comportamiento "normal" cuando la
variante de bsqueda avanzada est presente. Las caractersticas relacionadas y
los escenarios afectados tambin se registran,
Para indicar dnde se producen los cambios.
Los casos de cambio tienen la ventaja de representar escenarios completos. Esto
facilita la evaluacin arquitectnica porque los interesados pueden comprender
plenamente cmo funciona un escenario sin tener que interpretar etiquetas
especficas o analizar combinaciones entre alternativas. Sin embargo, resultan en
descripciones ms largas y cierta duplicacin.
B. Identificacin de los factores de variabilidad basados en el DSL Algunos autores han
propuesto extensiones a la tcnica de modelado de caractersticas bsicas para este
propsito [4]. Sin embargo, incluso el modelo de funcin extendida tiene una notacin
fija y genrica. Esto puede no ser un problema al principio, durante el anlisis de
variabilidad, pero ms tarde en el proceso MDE esta notacin genrica es incapaz de
representar todas las complejidades y Detalles necesarios para la generacin del
cdigo [3]. El desarrollo del DSL es una tarea compleja y demorada [16], por lo que no
es viable construir un DSL completo Para fines de diseo arquitectnico. Sin embargo,
la estructura subyacente de un DSL - su sintaxis abstracta, o meta modelo [17] - se
puede utilizar para formalizar el espacio de variacin en determinadas reas del
dominio (subdominios). Puede introducir restricciones y reglas que van ms all de la
informacin contenida en el modelo de caractersticas, definiendo con mayor precisin
cmo varan las aplicaciones en estas reas, hasta un punto en el que el diseo puede
comenzar. Diferentemente de la variabilidad basada en caractersticas, los escenarios
no son tiles aqu, porque hay infinitas posibilidades de variacin. Por lo tanto,
proponemos la identificacin y el desarrollo del meta modelos DSL para ser utilizados
como conductores de la arquitectura. la identificacin de un meta modelo DSL se basa
principalmente en el modelo de caracterstica [6], pero el conocimiento del experto en
el dominio [3] tambin es importante. Tambin depende de la identificacin de los
subdominios, analizando por ejemplo las dependencias de las caractersticas [7] o su
potencial para la automatizacin impulsada por modelos1. Cada subdominio
corresponde a un subconjunto del dominio, y tiene su propio conjunto de
caractersticas.

En primer lugar, es necesario identificar las caractersticas que componen el meta

modelo del DSL. Proponemos que esta tarea debe comenzar por analizar las
caractersticas de la tecnologa de dominio [7]. Estas son las caractersticas que
representan formas especficas de dominio para implementar servicios u operaciones
en un dominio. En otra, Son los bloques de construccin del dominio sobre los que
normalmente se construyen las funciones y servicios de dominio (caractersticas de
capacidad). Estas caractersticas de tecnologa de dominio son buenas Candidatos a
formar parte de una DSL.

Considrese, por ejemplo, el dominio web mostrado en la Figura 1A. En este

dominio, se puede identificar el subdominio de creacin. Las entidades que
representan este subdominio (creacin, tipo de documento y relacin) sern el
punto de partida del meta modelo del DSL. Estas caractersticas se analizan
posteriormente para determinar cmo se relacionan entre s y si se necesitan
conceptos adicionales. Por ejemplo, el meta modelo que se muestra en la Figura 3
incluye, adems de Autora, Tipo de Documento y Relacin, obtenido directamente
del modelo de entidad, las relaciones entre ellos y nuevos conceptos, tales como
Autor, Campo y Tipo de Campo. Este meta modelo describe la esencia del DSL y la
variabilidad en ese subdominio particular.

C. Identificacin de los controladores de integracin de subdominio:

Una vez identificados los controladores que describen la variabilidad basada en caractersticas
y DSL, cada uno normalmente contenido en un subdominio bien definido, el arquitecto de
dominio debe tratar la integracin entre ellos. Por ejemplo, en el dominio web (Figura 1A), el
subdominio de navegacin puede contener referencias al subdominio de creacin (por ejemplo,
una pgina que seala un tipo de documento especfico). Estas interdependencias de
subdominio deben hacerse explcitas, de modo que la arquitectura pueda estar preparada para
la existencia de mltiples subdominios y posiblemente mltiples DSLs [10,11]. Por ejemplo,
puede ser necesario definir un solo metamodelo para mltiples subdominios, y
luego desarrollar diferentes sintaxis concretas para cada uno de ellos, de manera
que puedan integrarse bien pero an as tener diferentes puntos de vista.

Para realizar esta tarea, se inspecciona cada subdominio (modelos de

caractersticas y modelos DSL), buscando elementos (caractersticas o
metaelementos DSL) que dependen de un elemento en un subdominio diferente.
Los usos mltiples del mismo nombre, los sinnimos y los homnimos pueden
sealar stos hacia fuera. A continuacin, las dependencias deben documentarse
de forma clara, anotar los modelos de caractersticas y los modelos DSL o utilizar un
documento separado que enumere estas dependencias.

IV. PATRONES ARQUITECTNICOS PARA LA INGENIERA MODELO

Los controladores de arquitectura descritos en la Seccin III proporcionan informacin detallada

sobre cmo se produce la variacin en los diferentes subdominios. Con esta informacin en
mano, el arquitecto puede disear una arquitectura de software especfica de dominio que
proporcione el soporte necesario para MDE. El diseo arquitectnico es un proceso creativo
que Experiencia y conocimiento sobre el dominio. Esta tarea se lleva a cabo normalmente con
la ayuda de patrones para facilitar el diseo [2]. Depende del arquitecto decidir cmo combinar
Los patrones disponibles segn los conductores identificados, o incluso proponer nuevos
patrones para disear la arquitectura. Una lista de patrones bien conocidos est disponible en
la literatura [2], [18], pero normalmente no se ocupan de la variabilidad y los problemas
relacionados con el MDE. As, presentamos algunas Patrones para tratar con los controladores
identificados, destacando cmo se pueden integrar con artefactos MDE, en particular los
generadores de cdigo. Algunos de los patrones se basan en [19], Que son tiles para
proyectos MDE. Pero como estos no son especficos para el diseo arquitectnico o la
ingeniera del dominio, ofrecemos ms discusiones sobre estos aspectos. Aquellos patrones
que no aparecen en otros lugares (capa fina y capa de datos caractersticas - Seccin IV-B) se
observaron al menos en nuestros estudios de caso, pero somos conscientes de que se
necesita ms experiencia para Aumentar su generalidad.

A. Patrones de variabilidad basados en caractersticas En un trabajo anterior [20],

presentamos cmo algunos de los patrones GoF [21] pueden ayudar a hacer la
arquitectura lista
Para los diferentes tipos de variabilidad basada en caractersticas. Aqu, ampliamos
ese trabajo resaltando cmo MDE se integra con cada patrn y especificando qu
partes se pueden generar automticamente. El escenario es el siguiente: un modelo
de entidad describe las partes comunes y variables. Un generador de cdigo toma
como entrada una seleccin de caractersticas / sub-caractersticas que formarn
parte de la aplicacin generada y producir el cdigo correspondiente. Dependiendo
del tipo de caracterstica, se puede aplicar un patrn diferente.
Caractersticas alternativas. Estas son caractersticas en las que slo una
Alternativa de un grupo puede estar presente en una aplicacin.
Cuando una caracterstica se puede asignar directamente a una sola clase, sugerimos el uso
del patrn Prototype. Cada alternativa se implementa como una subclase diferente de un
prototipo comn. El generador de cdigo es responsable de generar el cdigo que instancia
slo la alternativa seleccionada. Si una caracterstica debe ser implementada por diferentes
clases, Sugieren el uso de los patrones Abstract Factory o Factory Method. Estos permiten, a
travs de la herencia de la fbrica, construir ms de una clase (ConcreteProduct) para la misma
caracterstica. Para automatizar este patrn, las caractersticas alternativas se implementan
como productos de hormign, y el generador es responsable de producir la fbrica de concreto
o mtodo de fbrica que corresponde a la alternativa seleccionada.

Cuando las alternativas son comportamientos diferentes que se pueden asignar a

un solo mtodo, se pueden utilizar los patrones de estrategia o modelo. Estos son
similares a prototipos, pero slo un mtodo es anulado. En este caso, el generador
debe producir el mtodo de llamadas para la alternativa seleccionada. O
caractersticas. Estas son caractersticas alternativas donde ms de una alternativa
de un grupo puede estar presente. Los patrones Decorador y Cadena de
Responsabilidad pueden ser usados cuando diferentes caractersticas tienen
funcionalidades que son complementarias entre s. El decorador es un patrn
estructural, ms indicado para los casos en los que la interaccin
Entre varias caractersticas es complejo, pero bien definido. La Cadena de
Responsabilidad es un patrn de comportamiento, es decir, la estructura de la
interaccin no est bien definida, y por lo tanto es ms indicado para interacciones
de caractersticas ms simples. En ambos casos, el comportamiento se encapsula
en mtodos especficos, clases o el patrn de comandos, y el generador es
responsable de producir las llamadas de mtodo que corresponden a la seleccin
caractersticas. Caractersticas opcionales. Para las funciones opcionales, se puede
utilizar el mismo conjunto de patrones utilizados para las caractersticas O, con la
diferencia de que en este caso no es necesario garantizar
Que al menos una caracterstica est presente en la aplicacin. La figura 4 muestra
un ejemplo de aplicacin del resumen
Patrn de diseo de fbrica que se utiliza para las caractersticas alternativas.
En este ejemplo, hay dos caractersticas alternativas, cada una para un sistema de
gestin de bases de datos diferente: Apache Derby y MySQL2. Dependiendo de la
funcin elegida, se genera un conjunto diferente de clases.

El siguiente listado muestra una pieza de cdigo JET3 que genera una clase
DAOAbstractFactory.
Este cdigo utiliza etiquetas jet <c:iterate> y <c:get>, Junto con las consultas XPATH
[22], para iterar a travs de todos los tipos de documentos y generar un mtodo creador para
cada tipo de documento.
public abstract class DAOAbstractFactory {
<c:iterate select="/documentTypes" var="d">
public abstract
<c:get select="$d/@name" />
create<c:get select="$d/@name" />Instance();
</c:iterate>
}
Para los tipos de documento "Noticias", "Proyecto" y "Referencia", se genera la clase
en la esquina superior izquierda de la Figura 4. Para ilustrar cmo este patrn
facilita la tarea del generador de cdigo, considere la siguiente pieza de cdigo JET:

<c:iterate select="/documentTypes" var="d">

<c:choose>
<c:when test="$featuresModel/@derby=true">
<java:class name="{$d/@name}"
template="DerbyDAOClass.java.jet" />
</c:when>
<c:when test="$featuresModel/@mysql=true">
<java:class name="{$d/@name}"
template="MySQLDAOClass.java.jet" />
</c:when>
</c:choose>
</c:iterate>

Aqu, las etiquetas JET <c: choose> y <c: when> se utilizan para seleccionar entre
alternativas mutuamente exclusivas, en este caso, las caractersticas alternativas
"derby" y "mysql", que se obtienen del modelo de caractersticas mediante
consultas XPATH. Dependiendo de la eleccin, la etiqueta JET <java: class> llama a
la plantilla apropiada. Para los tipos de documentos "Noticias", "Proyecto" y
"Referencia", tres de las seis clases concretas en la parte inferior
Lado derecho de la Figura 4. Una construccin similar produce la fbrica de
hormign (DerbyDAOFactory o
MySQLDAOFactory) para la funcin seleccionada. Tambin hay dos patrones que se
pueden utilizar para la variabilidad basada en caractersticas, sobre la base de
buenas prcticas bien conocidas [23] para escribir generadores de cdigo:

El primer patrn (Figura 5) se conoce como el enfoque de visitante [23]. En este

patrn, el modelo de entrada es atravesado y cada elemento es visitado. Para cada
elemento, se llama una plantilla correspondiente, segn el tipo del elemento del
modelo. En el escenario de ingeniera de dominio, puede ser particularmente til
para diferentes tipos de obligatorios y caractersticas opcionales [7].
Un visitante recorre el modelo de caractersticas y, para cada funcin seleccionada,
llama a la plantilla correspondiente. Normalmente, cada plantilla produce una nica
clase que se ajusta a la arquitectura a travs de patrones de diseo como los
anteriores.
El enfoque de visitante es una buena opcin cuando es posible encapsular la
funcionalidad de una caracterstica en una sola clase. Si no, un segundo patrn
puede ser utilizado, conocido como el enfoque de plantilla [23]. Consiste en un solo
punto de entrada, responsable de consultar los modelos y llamar a otras plantillas.
Esta
Puede utilizarse en diferentes tipos de variabilidad, ya que es ms flexible, siendo
particularmente til para
Implementar o caractersticas [7]: una plantilla principal analiza los modelos de
caractersticas y decide las plantillas a llamar basadas en las caractersticas
seleccionadas.

B. Patrones de variabilidad basados en DSL:

Los patrones de esta categora se centran en cmo las herramientas basadas en DSL y los
generadores de cdigo pueden integrarse con los otros artefactos de dominio. Una
particularidad de estos patrones es que, despus de que el proceso MDE se finaliza y se
produce la generacin de cdigo, los patrones "desaparecen" de la arquitectura del producto
final. Esto sucede porque pertenecen a un meta-nivel diferente. Sin embargo, ellos Tienen
impacto en el xito del dominio, ayudando a dar forma a una arquitectura que est mejor
preparada para tareas como modelado de dominios y generacin de cdigo. Un primer patrn
que proponemos se llama capa de datos delgada, lo que facilita la integracin entre el
generador y la herramienta / modelador DSL. Normalmente, los generadores de cdigo leen
informacin directamente desde una herramienta DSL, que se puede crear manualmente o con
un workbench de lenguaje como GME o el proyecto de modelado de Eclipse.

Este patrn, mostrado en la Figura 6, aboga por el uso de una capa de datos
independiente, construida en una tecnologa que es independiente de la
herramienta DSL, y que contiene la informacin que es esencial para el generador,
y nada ms. De esta manera, se hace explcita la informacin que necesita el
generador, lo que facilita la evolucin tanto del generador como de la herramienta
DSL. Tambin permite el desarrollo de ambos lados en paralelo (un equipo que
desarrolla el generador y otro
Equipo que desarrolla las herramientas / metamodelos). Finalmente, libera
El generador de una tecnologa de modelado particular, y restringe la necesidad de
aprender las particularidades de una herramienta de modelado especfica a un solo
equipo. El equipo que trabaja con la generacin de cdigo puede centrarse en sus
propias tareas.

Un segundo patrn es la capa de datos de caractersticas. Normalmente, el modelo

de caractersticas es un punto central de informacin para los generadores, incluso
aquellos que se dedican exclusivamente a la base DSL
variabilidad. Este patrn propone que una capa de datos comn contiene toda la
informacin relacionada con las caractersticas. Esta capa de datos debe estar
diseada para ser accesada por cualquier generador, lo que le permite consultar la
informacin de la caracterstica mientras genera cdigo. Si existe una herramienta
para el modelado de entidades, se puede utilizar una capa de datos delgada
separada para contener datos de caractersticas sin depender de esa herramienta
en particular. La segunda muestra de cdigo en la Seccin IV-A ilustra el patrn de
capa de datos de caractersticas.
En lugar de leer directamente desde el modelo de entidad, las consultas XPATH
$featuresModel/@derby=true y $featuresModel/@mysql=true Acceder a una
capa de datos separada, almacenada en una ranura temporal representada por
$featuresModel.

Esta ranura temporal contiene slo la informacin necesaria del modelo de caractersticas que
es realmente utilizado por los generadores de cdigo. El cdigo siguiente muestra la idea
general de cmo se puede rellenar esta capa utilizando JET jags <c: load> y <c: set>. En este
ejemplo, se selecciona la funcin "derby":

<%-- load from product configurator tool --%>

<c:load url="features.xmi" var="conf"/>
<%-- inspect conf to see which features
are selected. and set necessary
variables --%>
<c:set select="$featuresModel"
name="derby">true</c:set>
<c:set select="$featuresModel"
name="mysql">false</c:set>

C. Patrones de integracin de subdominios:

Estos patrones tienen como objetivo proporcionar una buena integracin entre
software generado y no generado, particularmente en aquellas reas que implican
los lmites de un subdominio. Los patrones de esta seccin se dividen en cuatro
categoras, de acuerdo con la dependencia entre cdigo generado y no generado:
El cdigo generado depende del cdigo no generado. Este es el tipo ms simple de
interaccin, y consiste en hacer que el generador produzca cdigo que utilice
fuentes existentes, no generadas Cdigo, como un marco o una API.
El patrn de Fachada [21] se puede utilizar para simplificar la interaccin entre
cdigo generado y no generado. En lugar de generar cdigo que utiliza mltiples
clases y mtodos, una nica clase de Fachada puede agrupar todas las
Clases y mtodos. Esto no slo hace que las dependencias sean ms explcitas, sino
que tambin puede proporcionar cierta proteccin contra los cambios en el cdigo
no generado.

Dependiendo de cun profundo sea el cambio, puede que no sea necesario cambiar el
generador, que es una tarea ms compleja y propensa a errores. Para proteger al generador de
modificaciones en el cdigo no generado, se puede usar el patrn del adaptador [21] para
recopilar, filtrar y / o preparar la informacin necesaria para el cdigo generado. El patrn de
puente [21] se puede utilizar con el mismo propsito, creando una representacin abstracta del
cdigo referenciado, que es libre de ser modificado para introducir Modificaciones ms
sencillas. Las clases parciales son otra manera de lograr esto, como muestra el siguiente
cdigo:
// This file is generated
public partial class ClientNodeObject
{
public ClientNodeObject(int port) {
// generated init code
_initData();
}
}
// This file is handwritten
public partial class ClientNodeObject
{
void _initData() {
// handwritten code
}
}
En este ejemplo, escrito en C #, el compilador es responsable de integrar los dos archivos en
una sola clase. El cdigo no generado depende del cdigo generado. Esto sucede cuando
algn cdigo no generado espera que se genere algn comportamiento o estructura. En la
mayora de los casos, los patrones Tales como la fbrica abstracta, el mtodo de la plantilla o la
fbrica [21] se puede utilizar, de modo que el cdigo no-generado no necesita saber los detalles
sobre cmo las clases o los mtodos que utiliza son Realmente implementado. El siguiente
cdigo Java no generado ilustra cmo se reduce la dependencia a travs del patrn de fbrica
abstracto. En este ejemplo, este cdigo Java no generado depende de Se selecciona la funcin
"derby", pero no hay necesidad de mucho detalle, ya que el patrn abstracto de fbrica lo
oculta la mayor parte:

public class DefaultDAOFactoryProvider {

private static DAOAbstractFactory
theInstance = null;
public static DAOAbstractFactory
getDefaultDAOFactoryInstance() {
if(theInstance == null)
theInstance = new DerbyDAOFactory();
return theInstance;
}
}.
El cdigo generado depende del cdigo generado. Esto suele suceder cuando hay dos
subdominios que dependen unos de otros. Un problema que surge cuando varios subdominios
estn relacionados es cmo asegurar esta relacin entre ellos. Una posibilidad es utilizar los
nombres de los elementos como referencias, es decir, el nombre de una referencia en un
modelo debe coincidir con el nombre del elemento referenciado en otro modelo. Aunque no es
ideal, esto simplifica el proceso de Implementando referencias cruzadas [11].

Otra opcin son los puentes de modelo, que consisten en crear duplicados de elementos del
metamodelo referenciado en el metamodelo de referencia. En el ejemplo de creacin web, esto
corresponde a la creacin, en el metamodelo de navegacin, de un elemento denominado
ReferenceToDocumentType, O algo similar, que puede ser utilizado para establecer referencias
entre metamodelos. Un inspector independiente puede asegurarse de que estas referencias
son vlidas [10].
V. EVALUATION:

Para evaluar nuestro enfoque, llevamos a cabo tres estudios de casos, que se
describen en la Tabla I. El primer estudio involucr el dominio de creacin de
contenido web, que es un dominio tcnico
Que incluye aplicaciones para publicar y ver informacin, como sitios web de
noticias, foros y blogs. Se realiz en un escenario puramente acadmico. Los
estudios segundo y tercero se realizaron conjuntamente con la industria. El segundo
estudio involucr el dominio de las aplicaciones distribuidas basadas en la nube,
que es tambin un dominio tcnico, que se ocupa principalmente de las funciones
de comunicacin punto a punto y descubrimiento. El tercer estudio de caso
involucr el dominio de los eventos cientficos, que es un dominio empresarial.
Los tres estudios de casos tomaron una cantidad similar de tiempo, aunque el tercer
estudio tuvo una duracin ms pequea y slo a tiempo parcial la disponibilidad de
los participantes. El tercer estudio de caso fue el ms grande en trminos de lneas
de cdigo de la referencia Implementacin, pero menor en trminos de generacin
Artefactos, lo que refleja el hecho de que los participantes tenan menos
Tiempo para implementar la automatizacin MDE.
El objetivo de estos estudios fue evaluar si los impulsores y patrones propuestos
pueden ayudar a producir una arquitectura que sea ms adecuada para MDE, por lo
que la idea era hacer una comparacin entre las implementaciones existentes,
desarrolladas sin ellas, y la implementacin MDE resultante , Desarrollado con ellos.
Para todos los estudios, los mismos participantes
Fueron responsables de desarrollar las dos versiones (con y sin nuestro enfoque).