IV Simpsio Brasileiro de Componentes, Arquiteturas e Reutilizao de software
El diseo de arquitecturas de dominio de Ingeniera Dirigida por Modelos
Daniel Lucr' edio *, Renata PM Fortes , Eduardo S. Almeida y Silvio L. Meira
* Departamento de Informtica - Universidad Federal de S~
Instituto de Ciencias Matemticas y Computacin - Universidad de S~
Departamento de Ciencias de Computacin - Universidad Federal de Baha, Salvador - BA - Brasil
Centro de Recife de Estudios Avanzados y Sistemas - Recife, PE, Brasil
Autor correspondiente: daniel@dc.ufscar.br
Abstracto -Modelo-Driven Ingeniera (MDE) puede aprovechar
la ingeniera de dominio, ofreciendo apoyo a la variabilidad compleja e implementacin
automtica. Sin embargo, se presta poca atencin al proceso de diseo de una arquitectura
de dominio que se adapta bien a las tcnicas de MDE, como los idiomas fi cas de
dominio-especfico y transformaciones de software. Una arquitectura de software fi
co-dominio especfico se desarrolla normalmente en base a unos requisitos cionado e
importantes Se-, llamado conductores arquitectnicos. Este artculo presenta tres tipos de
controladores arquitectnicos que se pueden utilizar para construir una arquitectura de
software que se puede sacar el mximo provecho de los beneficios de MDE. Tambin se
presentan algunos patrones que se pueden utilizar para ayudar en el diseo arquitectnico.
Tambin se presenta una evaluacin, lo que demuestra que, cuando se usan juntos en un
proyecto de ingeniera de dominio basado en modelos, estos controladores y los patrones se
pueden llevar a algunos beneficios en trminos de capacidad de reutilizacin y complejidad,
pero que en algunos casos hay inconvenientes que deben tenerse en cuenta en un anlisis
de compensaciones.
Palabras Clave: modelo impulsado por ingeniera; ingeniera de dominio; los conductores de
arquitectura; patrones; idiomas fi dominio C-especfico; codigo de GENERACION;
I. INTRODUCCIN
Una de las principales tareas de ingeniera de dominio es de definir una
arquitectura de software fi co-dominio especfico que se apoya en comn y la
variabilidad [1]. La arquitectura no slo debe predecir los puntos de variacin, sino que
tambin proporcionan de manera efectiva el apoyo necesario, normalmente en forma
de compo- nentes reutilizables [2]. Ingeniera Dirigida por Modelos (MDE) se puede
extender este proceso con lenguajes fi cas de dominio-especfico y las
transformaciones que proporcionan apoyo a la variabilidad ms complejo e
implementacin automatizada.
Para que este escenario dominio de la ingeniera dirigida por modelos (MDDE) es
posible, la arquitectura de software debe ser construida alrededor del concepto de
MDE, siendo conscientes y dar apoyo a sus tecnologas, por lo que el proceso de
desarrollo de la aplicacin se puede sacar el mximo provecho de sus beneficios.
Sin embargo, la mayora de los enfoques basados en modelos para la ingeniera de
dominio y la lnea de productos enfoque de ingeniera en la tarea derivacin producto,
despus de la arquitectura ya se define (dos ejemplos son [3], [4]). En general, no se
presta suficiente atencin al proceso de disear una arquitectura que es muy adecuado
para MDE. Tratamos de abordar este problema de dos maneras: (i) mediante la
identificacin de tres tipos de MDE-espec fi cos de los conductores arquitectnicos [2]; y
(ii) mediante la presentacin de algunos patrones
105
ao Carlos, S~ ao Carlos - SP - Brasil
ao Paulo, S~ ao Carlos - SP - Brasil
para tratar con ellos. Cuando se usan juntos, facilitan la tarea de disear
arquitecturas de MDE. Los controladores guan el arquitecto dominio a travs de la
identificacin de las diferentes posibilidades de variabilidad de dominio, mientras que
los patrones ayudan proporcionando soluciones a algunos de los problemas
implicados en el diseo de dominio basado en modelos.
Tambin se presentan los resultados de una evaluacin llevada a cabo para demostrar la
viabilidad, los beneficios y las desventajas de la utilizacin de estos controladores y los
patrones.
II. re Omain V Y ARIABILITY METRO ODEL- re HENDIDO
mi NGENIERA
La variabilidad es el concepto clave detrs de una arquitectura de dominio exitosa [1].
Hay dos tipos de dominio de la variabilidad [6]: rutinaria con fi guracin - un subconjunto de
caractersticas se selecciona para con fi gura un producto, el uso de estructuras en forma
de rbol; y cre- ativa de construccin - modelos describen la variacin a travs de
estructuras de grfico similar.
La mayora de los enfoques de diseo de dominio se basan en la identificacin
de la variabilidad como se describe en trminos de caractersticas [7] -
caractersticas observables externamente de un producto. ING funcin modelo- se
encuentra en algn lugar entre la rutina con fi guracin y la construccin creativa [6],
y ya ha sido utilizado con xito en muchos casos. Sin embargo, hay otros tipos de
variacin, como en los modelos entidad [8], que son ms complejas de lo que es
posible capturar en modelos de caractersticas, ya que son demasiado genricos [3].
Esto requiere un mecanismo ms rico, con potencia ms expresiva para capturar las
relaciones detalladas y limitaciones entre las entidades. La tecnologa de eleccin
para este es normalmente un fi c idioma del dominio-Speci (DSL) [3], [6]. Junto con
las transformaciones de modelos y generadores de cdigo, DSL forman la base de
la Ingeniera Dirigida por Modelos (MDE).
Por ejemplo, considere un dominio de creacin de pginas web con aplicaciones de
publicacin-navegar. Un administrador publica informacin, como noticias, mensajes,
mensajes, etc., que pueden acceder los usuarios. sitios web de noticias, foros y blogs son
algunos ejemplos de aplicacin de este dominio. La figura 1A muestra un modelo de
caractersticas para este dominio. Usando este modelo, es posible, por ejemplo, para con
fi gura un producto mediante la seleccin de caractersticas opcionales como bsqueda
simple y el contenido del usuario sumisin (Figura 1B). Pero las cuatro caractersticas de
la tecnologa de dominio en la parte inferior de la figura 1A no se pueden simplemente
seleccionar o
 IV Simpsio Brasileiro de Componentes, Arquiteturas e Reutilizao de software

Figura caractersticas de dominio de autora 1. Web y las diferentes posibilidades con fi guracin producto. Desarrollado con ToolDAy [5].

sin seleccionar. En lugar de ello, tienen que ser combinadas de una manera creativa para con A. fi cacin de los conductores de variabilidad basados en caractersticas

fi gura un producto (Figura 1C).

