UNIVERSIDAD DE COLIMA

Transcripción

1 UNIVERSIDAD DE COLIMA FACULTAD DE TELEMÁTICA MODELADO DE SISTEMAS SOFTWARE BASADO EN MDE (Caso: SISTEMAS EXPERTOS DE DIAGNÓSTICO) TESIS PARA OBTENER EL GRADO DE MAESTRO EN COMPUTACIÓN PRESENTA: Saúl Iván Beristain Petriz ASESORES: D. en C. María Eugenia Cabello Espinosa D. en C. Jorge Rafael Gutiérrez Pulido COLIMA, COL., JUNIO 2011

2 Dedicatoria -Mamá: Porecharme porras, ayudarme, regañarme y motivarme. Sin su apoyo nunca hubiera empezado ni terminado este trabajo. GRACIAS MAMÁ. -Raúl: Que con sus burlas y comentarios graciosos me alegraba el rato en los momentos de estress y que a pesar de que lo molesté en varias ocasiones con el uso de su laptop nunca me reclamó nada. -Maestra Maru: Que como asesora y tutora nunca faltó aún en contra de muchas adversidades, siempre al pendiente de mis avances y de mis errores. Sin lugar a dudas fui la envidia del resto de mis compañeros de generación. Mejor maestra, asesora y tutora no pude haber tenido. -Maestro Rogelio: Que no escatimó en tiempo ni en distancia para asesorarme durante el transcurso de esta tesis. -Bere: Que en los momentos en que bajaba el ritmo de este trabajo siempre me recordaba que tenía que terminar.

3 Resumen Esta tesis presenta una propuesta para la transformación de modelos, especificamente del modelo modular al modelo de componentes y conectores. La propuesta utiliza técnicas de Líneas de Productos Software y varios estándares de la OMG que contemplan al paradigma de la Ingeniería Dirigida por Modelos. Para ilustrar la propuesta se ha elegido el dominio de los Sistemas Expertos que realizan tarea de diagnóstico.

4 Abstract This thesis presents a proposal for the transformation of models, specifically modularmodel to components and connectors model. The proposal uses techniques of Software Product Lines and several OMG standards that provide the paradigm of Model Driven Engineering. To illustrate the proposal has been chosen the domain of expert systems performing diagnostic task.

5 Índice Listado de Figuras... ix Listado de Tablas... xiii 1 INTRODUCCIÓN Planteamiento del problema y justificación del trabajo Hipótesis y objetivos de la tesis Hipótesis Objetivos Objetivo general Objetivos específicos Estructura de la tesis ESTADO DEL ARTE Trabajos relacionados Aproximación BOM-Lazy Fundamentos Ingeniería dirigida por modelos (MDE) Arquitectura dirigida por modelos (MDA) Modelos en MDA Modelo Transformación de modelos Query View Transformations (QVT) Facilidad para Meta-Objetos (MOF) Metamodelos Metamodelo modular Metamodelo de componentes y conectores El Componente El Conector Lenguaje Unificado de Modelado (UML) Diagrama de clases... 42

6 Diagrama de secuencias Lenguaje de Marcas Generalizado (XML) XML de Intercambio de Metadatos (XMI) Ventajas de XMI Líneas de Productos Software (SPL) Variabilidad en las Líneas de Productos Software Modelo de Características UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS Introducción Proceso de transformación del modelo modular al modelo de componentesconectores-comportamiento Especificación de los Metamodelos Especificación del Metamodelo de Características Especificando el Metamodelo Modular Especificando el Metamodelo de Componentes y Conectores Relaciones entre el Metamodelo Modular y el Metamodelo de Componentes- Conectores Identificando relaciones de correspondencia Especificando relaciones de correspondencia Diseño de los modelos El dominio: los Sistemas Expertos de Diagnóstico Modelo de interacción de los elementos de lossistemas Expertos de Diagnóstico Modelo de Características de los Sistemas Expertos de Diagnóstico (modelo de variabilidad) Modelo Modular de los Sistemas Expertos de Diagnóstico Modelo Componente-Conector de un Sistemas Experto de Diagnóstico Patrones de diseño utilizados en el desarrollo de los modelos componenteconector de los DES Ejemplos del modelado C-C de un Sistemas Experto de Diagnóstico Ejemplo del modelado C-C de un Sistemas Experto de diagnóstico médico

7 Ejemplo del modelado C-C de un Sistemas Experto de diagnóstico de programas educativos Aplicando la transformación (del modelo modular a un modelo de componentes y conectores) IMPLEMENTACIÓN Herramientas utilizadas Costos Descripción del uso de las herramientas CONCLUSIONES ANEXOS Anexo A. Código de las QVT-Relations BIBLIOGRAFÍA

8

9 Listado de Figuras Figura 1. Plan de Producción BOM-Lazy Figura 2. Contexto histórico (Bézivin, 2003) Figura 3. Logotipo de MDA Figura 4. Ciclo de vida del desarrollo MDA Figura 5. Modelos y lenguajes.(kleppe, et al., 2003) Figura 6. Pasos en la transformación.(mellor, et al., 2004) Figura 7. Transformación definida entre distintos lenguajes.(kleppe, et al., 2003) Figura 8. Esquema de transformación con QVT (Gómez, 2009) Figura 9. Capas en MOF Figura 10. El icono de una clase Figura 11. Relación de Composición Figura 12. Relación de Herencia Figura 13. Diagrama de secuencias Figura 14. Integración de estándares Figura 15. Tipos de intercambios (OMG) Figura 16. Relación entre dominios y plataformas según OMG. (OMG, Especificación XMI 2.0) 49 Figura 17. Intercambio de objetos entre aplicaciones. (OMG, Especificación XMI 2.0) Figura 18. Validación de un archivo XMI Figura 19. Desarrollo de una SPL (figura adaptada de (Clements y Northrop, 2001) Figura 20. Actividades esenciales para SPL (SEI) Figura 21. Notación gráfica utilizada en el Modelo de Características clásico (Batory et al., 2006) Figura 22. Proceso de desarrollo de un sistema software esqueleto (mostrado en SPEM) Figura 23. Metafora visual de la transformaciondel modelo modular al modelo de C-C-C Figura 24. La transformación del modelo modular al de C-C, expresado en niveles de MOF Figura 25. Proceso para la trasformación Figura 26.Correspondencia entre metamodelo, modelo y sistema (Gasevic et al, 2006) Figura 27. Metamodelo de Características Figura 28. Metamodelo Modular Figura 29. Metamodelo de Componentes y Conectores Figura 30. Diagrama de la relación ModulesModel2ComponentsModel Figura 31. Diagrama de la relación UseCase2Connector Figura 32. Diagrama de la relación Module2Component... 83

10 Figura 33. Diagrama de la relación Module2RolePort Figura 34. Diagrama de la relación ConnectRoleAndPort Figura 35. Diagrama de la relación Function2service Figura 36. Diagrama de la relación Function2Relation Figura 37. Orden de relaciones Figura 38. Relación Module to Component Figura 39. Relación Uses to Connector Figura 40. Relación Module to Role&Port Figura 41. Relación Function to Service Figura 42. Relación Function to Relation Figura 43. Elementos básicos de un Sistema Experto Figura 44. Metáfora visual del razonamiento utilizado en elproceso de diagnóstico médico Figura 45. Diagrama de casos de uso de un diagnóstico médico Figura 46.Diagrama de secuencias del caso: diagnostico medico Figura 47. Modelo de Características Figura 48. Modelo Modular de un Sistema Experto Figura 49. Metáfora visual de (a) una única arquitectura genérica, y (b) dos arquitecturas base Figura 50. Metáfora visual de la función transformación Figura 51. Modelo arquitectónico correspondiente a un caso de uso Figura 52. Modelo arquitectónico correspondiente a la relación include entre dos casos de uso Figura 53. Diagrama UML-casos de uso para un sistema de diagnóstico médico Figura 54. Modelos arquitectónicos correspondientes a cada caso de uso Figura 55. Modelo arquitectónico caso diagnostico medico Figura 56. Diagrama de casos de uso correspondiente al diagnóstico de programas educativos Figura 57. Elementos arquitectónicos del modelo componentes y conectores Figura 58. Modelos que intervienen en la transformación Figura 59. Arquitectura de la herramienta generada a partir de la plataforma Eclipse Figura 60. Metáfora visual de la transformación con refinamiento Figura 61. Orden en el proceso de transformación Figura 62. Proceso de la transformación y su refinamiento expresado en SPEM Figura 63. Forma de uso de la plataforma Eclipse Figura 64. Tareas/actividades y productos de la transformación Figura 65. Especificando el Metamodelo de Características Figura 66. Especificando el Metamodelo Modular

11 Figura 67. Especificando el Metamodelo de Componentes y Conectores Figura 68. Obteniendo una instancia del modelo de caracteristicas Figura 69. Diseñando el Modelo Modular Figura 70. Estableciendo metamodelos para la transformación Figura 71. Codificando QVT Figura 72. Invocando modelos para la transformación Figura 73. Generando el Modelo de Componentes y Conectores (sin refinar) Figura 74. Metamodelo de Componentes y Conectores Figura 75. Metamodelo de Componentes y Conectores con Comportamiento Figura 76. Refinando (comportamiento/secuencia) el modelo resultante

12

13 Listado de Tablas Tabla 1.Procesos de Ingenieria del dominio y de Aplicacion Tabla 2.Descripción de las clases que pertenecen al Metamodelo Modular Tabla 3.Descripcion detallada de las clases que componen al metamodelo de componentes y conectores Tabla 4. Algunas relaciones identificadas entre el metamodelo modular, el metamodelo de características y el metamodelo C-C Tabla 5. Restricciones existentes entre variantes en el Modelo de Características Tabla 6. Reglas de transitividad en la restricción implies... 96

14

15

16

17 INTRODUCCIÓN 1 1 INTRODUCCIÓN 1.1 Planteamiento del problema y justificación del trabajo El desarrollo de sistemas software es cada vez más complejo debido a una serie de factores, como la aparición de nuevas tecnologías, la interconexión de varios sistemas y plataformas, la necesidad de integrar viejos sistemas aun válidos, la adaptación personalizada del software a cada tipo de usuario, las necesidades específicas de un sistema y las diferentes plataformas de implementación. Esteescenario lleva a necesitar, en cortos periodos, múltiples versiones de la misma o parecida aplicación. Por ello, la Ingeniería del Software debe proporcionar herramientas y métodos que permitan desarrollar una familia de productos con distintas capacidades y adaptables a situaciones variables, y no sólo un único producto. Esta situación provocó la creación de un diseño que puede ser compartido por todos los miembros de una familia de programas. De esta manera, un diseño hecho explícitamente para un producto, beneficia al software común y puede ser usado en diferentes productos, reduciendo los gastos generales y el tiempo para construir nuevos productos. Ante esta situación, surge el concepto de Líneas de Productos Software (del inglés Software Product Lines y siglas SPL),con la finalidad de controlar y minimizar los altos costos del desarrollo de software, así como los largos tiempos de producción. Uno de los elementos clave para una SPL es la representación y gestión de la variabilidad. Para captar la semántica de la variabilidad de un dominio específico, i.e. para plasmar las características comunes y variantes de una SPL mediante modelos que representen familias de sistemas software, se utiliza el denominado Modelo de Características. Este modelo es la representación clásica de la va-

18 2 CAPÍTULO 1 riabilidad en una SPLel cualpuede definirse como una jerarquía de características con variabilidad (K. Czarnecki, et al., 2006). Asimismo, la Ingeniería Dirigida por Modelos (del inglés Model Driven Engineering y siglas MDE) (Kent, 2002)y el enfoque de la Programación Generativa (Czarnecki y Eisenecker, 2000) proporcionan una base adecuada para apoyar el desarrollo de las SPL, facilitando el desarrollo de productos de software para diferentes plataformas y permitir su utilización en diferentes tecnologías. Pero este desarrollo de productos de software deberá hacerse bajo las técnicas ampliamente utilizadas durante el proceso de desarrollo de productos de toda la SPL, lo cual permite que el proceso sea correcto y adecuado. Además, para enfrentar la complejidad de los sistemas software, la Ingeniería de Software promueve la automatización del desarrollo del software y otros mecanismos. Sin embargo, la automatización de estos sistemas sólo es posible mediante un framework que soporte este proceso. Ante ésto, el Grupo Gestionador de Objetos (del inglés Object Management Group y siglas OMG) ( propone para la MDE: i) La Arquitectura Dirigida por Modelos (del inglés Model Driven Architecturey siglas MDA) ( la cual aboga el uso de estándares e independencia de plataforma en el proceso de desarrollo de software, como un nuevo método de producir aplicaciones; y ii) La Facilidad de Meta-Objetos (del inglés Meta Object Facilityy siglasmof) ( que identifica conceptos básicos como modelo, metamodelo y meta-metamodelo, y las relaciones entre ellos. Por otro lado, una clase de sistemas que está cobrando interés en los últimos tiempos son los Sistemas Expertos (del inglés Expert Systems y siglas ES)(Giarratano y Riley, 2004). Pero el desarrollo de este tipo de sistemas es complejo, dado que los elementos básicos que conforman su arquitectura varían tanto en su comportamiento como en su estructura (Cabello,2008). Por consiguiente, existe la necesidad de soportarlos adecuadamente. Las

19 INTRODUCCIÓN 3 metodologías y aplicaciones desarrolladas de los SEforman una amplia categoría de productos de investigación, ofreciendo ideas y soluciones a dichos sistemas en dominios específicos. Estos sistemas emulan el razonamiento humano para la solución ante un problema. Cabe señalar que es notable la importancia que han cobrado en los últimos años los SE que realizan tareas de diagnóstico(cabello, 2008). Por ello, para ilustrar la tesis, se ha elegido como dominio a los Sistemas Expertos de Diagnóstico (del inglés Diagnostic Expert Systems y siglas DES). Por todo lo anterior, en esta tesis se sigue el enfoque MDA, para poder generar código desde modelos (que capturan la variabilidad), utilizando programación generativa y técnicas de SPL. Explícitamente, se propone capturar la variabilidad de la SPLde los DES, en términos de un modelo de características.con la configuración de dicho modelo y la información del comportamiento de un sistema específico (mediante un diagrama de secuencias), se transforma un modelo modular en modelos de componentes y conectores. La transformación entre estos modelos es definida mediante mapeos, que se caracterizan por tener una correspondencia sintáctica y semántica entre sus respectivos metamodelos.para realizar dicha transformación de modelos será utilizado el lenguaje estándar de la OMG para la transformación de modelos, denominado Query/View/Transformations Relational (QVT-Relational) (OMG, 2001). 1.2 Hipótesis y objetivos de la tesis Hipótesis Con base en lo anteirormente descrito, la hipótesis planteada en esta tesis expresa que: Los sistemas software pueden modelarse aplicando estrategias de la Ingeniería Dirigida por Modelos

20 4 CAPÍTULO Objetivos Objetivo general El objetivo de esta tesis, derivada de la hipótesis es: Generar modelos de sistemas software (Sistemas Expertos de Diagnóstico), aplicando estrategias de la Ingeniería Dirigida por Modelos Objetivos específicos Para la realización del objetivo general se plantearon los siguientes objetivos específicos: Obtener el modelo de características que especifique la variabilidad de la SPL de los DES. Desarrollar el modelo modular que represente a los DES. Obtener el metamodelo de la variabilidad (metamodelo de características) y los metamodelos funcionales (metamodelo modular y metamodelo componente-conector) de los DES. Obtener las relaciones entre los metamodelos. Obtener (en tiempo de ejecución) las variantes de los puntos de variabilidad plasmadas en el modelo de caracterísitas, como instancias de dicho modelo. Implementar las QVT-Relations que permitan ejecutar la transformación del modelo modular al modelo de componente y conector. Diseñar los modelos de entrada (modelo modular, modelo de características, modelos de interacción) de la transformación, que permitirán generar otros modelos (modelos componente-conector). Obtener los modelos de componente-conector mediante transformaciones, acorde a las variantes de los puntos de variabilidad de la SPL de los DES (instancias del modelo de variabilidad) y del comportamiento de los DES (modelo de interacción).

21 INTRODUCCIÓN Estructura de la tesis La estructura de esta tesis está organizada de la siguiente manera: Capítulo 2.- Estado del arte Este capítulo presenta un panorama de las tendencias actuales más importantes en la Ingeniería de Software, relacionadas con la temática de la tesis,asi como los trabajos relacionados con los espacios tecnológicos utilizados para el desarrollo de esta tesis. Capítulo 3.- Una aproximación MDE para el modelado de sistemas software para la transformación de modelos En este capítulo se describe la propuesta para el modelado de sistemas software, basada en MDE, la cual utiliza técnicas de SPL y de transformación de modelos (especificamente del modelo modular al modelo de componentes y conectores)así como varios estándares de la OMG. Se describen, analizan y especifican los modelos y sus respectivos metamodelos y la relación entre ellos. Para mostrar la aproximacion MDE se eligió a los DES. Capítulo 4.- Implementación Este capítulo muestra la implementación de la propuesta plasmada en estatesis, a través de un prototipo realizado exprofeso para ello. Capítulo 5.- Conclusiones Las conclusiones derivadas de esta resis son presentadas en este capítulo. Asimismo son presentadas algunas ideas para trabajos de investigación a futuro.

22 6 CAPÍTULO 1 Apéndices Apéndice A.- En este apéndice se presenta completamente el código en QVT- Relations, utilizado para llevar a cabo la transformación de los modelos.

23 ESTADO DEL ARTE 7 2 ESTADO DEL ARTE 2.1 Trabajos relacionados Existen un gran número de trabajos relacionados con la aproximación presentada en esta tesis. Las metodologías y aplicaciones en esta temática han producido una amplia variedad de productos de investigación, ofreciendo sugerencias y soluciones en dominios específicos. En concreto, el trabajo de investigación de esta tesis tiene como puntos de partida los trabajos que se exponen a continuación. a) Las investigaciones realizadas por(liao, 2005): al examinar las metodologías de los SE y clasificarlos en once categorías. Dos de esas categorías corresponden a los sistemas basados en en el conocimiento. Esta categoría ha sido tomada en cuenta en esta tesis, al utilizar el conocimiento de los expertos que realizan tareas de diagnóstico. al expresar que las aplicaciones de los SE se desarrollan como sistemas orientados a un problema en un dominio específico. Esta tesis está enfocada al dominio del diagnóstico. al señalar que el desarrollo de los SE se caracteriza por separar el conocimiento de los procesos, como unidades independientes. En el modelo presentado en esta tesis, los elementos arquitectónicos son definidos tomado en cuenta este concepto, específicamente cuando se considera un componente que contiene el conocimiento del dominio de aplicación y otro componente distinto que ejecuta los procesos de inferencia para llevar a cabo el diagnóstico. b) Las investigaciones realizadas por (Giarratano y Riley, 2004) y otros autores, consideran que las arquitecturas de los SE están basadas en componentes. En esta tesis, la arquitectura genérica de la SPL (i.eel modelo modular de los SE)

