Modelos de Marcas en Arquitecturas dirigidas por Modelos

Prof. Dr. Ricardo TESORIERO – Departamento de Sistemas Informáticos- Universidad de Castilla-La Mancha
[ricardo.tesoriero@uclm.es]
Métodos Avanzados de Desarrollo de Software
Asignatura Optativa de 4º Año
Grado en Informática
Departamento de Sistemas Informáticos
Universidad de Castilla-La Mancha
Métodos avanzados de
desarrollo de software
Tema VIII: Arquitecturas dirigidas por Modelos.
Modelos de marcado

Índice
• Motivación
• Modelo de marcado y marcas
• Beneficios
• Formas de marcado
• Aplicación de marcas y modelos de marcado
• Relación entre marcas y modelos de marcado
• Otras marcas
• Implementaciones
• Uso
El material que aquí se presenta está parcialmente basado en una traducción de:
Stephen J. Mellor, Kendall Scott, Axel Uhl, Dirk Weise. MDA Distilled: Principles of Model-
Driven Architecture. Addison Wesley. 2004.

Motivación
• Hemos visto que a que las funciones de transformación por si solas
no son suficientes para transformar un modelo fuente de forma
completa, ya que podríamos no ser capaces de seleccionar la regla
de transformación adecuada solamente con la información
contenida en el modelo fuente.
• Por lo tanto, podríamos necesitar entradas adicionales para ejecutar
la transformación
• Estas entradas adicionales se llaman marcas, las cuales son
extensiones livianas no intrusivas de los modelos que capturan la
información requerida para la transformación sin contaminar los
modelos.
• Un modelo de marcado establece la misma relación a las marcas
que los meta-modelos lo hacen a los modelos
• El modelo de marcado define nombres, tipos, y valores por omisión
para cada marca. De aquí, las instancias de las clases en un modelo
de marcado, son las marcas

Modelo de marcado y marcas
Modelo Metamodelo
Transformación
Función de
Transformación
Regla de
Transformación
Marca
Modelo de
Marcado
capturado_en
0..1
destinofuente
1..* 1..*
aplicación_de
1
instancia_de
1
generaacepta
1..* 1..*
0..* 0..*
destinofuente
1..* 1
acepta
1..* 1..*
0..* 0..*
1..*
marca
0..* 0..*
modeloMarcas
genera
Figura basada en la presentada en [1].

Uso de Marcas
• Consideremos un PIM, modelado sin referencia a los objetos
distribuidos y acceso remoto (similar al que vimos la clase
pasada)

Uso de marcas
• Una función de transformación por omisión que transforma todos
los elementos del modelo fuente en objetos accesibles
remotamente en el modelo destino.
• Esto podría llevar a una implementación muy lenta.
• Sería más eficiente hacer algunos accesos locales y otros remotos.
• => debe existir algún mecanismo que indique si
• Se debe aplicar la regla de transformación que genera un acceso
remoto.
• Se debe aplicar la regla de transformación que genera un acceso
local.
• El mecanismo que usamos es una marca.
• = que las funciones de transformación, las marcas no son parte ni del
modelo fuente ni del destino, aunque se pueden referir elementos
de ambos

Uso de marcas

Beneficios de usar marcas
• Esta separación
• proporciona longevidad y portabilidad
• permite evaluar diferentes posibilidades de transformación sin
modificar el PIM.
• En sistemas empresariales
• Permiten que características como la distribución entre
procesadores y tareas, varíen, mientras se miden los efectos.
• En el diseño de sistemas embebidos,
• Permiten variar características asociadas a la tecnología de
implementación con modelos de aplicación
• Por ejemplo, elementos de la aplicación con una tareas o
procesador