Aqu es donde entra una conexin DSL en la mano. Es un lenguaje que describe
los conceptos de dominio y cmo pueden relacionarse entre s. El uso de un DSL, uno
puede crear modelos que capturan la variabilidad ms detallado. En el ejemplo
anterior, un diseador de dominio podra utilizar una conexin DSL creacin de
pginas web para especificar qu 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 ellos.
Desde un dominio comprende normalmente ambos tipos de variabilidad, que se
puede dividir en subdominios [9], cada uno descrito en trminos de variabilidad basada
en la caracterstica (con rutina fi guracin) o la variabilidad basada en DSL
(construccin creativa). Adems, estos diferentes subdominios deben cooperar
eficazmente con el fin de apoyar la variabilidad, es decir, los modelos de caractersticas
individuales y DSL deben integrarse [10], [11].
III. re Un ESIGNING re OMAIN- S ESPECFICOS S OFTWARE
UN RCHITECTURE PARA MDE
El proceso de disear un software fi c dominio espec Ar- quitectura se lleva a
cabo habitualmente por un arquitecto, junto con el las partes interesadas, que puede
identificar los principales atributos de calidad que son importantes para un dominio
particular [2]. Estos se llaman conductores arquitectnicas - una combinacin de
requisitos funcionales y de calidad que forma de la arquitectura. Para identi- ficar
ellos, se deben analizar los objetivos de negocio ms importantes, y los que tienen
mayor impacto en la arquitectura deben ser elegidos como conductores [2].
Dominio dispone identificacin y anlisis de la variabilidad se realiza normalmente
durante el anlisis de dominio [12], [13]. Por lo tanto, en este punto el arquitecto
dominio ya tiene una buena idea acerca de las similitudes entre las aplicaciones de
dominio y la forma en que pueden ser diferentes unos de otros.
Sin embargo, para el diseo arquitectnico para empezar, se necesita informacin
ms concreta. El arquitecto debe 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 el
uso de escenarios. Un escenario es una breve descripcin de comportamiento que ilustra
ciertas condiciones - como la presencia de una caracterstica particular
- y sirve para poner a prueba la capacidad de una arquitectura en atributos satisfacer
una o ms de calidad [2].
Hay diferentes formas de asignar la variabilidad en el nivel de caractersticas en
escenarios que describen la variabilidad. Por ejemplo, casos de uso con inclusin y
exclusin PARENTESCO buques o etiquetas especiales que puntos de variacin de
fi ne se pueden utilizar [14]. Aqu proponemos el uso de otro concepto para derivar
estos escenarios, llamados casos de cambio [15].
Un caso el cambio es un escenario que describe un punto de variacin teniendo en
cuenta la presencia de una o ms variantes. Por ejemplo, considere un dominio con
simples y avanzadas opciones de bsqueda. 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 sustituto 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.

De Ingeniera de Dominio Model-Driven, que de fi ne tres tipos de controladores

arquitectnicos que deben ser identi fi cada: ( i) la variabilidad basado en funciones, (Ii)
la variabilidad basada en DSL y ( iii) la integracin subdominio. En las siguientes
secciones se discuten algunas tcnicas para ayudar a identificarlos. En las siguientes
discusiones, se supone que el anlisis de dominio ya se ha llevado a cabo, por lo que
un modelo de funcin est disponible en este momento.
Cambiar los casos tienen la ventaja de representar escenarios completos. Esto
facilita la evaluacin arquitectnica, debido a que las partes interesadas pueden
entender completamente cmo funciona un escenario sin tener que interpretar las
etiquetas mercantiles o analizar las combinaciones entre alternativas. Sin embargo, dan
lugar a descripciones ms largas y algunas duplicaciones.

106
 IV Simpsio Brasileiro de Componentes, Arquiteturas e Reutilizao de software

Figura 2. Ejemplo de un caso cambio la introduccin de la variante de bsqueda avanzada

B. La identificacin de los conductores de variabilidad basados en DSL Consideremos por ejemplo el dominio de web se muestra en la Figura 1A.
En este dominio, el subdominio de creacin puede ser iden- ti fi ed. Las
Algunos autores han propuesto extensiones a la tcnica bsica de modelado
caractersticas que representan este subdominio ( Autora, DocumentType y Relacin)
caracterstica para este fin [4]. Sin embargo, incluso el modelo de caractersticas
ser el punto de partida del metamodelo del DSL. Estas caractersticas son
extendidas tiene una notacin fijada cin, genrico. Esto puede no ser un problema en
luego analizados para determinar la forma en que se relacionan entre s y si se
el principio, durante el anlisis de variabilidad, pero ms tarde en el proceso MDE esta
necesitan conceptos adicionales. Por ejemplo, el modelo de meta- muestra en
notacin genrica no es capaz de representar todas las complejidades y detalles
la figura 3 incluye, adems de Autora, DocumentType y Relacin, obtenida
necesarios para la generacin de cdigo [3].
directamente del modelo de caractersticas, las relaciones entre ellos, y los
nuevos conceptos, tales como una Autor, Campo y Tipo de campo. Este modelo
desarrollo DSL es un complejo, tarea que consume tiempo [16], por lo que no es
describe la esencia meta del DSL y la variabilidad en ese subdominio en
viable construir un DSL completa slo para propsitos de diseo arquitectnico. Sin
particular.
embargo, la estructura de un DSL subyacente - su sintaxis abstracta, o metamodelo
[17] - se pueden utilizar para formalizar el espacio variacin en determinadas zonas
del dominio (subdominios). Se puede introducir limitaciones y reglas que van ms all
de la informacin contenida en el modelo de funcin, de fi nir con mayor precisin C. La identificacin de los conductores de integracin subdominio
cmo las aplicaciones varan en estas zonas, hasta un punto en el que el diseo
Tener identi fi aquellos conductores que describen la variabilidad basada en
puede comenzar. A diferencia de la variabilidad basado en funciones, los escenarios
DSL basado en funciones y, cada uno normalmente contenida en un subdominio
no son tiles aqu, porque no estn en posibilidades de variacin finitas.
fi bien de nido, el arquitecto dominio tiene que hacer frente a la integracin entre
ellos. Por ejemplo, en el dominio de web (Figura 1A) el subdominio de
navegacin puede contener referencias al subdominio de creacin (por ejemplo,
Por lo tanto, se propone la identificacin y desarrollo de metamodelos DSL para ser
una pgina que apunta a un tipo de documento fi ca). Estas interdependencias
utilizados como conductores de arquitectura. La identificacin del metamodelo del DSL
subdominio se deben hacer explcita, de modo que la arquitectura se puede
se basa principalmente en el modelo de funcin [6], pero el conocimiento del dominio
preparar para la existencia de varios subdominios y posiblemente mltiples DSL
del experto [3] Tambin es importante. Tambin depende de la identificacin de los
[10], [11]. Puede ser que sea necesario, por ejemplo, para definir un nico
subdominios, mediante el anlisis de por ejemplo la caracterstica de depen- dencias [7]
metamodelo para varios subdominios, y luego desarrollar concreta diferente
o su potencial para la automatizacin basada en modelos 1.

Cada subdominio corresponde a un subconjunto del dominio, y tiene su propio conjunto de

caractersticas.

En primer lugar, es necesario identificar las caractersticas que com- plantean

metamodelo del DSL. Proponemos que esta tarea debe comenzar por el anlisis de la caractersticas

de la tecnologa de dominio [ 7]. Estas son las caractersticas que representan formas fi cas

de dominio-especfico para implementar servicios u operaciones en un dominio. En otras

palabras, son bloques de construccin del dominio sobre el cual las funciones y servicios

