Arquitectura de software
dirigida por modelos
(Model-Driven Architecture)
Liliana Favre
UNCPBA
2006
Model-Driven Architecture (MDA)
La MDA es un framework para el desarrollo de software
donde los modelos son la base en el proceso de desarrollo
de software.
Ideas centrales:
 Separar la especificación de la funcionalidad del
sistema de su implementación sobre una plataforma en
una tecnología específica.

Controlar la evolución desde modelos abstractos a
implementaciones tendiendo a aumentar el grado de
automatización.
Modelos y MDA
Distingue diferentes tipos de modelos:

CIM (Computation Independent Model)

PIM (Platform Independent Model)

PSM (Platform Specific Model)

ISM (Implementation Specific Model)
Transformaciones y MDA

Una transformación es el proceso de generar
un nuevo modelo (destino) a partir de otro
(origen).

El proceso se describe por medio de una
definición de transformación, la cual consiste
en un conjunto de reglas de transformación
que se ejecutan por medio de una herramienta.
Transformaciones y MDA
Transformaciones y MDA
Evolución de modelos


Refinamientos: permiten construir una especificación más
específica a partir de una más abstracta

Verticales (PIM a PSM, PSM a ISM)

Horizontales ( PIM a PIM, PSM a PSM)
Refactorings: permiten transformar modelos en un
determinado nivel sin cambiar su funcionalidad, pero
mejorando algunos factores de calidad no funcionales
(PIM a PIM, PSM a PSM)
Model-driven Development (MDD)
Un desarrollo MDD distingue al menos las siguientes
etapas:

Construir un PIM en un alto nivel de abstracción,
independiente de una tecnología específica.

Transformar al PIM en uno o más modelos
dependientes de una plataforma específica,
denominados PSM. Por ejemplo, relacional, J2EE,
.NET

Transformar los PSM a código.
Ingeniería directa, inversa y reingeniería
REFACTORING DE MODELOS
REFACTORING

Reestructuración de software:
Es el proceso de transformar una representación en
otra en el mismo nivel de abstracción, preservando
el comportamiento externo del sistema.

Refactoring:
Es el proceso de reestructuración en un contexto
orientado a objetos.
REFACTORING: Definición
(Fowler)

Refactoring (sustantivo): un cambio en la estructura
interna del software para hacerlo más fácil de entender
y menos costoso de modificar sin cambiar el
comportamiento observable del sistema.

Refactoring (verbo): es la reestructuración de software
mediante la aplicación de una serie de refactorings sin
cambiar el comportamiento observable del sistema.
REFACTORING: Características

trata de la estructura interna del software,

preserva el comportamiento observable,

mejora una situación dada de acuerdo a un
objetivo,

los pasos de refactoring son pequeños y pueden
ser combinados sistemáticamente en secuencias
más poderosas,
REFACTORING: Características

es una técnica constructiva basada en reglas,

es aplicado por desarrolladores de software,

la corrección de la aplicación de las reglas de
refactoring es responsabilidad del desarrollador.
REFACTORING: Ventajas

Mejora el diseño del software

Mejora el entendimiento del software

Ayuda a encontrar errores

Ayuda a desarrollar código más rápidamente
REFACTORING DE MODELOS
Es el proceso de reestructurar un modelo orientado
a
objetos
aplicando
una
secuencia
de
transformaciones que preservan la funcionalidad
del mismo a fin de mejorar alguna métrica.
Refactoring y MDD
Refactoring
PIM’
PIM
Refinamiento
PSM-C++
PSM-EJB
PSM’-C++
PSM’-EJB
C++
Java
Java’
C++’
Refactorings basados en MDA
Ejemplos de refactorings a nivel de PIMs
Promoción de asociación (Evans)
C
R
A
C
0 ..1
R
A
1
1
1
B
B
Agregado de una asociación transitiva (Whittle)
B
A
B
C
A
C
Refactorings basados en MDA
Ejemplos de refactorings a nivel de PSMs
Factorización de clases
C
A
B
A'
B'
Refactorings basados en MDA
Ejemplos de refactorings a nivel de ISMs
Reemplazar Temp con Query (Fowler)
d o ub le b a se P ric e = q ua ntity*ite m P ric e ;
if (b a se P ric e > 1 0 0 0 )
re turn b a se P ric e * 0 .9 5 ;
e lse
re turn b a se P ric e * 0 .9 8 ;
m e th o d ()
d o ub le b a se P ric e () {
re turn q ua ntity*ite m P ric e ; }
if (b a se P ric e () > 1 0 0 0 )
re turn b a se P ric e () * 0 .9 5 ;
e lse
re turn b a se P ric e () * 0 .9 8 ;
b a s e P ric e ()
m e th o d ()
Especificación de Transformaciones
basada en Metamodelos
Un metamodelo describe un modelo a través de sus