Formas de marcado
• Por el usuario, en tiempo de mapeo
• Una transformación automatizada podría pedir información (como
un Clipo) cada vez que se ejecuta para decidir.
• ¿Acceso Local o Remoto para X?
• Sin embargo, sería interesante guardar esas respuestas (para no
tener a Clipo preguntando ) en futuras aplicaciones de la misma
función de transformación sobre el mismo modelo fuente.
• Derivadas del modelo fuente
• Las marcas pueden ser derivadas automáticamente de los modelos
fuente.
• Por ejemplo:
• Se podrían contar en cuantas acciones de la clase Cliente se accede a
Cuenta y guardarlo como una marca.
• Si la cuenta es 0 => no hace falta acceso remoto.

Marcas y modelos de marcado
• Existen varios tipos de marcas
• Sólo describiremos aquellas asociadas con los elementos del modelo de
desarrollo (en el nivel M1)
• Ejemplo 1
• En el caso de las cuentas, cada operación de acceso en el modelo fuente
tendremos una marca (AccessorType) con uno de estos dos valores:
• isRemote
• isLocal
• Ejemplo 2
• Supongamos que el sistema tiene que manejar 100.000 instancias de clientes
y 500.000 de cuentas.
• Éstos valores se pueden tener en cuenta cuando hay que decidir el tamaño
de las tablas en la base de datos y en la generación de sentencias de acceso
de datos optimizadas
• Esta información puede ser capturada como una marca InstanceQuantity en cada
clase

Marcas y modelos de marcado
• Ejemplo 3
• Supongamos una función de transformación produce un esquema
de base de datos relacional de un modelo de UML.
• A veces, el administrador de base de datos es el que establece el
nombre de las tablas y de las columnas de base de datos.
• En este caso, no se usa la marca para seleccionar la regla a aplicar
la marca; simplemente indica los nombres de las tablas y de las
columnas de la base de datos.
• Implementaciones
• enum AccessorType [isRemote, isLocal] = isLocal
• InstanceQuantity:Int = 500000
• table: String
• column: String
UML REL
(Ejemplo 1)
(Ejemplo 2)
(Ejemplo 3)

Aplicación de marcas y modelos de
marcado
• Marcas de selección
• La marca AccessorType demuestra cómo se seleccionan las reglas de
acuerdo con el valor de una marca.
• Si el valor de una marca es isRemote, la transformación usa las reglas
que producen un componente para acceso remoto
• En caso contrario utiliza las reglas para un componente de acceso local.
• Marcas de provisión
• Supongamos que decidimos asignar post-fijos a los nombres de
clases. El valor del post-fijo puede ser proveído por las marcas.
• Marcas de optimización
• Supongamos que necesitamos optimizar memoria. Si podemos
calcular a partir de los métodos cuales son las variables que se
necesitan, podemos eliminar aquellas referencias que no se
necesiten
• Marcas Mixtas
• Combinación de las anteriores

¿Cómo relacionamos las marcas y
los elementos del modelo?
• En el ejemplo remoto/local, las marcas se aplican a acciones que
leen, escriben o limpian un atributo.
• En el meta-modelo de UML, estas acciones son modeladas como un
súper-tipo de StructuralFeatureAction, y cada acción atributo puede
ser local o remota.
• El resultado es que la marca AccessorType está asociada a
StructuralFeatureAction.
• Después de enfatizar que las marcas deben estar separadas de los
modelos, sería patológico contaminar el meta-modelo con
conceptos de modelos de marcado.
• Como hemos visto las marcas son livianas, extensiones no intrusivas
añadidas al modelo de desarrollo, así que podemos ver el modelo de
marcado como una «hoja de plástico» sobre el meta-modelo.
• Específicamente una «hoja de plástico» con un atributo extendido
de StructuralFeatureAction llamado AccessorType.

• En el ejemplo del acceso remoto/local; las marcas se aplican a
acciones que leen, escriben o limpian un atributo.
• Por lo tanto, una solución sería:
Notar que StructuralFeatureAction es la meta-clase de los atributos en UML.
• No tenemos la intención de que el meta-modelo debería extenderse
directamente
• Ya que dijimos que las marcas eran “independientes” y no debíamos
“ensuciar” el modelo.
• Además, un elemento del modelo puede tener varias marcas
asociadas: Stateful o Stateless, Transient o Persistent, Local o
Remote, Identificables o no