(caractersticas de capacidad de dominio) se construyen normalmente. Estas caractersticas

de la tecnologa de dominio son buenos candidatos a formar parte de una conexin DSL.

1 Subdominios identi fi cacin est fuera del alcance de este documento. Otras lecturas en [9]
Figura 3. De definicin del metamodelo de autora de subdominio.

107
 IV Simpsio Brasileiro de Componentes, Arquiteturas e Reutilizao de software
sintaxis para cada uno de ellos, para que puedan integrar bien, pero todava tienen
diferentes puntos de vista.
Para lograr esta tarea, se inspecciona cada subdominio (modelos de caractersticas y
modelos DSL), en busca de elementos (caractersticas o metaelements DSL) que
dependen de un elemento en un subdominio dife- rentes. Mltiples usos del mismo
nombre, sinnimos y homnimos pueden destacar este hecho. A continuacin, las
dependencias deben estar documentados de forma clara, la anotacin de los modelos de
caractersticas y los modelos de DSL, o el uso de un documento separado que se
enumeran estas dependencias.
IV. UN RCHITECTURAL PAG ATTERNS PARA METRO ODEL- re HENDIDO
mi NGENIERA
Los controladores arquitectnicos descritos en la Seccin III proporcionan
informacin detallada acerca de cmo se produce la variacin en los diferentes
subdominios. Con esta informacin en mano, el arquitecto puede disear una
arquitectura de software fi co-dominio especfico que proporciona el apoyo necesario
para el MDE.
El diseo arquitectnico es un proceso creativo, que requiere experiencia y
conocimiento sobre el dominio. Esta tarea se lleva a cabo normalmente con la
ayuda de patrones para facilitar el diseo [2]. Corresponde al arquitecto para
decidir cmo combinar los patrones disponibles de acuerdo a los conductores identi
fi cados, o incluso proponer nuevos patrones para disear la arquitectura.
Una lista de los patrones conocidos est disponible en la literatura [2], [18], pero
normalmente no se ocupan de la variabilidad y las cuestiones relacionadas con el MDE.
Por lo tanto, presentamos algunos patrones arquitectnicos para hacer frente a los
conductores identi fi cados, destacando la forma en que 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. Sin embargo, ya que estos no son especfico para el
diseo arquitectnico o de ingeniera de dominio, proporcionamos nuevos debates sobre
estos aspectos. No se observaron al menos en nuestros estudios de casos, pero son
conscientes de que se necesita ms experiencia para aumentar su generalidad - aquellos
patrones que no aparecen en otros lugares (Seccin IV-B de capa delgada y cuenta con
capa de datos).
A. patrones de variabilidad basado en funciones
En un trabajo previo [20], presentamos cmo algunos de los patrones GoF [21]
puede ayudar a hacer la arquitectura listo para los diferentes tipos de variabilidad
basado en funciones. A continuacin, extendemos ese trabajo, poniendo de relieve
cmo MDE se integra con cada patrn y especificar qu partes se pueden generar
de forma automtica. El escenario es el siguiente: un modelo de caractersticas se
describen las partes comunes y variables. Un generador de cdigo toma como
entrada una seleccin de caractersticas / sub-caractersticas que sern parte de la
solicitud generada, y produce el cdigo correspondiente. Dependiendo del tipo de
funcin, un patrn diferente se puede aplicar.
caractersticas alternativas. Estas son caractersticas que slo una alternativa de
un grupo puede estar presente en una aplicacin. Cuando una caracterstica se
puede asignar directamente a una sola clase, se sugiere el uso de la Prototipo patrn.
cada alternativa
108
se implementa como una subclase diferente de un prototipo comn. El generador de
cdigo es responsable de generar cdigo que crea una instancia nica de la
alternativa seleccionada.
Si una caracterstica tiene que ser implementado por diferentes clases, se sugiere el
uso de la Resumen de fbrica o Mtodo de fbrica
patrones. Estos permiten, a travs de la herencia de la fbrica, para construir ms
de una clase ( ConcreteProduct) para la misma funcin. Para automatizar este
patrn, las caractersticas alternativas que se implementan como productos de
hormign, y el generador es responsable de producir el mtodo de fbrica o
planta de hormign que corresponde a la alternativa seleccionada.
Cuando las alternativas son diferentes comportamientos que se pueden asignar
a un solo mtodo, el Estrategia o Mtodo plantilla
patrones pueden ser utilizados. Estos son similares al prototipo, pero slo se redefine
un mtodo. En este caso, el generador debe producir las llamadas a mtodos para la
alternativa seleccionada.
O caractersticas. Estas son caractersticas alternativas donde ms de una
alternativa de un grupo pueden estar presentes. los
Decorador y Cadena de Responsabilidad patrones pueden ser utilizados cuando
diferentes caractersticas tienen funcionalidades que son complementarias entre
s. los Decorador es un patrn estructural, ms indicado para los casos en los que
la interaccin entre varias caractersticas es complejo, pero bien de fi nido. los
Cadena de Responsabilidad es un patrn de comportamiento, es decir, la estructura de
la interaccin no es bien definido, y por lo tanto es ms indicado para simples
interacciones entre caractersticas. En ambos casos, el comportamiento se encapsula
en espec mtodos fi c, clases, o la Mando patrn, y el generador es responsable de
producir las llamadas a mtodos que se corresponden con las caractersticas
seleccionadas.
Caractersticas opcionales. Por las caractersticas opcionales, el mismo conjunto de
patrones utilizado para el o caractersticas se puede utilizar, con la diferencia de que en
este caso no es necesario para garantizar que al menos una caracterstica est presente en
la aplicacin.
La Figura 4 muestra un ejemplo de aplicacin del patrn de diseo de fbrica
abstracta se utiliza para caractersticas alternativas.
Figura 4. Ejemplo de fbrica abstracta se utiliza para caractersticas alternativas.
En este ejemplo, hay dos caractersticas alternativas, cada uno para un
sistema de gestin de base de datos diferente: Apache
 IV Simpsio Brasileiro de Componentes, Arquiteturas e Reutilizao de software

Derby y MySQL 2. Dependiendo de qu caracterstica es selec- cionado, se genera proach [23]. En este modelo, el modelo de entrada es atravesada y cada elemento es
un conjunto diferente de clases. visitado. Para cada elemento, una plantilla correspondiente se llama, de acuerdo con
El siguiente listado muestra una pieza de JET 3 cdigo que genera la clase DAOAbstractFactory.
el tipo del elemento del modelo. En el escenario de la ingeniera de dominio, que
Este cdigo utiliza etiquetas JET < c: Iterar> y < c: obtener>, junto con XPATH puede ser particularmente til para diferentes tipos de caractersticas obligatorias y
[22] consultas, para iterar a travs de todos los tipos de documentos y opcionales [7]. Un visitante atraviesa el modelo de caractersticas y, para cada funcin
generan un mtodo creador para cada tipo de documento. seleccionada, llama a la plantilla correspondiente. Normalmente, cada plantilla
produce un solo tting clase fi en la arquitectura a travs de los patrones de diseo