metaclases, donde cada una de ellas define un
elemento que pueden existir en el modelo.

relaciones entre metaclases que especifican las
interrelaciones que deben existir entre los
elementos de los modelos.
Especificación de Transformaciones
basada en Metamodelos

la transformación se especifica relacionando los
elementos del modelo fuente y los elementos
del modelo destino a nivel de metamodelo,

es decir, relacionando la metaclase del elemento
del modelo fuente con la/s metaclase/s de los
elementos del modelo destino.
Especificación de Transformaciones
basada en Metamodelos
M: modelo fuente UML/OCL.
M’: modelo destino UML/OCL.
T: Transformación de modelos basada en reglas y estrategias.
T’: Especificación de transformación basada en reglas a nivel de metamodelo.
Especificación de Transformaciones
como contratos OCL
Transformation transformation-name{
parameters <parameter-list >
local operations <OCLExpression-list>
preconditions
< OCLExpression >
postconditions
< OCLExpression >
}
Refactoring a nivel de PIM
Ejemplo: Extract Composite
Refactoring a nivel de PIM
Ejemplo: Extract Composite
Extrae una superclase que implementa el Composite
cuando subclases en una jerarquía implementan el
mismo Composite. (Kerievsky)
P
P
.........
A
.........
C
B
A
B
Refactoring: Extract Composite
La especificación del refactoring se basa en:
 Metamodelo origen: describe los modelos a los
cuales puede aplicarse el refactoring Extract
Composite.
 Metamodelo destino: describe los modelos