24 8 CAPÍTULO 2 está conformada por módulos que se corresponden con los componentes mencionados por Giarratano. c) La detección de componentes basada en la descomposición funcional del problema, es decir del sistema, compatible con la metodología Architecture BaDES Design Method(Bachman, et al., 2000), propuesta por The Software Engineering Institute of The Carnegie Mellon University para diseñar arquitecturas software de un dominio de aplicación. Esta metodología ha sido aplicada para la construcción del modelo arquitectónico de los SE. d) El trabajo realizado por (Garlan, et al., 2001), como punto de referencia para establecer los elementos de un sistema software complejo, en el cual se introducen conceptos como componente, conector, sistema, puertos de entrada y de salida. Dichos conceptos han sido contemplados en el modelo de componentes y conectores de esta tesis. e) El concepto de contrato de (Andrade y Fiadeiro, 1999), ya que se han definido los conectores de los modelos arquitectónicos de la SPL como una extensión de dicho conceptof) La investigación realizada por (Limón, 2010) quien aplica transformación de modelos para generar un modelo arquitectónico (de vista de componentes-conectores) tomando otro modelo arquitectónico como referencia (el modelo de vista modular). El trabajo realizado en esta tesis, aplica la misma técnica de transformación de modelos pero con la diferencia de que la generación del modelo de vista componente-conectores considera varios modelos como referencia. g) Los trabajos que incorporan técnicas y metodologías de las SPL relacionadas con esta tesis. Entre ellos se encuentran :: i. (D Batory, et al., 2006),(Czarnecki y Kim, 2005) y (Gómez y Ramos, 2010) donde se expresan las características del dominio mediante un

25 ESTADO DEL ARTE 9 Modelo de Características. En esta tesis se han implementadolas características de los SED en un modelo de características. ii. (González-Baixauli y Laguna, 2005) aplican la propuesta de MDA y la Ingeniería de Requisitos para Líneas de Productos. En la tesis se ha utilizado técnicas de MDA para producir aplicaciones, así como contemplar los requisitos del usuario final para construir los elementos arquitectónicos de la SPL. i.e. los activos reutilizables. iii. (Clements y Northrop, 2001) que usan la aproximación de desarrollo de SPL, estableciendo una división entre la ingeniería del dominio y la ingeniería de la aplicación, para el reuso y la automatización de los procesos software. Así mismo, el método Kobra divide la ingeniería del dominio (para desarrollar la familia de productos, incluyendo identificación de componentes comunes y variables) de la ingeniería de la aplicación (para la derivación de un producto específico dentro de la familia). Esta aproximación es utilizada en esta tesispara desarrollar laspl en las fases de ingeniería del dominio e ingeniería de la aplicación. iv. (Ávila-García, et al., 2006) que desarrollaron un editor de SPEM para procesos de modelado, ofreciendo facilidades de creación y manipulación de SPL. En esta tesis se ha utilizado el estándar SPEM para modelar todo el proceso de desarrollo de la SPL. v. (Santos, et al., 2007) que propone el desarrollo de una técnica basada en MDA para gestionar la variabilidad en las SPL, tomando en cuenta el dominio específico. En esta tesis se aplicadicha técnica medianteun modelo conceptual (el modelo de características)utilizado para generar el software necesario, que captura las características del dominio como instancias de dicho modelo. vi. (Bachman, et al., 2003) que proponen la separación de la descripción de la variabilidad y de la funcionalidad de los artefactos afectados. En esta

26 10 CAPÍTULO 2 vii. viii. ix. tesis,la especificación de la variabilidad y de la funcionalidad se captan en modelos separados. (Gomma y Shin, 2007) utilizan un modelo de variabilidad semi-ortogonal donde la variabilidad es representada en una vista separada, pero los puntos de variabilidad y las variantes aparecen estereotipadas en diagramas UML. En esta tesis las vistas de la variabilidad y de la funcionalidad son tratadas separadamente, pero a diferencia de Gomma, las variantes están incorporadas en los modelos de variabilidad específicos. (Bosch, 2000) que describe tres dimensiones en las que se pueden descomponer los conceptos involucrados en las SPL. De esas tres, la que se corresponde con esta tesis es su primera dimensión, que considera un sistema como un conjunto de assets (activos reutilizables), formado por los sistemas construidos sobre la base de la arquitectura y componentes de la línea de productos. Esta actividad requiere la adaptación de la arquitectura de la línea de productos para ajustarse a la arquitectura de sistema, que puede requerir eliminar o añadir componentes o relaciones entre ellos, desarrollar extensiones a los componentes existentes, configurar los componentes y desarrollar elementos software específicos para el sistema. En esta tesis se parte de una arquitectura genérica que comparten las arquitecturas base de los DES. (Clements y Krueger, 2002), que propusieron la distinción de tres modelos de creación de SPL: el proactivo, el extractivo y el reactivo. Esta tesis se inclinó por el modelo reactivo, en el cual no se establece desde un principio el dominio en extenso de la línea de producto, sino que se irán incluyendo nuevos productos a medida que aparezca la necesidad de producirlos. Con esta técnica la creación de activos es más incremental y progresiva que con los otros modelos de adopción.

