Arquitectura de software dirigida por modelos



Descargar 422,5 Kb.
Fecha de conversión25.04.2017
Tamaño422,5 Kb.

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

  • PIM
  • PIM’
  • PSM-C++
  • PSM’-C++
  • PSM’-EJB
  • PSM-EJB
  • Java’
  • Java
  • C++’
  • C++
  • Refactoring
  • Refinamiento

Refactorings basados en MDA

  • Ejemplos de refactorings a nivel de PIMs
  • Promoción de asociación (Evans)
  • Agregado de una asociación transitiva (Whittle)

Refactorings basados en MDA

  • Factorización de clases

Refactorings basados en MDA

  • Ejemplos de refactorings a nivel de ISMs
  • Reemplazar Temp con Query (Fowler)

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
  • 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)

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 :

Refactoring: Extract Composite

  • Metamodelo fuente:

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:

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)
  • 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 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 <>-The Unified Modeling Language. Lecture Notes in Computer Science 2460 (eds. J. Jezequel; H. Hussman) Springer-Verlag, 227-241.



Compartir con tus amigos:


La base de datos está protegida por derechos de autor ©absta.info 2019
enviar mensaje

    Página principal