• Utilizar el concepto de transparencia
• En el cual podemos “agregar información” sin necesidad de
modificar el ni el modelo, ni el meta-modelo del dominio
• Ésta es la forma “más correcta” y “elegante”
Meta-modelo de
dominio
Modelo de marcas
(meta-modelo)
Modelo de dominio
Modelo de dominio
marcado
Merge
Extends
Imports

Ejemplo de múltiples intereses
• Stateful o stateless, transient o persistent, local o remote,
identificables o no.
Meta-modelo de
dominio
Modelo de marcas
(Persistencia)
Modelo de marcas
(Estado)
Modelo de marcas
(Identificación)
Modelo de dominio
Modelo de dominio
(estado)
Modelo de dominio
(identificable)
Modelo de dominio
(persistente)
Combinaciones de modelos

Relacionando marcas y elementos
del modelo
• La reusabilidad está relacionada con las marcas
• Elementos que probablemente sean utilizados en forma conjunta
por funciones de transformación deben ser agrupados en un mismo
modelo de marcado
• Las marcas que capturan estas decisiones de diseño pueden ser
reutilizadas si el modelo fuente es transformado en otro modelo
destino donde decisiones de diseño similares podrían ser utilizadas.
• Ejemplo, múltiples plataformas
• Se pueden hacer particiones del marcado: una para las marcas
independientes de la plataforma y otro para las marcas específicas de
la plataforma.
• Así se puede mantener las decisiones de diseño en diferentes
plataformas

Otras marcas
• Las marcas que hemos descripto son aplicadas a elementos
del modelo construidos por el desarrollador, pero existen
otras marcas
• Por ejemplo, podríamos definir marcas para que todos los
nombres de las clases terminen en «_C».
• Se aplica a todas las clases, no a clases en particular.
• Se puede ver como una marca de configuración global
• Las funciones de transformación pueden producir marcas para los
meta-modelos destino como salidas que puedes ser útiles si la
transformación necesita recordar cómo se mapean los elementos
de modelo fuente y destino.

Implementaciones de marcas y
modelos de marcado
• Para asignar valores a las marcas
• Drag and Drop gráfico en carpetas que definen las marcas
• Editor que permite para los conjuntos de marcas definidos que
muestras todas las marcas definidas por el modelo para un
elemento de modelo seleccionado, con menús para cada marca.
• Archivos de texto (permiten scripting)
• Lenguaje de modelo de marcado en MOF, en repositorios (otro
modelo)

Teoría de modelos de marcado
• No existe ninguna que especifique exactamente que debe ir
en el modelo de marcado y como crear uno
• Todo depende del problema a resolver
• No hay una taxonomía para las marcas de las cuales podemos
derivar todas las marcas.

Uso de las marcas
• Se utilizan para seleccionar reglas de transformación y actuar
como funciones de transformación.
• Las marcas no son parte ni del modelo origen, ni del destino
• No deberían contaminar los modelos
• Deberían ser reusadas en diferentes contextos
• Los tipos de marcas que se pueden aplicar a un modelo
pueden ser capturadas en un modelo de marcado, que
definen las características de las marcas
• Las marcas y los modelos de marcas van juntos y permiten
adaptar el modelo origen al destino
• Las marcas pueden se propagadas o heredadas de un
elemento de modelo a otro

Referencias
1. Stephen J. Mellor, Kendall Scott, Axel Uhl, Dirk Weise. MDA
Distilled: Principles of Model-Driven Architecture. Addison
Wesley. 2004.
2. Object Management Group. Unified Modeling Language:
Superstructure. Version 2.0, ptc/03-07-06, July 2003;
http://www.omg.org/cgi-bin/doc?ptc/2003-08-02.

Modelos de Marcas en Arquitecturas dirigidas por Modelos

Recomendados

Recomendados

Más contenido relacionado

Similar a Modelos de Marcas en Arquitecturas dirigidas por Modelos

Similar a Modelos de Marcas en Arquitecturas dirigidas por Modelos (20)

Modelos de Marcas en Arquitecturas dirigidas por Modelos