Arquitectura de software dirigida por modelos ModelDriven Architecture

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: n Separar la especificación de la funcionalidad del sistema de su implementación sobre una plataforma en una tecnología específica. n 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: n CIM (Computation Independent Model) n PIM (Platform Independent Model) n PSM (Platform Specific Model) n ISM (Implementation Specific Model)

Transformaciones y MDA n Una transformación es el proceso de generar un nuevo modelo (destino) a partir de otro (origen). n 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 n n Refinamientos: permiten construir una especificación más específica a partir de una más abstracta n Verticales (PIM a PSM, PSM a ISM) n 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: n Construir un PIM en un alto nivel de abstracción, independiente de una tecnología específica. n Transformar al PIM en uno o más modelos dependientes de una plataforma específica, denominados PSM. Por ejemplo, relacional, J 2 EE, . NET n Transformar los PSM a código.

Ingeniería directa, inversa y reingeniería

REFACTORING DE MODELOS

REFACTORING n 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. n Refactoring: Es el proceso de reestructuración en un contexto orientado a objetos.

REFACTORING: Definición (Fowler) n 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. n 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 n trata de la estructura interna del software, n preserva el comportamiento observable, n mejora una situación dada de acuerdo a un objetivo, n los pasos de refactoring son pequeños y pueden ser combinados sistemáticamente en secuencias más poderosas,

REFACTORING: Características n es una técnica constructiva basada en reglas, n es aplicado por desarrolladores de software, n la corrección de la aplicación de las reglas de refactoring es responsabilidad del desarrollador.

REFACTORING: Ventajas n Mejora el diseño del software n Mejora el entendimiento del software n Ayuda a encontrar errores n 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’ C++’

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 Ejemplos de refactorings a nivel de PSMs 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 n metaclases, donde cada una de ellas define un elemento que pueden existir en el modelo. n relaciones entre metaclases que especifican las interrelaciones que deben existir entre los elementos de los modelos.

Especificación de Transformaciones basada en Metamodelos n la transformación se especifica relacionando los elementos del modelo fuente y los elementos del modelo destino a nivel de metamodelo, n 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)

Refactoring: Extract Composite La especificación del refactoring se basa en: n Metamodelo origen: describe los modelos a los cuales puede aplicarse el refactoring Extract Composite. n 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. association. End. association for. All ( a 1, a 2 | a 1 = a 2 or a 1. is. Equivalent. To(a 2) ) context Component inv: -- Para cada clase Composite existe una operación self. composite. Specialization. child for. All ( class | class. owned. Operation exists ( op | -- equivalente a operaciones de las otras clases Composite self. composite. Specialization. child excluding (class) for. All ( c |c. owned. Operation exists ( o | op. is. Equivalent. To(o) ))))

Refactoring: Extract Composite Metamodelo destino:

Refactoring: Extract Composite Restricciones del metamodelo destino: context Ass. End. Composite 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: : is. Equivalent. To ( op: Operation): Boolean; … postconditions post -- Para cada clase en el paquete source, source. owned. Member. ocl. Is. Kind. Of(Class) for. All ( source. Class | -- existirá una clase en el paquete target tal que target. owned. Member. ocl. Is. Kind. Of(Class) exists ( target. Class |

Refactoring: Extract Composite Regla de Transformación -- si el tipo de source. Class es Component, if ( source. Class. ocl. Is. Type. Of(Component) ) then -- el tipo de target. Class es Component, target. Class. ocl. Is. Type. Of(Component) and -- target. Class tiene una generalización Component-Composite, target. Class. composite. Specialization size() =1 and -- target. Class tiene un extremo de asociación que se asocia con -- Composite, target. Class. association. End size() =1 and -- target. Class y source. Class tiene las mismas clases Leaf, target. Class. leaf. Specialization. child = source. Class. leaf. Specialization. child …

Refactoring: Extract Composite Regla de Transformación -- si el tipo de source. Class es Composite, else if ( source. Class. ocl. Is. Type. Of(Composite) ) then -- la clase Composite es superclase de target. Class, target. Class. generalization. general includes(Composite) and -- target. Class y source. Class tienen el mismo nombre, target. Class. name = source. Class. name and …

Refactoring: Extract Composite Regla de Transformación -- Para cada operación equivalente de las clases Composite en source. Class. owned. Operation for. All( op | (source. owned. Member. ocl. Is. Type. Of(Composite) excluding(source. Class)). owned. Operation for. All ( o | if o. is. Equivalent. To(op) then -- en target existirá una operación equivalente en la superclase de -- target. Class, target. Class. generalization. general. ocl. Is. Type. Of(Composite). owned. Operation exists ( target. Op |op. is. Equivalent. To (target. Op) ) and target. Class. owned. Operation excludes(op) else – en caso contrario, la operación es de target. Class. owned. Operation includes(op) endif ))

Refactoring: Extract Composite Regla de Transformación else -- si source. Class es cliente de alguna clase Composite en el -- paquete source, target. Class será cliente de la clase -- Composite en el paquete target. … endif }

Bibliografía n Evans, A. : Reasoning with UML Class Diagrams. In: Proceedings of 2 nd Workshop on Industrial Strength Formal Specification Techniques (1998) n Fowler, M. Refactoring: Improving the Design of Existing Programs. Addison-Wesley (1999) n n n Kerievsky, J. Refactoring to Patterns. Addison-Wesley (2004) n n n 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.