DAOAbstractFactory clase abstracta pblica {<c: iterar select = "/ DocumentTypes"

como el anterior.
var = "d"> public abstract

El enfoque de visitantes es una buena opcin cuando es posible encapsular la

<C: obtener seleccione = "$ d / @ nombre" />
funcionalidad de una caracterstica en una sola clase. Si no, un segundo patrn se
crear <c: obtener seleccione = "$ d / @ nombre" /> Instancia (); </ C: iterar>}
puede utilizar, conocido como el modelo
enfoque [23]. Se compone de un nico punto de entrada, responsable de la consulta
de los modelos y llamar a otras plantillas. Este enfoque puede ser utilizado en
Para los tipos de documentos Noticias, Proyecto y referencia, se genera la
diferentes tipos de variabilidad, ya que es ms flexible, siendo particularmente til
clase en la esquina superior izquierda de la figura 4.
para poner en prctica o caractersticas [ 7]: una plantilla principal analiza los
Para ilustrar cmo este patrn facilita la tarea del generador de cdigo,
modelos de caractersticas y decide qu plantillas a la llamada en base a las
considere el siguiente fragmento de cdigo JET:
caractersticas seleccionadas.
<C: iterar select = "/ DocumentTypes" var = "d"> <c: choose>

<C: cuando la prueba = "$ featuresModel / @ derby = 'verdadero'"> <java: class

B. patrones de variabilidad basados en DSL
name = "{$ d / @ nombre}"
template = "DerbyDAOClass.java.jet" />
Los patrones de esta categora se centraron en cmo las herramientas basadas
</ C: when>
<C: cuando la prueba = "$ featuresModel / @ mysql = 'verdadero'"> <java: class
en DSL y generadores de cdigo se pueden integrar con los otros artefactos de
name = "{$ d / @ nombre}" dominio. Una particularidad de estos patrones es que, despus del proceso MDE
template = "MySQLDAOClass.java.jet" />
est fi nalizado y la generacin de cdigo se lleva a cabo, los patrones de
</ C: when> </ c:
choose> </ c: iterar>
desaparecer de la arquitectura del producto final. Esto sucede debido a que
pertenecen a un meta-nivel diferente. Sin embargo, s tienen impacto en el xito de
dominio, lo que ayuda a dar forma a una arquitectura que est mejor preparado
Aqu, las etiquetas <JET c: choose> y < c: when> se utilizan para seleccionar
para tareas como el modelado fi co y generacin de cdigo especfico dominio-.
entre las alternativas que se excluyen mutuamente, en este caso, caractersticas
alternativas derby y MySQL, que se obtienen a partir del modelo caractersticas
a travs de consultas XPath. Dependiendo de la eleccin, etiqueta JET < Java:
Un patrn primero que proponemos se denomina capa de datos delgada, lo que facilita
clase> llama a la plantilla piado appro-. Para los tipos de documentos Noticias,
la integracin entre el generador y la herramienta DSL / modelador. Normalmente, los
Proyecto y referencia, tres de las seis clases de hormign en la parte inferior
generadores de cdigo leen la informacin directamente de una herramienta DSL, que se
derecha de la figura 4 se generan. Una construccin similar produce la fbrica de
pueden crear manualmente o con un banco de trabajo de lenguaje como GME o el
hormign ( DerbyDAOFactory o
proyecto de modelado de Eclipse 4.

MySQLDAOFactory) para la funcin seleccionada.

Tambin hay dos modelos que se pueden utilizar para feature- variabilidad basada,
basados en las buenas prcticas conocidas [23] para escribir generadores de cdigo:

Figura 6. patrn de capa de datos Thin.

Figura 5. Modelo de Visitantes aplica la generacin de cdigo basado en funciones a.
El patrn primera (Figura 5) se conoce como la visitante AP-
Este patrn, que se muestra 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, la informacin que necesita el
generador se hace explcito, lo que facilita la evolucin tanto del generador y