27 ESTADO DEL ARTE Aproximación BOM-Lazy La aproximación Baseline-Oriented Modeling-Lazy(Cabello, 2008), (Gómez, et al., 2010), cuyo acrónimo es BOM-Lazy, es un enfoque de la MDA para desarrollar aplicaciones basada en SPL, mediante técnicas de transformación de modelos. En BOM-Lazy las características observadas en el dominio, son consideradas como el primer grupo de variantes. Adicionalmente, se presenta un segundo grupo de variantes: la variabilidad que emerge de las propiedades del dominio de aplicación. Por lo tanto, la variabilidad está dirigida en dos etapas. La primera maneja la variabilidad usando el Modelo de la Variabilidad deldominio (del inglés Domain Variability Model y siglas DVM, ya sea Modelo de Características o cualquier otro modelo conceptual (por ejemplo, un Modelo Ontológico), el cual es utilizado para obtener una arquitectura base específica. La segunda etapa maneja la variabilidad de las propiedades utilizaun modelo de dominio de aplicación, con el cual se decora la arquitectura base con las características del dominio de la aplicación, conformando un modelo final de los DES. El Plan de Producción de una SPL, teniendo en cuenta la aproximación de BOM- Lazy, es mostrado en la figura 1, usando la notación SPEM ( La descripción del Plan de Producción se describe a continuación: El Plan de Producción inicia (tarea 1) cuando las características de la primera variabilidad (variabilidad del dominio), son obtenidas por el ingenierio de aplicación. A continuación (tarea 2), una arquitectura esqueleto (arquitectura base) se construye mediante la ejecución de una transformación QVT (primera transformación T1)a partir de las instancias del VDM y el modelo modular de la

28 12 CAPÍTULO 2 arquitectura genérica. De esta manera, el modelo modular se transforma en un modelo de componentes y conectores específico.acorde a la información del dominio. Por otro lado, el Modelo de la Variabilidad del Dominio de la Aplicación (del inglés Aplication Domain Variability Model y siglas ADVM) se utiliza para definir las características del dominio de aplicación (tarea 3). Las instancias de dicho modelo se utilizan para construir el modelo final (tarea 4) mediante la ejecución de otra transformación QVT (segunda transformación T2). De esta manera, el modelo de arquitectura base se transforma automáticamente en un modelo arquitectónico final, que incluye a las caracterísitcas del dominio de aplicación. Por último, este modelo arquitectónico se compila (tarea 5) utilizando un compilador de modelos (PRISMA-MODEL-COMPILER(Pérez, 2006)). Esta herramienta genera automáticamente el producto final de nuestra SPL: un programa C#.NET ejecutable y completamente funcional. El trabajo realizado en esta tesis consiste en implementar la primer transformación de la aproximación BOM-Lazy, con una mejora al generar las arquitecturas base (o arquitecturas esqueletos): tratar separadamente la funcionalidad de dichos sistemas. De esta forma, la qrquitectura softwrae se genera mediante un modelo para la estructura y otro modelo para el comportameinto. Ello implica considerar en la transformación T1, un modelo adicional que represente el comportamiento de los sistemas software (en el caso de esta tesis, de los DES)

29 Figura 1.Plan de Producción BOM-Lazy ESTADO DEL ARTE 13

30 14 CAPÍTULO Fundamentos Ingeniería dirigida por modelos (MDE) Los modelos son tan antiguos como las ingenierías, los ingenieros tradicionales en cualquier disciplina siempre crean modelos antes de construir sus obras y artefactos. Existen diversas definiciones para el término modelo de software: Una descripción de una parte de un sistema escrito en un lenguaje bien definido. (Kleppe, et al., 2003). Una representación de una parte de la función, estructura y/o mportamiento de un sistema. Una descripción o especificación del sistema y su entorno para un determinado propósito. Un modelo es representado frecuentemente como una combinación de dibujos y texto. Los modelos sirven para especificar el sistema, tanto en estructura como en comportamiento; comprender el sistema, si ya existe; razonar y validar el sistema, es decir, detectar errores y omisiones en el diseño; prototipado (ejecutar el modelo), inferir y demostrar propiedades y guiar la implementación. Entre sus características están el que son: abstractos, comprensibles, precisos, predictivos y baratos. Aproximadamente en el año 2000 aparece un nuevo paradigma, la Ingeniería de Software Dirigida por Modelos (del inglés Model-Driven Engineering y acrónimo MDE) (Kent, 2002), la cual se trata de un enfoque de desarrollo de software donde los principales activos son los modelos y las transformaciones aplicadas sobre ellos. MDE permite representar tanto la orientación a objetos como todos los demás conceptos que surgen como consecuencia de la evolución tecnológica del software. La figura 2 muestra la evolución tecnológica en el desarrollo de software.

31 ESTADO DEL ARTE 15 Figura 2. Contexto histórico(bézivin, 2003) De este modo, la MDE ofrece un acercamiento a la resolución del problema de ciertos lenguajes de programación a poder expresar conceptos de dominio de manera efectiva y menos complejos. MDE constituye una aproximación para el desarrollo de sistemas software basada en la separación de la especificación de la funcionalidad del sistema, de su implementación en plataformas específicas. A su vez, persigue elevar el nivel de abstracción dándole una mayor importancia al modelado conceptual y al papel de los modelos en el desarrollo de software. Esto implica la generación automática de implementaciones a partir de modelos (K Czarnecki y Eisenecker, 2000), lo que permite automatizar el proceso de desarrollo. En MDE son clave los lenguajes, tanto de modelado como de transformación de modelos. Un estudio realizado por Douglas Schmidt en 2006, menciona que las tecnologías utilizadas por la MDE, combinan: Lenguajes de modelado de dominio específico (del inglés Domain Specific Modeling Language y acrónimo DSML) cuyos tipos de sistemas definen la estructura de la aplicación, comportamiento y requisitos para algún dominio en específico, por ejemplo: servicios financieros, minería de datos. Los DSMLs usan metamodelos que definen las relaciones entre los conceptos en un dominio y especifican las restricciones

32 16 CAPÍTULO 2 asociadas con el mismo. Los desarrolladores de estos lenguajes de modelado construyen estas aplicaciones con la finalidad de expresar todo de manera declarativa en lugar de imperativa. Generadores y máquinas de transformación las cuales analizan ciertos aspectos de los modelos y sintetizan diversos componentes, como el código fuente, descripciones XML o representaciones alternativas de modelos. Esta habilidad de sintetizar ayuda a garantizar la coherenciaentre las implementaciones de aplicación y las de análisis de la información. Además que la automatización de la transformación es un paso grande a diferencia de los programas hechos paso a paso que día tras día son rechazados más. De esta forma, emergiendo la MDE, se puede proporcionar un alto nivel de plataforma y simplificaciones en el lenguaje. DSML puede ser de gran ayuda principalmente asegurándose que esta técnica siga cubriendo las necesidades del usuario. Además el uso de restricciones puede detectar y prevenir muchos errores en el ciclo del programa Arquitectura dirigida por modelos (MDA) La Arquitectura Dirigida por Modelos (del inglés Model Driven Architecture y acrónimo MDA) es una iniciativa del Object Management Group (OMG) presentada en el año 2001, propone la definición y uso de modelos a diferentes niveles de abstracción, así como la posibilidad de generación automática de código a partir de los modelos definidos y de reglas de transformación entre dichos modelos. MDA es un framework para desarrollo de software que defiende la separación de la especificación y funcionalidad de un sistema de su implementación en cualquier plataforma tecnológica concreta. Las plataformas middleware pasan a un segundo plano y los modelos constituyen el elemento principal para el desarrollo software.

33 ESTADO DEL ARTE 17 La idea principal de MDA es la importancia de los modelos y las transformaciones entre modelos en el proceso de desarrollo. Siguiendo esta aproximación, los desarrolladores construyen modelos de los sistemas utilizando primitivas de alto nivel de abstracción. Estos modelos son transformados hasta obtener el código fuente del sistema software final. MDA es la propuesta para MDE que hace la OMG. Entre los principales estándares (que se interrelacionan) y que son utilizados en esta tesis, se encuentran: UML (Unified Modeling Language) es un lenguaje de modelado para visualizar, especificar, construir y documentar un sistema de forma estándar. MOF (Meta-Object Facility) proporciona un mecanismo para definir metamodelos. XMI (XML Metadata Interchange) es un formato para el intercambio de metadatos incluyendo los modelos UML. QVT (Query/View/Transformation) un vocabulario que utiliza OCL para expresar transformaciones y relaciones de equivalencia sobre modelos. OCL (Object Constraint Language) un vocabulario que permite expresar consultas y restricciones sobre modelos. Figura 3. Logotipo de MDA

34 18 CAPÍTULO 2 El proceso de desarrollo software típico es un proceso iterativo en el que se suceden las fases: recogida de requerimientos, análisis, diseño, implementación, pruebas e instalación. Durante los últimos años se han hecho muchos progresos en el desarrollo de software, sin embargo sigue teniendo múltiples problemas. El proceso tradicional produce una gran cantidad de documentos y diagramas, pero este material va perdiendo su valor gradualmente cuando comienza la fase de codificación. Cuando el sistema cambia a lo largo del tiempo, la distancia entre el código, el texto y los diagramas se hace cada vez mayor y los cambios son frecuentemente realizados a nivel de código. Por tanto se necesita un soporte Modelos en MDA La clave para el uso de MDA es la importancia de los modelos en el proceso de desarrollo de software, ya que dichos modelos tendrán la responsabilidad de definir la estructura completa del software(omg, 2003). El ciclo de vida en el desarrollo MDA, que se muestra en la figura 4, no parece muy diferente del ciclo de vida tradicional de un sistema de información. Se pueden identificar las mismas fases con algunas excepciones. Una de las principales diferencias radica en la naturaleza de las instancias que se crean durante el proceso de desarrollo. Las instancias son los modelos formales, es decir, modelos que pueden ser interpretados por computadoras.(kleppe, et al., 2003).

35 ESTADO DEL ARTE 19 Figura 4. Ciclo de vida del desarrollo MDA (OMG,2003). MDA ha definido tres niveles conceptuales de modelado, en diferentes niveles de abstracción: Modelo Independiente de Computación (del inglés Computational Independent Model y acrónimo CIM).- modelo que expresa el sistema y su entorno, describe los requerimientos del sistema pero oculta detalles sobre su estructura. Por ejemplo, modelos de casos de uso que capturan los requisitos del sistema. Modelo Independiente de Plataforma (del inglés Platform Independent Model y acrónimopim).- modelo de un elevado nivel de abstracción independiente de cualquier tecnología de implementación. Un PIM es transformado en uno o más PSM. Por ejemplo, la descripción de la arquitectura software del sistema, que especifica cómo se descompone la funcionalidad básica del sistema en términos de componentes (arquitectónicos) y conectores.

36 20 CAPÍTULO 2 Modelo Específico de Plataforma (del inglés Platform Specific Model y acrónimo PSM).- modelo de un subsistema que incluye información de la tecnología específica que se empleará para su implementación en una plataforma específica. Por ejemplo, un sistema implementado en una plataforma como.net, o J2EE. Este modelo expresa como las distintas partes de la arquitectura deben ser representados en esa plataforma. Modelo de Código(del inglés Code Model y acrónimocm).- nivel de abstracción más bajo, se trata del código que implementa el sistema. Cada PSM es transformado en código Modelo Un modelo describe un sistema de tal manera que pueda ser utilizado para producir otro sistema similar. El sistema creado a partir de un modelo no puede ser igual tal cual al modelo raíz debido a el nivel de abstracción que se maneja en dicho modelo, por lo que los detalles en un modelo creado a partir de otro tienen diferencia a nivel de características. Sin embargo, debido a que sólo los detalles se omiten en el modelo creado y las características principales se mantienen, el sistema de nueva producción tiene las mismas características principales que el original, es decir, es similar a él. Cuanto más detallado sea el modelo, más similares serán los sistemas que este pueda generar. Un modelo debe ser creado o definido en algún lenguaje. Esto podría ser UML, un lenguaje de programación o cualquier otro idioma común existente. Para habilitar la transformación de un modelo, es necesario restringir los modelos y establecerlos de acuerdo a MDA que establece que los modelos deben de estar escritos en un lenguaje bien definido. (Mellor, et al., 2004) Un lenguaje bien definido tiene reglas y restricciones y lo principal es que debe ser interpretado de forma por una computadora. Un lenguaje natural no es considerado como bien definido, porque no puede ser interpretado por

37 ESTADO DEL ARTE 21 computadoras. Por lo tanto, no son adecuados para la transformación en el framework de la MDA. Considerando esto se puede establecer que: Un modelo es una descripción de (parte de) un sistema escrito en un lenguaje bien definido. Un lenguaje bien definido debe estar bien estructurado (sintaxis) y tener un significado (semántica), que sea adecuado para la interpretación de manera automatizada mediante una computadora. Figura 5.Modelos y lenguajes.(kleppe, et al., 2003) Algunas de las características que complementan la creación de un modelo son las siguientes: Un modelo puede omitir información con el fin de ayudar a los ingenieros en software ver con mayor claridad el dominio a modelar y plasmar sus características con exactitud para la fácil comprensión de este. Por lo tanto un modelo nunca será exactamente lo mismo que se muestra en la realidad sino más bien una aproximación muy buena a ésta. Un buen modelo refleja fielmente algo real ya sea de forma abstracta o hipotética. Es decir, aunque el modelo omita detalles, la información

38 22 CAPÍTULO 2 que no se omite refleja con precisión el objeto para que podamos entenderlo. Un buen modelo debe ser más fácil de generar que la misma realidad que se pretende modelar (ej. Un modelo de un avión es más fácil, que la construcción del mismo). Un buen modelo sirve como un medio gráfico que ilustra una o más ideas de forma rápida y sencilla. El lenguaje de modelado debe ser bien definido con el fin de reducir la probabilidad de error de interpretación por los demás actores que trabajaran con el modelo, incluidas las computadoras. MDA aprovecha esto para proporcionar automatización. Los modelos se construyen para aumentar la productividad y para manipular el modelo, entender su comportamiento y funcionalidad antes de llevarlo a algo real (Software). Una aplicación importante de los modelos es entender un problema real de un dominio específico, y la forma en que se puede reflejar en un sistema real. Esto se hace mediante la abstracción, la clasificación y la generalización de las entidades objeto con un conjunto adecuado clases y su comportamiento. Antes de MDA, estos modelos sólo sirvieron para facilitar la comunicación entre clientes y desarrolladores y actuar como modelos para el desarrollo. Hoy en día, MDA establece el framework necesario para definir y ejecutar transformaciones entre modelos de varios tipos Transformación de modelos El proceso MDA puede ser muy parecido a un desarrollo tradicional de software. Sin embargo, hay una diferencia crucial. Tradicionalmente, las transformaciones de modelo a modelo, o de modelo a código, se hacen principalmente a mano. Muchas herramientas pueden generar código de un modelo, pero usualmente no va más allá de la generación de algún código

39 ESTADO DEL ARTE 23 en forma de plantilla, donde la mayor parte de la labor todavía tiene que ser completado a mano por un programador. En cambio, las transformaciones MDA se ejecutan siempre por las herramientas como se muestra en la siguiente figura. Muchas herramientas son capaces de transformar de PSM a código, pero teniendo en cuenta el hecho de que el PSM está ya muy cerca del código, esta transformación no resulta muy fructífera. En cambio en MDA la transformación de PIM a PSM se logró automatizar y es justo en esta parte donde se ve la gran ayuda del desarrollo en MDA. Figura 6. Pasos en la transformación.(mellor, et al., 2004) El desarrollo con MDA es relativamente nuevo. Debido a esto, las herramientas actuales siguen puliendo sus características para proporcionar las transformaciones de PIM a PSM y de PSM a código al cien por ciento. El desarrollador aun necesita mejorar de forma manual el PSM transformado. Sin embargo, las herramientas actuales son capaces de generar una aplicación que se ejecuta desde un PIM y que puede proporcionar una funcionalidad básica, como crear y modificar objetos en el sistema. En general, se puede decir que una transformación consiste en una colección de reglas que son especificaciones inequívocas de la forma en que una parte de un modelo puede ser usado para crear una parte de otro modelo o en su defecto todo un modelo podría generar a un nuevo modelo. Basado en esta conclusión se puede definir la transformación, regla de transformación, y la definición de transformación como lo siguiente:

40 24 CAPÍTULO 2 Una transformación es la generación automática de un modelo destino de un modelo de origen, de acuerdo con una definición de transformación. Una definición de transformación es un conjunto de reglas de transformación que describen como un modelo origen se puede transformar en un modelo destino. Una regla de transformación es una descripción de cómo una o varias definiciones en el modelo de origen se puede transformar en una o varias definiciones en el modelo destino. Para ser totalmente útil, una transformación debe tener ciertas características. La característica más importante es que la transformación debe preservar la integridad entre el modelo fuente y el modelo destino. Por supuesto, la integridad de un modelo sólo se puede conservar en la medida en que pueda expresarse tanto en el fuente como en el modelo destino. Por ejemplo, la especificación del comportamiento puede ser parte de un modelo UML, pero no de uno entidad-relación (ER). Aun así, el modelo UML puede transformarse en un modelo ER, preservando la integridad estructural de los modelos. Figura 7. Transformación definida entre distintos lenguajes.(kleppe, et al., 2003) Para poder tener una mayor precisión sobre lo que es una transformación entre modelos, es conveniente presentar una especificacion formal de ésta, y a partir de ahí establecer las variaciones que pueden existir de ellas. Una transformacion t es definida como: t : M1(S1) L1 M2(S2) L2

41 ESTADO DEL ARTE 25 donde, M1 es el modelo origen, M2 es el modelo destino, S1 y S2 son los sistemas descritos por sus correspondientes modelos M1 y M2 respectivamente, y L1 y L2 son los lenguajes que definen la sintaxis y la semantica de cada uno de los modelosm1 y M2 respectivamente. La forma de llevar a cabo una transformación t depende de varios factores que intervienen en su proceso, factores como el nivel o niveles de abstracción donde se aplica, el tipo de relación existente entre cada modelo, y otros más. En (Czarnecki y Helse, 2003) se hace una clasificación de las transformaciones de acuerdo a ocho criterios que constituyen los modelos principales de transformación estos a su vez son descompuestos en otros, usando un diagrama de características para indicar su relación de dependencia, llegándose a formar más de cincuenta tipos diferentes. En (Brown, et al., 2005) se describen tres de los tipos mas usuales, la transformación de refactorización, la de modelo a modelo y la de modelo a código. En(Sendall y Kozaczynski, 2003) se agregan otros tipos de transformación usando una variedad de criterios de clasificación, diferentes a los usados en la clasificación de (Czarnecki y Helse, 2003). Una manera de establecer diferentes tipos de transformaciones, es analizando la forma en cómo se vinculan los sistemas(s), lenguajes (L) y modelos (M), de acuerdo a si se usa el mismo o diferente sistema, lenguaje o modelo, o bien combinando estas dos posibilidades, lo cual es propuesto por (Metzger, 2005) Query View Transformations (QVT) En el marco de la MDA, la OMG propone Query/Views/Transformations (QVT) ( como lenguaje para la transformación entre modelos. Una transformación, define como un conjunto de modelos pueden ser transformados en otro. Esta contiene un conjunto de reglas que especifican el comportamiento de su ejecución. Se ejecuta sobre

42 26 CAPÍTULO 2 un conjunto de modelos cuyos tipos están especificados por un conjunto de tipos de modelos o metamodelos asociados con la transformación. La especificación QVT posee una naturaleza hibrida: declarativa e imperativa. Parte declarativa: Esta formada por un lenguaje de alto nivel de abstracción para expresar relaciones y por un lenguaje base menos abstracto semánticamente equivalente. Parte imperativa: Para los casos en que es difícil una transformación en declarativo, QVT ofrece el lenguaje operacional de conversiones. Las transformaciones de modelos tienen como propósito obtener uno o varios modelos a partir de cierto número de modelos de origen. Los modelos obtenidos representan el sistema a diferentes niveles de abstracción, o desde distintos puntos de vista. Para dar soporte al proceso de transformaciones de modelos, se han definido numerosos lenguajes y herramientas que difieren en aspectos como tipos de paradigmas soportados (declarativos vs. imperativos vs. híbridos), grado de generalidad (de propósito general vs. optimizados para dominios específicos), o niveles de abstracción (alto vs. bajo nivel, máquinas virtuales, etc.). En QVT se describen tres lenguajes complementarios cuyo propósito es definir transformaciones entre modelos en el marco de MDA. Dos de ellos, llamados Relations y Core, son de naturaleza declarativa. El tercero, Operational Mappings, es imperativo. La definición de estos tres lenguajes incorpora en su sintaxis el lenguaje estándar OCL (Object Constraint Language) para expresar consultas (queries) a los modelos en una notación ampliamente conocida y utilizada.

43 ESTADO DEL ARTE 27 Figura 8. Esquema de transformación con QVT (Gómez, 2009) Los lenguajes que componen QVT ofrecen mecanismos de trazabilidad entre elementos de uno o varios modelos. El flujo de ejecución de las transformaciones determina implícitamente la información de traza. Hay implementaciones que permiten persistir esta traza al finalizar la ejecución. QVTo dispone adicionalmente de operaciones para acceder a su contenido dinámicamente, en tiempo de ejecución. En este trabajo analizamos el lenguaje de transformaciones de modelos Operational Mappings (QVTo). QVTo es similar a los lenguajes procedurales de programación tradicional. Adicionalmente, incorpora elementos constructivos diseñados para operar (crear, modificar, eliminar) sobre el contenido de modelos descritos en términos del meta-metamodelo MOF de MDA. El lenguaje se estructura básicamente en procedimientos u operaciones invocables, denominados mapping operations. También dispone de procedimientos simples llamados helpers o queries. QVTo extiende el lenguaje declarativo EssentialOCL con su propio complemento de expresiones imperativas recogidas en el paquete denominado ImperativeOCL. La ejecución de estas expresiones imperativas provoca efectos en el estado de ejecución (asignación de valores a variables, etc.). En contrapartida, por ser declarativas, la evaluación de las expresiones OCL no ocasiona cambios de estado.

44 28 CAPÍTULO Facilidad para Meta-Objetos (MOF) La OMG ha creado el estándarfacilidad para Meta-Objetos (del inglés Meta Object Facility y acrónimo MOF) ( extiende UML para que éste sea aplicado en el modelado de diferentes sistemas software. El estándar MOF define diversos metamodelos, esencialmente abstrayendo la forma y la estructura que describe los metamodelos. MOF es un ejemplo de un meta-metamodelo o un modelo del metamodelo orientado a objetos por naturaleza. Define los elementos esenciales, sintaxis y estructuras de metamodelos que son utilizados para construir modelos orientados a objetos de sistemas. A demás, proporciona un modelo común para los metamodelos de UML. Más en concreto, el estándar MOF proporciona: Un modelo abstracto de los objetos genéricos MOF y sus asociaciones. Reglas que definen el ciclo de vida, composición y semántica de los elementos basados en metamodelos MOF. Una jerarquía de interfaces reflexivos. Estos definen un conjunto de operaciones para localizar y manipular modelos basados en MOF pero de los cuales no conocemos sus interfaces. El gran potencial de MOF reside en que permite interoperar entre metamodelos muy diferentes que representan dominios diversos. Las aplicaciones que utilizan MOF no tienen por qué conocer los interfaces del dominio específico de algunos de sus modelos, pero pueden leer y actualizar los modelos utilizando las operaciones genéricas y reflexivas ofrecidas en los interfaces. La semántica de MOF define generalmente servicios para el repositorio de metadatos, para así permitir la construcción, la localización, la actualización, etc. En concreto, una implementación MOF debe proporcionar herramientas para la autorización y la publicación de metadatos contra un repositorio MOF. En este framework en la capa de información se encuentran bases de datos relacionales, orientadas a objetos, ficheros e información en XML. Cada fuente de datos tiene un metamodelo, definido en la capa del modelo, que de-

45 ESTADO DEL ARTE 29 termina su estructura y las relaciones que existen entre los diferentes tipos de entidades del modelo. El meta-metamodelo, es un metamodelo que describe el contenido de los metamodelos, es decir, los tipos de entidades que son compartidas a través de los diferentes sistemas de información. El estándar MOF proporciona los mecanismos para poder describir todos los tipos de sistemas de información y puede ser ampliado para incluir más sistemas de los cuatro predefinidos.

46 30 CAPÍTULO 2 Figura 9. Capas en MOF

47 ESTADO DEL ARTE 31 El framework MOF tiene bastantes ventajas sobre los sistemas de modelado simples y permite: Soportar cualquier tipo de modelo y paradigma de modelado imaginable. Permite relacionar diferentes tipos de metadatos. Permite añadir de forma incremental metamodelos y nuevos tipos de metadatos. Permite intercambiar modelos y metamodelos entre elementos que usen el mismo meta metamodelo. El modelo MOF está orientado a objetos y formado por elementos totalmente compatibles con el lenguaje de modelado UML. Las capas de la arquitectura MOF no son fijas y aunque normalmente se utilizan cuatro niveles estos podrían ser más o menos en función de cómo se quiera utilizar MOF. Estas capas son simplemente un mecanismo para entender las relaciones entre los diferentes tipos de datos y metadatos; Un modelo no está limitado únicamente a un meta-nivel. MOF se autodescribe asimismo y normalmente es definido usando sus propios elementos del metamodelo, y además este modelo está representado por medio del dibujo del paquete UML. Esta característica tiene unas consecuencias importantes: Indica que el modelo MOF es lo suficientemente expresivo para realizar metamodelos. Permite a los interfaces MOF ser definidos por medio de mapeo IDL. Proporciona las bases de una arquitectura para su extensión y modificación. Permite nuevas implementaciones del repositorio del metamodelo y herramientas asociadas.

48 32 CAPÍTULO Metamodelos Todo metamodelo ayuda a representar uniformemente un concepto o un dominio. En el caso de esta tesis, el dominio elegido son los DES. Dentro del contexto de la Ingeniería Dirigida por Modelos (MDE), la especificación de los metamodelos es de relevante importancia para el modelado de los sistemas software, ya que los metamodelos sirven como plantillas para crear los modelos, dado que en un metamodelo se representan los elementos de los modelos, que conforman a dicho metamodelo(i.e. los modelos son instancias de los metamodelos), y cómo están relacionados entre sí. De tal forma que, al crear un modelo, éste contendrá sólo lo que está especificado en su respectivo metamodelo, permitiendo mantener consistencia entre los modelos generados (como instancias del metamodelo o como salidas al ejecutarse la transformación de modelo a modelo) Metamodelo modular Este metamodelo se fundamenta en una estructura que representa una descomposición del sistema usando como criterio las funciones que se esperan que este realice. La forma dedescomponer al sistema mediante esta estructura es adecuada para modelar a los sistemas complejos que se dan en el software, puesto que con ella se representan relaciones de jerarquía, lo cual es propio de los sistemas complejos. (Simon y Ando, 1961) argumentan que al observar la forma que adopta la estructura de varios sistemas complejos, éstos toman la forma de una jerarquía. Por otra parte, los módulos han constituido desde los 70 s las primeras estructuras para descomponer y agrupar el software, en (Parnas, 1972) el módulo se usó para agrupar las responsabilidades del sistema, y después se le consideró como el elemento esencial para abordar la complejidad al ocultar los detalles de la implementación. Actualmente, a nivel

49 ESTADO DEL ARTE 33 arquitectónico, esta estructura (modular) se ha consolidado como algo fundamental (Clements, et al., 2002),(Clements, et al., 2003) la estructura que se representa con esta vista responde a preguntas tales como las expuestas en(clements, et al., 2003): a) Qué hace el sistema? b) Cuál es la responsabilidad principal asignada a cada módulo? c) Qué módulos son usados por otros? d) Qué módulos son permitidos usar por otros módulos? e) Qué módulos están vinculados con otros módulos por medio de relaciones de generalización o especialización? Estas preguntas permiten delinear lo que debe contener un módulo y dirigir las relaciones que se establecen entre este tipo de elementos. Para esto, primero se comienza con la definición de lo que aquí se considera como un módulo, la cual es tomada como referencia:un módulo es una unidad de implementación de software que provee una unidad coherente de funcionalidad(clements, et al., 2002). Aunque el módulo representa una unidad de implementación de software, en realidad al diseñar la arquitectura éste sólo incluye la especificación de las funciones que serán posteriormente diseñadas (en detalle) e implementadas en las siguientes fases del desarrollo, puesto que la intención esencial de la modularidad es incluir decisiones de lo que deben ser los módulos antes que lleguen a convertirse en unidades de implementación (D. Parnas, 2001). De esta manera se cumple uno de los propósitos de este metamodelo, el llegar a ser el anteproyecto del código(clements, et al., 2002). Los atributos que se usan para definir a un módulo responden a las preguntas (a) y (b) que se plantearon anteriormente, estos atributos son: La función principal que desempeña, la cual define la razón del ser del módulo.

50 34 CAPÍTULO 2 Las responsabilidades que le son asignadas, las cuales responden a los requisitos detectados por la ingeniería de requisitos, y que se consideran deben estar agrupadas en un módulo. Estas pueden ser accesibles a través de interfaces. Las interfaces, que hacen posible establecer con precisión los roles que desempeñan los módulos dentro del sistema. La información adicional de las características de la implementación sobre la plataforma en que un módulo será desarrollado (por ejemplo, Java,.NET). Por otra parte, las relaciones que se establecen entre los módulos se derivan de las últimas tres preguntas planteadas anteriormente: (c),(d), y (e). La pregunta (c) da pie a la relación llamada usa, la pregunta (d) plantea conocer las relaciones que se establecen entre distintos niveles de abstracción llamadas usa-capa, y por último la pregunta (e) plantea dos tipos de relación: la generalización y la especialización entre módulos. A continuación se fundamentan y definen estas relaciones. I. Relación usa: esta relación implica que un elemento tipo módulo usará las funciones de otro elemento de este tipo para completar sus funciones. Esto significa que el primer elemento (el que usa) tenga una fuerte dependencia del segundo (del usado), puesto que aunque son dos módulos independientes, el segundo es complementario del primero. Por ejemplo, sean a y b dos elementos tipo módulo, la relación usa se puede representar como: a b, indicando que el elemento a usa alguna o todas las responsabilidades asociadas a la función del elemento b. Si se quiere especificar qué es exactamente lo que ausa de b, se puede usar una interfaz en el módulo bque especifique la responsabilidad que se está accediendo de él. Con esta relación es posible conocer que módulos le son necesarios a otro módulo para analizar el grado de dependencias que existe entre módulos dentro de una arquitectura.

51 ESTADO DEL ARTE 35 II. Relación usa-capa: en esta relación se usa el mecanismo de abstracción llamado capa, que permite hacer una separación de tareas agrupando a los módulos en diferentes niveles de abstracción, de tal manera que los elementos de una capa se refinan en las funciones que en su conjunto brindan los elementos de otra capa. Las capas equivalen a máquinas virtuales, tal como se declara en (Clements, et al., 2002) Las capas intentan ser una máquina virtual. Una máquina virtual es una colección de módulos, que en su junto proveen un conjunto de servicios que otros módulos usan Metamodelo de componentes y conectores El metamodelo de componentesyconectores (C-C) es una perspectiva que muestra las estructuras que adoptan los elementos de software usados en tiempo de ejecución. Aquí se modelan las potenciales interacciones entre las entidades ejecutables de software que se manifiestan al operar el sistema. El modelado a nivel arquitectónico de éste consiste en describir como estas interacciones llegan a configurarse, el tipo de flujos de comunicación que se establecen entre estas entidades, y el rol que desempeña cada elemento. Mediante la estructura básica de estemetamodelo se pueden derivar otras más específicas, con el objeto de describir aspectos más particulares, como por ejemplo aspectos de concurrencia y sincronización (Krutchen, 1995) que pueden ser descritos mediante el modelo especifico de procesos de comunicación(clements, et al., 2002). Esto es posible gracias a los diferentes roles que desempeñan sus dos principales elementos, el componente y el conector. Estemetamodelo es el más tratado en la temática de la arquitectura de software, ya que los componentes y conectores fueron considerados desde la concepción de la arquitectura de software. En (Perry y Wolf, 1992) se menciona a los componentes como elementos para el procesamiento, y a los