generados por la aplicación del refactoring.
Ambos metamodelos son especializaciones del
metamodelo UML con restricciones OCL.
Refactoring: Extract Composite
Diagrama de clases del Metamodelo UML :
+general
Classifier
1
+specific
Generalization
1
Classifier
Relationship
+generalization
*
+ownedAttribute
Class
0..1
Property
+memberEnd
+association
2..*
*
Association
0..1
+navigableOwnedEnd
*
+/superClass
0..1
*
+class
*
+ownedOperation
Operation
+ownedEnd
0..1
+/opposite
*
+owningAssociation
0..1
+/endType
StructuralFeature
1..*
Type
Refactoring: Extract Composite
Metamodelo fuente:
Component-Leaf-Generalization
Component-Composite-Generalization
1 +component
{subsets
generalization} Generalization
+child
{redefines
specific}
1
1..*
+composite
2..*
Specialization
+parent
{redefines
general} 1
Generalization
(from Kernel)
Composite
+participant
1
+associationEnd
1
AssEndComposite
+parent
{redefines
general}
Class
(from Kernel)
+association 1
Composite-Com ponent-Assoc
+child
{redefines
specific}
1
+participant
1
+associationEnd
2..*
Property
(from Kernel)
+component 1
{subsets
Generalization generalization}
Leaf
Component
1
{redefines association}
1
+leaf
Specialization
Class
(from Kernel)
AssEndComponent
1
1 +association
{redefines association}
Association
(from Kernel)
Refactoring: Extract Composite
Restricciones del metamodelo fuente:
context Component inv:
self.associationEnd.association  forAll ( a1, a2 |
a1 = a2
or
a1.isEquivalentTo(a2) )
context Component inv:
-- Para cada clase Composite existe una operación
self.compositeSpecialization.child  forAll ( class |
class.ownedOperation  exists ( op |
-- equivalente a operaciones de las otras clases Composite
self.compositeSpecialization.child  excluding (class) 
forAll ( c |c.ownedOperation  exists ( o | op.isEquivalentTo(o)
))))
Refactoring: Extract Composite
Metamodelo destino:
Component-Leaf-Generalization
Component-Composite-Generalization
1 +component
{subsets
generalization} Generalization
+child
{redefines
specific}
1
+composite
1
Specialization
+parent
{redefines
general} 1
1..* +leaf
Specialization
Generalization
(from Kernel)
Composite
+participant
1
+associationEnd
1
AssEndComposite
Class
(from Kernel)
Property
(from Kernel)
+association 1
Composite-Component-Assoc
+child
{redefines
specific}
1
Leaf
Component
1
{redefines association}
+parent
{redefines
1 general}
+component 1 {subsets
Generalization generalization}
+participant
1
+associationEnd
1
AssEndComponent
Class
(from Kernel)
1
1 +association
{redefines association}
Association
(from Kernel)
Refactoring: Extract Composite
Restricciones del metamodelo destino:
context AssEndComposite inv:
self.aggregation = #shared or
self.aggregation = #composite
Refactoring: Extract Composite
Regla de Transformación
Transformation Extract Composite {
parameters
source: Extract Composite Source Metamodel:: Package
target: Extract Composite Target Metamodel:: Package
local operations
Operation::isEquivalentTo ( op: Operation): Boolean;
…
postconditions
post
-- Para cada clase en el paquete source,
source.ownedMember.oclIsKindOf(Class)  forAll ( sourceClass |
-- existirá una clase en el paquete target tal que
target.ownedMember.oclIsKindOf(Class)  exists ( targetClass |
Refactoring: Extract Composite
Regla de Transformación
-- si el tipo de sourceClass es Component,
if ( sourceClass.oclIsTypeOf(Component) ) then
-- el tipo de targetClass es Component,
targetClass.oclIsTypeOf(Component) and
-- targetClass tiene una generalización Component-Composite,
targetClass.compositeSpecialization  size() =1 and
-- targetClass tiene un extremo de asociación que se asocia con
-- Composite,
targetClass.associationEnd  size() =1 and
-- targetClass y sourceClass tiene las mismas clases Leaf,
targetClass.leafSpecialization.child = sourceClass.leafSpecialization.child
…
Refactoring: Extract Composite
Regla de Transformación
-- si el tipo de sourceClass es Composite,
else if ( sourceClass.oclIsTypeOf(Composite) ) then
-- la clase Composite es superclase de targetClass,
targetClass.generalization.general includes(Composite)
and
-- targetClass y sourceClass tienen el mismo nombre,
targetClass.name = sourceClass.name and
…
Refactoring: Extract Composite
Regla de Transformación
-- Para cada operación equivalente de las clases Composite en source
sourceClass.ownedOperation  forAll( op |
(source.ownedMember.oclIsTypeOf(Composite)
excluding(sourceClass)).ownedOperation  forAll ( o |
if o.isEquivalentTo(op) then
-- en target existirá una operación equivalente en la superclase de
-- targetClass,
targetClass.generalization.general.oclIsTypeOf(Composite).
ownedOperation exists ( targetOp |op.isEquivalentTo (targetOp) )
and
targetClass.ownedOperation  excludes(op)
else – en caso contrario, la operación es de targetClass.
targetClass.ownedOperation  includes(op)
endif ))
Refactoring: Extract Composite
Regla de Transformación
else
-- si sourceClass es cliente de alguna clase Composite en el
-- paquete source, targetClass será cliente de la clase
-- Composite en el paquete target.
…
endif
endif
}
Bibliografía

Evans, A.: Reasoning with UML Class Diagrams. In: Proceedings of 2nd Workshop on
Industrial Strength Formal Specification Techniques (1998)

Fowler, M. Refactoring: Improving the Design of Existing Programs. Addison-Wesley
(1999)



Kerievsky, J. Refactoring to Patterns. Addison-Wesley (2004)



UML: UML 2.0 Superstructure Specification. OMG formal/05-07-04 www.omg.org
MDA: The Model Driven Architecture www.omg.org/mda, 2006
OCL: Object Constraint Language. Version 2.0. OMG Available Specification:
formal/06-05-01. Available:www.omg.org
UML: UML 2.0 Infrastructure Specification. OMG formal/05-07-04 www.omg.org
Whittle, J. (2002). Transformations and Software Modeling Languages: Automating
Transformations.in UML. Proceedings of <<UML 2002>>-The Unified Modeling
Language. Lecture Notes in Computer Science 2460 (eds. J. Jezequel; H. Hussman)
Springer-Verlag, 227-241.
Descargar

Arquitectura de software dirigida por modelos