ATL 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 IX: Arquitecturas dirigidas por Modelos.
Atlas Transformation Language (ATL) - Parte I

Índice
• Repaso
• Introducción
• ATL module
• Estructura
• header
• import
• helpers
• Rules
• Matched Rules
• Lazy Rules y Called Rules
• Modos de ejecución de ATL
• Semántica de ejecución de ATL
• ATL Queries
• ATL Libraries

Repaso
• Un modelo tiene que ser definido de acuerdo a la semántica que
provee su meta-modelo
• Así un modelo «se ajusta» (conforms to) a un meta-modelo
• De la misma forma, un meta-modelo «se ajusta» a un meta-meta-
modelo
• En esta arquitectura de 3 capas (modelos, meta-modelos y meta-
meta-modelos), el meta-meta-modelo usualmente se autoajusta a
su propia semántica (se define con sus propios conceptos).
• Algunos meta-meta-modelos son MOF y ECORE

Repaso
• Considerando un modelo como una entidad de «primera clase» se
necesita proveer un conjunto de herramientas que definen algunas
operaciones dedicadas a los modelos.
• Así surge la idea de «transformación de modelos» como operación
entre modelos
• La transformación de modelos es una de las operaciones más
importantes entre modelos
• Las transformaciones de modelos tienen por objetivo generar un
modelo Mb que se ajusta a un meta-modelo MMb, a partir de un
modelo Ma que se ajusta a un modelo MMa.
Mb = fT(Ma)
fT : : MMa -> MMb

Introducción
• Una característica importante en la ingeniería de modelos es
considerar, tanto como sea posible, que todos los elementos
que manejamos sean modelos
• Por lo tanto, la transformación en si misma tiene que ser
definida como un modelo.
• Este modelo de transformación tiene que ajustarse a un meta-
modelo de transformación que define el modelo de la
semántica de la transformación.
• Finalmente, como todos los meta-modelos, el meta-modelo
de transformación tiene que ajustarse a un meta-meta-
modelo

El modelo de transformación
Figura extraída de [1].

El lenguaje ATL
• Se enfoca en las transformaciones modelo a modelo
• ATL ofrece diferentes tipos de unidades (ATL Units):
• ATL Modules que permiten especificar operaciones entre
modelos
• ATL Queries que permiten computar valores primitivos, es decir
Strings o Enteros a partir de modelos fuentes.
• ATL Libraries que permiten crear librerías que pueden ser
importadas desde distintas tipos de unidades ATL (inclusive desde
librerías)
• Útiles para factorizar el código
• Todas las unidades se guardan en archivos ATL

ATL Module
• Un ATL Module se corresponde con una función de
transformación
• Especificar la forma de producir un conjunto de «modelos
destino» a partir de un conjunto de «modelos fuente»
• Tanto los modelos fuente, como los destino, deben estar
tipados por sus correspondientes meta-modelos.
• Un ATL Module acepta un número fijo de modelos de entrada,
y devuelve un numero fijo de modelos de salida
• Como consecuencia, un módulo ATL no puede generar un
número desconocido de modelos destino similares (que se
ajusten a un mismo meta-modelo)

Estructura de un ATL module
• Un ATL Module está compuesto por los siguientes elementos:
• Una sección header que define algunos atributos relativos al
módulo de transformación
• Una sección import opcional que permite importar ATL libraries
• Un conjunto de helpers, que pueden ser vistos como métodos
• Un conjunto de rules que definen la forma en que los modelos
destino se generan a partir de los modelos fuente
• Tanto los helpers como las rules no pertenecen a una sección
específica, y pueden definirse en cualquier orden

La sección header
• El header define:
• El nombre del módulo de transformación
• Las variables que se corresponden con los modelos fuente y destino
• El modo de ejecución
• La sintaxis es:
module module_name;
create output_models [from|refining] input_models;
• module_name
• Establece el nombre del módulo
• Debe corresponderse con el nombre del archivo ATL
• output_models
• Establece los modelos destino
• from/refining
• Establece si es una transformación normal o de refinamiento
• input_models
• Establece los modelos fuente
• Tanto los modelos fuente como destino:
• Deben ser especificados como model_name : metamodel_name
• Se pueden declarar más de uno, separándolos con comas (,).
• Los nombres de los modelos sirven para identificarlos => deben ser únicos

Ejemplo
module Author2Person;
create MMPerson : PersonModel from MMAuthor :
AuthorModel;
MMAuthor MMPerson

La sección import
• Es opcional
• Permite declara las librerías ATL que son importadas
• Sintaxis
uses extensionless_library_file_name;
• Ejemplo
uses strings;
• Se acepta la importación de más de una librería mediante el
uso de secuencias de sentencias uses.

Las rules
• En ATL existen 3 tipos de reglas que se corresponden con dos
modos de programación diferentes (programación declarativa
e imperativa)
• Matching rules (declarativa)
• Lazy rules (imperativa)
• Called rules (imperativa)