52 36 CAPÍTULO 2 conectores se les designa como elementos de interconexión. En (Shaw y Garlan, 1996) se les considera ya como los dos elementos básicos de una arquitectura, situándolos en diferentes niveles de abstracción. Actualmente, estos elementos son el soporte de casi todos lenguajes desarrollados para la descripción arquitectónica (ADL`s), desde lenguajes diseñados ex-profeso para la arquitectura, como los analizados en (Medvidovic y Taylor, 2000), o lenguajes genéricos como el UML 2.0 que se han adaptado para tal fin(kandé y Strohmeier, 2000), hasta aquellos lenguajes diseñados con una orientación especifica de la arquitectura como PRISMA (Pérez, 2006) que está diseñado para trabajar con aspectos. Con estemetamodelo de C-C se pretende dar respuesta a preguntas tales como: a).cuáles son los principales componentes en ejecución y como ellos interactúan? b) Cuáles son los principales almacenes de datos compartidos? c) Qué partes del sistema están replicadas? d) Cómo hacer que los datos progresen a través del sistema? e) Qué partes del sistema pueden ejecutarse en paralelo? f) Cómo puede la estructura del sistema cambiar, cuando se ejecuta? Para ver como estemetamodelo puede dar respuesta a las preguntas planteadas anteriormente, se comienza por definir a sus dos principales elementos: componente y conector El Componente. Un componente de software es definido por (Hezum y Sims, 1999) como una construcción auto-contenida de software que tiene un uso definido, con interfaces para eltiempo de ejecución, y puede ser desarrollado en forma autónoma. En esta definición se destacan características genéricas de un componente: su autonomía, que desempeña una función específica, y que

53 ESTADO DEL ARTE 37 cuenta con interfaces para interconectarse en tiempo de ejecución. Una definición también genérica dada por (Hopkins, 2000), agrega una característica más, la que un componente es un elemento ejecutable. Sin embargo estas definiciones se refieren a componentes de software en general, por lo que para ubicarse dentro del ámbito de la arquitectura de software se toma la definición dada en (Clements y Krueger, 2002)donde se describe lo que representa un componente dentro de este ámbito de la siguiente manera:los componentes son los principales elementos computacionales ejecutables, y los almacenes de datos que intervienen en tiempo de ejecución. Se puede entender que un componentedentro de la arquitectura, representa a dos tipos de elementos de un sistema (a elementos ejecutables y a los almacenes de datos), quienes juegan un rol importante en el ambiente de ejecución. Algo importante que vale la pena aclarar sobre el elemento computacional al que se hace referencia en esta definición, es que a nivel arquitectónico no interviene ni la metodología ni tecnología con que este haya sido hecho(o se vaya hacer), por lo tanto un elemento puede ser un objeto o un componente desarrollado bajo cualquier plataforma, o un elemento diseñado con un software especializado. Lo importante aquí es que sea ejecutable y que además sea un elemento principal dentro del sistema. El calificativo de ser principal, aunque es muy relativo, indica que sólo interesan elementos ejecutables que tengan una injerencia significativa en el sistema, descartando a muchos elementos que aunque útiles no repercuten en la arquitectura. Por otro lado, el término componentecomo un elemento arquitectónico, hace alusión a las características señaladas en el desarrollo orientado a componentes, en el sentido de ser un elemento reutilizable, y que hace posible que el sistema (en este caso la arquitectura) evolucione(hopkins, 2000), gracias a la relativa independencia que se tiene para su diseño y

54 38 CAPÍTULO 2 desarrollo. Es decir un componentearquitectónico se comporta como un componente de software. Puesto que el propósito de un componentearquitectónicoes modelar el comportamiento de los elementos del sistema que se usan en tiempo de ejecución, se debe incluir en su especificación la información necesaria que permita describirlos. La información para un componente genérico, es decir para aquellos que no tienen una especialización en su comportamiento, comprende básicamente lo siguiente: La tarea o función computacional en tiempo de ejecución que realiza, la cual lo identifica como tal, especificando también si se trata de un elemento ejecutable o un almacén de datos (Nock, 2003). Las interfaces de comunicación, que consisten en los puertos de entrada y salida, por los cuales recibirá y enviara información desde y hacia los demás componentes. Dichos puertos son los puntos por donde se comunica con los demás elementos. Información y operaciones internas necesarias para hacer manipulaciones de lo que se modela con él. Ejemplo de estas operación se encuentran en los componentes definidos por algunos ADL s, por ejemplo en Wright(Allen, 1997) se incluye las computaciones, y en PRISMA (Pérez, 2006) las evaluaciones. Un componente genérico es especializado cuando se le asocia con alguna de las funciones que forman parte de ciertas estructuras arquitectónicas identificadas como estilos, las cuales han sido especificados en (Shaw y Garlan, 1996), y (Clements y Krueger, 2002). Entre las estructuras (o estilos) más comunes que emplean componentes están las siguientes: filtro-tubería, cliente-servidor, igualdad-de-servicios, escritor-lector, datos compartidos. Dichas estructuras especializan al componente mediante la especificación de la función computacional particular que debe realizar dentro de ellas, el tipo y número de puertos que debe usar, y los atributos adicionales que debe contener.

55 ESTADO DEL ARTE 39 Los tipos de componentes que aquí se proponen tienen la descripción de su función computacional correspondiente, indicando el tipo de puertos y el número de éstos, y los atributos adicionales que ellos especializan. Un puerto puede ser de tipo entrada o de salida; por el de salida se comunican los servicios que un componente ofrece a los demás, y por el de entrada se reciben las solicitudes de esos servicios o lo que el mismo componente requiera. También es posible contar con componentes donde un puerto es del tipo entrada y salida, como es considerado en esta tesis. Deben existir tantos puertos de cada tipo como servicios diferentes se ofrezca o se requieran, el número de estos dependerá de la función computacional de cada tipo de componente, aunque solo es posible determinar su mínimo necesario o en algunos casos asociarlo a los tipos de servicios que ofrece o recibe. Los atributos corresponden a información interna necesaria para modelar el comportamiento de cada tipo de componente. Los artefactos son unidades adicionales para la ejecucion del componente. Por último, hay que señalar que estos tipos de componentes pueden ser compuestos, es decir estar formados por otros componentes, por ejemplo en PRISMA (Pérez, 2006) a un componente compuesto se le designa como sistema El Conector Con respecto al conector, segundo elemento basico de este modelo, su importancia dentro de la arquitectura esmanifestada desde los inicios de ésta al ser considerado como un elemento de primera clase(shaw, 1994). En (Shaw, et al., 1995) a un conector se le describe como el lugardonde se definen las relaciones entre los componentes, estosignifica que sirve como enlace entre los componentes,coordinando las interacciones entre ellos y estableciendo lasreglas que las gobiernan, tal como se señala en (Shaw y Garlan, 1996). Recientemente un conector ha sido definidopor(clements, et al., 2002) de la

56 40 CAPÍTULO 2 siguiente manera: Un conector es una ruta de ejecución de la interacción entre dos o más componentes. Al considerarse a un conector como una ruta, significa que en ella se tiene que modelar las formas de vincular a los componentes, especificando las reglas de interacción y la forma de coordinarse. De hecho, un conector podría comparase con la medula espinal del centro nervioso de este modelo de C-C, donde concurren las conexiones de los componentes mas importantes. La forma en que dos o más componentes se vinculan, depende del tipo de interacción que sus servicios produzcan y demanden. Los servicios pueden interactuar mediante llamadas de procedimientos, eventos, acceso a datos, o solo mediante un simple flujo de comunicación. Cada una de estas formas de interacción implica que los conectores se tengan que especializar, incorporando propiedades adecuadas para modelarlas. Desde los inicios de la arquitectura se propusieron a cuatro tipos de éstos, para llamadas a procedimientos, para manejo de eventos, de protocolos para bases de datos y tipo tuberia (Shaw y Garlan, 1996). A nivel general, dentro del software se han detectado varios tipos de conectores. En (Mehta, et al., 2000) se ha hecho una clasificacion de ocho tipos, de acuerdo a los servicios de interacción que prestan. Éstos son llamadas a procedimientos, eventos, acceso-a-datos, enlaces, flujos, árbitro, adaptador y distribuidor. Cada uno tiene diferentes formas de coordinar las interacciones, a continuación se describe lo que realiza cada tipo de conector: El tipo llamadas-a-procedimientos, establece una coordinación a través de técnicas de invocación, y transfiere datos a través del uso de parámetros. El tipo eventos, detecta los eventos que le acontecen a un componente, y los mensajes generados por estos eventos son enviados a los componentes involucrados para que ellos los procesen.

57 ESTADO DEL ARTE 41 El tipo acceso-a-datos, coordina el acceso a componentes de tipo datos-compartidos, pudiendo además prestar otros servicios como conversión de la información que se recibe o envía. El tipo enlace, solo proporciona un canal para que la información de los componentes fluya a través de él. El tipo flujo, coordinan la ejecucion de la transferencia de grandes cantidades de información entre procesos autónomos, como por ejemplo entre componentes clientes y servidores. La composición básica de un conector de acuerdo a (Clements, et al., 2002), incluye: Las reglas de interacción, lo cual está determinado por su tipo y por los tipos de componentes que llega a enlazar. Las reglas de interacción de los conectores se fundamenta en la naturaleza de su tipo. Estas reglas se hacen explícitas al relacionarse con los tipos de componentes. Los protocolos de estas interacciones, cuyas entidades visibles son los roles,se forman al enlazar a los componentes. Los roles son los puntos de enlace de los conectores que enlazan a los puertos de los componentes. Las propiedades adicionales, que son atributos adicionales requeridos para llevar a cabo la interacción. Cada tipo de conector determina sus posibles roles y el número de ellos. Estos roles son los básicos a considerar porque pueden darse otros de acuerdo a los tipos de componentes que vincule. Las propiedades adicionales de cada tipo de conector, están formadas por atributos que requieren ser especificados, pero pueden existir otras propiedades de comportamiento que resulten necesarias.

58 42 CAPÍTULO Lenguaje Unificado de Modelado (UML) El Lenguaje Unificado de Modelado (del inglés Unified Model Lenguage y acrónimouml) representa una unificación de conceptos y anotaciones creadas por tres personas.1(booch y Cummings, 1994), (Rumbaugh, 1991) y (Jacobson, 1992). El objetivo principal de UML es el de convertirse en un lenguaje común utilizado para la creación de modelos orientados al software computacional. La notación de UML es muy completa. Existe una notación para modelar los elementos estáticos como clases, atributos y relaciones. Además, existe otra notación para el modelado de elementos dinámicos como objetos y mensajes Diagrama de clases Es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. El elemento fundamental de un diagrama de clases es una clase, la cual es mostrada en la figura 10. El icono de una clase es simplemente un rectángulo dividido en tres. El compartimento de arriba contiene el nombre de la clase, el de en medio contiene todos los atributos correspondientes a esa clase, mientras que el de abajo contiene una lista de operaciones. Figura 10. El icono de una clase Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.

59 ESTADO DEL ARTE 43 Las relaciones de composición, como por ejemplo la mostrada en la figura 11, en donde el diamante negro representa la composición y la flecha denota que la relación que sólo puede ser navegable en una sola dirección. Las relaciones de composición es una manera completa de representar una agregación, también indica el tiempo de vida de los componentes, es decir, en nuestro ejemplo, si Circle es eliminado, Poin también será eliminado. Figura 11. Relación de Composición La figura 12muestra una relación de herencia. Esta es una relación en la cual un elemento del modelo es basado en otro elemento del mismo modelo (clase padre). Para fines de semántica, las dos clases deben de ser del mismo tipo y tanto el elemento padre como el elemento hijo pueden tener muchos hijos y muchos padres respectivamente. Este tipo de relaciones no llevan nombres, y son representadas con el triangulo blanco apuntando a la clase padre. Figura 12.Relación de Herencia Diagrama de secuencias Los diagramas de secuencias ilustran la interacción entre objetos y el orden secuencial en el que ocurren dichas interacciones, es decir como se comunican los objetos entre sí. Los objetos se comunican mediante interfases, para poder invocar a una operación. En los Casos de Uso se modelan las caracte-

60 44 CAPÍTULO 2 rísticas del sistema y se desarrollan escenarios para proporcionar un camino a partir de los escenarios y describir las operaciones en una forma más detallada. Los elementos que representan un diagrama de secuencias son los siguientes: Objetos: Representan a cada una de las entidades que intervienen en el diagrama de secuencia, el orden en el que aparecer es indistinto ya que a través de la secuencia se determinara la interacción de estos. Mensajes: Determinan la acción y dirección de el evento que están solicitando estos pueden ser síncronos o asíncronos. Línea de Vida: Su función es determinar el tiempo de vida de un objeto, mientras mas grande sea la extencion de esta vida el objeto participara más tiempo en el diagrama de secuencia. Los mensajes se mueven a través de éstas. La figura 13 presenta el diagrama de secuencias de la interacción entre los elementos de un sistema de diagnóstico de programas educativos.

61 ESTADO DEL ARTE 45 Figura 13. Diagrama de secuencias Lenguaje de Marcas Generalizado (XML) Dentro del mundo de los datos y la computación, la información va de un lado a otro transportando contenido de diferentes áreas y entre aplicaciones distintas. Esta información se genera con ciertas características de acuerdo a parámetros establecidos por el emisor y quizás a normas que obligan al formato en el que esta es liberada. Usualmente la instancia que genera información a compartir no se preocupa por la forma en que la emite ya que se asume que será leída e interpretada por una instancia similar. Pero qué sucede cuando una instancia que no pertenece al campo o dominio del emisor necesita leer esta información?. Es justo aquí donde se genera un conflicto, ya que cuando esta instancia ajena pretenda leer, interpretar y manipular la información no podrá hacerlo al no contar con los parámetros establecidos por la instancia origen. Todo esto en referencia a información de contenido abierto, en la que se pretende que una o más instancias de origen distinto puedan intercambiar datos.

62 46 CAPÍTULO 2 Viendo la realidad actual, la información han dejado de ser cerrados, rígidos y estáticos, en cambio se ha tornado abierta, accesible y dinámica, esto conlleva muchos retos ya que darle ese plus a la información en teoría debería de ser más complejo. Se entiende que en un principio si se pretende darle un toque genérico a los datos al momento de compartirlos estos se deben de estructurar de cierta forma. El Lenguaje de Marcas Generalizado (del inglés Extensible Markup Language y acrónimo XML) es un lenguaje de definición que ayuda a establecer criterios y formas en las que cierto documento debe ir estructurado. Ha ganado mucha popularidad en los últimos años debido a ser un estándar abierto y libre, creado por el Consorcio World Wide Web (W3C). Este lenguaje no es más que una evolución de SGML (Standard Generalized Markup Language) que es una evolución de GML creado por IBM. Lo que pone de manifiesto que es un lenguaje que trae una consecución de rasgos evolutivos que han ido mejorando su uso. En su momento SGML proporciono la misma funcionalidad de XML pero su dificultad presentaba un reto para los desarrolladores en cambio XML simplifico de forma muy concreta la definición de patrones y características dentro de sus documentos. XML además es un metalenguaje, es decir, es un lenguaje para definir lenguajes. Los elementos que lo componen pueden dar información sobre lo que contienen, no necesariamente sobre su estructura física o presentación. Un lenguaje de marcado como XML debe de cumplir con ciertas restricciones, tiene que especificar cuáles marcas son permitidas, cuales son obligatorias u opcionales, como deben diferenciarse esas marcas de la información incluida y que significa cada marca. Por lo tanto el metalenguaje esta contenido intrínsecamente dentro de cada lenguaje, pero la manera de representar el conjunto de reglas y definiciones de ese lenguaje, es una instancia del metalenguaje.

63 ESTADO DEL ARTE XML de Intercambio de Metadatos (XMI) XML de Intercambio de Metadatos(del inglés XMLMetadata Interchangey acrónimo XMI) tiene como principal objetivo el permitir un intercambio de meta información entre herramientas de modelado (basados en UML) y repositorios de meta información (basados en MOF), en heterogéneos entornos distribuidos. Realizando este intercambio mediante streams o ficheros con formato estándar basado en XML. UML es un estándar que define un lenguaje de modelado orientado a objetos que es soportado por una gama de herramientas de diseño gráfico y MOF es un estándar que define un marco de trabajo para definir modelos de meta información y proporciona herramientas con interfaces programadas para almacenar y acceder a meta información en un repositorio. De esta forma se consigue un modelado, una gestión y una publicación de meta información estándar utilizando UML y MOF para el diseño de metamodelos y XML para transferir la información. El DTD especifica el permiso para la transferencia y la verificación de: Modelos basados en UML utilizando el DTD de UML. Metamodelos y sus instancias basados en MOF, permitiendo el uso de XMI en nuevos dominios como DataWarehouse, componentes, etc. Figura 14. Integración de estándares

64 48 CAPÍTULO 2 XMI es el único estándar para el intercambio de información en un entorno de desarrollo de colaboración. Las compañías obtienen una mayor productividad en el desarrollo de aplicaciones. Los desarrolladores corporativos pueden desarrollar modelos que pueden ser distribuidos y usados por varios grupos, incluso en diferentes entornos de desarrollo. Figura 15. Tipos de intercambios(omg) Otra de sus características es que permite el intercambio de objetos y de software activo a través de entornos de desarrollo de aplicaciones de análisis de objetos OMG y facilita el diseño Ventajas de XMI Una de las ventajas que proporciona XMI es el hecho de trabajar con Internet y que está construido en base a estándares industriales como HTML, XML, UML, MOF, etc.

65 ESTADO DEL ARTE 49 Figura 16. Relación entre dominios y plataformas según OMG. (OMG, Especificación XMI 2.0) XMI evita la creación de distintos formatos, cada cual especificando la herramienta de un fabricante, siendo independiente de las herramientas, repositorios y aplicaciones en las que se haya generado la información. Haciendo posible que distintos productos sean compatibles, ya que permite que compartan su información. XMI evita la necesidad de utilizar una única infraestructura permitiendo al usuario elegir la plataforma, el fabricante, el lenguaje y la herramienta con la que desee trabajar, ya que su información podrá representarse y transferirse igualmente. Figura 17. Intercambio de objetos entre aplicaciones. (OMG, Especificación XMI 2.0)

66 50 CAPÍTULO 2 XMI ofrece una forma fácil de empaquetar la información y la meta información. Siendo más fácil de usar y comprender que las tradicionales tecnologías de meta información (relacional y repositorios de objetos). Es fácil de implementar en un tiempo récord proporcionando una tecnología y un middleware neutral. Es un enlace con la Web que promete un lenguaje común mediante etiquetas. XMI usa como normativa el intercambio de modelos UML por medio de flujos o archivos siguiendo una serie de reglas y pasos específicos. Figura 18.Validación de un archivo XMI Líneas de Productos Software (SPL) Hoy en día se necesitan nuevas técnicas para generar software de una manera más sencilla, segura y práctica para así lograr reducir los costos de producción y minimizar los esfuerzos, además de que también es necesario abastecer la demanda de software que se ha ido incrementando en estos últimos años así como su complejidad. Una alternativa para abordar esta situación son las Líneas de Producto Software (del inglés Software Product Lines y acrónimo SPL). Las SPL pueden ser definidas como: Un conjunto de sistemas software que comparten un conjunto común, administrado de características para satisfa-

67 ESTADO DEL ARTE 51 cer las necesidades específicas de un segmento de mercado o misión y que son desarrollados a partir de un conjunto en común de activos centrales de un modo prescrito (Clements y Northrop, 2001) Las SPL ofrecen una solución a ese problema. Las bases de las SPL modelan lo que es común y qué difieren entre variantes de productos. Las SPL surgieron para controlar y minimizar el costo del desarrollo de software. A medida que los programas crecen en complejidad, el desarrollo de software de un único producto cada vez se va haciendo menos económico. Una mejor aproximación es la creación de un diseño que compartan todos los miembros de una familia de productos. De este modo, el poder tener una SPL representa una tendencia en el desarrollo de software así como una alternativa de los sistemas hechos uno por uno. Otra característica de las SPL es que son desarrolladas a partir de un conjunto en común de activos centrales (<<core assets>>) de un modo preescrito(clements y Northrop, 2001). Estos activos centrales forman la base para la línea de Productos y en ellos se incluyen, entre otros, la arquitectura, las especificaciones de requisitos, los planes y casos de prueba y componentes de software reutilizables. Una forma muy sencilla de ilustrar una SPL es mediante un sistema de reservación, el cual puede incluir, reservaciones en hoteles, restaurantes, cuidado de niños, renta de vehículos, etc. A pesar de que el contexto en cada situación varía, todos estos contextos poseen algo en común (todos involucran alguien reservando algo), y al poder capturar el dominio de reservación, una gran gama de sistemas de reservación se pueden producir. Las SPL, desde un punto de vista práctico, son una de las aproximaciones más exitosas en reutilización de software, la cual se centra en desarrollar familias de sistemas. Los productos son diferentes en algunas características, pero comparten una arquitectura básica, y el proceso de desarrollo produce

68 52 CAPÍTULO 2 series (familias) de ellos. UnaSPL proporciona una aproximación industrial al proceso de desarrollo de software con el objetivo principal de desarrollar un framework que represente la familia, el cual es adaptado para desarrollar productos individuales. Una familia de productos es una colección de productos similares que comparten la mayoría de características. Esta idea de las SPL resulta ser muy útil en la generación de nuevo software ya que en la entrega del producto software se hace de una manera más rápida, económica y de una mejor calidad. El poder desarrollar un grupo de productos que tienen características en común permite la reutilización en todas las fases del desarrollo de un sistema, e incrementa la productividad y calidad de los productos software, pudiendo así, describir similitudes y variabilidades que al final, incrementarán la funcionalidad del producto.la figura 19 muestra el desarrollo de una SPL. Figura 19. Desarrollo de una SPL (figura adaptada de(clements y Northrop, 2001) La figura 20 muestra las tres actividades esenciales que se llevan a cabo para desarrollar una SPL: Desarrollo de los activos centrales: representa las actividades en curso para desarrollar los elementos básicos reutilizables de la SPL. Sus en-

69 ESTADO DEL ARTE 53 tradas son los activos centrales usados en la familia de productos, y un plan de producción que indica cómo utilizarlos o ensamblarlos para producir un producto. Desarrollo de productos: representa las actividades de ingeniería para producir productos usando los activos reutilizables que fueron prescritos en el plan de producción. Gestión: representa actividades de gestión técnica y organizacional. Las tres actividades son esenciales y están interrelacionadas, cada una de ellas puede aparecer en cualquier orden, el desarrollo es iterativo. Figura 20. Actividades esenciales para SPL (SEI) En la tabla 1se resumen los procesos a seguir en la Ingeniería del Dominio y en la Ingeniería de la Aplicación para desarrollar una SPL, según (P. Clements y L. M. Northrop, 2001). Ingeniería del dominio Análisis del Dominio Desarrollo de los componentes básicos reutilizables (assets) Planeación de producción Estudia la variabilidad del dominio. Frecuentemente este estudio se realiza en términos de características del dominio y se representa usando un modelo de características. Se concibe, diseña e implementan los componentes básicos reutilizables. Esto no sólo involucra el desarrollo de la funcionalidad del dominio, sino también define cómo los componentes básicos reutilizables deben ser extendidos. Define cómo los productos individuales son creados.

70 54 CAPÍTULO 2 Ingeniería de la aplicación Caracterización del producto Síntesis del producto Construcción del producto Se eligen las características que diferencian un producto seleccionado. Reúne los componentes básicos reutilizables que formarán el producto. Procesa la componentes básicos seleccionados siguiendo el plan de producción (p.e. compilar, generar código, ejecutar, etc.), para obtener un producto final. Tabla 1.Procesos de Ingenieria del dominio y de Aplicacion La SPL requiere almacenar sus activos de software en repositorios o «Baselines». La Baseline es una base de datos especializada que almacena activos de software y facilita su recuperación y mantenimiento. Su objetivo es asegurar la disponibilidad de activos para apoyar el desarrollo de productos de la SPL Variabilidad en las Líneas de Productos Software La variabilidad en las SPL se pueden representar mediantes distintos tipos de modelado, en este proyecto se hará uso del Modelo de Características para la representación de los DES. Uno de los elementos clave para una SPL es la representación y gestión de la variabilidad. Para tratar la variabilidad han sido realizadas y discutidas diferentes aproximaciones en los últimos años. Sin embargo, actualmente no existe una forma estándar para representarla. Muchas de las aproximaciones propuestas agregan anotaciones de variabilidad directamente en los modelos que captan la funcionalidad del software (como el Lenguaje de Modelado Unificado - del inglés Unified Modeling Language y siglas UML (UML, 2005), los Lenguajes de Descripción de Arquitecturas - del inglés Architectural Description Languages y siglas ADL, etc.), mientras que otras aproximaciones más poderosas separan la especificación de la variabilidad en modelos específicos.

71 ESTADO DEL ARTE 55 (Loughran, et al., 2007) comentan que aunque la variabilidad representa gran parte de lo que puede realizar una aplicación construida bajo el esquema de las líneas de productos software, aun no hay un estándar que defina claramente como representarla de forma completa y funcional.. Losmodelos de variabilidad pueden ser plasmados en modelos de características para captar la semántica de la variabilidad de un dominio específico Modelo de Características Un modelo de características es una jerarquía de características con variabilidad (K. Czarnecki y Antkiewicz, 2005). Los modelos de características son la clave técnica de las líneas de producto para desarrollar software (D Batory, et al., 2006). Son modelos formales que usan características para especificar productos. El modelo de características es la forma clásica de representar la variabilidad de una SPL. Sin embargo, en los últimos tiempos se ha incrementado el poder descriptivo del modelado de características, visualizado como un amplio espectro, en la cual los modelos de características situados en el lado izquierdo del espectro son menos poderosos que los modelos ontológicos situados en el lado derecho de dicho espectro (Czarnecki et al., 2006). Los modelos utilizados en el análisis de las SPL han de permitir el modelado de requisitos tanto comunes como variables en la línea de productos. Cada conjunto de características define un programa único en una SPL. (Cabello, 2008). En 1990 (Kang, et al., 1990) introdujeron la primera notación para el modelado de características, a partir de entonces se han propuesto muchas extensiones y mejoras sobre dicho modelo. Una de las notaciones para diseñar

72 56 CAPÍTULO 2 modelos de características más extendida y aceptada en la actualidad es la propuesta en (K. Czarnecki y Antkiewicz, 2005). La notación Czarnecki propone cuatro tipos de relaciones: obligatorio, opcional, alternativa y relación or. En estas relaciones existe siempre una característica padre y una (en el caso de relaciones obligatorias u opcionales) o más (en el caso de relaciones alternativas y relaciones or) características hijas. Para este proyecto se utilizará este tipo de notación y algunos aspectos propios. (D Batory, et al., 2006)Definen un Modelo de Características de dos formas: como un conjunto de características organizadas jerárquicamente y como un lenguaje para especificar productos en una SPL. Utilizan un diagrama de características para representar gráficamente un modelo de características. Su trabajo señala que las relaciones entre un padre (o mezcla) de características y sus hijos (o subcaracterísticas) son categorizadas como: and (y)- todas las subcaracterísticas deben ser seleccionadas xor alternative (o)- solamente una subcaracterística puede ser seleccionada or (or)- una o más pueden ser seleccionadas mandatory (obligatorio)- características que son requeridas optional (opcional)- características que son opcionales. Su notación gráfica se muestra en la figura 21.

73 ESTADO DEL ARTE 57 Figura 21. Notación gráfica utilizada en el Modelo de Características clásico (Batory et al., 2006) El modelado de características es una actividad principal de la ingeniería del dominio. Una característica (feature) es definida como una característica del producto que es usado para distinguir un producto de una familia de productos relacionados (D. Batory, 2004). El modelo de características identifica la SPL en términos de la variabilidad soportada. Entre las distintas variantes disponibles del dominio, el analista del dominio de la SPL debe seleccionar (incluir o excluir) las características de acuerdo a las alternativas que son presentadas.

74 58 CAPÍTULO 2

75 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 59 3 UNA APROXIMACIÓN MDA PARA LA TRANSFORMA- CIÓN DE MODELOS 3.1 Introducción La aproximación BOM-Lazy en la que se basa esta tesis, ha sido modificada en su primera transformación, i.e. en el desarrollo de sistemas esqueletos o aquitecturas base. Dicha transformación es la temática principal de la tesis. Por ello, nos enfocaremos en el contexto de latransformación del modelo modular en los modelos componente-conector. La figura 22muestra, en el estándar SPEM el proceso de desarrollo de un sistema software esqueleto utilizado en esta tesis.

76 GetDiag(D) GetProperties(P0) GetProperties(P0) GetDiag(D) GetDiag(D) CleanDB( ) GetProperties(P0) GetProperties(P0) InferProperties(P0,P1) InferProperties(P0,P1) InferHipothesis(P1,H) InferHipothesis(P1,H) Getiag(D) InferHipothesis(P1,H) InferProperties(P0,P1) CleanDB( ) InferProperties(P0,P1) InferHipothesis(P1,H) 60 CAPÍTULO 3 INTERACTION MODEL UI Cnct IM KB MODULAR MODEL INFERENCE MOTOR USER INTERFACE KNOWLEDGE BASE <<in>> <<in>> DiagnosticExpertSystems INFERENCE MOTOR View Reasoning Hypothesis PropertyLevel number:integer one many same change oportunistic deductive Actor UseCase name:string name:string [1..*] usecasebyactor <<in>> Obtain domain features <<out>> <<in>> Build Behavoiur-Skeleton (execute transformation) <<out>> USER INTERFACE CONNECTOR FEATURE MODEL DOMAIN FEATURES (an instance of Feature Model) <<in>> KNOWLEDGE BASE COMPONENT-CONNECTOR MODEL QVT Figura 22. Proceso de desarrollo de un sistema software esqueleto (mostrado en SPEM)

77 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 61 La transformación involucrada, consiste en transformar un modelo modular (arquitectura genérica) en varios modelos de componente-conector (esqueletos o arquitecturas base de la SPL). Cabe señalar quela arquitectura genérica es compartida por todos las arquitecturas base,ya que ésta describe las partes comunes de los DES. Específicamente, esta transformación produce un modelo de componentes y conectores (denominado modelo C-C-C), toma como entrada el modelo modular, una instancia del modelo de características(que captura la variabilidad del dominio concreto), y un modelo de interaccion representado mediante undiagrama de secuencias que otorga que existe intra/entre los elementos arquitectónicos del sistema software, i.e. de un DES). La figura 23 muestra una metáfora visual de la transformación. INTERACTION MODEL in MODULAR MODEL in Transform out C-C MODEL in Instance of FEATURE MODEL Figura 23. Metafora visual de la transformaciondel modelo modular al modelo de C-C-C Esta misma situación, expresada en los niveles del estándar MOF, presentada en la figura 24. es

78 62 CAPÍTULO 3 conforms_to M3 META OBJECT FACILITY conforms_to conforms_to conforms_to conforms_to M2 FEATURE METAMODEL INTERACTION METAMODEL MODULAR METAMODEL relations C-C METAMODEL conforms_to conforms_to conforms_to transforms_to conforms_to M1 FEATURE MODEL INTERACTION MODEL MODULAR MODEL C-C MODEL instance_of M0 Instance FEATURE MODEL TRANSFORMATION Figura 24. La transformación del modelo modular al de C-C, expresado en niveles de MOF 3.2 Proceso de transformación del modelo modular al modelo de componentes-conectores-comportamiento Con el fin delograrlas transformacionesentrelosmodelos, un proceso que permite el diseño de un modelo C-C, así como las tareas y elementos involucrados en el proceso de transformación son mostrados en la figura 25. En dicha figura se muestra que las especificaciones del metamodelo modular, el metamodelo C-C-C, el metamodelo de características, son los elementos requeridos para inicializar este proceso. A continuación son identificadas y especificadas las relaciones de correspondencia entre los metamodelos modular, C-C y el de características. Para esta tarea son usados el lenguaje QVT-Relational y la notación de MOF.

79 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 63 Todas estas tareas son realizadas sólo una vez, dado que sus productos (elementos) son usados como templates. La tarea del diseño de los modelos (modulary de características) es llevada a cabo tantas veces como sea requerida. El modelo modular, una instancia del modelo de características, y las relaciones establecidas ente los metamodelos modular, de caracteristicas y el C-C-C son usadas como fuente en la tarea de transformación, para producir el modelo C-C-C.

80 64 CAPÍTULO 3 TO SPECIFY METAMODELS TO INDENTIFY RELATIONS OF CORRESPONDENCES AMONG METAMODELS TO SPECIFY RELATIONS OF CORRESPONDENCES AMONG METAMODELS Modular Metamodel C-C Metamodel and Interaction Metamodel QVT- Relations Feature Metamodel C-C Behavior-Skeleton Model T Modular Model Interaction Model Instance of Feature Model TO TRANSFORM: MODULAR MODEL INTO C-C BEHAVIOR-SKELETON MODEL TO DESIGN MODULAR MODEL TO OBTAIN AN INSTANCE OF FEATURE MODEL TO DESIGN FEATURE MODEL KEY: Task that is performed only one time Task that can be perfomed several times Figura 25.Proceso para la trasformación

81 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS Especificación de los Metamodelos Todo metamodelo ayuda a representar uniformemente un concepto o un dominio. En el caso de esta tesis, el dominio elegido son los DES. Dentro del contexto de la Ingeniería Dirigida por Modelos (MDE), la especificación de los metamodelos es de relevante importancia para el modelado de los sistemas software, ya que los metamodelos sirven como plantillas para crear los modelos, dado que en un metamodelo se representan los elementos de los modelos, que conforman a dicho metamodelo(i.e. los modelos son instancias de los metamodelos), y cómo están relacionados entre sí. De tal forma que, al crear un modelo, éste contendrá sólo lo que está especificado en su respectivo metamodelo, permitiendo mantener consistencia entre los modelos generados (como instancias del metamodelo o como salidas al ejecutarse la transformación de modelo a modelo). En esta tesis se especificaron el metamodelo de características, el metamodelo modular, el metamodelo de componentes-conectores con comportamiento, el modelo de características, el modelo modular y el modelo de componentes-conectores con comportamiento (un híbrido creado exprofeso para esta tesis que concatena el modelo de componentes-conectores con el modelo de interacción). La diferentes relaciones entre los metamodelos,son guía para la implementación de las reglas de transformación de los modelos, ya que éstas reglas de correspondencia especifican dichas relaciones mediante mappings entre los metamodelos, haciendo uso de un lenguaje específico, como el QVT- Relational. Dentro del software uno de las definiciones más difundidas sobre este término es ladada dentro de UML, donde se usa un metamodelo para cada uno de los nueve modelos que forman a este lenguaje.

82 66 CAPÍTULO 3 En (Gašević, et al., 2006) un metamodelo es definido como: una especificación de un modelo para una clase de sistema bajo estudio. Donde cada sistema bajo estudio en la clase, es él mismo, un modelo válido, expresado en un cierto lenguaje de modelado. Un metamodelo establece lo que puede ser expresado como válido en el modelo, por ejemplo UML describe con precisión y detalle el significado de una clase, un atributo, y el significado entre la relación de estos dos conceptos. De hecho un metamodelo es un modelo de un lenguaje de modelado(seidewitz, 2003). En la figura 26 se muestra mediante un diagrama de clases de UML, la relación entre el sistema bajo estudio y un lenguaje expresado en un lenguaje de modelado específico. En este caso la clase Meta-modelo es el lenguaje de modelo que contiene la terminología y aseveraciones que define a la clase modelo. Figura 26.Correspondencia entre metamodelo, modelo y sistema (Gasevic et al, 2006) Especificación del Metamodelo de Características El Metamodelo de Características propuesto en esta tesis es presentado en la figura 27, el cual representa de forma uniforme y explícita, las características, sus relaciones y restricciones. La clase FeatureModel representa a un- Modelo de Características en sí. Una clase FeatureModel se puede componer tanto de características (clase Feature) como de relaciones(clase RelationShip). Un Modelo de Características también debe de tener una función raíz,

83 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 67 que se representa mediante la función rootfeature, que se corresponde con el dominio. Además de la función raíz, el modelo debe de tener características (o puntos de variabilidad) y subcaracterísticas (o variantes de los puntos de variabilidad), en donde la subcaracterística tiene una característica padre. La información de la característica se expresa en términos de sus atributos, por lo que una característica puede tener varios atributos. El atributo expresa información que es complementario a una clase de características y se puede utilizar para describir las características paramétricas. La clase Relationship tiene como descendientes, por un lado a BinaryRelationship, GrouppedRelationship, y por otro lado StructuralRelationship, ConstraintRelationship y DependencyRelationship. Las multiplicidades de las características son representadas a nivel de la relación mediante la clase CardinalityElement. Esta clase nos permite definir fácilmente las relaciones, XOR, OR, mandatory y opcional de manera explícita, por medio de cardinalidades. La cardinalidad máxima es el límite superior, y la cardinalidad mínima es el límite inferior. Los tipos de relaciones entre los elementos se clasifican en dos grupos ortogonales: binarias vs grupales. Las relaciones binarias definen relaciones entre dos características individuales. A su vez, las relaciones se agrupan un conjunto de relaciones entre una característica única y un grupo de hijos. verticales vs horizontales. Las relaciones verticales definen la estructura jerárquica de un Modelo de Características, quien tiene un límite superior e inferior. Estos límites especifican el mínimo y el máximo número de características que pueden ser instanciadas (independientemente del número total de instancias). Las relaciones horizontales definen dependencias y restricciones entre características, en don-

84 68 CAPÍTULO 3 de la relación de dependencia tiene un límite superior e inferior. Sin embargo, las relaciones verticales pueden ser binarias y agrupadas, mientras que las relaciones horizontales sólo pueden ser binarias. Las relaciones verticales y binarias se definen como relaciones estructurales entre dos características: padre e hijo. Estas pueden ser obligatorias u opcionales dependiendo del valor del límite inferior y superior, indicando cuantas instancias de la característica hijo están permitidas. Nuestra propuesta establece la siguiente clasificación de acuerdo a la cardinalidad. Hay tres opciones que son obligatorias: mandatory [1..1], mandatory [1..*] y mandatory [n..m] donde 0 n m, m 1 y dos formas opcionales: opcional [0..1] y opcional [0..*]. Las relaciones verticales y agrupadas son un conjunto de relaciones jerárquicas en donde una característica hijo tiene una característica padre. Estas relaciones son: XOR (i.e. selección de uno, i.e. cardinalidad de [1..1]), y OR. La relación OR tiene un valor minimo ny uno máximo n1, i.e. [n..m] en donde la cardinalidad es 0 n m, and m 1. Las relaciones horizontales y binarias son especificadas mediante dos características y no expresan ninguna jerarquía. Estas son relacionesque expresan restricciones para implicación (implies) exclusión (excludes) y dependencia(uses). Estasrelaciones d permiten combinaciones de características en el modelo, por ejemplo: Relación implies: significa que si una instancia de la característica A existe, al menos también una instancia de la característica B debe de existir. Relación excludes: significa que si una instancia de la característica A existe, no puede existir ninguna instancia de la característica B y viceversa. Relación uses: Una característica estará relacionada con una (o más) característica en específico. Esta relación estará definida en el nivel de configuración y especificará una instancia específica de la característica en sí.

85 Figura 27.Metamodelo de Características UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 69

86 70 CAPÍTULO Especificando el Metamodelo Modular Para representar la arquitectura genérica de los SE se ha utilizado el metamodelo de la vista modular definido en (Bass, et al., 2003). La figura 28 muestra el Metamodelo de la Vista Modular empleado para representar las arquitecturas genéricas. En él se muestra que un modelo modular representado por la metaclase ModulesModelcontiene un conjunto de módulos representado por la clase TModules, que se vinculan mediante una serie de relaciones representadas por la metaclase Relation. En el metamodelo descrito se establecen relaciones de asociación binarias entre metaclases (asociación simple, composición y generalización). Cada vínculo o relación entre dos metaclases está etiquetado en ambos extremos (a excepción de la generalización) para indicar la navegabilidad entre una y otra metaclase, además de la especificación de su cardinalidad. Así por ejemplo, la composición entre las metaclases Module y Function del metamodelo modular referido, en la figura 28se lee: una instancia Module está compuesta por unainstancia Function (etiqueta: function). Lo mismo se aplica para todas las demás asociaciones. El Metamodelo Modular presentado en la figura 28, tiene como metaclaseraíz a ModulesModel, que contiene como atributo a name, que sirve para identificar a un modelo modular a nivel de instancia. La metaclase raíz está compuesta básicamente de las metaclases de tipo TModuley de tipo Relation, los cuales definen propiamente a unmodeloarquitectónico de software, pero lo que caracteriza a un modelo modular es el tipo de elementosy relaciones que la conforman. Como se puede apreciar en la figura 28, cada uno estos tipos tiene como atributo común a name, el cual es generalizado en su metaclase correspondiente. Este atributo permite la identificación de cada elemento a nivel de instanciación. Los tipos de meta clases contenidos en TModuleson:Module, Container y Relation. Moduleestá compuesto por la metaclasefunction. Puesto que la fun-

87 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 71 cióndescribe la naturaleza de una instancia de la metaclase Module (i.e. delmódulo), solo hay una, en cambio un módulo puede llegar a tener varias funciones ya que ellas corresponden a tareas específicas que competen a su función. Otro tipo de elemento del metamodeloes Layer, se puede apreciar que esta metaclase está asociada con varias metaclases. Nótese que Layerno se vincula directamente con las instancias de la metaclase Module, ésta debe forzosamente estar incluidas dentro de un un Container. Por su parte una metaclaselayergeneraliza a la metaclase Uses. Los otros tipos de metaclases de esta vista modular, corresponde a los tipos de relaciones que se pueden establecer entre sus elementos, las cuales son: Uses ydecomposition. Algunas fuentes bibliográficaslasdesignan como estilos arquitectónicos (Clements y Krueger, 2002; Shaw y Garlan, 1996). La relaciónuses, vincula a instancias de Moduleentre sí. Como se puede apreciar en lafigura 28, se usan dos enlaces de asociación para estos vínculos, un enlace va de lainstancia que usa (a un módulo), y el otro enlace va hacia la instancia usada.

88 72 CAPÍTULO 3 Figura 28. Metamodelo Modular

89 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 73 A continuación, mediante la tabla 2,se presenta la descripción de cada una de las metaclases que integran el metamodelo modular. CLASE FUNCION Establece el nombre a nivel de instancia del módulo en el modelo. Establece la tarea que hará el modulo en el sistema. Especifica cada módulo del modelo. Especifica la clase contenedora. Especifica la función que tendrá el módulo. Determina el numero de capa en el que se encontrará cada modulo(capa, nivel de prioridad). Determina las respectias funciones entre modulos. Determina que servicios usa cada módulo.. Establece que toos los modulos pueden ser derivados en modulos mas pequeños. Tabla 2.Descripción de las clases que pertenecen al Metamodelo Modular

90 74 CAPÍTULO Especificando el Metamodelo de Componentes y Conectores. Para representar las arquitecturas base, se ha utilizado una versión simplificada del metamodelo de componentes y conectores(a partir de ahora denominado metamodelo C-C) definido en (Bass, et al., 2003), el cual se muestra en la Figura 29. En dicha figura, se aprecia que un modelo C-C se forma por sus elementosfundamentales(conjunto de componentes y de conectore)y su metaclase Relation. Todos los vínculos entre sus metaclases están etiquetados en ambos extremos para poder navegar entre ellos (como se hizo con el Metamodelo Modular). Los componentes proporcionan una serie de servicios a través de un conjunto de puertos, y los conectores se encargan de conectar mediante sus roles los diferentes puertos entre diversos componentes.los componentes por su parte, están constituidos por los servicios que una instancia que estos prestan, y por los puertos por donde éstos se llegan a comunicar. Los servicios de un componente, modelan su comportamiento al tiempo de ejecución. Los puertos son los canales por donde se accede al servicio, el de entrada es usado para comunicarle información que éste solicita y el de salida se usa para comunicar sus resultados, por eso su cardinalidad mínima ha sido fijada con el valor de 1, pues se considera que algo debe entrar o salir de un componente. En el caso de los conectores, ellos están integrados por sus roles que son los que llegan a interactuar con los puertos, denotándose esto último en los enlaces de asociación mostradas en el metamodelo. Esta interconexión entre roles y puertos permite la interacción entre componentes a través de los conectores, la cual sigue un patróndeterminado por el tipo de relación que se forma entre estos elementos, por esto la metaclase Roleincluye como uno de sus atributos a typepara que pueda adaptarse a cada clase de relación. Las relaciones (Relations) entre los elementos de un modelo C-C pueden ser de diferentes tipos: SharedData, PipeFilter, ClientServer, PeerToPeer y PublishSubscribe.

91 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 75 Lo anterior es mostrado en la Figura 29 mediante la especialización de la metaclase Relation.

92 76 CAPÍTULO 3 Figura 29. Metamodelo de Componentes y Conectores

93 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 77 En la tabla 3se describe cada una de las clases que conforman el metamodelo C-C. CLASE FUNCIÓN El nombre del modelo es especificado mediante la metaclase CCModel. Los componentes y conectores son especializaciones de la metaclase TComponent Un componente es un elemento que captura la funcionalidad del sistema. Está formado por uno o más puertos de entrada y de salida, cuyo tipo es una determinada interfaz. Los componentes interaccionan con el resto de elementos de la arquitectura a través de sus puertos. Un conector es un elemento del sistema que actúa como coordinador entre varios elementos. Se compone de un conjunto de roles de entrada y salida. Los conectores conectan y sincronizan componentes, y a su vez, a otros conectores, a través de sus roles. Los conectores y componentes pueden prestar o recibir un servicio, especificado por un nombre y un tipo. Las respectivas relaciones entre componentes y conectores, son contermpladas mediantes esta metaclase. Los datos que podrían ser compartidos a nivel de modelo, mediante la instanciación de la metaclase ShareData PiperFilter funciona como filtro a nivel de instancia. Ésta es una metaclase opcional, ya que puede ser incorporada o no al metamodelo.

94 78 CAPÍTULO 3 Registra a todos los posibles clientes y el servicio que utilizaran. Clase que a nivel de modelo determina los puntos en los que trabajaran los componentes. Se encarga de registrar el posible servicio, ya sea que se publique o se solicite. Tabla 3.Descripcion detallada de las clases que componen al metamodelo de componentes y conectores. 3.4 Relaciones entre el Metamodelo Modular y el Metamodelo de Componentes- Conectores Se deben establecer reglas de correspondencia entre metamodelos, las cuales marcarán la pauta para la realización de la transformación a nivel de modelo. A continuación se muestran de manera detallada las reglas existentes entre el Metamodelo Modular y el Metamodelo C-C Identificando relaciones de correspondencia Para definir las relaciones entre metamodelos, se ha elegido el lenguaje estándar QVT-Relational. La transformación establece correspondencias entre los elementos de los modelos origen y los elementos del modelo destino.estas correspondencias son entre los elementos de los modelos origen(modelo modular) y los elementos del modelo destino (modelo componente-conector). Las reglas consideradas en las relaciones de los elementos son del tipo check-only y enforcecheckonly comprueba que al menos, existe algún objeto que valida el patrón definido en el dominio.enforce, provoca que el patrón

95 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 79 del dominio dse aplique siempre y sirve para crear los elementos del Metamodelo C-C. La tabla 4 muestra, de forma resumida, algunas de las relaciones de correspondencia identificadasentre el Metamodelo Modular, el Metamodelo de Característicasy el Metamodelo C-C-, junto con los elementos implicados en cada una de ellas.

96 80 CAPÍTULO 3 RELATION TYPE MODULAR METAMO- DEL CLASS FEATURE METAMO- DEL CLASS C-C METAMODEL CLASS ModulesModel2ComponentsModel Top ModulesModel Diagnosis CCModel UseCase2Connector - ModulesModel UseCase Connector Module2Component - Module Actor, UseCase Component, Connector Module2RolePort - Module UseCase Role, Port, Connector, Component ConnectRoleAndPort Role, Port Function2Service - Function Port, Service Function2Relation - Function PeerToPeer, Relation Tabla 4. Algunas relaciones identificadas entre el metamodelo modular, el metamodelo de características y el metamodelo C-C

97 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS Especificando relaciones de correspondencia En esta sección se explican detalladamente todas las reglasidentificadas e implementadas para poder llevar a cabo la transformación. De cada una de ellas, se adjunta una descripción, la implementación expresada en la notación diagramática que proporciona QVT y los patrones que codifican. En la transformación intervienen tres dominios el dominio:mdomain (del metamodelo modular), el dominio dcmdomain (del modelo de caracteristicas) y el dominio ccdomain (del metamodelo C-C). El dominio modular y el dominio del modelo de caracteristicas son de tipo «checkonly» (indicado con una «C» adjunta a la flecha del dominio). Este modificador comprueba que, al menos, existe algún objeto que valida el patrón definido en el dominio. Si no existe tal objeto, y puesto que la transformación se ejecuta en el sentido del dominio ccdomain, la aplicación de la regla no produce efectos en tales dominios. Por su parte, el dominio componente conector es de tipo «enforce» (marcado con una «E»). Este modificador provoca que el patrón del dominio deba poderse aplicar siempre. En caso de que no haya objetos que validen el patrón, la regla deberá crear un objeto que sí lo cumpla y con ello se hace cierta la aplicación de la regla. La regla «ModulesModel2ComponentsModel» es de tipo top-level y será invocada en primer lugar, mientras que el resto de reglas son de tipo «non-top-level» e irán siendo invocadas a través de las cláusulas«where» de las reglas. Relación ModulesModel2ComponentsModel Esta relación transforma el elemento modulesmodel del Metamodelo Modular en el elemento CCModel en el Metamodelo C-C, asignándole el mismo nombre. Desde la cláusula «where»,es invocada la regla «UseCaseToConnector».

98 82 CAPÍTULO 3 Figura 30. Diagrama de la relación ModulesModel2ComponentsModel Relación UseCase2Connector Esta regla crea, por cada uno de los casos de uso del modelo de caracteristicas, un conector en el modelo C-C, tomando el nombre del caso de uso seguido de la palabra «Connector». Por último, la cláusula «where»,indica que la relación «Module2Component» es postcondición de la regla «UseCase2Connector», y que ésta última se debe poder aplicar correctamente tras la aplicación de «UseCase2Connector». Figura 31. Diagrama de la relación UseCase2Connector

99 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 83 Relación Module2Component Esta regla crea, por cada módulo del modelo modular, un componente en el modelo C C, obteniendo su nombre a través de una llamada a la query«getcomponentname». Si el módulo es UserInterface, el nombre del componente será el nombre del módulo seguido del nombre de la variable actor que accede a ese módulo. Si el módulo es el InferenceMotor o KnowledegeBase el nombre del componente será el tipo de razonamiento (deductive, o differential) obtenido de la variable reasoning del modelo de variabilidad seguido del nombre del módulo. Por último, si el módulo es la UserInterface, desde la cláusula «where», es invocada la regla «Module2RolePort» con el módulo y los casos de uso a los que accede el actor, que interactuará con la interfaz del sistema. En el resto de módulos se invoca la regla «Module2RolePort» con los casos de uso del modelo de caracteristicas. A continuación, en todos los casos, es invocada la regla «Function2Relation». Figura 32. Diagrama de la relación Module2Component

100 84 CAPÍTULO 3 Relación Module2RolePort Esta regla crea, en cada componente del modelo C C, un puerto, asignándole el nombre del caso de uso seguido de la palabra «Port»; y en cada conector del modelo C-C, un rol, asignándole el nombre del módulo seguido de la palabra «Role». Por último, la cláusula «where»indica que las relaciones «ConnectRoleAndPort» y «Function2Service» son postcondición de la regla «Module2RolePort», y que éstas se deben poder aplicar correctamente tras la aplicación de «Module2RolePort». Figura 33. Diagrama de la relación Module2RolePort Relación ConnectRoleAndPort Esta regla relaciona elementos del modelo C-C, conecta cada puerto de los componentes con los correspondientes roles de los conectores.

101 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 85 Figura 34. Diagrama de la relación ConnectRoleAndPort Relación Function2Service Esta regla implica que una función de un módulo del modelo modular generará un servicio de un componente del modelo C C, asignándole el mismo nombre y tipo. Figura 35.Diagrama de la relación Function2service.

102 86 CAPÍTULO 3 Relación Function2Relation Esta regla implica que una función de un módulo del modelo modular generará una relación de tipo PeerToPeer en el modelo C C, relacionando un componente y un conector del modelo C C. Figura 36.Diagrama de la relación Function2Relation En la figura 37 se puede apreciar el orden en el que se ejecutan las relaciones correspondiente a la transformación del modelo modular al modelo C C. El orden de dicha transformación es restrictivo al considerar que unas relaciones deben de generarse antes que otras, para cumplir con ciertas condiciones. Figura 37. Orden de relaciones

103 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 87 De la figura38 a la figura 42 se observa en que se transforma cada una de las clases de los modelos que participan en las relacionesde los metamodelos. Figura 38. Relación Module to Component Figura 39. Relación Uses to Connector Figura 40. Relación Module to Role&Port Figura 41. Relación Function to Service Figura 42. Relación Function to Relation 3.5 Diseño de los modelos Para ilustrar el diseño de modelos que conforman los metamodelos previamente especificados, se ha seleccionado el dominio de los Sistemas Expertos de Diagnóstico (DES).

104 88 CAPÍTULO El dominio: los Sistemas Expertos de Diagnóstico En la literatura existen muchas definiciones de los Sistemas Expertos, pero todas ellas coinciden en que éstos son sistemas que poseen razonamientos, habilidades y conocimientos de un dominio en particular para resolver los problemas de forma similar a la de un ser humano. De forma general se puede decir que los Sistemas Expertos capturan el conocimiento de expertos y tratan de imitar sus procesos de razonamiento para resolver problemas en un dominio específico. Un estudio de campo realizado por (Cabello, 2008) muestra que los Sistemas Expertos basados en reglas tienen tres elementos que conforman una arquitectura básica y que son: una Base de Conocimientos, un Motor de Inferencia y una Interfaz del Usuario (ver figura 43). Estos elementos son independientes y se encuentran en unidades separadas. El control es independiente de los datos y es llevado a cabo por el Motor de Inferencia durante el proceso de inferencia, usando diferentes estrategias de razonamiento. Los datos se almacenan en una memoria de trabajo (almacenamiento temporal de información dinámica).la representación del conocimiento está capturada por una serie de reglas que constituyen la Base de Conocimientos. Las entradas y salidas de información (interacción del usuario con el sistema) se llevan a cabo a través de la Interfaz delusuario. Figura 43. Elementos básicos de un Sistema Experto Según la tarea que desarrollan, existen diferentes tipos de sistemas de expertos. Podemos encontrar sistemas expertos para el diagnóstico, la interpretación, la predicción, entre otros.

105 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 89 Dado que el diagnóstico es la principal tarea de desarrollo de estos sistemas, se ha seleccionado a los Sistemas Expertos de Diagnóstico (DES) como el caso de estudio o dominio para modelar la variabilidad en esta tesis. El objetivo principal de los DES es capturar el estado de una entidad de una serie de datos (variables observables) y producir un diagnóstico. El dominio de los DES incluye sistemas para diagnóstico médico, el diagnóstico educativo, y el diagnóstico de emergencia, entre otros muchos. La representación del conocimiento es capturado por medio de reglas del tipo: IF <antecedente> THEN <conclusión>, que constituyen la Base de Conocimientos. El control es independiente de los datos y se lleva a cabo por el Motor de Inferencia en los procesos de inferencia utilizando diferentes estrategias de razonamiento. La entrada y la salida de la información se realizan a través de la Interfaz de Usuario. Con base en el análisis de campo realizado en (Cabello, 2008), se concluye que la variabilidad de los DES presenta dos tipos de variabilidad ortogonal: i) La variabilidad del dominio - dada por las características asociadas con el tipo de diagnóstico (i.e. el diagnóstico médico), por ejemplo las características consideradas para la construcción de la arquitectura de un DES Médico. Las características asociadas con el proceso del diagnóstico, se relacionan con el comportamiento de los DES. ii) La variabilidad del dominio de aplicación.- dada por las características de los productos finales, por ejemplo las características plasmadas en un sistema (DES Médico) para enfermedades cariovasculares. Las características asociadas con los requisitos del usuario, se relacionan con la estructura de los DES.

106 90 CAPÍTULO 3 En este trabajo sólo está presente la variabilidad del dominio,la cual está dada por: i) El proceso de diagnóstico.- a través de las siguientes características: i) Lasvistas: durante el proceso del diagnóstico, las propiedades de una entidad pueden variar (i.e. diferentes vistas) o pueden ser siempre las mismas (i.e. mismas vistas). ii) Los niveles de abstarcción de las diferentes propiedades de las. iii) El número de hipótesis que se obtienen como resultado del diagnóstico. iv) Los diferentes tipos de razonamiento que aplica el Motor de Inferencia al realizar un diagnóstico. ii) Los requisitos del usuario(modelados en un diagrama de casos de uso UML) a través de las siguientes características: i) Número de casos de uso del sistema,donde se plasma cómo el sistema interactúa con el medio ambiente (usuarios finales). ii) Número de actores: número de usuarios finales del sistema. iii) La utilización casos por cada actor: un actor (usuario final) puede acceder a los diferentes casos su uso. La figura 44 muestra una metáfora visual de un proceso de diagnóstico, y la figura 45 muestra el diagrama de casos de uso; ambos referentes al caso de estudio del diagnóstico médico.

107 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 91 ENFERMEDAD 4 ENFERMEDAD 1 ENFERMEDAD 3 ENFERMEDAD 2 ENFERMEDAD 5 signos y síntomas de grano fino síndrome 1 síndrome 2 signos y síntomas de grano grueso Figura 44.Metáfora visual del razonamiento utilizado en elproceso de diagnóstico médico Doctor Get Clinical Diagnosis Get Diagnosis <<include>> Get Laboratory Diagnosis Laboratory member Get Therapy Figura 45.Diagrama de casos de uso de un diagnóstico médico Modelo de interacción de los elementos de lossistemas Expertos de Diagnóstico Con el fin de diseñar un modelo C-C que represente la arquitectura de los DES, es necesario definir todos los elementos arquitectónicos que conforman dicho modelo- y las interacciones entre ellos. Las interacciones entre los componentes de dicho modelo puede entenderse como la comunicación que existe entre ellos, misma que se realiza a través de los conectores, quienes actúan como coordinadores de dicha comunica-

108 92 CAPÍTULO 3 ción. Las interacciones constituyen un mecanismo común para describir lo que los sistemas producen a diferente nivel de detalle. En el ámbito de la arquitectura de software son útiles para describir la comunicación entre los elementos de un modelo, como se señala en (Hofmsteir, 2005). La comunicación se realiza mediante servicios que envían/reciben los elementos arquitectónicos (componentes y conectores) de los DES. En el modelo de componentes y conectores, una interacción es usada para especificar la manera en que los conectores vinculan a los componentes, definiendo el tipo y número de conectores y puertos requeridos, con lo cual se facilita la tarea de identificar cuál relación representa mejor su comportamiento resultante. Una interacción se forma al desglosar cada servicio conforme se incorporan los diferentes escenarios de los requisitos detectados por el arquitecto de software. Cada escenario hace que los servicios, que le corresponden a los componentes, se vayan desglosando de acuerdo a la secuencia y a lasoperaciones específicas que ellos proveen o requieren. Las interacciones entre los componentes han sido modeladas en el trabajo presentado en(limón y Ramos, 2006) donde se usaron los mapas de casos de usos para detectar posibles cruzamientos de interacciones; sin embargo,éstos sólo revelan los componentes implicados y la ruta que siguen los escenarios. En esta tesis, lo que se requiere es detallar las posibles interacciones que se tienen entre ellos, centrando la atención en los servicios que llegan a requerir y proporcionar. Esta interacción es representada mediante un modelo de interacción o diagrama de secuenciasde UML 2.0(OMG, 2004). En esta tesis se considera que los objetos son instancias de componentes, y las operaciones son los servicios que se proveen y requieren.la propuesta hecha para modelar las interacciones de los elementos deun modelo C-Ces ilustrada mediante un ejemplo, mostrado en la Figura 46. Este diagrama está compuesto por cincoobjetos componentes: UserInterfacelab (UIL), InferenceMotor (IM), KnowledgeBase (KB) y tres objeto conector: Connector(CNCT). Cada elementoagrupa a

109 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 93 un conjunto de mensajes que se transmiten utilizando los servicios de los componentes. La secuencia en que ocurren los mensajes, desde una perspectiva de línea de tiempo vertical, es en orden descendente siendo el mensaje siguiente el de ejecución posterior. La activación de los mensajes obedece a los eventos provocados por los usuarios del sistema o por las condiciones de ejecución del sistema.la comunicación realizada a través de los mensajes puede ser síncrona o asíncrona. En el caso que ocupa a esta tesis (DES) la comunicación es síncrona, como puede observarse en la figura 46, la cual presenta el diagrama de secuencias en UML de un sistema experto que realiza el diagnóstico médico. Figura 46.Diagrama de secuencias del caso: diagnostico medico

110 94 CAPÍTULO Modelo de Características de los Sistemas Expertos de Diagnóstico (modelo de variabilidad) Las partes de los DESson expresadas atravésde sus características, en una organización jerárquica, mediante un modelo de características. En esta tesis, la variabilidad de los DES es plasmada mediante un modelo de características el cual está, conformado por losseis puntos de variabilidad (view, reasoning, hypothesis, porperty level, actor, use case)con diferentes valores llamados variantes. En elmodelo presentado en la figura 47, las caracterísitcasview, reasoning, hypothesisdeben tomar como valor una sola variante, lo cual se muestra con la relación XOR (select one). Las otras características porperty level, actor, use case toman sus valores por medio de sus atributos. Figura 47. Modelo de Características Como se observa, el modelo organiza las características en una composición jerárquica, donde la opcionalidad y la obligatoriedad están presentes. Ade-

111 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 95 más de establecer una relación jerárquica, el Modelo de Características también permite restricciones entre características de árbol, estas restricciones son la implicación (implies)el uso(uses)y la exclusión(excludes). El símbolo indica que las características vista de la entidad(view), nivel de propiedad(property level) y número de hipótesis tienen una cardinalidad de [1..1]. La cardinalidad es un intervalo que denota con qué frecuencia una característica, con sus sub-características pueden ser clonadas en una configuración. La cardinalidad de [1..1] indica que estas características deben de existir una y no más de una vez. Por otro lado el símbolo indica que las características: property level, Usescase y actorspueden ser utilizadas de 1 a muchas veces [1..*].Las características de vista de la entidad(views), el razonamiento(reasoning)y la hipótesis(hypotheses) no contienen cardinalidades explícitas. Al tener un XORse toma en cuenta que puede ser opcional [0..1] y esto coincide con la semántica de la tabla de verdad respectiva del XOR. Paraeldominio de los DES,en el Modelo de Características se utilizaron estas restricciones para involucrar la relación que existe entre las vistas de las entidades(view), los razonamientos(reasoning) y los números de hipótesis(hypothesis), como a continuación se enlistan: si la vista de la entidad no cambia, esto implica que el tipo de razonamiento será deductive y la hipótesis sólo será una. si la vista de la entidad no cambia, se excluirá el razonamiento differentialy el número de hipótesis será de más de una. si el tipo de razonamiento es differential, esto implica que las hipótesis serán varias y la vista de la entidad cambiará. De esta forma las tres características (view, reasoninge hipothesis) están relacionadas con las restricciones de exclusión (excludes) y de implicación (implies ).

112 96 CAPÍTULO 3 Otro tipo de restricción utilizada en el Modelo de Características es la relación de dependencia (uses) que un actor puede acceder a varios casos de uso.con lo cual se construye lasiguiente restricción entre los puntos de variabilidadactor y UseCases: Actor uses UseCases La tabla 5muestra los tipos de restricciones existentes entre las variantes de los puntos de variabilidad o características. En la tabla 6 se presentan las reglas de transitividad de la restricción (<<implies>>). sameview implies deductivereasoning changeview implies oportunisticreasoning deductivereasoning implies onehipothesis opotunisticreasoning implies manyhipothesis sameview excludes oportunisticreasoning changeview excludes deductivereasoning deductivereasoning excludes manyhipothesis opotunisticreasoning excludes onehipothesis Tabla 5. Restricciones existentes entre variantes en el Modelo de Características If sameview implies deductivereasoning and deductivereasoning implies onehipothesis then sameview implies onehipothesis If changeview implies opotunisticreasoning and deductivereasoning implies manyhipothesis then changeview implies manyhipothesis Tabla 6. Reglas de transitividad en la restricción implies En general, las restricciones en los Modelos de Características basados en cardinalidades requieren una buena navegación con facilidades de consulta, lo que involucra lógica, aritmética y operadores en ciertos atributos. Semán-

113 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 97 ticamente, este Modelo de Características describe un conjunto de posibles configuraciones, las cuales especifican una instancia específica del Modelo de Características Modelo Modular de los Sistemas Expertos de Diagnóstico EL modelo modular está constituido por tres módulos: InferenceMotor, KnowledgeBase y UserInterface. Dichos módulos son unidos entre sí a través de relaciones de dependencia. El módulo «InferenceMotor», establece el proceso de inferencia y la toma decisiones. El módulo «KnowledgeBase» contiene el conocimiento del dominio de aplicación. El módulo «UserInterface» establece la forma en que el usuario interactúa con el sistema. Figura 48. Modelo Modular de un Sistema Experto Modelo Componente-Conector de un Sistemas Experto de Diagnóstico A partir de la arquitectura genérica de los DES (modelo modular) se obtienenlasarquitecturas base/esqueleto (modelos C-C) de las DES.una arquitectura genérica ligada al dominio(modelo Modular de todo SE), pero existen características particulares adicionales cuya presencia/ausencia define el producto concreto. Esta situación puede requerir eliminar o añadir componentes o relaciones entre ellos, desarrollar extensiones a los componentes existentes, configurar los componentes y desarrollar elementos software es-

114 98 CAPÍTULO 3 pecíficos para las arquitecturas base. Esto implica la creación de una arquitectura base específica, cada vez que se desarrolla un producto. En este contexto, en la figura 49 se muestra una metáfora visual de dos arquitecturas base distintas derivadas de la misma arquitectura genérica. IM USER INTERFACE (UI) INFERENCE MOTOR (IM) KNOWLEDGE BASE (KB)... UI 1 UI... C1 C KB IM UI 2 C2 C3 KB MODULAR MODEL (a) COMPONENT-CONNECTOR MODEL (b) Figura 49.Metáfora visual de (a) una única arquitectura genérica, y (b) dos arquitecturas base Con el objetivo de incrementar la calidad del diseño del modelo C-C (la arquitectura)de un DES, se aplicanlasbuenas prácticas de diseño software definidas en(pressman, 1998). Para ello, se especifican una serie de patronespara calcular las arquitecturas base de los DES. A partir de los requisitos del sistema a desarrollar, que vienen dados por una instancia concreta del modelo de caracteristicas, se busca la correspondencia entre tipos de requisitos y patrones, para conseguir agrupaciones de características que lleven a la misma arquitectura base. De este modo, la transformación puede ser vista como una función T que a través de patrones calcula las arquitecturas base correspondientes. Con esta

115 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 99 función se obtiene la arquitectura base, recibiendo como parámetros la arquitectura genérica y la variabilidad del dominio, i.e. T (GenericArchitecture, Instance-VariabilityModel) = BaseArchitecture EntityView=same Reasoning= deductive PropertyLevel = 2 Hypotheses = only one Use Cases=1 Actors=1 EntityView=change Reasoning= differential PropertyLevel = 2 Hypotheses = many Use Cases=3 Actors=2 Figura 50.Metáfora visual de la función transformación Patrones de diseño utilizados en el desarrollo de los modelos componente-conector de los DES Un patrón de diseño es, una regla de tres partes, las cuales expresan una relación entre un contexto, un problema y una solución (Alexander, et al., 1977). En esta sección se detallan los patrones identificados para diseñar los modelos C-C de los DES, lo que constituye la técnica de modelado utilizada en esta tesis. Estos patrones contienen criterios y decisiones de diseño que serán codificados en las reglas de la transformación. Las reglasinvolucran a cada elemento de los modelos que intervienen en la transformación y proporcionan las directrices que definen cada elemento del modelo resultante.

116 100 CAPÍTULO 3 Patrón1. Organización Jerárquica Con la finalidad de satisfacer el criterio de buen diseño de software que establece que:«un diseño debe presentar una organización jerárquica que haga un uso inteligente del control entre los componentes del software»,se establece como criterio de diseño que el Metamodelo Modular (metamodelo origen) contiene un elemento ModulesModelcomo contenedor del resto de elementos que lo componen., A través del mismo es posible acceder a todos los elementos que conforman el metamodelo. Del mismo modo el Metamodelo C-C (metamodelo destino) contiene un elemento CCModelcomo contenedor del resto de elementos del metamodelo. Por lo tanto, la regla define que se estable una relación uno a uno, entre el elemento ModulesModeldel metamodelo origen y el elemento CCModeldel metamodelo destino. Como resultado de aplicar esta regla, a partir del elemento ModulesModelse genera un elemento CCModelcon el mismo nombre.los elementos implicados son: Elementos del Metamodelo Modular Elementos del Metamodelo C-C ModulesModel CCModel Patrón 2. Clonación del Conector Con la finalidad de satisfacer el criterio de buen diseño de software que establece que: «El diseño debe ser modular, es decir, se debe hacer una partición lógica del software en elementos que realicen funciones y subfunciones específicas», y dado que los casos de uso constituyen una división del sistema basada en la funcionalidad, se establece como criterio de diseño, que por cada caso de uso, se crea un conector que une a todos los componentes de ese caso de uso.

117 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 101 Por lo tanto, la regla define que se estable una relación uno a uno entre casos de uso y conectores. Como resultado de aplicar esta regla, el número de conectores será igual al número de casos de uso existentes en la instancia del Modelo de Carácterísticas. Los elementos implicados son: Elementos del Modelo de Características. Elementos del MetaModelo C-C UseCase Connector Figura 51.Modelo arquitectónico correspondiente a un caso de uso Patrón 3. Clonación de la Interfaz de Usuario Con la finalidad de satisfacer el criterio de buen diseño de software que establece que «Se debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los módulos y el entorno exterior», se establece como criterio de diseño que el módulo UserInterface generará un componente UserInterface distinto por cada uno de los actores que intervienen en la instancia del Modelo de caracteristicas. Cada componente tomará el nombre: «UserInterface» seguido del nombre del actor. Por lo tanto, la regla define que se estable una relación uno a uno entre actores e interfaces de usuario. Los elementos implicados son: Elementos del Metamodelo Modular Elementos del Modelo de Características Module Actor

118 102 CAPÍTULO 3 Elementos del Metamodelo C-C Component Patrón 4. Unificación de la Base de Conocimientos Dado que, cada Caso de Uso genera un modelo arquitectónico compuesto por los componentes: InferenceMotor, KnowledgeBase y UserInterface, coordinados mediante un Connector, se establece como criterio de diseño, la unificación de la KnowledegeBase en una sola, puesto que el conocimiento debe ser único para todo el sistema. Esto implica que por cada Caso de Uso existirá una vista de la KnowledgeBase distinta, donde se realiza la unión de las vistas en una, mediante la adición de puertos a dicho componente, que la unen con cada conector mediante diferentes roles. Como resultado de aplicar esta regla, la KnowledegeBasetendrá tantos puertos como vistas, es decir tendrá tantos puertos como Casos de Uso que existan para hacer funcionar el sistema. Por lo tanto, la regla define que se establece una relación de n a 1 entre los Casos de Uso y la KnowledegeBase. Los elementos implicados son: Elementos del Metamodelo Modular Elementos del Metamodelo C-C Module Component Patrón 5. Unificación del Motor de Inferencia. Además dado que el tipo de razonamiento utilizadodurante el proceso de diagnóstico viene dado por el punto decaracteristicas«reasoning» del modelo de variabilidad, la cual puede ser de dos tipos «Deductive» o «Differential», se determina el tipo de InferenceMotor que tendrá el modelo C-C. Esto implica que el InferenceMotorserá Deductiveo Differential pero no presentará los dos comportamientos simultáneamente.

119 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 103 Los elementos implicados son: Elementos del Metamodelo Modular Elementos del Modelo de Características Elementos del Metamodelo C-C Module Reasoning Component Patrón 6. Interacción de la Interfaz del Usuario Como resultado de aplicar esta regla, por cada Caso de Uso a los que puede acceder un Actor, se realiza la fusión de los componentes en uno mediante la adición de puertos al componente UserInterface que representa al Actor. Por lo tanto, la regla define que el número de puertos de cada componente UserInterfaceserá igual al número de Casos de Uso a los que puede acceder el Actorque representa alcomponenteuserinterface. Los elementos implicados son: Elementos del Metamodelo Modular Elementos del Modelo de Características Elementos delmetamodelo C-C Module Actor Component Patrón 7. Fusión de Conectores La regla define que la existencia de una relación «include» entre dos Casos de Uso implica la fusión de conectores. Un Caso de Uso incluido es un subproceso del otro. Los elementos implicados son: Elementos del Modelo de Características UseCase

120 104 CAPÍTULO 3 Elementos del Metamodelo C-C Connector Figura 52.Modelo arquitectónico correspondiente a la relación include entre dos casos de uso Ejemplos del modelado C-C de un Sistemas Experto de Diagnóstico Tomando en cuenta lo anteriormente expuesto, y para ilustrar la técnica de modelado de arquitecturas software, utilizada en esta tesis, se presentan loscasos de estudio de los sistemas expertos que realizan el diagnóstico médico y el diagnóstico de programas educativos Ejemplo del modelado C-C de un Sistemas Experto de diagnóstico médico En el diagnóstico médico, la entidad a diagnosticar es el paciente y el resultado del diagnóstico es la enfermedad que padece el paciente. En este tipo de diagnóstico se pueden considerar los siguientes casos de uso: Caso de uso 1: realizar diagnóstico clínico Caso de uso 2: realizar diagnóstico de laboratorio Caso de uso 3: obtener resultados del diagnóstico (diagnóstico integral). Los casos de uso son utilizados por dos usuarios finales distintos: el médico y el encargado del laboratorio. Los casos de uso 1 y 3 son realizados por el médico. El caso de uso 2 es realizado por el encargado del laboratorio.

121 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 105 Las propiedades son los signos y síntomas del paciente; los cuales están clasificados en dos niveles de abstracción: los de grano grueso y los de grano fino. Las propiedades del nivel 2 son los signos y síntomas de grano grueso (p.e. tos y fiebre). Las propiedades del nivel 1 son los signos y síntomas de grano fino (p.e. tos seca y fiebre continua). Las hipótesis del nivel 1 son los síndromes (p.e. ira), que son inferidos a través de las reglas del nivel 1. Las hipótesis del nivel 2 son las enfermedades (.p.e neumonía), i.e. el resultado del diagnóstico inferido a través de las reglas del último nivel. Las vistas de las propiedades que intervienen en el proceso del diagnostico, cambió, el razonamiento. El tipo de razonamiento aplicado es el diferencial. Al inicio se realiza un razonamiento deductivo el cual infiere varias hipótesis (i.e. posibles enfermedades), por lo que se invoca al razonamiento inductivo para poder diferenciar entre esas hipótesis, la hipótesis validada que es el resultado del diagnóstico (i.e. la enfermedad). El escenario del proceso del diagnóstico médico es el siguiente: Con valores de los signos y síntomas de grano grueso, es inferido el síndrome. Esta parte del proceso se realiza con el razonamiento deductivo. Dicho síndrome da lugar (por deducción) a dos o más posibles enfermedades (posibles hipótesis). Estas hipótesis deben ser validadas, por lo que con los datos de los signos y síntomas de grano fino se infiere la enfermedad (hipótesis validada) que padece el paciente. Este última parte del proceso se realiza con el razonamiento inductivo. La técnica de modelado utilizada para diseñar un sistema de diagnóstico médico, se centra en los siguientes tres pasos: 1.- Especificación de los requisitos funcionales (en un alto nivel de abstracción) mediante un diagrama UML de casos de uso. En el caso del diagnóstico

122 106 CAPÍTULO 3 médico, se tienen tres casos de uso y dos actores, en donde un actor (el doctor) accede a dos casos de uso y el otro actor (el miembro del laboratorio) accede a un sólo caso de uso. Doctor Get Clinical Diagnosis Get Diagnosis <<include>> Get Laboratory Diagnosis Laboratory member Get Therapy Figura 53.Diagrama UML-casos de uso para un sistema de diagnóstico médico 2.- Configuración de un modelo arquitectónico, por cada caso de uso. En el caso de estudio contemplado (diagnóstico médico): Se cuenta con tres casos de uso, por lo que se construyen tres modelos arquitectónicos. La existencia de la relación «include» entre los casos de uso Get Diagnosis y Get Therapy implica un solo conector, para el caso de uso 1

123 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 107 SKELETON CLINICAL CLINICAL USER USER Connector 1 SKELETON INFERENCE INFERENCE MOTOR MOTOR SKELETON INFERENCE INFERENCE MOTOR MOTOR SKELETON CLINICAL CLINICAL USER USER INFERENCE MOTOR LABORATORY USER Connector 2 KNOWLEDGE SKELETON KNOWLEDGE BASE BASE SKELETON KNOWLEDGE BASE Connector 3 SKELETON KNOWLEDGE BASE a) Caso de Uso 1 b) Caso de Uso 2 c) Caso de Uso 3 Figura 54.Modelos arquitectónicos correspondientes a cada caso de uso 3.- Construcción del modelo arquitectónico final.- Los elementos arquitectónicos definidos en cada caso de uso son modificados para obtener los elementos arquitectónicos del modelo final, el cual presenta la vista de la figura 55, y está conformadocon los siguientes elementos: el componente InferenceMotor (con tres puertos) el componente KnowledegeBase (con tres puertos) el componente ClinicalUser (con dos puertos) el componente LaboratoryUser (con un puerto) el conector Coordinator 1 el conector Coordinator 2 el conector Coordinator 3

124 108 CAPÍTULO SKELETON CLINICAL USER SKELETON Connector SKELETON INFERENCE MOTOR 3 SKELETON LABORATORY USER SKELETON Connector SKELETON Connector SKELETON KNOWLEDGE BASE 3 Figura 55. Modelo arquitectónico caso diagnostico medico Ejemplo del modelado C-C de un Sistemas Experto de diagnóstico de programas educativos En el diagnóstico de programas educativos, la entidad a diagnosticar es un programa educativo de postgrado, y el resultado del diagnóstico es el nivel de desarrollo que tiene el programa educativo. Las propiedades con las que son analizadas las entidades no cambian, por lo que se genera una sola hipótesis que resulta del proceso del diagnóstico. En este caso, se ha considerado un caso de uso (obtener el diagnostico educativo al nivel de desarrollo del programa) y un usuario final que desempeña un rol. Las propiedades en este caso de estudio son los rubros y subrubros evaluados de un programa educativo. Las propiedades del nivel 0 son los subrubros

125 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 109 (p.e. control de calidad de alumnos). Las propiedades del nivel 1 son los rubros cuyo valor es inferido al aplicarse las reglas del nivel 1 (p.e. plan de estudios). La hipótesis es la calificación que se le otorga al programa educativo según su estado de desarrollo, i.e. el resultado del diagnóstico inferido a través de las reglas del nivel 2. El tipo de razonamiento aplicado es el deductivo.el escenario para el proceso del diagnóstico educativo es el siguiente: Con valores de los subrubros involucrados en la evaluación del programa educativo, es inferido por (deducción) el valor de los rubros y posteriormente es inferida la hipótesis, deduciéndose la etapa de desarrollo del programa educativo. La técnica de modelado utilizada para diseñar un sistema de diagnóstico de programas educativos, se centra en los siguientes tres pasos: 1.- Especificación de los requisitos funcionales (en un alto nivel de abstracción) mediante un diagrama UML de casos de uso. En el caso del diagnóstico de programas educativos, se tiene un sólo caso de uso y un actor (el evaluador del programa), en donde ese actor accede al único caso de uso. Figura 56. Diagrama de casos de uso correspondiente al diagnóstico de programas educativos 2.- Configuración de un modelo arquitectónico, por cada caso de uso. Como enel caso de estudio contemplado (diagnóstico de programas educativos), se cuenta con un caso de uso, se construyeun solo modelo arquitectónico.

126 110 CAPÍTULO Construcción del modelo arquitectónico final.- Los elementos arquitectónicos definidos en el caso de uso son los elementos arquitectónicos del modelo final, el cual presenta la vista de la figura 57, y está conformado con los siguientes elementos: Componente Motor de Inferencia (con 1 puerto). Componente Base de Conocimientos (con 1 puerto). Componente Interfaz del Usuario (con 1 puerto). Conector Coordinador (con tres puertos). INFERENCE MOTOR USER INTERFACE CONNECTOR KNOWLEDGE BASE Figura 57.Elementos arquitectónicos del modelo componentes y conectores 3.6 Aplicando la transformación (del modelo modular a un modelo de componentes y conectores) Para ilustrar cómo las transformaciones a nivel de modelo son aplicados en el proceso de transformación, se presenta en la figura 58 una metáfora visual.con una instancia del modelo de variabilidad del dominio (modelo de característcas), se genera una arquitectura base (modelo C-C) específica a un caso de estudio, el cual conlleva las características de la instancia del modelo de variabilidad. Esas arquitecturas base comparten la única arquitectura genérica de los DES, la cual es capturada en un modelo modular. Como un paso previo a la transformación, son especificados los metamodelos de todos los modelos que intervienen en la transformación. En la transformación son usados como fuente el modelo modular (figura 58a),el modelo de características (figura 58b)y el modelo de interacción (figura 58c)para obtener el modelo destino: un modelo C-C.

127 UNA APROXIMACIÓN MDA PARA LA TRANSFORMACIÓN DE MODELOS 111 Los tres elementos del modelo modular están unidos mediante relaciones de dependencia.como se muestra en la figura 58, un componente con sus servicios, fue producido por cada módulo con sus funciones, y las relaciones de dependencia generan un conector con sus servicios. Las relaciones establecidas en la sección de esta tesis son las reglas que se aplicaron para generar el nuevo modelo C-C (usando su correspondiente metamodelo como un template ). En este caso, fueron aplicadas las relaciones moduletocomponent y rusomodtoconnector La transformación se lleva a cabo mediante la ejecución de las QVT-Relations.

128 GetDiag(D) GetProperties(P0) GetProperties(P0) GetDiag(D) GetDiag(D) CleanDB( ) GetProperties(P0) GetProperties(P0) InferProperties(P0,P1) InferProperties(P0,P1) InferHipothesis(P1,H) InferHipothesis(P1,H) Getiag(D) InferHipothesis(P1,H) InferProperties(P0,P1) CleanDB( ) InferProperties(P0,P1) InferHipothesis(P1,H) 112 CAPÍTULO 3 IINFERENCE MOTOR USER INTERFACE (a) KNOLEDGE BASE INFERENCE MOTOR DiagnosticExpertSystems View Reasoning Hypothesis PropertyLevel number:integer Actor name:string UseCase name:string TRANSFORMATION USER INTERFACE CONNECTOR same change oportunistic one deductive many (b) usecasebyactor [1..*] QVT-Relations KNOWLEDGE BASE UI Cnct IM KB (d) (c) Figura 58. Modelos que intervienen en la transformación

129 IMPLEMENTACIÓN IMPLEMENTACIÓN En este capítulo se presenta la implementación de la transformación y su refinamiento.en la primer parte se comentan las herramientas principales que se utilizaron para obtener la transformación. En la segunda parte los costos de aprendizaje y uso de dichas herramientas. En la tercera parte, se presenta la forma en la que fueron utilizadas cada una. 4.1 Herramientas utilizadas La figura 59 describe la arquitectura de la herramienta utilizada para llevar a cabo la transformación del modelo modular al modelo C-C. Figura 59. Arquitectura de la herramienta generada a partir de la plataforma Eclipse. Para implementar la transformación se utilizó la platforma Eclipse, versión Europa. Los archivos generados con Eclipse son del tipo *.ecore. EMF es un framework para el modelado y generación de código para construir herramientas y otras aplicaciones basadas en un modelo de datos estructurados. Desde la especificación de un modelo descrito en XMI, EMF proporciona herramientas y soporte para generar modelos, además de herramientas para soportar la visualización y la edición del modelo.

130 114 CAPÍTULO 4 Con EMF se puede describir el modelo de datos en un alto nivel. Se pueden usar diagramas UML, XSD (OMG, 2003), y de interfaces Java anotadas para construir un archivo ecore con el modelo de datos de nuestra preferencia. La plataforma Eclipse es la base de: Eclipse Modeling Framework (EMF), el cual es una herramienta basada en MOF que permite modelar software de utilizando código Java y XMI como lenguaje de persistencia. Graphic Modeling Framework (GMF), el cual es una herramienta basada en MOF que permite visualizar los modelos y metamodelos como un diagrama de clases de UML. Medini, el cual es una herramienta utilizada como entorno de desarrollo para la especificación de las QVT-Relations. Medini es un plug-in de Eclipse. Las herramientas utilizadas para el metamodelado, el modelado y la transformación, así como los lenguajes utilizados, son comentados a continuación: METAMODELADO Diagrama de clases UML con notación en documentos tipo XMI especificado por EMF. Herramientas: EMF y GMF MODELADO Especificado en archivos XMI definidos por EMF Herramientas: EMF y GMF

131 IMPLEMENTACIÓN 115 TRANSFORMACIÓN Herramienta: Medini. Lenguaje: QVT-Relational LENGUAJES Java y QVT-Relational 4.2 Costos Conocimientode lenguajes Lenguaje Conocimiento Complejidad Java Básico Media Qvt-Relational Nulo Muy Alta Costo de Lenguajes (Monetario) Lenguaje Tipo Costo Java Libre Sin Costo Qvt-Relational Libre Sin Costo Conocimiento de herramientas (Uso) Herramienta. Conocimiento. Complejidad. EMF Nulo Media GMF Nulo Media Medini Nulo Alta Costo de herramientas (Monetario) Herramienta Tipo Costo EMF Libre Sin Costo

132 116 CAPÍTULO 4 GMF Libre Sin Costo Medini Libre Sin Costo 4.3 Descripción del uso de las herramientas Las relaciones entre los métamodelos fueron implementadas mediante QVT- Relational, para poder realizar la transformación de modelos.para La construcción de las reglas que utilizan las QVT para la transformación del modelo modular a uno de los modelos C-C-C, se tomó en cuenta los valores de las variantes de los puntos de variabilidad de la SPL (plasmados en el modelo de características) y el comportamiento de los elementos arquitectónicos (plasmado en el modelo de interacción). De forma tal que,teóricamente(como se vió en el capitulo 3 de esta tesis), para llevar a cabo la transformación de modelos, se recibe como entrada el modelo modular, la instancia del modelo de características; y el modelo de interacción, para generarun modelo C-C-C, i.e. un modelo componenteconector con estructura y comportamiento (la arquitectura completa de un DES); i.e. T (modelo modular, instancia_modelo características) = modelo C-C-C. misma que puede ser visualizada a través de lasfiguras22,23 y 58 de esta tesis. Pero en la implementación fue necesario realizar la transformación en dos partes. Podría decirse que la primera parte consistió en la propia transformación T y la segunda parte en un refinamiento R de esa transformación. De forma tal que,en la práctica, para llevar a cabo la transformación de modelos, se recibe como entrada el modelo modular y la instancia del modelo de características; obteniendo un modelo C-C. Posteriormente este modelo C-C es refinado haciendo uso de una instancia del modelo de interacción, para generar un modelo C-C-C, i.e. un modelo componen-

133 GetDiag(D) GetProperties(P0) GetProperties(P0) GetDiag(D) GetDiag(D) CleanDB( ) GetProperties(P0) GetProperties(P0) InferProperties(P0,P1) InferProperties(P0,P1) InferHipothesis(P1,H) InferHipothesis(P1,H) Getiag(D) InferHipothesis(P1,H) InferProperties(P0,P1) CleanDB( ) InferProperties(P0,P1) InferHipothesis(P1,H) IMPLEMENTACIÓN 117 te-conector con estructura y comportamiento (la arquitectura completa de un DES). En notación matemática se puede escribir como: T (instancia_modelo características, modelo modular) = modelo C-C, R (modelo C-C, instancia_modelo interacción) = modelo C-C-C, como puede visualizarse a través de las figuras60, 61 y 62. Instance of FEATURE MODEL INTERACTION MODEL in in MODULAR MODEL (skeleton) in Transform out C-C MODEL (skeleton) in Refine out C-C-C MODEL (behaviorskeleton) Figura 60. Metáfora visual de la transformación con refinamiento UI Cnct IM KB IINFERENCE MOTOR USER INTERFACE (a) KNOLEDGE BASE TRANSFORMATION (c) USER INTERFACE INFERENCE MOTOR CONNECTOR REFINE USER INTERFACE INFERENCE MOTOR CONNECTOR KNOWLEDGE BASE DiagnosticExpertSystems View Reasoning Hypothesis PropertyLevel Actor UseCase KNOWLEDGE BASE (e) same change one number:integer many name:string name:string [1..*] usecasebyactor (d) oportunistic deductive (b) Figura 61. Orden en el proceso de transformación

134 UI Cnct IM KB GetDiag(D) GetProperties(P0) GetProperties(P0) GetDiag(D) GetDiag(D) CleanDB( ) GetProperties(P0) GetProperties(P0) InferProperties(P0,P1) InferProperties(P0,P1) InferHipothesis(P1,H) InferHipothesis(P1,H) Getiag(D) InferHipothesis(P1,H) InferProperties(P0,P1) CleanDB( ) InferProperties(P0,P1) InferHipothesis(P1,H) 118 CAPÍTULO 4 MODULAR MODEL DiagnosticExpertSystems View Reasoning Hypothesis PropertyLevel Actor UseCase <<in>> number:integer name:string name:string same change oportunistic one deductive many usecasebyactor [1..*] <<in>> Obtain Domain Features <<out>> <<in>> Build Skeleton (execute transformation) <<out>> FEATURE MODEL DOMAIN FEATURES (an instance of Feature Model) <<in>> COMPONENT-CONNECTOR SKELETON MODEL QVT <<out>> Incorporate Behavoiur (refine model) <<in>> COMPONENT-CONNECTOR BEHAVIOR-SKELETON MODEL <<in>> INTERACTION MODEL Figura 62.Proceso de la transformación y su refinamiento expresado en SPEM La figura 63 muestra el uso de la herramienta con los productos generados (archivos)paso a paso, durante el proceso de transformacicón y su refinamiento. Con el archivo ecore, se genera un archivo genmodel, que es usado para generar el código Java que describe el modelo. Además crea un editor en línea de comandos y un editor gráfico como plugins de Eclipse. Con el código generado, se serializa/deserializael modelo a XMI, obteniendo relaciones entre objetos, atributos, propiedades, enumeradores, etc. Todo ésto sólo con la descripción a alto nivel del modelo y su correspondiente metamodelo. El código generado se recarga, y se regenera si los modelos han sufrido cambios. Al instalar el plug-inadecuado (Medini), se utiliza EMF para codificar las QVT- Relations y transformar los modelos.

135 IMPLEMENTACIÓN 119 Modeling Tool codify specify specify specify Modular Metamodel (ECORE) C-C-C Metamodel (ECORE) QVT- Relations design Feature Model (ECORE) Modular Model (ECORE) transform C-C Model (ECORE) export export Feature Model (XMI) Modular Model (XMI) Interaction Model import design input input Instances of Feature Model (XMI) input Transform output C-C Model (XMI) input Refine output C-C-C Model (XMI) input Figura 633. Forma de uso de la plataforma Eclipse.

136 120 CAPÍTULO 4 A continuación se describe el mecanismo llevado a cabo para implementar la transformación, mismo que es mostrado mediante las tareas/actividades y productos de la figura 64.Para cada una de las tareas de esta figura, se presenta el resultado de dicha acción mediante una captura de pantalla. Con la finalidad de obtener lo necesario para llevar a cabo la transformación, con la herramienta EMF,se procedió a construir todos los metamodelos y los modelos de entrada a la transformación, i.e.: - Especificar el modelo de características (ver figura 65). - Especificar el metamodelo modular (ver figura 66). - Especificar el metamodelo de componentes y conectores (ver figura 67). - Obtener una instancia del modelo de caracteristicas (ver figura 68). - Diseñarelmodelo modular (como una instancia del metamodelo modular).(ver figura 69).

137 IMPLEMENTACIÓN 121 TO SPECIFY METAMODELS TO INDENTIFY RELATIONS OF CORRESPONDENCES AMONG METAMODELS TO SPECIFY RELATIONS OF CORRESPONDENCES AMONG METAMODELS TO SPECIFY FEATURE MODEL Modular Metamodel QVT- Relations Feature Model C-C-C Metamodel (C-C Metamodel with Interaction Metamodel) C-C-C Model R C-C Model T Modular Model Instance of Feature Model Interaction Model TO TRANSFORM: MODULAR MODEL INTO C-C C MODEL TO REFINE C-C MODEL TO DESIGN INTERACTION MODEL TO TRANSFORM: MODULAR MODEL INTO C-C MODEL TO DESIGN MODULAR MODEL TO OBTAIN AN INSTANCE OF FEATURE MODEL KEY: Task that is performed only one time Task that can be perfomed several times Figura 64. Tareas/actividades y productos de la transformación

138 122 CAPÍTULO 4 Figura 65. Especificando el Metamodelo de Características

139 Figura 66.Especificando elmetamodelo Modular IMPLEMENTACIÓN 123

140 124 CAPÍTULO 4 Figura 67. Especificando elmetamodelo de Componentes y Conectores

141 Figura 68. Obteniendo una instancia delmodelo de caracteristicas IMPLEMENTACIÓN 125

142 126 CAPÍTULO 4 Figura 69. Diseñando el Modelo Modular

143 IMPLEMENTACIÓN 127 A continuación, se ejecutó la transformación utilizandomedini. En este paso se procedió a: - Invocar los metamodelos creados en EMF. - Crear los modelos (como instancia de los metamodelos). - Invocar los modelos (de entrada a la transformación) obtenidos en EMF. - Codificar el archivo de transformación por medio de las QVT-Relations. - Obtener el modelo destino(o modelo de salida) de la transformación. Para invocar los metamodelos a los que se hace referencia en la transformación, es necesario configurar el compilador. En las opciones de configuración, en la parte de QVT METAMODELS, se agregócada uno de los metamodelos que intervinieronen dicha transformación, como se aprecia en la figura 70. Figura 70. Estableciendo metamodelos para la transformación

144 128 CAPÍTULO 4 Una vez codificadas lasqvt-relations(ver figura 71) se procedió a la invocación de los modelos,como instancias de sus respectivos metamodelos. Todos ellosestán serializados en XMI y conforman los metamodelos ya invocados con anterioridad. Figura 71. Codificando QVT Del menú contextual se seleccionó la opcion QVT TRANSFORMATION que inicializa la pantalla de configuración con los parámetros a establecer, como lo muestra la figura 72.

145 IMPLEMENTACIÓN 129 Figura 72. Invocando modelos, Metamodelos, Instancias y transformando los modelos El resultado de la transformación (modelo C-C skeleton) es un archivo XMI, que se especifica en el paso anterior. Éste se muestra como un diagrama de árbol desplegable y configurable (ver figura 73).