2 http://db.apache.org/derby/ y http://www.mysql.com
3 Java emisor plantillas (http://www.eclipse.org/modeling/m2t) 4 www.isis.vanderbilt.edu/projects/gme/ y www.eclipse.org/modeling/

109
 IV Simpsio Brasileiro de Componentes, Arquiteturas e Reutilizao de software
la herramienta DSL. Tambin permite el desarrollo de ambos lados en paralelo (un
equipo de desarrollo del generador y otro equipo de desarrollo de las herramientas /
metamodelos). Por ltimo, se libera el generador de una tecnologa de modelado en
particular, y restringe la necesidad de aprender las particularidades de una
herramienta de modelado fi ca a un solo equipo. El equipo de trabajo con la
generacin de cdigo puede centrarse en sus propias tareas.
Un segundo patrn es el caractersticas capa de datos. Normalmente, el modelo de
caractersticas es un punto central de informacin para los generadores, incluso los que se
dedica exclusivamente a la variabilidad basada en DSL. Este patrn propone que una capa
comn de datos contiene toda la informacin relacionada con las caractersticas. Esta capa de
datos debe estar diseado para ser accedido por cualquier generador, permitiendo que se
consulta de informacin de funcin, mientras que la generacin de cdigo. Si hay una
herramienta para el modelado de funcin, una por separado
capa de datos delgada se puede utilizar para almacenar los datos de caractersticas sin depender de
esa herramienta en particular.
El segundo ejemplo de cdigo en la seccin IV-A ilustra la caractersticas
capa de datos patrn. En lugar de directamente
leyendo desde el modelo de caractersticas, XPath
consultas $ FeaturesModel / @ derby = 'true'
$ FeaturesModel / @ mysql = 'true' acceder a una capa de datos separado,
almacenada en una ranura temporal representada por
$ FeaturesModel. Esta ranura temporal contiene slo la informacin necesaria
del modelo de caractersticas que en realidad es utilizado por los generadores
de cdigo. El cdigo siguiente muestra la idea general de cmo esta capa
puede ser poblada usando jags JET < c: Carga> y < c: set>. En este ejemplo,
se selecciona la funcin derby:
<% - carga de la herramienta configurador de productos -%> <c: carga url =
"features.xmi" var = "conf" /> <% - inspeccionar conf para ver que cuenta
se seleccionan. y establecer las variables necesarias -%>
<C: set select = "$ featuresModel"
name = "derby"> true </ c: set>
<C: set select = "$ featuresModel"
name = "mysql"> false </ c: set>
patrones de integracin C. Subdominio
Estos patrones tienen por objeto proporcionar una buena integracin entre el
software generado por la no generado y, particularmente en aquellas reas
relacionadas con las fronteras de un subdominio. Los patrones de esta seccin se
dividen en cuatro categoras, de acuerdo con la dependencia entre el cdigo generado
y no generado:
El cdigo generado depende de cdigo no generado. Este es el tipo ms
simple de la interaccin, y consiste en hacer el cdigo de producto generador
que utiliza el cdigo existente, no generado, tal como un marco o API.
los fachada [ 21] patrn se puede utilizar para simplificar la interaccin entre
el cdigo generado y no generado. lugar In- de generar cdigo que utiliza
mltiples clases y mtodos, un solo grupo lata clase Fachada todas las clases y
los mtodos necesarios. Esto no slo hace que las dependencias ms explcita,
sino que tambin puede proporcionar cierta proteccin contra los cambios en el
cdigo no generado. Dependiendo de la profundidad
el cambio es, podra no ser necesario cambiar el generador, que es una
tarea ms compleja, propenso a errores.
Para proteger el generador de modificaciones en el cdigo no generado, el adaptador
[ 21] patrn puede ser utilizada, en recoger, de filtro y / o preparar la
informacin que necesita el cdigo generado. los puente [ 21] patrn puede ser
usado con el mismo propsito, la creacin de una representacin abstracta de
un cdigo de referencia, que es libre de ser modi fi introducir simples modi fi
caciones. Las clases parciales son otra manera de lograr esto, como muestra
el siguiente cdigo:
// Este archivo se genera clase parcial pblica ClientNodeObject {
ClientNodeObject pblica (int puerto) {
// generado _initData cdigo init (); }}
// Este archivo es escrito a mano clase parcial pblica
ClientNodeObject {
_initData vaco () {
y // cdigo escrito a mano}}
En este ejemplo, escrito en C #, el compilador es responsable de integrar
los dos archivos en una sola clase.
No generado por el cdigo depende del cdigo generado. Esto sucede cuando
algn cdigo no genera espera que se genere algn comportamiento o estructura. En
la mayora de los casos, tales como patrones fbrica de resumen, el mtodo de la
plantilla o la fbrica [ 21] se puede utilizar, por lo que el cdigo no generado no
necesita saber detalles acerca de cmo se implementan en realidad las clases o
mtodos que utiliza.
El siguiente cdigo de Java no generados ilustra cmo la dependencia se
reduce a travs de la Abstract Factory. En este ejemplo, este cdigo no-Java
generada depende de la caracterstica de derby es seleccionado, pero no hay
necesidad de mucho detalle, como el patrn de la fbrica abstracta oculta la mayor
parte de ella:
DefaultDAOFactoryProvider public class {DAOAbstractFactory esttica
privada
theInstance = null;
DAOAbstractFactory public static
getDefaultDAOFactoryInstance () {if (theInstance == null)
theInstance = new DerbyDAOFactory (); volver 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 varias de red subdo- estn relacionados es cmo asegurar esta relacin
entre ellos. Una posibilidad es el uso de los nombres de los elementos como
referencias, es decir, el nombre de una referencia en un modelo debe coincidir
con el nombre del elemento que se hace referencia en otra
110
 IV Simpsio Brasileiro de Componentes, Arquiteturas e Reutilizao de software
nmero de estudio 1 2
Dominio Autora de web
Ubicacin CCIM / USP - S~ ao Carlos / SP - Brasil
Participantes 1 (autor)
Duracin 3 meses (tiempo completo)
Num. DSL 4 3
Num. artefactos generacin 38
Tamao (LOC) de generacin de artefactos 1610
Tamao (LOC) ref. implementacin 5941
Num. de caractersticas de dominio 15
tecnologas de implementacin Apache Tomcat, MySQL, Java, JSP, JSTL, Servlets,
XML, SQL, Eclipse
tecnologas MDE Modelado del eclipse, el JET (Java emisor plantillas)
S UMARIO de los casos prcticos
modelo. Aunque no es ideal, esta simpli fi ca el proceso de implementacin de las
referencias entre modelos [11].
Otra opcin son los puentes modelo, que consisten en los duplicados IONES
CRE de elementos de la metamodelo referencia en el metamodelo de referencia.
En la creacin de pginas web ejem- plo, esto corresponde a la creacin, en el
metamodelo de navegacin, de un elemento llamado ReferenceToDocumentType,
o algo similar, que se puede utilizar para establecer referencias entre
metamodelos. Una ficha separada puede asegurarse de que estas referencias
son vlidas [10].
V. E VALUACIN
Para evaluar nuestro enfoque, hemos llevado a cabo tres casos estu- IES, que
se describen en la Tabla I. El primer estudio implic el dominio de la creacin de
contenidos web, que es un dominio tcnico que incluye aplicaciones para la
Publicacin y visualizacin informa- cin, tales como sitios web de noticias, foros y
blogs. Se realiz en un escenario puramente acadmico. Los estudios se
realizaron segunda y tercera, en relacin con la industria. El segundo estudio
incluy el dominio de dis- aplicaciones basadas en la nube Tributado, que es
tambin un dominio tcnico, principalmente relacionadas con la comunicacin y de
descubrimiento de funcionalidades peer-to-peer. El tercer estudio de caso involucr
el dominio de los acontecimientos cientficas, que es un dominio de negocio.
Los tres estudios de caso tom una cantidad de tiempo similar, aunque el tercer
estudio tuvo una duracin ms pequea y slo la disponibilidad de tiempo parcial de
los participantes. El tercer caso fue el ms grande en trminos de lneas de cdigo de
la implementacin de referencia, pero ms pequeo en trminos de los artefactos
generacin, que re fl eja el hecho de que los participantes tenan menos tiempo para
implementar la automatizacin MDE.
El objetivo de estos estudios fue evaluar si los controladores y los modelos
propuestos pueden ayudar a producir una arqui- tectura que se adapta mejor a
MDE, por lo que la idea era hacer una comparacin entre las implementaciones
existentes, desarrollado sin ellos, y la resultante MDE- implementacin basada,
desarrollado con ellos. Para todos los estudios, los mismos participantes eran
responsables del desarrollo de las dos versiones (con y sin nuestro enfoque).
3
Las aplicaciones basadas en la nube eventos cientficas
Microsoft Research - Redmond / WA - EE.UU. Sistemas Aptor - S ao Carlos / SP - Brasil
2 (incl. Autor) 2
3 meses (tiempo completo) 2 meses (a tiempo parcial)
2
29 8
2847 1375
12127 71873
- 29
Visual Studio 2008, SQL Server, C #, .NET,
.NET Remoting, Volta, PNRP, DBML, LINQ Adobe Dreamweaver, PHP, MySQL
Visual Studio 2008, Microsoft Las plantillas de texto, Modelado del eclipse, el JET (Java emisor plantillas)
Genrico Modelado Medio Ambiente
Tabla I
Hay pocas mtricas orientadas al modelo disponibles y ex periencia han
demostrado que estos a menudo no son fiables [24]. Algunos autores han utilizado
indicadores clsicos orientados a objetos para evaluar los modelos [25], [26],
argumentando que son ms estables y pueden detectar los mismos problemas que
aparecern en el cdigo, pero antes en el proceso. Decidimos seguir esta segunda
lnea de pensamiento y utilizar las medidas ms confiables:
METRO 1: RP - Reutilizacin ciento. LOC reutilizado / COL total. Este es un clsico
mtrica reutilizacin [27], que cuenta como reutilizado cualquier lnea de cdigo que se
reutiliza sin modi fi cacin.
METRO 2: RR - Relacin de reutilizacin. Lo mismo que METRO 1, pero aqu artefactos
que sufren slo una pequea modificacin fi (menos de 25% del cdigo es modi fi) se
consideran reutilizado as como [28].
METRO 3: Porcentaje de reutilizacin no deseado. La reutilizacin de las grandes piezas de
cdigo no utilizado puede distorsionar la mtrica reutilizacin por ciento. Por esta razn, hemos de
fi nida mtrica METRO 3, que consiste en el clculo de las lneas de cdigo que se reutiliza (copiado
en el nuevo contexto), pero no se estn utilizando. funciones IDE que encontramos mtodos que
no estn siendo llamados pueden ser utilizados para recoger estos datos.
METRO 4: inestabilidad del mdulo. Esta medida tiene como objetivo evaluar lo
difcil que es para modificar una pieza de software [29]. Los rangos de mtricas de
cero a uno, donde cero significa un establo (fcil de modificar) mdulo, y uno
significa un inestable (culto di fi modificar) mdulo.
METRO 5: ciclomtica complejidad. Se trata de una complejidad mtrica clsica
[30], basado en el nmero de caminos dentro de un programa. Los valores entre 1 y
10 indican la simplicidad, y valores por encima de 50 representan mdulos complejos.
En el contexto de esta investigacin, la complejidad es un indicador importante de
cmo la arquitectura est facilitando tareas como la implementacin, mantenimiento y
reutilizacin del software.
METRO 6: ndice de mantenimiento. Esta mtrica es un intento de determinar la facilidad
con un mdulo puede ser mantenida, mediante la combinacin de una serie de mediciones
empricas, como el volumen y la complejidad Halstead ciclomtica [31]. Valores por debajo
de 65 indican baja de mantenimiento, mientras que los valores superiores a 85 indican una
buena capacidad de mantenimiento.
Estas mtricas se recogieron con la ayuda de herramientas
111
 IV Simpsio Brasileiro de Componentes, Arquiteturas e Reutilizao de software
METRO 1 METRO 2 METRO 3
WO W WO W WO W WO W WO W WO
estudio 1 36.04 93.32 43.70 93.32 3.32 0
estudio 2 64,47 82,66 65.66 82.66 16,68 10,01
estudio 3 82.15 74.45 96.11 94.69 51.43 21.88
Tabla II
mi Resultados de valoracin. WO = W ITHOUT APPROACH, W = W ITH de aproximacin.
Eclipse Metrics, JHawk y Net2Java 5. La extraccin manual tambin era necesario que
esos artefactos, como las plantillas genera- cin de cdigo, no son compatibles con las
herramientas automticas.
El uso de estos indicadores indirectos, se intent obtener una imagen de cmo el
enfoque puede influir diferentes factores en el desarrollo de software. Saber si los
resultados observados se di- rectamente causados por el enfoque y la arquitectura
producida o por otros factores sigue siendo una amenaza para el estudio. Para
suavizar esta incertidumbre, una entrevista tambin se llev a cabo con los
participantes en el tercer caso de estudio. La entrevista consisti en preguntas
abiertas sobre las impresiones de los participantes sobre los beneficios y di fi
cultades de utilizar el enfoque.
A. Resultados y anlisis
La Tabla II muestra los resultados de la evaluacin. Mtrica METRO 4,
METRO 5 y METRO 6 no pudo ser extrado para el Estudio 3 porque no podamos
hallar una herramienta automatizada para extraerlos de OO no cdigo PHP, que se
utiliz en este dominio.
En los dos primeros estudios, se observ un aumento en el nivel de reutilizacin,
en trminos de la LOC, ya sea teniendo en cuenta su reutilizacin sin modi fi cacin ( METRO
1) y con modificaciones menores ( METRO 2). El grado de reutilizacin no deseada ( METRO
3) tambin se redujo ligeramente en esta primera dos estudios. Para el tercer estudio,
sin embargo, el nivel de reutilizacin en trminos de LOC se redujo cuando se utiliz el
enfoque. De hecho, el nivel de reutilizacin ya era alta y sin el enfoque. Por otra parte,
la reutilizacin no deseada es considerablemente menor cuando se utiliz el enfoque.
Para el estudio 1, que es un dominio tcnica relativamente simple, se
observ que la arquitectura resultante tena una estabilidad general
mejorada de los mdulos. Sin embargo, eran, en promedio, ms complejo y
ms difcil de mantener. Para el estudio 2, que involucr a un dominio
tcnico ms complejo, se redujo la complejidad de la arquitectura, sin afectar
demasiado la capacidad de mantenimiento.
Para el estudio 3, se realiz una entrevista. Durante esta entrevista, los
participantes informaron que el enfoque ayud a resolver algunos problemas que
no pueden resolverse con la mano, en particular las muchas personalizaciones
que deben realizarse cada vez que se vende un producto. Trataron de
parametrizar algunos de estos en el cdigo, pero se abandon esta prdida
causada a menudo de generalidad, y as esta solucin. Con MDE y el uso de un
enfoque de diseo arquitectnico ms alto nivel, el cdigo reutilizable puede
permanecer genrico, mientras que el cdigo fi nal
5 metrics.sourceforge.net, www.virtualmachinery.com/jhawkprod.htm y net2java.dev.java.net
112
METRO 4 METRO 5 METRO 6
W
0,558 0,488 2,267 3,916 114.891 82.329
0,496 0,479 3.252 2.054 120,333 118,063
- - - - - -
se hace especfica a travs de la generacin de cdigo. La automatizacin tambin ayud a
reducir los errores en la personalizacin.
Otro aspecto planteado por los participantes fue el hecho de que la
reutilizacin fue alta sin el enfoque, pero a costa de tener grandes piezas de
cdigo no utilizado copiado en el producto. Esto estaba causando cierta
confusin, especialmente en el mantenimiento. El enfoque que ayud a reducir.
Los participantes tambin informaron de que las tecnologas de modelado y generacin
de cdigo son difciles de aprender, lo que requiere un cambio de pensamiento a utilizar
correctamente ellos. Los participantes tenan habilidades bsicas de modelado y trabaj
como programadores durante dos aos, sin haber trabajado con MDE antes. Sin embargo,
se las arreglaron para implementar la funcionalidad requerida despus de un entrenamiento
de 16 horas sobre el MDE.
La Tabla III resume nuestras observaciones, las cuales indican que los conductores y los
patrones propuestos pueden traer beneficios en muchas situaciones, pero un anlisis de
compensaciones debe llevarse a cabo para evaluar sus inconvenientes de mayor
complejidad, disminucin de la capacidad de mantenimiento y una curva de aprendizaje alta.
Proyectos similares para estudiar 2, es decir, que implican dominios tcnicos ms complejos,
parecen ser los mejores candidatos para el uso de nuestro enfoque.
std principales observaciones
1 Arquitectura produjo un aumento de la reutilizacin, pero al coste de los
mdulos ms complejos y menos mantenibles 2
Arquitectura produjo un aumento de la reutilizacin, menos complejo y ms fcil de
mantener los mdulos 3
enfoque basado en el MDE es difcil de aprender, pero facilita la personalizacin
de productos y hace ms centrado reutilizacin
Tabla III
METRO OBSERVACIONES AIN en los casos estudiados
B. Amenazas a la validez
Hay algunas amenazas a la validez de este estudio. La participacin de uno de los
autores de este trabajo en dos de los estudios pueden haber influido en los resultados.
Adems, el hecho de que no hemos sido capaces de recopilar las mtricas para el
tercer estudio hecho nuestras conclusiones menos generalizada. El uso de mediciones
indirectas es tambin una amenaza para este tipo de experimento.
Consideramos que el hecho de que los mismos participantes desarrollaron la
infraestructura de dominios con y sin el enfoque qu no influir en los resultados, ya
que el enfoque en realidad fomenta la reutilizacin de software existente para el
desarrollo de dispositivo o de los generadores de cdigo.
 IV Simpsio Brasileiro de Componentes, Arquiteturas e Reutilizao de software
Por ltimo, la realizacin de experimentos en un escenario industrial hace
que sea di fi culto a controlar todos los factores y variables que influyen, y por lo
tanto los resultados pueden ser muy sesgada. Esto tambin se ve agravado por
el hecho de que los estudios se realizaron en ms de un pas, en diferentes
entornos y con diferentes culturas. Sin embargo, esto tambin es una buena
cosa, ya que aumenta la diversidad y la confianza general con fi en los
resultados.
VI. R TRABAJO ELACIONADAS
Czarnecki et al. [32] presentar un enfoque basado en la plantilla para la generacin de
modelos a partir de modelos de caractersticas. A travs de pings MAP- entre caractersticas y
modelos generales, tales como datos o modelos de comportamiento, ms rico de informacin
puede asociarse con las caractersticas. Cuando se aplica a los modelos arquitectnicos, la
variabilidad ms detallado puede ser especi fi cado, que es similar a nuestro enfoque. Sin
embargo, a diferencia de Czarnecki et al. De trabajo, que tambin se ocupan de los problemas
que se derivan de la inclusin de los artefactos fi MDE-especficas, tales como modeladores fi
cas de dominio-especfico y generadores de cdigo.
Perovich et al. [33] proponer un enfoque que utiliza las caractersticas de modularizar
decisiones arquitectnicas. Estos estn hechos Creta con- travs de transformaciones de
modelos que pro- automticamente fragmentos arquitectnicos Duce que corresponden a
las caractersticas seleccionadas. Al igual que en nuestro enfoque, la arquitectura es un
artefacto que se sienta en un meta-nivel diferente, incluyendo transformaciones y
generadores de cdigo que van a desaparecer de la arquitectura del producto fi nal. La
principal diferencia con respecto a nuestro trabajo es que incluimos una preocupacin
explcita sobre la variabilidad ms detallado, la aplicacin de DSL en partes del dominio
para alcanzar el poder ms expresivo, mientras Perovich et al. utilizar slo modelos de
caractersticas como un punto de partida para con producto fi guracin.
En [34], los autores presentan un enfoque basado en modelos para la ingeniera de
requisitos en un contexto lnea de productos. Al igual que en nuestra investigacin, que
defienden la idea de que las caractersticas deben complementarse con modelos
adicionales para representar mejor la variabilidad. reglas de composicin entre casos de
uso se utilizan de manera similar al concepto de casos de cambio, pero sin el beneficio
de la produccin de escenarios individuales que pueden ser utilizados en la evaluacin.
Adems, su trabajo no presentan detalles acerca de cmo se obtiene la arquitectura, con
los patrones, por ejemplo.
El trabajo descrito en [35] presenta un enfoque para derivar la arquitectura de los
modelos de anlisis utilizando transformaciones semi-automticas. Sin embargo, se
supone que los modelos de anlisis son lo suficientemente ricos como para ser
transformado automticamente en una arquitectura. Adems, slo un nico estilo
arquitectnico (C2 [35]) es compatible. Y finalmente, el enfoque se centra en el
desarrollo de producto nico, que no cubra las cuestiones relacionadas con la
reutilizacin, tales como la variabilidad de apoyo y derivacin producto.
VII. do OBSERVACIONES ONCLUDING y trabajo futuro
MDE puede aprovechar la ingeniera de dominio a travs de tcnicas que
apoyan la variabilidad ms complejo e implementacin automtica. En
general, la literatura est ms enfocado
113
en el proceso de derivacin producto automtico. No hay duda de que este es el
objetivo final a alcanzar, y estamos de acuerdo con eso. Sin embargo, se presta
poca atencin al proceso de produccin de un dominio de la arquitectura que est
preparado para este tipo de automatizacin, y creemos que los temas que hemos
discutido en este trabajo son importantes.
Nuestra investigacin tiene como objetivo proporcionar una manera ms sistemtica para
llevar a cabo el diseo de dominio teniendo en cuenta los requisitos de un esfuerzo de
ingeniera de dominio que beneficiarse de las tcnicas de MDE. Las principales aportaciones
de esta investigacin son la identificacin de los espec fi cos de los conductores y los
patrones arquitectnicos que se pueden utilizar para producir una arquitectura de software fi
co-dominio especfico, y la descripcin de cmo tratar con ellos utilizando los nuevos patrones
existentes y nuevos.
Tambin proporcionamos los resultados de una evaluacin. A pesar de las
amenazas a su validez, consideramos que las observaciones valiosas podran
hacerse. Los datos cualitativos y cuantitativos sealaron que el enfoque es viable, y
puede conducir a beneficios en trminos de desarrollo de software. La arquitectura
resultante ayud a aumentar el nivel de reutilizacin, como se observ en dos de los
tres estudios de caso, y tambin hacen que sea ms centrado, como se observa en
uno de los estudios. Los patrones propuestos tambin parece ayudar a tratar con el
diseo de arquitecturas para los dominios ms complejos, como la que implica
aplicaciones basadas en la nube distribuidos. Sin embargo, hemos observado algunos
inconvenientes que deben tenerse en cuenta en un anlisis de compensaciones antes
de usar nuestro enfoque.
Como trabajo futuro, estamos planeando ms experimentos con estos
controladores y los patrones, para refinar y extender ellos. Los resultados de los
primeros estudios de casos son prometedores, y esperamos que la realizacin de
ms experimentos puede ofrecer resultados ms slidos para la comunidad
interesada.
UN GRADECIMIENTOS
Este trabajo fue apoyado en parte por el National Institute de Ciencia y
Tecnologa de Ingeniera de Software (INES - www.ines.org.br), financiado
por el CNPq y FACEPE, otorga 573.964 / 2008-4 y APQ-1037 a 1,03 / 08 .
R EFERENCIAS
[1] P. Clements y L. Northrop, Lneas de productos de software: ticas
ticas y patrones. Addison-Wesley, 2002. [2] L. Bass, P. Clements, y R. Kazman,
Arquitectura de software
en la prctica, 2 edicin. Addison-Wesley, 2003. [3] J.-P. Tolvanen y S. Kelly,
De fi nicin de dominio especfico mo-
eling idiomas para automatizar la derivacin del producto: experiencias
recogidas,en 9 de SPLC-Europa, Ser. LNCS, vol. 3714. Springer, 2005, pp.
198-209.
[4] K. Czarnecki, S. Helsen, y U. Eisenecker, , presentada con fi g-
URACIN usando modelos de caractersticas,en Tercero SPLC, Ser. LNCS 3154. Springer,
2004, pp. 266-283.
[5] LB Lisboa, ToolDAy - Una herramienta para el anlisis de dominios
Tesis de maestra, Universidad Federal de Pernambuco, Recife, Pernambuco,
Brasil, 2007.
 IV Simpsio Brasileiro de Componentes, Arquiteturas e Reutilizao de software
[6] K. Czarnecki, Visin general de desa- software generativo
rrollo,en Int. Trabajo. en paradigmas de programacin no convencionales,
Francia, sept, 2004, Ser. LNCS, vol. 3566. Springer, 2005, pp. 326-341.
[7] K. Lee y KC Kang, anlisis de la dependencia de funciones para
lnea de productos de diseo de componentes , en Octavo ICSR, Madrid, Espaa,
2004, pp. 69-85.
[8] J. Bartholdt, R. Oberhauser, y A. Rytina, Un enfoque para
hacer frente a la variabilidad del modelo de entidad dentro de las lneas de productos de software , en ICSEA.
IEEE, 2008, pp. 465-471.
[9] D. Lucr' edio, RP d. M. Fortes, ES d. Almeida, y
d SR. L. Meira, Realizacin de anlisis en el dominio de modelo- impulsada por la
reutilizacin del software, en 10 de ICSR, Ser. LNCS, vol. 5030. Springer, 2008, pp.
200-211.
[10] J. clido y A. Kleppe, La construccin de un software flexible
fbrica utilizando modelos fi especficos de dominio parcial , en 6 Workshop OOPSLA el
dominio espec fi co de modelado, 2006, pp. 15-22.
[11] A. Hessellund, K. Czarnecki, y A. Wasowski, guiado
desarrollo con mltiples lenguajes de dominio especfico,en
MODELOS, Ser. LNCS, vol. 4735. Springer, 2007, pp. 46-60. [12] K. Kang, S.
Cohen, J. Hess, W. Novak, y A. Peterson,
Estudio de viabilidad anlisis orientado en funcin del dominio (FODA), SEI /
CMU, Tech. Rep. CMU / SEI-90-TR-21, 1990. [13] K. Kang, J. Lee, y P. Donohoe,
producto orientado Feature-
ingeniera de la lnea IEEE suave., vol. 19, no. 04, pp. 58-65, 2002. [14] A.
Fantechi, S. Gnesi, G. Lami, y E. Nesti, Una metodologa
para la derivacin y la verificacin de casos de uso para lneas de productosen Tercero
SPLC, Ser. LNCS, vol. 3154. Springer, 2004, pp. 255-265.
[15] EF Ecklund, Jr, LML Delcambre, y MJ Freiling,
Cambiar casos: Casos de uso que identifican las necesidades futuras, en Actas
de la Conferencia de la OOPSLA 96, San Jose, CA, EE.UU.. ACM Press, 1996, pp.
342-358.
[16] E. Visser, WebDSL: Un estudio de caso en el dominio-especfico len-
la ingeniera de calibre , en GTTSE 2007, Ser. LNCS, vol. 5235. Springer, 2007,
pp. 291-373.
[17] G. Guizzardi, LF Pires, y MJV Sinderen, Sobre el papel
de ontologas de dominio en el diseo de lenguajes de modelado visual fi cas de
dominio-especfico , en 2do Taller de dominio espec fi cos lenguajes visuales,
OOPSLA, 2002.
[18] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad,
M. Stal, P. Sommerlad, y M. Stal, Patrn-Oriented Architecture soft- ware,
Volumen 1: un sistema de modelos.
Wiley & Sons, 1996. [19] M.
V Olter y J. Bettin, Patrones para el desarrollo de software dirigido por
modelos, en EuroPLoP 2004, Irsee, Alemania, 2004, pp. D3-1-D3-54.
[20] ES Almeida, A. Alvaro, VC Garcia, LM Nascimento,
D. Lucr' edio, y SR d. L. Meira, Un enfoque sistemtico para disear arquitecturas
de software fi co-dominio especfico, Jour. de Soft.
- Editorial Academia, vol. 02, no. 2, pp. 38-51, 2007.
[21] E. Gamma, R. Helm, R. Johnson, y J. Vlissides, Diseo
Patrones: Elementos de software orientado a objetos reutilizables.
Add.-Wesley, 1995.
[22] W3C, XML Path Language (XPath) versin 1.0 - W3C
la recomendacin 16 de noviembre de 1999World Wide Web Con- consorcio, Tech.
Rep., 1999.
[23] K. Czarnecki y S. Helsen, encuesta basado en funciones de modelo
enfoques de transformacin IBM Syst. Jour., vol. 45, no. 3, pp. 621-645, 2006.
[24] M. Genero, G. Poels, y M. Piattini, De fi Ning y validada
data mtricas para evaluar la comprensibilidad de los diagramas entidad-relacin
Conocimiento de datos. Eng., vol. 64, no. 3, pp. 534-557, 2008.
[25] J. Muskens, M. Chaudron, y C. Lange, Investigaciones en
la aplicacin de mtricas a los modelos multi-vista de la arquitectura , en Conferencia
EUROMICRO 30a. IEEE / CS Press, 2004, pp. 372C-
379.
[26] SR Chidamber y CF Kemerer, Un conjunto de mtricas
objeto de diseo orientado, IEEE Trans. N del software. Eng., vol. 20, no. 6, pp.
476-493, 1994.
[27] JS Poulin y JM Caruso , una mtrica de reutilizacin y el retorno de la
modelo de inversin,en Segundo ACM / IEEE Int. Taller sobre suave. Reutilizacin.
IEEE / ACM, 1993, pp. 152-167.
[28] P. Devanbu, S. Karstu, W. Melo, y W. Thomas, Analytical
y la evaluacin emprica de las mtricas de reutilizacin de software , en 18a CISE.
IEEE, 1996, pp. 189-199.
[29] R. Martin, Diseo orientado a objetos mtricas de calidad: Un
anlisis de dependencias 1994, disponible a:
http://www.objectmentor.com/resources/articles/oodmetrc.pdf. El acceso en MAR
/ 2010. [30] TJ McCabe, Una medida de la complejidad IEEE Transactions
en Ingeniera de Software, vol. 2, no. 4, pp. 308-320, 1976. [31] KD Welker y
PW Oman, mantenibilidad Software
mtricas modelos en la prctica Diafona, Diario de Defensa Ingeniera de
Software, vol. 8, no. 11, pp. 19-23, 1995. [32] K. Czarnecki y M. Antkiewicz,
caractersticas de mapeo para MOD-
els: Un enfoque basado en la plantilla variantes superpuestas,en GPCE cuarto, Ser.
LNCS, vol. 3676. Springer, 2005, pp.
422-437.
[33] D. Perovich, PO Rossel, y MC Bastarrica, Feature
modelo para arquitecturas de producto: Aplicacin MDE a las lneas de productos de
software , en WICSA / ECSA 2009. IEEE, 2009, pp. 201-
210.
John
[34] M. Alferez, U. Kulesza, A. Sousa, J. Santos, A. Moreira,
J. Ara' Ujo, y V. Amaral, Un enfoque basado en modelos para el producto de
software requisitos lneas de ingeniera, en SEKE.
Sistemas de Conocimiento Instituto Graduate School, 2008, pp. 779-784. [35]
JE P'
Erez-Mart'nez y A. Sierra-Alonso, Desde modelo de anlisis de la
arquitectura de software: Un mapeo PIM2PIM, en
ECMDA-FA, Ser. LNCS, vol. 4066. Springer, 2006, pp. 25-
39.
114