Las Matched rules
• Son el núcleo de ATL
• Permiten especificar:
• Para qué tipos de elementos fuente deben ser generados
elementos destino
• La forma en que los elementos destino deben ser inicializados
• Se identifican con un nombre
• Se corresponden con un tipo de elemento del modelo fuente
• Genera 1 o más tipos de elementos de modelo destino
• Especifica la forma en que los elementos del modelo destino
generado deben ser inicializado a partir de los elementos
correspondientes del modelo fuente

Definición de Matched rules
• Comienzan con la palabra clave rule que contiene:
• 2 Secciones obligatorias
• Sección de patrón fuente (from)
• Sección de patrón destino (to)
• 2 secciones opcionales
• Sección de variables locales (using)
• Sección imperativa (do)

Patrones fuente
• Se introducen luego de la palabra clave from
• Permite declarar una variable de elemento de modelo que se
corresponde con el tipo de elemento fuente que define la regla
• Este tipo se corresponde con una entidad definida en los meta-
modelos fuente de la transformación
• Significa que esta regla generará elemento destino para cada
elemento del modelo fuente que se corresponda con el tipo de
esta regla
• Para corresponderse con un subconjunto de los elementos, se
puede especificar una condición expresada como una ATL
Expression dentro del patrón de la regla fuente generando sólo
elementos destino que se correspondan con el tipo y la condición
especificada

Ejemplo from
rule Author {
from a : MMAuthor!Author
…}
rule Author {
from a : MMAuthor!Author (condición)
…}
MMAuthor MMPerson

Patrones destino
• Se introducen luego de la palabra clave to
• Permite especificar:
• Los elementos a generar cuando el patrón fuente de la regla se
cumple
• Cómo se generan los elementos
• Cómo se inicializan los elementos
• Un elemento del patrón fuente se corresponde con una
declaración de variable de un elemento de modelo asociada a
un conjunto de asociaciones de inicialización
• La declaración de la variable del elemento de modelo se
corresponde a una entidad de los meta-modelos destino de la
transformación

MMAuthor MMPerson
Ejemplo to
rule Author {
to p : MMPerson!Person ( name <- a.name, surname <- a.surname)
…}

Variables locales y sec. imperativa
• Sección de variables locales
• Se introducen con la palabra clave using
• Permiten declarar e inicializar variable locales
• Sólo visibles dentro de la regla
• Sección imperativa
• Se introduce con la palabra clave do
• Permite especificar algo de código imperativo que se ejecuta
luego de la inicialización de los elementos destino generados por
la regla

Ejemplo using
from
c : GeometricElement!Circle
using {
pi : Real = 3.14159;
area : Real = pi * c.radius.square()
…}
Ejemplo del do…
más adelante 

Ejemplo de una Matched Rule
rule Author {
from
a : MMAuthor!Author
to
p : MMPerson!Person (
name <- a.name,
surname <- a.surname
)
}
• No hay filtro (condición) => todas las clases fuente
• Único destino
• Notar que un elemento fuente NO debe ser correspondido por más
de UNA regla => diseño cuidadoso
• No se pueden generar valore primitivos

Las Called Rules
• Called Rules
• Proveen facilidades de programación imperativas
• Se pueden ver como un tipo particular de helper
• Se llaman explícitamente para ser ejecutadas
• Aceptan parámetros
• Sin embargo, pueden generar elementos del modelo destino (los
helpers no)
• Pueden ser llamadas desde
• Una sección de código imperativo
• Una Matched Rule
• Otra rule

Las Called Rules
• Al igual que las Matched Rules, se introducen con la palabra clave rule
• Pueden incluir una sección de variables locales
• No definen patrones de modelos fuente
• La definición de un patrón destino es opcional
• Notar que como no definen elementos de modelo fuente, la
inicialización de los elementos destino generados por el patrón destino
tiene que basarse en una combinación de variables locales, parámetros
y atributos del módulo.
• El patrón destino se define de la misma forma que se define para una
Matched Rule.
• Se introduce con la palabra clave to
• Pueden tener una sección imperativa similar a la de las Matched Rules
(opcional).
• Se pueden definir Called Rules que sólo tengan patrones destino, ó
secciones imperativas.

Ejemplo de Called Rule
do {thisModule.id = 0;}
rule Author2Person {
from
a : MMAuthor!Author
to
name <- a.name,
father <- thisModule.NewFather(a.surname)
)
}
rule NewFather(sname:String) {
to p : MMPerson!Person (surname <- sname,
gender<-Gender::Male)
do {id <- thisModule.id; thisModule.id <- thisModule.id + 1;}
}

Las Lazy Rules
• Lazy Rules
• Son como las Matched Rules pero solamente se llaman desde otras reglas
rule Author2Person {
from
a : MMAuthor!Author
to
name <- a.name,
father <- thisModule.NewFather(a)
)
}
lazy rule NewFather{
to p : MMPerson!Person (name <- a.surname)
do {id <- thisModule.id; thisModule.id <- thisModule.id + 1;}
}

