Arquitectura de software dirigida por modelos (Model-Driven Architecture)

1
Arquitectura de software dirigida por
modelos(Model-Driven Architecture)

• Liliana Favre
• UNCPBA
• 2006

2
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.

3
Modelos y MDA

• Distingue diferentes tipos de modelos
• CIM (Computation Independent Model)
• PIM (Platform Independent Model)
• PSM (Platform Specific Model)
• ISM (Implementation Specific Model)

4
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.

5
Transformaciones y MDA
6
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)

7
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.

8
Ingeniería directa, inversa y reingeniería
9

• REFACTORING DE MODELOS

10
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.

11
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.

12
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,

13
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.

14
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

15
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.
16
Refactoring y MDD
Refactoring Refinamiento
PIM
PIM
PSM-C
PSM-EJB
PSM-C
PSM-EJB
C
Java
Java
C
17
Refactorings basados en MDA

• Ejemplos de refactorings a nivel de PIMs

Promoción de asociación (Evans)
Agregado de una asociación transitiva (Whittle)
18
Refactorings basados en MDA

• Ejemplos de refactorings a nivel de PSMs

Factorización de clases
19
Refactorings basados en MDA

• Ejemplos de refactorings a nivel de ISMs

Reemplazar Temp con Query (Fowler)
20
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.

21
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.

22
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.
23
Especificación de Transformaciones como contratos
OCL

• Transformation transformation-name
• parameters ltparameter-list gt
• local operations ltOCLExpression-listgt
• preconditions
• lt OCLExpression gt
• postconditions
• lt OCLExpression gt

24
Refactoring a nivel de PIM Ejemplo Extract
Composite
25
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)

26
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.

27
Refactoring Extract Composite

• Diagrama de clases del Metamodelo UML

28
Refactoring Extract Composite
Metamodelo fuente
29
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) ))))

30
Refactoring Extract Composite

• Metamodelo destino

31
Refactoring Extract Composite

• Restricciones del metamodelo destino
• context AssEndComposite inv
• self.aggregation shared or
• self.aggregation composite

32
Refactoring Extract CompositeRegla de
Transformación
Transformation Extract Composite
parameters source Extract Composite Source
Metamodel Package target Extract Composite
Target Metamodel Package local
operations OperationisEquivalentTo ( op
Operation) Boolean
postconditions post -- Para
cada clase en el paquete source, source.ownedMemb
er.oclIsKindOf(Class) ? forAll ( sourceClass
-- existirá una clase en el paquete target tal
que target.ownedMember.oclIsKindOf(Class) ?
exists ( targetClass
33
Refactoring Extract CompositeRegla de
Transformación
-- si el tipo de sourceClass es Component,
if ( sourceClass.oclIsTypeOf(Component) ) then
-- el tipo de targetClass es Component, targetC
lass.oclIsTypeOf(Component) and -- targetClass
tiene una generalización Component-Composite, tar
getClass.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.leafSpecializatio
n.child sourceClass.leafSpecialization.child

34
Refactoring Extract CompositeRegla 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.n
ame sourceClass.name and
35
Refactoring Extract CompositeRegla de
Transformación
-- Para cada operación equivalente de las clases
Composite en source sourceClass.ownedOperation ?
forAll( op (source.ownedMember.oclIsTypeOf(
Composite) ?excluding(sourceClass)).ownedOp
eration ? forAll ( o if o.isEquivalentTo(op)
then -- en target existirá una operación
equivalente en la superclase de
-- targetClass,
targetClass.generalization.general.oclIsTypeOf(Com
posite). 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 ))
36
Refactoring Extract CompositeRegla 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
37
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)
• MDA The Model Driven Architecture
  www.omg.org/mda, 2006
• OCL Object Constraint Language. Version 2.0. OMG
  Available Specification formal/06-05-01.
  Availablewww.omg.org
• UML UML 2.0 Superstructure Specification. OMG
  formal/05-07-04 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 ltltUML 2002gtgt-The Unified
  Modeling Language. Lecture Notes in Computer
  Science 2460 (eds. J. Jezequel H. Hussman)
  Springer-Verlag, 227-241.