Los Helpers
• Son funciones de ayuda o soporte
• Permiten factorizar el código
• Pueden ser llamados desde diferentes puntos de una
transformación ATL
• Están definidos por los siguientes elementos:
• Nombre: Nombre de la función
• Tipo de contexto: Define el contexto en el cual se define el
atributo (de la misma forma en que un método se define en el
contexto de una clase en OO)
• Valor de retorno: En ATL cada helper debe devolver un valor
• Expresión ATL: Representa el código del ATL helper
• Conjunto opcional de parámetros: cada parámetro se define por
un par (nombre del parámetro: tipo del parámetro)

Los helpers
• Ejemplos:
• helper context Integer def : max(x : Integer) : Integer = ...;
• Completo
• helper context Integer def : double() : Integer = self * 2;
• Sin parámetros
• helper def : max(x1 : Integer, x2 : Integer) : Integer = ...;
• Contexto por omisión (el Módulo)
• Pueden existir helpers con el mismo nombre, pero con
distintas firmas
• Se pueden definir atributos (helpers sin parámetros)
• Tanto a nivel de módulo como de elemento
• Ejemplo de atributo
• helper context Integer def : double : Integer = self * 2;

Los helpers
• Diferencia entre atributo y función sin parámetros
• Una función se recalcula cada vez que se invoca
• Un atributo se calcula sólo la primera vez que se utiliza =>
atributo + eficiente
• Notar que un atributo definido en un módulo se ejecuta durante
la fase de inicialización => el orden tiene importancia

Modos de ejecución de módulos
• ATL define dos modos de ejecución:
1. Normal
2. Refinamiento
• El modo normal
• El desarrollador tiene que especificar explícitamente la forma en que los
elementos del modelo destino se general a partir de los elementos del modelo
fuente
• En este modo, cuando la transformación sólo tiene que hacer unas pocas
modificaciones en el modelo fuente para generar el modelo destino => mucho
trabajo
• El diseño de este tipo de transformación no solo implica la generación de reglas
que modifican los elementos, sino también las que no lo hacen
• El modelo de refinamiento
• Facilita la programación de las transformaciones entre modelos fuente y destino
similares
• El desarrollador sólo se enfoca en el código de los elementos modificados, los
otros elementos se copian del fuente al destino de forma implícita
• Sólo funciona con UN modelo fuente y UN modelo destino

Semántica de ejecución
• Aunque no es necesario introducir la semántica para crear las reglas, es útil para
debugging.
• En el modo normal => 3 fases:
1. Fase de inicialización de módulos
2. Fase de correspondencia de los elementos del modelo fuente
3. Fase de inicialización de elementos del modelo destino
• Fase de inicialización de módulos
• Se inicializan los atributos definidos en el contexto del módulo de transformación
• Notar que la inicialización de estos atributos puede utilizar atributos definidos en el contexto de
los elementos del modelo fuente = nuevos atributos inicializados
• Ejecución Entry points y Called rules
• Fase de correspondencia de elementos del modelo fuente
• Se prueban las condiciones de las matching rules con los elementos del modelo fuente.
• Cuando se cumple la condición, ATL crea los elementos del modelo destino que se
corresponden en el patrón destino de la regla. Notar que sólo se crean, no se inicializan.
• Fase de inicialización de elementos del modelo destino
• … creados en la etapa anterior
• Se inicializan los elementos ejecutando el código de los enlaces asociados en los
elementos del patrón destino
• Ésta fase permite la invocación de resolveTemp() definida en el contexto del modulo ATL.
• Se ejecuta la sección de código imperativo en la regla (UNA VEZ)

ATL Query
• Es una transformación de un modelo a un tipo primitivo.
• Sirve para la generación de salida textual
• Tipos soportados: Strings, Boolean y numeros
• Estructura
• Sección import (opcional) Importar librerías
• Definición query (Instantiation) Especifica el resultado de la
operación. Ej. query query_name = exp;
• Puede incluir helpers, atributos a nivel de query.
• Semántica de ejecución
• Inicialización de atributos
• Computación del resultado

ATL Library
• Permiten definir conjuntos de ATL helpers que pueden ser
llamados de otras ATL units (modules, queries y libraries)
• Pueden incluir una sección import opcional
• Definen helpers
• No existe elemento por misión => no se pueden declarar
helpers en el contexto por omisión del módulo => siempre hay
que asociarles un contexto
• No se pueden ejecutar independientemente
• No se asocian a ningún paso de inicialización
• => no se pueden definir atributos

Referencias
1. ATL User Guide: Overview of Atlas Transformation Language.
http://wiki.eclipse.org/ATL/User_Guide_-
_Overview_of_the_Atlas_Transformation_Language.
2. ATL User Guide: The ATL Language.
http://wiki.eclipse.org/ATL/User_Guide_-
_The_ATL_Language

ATL Arquitecturas dirigidas por modelos

Recomendados

Recomendados

Más contenido relacionado

Similar a ATL Arquitecturas dirigidas por modelos

Similar a ATL Arquitecturas dirigidas por modelos (20)

Último

Último (7)

ATL Arquitecturas dirigidas por modelos