UNIVERSIDAD POLITÉCNICA DE MADRID

Transcripción

1 UNIVERSIDAD POLITÉCNICA DE MADRID ESCUELA UNIVERSITARIA DE INFORMÁTICA Departamento de Organización y Estructura de la Información TRABAJO FIN DE CARRERA (Ing. Técnica en Informática de Sistemas) SOPORTE A LA TRAZABILIDAD EN EL DESARROLLO DE LÍNEAS DE PRODUCTO SOFTWARE Raúl Puerta Sánchez Madrid, Julio 2011 i

2 ii

3 UNIVERSIDAD POLITÉCNICA DE MADRID ESCUELA UNIVERSITARIA DE INFORMÁTICA Departamento de Organización y Estructura de la Información TRABAJO FIN DE CARRERA (Ing. Técnica en Informática de Sistemas) SOPORTE A LA TRAZABILIDAD EN EL DESARROLLO DE LÍNEAS DE PRODUCTO SOFTWARE Raúl Puerta Sánchez Tutoras: Jennifer Pérez Benedí Yessica Díaz Fernández Madrid, Julio 2011 iii

4 iv

5 AGRADECIMIENTOS Este trabajo ha sido realizado gracias al apoyo de muchas personas que con su contribución directa o indirecta, lo han hecho posible. Especialmente quiero agradecer la ayuda a mis tutoras de este Trabajo Fin de Carrera, Dra. Jennifer Pérez Benedí y Yessica Díaz Fernández, por su disposición y entusiasmo a ayudarme y orientarme a lo largo de toda la investigación. También dar las gracias al Catedrático Juan Garbajosa Sopeña, por toda su ayuda y orientación aportada en este trabajo. A todo el grupo de Investigación SYST de la Universidad Politécnica de Madrid por sus ánimos, consejos, apoyo y amistad que me han brindado. A toda mi familia por estar siempre ahí y apoyarme a lo largo de todos estos años. A mi novia Leonor, por darme todos los ánimos del mundo para sacar la carrera adelante en los peores momentos y confiar en mis posibilidades ciegamente. También recordar a mi abuelillo Inocente Sánchez, recientemente fallecido, y que tanta ilusión le hacía. v

6 vi

7 RESUMEN En la actualidad, la mayoría de los sistemas software sufren inevitablemente cambios en sus requisitos durante y después de su desarrollo. En las grandes empresas la evolución del software es fundamental, ya que un gran porcentaje del presupuesto invertido se dedica al mantenimiento de los sistemas existentes. Para que un sistema pueda soportar correctamente evolución, es imprescindible tener definida correctamente la trazabilidad entre los requisitos y cada uno de los elementos que conforman los distintos modelos que definen un producto software (diagrama de clases, casos de uso, diagrama de secuencia, etc), para tener un seguimiento del desarrollo y evolución de los requisitos en los modelos de desarrollo software. Esta práctica es necesaria para soportar actividades de la Ingeniería del Software como el análisis del impacto del cambio, tareas de validación y verificación, rastreo de código, etc. En el paradigma de desarrollo de Ingeniería de Líneas de Producto Software, comúnmente conocido por su término inglés SPLE (Software Product Line Engineering), la trazabilidad también es esencial. SPLE se basa en la construcción de una línea de producto software (Software Product Line, SPL), es decir, familias de productos en un dominio determinado, donde los productos comparten un conjunto de características comunes y se diferencian en otra serie de características variables. Dentro de este paradigma, se requiere el modelado de arquitecturas de líneas de producto (Product Line Architecture, PLA). La herramienta Flexible-FPLA (FPLA), desarrollada por el grupo de investigación SYST de la UPM, da soporte a la especificación de PLAs. FPLA proporciona soporte para la especificación, de forma explícita, de características comunes y variables en PLAs. Este trabajo fin de carrera tiene como objetivo extender FPLA, para complementar su funcionalidad permitiendo la trazabilidad entre requisitos y PLAs. Para ello, FPLA ha sido extendida incorporando una vista que permita la especificación de dicha trazabilidad. La herramienta ha sido generada mediante un proceso de Desarrollo Software Dirigido por Modelos (Model Driven Development, MDD). MDD se basa en la idea de elevar el nivel de reutilización y abstracción, utilizando los modelos como pieza fundamental en el desarrollo software, en lugar de la escritura manual de código. En concreto, la iniciativa MDA (Model Driven Architecture) y los estándares que engloba tienen como objetivo situar los modelos en un nivel de abstracción tal que su realización en múltiples plataformas sea posible. vii

8 viii

9 ABSTRACT Currently, most software systems necessarily require changes in their requirements during and after their development. In large companies, software evolution is critical, since a large percentage of budget is invested in maintaining and evolving existing systems. To support software evolution, it is essential to properly define traceability between requirements and each of the elements that form the different models that define a software product (class diagram, use case, sequence diagram, etc.) to track the development and the evolution of requirements on software development models. This practice is necessary to support activities such as software engineering change impact analysis, validation and verification tasks, tracking code, etc. In the paradigm of Software Product Line Engineering (SPLE), traceability is also essential. SPLE is based on the construction of software product lines (SPL), i.e. family of products in a particular domain, in which the products share a common set of features and differ in a other set of variable features. This paradigm requires the modeling of product line architectures (PLAs). The tool Flexible-FPLA (FPLA), developed by the SYST research group of UPM provides support for the specification of PLAs. FPLA supports the specification of the common and variable features in PLAs.. This final project aims to extend FPLA to complement its functionality by providing traceability between requirements and PLAs. To achieve this, FPLA has been extended by adding a new view that allows the specification of traceability. The tool has been developed following Model-Driven Software Development (MDD) process. MDD is based on high-level of reuse and abstraction, using the models as a cornerstone in developing software, rather than hand written code. ix

10 x

11 ÍNDICE GENERAL AGRADECIMIENTOS... v RESUMEN... vii ABSTRACT... ix ÍNDICE GENERAL... xi ÍNDICE DE FIGURAS... xiii 1. INTRODUCCIÓN OBJETIVOS DEL PROYECTO ESTRUCTURA DEL TRABAJO FIN DE CARRERA INGENIERÍA DE LÍNEAS DE PRODUCTO SOFTWARE PROCESOS DE DESARROLLO Ingeniería de dominio Ingeniería de aplicación LA VARIABILIDAD EN LAS LINEAS DE PRODUCTOS SOFTWARE Representación de la variabilidad en requisitos Representación de la variabilidad en arquitectura DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS MODEL DRIVEN ENGINEERING (MDE) Modelos y metamodelos: mecanismos de abstracción en desarrollo software Model Driven Development (MDD) Model Driven Architecture (MDA) Software Factories Transformación entre modelos Estándares en MDE Comparativa: proceso de desarrollo tradicional vs MDD MODELOS ESPECÍFICOS DE DOMINIO (DSM) HERRAMIENTA PARA EL MODELADO DE TRAZABILIDAD EN SPLE CONTEXTO: FPLA PLATAFORMA DE DESARROLLO MODELO DE CARACTERÍSTICAS (Feature Diagram) Descripción del metamodelo Representación gráfica Iconografía Modificaciones del código (SRC) MODELO DE TRAZABILIDAD (Traceability Diagram) Descripción del metamodelo Representación gráfica Iconografía Modificaciones del código (SRC) Restricciones OCL INTEGRACIÓN EN LA HERRAMIENTA FPLA CASO DE ESTUDIO CONCLUSIONES Y TRABAJOS FUTUROS RESULTADOS OBTENIDOS PROBLEMAS ENCONTRADOS CONCLUSIONES TRABAJOS FUTUROS xi

12 Lista de acrónimos: Anexo A: Manual de Usuario Anexo B: Código Fuente de la clase CircleDecoration.java BIBLIOGRAFÍA Y REFERENCIAS WEB xii

13 ÍNDICE DE FIGURAS Figura 2.1. Ejemplo de componentes comunes en teléfonos móviles Figura 2.2. Enfoque del doble ciclo de vida aplicado a las líneas de producto Figura 2.3. Las 3 actividades esenciales para la SPL que propone el SEI Figura 2.4. Metamodelo propuesto por Czarnecki Figura 2.5. Representación gráfica de las características y grupos de características Figura 2.6. Ejemplo de representación gráfica de un modelo de características Figura 3.1. Evolución de los distintos niveles de abstracción Figura 3.2. Definición de modelo Figura 3.3. Relaciones entre modelos, metamodelos y lenguajes de modelado Figura 3.4. Niveles de abstracción en MDA Figura 3.5. Proceso de desarrollo MDA Figura 3.6. Visión general de las transformaciones Figura 3.7. Arquitectura de referencia MOF Figura 4.1. Esquema del objetivo que persigue este trabajo Figura 4.2. Desarrollo de un proyecto GMF Figura 4.3. Proyectos de FPLA Figura 4.4. Proyecto Principal-Metamodelo Ecore Figura 4.5. Código generado automáticamente en el proyecto principal Figura 4.6. Metamodelo Ecore que implementará Feature Diagram Figura 4.7. Representación gráfica en el tapiz de los distintos elementos en la vista Feature Diagram Figura 4.8. Iconos de la paleta de herramientas de la vista Feature Diagram Figura 4.9. Metamodelo UML que implementa Traceability Diagram Figura Metamodelo Ecore que implementa Traceability Diagram Figura Representación de la paleta de herramientas sobrecargada Figura Metamodelo Ecore simplificado de la vista Traceability Diagram Figura Representación de la paleta de herramientas simplificada Figura Representación gráfica en el tapiz de los distintos elementos en la vista Traceability Diagram Figura Iconos representativos que aparecen en la vista Traceability Diagram.. 68 Figura Código OCL en GMF, en el enlace Source Link Figura Código OCL en GMF, en el enlace Target Link Figura Control de cardinalidad en Trazabilidad Figura Mensaje de notificación al usuario Figura Código OCL en GMF, en el elemento Linkage Rule Figura Metamodelo final Figura 5.1. Modelo de características del caso de estudio.. 79 Figura 5.2. Técnicas para implementar disponibilidad en un sistema. 80 Figura 5.3. Mecanismo de funcionamiento de las técnicas de Disponibilidad. 81 Figura 5.4. Modelo de la PLA del caso de estudio. 82 Figura 5.5. Modelo de trazabilidad del caso de estudio Figura A.1. Ventana inicial de aplicación Eclipse Figura A.2. Selección del tipo de proyecto Figura A.3. Selección del tipo de elemento a añadir al proyecto Figura A.4. Apariencia de la vista Feature Diagram Figura A.5. Paleta de herramientas de la vista Feature Diagram Figura A.6. Modelado de una Root Feature Figura A.7. Modelado de una enlace MandatoryFeature Figura A.8. Modelado de un XorGroup xiii

14 Figura A.9. Modelado de un enlace FeatureGroup has Grouped Figura A.10. Tipo de elemento a añadir al proyecto Figura A.11. Paleta de herramientas de la vista Traceability Diagram Figura A.12. Modelado de un SatistactionLink Figura A.13. Modelado de trazabilidad xiv

15 Capítulo1. Introducción 1. INTRODUCCIÓN 1. Introducción 1.1. Objetivos del Proyecto 1.2. Estructura del Trabajo Fin de Carrera Hoy en día, la mayoría de los sistemas software una vez desarrollados, inevitablemente han de sufrir cambios para poder seguir siendo útiles. Una vez puesto en funcionamiento el sistema, surgen nuevos requisitos y/o los requisitos existentes cambian. Los cambios en los negocios a menudo generan nuevos requisitos para el software existente. Algunas partes del software deben de modificarse para corregir errores encontrados en su funcionamiento, adaptarlo a una nueva plataforma y/o mejorar su rendimiento u otras características no funcionales. Por lo tanto, el desarrollo del software no finaliza cuando un sistema es entregado, sino que continúa durante el tiempo de vida del sistema. La evolución del software es importante debido a que las organizaciones actualmente son completamente dependientes de sus sistemas software y han invertido millones de euros en ellos. Los sistemas software son activos de negocio críticos y las organizaciones deben invertir en los cambios del sistema para mantener el valor de estos activos. Por lo tanto, en grandes compañías, la mayor parte del presupuesto de software se dedica a mantener los sistemas existentes, y algunos estudios como el realizado por Erlikh [Erlikh, 2000] sugiere que el 90% de los costes de software son costes de evolución. Para que un sistema software pueda soportar correctamente la evolución, es imprescindible haber definido en las etapas de proceso software la trazabilidad de los requisitos. La trazabilidad es parte activa de la gestión de la configuración del software, por lo tanto debe soportar el control de versiones, el seguimiento de la evolución de los requisitos en modelos de desarrollo, la propagación del cambio, y el análisis de impacto del cambio. En Ingeniería del Software, la trazabilidad es un atributo de calidad que establece un conjunto de características y elementos para hacer el seguimiento de la vida de los requisitos durante el proceso de desarrollo. Esta práctica implica 1

16 Capítulo1. Introducción realizar actividades de validación 1 y verificación 2 durante el proceso de desarrollo para lograr características como la confiabilidad 3 y la exactitud 4 de los productos de software que se producen [Gotel, 1994]. En particular, la trazabilidad es una práctica que facilita el control de los requisitos por medio de vínculos de trazado entre diferentes artefactos que los representan a través del ciclo de vida de desarrollo [Sommerville, 1995]. El organismo internacional de estandarización IEEE (Institute of Electrical and Electronics Engineers) define la trazabilidad como el grado en el cual una relación puede ser establecida entre dos o más productos del proceso de desarrollo, especialmente productos que tienen relaciones de predecesor-sucesor o maestro-subordinado entre uno y otro [IEEE-STD- 610]. El modelo de madurez CMMI (Capability Maturity Model Integration) es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software. Este modelo define que cuando los requisitos están bien gestionados, es posible mantener la trazabilidad bidireccional entre los requisitos y sus productos de trabajo. Esta práctica es necesaria para conducir la evaluación del impacto del cambio en las actividades del proyecto y los productos de trabajo [CMMI-DEV 2006]. Existen diferentes enfoques de trazabilidad para garantizar la correlación entre los requisitos y los artefactos que los representan en el proceso de refinamiento del ciclo de vida. En general, cada enfoque propone una semántica de trazado diferente que corresponde a la definición de los elementos de trazado (trace elements) y vínculos de trazado (tracing links) en el marco de un modelo de trazabilidad conceptual. El significado que se le dé a cada uno de esos elementos permitirá hacer el seguimiento de los requisitos desde su identificación hasta su implementación [Sommerville, 1995]. En la actualidad, poner en práctica la trazabilidad depende de los criterios de calidad establecidos por las empresas de desarrollo para el modelado de los requisitos. Además, nuevos paradigmas de desarrollo proveen enfoques para el tratamiento de los requisitos, su modelado en artefactos de software y su trazabilidad. Algunos de ellos son: 1 Validación: Estamos construyendo el producto adecuado? La validación supone comprobar que el programa, según se ha implementado, cumple con las expectativas del cliente. [Boehm, 1979]. 2 Verificación: Estamos construyendo bien el producto? La verificación supone comprobar que el programa satisface sus especificaciones. [Boehm, 1979]. 3 Confiabilidad: Conjunto de atributos que se relacionan con la capacidad del software de mantener su nivel de rendimiento bajo las condiciones establecidas por un período de tiempo. 4 Exactitud: Atributos que determinan que los efectos sean los correctos o los esperados. 2

17 Capítulo1. Introducción La Ingeniería de Líneas de Producto Software (SPLE 5 ): es un paradigma de desarrollo software fundamentado en la reutilización de software e inspirado en los procesos de producción de sistemas físicos como producciones de vehículos, aviones, etc., en los que un alto porcentaje de los componentes utilizados en su construcción son comunes. Con el objetivo de evitar la repetición del proceso de producción o al menos parte de éste, surgen (en detalle en el Capítulo 2) las Líneas de Producto Software o SPL 6. Una SPL es un conjunto de productos de software asociados a un dominio o familia determinado. Los miembros de la familia comparten aspectos comunes que son compartidos por todos sus productos y aspectos variables que establecen diferencias entre los productos (variabilidad). La variabilidad es el elemento más característico de las SPLs y su gestión eficiente es fundamental a la hora de definir la línea de producto satisfactoriamente. La variabilidad de la SPL debe especificarse tanto a nivel de requisitos a través de un modelo de variabilidad, ej. un Modelo de Características, como a nivel de arquitectura a través de la especificación de la Arquitectura de Línea de Producto software (PLA 7 ). La trazabilidad de la variabilidad entre ambas especificaciones es imprescindible para poder reaccionar ante futuros cambios, modificaciones o cambios de requisitos que puedan afectar a los productos de la línea y que se sepa en todo momento, que componentes (elementos de la arquitectura) se ven implicados o afectados al efectuar un cambio en la SPL. El Desarrollo Dirigido por Modelos MDD (Model-Driven Software Development) [Stahl and Volter 2006] soporta la transformación desde modelos fuente hacia modelos destino en diferentes niveles de abstracción. Una de los enfoques que siguen MDD es MDA 8 (más en detalle en el Capítulo 3 de este documento). MDA es una iniciativa del Object Management Group (OMG) que asume las ideas de elevar el nivel de reutilización y abstracción dando una mayor importancia al modelado conceptual y al papel de los modelos en el desarrollo del software. La idea principal de esta iniciativa es que el proceso de crear software debería ser dirigido por la formulación de modelos en lugar de por la escritura manual de código fuente. Para ello se definió una arquitectura de estándares y un conjunto de directrices que permiten expresar las especificaciones de software 5 Software Product Line Engineering 6 Software Product Lines 7 Product Line Architecture 8 Model Driven Architecture 3

18 Capítulo1. Introducción como modelos. La iniciativa MDA y los estándares que engloba tienen como objetivo situar los modelos en un nivel de abstracción tal que su realización en múltiples plataformas sea posible OBJETIVOS DEL PROYECTO La definición de la variabilidad es clave para construir exitosamente una SPL. Esta variabilidad debe reflejarse tanto a nivel de requisitos (Modelo de Características (Feature Model)) como a nivel de arquitectura (Modelo de la PLA). La herramienta Flexible-FPLA (FPLA), desarrollada por el grupo de investigación SYST de la UPM, da soporte a la especificación de PLAs. FPLA proporciona soporte para la especificación, de forma explícita, de características comunes y variables en PLAs. El objetivo de este trabajo fin de carrera consiste en extender FPLA, para complementar su funcionalidad permitiendo la trazabilidad entre requisitos y PLAs. Para ello, FPLA será extendida incorporando una vista que permita definir modelos de características y otra vista que permita la especificación de dicha trazabilidad. La trazabilidad entre modelos soporta varias actividades de la ingeniería del software como el análisis de impacto del cambio, tareas de validación y verificación, rastreo de código, etc. El análisis del impacto del cambio es a su vez, una tarea fundamental en evolución del software, ya que permite conocer aquellos artefactos software que son impactados cuando se produce un cambio en los requisitos. La herramienta ha sido desarrollada mediante un proceso de Desarrollo Dirigido por Modelos (Model-Driven Development, MDD), y que está soportado mediante plugins de Eclipse (Eclipse Modeling Framework (EMF 9 ) y Graphical Modeling Framework (GMF 10 )). MDD se basa en la idea de elevar el nivel de reutilización y abstracción, utilizando los modelos como pieza fundamental en el desarrollo software, en lugar de la escritura manual de código. En concreto, la iniciativa MDA (Model Driven Architecture) y los estándares que engloba tienen como objetivo situar los modelos en un nivel de abstracción tal que su realización en múltiples plataformas sea posible

19 Capítulo1. Introducción 1.2. ESTRUCTURA DEL TRABAJO FIN DE CARRERA Este trabajo fin de carrera está estructurado en 6 capítulos y dos anexos, uno de ellos con ejemplo de aplicación. A continuación se describe la aportación de cada uno de estos capítulos brevemente. Capítulo 1. Introducción En este capítulo se introduce la motivación que ha llevado al desarrollo de este Trabajo Fin de Carrera, así como los objetivos que se pretenden cumplir con su desarrollo. Capítulo 2. Ingeniería de Líneas de Producto Software Este capítulo cubre el paradigma de desarrollo de Ingeniería de Líneas de Producto Software, uno de los capítulos centrales de este Trabajo Fin de Carrera. El capítulo comienza con una introducción que describe los conceptos básicos, las ideas y los objetivos en los que se basa este paradigma de desarrollo. A continuación se detalla los dos procesos de desarrollo en los que se basa este paradigma (Ingeniería de Dominio e Ingeniería de Aplicación), así como una de las claves para construir exitosamente una Línea de Producto Software: la gestión de la variabilidad. Capítulo 3. Desarrollo de Software basado Modelos Este capítulo cubre el paradigma de desarrollo de software dirigido por modelos (MDD) que es otra pieza central en este Trabajo Fin de Carrera. El capítulo comienza con una introducción que describe la evolución de los paradigmas y lenguajes de programación a lo largo de la historia así como la situación actual. Después se explican algunos conceptos clave como metamodelo y modelos, ambos necesarios de la Ingeniería Dirigida en Modelos (MDE) 11. Posteriormente se explican los principios sobre los que se sustenta MDE, incluyendo tecnologías y aproximaciones conceptos básicos del modelado de sistemas software y típicamente empleadas en este enfoque. De entre las aproximaciones expuestas destaca MDA propuesta por la OMG a la que se le da especial atención. Una alternativa a MDA es Software Factories, la propuesta de Microsoft con ideas de punto en común a MDA. Finalmente, se compara el proceso de desarrollo software tradicional frente al proceso MDA y se introduce los Modelos Específicos de Dominio (DSM 12 ) y los Lenguajes Específicos de 11 Model Driven Engineering 12 Domain Specific Model 5

20 Capítulo1. Introducción Dominio (DSL 13 ). Los DSM son una aproximación al desarrollo software basada en modelos y se centran en el uso de modelos específicos de dominio como principales elementos en el proceso de desarrollo software. Estos DSM se especifican utilizando DSL. Un DSL es fundamental en un enfoque de desarrollo basado en el uso de modelos ya que permite elevar el nivel de abstracción con el que se describen las aplicaciones. A lo largo del capítulo se describen estos lenguajes, incidiendo en sus ventajas e inconvenientes, así como el proceso que se sigue para su definición. Capitulo 4. Herramienta para el modelado de trazabilidad en SPLE En este capítulo se describe la herramienta y decisiones de diseño del Trabajo, junto con sus problemas detectados y soluciones. Capitulo 5. Caso de estudio En este capítulo se describe un escenario para ilustrar el uso de la herramienta de este Trabajo Fin de Carrera. Se mostrará un ejemplo típico de SPL de sistemas software para venta de productos. Capítulo 6. Conclusiones y Trabajos futuros En este capítulo se presentan las conclusiones obtenidas tras la realización del Trabajo Fin de Carrera, así como las posibles líneas de investigación a seguir dentro de las áreas abordadas en el Trabajo Fin de Carrera. 13 Domain Specific Language 6

21 Capítulo 2. Ingeniería de Líneas de Producto Software 2. INGENIERÍA DE LÍNEAS DE PRODUCTO SOFTWARE 2. Ingeniería de Líneas de Producto Software 2.1. Dos procesos de desarrollo Ingeniería de dominio Ingeniería de aplicación 2.2. La variabilidad en las líneas de producto software Representación de la variabilidad en requisitos Representación de la variabilidad en arquitectura La industria software se enfrenta a un mercado competitivo que se ha de adaptar constantemente a nuevas tecnologías. Dada esta situación, surgen nuevas necesidades como reducir al máximo el tiempo de desarrollo (time to market) y de mantenimiento, reducir costes de desarrollo y mantenimiento, desarrollar productos de calidad y soportar características como las flexibilidad y la adaptabilidad debido a la diversidad altamente cambiante del mercado. Con el objetivo de dar soluciones a estas necesidades del desarrollo de software surge un paradigma de desarrollo software fundamentado en la reutilización de software: Ingeniería de Líneas de Producto Software o también conocido como SPLE (Software Product Line Engineering): <<Es un paradigma para desarrollar aplicaciones software (sistemas intensivos software y productos software) usando plataformas y personalizaciones masivas.>> [Pohl, 2005] SPLE se basa en las siguientes ideas clave: La mayoría de los sistemas software no son nuevos. Los sistemas de un mismo dominio de aplicación tienen muchas cosas en común. Muchas organizaciones construyen sistemas software de un dominio en concreto. Muchas organizaciones construyen muchas versiones de un mismo producto a lo largo del tiempo a base de añadirle funcionalidades nuevas. 7

22 Capítulo 2. Ingeniería de Líneas de Producto Software Aplicar SPLE proporciona una serie de ventajas. Esto nos lleva a la necesidad de construir una línea de producto software para una familia de productos, lo cual nos producirá las siguientes ventajas: Obtendremos un gran incremento de la productividad. La línea de producto software nos permitirá gestionar fácilmente la diversidad del mercado. Reduciremos el tiempo empleado en el desarrollo (time to market). También nos permitirá la explotación de otros productos y dominios de desarrollo mediante la reutilización de código. En consecuencia, mejoraremos la calidad, que como El padre de la Calidad Total Kaoru Ishikawa ( ) definía: <<La calidad es cuando se logra un producto económico, útil y satisfactorio para el consumidor. [Ishikawa, Kaoru., 1988] >> SPLE está inspirado en los procesos de producción de sistemas físicos como producciones de vehículos, aviones, computadores, aparatos eléctricos, teléfonos móviles, etc., en los que un alto porcentaje de los componentes utilizados en su construcción son comunes. SPLE parte de la idea de que si se desea construir más de una versión de un producto software, el proceso de reutilización se repite. Con el objetivo de evitar la repetición del proceso de reutilización o al menos parte de éste, surgen las Líneas de Producto Software o SPL (Software Product Lines). Una SPL puede definirse como: <<Una línea de producto software es un conjunto de sistemas intensivos software que comparten un conjunto común de características manejables que satisfacen las especificaciones necesarias de un segmento de mercado particular y que son desarrolladas a partir de un conjunto común de activos básicos comunes (core assets).>> [Clements and Northorp, 2001]. SPLE consiste en el desarrollo de una línea de producto software para una familia de productos. Una familia de productos de software es un conjunto de productos de software asociados a un dominio determinado. A modo de ejemplo, la Figura 2-1, muestra las características de una familia de teléfonos móviles (por ejemplo servicio de llamadas, servicio de SMS y reproductor MP3), los cuales son comunes a toda la línea de teléfonos. También se muestra los componentes opcionales o variables que definen un producto concreto (por ejemplo bluetooth, juegos, etc.). 8

23 Capítulo 2. Ingeniería de Líneas de Producto Software Figura 2-1. Ejemplo de componentes comunes en teléfonos móviles. [Montero and Segura,2006] Los miembros de la familia comparten característica variables que establecen diferencias entre los productos y características comunes que son compartidos por todos sus productos. Las características comunes se traducen en artefactos comunes como un diseño arquitectónico común, un conjunto de componentes reutilizables, capacidades, servicios y tecnologías comunes. Cuando se habla de SPL, se habla también de conceptos como la variabilidad, derivación y extensibilidad de la SPL. La variabilidad es el elemento más característico de una SPL y por ello, se ha dedicado un apartado para describir las nociones básicas (ver apartado 2.2). La variabilidad es la capacidad de especificar flexibilidad para permitir el desarrollo de aplicaciones personalizadas de una SPL [Clements and others, 2010]. La derivación de una SPL consiste en realizar una definición precisa de puntos de variabilidad que permitan seleccionar las características específicas de un producto dentro del alcance de la SPL. Por último, la extensibilidad es la definición precisa de un punto de extensión para permitir añadir características específicas fuera del alcance de la línea. 9

24 Capítulo 2. Ingeniería de Líneas de Producto Software 2.1. PROCESOS DE DESARROLLO El proceso de desarrollo de una SPL no intenta construir una aplicación, sino una familia de ellas. Este enfoque supone un cambio de un desarrollo orientado a un único producto software, a un desarrollo de varios productos que contienen unas características comunes, formando una familia de productos. Siguiendo el enfoque propuesto por Pohl [Pohl, 2005], el paradigma SPLE está dividido en dos procesos: La ingeniería de dominio y la ingeniería de aplicación. La ingeniería de dominio se centra en el desarrollo de elementos reutilizables que formarán la familia de productos, identificando las partes comunes y variables de la familia. La ingeniería de aplicación se centra en el desarrollo de productos individuales, pertenecientes a la familia de productos y que satisfacen un conjunto de requisitos y restricciones expresados por un usuario específico, reutilizando, adaptando e integrando los elementos reutilizables existentes y producidos en la ingeniería de dominio [García, 2002]. La Figura 2-2 muestra el proceso total de los dos enfoques (Ingeniería de Dominio e Ingeniería de Aplicación) en la que se observa el doble ciclo de vida aplicado a las SPL. Figura 2-2. Enfoque del doble ciclo de vida aplicado a las líneas de producto. [Pohl, 2005]. 10

25 Capítulo 2. Ingeniería de Líneas de Producto Software Otro enfoque de desarrollo del paradigma SPLE, es el propuesto por el Software Engineering Institute (SEI). La Figura 2-3 muestra las 3 actividades esenciales en el desarrollo de una SPL que propone el SEI [SEI, 2007] : desarrollo de los core assets, desarrollo de productos, y la gestión. Los core assets también llamados activos software, son todos los artefactos producidos durante el desarrollo del software y que son reutilizables como son por ejemplo los requisitos, patrones de diseño, componentes, casos de prueba, etc. Cada uno de los tres círculos representados en la figura, representa una de las actividades esenciales. Las tres están ligadas en un movimiento conjunto, mostrando que las tres son esenciales y que están unidas. Las flechas rotativas indican que no solamente los activos principales son usados para desarrollar productos, sino también que las revisiones de activos principales existentes o incluso nuevos activos podrían evolucionar en el desarrollo del producto. La fase de desarrollo de core assets y desarrollo de productos que propone el SEI, es la equivalente al proceso de Ingeniería de Dominio e Ingeniería de Aplicación respectivamente que propone el enfoque de Pohl. El enfoque seguido en este documento y que a continuación se ve más en detalle es el enfoque propuesto por Phol et al. Figura 2-3. Las 3 actividades esenciales para la SPL que propone el SEI. [SEI, 2007] 11

26 Capítulo 2. Ingeniería de Líneas de Producto Software Ingeniería de dominio Se centra básicamente en el estudio del dominio con el objetivo de identificar las partes comunes y variables de la familia. También se encarga de la gestión de la variabilidad en el desarrollo de los core assets y en diseño del plan de producción. Este proceso o enfoque se puede definir como: <<La ingeniería de dominio es el proceso de las Ingenierías de líneas de producto software en el cual la parte común y la variabilidad de la línea de producto son definidas y realizadas>> [Pohl, 2005]. La Figura 2-2 muestra que el proceso de Ingeniería de dominio tiene 5 subprocesos formando un ciclo circular, la salida que producen los subprocesos son la entrada para otros. Los subprocesos que forman el proceso de Ingeniería de Dominio son los siguientes [Pohl, 2005]: Product Management (Gestión de productos): Encargado de los aspectos económicos y de la estrategia de mercado. Define el alcance de la SPL. Este proceso tiene como entrada los objetivos de la compañía y produce como salida las principales características comunes y variables de la SPL, una planificación de las entregas (releases) y una lista de los productos existentes y/o artefactos a reutilizar. Domain Requirements Engineering (Ingeniería de requisitos de dominio): Su principal tarea es la documentación y elicitación de requisitos comunes y variables de la línea de producto. Tiene como entrada la hoja del producto, es decir, las principales características comunes y variables del producto. Produce como salida los modelos de requisitos, reutilizables y textuales, un modelo de variabilidad de la línea de producto. Domain Design (Diseño de dominio): Es este subproceso de define la arquitectura de referencia de la SPL. Recibe como entrada los requisitos del dominio y su modelo correspondiente. Produce como salida la arquitectura de referencia y un modelo de variabilidad ya refinado. Domain Realisation (Realización de dominio): En esta fase es donde se realiza el diseño e implementación de componentes software reutilizables. Recibe como entrada la arquitectura de referencia y la lista de artefactos reutilizables que se han de desarrollar. Como salida produce el diseño e implementación de componentes software reutilizables. Domain Testing (Pruebas de dominio): En esta fase se lleva a cabo la validación y verificación de componentes software reutilizables. Recibe 12

27 Capítulo 2. Ingeniería de Líneas de Producto Software como entrada los requisitos de dominio, la arquitectura de referencia y el diseño e implementación de componentes reutilizables. Como salida produce el resultado de los test. En este enfoque de desarrollo intervienen 6 artefactos del dominio a lo largo del ciclo circular. Los artefactos que intervienen son los siguientes [Pohl, 2005]: Roadmap (mapa de ruta) de la línea de producto: Describe las características de todas las aplicaciones de la línea de productos software y clasifica las características (features) en características comunes que forman parte de cada aplicación y características variables sólo forman parte de algunas aplicaciones. Modelo de variabilidad del dominio: Define la variabilidad de la línea de producto software. Requisitos del dominio: Enmarca los requisitos que son comunes a todas las aplicaciones de la línea de productos software así como los requisitos variables que permiten la derivación de los requisitos personalizados para las diferentes aplicaciones. Arquitectura de dominio: La arquitectura de dominio o arquitectura de referencia determina la estructura y la textura de las aplicaciones en la línea de productos software. La estructura determina la descomposición estática y dinámica que es válida para todas las aplicaciones de la línea de productos. La textura es el conjunto de reglas comunes que guían el diseño y la implementación de las partes y cómo éstas son combinadas para formar las aplicaciones. Artefactos de implementación de dominio: se encargan del diseño e implementación de los artefactos de los componentes e interfaces software reutilizables. El diseño de artefactos abarca los diferentes tipos de modelos que capturan la estructura estática y dinámica de cada componente. La implementación de artefactos incluye archivos de código fuente, archivos de configuración, etc. Artefactos de test de dominio: Los artefactos de test de dominio incluyen el plan de pruebas de dominio, los casos de prueba de dominio y los escenarios de prueba de dominio. El plan de prueba de dominio define la estrategia de prueba para probar el dominio, los artefactos de prueba que son creados, y los casos de prueba que son ejecutados. Los casos de prueba y los escenarios de prueba de dominio proporcionan instrucciones detalladas para el ingeniero de pruebas que realiza las pruebas. 13

28 Capítulo 2. Ingeniería de Líneas de Producto Software Ingeniería de aplicación Se centra básicamente en el desarrollo de productos concretos, en obtener una aplicación en concreto reutilizando la mayor cantidad posible de artefactos del dominio y en explotar la parte común y variable de la SPL durante el desarrollo de la aplicación. Este proceso o enfoque se puede definir como: <<La ingeniería de aplicación es el proceso de las Ingenierías de líneas de producto software en el cual las aplicaciones de la línea de producto se construyen reutilizando artefactos de dominio y explotando la variabilidad de la familia de producto.>> [Pohl, 2005]. La Figura 2-2 muestra que el proceso de Ingeniería de dominio tiene 4 subprocesos formando un ciclo circular, la salida que producen los subprocesos son la entrada para otros. Los subprocesos que forman el proceso de Ingeniería de Dominio son los siguientes [Pohl, 2005]: Ingeniería de requisitos de aplicación: Su principal tarea es la especificación de los requisitos de la aplicación y del producto. Tiene como entrada la hoja del producto (principales características comunes y variables del producto), requisitos del dominio y requisitos adicionales del cliente. Produce como salida la especificación de requisitos de una aplicación en particular. Diseño de aplicación: En esta etapa se procede a la construcción de la arquitectura de la aplicación mediante la derivación de la arquitectura de referencia. Recibe como entrada la especificación de requisitos de la aplicación y la arquitectura de referencia. Produce como salida la arquitectura de la aplicación. Realización de la aplicación): En esta fase es donde se realiza el desarrollo de la aplicación, la selección y configuración de componentes reutilizables y la derivación de los artefactos. Recibe como entrada la arquitectura de la aplicación y el diseño de los artefactos de la aplicación. Como salida produce la aplicación ejecutable. Pruebas de aplicación: En esta fase se lleva a cabo la validación y verificación de la aplicación. Recibe como entrada los requisitos de la aplicación, la arquitectura de la aplicación, el diseño e implementación de las componentes de la aplicación, la aplicación resultante y los artefactos de test reutilizables generados en el subproceso domain testing. Como salida produce un informe detallado del proceso de prueba. Modelo de variabilidad de aplicación: Documentan para una aplicación en 14

29 Capítulo 2. Ingeniería de Líneas de Producto Software particular los enlaces de la variabilidad junto con los fundamentos para seleccionar estos enlaces. Requisitos de aplicación: Constituyen la especificación completa de requisitos de una aplicación concreta. Arquitectura de aplicación: La arquitectura de aplicación determina la estructura general de una aplicación determinada. Es una instancia específica de la arquitectura de referencia. Para el éxito de la línea de producto, es esencial reutilizar la arquitectura de referencia en todas las aplicaciones. Artefactos de implementación de aplicación: engloban el diseño de componentes e interfaces de una aplicación específica, así como su configuración y ejecución de la aplicación. Artefactos de prueba de aplicación: comprenden la documentación de prueba para una aplicación específica LA VARIABILIDAD EN LAS LINEAS DE PRODUCTOS SOFTWARE Algunas de las principales actividades de desarrollo de una línea de productos software (SPL) son la representación y la gestión de la parte común y variable de la misma, junto con la configuración y la derivación de los productos finales. La variabilidad es de hecho, el elemento más característico de las líneas de productos software. Su gestión eficiente es fundamental para definir la línea de producto satisfactoriamente. La variabilidad la podemos definir como: <<La variabilidad es la habilidad de un sistema software o artefacto para ser cambiado, personalizado o configurado para usarse en múltiples contextos >> [Van Grurp and Bosch, 2002]. La variabilidad de una SPL se define en la proceso de Ingeniería de Dominio mediante un modelo de variabilidad que captura la variabilidad del dominio en requisitos, arquitectura, componentes y pruebas, y se explota en la etapa de Ingeniería de Aplicación. A continuación se definen algunos conceptos básicos relacionados con el concepto de variabilidad: <<La variabilidad sujeto es un elemento variable del mundo real o una propiedad variable del propio elemento >> [Pohl, 2005]. Por ejemplo, son variabilidad sujeto el color de algún objeto, la forma de pago de una aplicación bancaria, etc. 15

30 Capítulo 2. Ingeniería de Líneas de Producto Software <<La variabilidad objeto es una instancia particular de la variabilidad sujeto>> [Pohl, 2005]. Ejemplos de este tipo son las instancias rojo, azul, verde, tarjeta de crédito, tarjeta de débito, efectivo, etc., que son instancias de la variabilidad sujeto del ejemplo anteriormente utilizado. <<Un punto de variabilidad es una representación de una variabilidad sujeto dentro de los artefactos de dominio enriquecidos por información contextual. >> [Pohl, 2005]. <<Una variante es una representación de una variabilidad objeto dentro de los artefactos de dominio>> [Pohl, 2005]. Es una entidad diferente en requisitos, arquitectura, etc., que identifica una única opción de un punto de variabilidad. Los puntos de variabilidad y variantes se utilizan para definir la variabilidad de la línea de productos software. El proceso para especificar la variabilidad es el siguiente: 1º) Identificación del sujeto de variación, es decir, identificación del elemento que varía en el mundo real. 2º) Definición del punto de variabilidad en el contexto de la SPL. 3º) Definición de las variantes, es decir, selección de los objetos de variabilidad de SPL y la definición de los objetos de variabilidad seleccionados como variantes. Cuando gestionamos la variabilidad en una línea de productos, necesitamos distinguir tres tipos principales de variabilidad: Opcional: Es aquella en la que la variante de un punto de variabilidad puede ser parte o no de la línea de producto de una aplicación. Establece relación entre el punto de variabilidad y la variante con una cardinalidad mínima de 0 y una cardinalidad máxima de 1. Ejemplo: las variantes que definen los accesorios del móvil como cámara de fotos, bluetooth, GPS se definen opcionales, de forma que el cliente puede no elegir ninguno de ellos, uno o más de uno. Obligatoria: La variante de un punto de variabilidad deber ser parte de la línea de producto de una aplicación. Establece una relación entre el 16

31 Capítulo 2. Ingeniería de Líneas de Producto Software punto de variabilidad y la variante con una cardinalidad mínima de 1 y una cardinalidad máxima de 1. Ejemplo: la comunicación encriptada de un sistema de casa domótica ofrece diferentes longitudes de clave: de 128 bits a 1024 bits. El ingeniero de la SPL establece que la encriptación de 128 bits es la mínima protección que se requiere para cualquier aplicación de acceso remoto. Por eso, 128 bits es una variante obligatoria, mientras que 256 bits, 512 bits, y 1024 bits son variantes opcionales. Alternativa múltiple: Se da cuando un punto de variabilidad puede seleccionar o no más de una variante. Establece relación entre el punto de variabilidad y la variante con la cardinalidad mínima entre 0..1, y máxima de N. Ejemplo: Las variantes que definen los accesorios del móvil como cámaras de fotos, bluetooth y GPS se pueden definir como una alternativa múltiple la cual establece que como mínimo ha de elegirse un accesorio y como máximo Representación de la variabilidad en requisitos La variabilidad entre productos de una línea de productos puede ser expresada en términos de características [Kang, 1998], [Bosch, 2000]. Una característica es una propiedad que representa una parte común o variable de un producto. Más formalmente una característica se define como: <<Una característica es una unidad lógica de comportamiento que es especificada por un conjunto de requisitos funcionales o de calidad. >> [Bosch, 2000]. En 1990, Kang et al, propusieron un modelo de características, el cual describe toda la variabilidad posible en una línea de producto siguiendo una estructura jerárquica de árbol. Seleccionando una configuración de este modelo podemos obtener la definición de un producto específico de la línea de productos. El Institute Engineering Software (SEI), describió la metodología FODA (Feature Oriented Domain Analysis) [Kang, 1990], con el objetivo de identificar las características comunes y variables de los sistemas software en un dominio concreto, considerando una característica como un aspecto, cualidad o característica visible por el usuario, destacada o distintiva de un sistema o sistemas software [Kang, 1990]. 17

32 Capítulo 2. Ingeniería de Líneas de Producto Software FODA distingue tres tipos diferentes de características: obligatorias, opcionales y grupos de características XOR. Además proponía una descripción textual para las restricciones requires y mutex. Más tarde Kang [Kang, 1990] propuso FORM (Feature-Oriented Reuse Method) como extensión de FODA, añadiendo los grupos de características OR. Después FeatureRSEB [Griss, 1998], que combina FODA y el método RSEB (Reuse-Driven Software Engineering Business), añadió una representación gráfica para las restricciones requires y mutex. Finalmente, Czarnecki [Czarnecki, 2005] propuso un metamodelo en el que añadió cardinalidades a las características y grupos de características. En el metamodelo de Czarnecki, los modelos de características están formados por una característica raíz del árbol jerárquico, de la que cuelgan el resto de características, que a su vez pueden ser características simple o grupos de características, como se aprecia en el metamodelo de la Figura 2-4. Éste metamodelo (junto a las restricciones gráficas requires y mutex) contiene los siguientes elementos: Características obligatorias: Estarán seleccionadas si y solo si su padre está seleccionado. Se representan con un círculo lleno en el arco de la característica. Características opcionales: Pueden ser seleccionadas solo si su padre está seleccionado. Se representan con un círculo vacío en el arco de la característica. Características alternativas XOR: Son un conjunto de características de las cuales una de ellas será seleccionada si su padre es seleccionado. Se representan con un conjunto de arcos agrupados con cardinalidad Grupos OR de características: Son un conjunto de características de las cuales un grupo de ellas serán seleccionadas si su padre es seleccionado. Se representan con un conjunto de arcos agrupados con cardinalidad variable (desde 0..1 hasta m..n en general). Restricciones mutex y requires: La relación requires significa que al seleccionar una característica la característica unida por la relación es seleccionada también. La relación mutex nos indica que cuando seleccionamos una característica la característica unida por la relación debe ser excluida. La multiplicidad de los arcos indica el número de características que deben ser seleccionadas. Esta multiplicidad está representada por un número mínimo y 18

33 Capítulo 2. Ingeniería de Líneas de Producto Software máximo especificado entre corchetes. La Figura 2-5 muestra un esquema de la representación gráfica de los elementos descritos. La Figura 2-6 ilustra un ejemplo de representación de un modelo de características. Or Xor Feature Group groupcardinality 0..* Feature name 0..* GroupedFeature groupcardinality RootFeature groupcardinality 0..* SolitaryFeature groupcardinality 0..1 FeatureModel groupcardinality Figura 2-4. Meta-modelo propuesto por Czarnecki. Figura 2-5. Representación gráfica de las características y grupos de características. 19

34 Capítulo 2. Ingeniería de Líneas de Producto Software Figura 2-6. Ejemplo de representación gráfica de un modelo de características Representación de la variabilidad en arquitectura Hoy en día, las arquitecturas software son la pieza fundamental del proceso de diseño software para sistemas complejos. Las arquitecturas software son el puente que permiten unir requisitos e implementación. Existe un amplio rango de definiciones realizadas por varios autores, de las cuales las más representativas son: [IEEE-1471, 2000]: La arquitectura es la parte fundamental de un sistema incorporada en sus componentes, sus relaciones con otros, y el entorno, y los principios que guían su diseño y evolución. [SEI, 2007]: Una arquitectura es la descripción de las estructuras de un sistema, puede haber varias (descomposición modular, de proceso, de despliegue, de capas, etc.). La arquitectura es el primer artefacto que puede ser analizado para determinar cómo son logrados los atributos de calidad, y también sirve como el plan del proyecto. Una arquitectura sirve como el vehículo de comunicación, es la manifestación de las decisiones de diseño tempranas, y es una abstracción reusable que puede ser transferida a nuevos sistemas La arquitectura de línea de productos o en inglés Product Line Arquitecture (PLA) es la clave para la reutilización sistemática, ya que describe la estructura de toda la familia de productos, mostrando sus componentes y las relaciones entre los mismos a través de interfaces. Una interfaz define una relación contractual entre un componente que requiere la realización de una funcionalidad y otro que la provee. La especificación de la interfaz es independiente del componente que la implementa. 20

35 Capítulo 2. Ingeniería de Líneas de Producto Software La variabilidad a nivel de arquitectura se consigue mediante la creación de componentes variantes y componentes opcionales. Los aspectos comunes de la arquitectura son capturados por los componentes de software que son comunes a toda la familia, y los aspectos variables de la arquitectura son capturados por los componentes de software que varían entre los miembros de la familia. A veces, un componente debe de ser excluido de un producto. Por ejemplo, hay aplicaciones para las que no es necesario incluir una interfaz de usuario. Ante esta situación, la arquitectura debe buscar reducir la dependencia con este tipo de componente opcional. Esta especificación de variabilidad a través de la adición o eliminación de elementos arquitectónicos (componentes, interfaces, etc) se conoce como variabilidad externa. En ocasiones, la especificación de la variabilidad externa no es suficiente para el desarrollo de SPLs [Magro09]. Esto es debido a que a veces, parte del comportamiento de los componentes es común a toda la SPL y parte de su comportamiento cambia dependiendo del producto. Debido a esto, es necesaria la especificación de variabilidad dentro de los componentes, es lo que se conoce como variabilidad interna. Por ejemplo, se podría tener una interfaz gráfica común, con una serie de características comunes para todos los teléfonos pertenecientes a una SPL, pero que dependiendo del rango de resolución de la pantalla de cada producto se incorpore esta interfaz gráfica. Una solución para soportar tanto variabilidad externa como interna, es la noción de Plastic Partial Component (PPC). Los PPCs son una solución para soportar la variación interna de los componentes en arquitecturas software. El mecanismo de los PPCs se basa en los principios de Composición Invasiva del Software [Assmann, 2003]. Estos principios definen los componentes como piezas software que se enlazan con fragmentos reutilizables de código. Específicamente, estos fragmentos reutilizables de código son variantes, lo que facilita el mantenimiento de los componentes, y consecuentemente, de las arquitecturas software. Estas variantes pueden entrecruzar la arquitectura (crosscutting-concerns) o no (non-crosscutting concerns). 21

36 22

37 Capítulo 3. Desarrollo de Software Dirigido por Modelos 3. DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS 3. Desarrollo de Software Dirigido por Modelos 3.1. Model Driven Engineering (MDE) Modelos y metamodelos: mecanismos de abstracción en desarrollo software Model Driven Development (MDD) Model Driven Architecture (MDA) Software Factories TRANSFORMACIÓN DE MODELOS ESTANDARES EN MDE Comparativa: proceso de desarrollo tradicional vs MDE 3.2. Modelos específicos de domimio (DSM) En la ingeniería informática como en otros campos, el objetivo es mejorar y evolucionar los productos ya existentes. Estas mejoras y evoluciones se trasladan al mundo del hardware y del software. Por ejemplo, en un sector del hardware se busca que los dispositivos como discos duros, memorias, etc., tengan una mayor capacidad de almacenamiento y al mismo tiempo se busca reducir su tamaño físico y conseguir una velocidad de procesamiento más elevada. Sin embargo, en el software las mejoras y evoluciones que se puedan producir son algo más complejas ya que el software no es algo físico que se pueda manipular. Durante las últimas décadas, se ha estado buscando mejoras en la creación de software y su proceso de desarrollo ha ido evolucionando con la intención de simplificarlo y dotar al programador de una mayor abstracción. Para ello, se han ido incorporando nuevos niveles de abstracción y de esta forma surgieron los primeros lenguajes de programación. Inicialmente la programación se realizaba mediante código máquina a través de secuencias de bits que los ordenadores entendían y ejecutaban. En este caso la abstracción era nula, la necesidad de conocer la arquitectura de ordenadores era primordial y la distancia respecto al razonamiento humano era grandísima ya que casi ningún humano podría entender el código maquina escrito por otra persona. De esta forma, 23

38 Capítulo 3. Desarrollo de Software Dirigido por Modelos surgieron los primeros lenguajes de programación como el lenguaje ensamblador, que abstraían al programador de las complejidades del manejo del código máquina incorporando una serie de instrucciones y subrutinas que hacían más sencillo el desarrollo de programas y su seguimiento, aunque aún era necesario conocer muy bien la arquitectura de la computadora en la que estuviésemos trabajando para poder programar. Posteriormente a finales de los años 50 aparecen los primeros lenguajes de alto nivel que se caracterizan por expresar los algoritmos de una forma más cercana a los humanos que a las máquinas. A principios de los años 60 aparece la programación estructurada y con ella una serie de lenguajes de programación que abstraían aún más al programador de la arquitectura, además que estos lenguajes daban lugar a programas más eficientes y mucho más comprensibles y fáciles de seguir y de leer para las personas. El teorema del programa estructurado establecía que cualquier programa escrito con un lenguaje de programación estructurado podía construirse en función de tres estructuras de control: las estructuras condicionales, las iterativas y las secuencias. Estos lenguajes supusieron un gran avance, aunque requerían de ciertas habilidades en los programadores. Sobre la década de los 80, surgió la ingeniería del software asistida por computador (CASE) (Computer-Aided Software Engineering) cuyo objetivo principal era desarrollar métodos y herramientas software que permitieran a los desarrolladores especificar sus diseños mediante representaciones gráficas genéricas. El problema de esta tendencia fue que las representaciones gráficas no se mapeaban bien a las plataformas subyacentes, y tenían una escalabilidad muy limitada., de ahí que hoy en día, la mayoría de las herramientas CASE tan sólo sean empleadas para generar documentación [Schmidt, D. C., 2006]. Sobre estos mismos años, es decir, sobre la década de 1980 se hicieron muy populares los leguajes orientados a objetos con conceptos de más alto nivel de abstracción y que hacían los programas más entendibles aún y más fáciles de escribir y de mantener. Sin embargo la orientación a objetos no parece soportar los requisitos computacionales del futuro. La evolución tecnológica nos trae nuevos elementos que se escapan al dominio de los objetos como los componentes, patrones, aspectos, escenarios, marcos, etc. Estos conceptos han tenido que ser representados mediante objetos con soluciones complicadas, no estandarizadas y difícilmente escalables. 24

39 Capítulo 3. Desarrollo de Software Dirigido por Modelos Sin embargo todos estos avances desde la programación en código maquina hasta la orientación a objetos han ido enfocados al dominio de la solución, es decir, a las propias tecnologías de programación. Para lograr un mayor nivel de abstracción es necesario centrarse en el dominio del problema, es decir, buscando abstracciones que describan conceptos de dominios, como por ejemplo, conceptos de la industria del automóvil, de la espacial, etc. Centrándose en este dominio se consigue una programación de aplicaciones más simple, que se asemeja más a los conocimientos y a la forma de razonar de los profesionales de cada una de estas áreas. Para centrarse y apuntar al dominio del problema se puede hacer uso de los modelos. Así, de esta forma en torno al año 2000 y siguiendo la tendencia de elevar el nivel de abstracción, surge un nuevo paradigma de desarrollo software: la Ingeniería Dirigida por Modelos (MDE - Model Driven Engineering) que se centra en el empleo de modelos a lo largo de todo el ciclo de vida del software y en los mecanismos que permiten definir transformaciones entre los distintos modelos definidos durante el proceso [Schmidt, D. C., 2006]. Figura 3-1. Evolución de los distintos niveles de abstracción. [Pérez and Alarcón,2010] 3.1. MODEL DRIVEN ENGINEERING (MDE) La ingeniería dirigida por modelos surge con la intención de reducir la complejidad de las plataformas basadas en lenguajes de programación de tercera generación como son ADA, C++, Java, etc. Plataformas existentes como J2EE,.NET, o CORBA están compuestas por miles de clases y métodos con complicadas dependencias, por lo que al desarrollador, le puede suponer un duro esfuerzo el hecho de realizar tareas de migración entre dichas plataformas. Stuart Kent [Kent, 2002] definió por primera vez el término MDE como marco general para la especificación de los modelos y tareas de modelado para realizar un proyecto de desarrollo software de comienzo a fin. 25

40 Capítulo 3. Desarrollo de Software Dirigido por Modelos MDE es una ingeniería de desarrollo software basada en modelos que usa técnicas de generación automática de código para obtener el producto software final. En MDE, los modelos constituyen los elementos centrales en el desarrollo de software, al contrario que en el enfoque tradicional que está más centrado en la implementación. El uso de modelos para el desarrollo del software nos produce soluciones independientes de la tecnología y cuyo código fuente puede haber sido obtenido mediante la generación automática de código. MDE defiende que las soluciones centradas en el código (dominio de la solución) no dan respuesta a las necesidades actuales y propone por tanto centrarse en buscar abstracciones que describan conceptos de dominios (dominio del problema) Modelos y metamodelos: mecanismos de abstracción en desarrollo software El uso de modelos como mecanismo de abstracción no es algo nuevo que se esté empezando a utilizar ahora, sino que durante siglos, el ser humano ha utilizado modelos para tener una representación simplificada de algún elemento de la realidad con distintos fines. El ser humano, incluso desde la prehistoria, se ayudaba con pinturas rupestres para representar estrategias de caza, divinidades, etc. También a lo largo de la historia, se ha ayudado de modelos como mapas territoriales, cartográficos, de carreteras, mapas del cuerpo humano, planos de un edificio etc., para obtener representaciones simplificadas y poder abstraerse de los detalles que por alguna razón no interesasen. En el contexto de la ingeniería, una definición de modelo aceptada es la propuesta por Jean Bézivin [Bézivin, 2001]: mente. >> << Un modelo es una simplificación de un sistema con un objetivo en A lo largo de la historia, las ingenierías más tradicionales han definido modelos como paso previo a la construcción de los sistemas. Estos modelos actúan cómo planos y describen la estructura y el comportamiento del sistema al cual representan. Siguiendo esta tendencia, la Ingeniería del Software utiliza el modelado como uno de los mecanismos habituales con el objetivo de definir el sistema software a construir y especificar su comportamiento y estructura. Un sistema software normalmente tiene diferentes modelos que describen cada cual una parte diferente del sistema, es decir, describen el sistema desde diferentes puntos de vista. El conjunto de los distintos modelos que describen el sistema 26

41 Capítulo 3. Desarrollo de Software Dirigido por Modelos software constituyen el modelo completo de dicho sistema. Puede existir solapamiento entre partes concretas de los modelos, pero nunca de forma completa ya que si ocurriese eso, estaríamos hablando de que los dos modelos que se solapan serian iguales. Una definición de modelo basada en esta idea es la descrita en MDA Explained: The Model Driven Architecture: Practice and Promise : <<Un modelo es una descripción (o parte) de un sistema en un lenguaje bien-formado>> [Kleppe 05]. Figura 3-2. Definición de modelo. Un lenguaje de modelado debe definir los elementos y las relaciones entre éstos, que pueden formar parte de un modelo. Esta información es recogida por el metamodelo del lenguaje. Un metamodelo es un modelo de modelos, es decir, es un modelo que define un lenguaje para expresar un modelo. De la misma forma, para expresar este metamodelo es necesario utilizar otro lenguaje y su correspondiente metamodelo, conocidos como metalenguaje y metametamodelo. Y así sucesivamente se cerraría el bucle infinito cuando el metamodelo de nivel más alto se describe usando el lenguaje que él mismo define. Cuando un modelo se construye según otro modelo, se dice que el modelo es conforme_al el modelo que se construye. De esta forma, un modelo tiene una relación conforme_a con su metamodelo. Ejemplo, sea un documento XML, se puede validar respecto a un esquema XML y determinar si satisface la relación conforme_al esquema XML, es decir, si nuestro documento XML está expresado correctamente siguiendo la gramática que define XML. En cambio, los objetos que hacen realidad un modelo concreto que describe un sistema software, son instancias_de dicho modelo. Entre metamodelo y lenguaje se establece una relación de definición, ya que un metamodelo define un lenguaje de modelado. A su vez, un lenguaje de modelado se define como el conjunto de modelos formado por todos los modelos 27

42 Capítulo 3. Desarrollo de Software Dirigido por Modelos que ese lenguaje puede formar, los cuales pertenecen a él. Por tanto, un metamodelo define un lenguaje, al igual que ocurre entre metamodelo y metalenguaje. Meta-metamodelo Define Metalenguaje de modelado Es conforme a Se describe Es conforme a Metamodelo Modelo Define Se describe Lenguaje de modelado Figura 3-3. Relaciones entre modelos, metamodelos y lenguajes de modelado. La importancia de los metamodelos en el desarrollo software se halla en que gracias a ellos, los modelos se pueden especificar formalmente. Una especificación formal es susceptible de ser interpretada por una máquina lo cual, permite el desarrollo de herramientas que la manipulen, y automaticen el desarrollo de software Model Driven Development (MDD) El desarrollo de software dirigido por modelos (MDD) es un paradigma de desarrollo que aplica los principios de MDE al desarrollo de software, es decir, es un paradigma de desarrollo software basado en modelos que usan técnicas de generación automática de código para obtener el producto software final. En MDD podemos diferenciar dos tendencias: Model Driven Architecture (MDA) iniciativa del Object Management Group (OMG) y Software Factories propuesta por Microsoft. A continuación se introducen las principales características de cada una de ellas Model Driven Architecture (MDA) MDA es una iniciativa del Object Management Group (OMG) que tiene como objetivo situar los modelos en un nivel de abstracción tal que su realización 28

43 Capítulo 3. Desarrollo de Software Dirigido por Modelos en múltiples plataformas sea posible buscando la portabilidad, interoperabilidad y la reusabilidad a través de la separación arquitectónica de conceptos. Para conseguir esto, MDA enfoca sus actividades principales en modelar los diferentes aspectos de un sistema a construir, ignorando hasta el final del proceso de desarrollo los detalles de implementación de cómo éste se implementa en una plataforma concreta y definiendo transformaciones entre los distintos modelos para conseguir la automatización de todo el proceso de desarrollo. De esta forma, un desarrollo basado en MDA permite especificar un sistema independiente de la plataforma destino y transformar la especificación del sistema para que sea soportado por diferentes plataformas. De la misma manera, MDA persigue la estandarización de las tecnologías empleadas en el proceso de desarrollo para permitir interoperabilidad entre las distintas herramientas y aplicaciones que toman parte en el desarrollo de software. A continuación se definen algunos conceptos básicos que conforman el núcleo de MDA. Sistema: Los conceptos de MDA se definen centrados en la existencia de un sistema. Este sistema puede contener: un programa, un simple sistema informático, un ordenador simple, una combinación de diferentes parte de sistemas, o diferentes sistemas en diferentes organizaciones. Modelo: El modelo de un sistema es la descripción o especificación de ese sistema y su entorno para desempeñar un determinado objetivo. Dirigido por modelos: MDA es un acercamiento al desarrollo de sistemas haciendo uso de modelos y utilizándolos como piezas fundamentales en el proceso de desarrollo. MDA es dirigido por modelos porque durante todo el proceso de desarrollo (diseño, construcción, mantenimiento, etc.) utiliza los modelos para dirigir el proceso de desarrollo. Arquitectura: La arquitectura del sistema es la especificación de las partes del sistema y de las conexiones entre ellas, y de las reglas de interacción entre las partes del sistema usando conectores. MDA determina algunos tipos de modelos que pueden ser usados, como tienen que prepararse dichos modelos y las relaciones existentes entre ellos. Punto de vista: Un punto de vista de un sistema es una abstracción haciendo uso de un conjunto seleccionado de conceptos de la 29

44 Capítulo 3. Desarrollo de Software Dirigido por Modelos arquitectura y reglas estructurales para centrarse en conceptos particulares del sistema. Vista: Una vista es la representación de un sistema desde un punto de vista determinado. Plataforma: Una plataforma es un conjunto de subsistemas y tecnologías que aportan un conjunto coherente de funcionalidad a través de interfaces y patrones de uso específico. Una aplicación que se construya para una plataforma puede ser utilizada sin preocuparse por los detalles de implementación dentro de la plataforma. Alguna plataformas de ejemplo son: CORBA, J2EE, etc. Aplicación: En MDA se utiliza la palabra aplicación para referirse a la funcionalidad que tiene que ser desarrollada. Por tanto, un sistema es descrito por una o más aplicaciones que son soportadas por una o más plataformas. Independencia de Plataforma: Esta es una cualidad que todo modelo en MDA debe tener. Esta característica lo que significa es que todo modelo ha de ser independiente de las características que implementan las plataformas. Puntos de Vista de los MDA: o o o Punto de vista de computación independiente: se centra sobre la adaptación del sistema, y los requisitos para el sistema; los detalles de la estructura y el proceso del sistema están ocultos o indeterminados. Punto de vista de independencia de plataforma: se centra en las operaciones del sistema mostrando la especificación del sistema que no cambia de una plataforma a otra. Punto de vista de plataforma específica: combina la vista de independencia de plataforma con un enfoque adicional centrado en los detalles del uso por parte del sistema de una plataforma específica. El modelo de plataforma: Un modelo de plataforma suministra un conjunto de conceptos técnicos que representan los diferentes tipos de elementos que conforman una plataforma y los servicios que provee. 30

45 Capítulo 3. Desarrollo de Software Dirigido por Modelos También especifica, para su uso en los modelos específicos de plataforma, los conceptos que representan los diferentes tipos de elementos utilizados para especificar el uso de la plataforma por una aplicación. Un modelo de plataforma especifica también los requisitos de conexión y uso de las partes de la plataforma y la conexión de aplicaciones a la plataforma. Transformación: La transformación del modelo es el proceso de convertir un modelo en otro del mismo sistema. En apartados posteriores lo veremos más detalladamente. Para alcanzar sus objetivos, MDA define una arquitectura de desarrollo software, formada por cuatro niveles de abstracción: CIM (Computation Independent Model), PIM (Platform Independent Model), PSM (Platform Specific Model) y CM (Code Model): Computation Independent Model (CIM): es el primer modelo en la jerarquía de MDA. Un modelo CIM describe una aplicación en función de conceptos independientes de la computación, especificando los requisitos del sistema. Los modelos CIM son usados principalmente por los expertos del dominio. Platform Independent Model (PIM): Es el segundo nivel en la arquitectura de desarrollo. Los modelos PIM describen el funcionamiento de un sistema mediante un enfoque computacional, pero sin especificar detalles tecnológicos asociados a las características específicas de la plataforma que soportará al sistema. Un modelo PIM modela el sistema desde el punto de vista del negocio. Siguiendo la arquitectura MDA, un modelo PIM se puede construir a partir de un modelo CIM, aunque a veces no es estrictamente necesario. Platform Specific Model (PSM): Tercer nivel en la arquitectura definida por MDA. Un modelo PSM describe un sistema desde el punto de vista de la plataforma concreta en la que vaya a ejecutarse. Estos modelos combinan las especificaciones independientes de la plataforma con las especificaciones de la plataforma escogida. Siguiendo la arquitectura definida por MDA, un modelo PSM es construido a partir de un PIM, es decir, un modelo PIM puede transformarse en uno o varios PSM. Code Model (CM): El paso final es la generación de código (en un lenguaje de programación) a partir del PSM, ya que estamos en el último 31

46 Capítulo 3. Desarrollo de Software Dirigido por Modelos nivel en la arquitectura de MDA. Este paso es trivial generalmente, debido a que el modelo PSM es cercano a la plataforma. Figura 3-4. Niveles de abstracción en MDA. [Pérez and Alarcón,2010] El proceso que MDA propone para el desarrollo de un sistema para una plataforma concreta consiste en primer lugar en la construcción de un CIM, el CIM se transforma en un PIM. Seguidamente, el PIM se transforma en uno a varios PSM y por último, cada uno de los PSM genera mediante transformaciones el código de forma automática. Las transformaciones que se ejecutan aunque idealmente deben estar automatizadas, a veces recibe información adicional del ingeniero basada en el modelo para indicar ciertas decisiones de diseño. Proceso de desarrollo MDA. El proceso de desarrollo MDA no difiere excesivamente del proceso de desarrollo tradicional. La Figura 3-5 muestra el proceso de desarrollo software de MDA. Como muestra la figura, el primer paso en el desarrollo de software en MDA sería la captura de requisitos, que está formada mayoritariamente por texto. El paso siguiente es obtener el modelo independiente de la plataforma (PIM) expresado en un lenguaje estándar como UML o MOF. Seguidamente, mediante transformaciones y herramientas de transformación, se genera a partir del PIM inicial, uno o más modelos PSM dependiendo de las plataformas 32

47 Capítulo 3. Desarrollo de Software Dirigido por Modelos específicas que se definan. Por último, a partir del modelo PSM se obtiene el código expresado en la plataforma específica que se haya elegido en el PSM. Dado que los modelos PSM son cercanos a la plataforma, este paso generalmente es trivial. Requisitos Texto Análisis PIM Diseño PSM Implementación Código Pruebas Código Implantación Figura 3-5. Proceso de desarrollo MDA Software Factories Software Factories es la propuesta de Microsoft para el desarrollo de software dirigido por modelos. Software Factories apuesta por utilizar intensivamente lenguajes específicos de dominio aunque la utilización de estos lenguajes ya ha había sido resaltado previamente por MDA. El objetivo de esta propuesta es industrializar el desarrollo software para conseguir establecer líneas de producción que automaticen la creación de productos. Con esta propuesta, el desarrollo de aplicaciones se basa en el uso de esquemas (Schemas) y plantillas (Templates). Los esquemas son modelos que describen cómo se construyen los productos de una misma familia y que relaciones hay entre ellos, es decir, describen cómo construir las aplicaciones utilizando unos determinados recursos. Sin embargo, una plantilla es un conjunto 33

48 Capítulo 3. Desarrollo de Software Dirigido por Modelos de recursos como asistentes, lenguajes específicos de dominio, etc., que son usados para configurar el entorno de desarrollo de una aplicación SPL concreta. Podríamos hacer un símil, si comparamos los esquemas con la receta de un plato de cocina y las plantillas con los ingredientes del plato. En este caso podríamos decir, que los esquemas serían la receta, es decir, la manera de crear nuestro producto y que la plantilla contendrá los ingredientes, es decir, los recursos necesarios. Al contrario que MDA, Software Factories resta importancia a la independencia de la plataforma y se centra más en la productividad. Los modelos en este enfoque no son los principales protagonistas, sino que además se debe de disponer un conjunto de recursos adicionales para poder llevar a cabo el desarrollo de software. Software Factories se desarrollan utilizando un conjunto de herramientas integradas dentro de Visual Studio 2005 (y en versiones posteriores), llamadas DSL Tools (Domain Specific Languages Tools) Transformación entre modelos. En el apartado , se observó como desde un modelo CIM o PIM definido por un desarrollador, era posible obtener el código de la aplicación (CM), en un lenguaje determinado mediante transformaciones sucesivas. Para ello, previamente se deben de definir las transformaciones sin ambigüedad, para que las transformaciones sean únicas. Las transformaciones generalmente no suelen aplicarse a modelos completos, sino que se van realizando transformaciones parciales de ellos. Uno de los objetivos más importantes de las transformaciones es lograr la trazabilidad entre los requisitos definidos en los modelos CIM y el código final, para poder verificar que mediante las transformaciones que hayamos definido, los requisitos especificados en el modelo CIM, se vean reflejados en el código final. Kleppe define los siguientes conceptos [Kleppe, 2005]: <<Una transformación es la generación automática de un modelo destino, a partir de un modelo fuente de acuerdo con una definición de transformación. >> <<Una definición de transformación es un conjunto de reglas de transformación que juntas describen como un modelo expresado en un lenguaje fuente puede transformarse en un modelo expresado en un lenguaje destino. >> 34

49 Capítulo 3. Desarrollo de Software Dirigido por Modelos <<Una regla de transformación es la descripción de cómo una o varias construcciones en un lenguaje fuente pueden transformarse en una o varias construcciones en un lenguaje destino. >> Aunque estas definiciones implican que las transformaciones son siempre automáticas, no siempre es cierto. Para que estas definiciones se puedan realizar en la realidad, deben de existir herramientas que aplicando las reglas definidas consigan realizar la transformación de cualquier modelo fuente en un modelo destino. La Figura 3-6 muestra cómo las herramientas de transformación, aplicando las definiciones de transformación, transforman un modelo origen expresado en un determinado lenguaje, en un modelo destino expresado en otro determinado lenguaje. Es necesario tener en cuenta, que las transformaciones se definen a nivel de los metamodelos, como podemos apreciar en la figura, ya que un lenguaje es definido por un metamodelo. Figura 3-6. Visión general de las transformaciones. [Gómez,2008]. De acuerdo a la naturaleza de los elementos que forman el origen de la transformación y el destino, existe una clasificación muy extendida que distingue 35

50 Capítulo 3. Desarrollo de Software Dirigido por Modelos dos tipos de transformaciones: Transformaciones modelo a modelo (Model To Model o M2M): Son aquellas en las que tanto el origen de la transformación como el destino son modelos. Transformaciones modelo a texto (Modelo To Text o M2T): Son aquellas en la que el origen es un modelo pero el destino es texto no sujeto a ningún metamodelo. Son útiles para la generación de código y documentación. Las transformaciones además se pueden clasificar también en transformaciones verticales y transformaciones horizontales, de acuerdo al nivel de abstracción de sus modelo/s origen y modelo/s destino. Las transformaciones verticales se dan cuando el modelo origen y el modelo destino, pertenecen a distinto nivel de acuerdo a la arquitectura de desarrollo software formada por los cuatro niveles de abstracción que define MDA (ver apartado ). Un ejemplo de transformación vertical podría ser una transformación PIMPSM o también de PSMCódigo (CM). Las transformaciones horizontales se dan cuando el modelo origen y el modelo destino pertenecen al mismo nivel. Un ejemplo de transformación horizontal podría ser la transformación PIMPIM que es utilizada cuando no se requiere añadir información específica de una plataforma Estándares en MDE Para poner en práctica MDD, la OMG propone el empleo de diferentes estándares entre los que podemos encontrar: Meta Object Facility (MOF): Las especificaciones MOF [MOF, 2001] definen una arquitectura para metamodelado. En particular, MOF definn una arquitectura de referencia de 4 niveles, en la que cada elemento del nivel x es instancia de un elemento de nivel superior x+1. Estos 4 niveles, se les denomina comúnmente: M3, M2, M1, M0: El nivel M3: Es el más abstracto. Este nivel define un metametamodelo y provee un lenguaje abstracto (MOF) para la definición de metamodelos en el nivel M2. El propio MOF se define a sí mismo en el nivel M3. El lenguaje MOF se puede considerar como un subconjunto del diagrama de clases UML, y en la versión actual tenemos dos variantes: EMOF (Essential MOF) y CMOF 36

51 Capítulo 3. Desarrollo de Software Dirigido por Modelos (Complete MOF). El nivel M2: Este nivel define metamodelos, es decir, define la estructura y la semántica de los modelos del nivel M1. Pertenecerían a este nivel por ejemplo conceptos como clases, atributos, relaciones de asociación, agregación, etc. El nivel M1: Este nivel define modelos, más concretamente define modelos de sistemas conforme a sus respectivos metamodelos definidos en el nivel M2. Conceptos de este nivel pueden ser entidades como persona, atributos como nombre y relaciones entre entidades. El nivel M0: Este es el nivel de información y ejecución. Este nivel define un modelo concreto, es decir, un producto software. Sus elementos son datos o instancias, como por ejemplo Pepe, que es una instancia concreta de una clase persona. La Figura 3-7 muestra un ejemplo de cómo cada nivel definido en la arquitectura es definido haciendo uso de los conceptos del nivel superior. Figura 3-7. Arquitectura de referencia MOF. [UML, 2007]. 37

52 Capítulo 3. Desarrollo de Software Dirigido por Modelos La arquitectura de referencia MOF, además se relaciona con otros numerosos estándares como (UML, OCL, XMI, QVT). Unified Modeling Language (UML): UML es un lenguaje visual de modelado estándar para visualizar, especificar y documentar sistemas software. Los conceptos y relaciones del lenguaje están definidos en MOF. Los objetivos principales de UML son soportar especificaciones independientes de lenguajes de programación y también permitir la interoperabilidad entre herramientas. Mediante el estándar XMI, sus modelos se pueden exportar al igual que ocurre con MOF. En la arquitectura de 4 niveles definida en MDA, UML tiene un papel muy importante ya que el OMG intenta que sea el estándar utilizado para la descripción de los modelos PIM y PSM, aunque también considera que se pueden utilizar lenguajes definidos con MOF. Object Constraint Language (OCL): Normalmente, los modelos UML no están definidos suficientemente, y a veces surge la necesidad de aplicar alguna restricción a alguno o entre alguno de los elementos que se encuentran definidos en nuestro diagrama UML. Para poder escribir estas restricciones se desarrollo OCL. OCL es un lenguaje formal y tipado (ya que cada expresión OCL tiene asociado un tipo), utilizado para describir restricciones sobre modelos UML. Estas restricciones realizan consultas sobre los objetos que tenemos definidos en los modelos UML. Es importante tener en cuenta que cuando evaluamos una expresión OCL, el resultado de la misma no altera el estado del modelo UML original ni del sistema. XML Metadata Interchange (XMI): XMI es un estándar del OMG que define reglas, las cuales permiten expresar en XML cualquier modelo o metamodelo que se haya definido en MOF, con el objetivo de poder intercambiar información de manera automática entre diferentes herramientas independientemente de la plataforma en la que se encuentren. XMI define cómo se deben de crear los documentos XML y los esquemas XML que se utilizan para la validación de la sintaxis de los elementos del modelo que se definen en el documento XML. Query Views Transformations (QVT): QVT es un lenguaje que define el marco en MDA para especificar transformaciones entre modelos y metamodelos definidos en MOF. QVT nos permite consultar modelos, la creación de vistas de modelos y definir transformaciones de modelos (de 38

53 Capítulo 3. Desarrollo de Software Dirigido por Modelos forma declarativa o imperativa). QVT se apoya en otros estándares ya existentes dentro del OMG como son MOF para la definición de artefactos y OCL para la consulta de los artefactos Comparativa: proceso de desarrollo tradicional vs MDD En el proceso de desarrollo tradicional, a medida que un sistema cambia con el tiempo, la distancia entre el código y los diagramas y textos que lo describen es mayor. Los cambios suelen realizarse a nivel de código puesto que normalmente no se dispone de tiempo suficiente para actualizar los diagramas u otros documentos de alto nivel. Durante los últimos años se han hecho muchos progresos en el desarrollo del software, que han permitido construir sistemas más grandes y complejos. Aun así, la construcción de software de la manera tradicional sigue teniendo múltiples problemas. A continuación, se muestra una comparativa desde el punto de vista de la productividad, portabilidad, interoperabilidad, mantenimiento y documentación entre ambos procesos la cual mostrará los problemas del proceso de desarrollo de software tradicional y cómo MDD los resuelve. Problemas del proceso de desarrollo tradicional: Productividad: En el proceso de desarrollo de software tradicional, la interacción entre sus fases no está suficientemente automatizada. Cada fase se realimenta de manera artesanal de las salidas de la fase anterior, lo que genera un riesgo de inconsistencias entre lo desarrollado y las fases previas del desarrollo. El objetivo sería dotar al modelo de desarrollo de mecanismos automáticos de interacción de fases y aumentar el nivel de consistencia entre el código desarrollado y el análisis del problema. Portabilidad: En la industria del software, cada año aparecen nuevas tecnologías y las empresas necesitan adaptarse a ellas, bien porque el cliente las solicita, bien porque soluciona problemas importantes existentes o porque se dejan de soportar antiguas tecnologías. Como consecuencia, el software existente debe adaptarse o migrar a la nueva tecnología. Esta migración no es ni mucho menos trivial, y obliga a las empresas a realizar un importante desembolso. El objetivo sería aumentar el nivel de abstracción mediante el uso de 39

54 Capítulo 3. Desarrollo de Software Dirigido por Modelos modelos y garantizar la conversión automática entre modelos dependientes de la tecnología y modelos independientes de la tecnología. Interoperabilidad: Un sistema normalmente no se ejecuta de forma aislada. La mayoría de sistemas necesitan interaccionar con múltiples tecnologías y sistemas diferentes, probablemente ya construidos. Incluso si los sistemas que van a comunicarse se construyen desde cero, frecuentemente usan tecnologías diferentes. Por ejemplo, una aplicación simple con interfaz web y acceso a bases de datos utiliza diferentes tecnologías para la parte relacionada con la interfaz web y otras tecnologías para la parte relacionada con la base de datos y su gestión. Sin embargo, la comunicación entre ambas partes es vital para el correcto funcionamiento global de la aplicación. El objetivo sería aumentar el nivel de abstracción mediante el uso de modelos y definir modelos de comunicación y trazabilidad entre modelos. Mantenimiento y documentación: La mayoría de los ingenieros software se consideran tan sólo desarrolladores, teniendo como único objetivo producir líneas de código. La documentación de un proyecto software es una tarea lenta que consume mucho tiempo, y que en realidad no interesa tanto a los que desarrollan el software, sino que es útil para el miembro o los miembros del equipo que lo modificarán o lo usarán más adelante y para el mantenimiento software. Debido a esto se suele poner poco entusiasmo en la realización de la documentación y generalmente se caracteriza por ser de poca calidad y realizarse mayoritariamente a mano. Solo a nivel de código hay cierto grado de automatización, como por ejemplo en Java. El objetivo para resolver estos problemas es hacer que los documentos sean modelos y que la documentación sea generada automáticamente en todas las etapas del ciclo de vida software. Además, será necesario definir la trazabilidad entre los distintos modelos del ciclo de vida software y los modelos de documentos. 40

55 Capítulo 3. Desarrollo de Software Dirigido por Modelos Beneficios de MDD: Solución al problema de la Productividad: En MDD el desarrollador debe de centrarse en el PIM, ya que es donde recae el foco de desarrollo. Los PSM se generan normalmente de forma automática a partir del PIM. El problema es que para ejecutar esta transformación de PIMPSM, antes se debe de definir exactamente la transformación, lo cual es una tarea difícil y especializada. Sin embargo, una vez definida una única vez esta transformación, ya se podrá aplicar de forma automática en el desarrollo de muchos sistemas. Por tanto, con sólo definir una buena transformación aumentaremos la productividad, reduciremos el tiempo de desarrollo y mantenimiento futuros. Solución al problema de la Portabilidad: La portabilidad se consigue con el desarrollo de los PIM. Al ser un modelo independiente de la plataforma, todo lo definido en él es totalmente portable. El mismo PIM puede ser transformado en múltiples PSMs para diferentes plataformas. Solución al problema de la Interoperabilidad: Los modelos PSM que provienen de un mismo PIM, normalmente tienen y necesitan relacionarse entre ellos. Estos modelos PSM por pertenecer a distintas plataformas o tecnologías, no pueden comunicarse directamente entre ellos. Sin embargo, MDD soluciona este problema creando puentes entre ellos. Estos puentes, son construidos por las herramientas de transformación, las cuales son uno de los pilares en los que se apoya MDD. Mantenimiento y documentación: El modelo PIM mediante transformaciones genera el modelo PSM y de igual forma el modelo PSM genera el código. Sin embargo, el modelo PIM desempeña el papel de la documentación a alto nivel que se necesita para cualquier sistema software. La mayoría de las herramientas son capaces de mantener las relaciones de trazabilidad entre el PSM y el PIM, por lo que los cambios realizados en el sistema se reflejarán en todos los niveles, mediante la regeneración de los PSMs y del código. Esto marca una gran ventaja frente al proceso de desarrollo de software tradicional, en el que los cambios en las aplicaciones pocas veces se reflejaban en etapas anteriores a la etapa de implementación. Aun 41

56 Capítulo 3. Desarrollo de Software Dirigido por Modelos así, siempre se necesitará documentación adicional que no pueda expresarse con el PIM, por ejemplo, para justificar las elecciones hechas en la construcción del modelo PIM MODELOS ESPECÍFICOS DE DOMINIO (DSM) Los modelos específicos de dominio o en inglés Domaim Specific Model (DSM) son una aproximación al desarrollo software basada en modelos y centrada en el uso de modelos específicos de dominio como principales elementos en el proceso. Los DSM son aplicables a múltiples plataformas con el mismo dominio y se especifican utilizando lenguajes diseñados para representar específicamente el conocimiento del dominio, son los llamados lenguajes específicos de dominio que veremos más adelante. El DSM eleva el nivel de abstracción por encima de la programación, especificando la solución mediante conceptos del dominio y obteniendo la generación automática de código a partir de esas especificaciones. Todo modelo necesita un lenguaje que permita especificarlo. Un lenguaje específico de dominio (Domain Specific Language o DSL) es un lenguaje de programación o de especificación dedicado a un dominio en particular. Son lenguajes que ofrecen un conjunto reducido de notaciones más cercanas al dominio del problema que al dominio de la implementación y ofrecen un alto nivel de abstracción para el desarrollo de aplicaciones. Así, de esta manera los desarrolladores de software disponen y trabajan con un lenguaje que recoge sus necesidades del dominio. Un ejemplo muy común que conocemos todos, es por ejemplo la gestión de directorios e información en disco. Para abordar este tema, la mayoría de los sistemas operativos, se centran en el dominio de una oficina, con sus elementos como son el escritorio con sus carpetas que dentro pueden tener archivos, las papeleras que también pueden tener archivos y documentos o carpetas que ya no sirven, etc. Para representar los directorios y toda su gestión relacionada con ellos, la mayoría de los sistemas operativos utilizan DSL centrado en el dominio de una oficina, el cual puede ser entendible y manejable para cualquier persona. La utilización de DSL tiene una seria de ventajas e inconvenientes que se exponen a continuación: Ventajas: La utilización de DSL eleva el nivel de abstracción hasta el 42

57 Capítulo 3. Desarrollo de Software Dirigido por Modelos dominio del problema, por lo que los expertos del dominio pueden entender, validad y desarrollar programas haciendo uso del lenguaje. Las especificaciones creadas con los DSL son breves, autodocumentadas y pueden ser reutilizables. Se mejora la productividad, portabilidad y mantenibilidad de las aplicaciones sobre todo se obtienen unos beneficios altos en compañías con un alto rango de productos similares o con líneas de producto. Sin embargo, en compañías que trabajan con en proyectos pequeños no se obtienen tales beneficios. Los DSL pueden ser usados para la generación automática de código. Inconvenientes: Uno de los mayores inconvenientes es la gran inversión económica inicial para el coste de diseño, implementación y mantenimiento del lenguaje el cual requiere unas mayores cualificaciones técnicas para del programador. A parte de esto, tendríamos que contar también con el poco conocimiento que hay para la elaboración de un DSL y la poca documentación de la que se dispone, por lo que habría que contar también con los costes de formación del personal y aprendizaje. Existen dos técnicas para la definición de un nuevo lenguaje y modelo: La definición pesada del lenguaje que se realiza mediante la definición de un metamodelo, y la definición ligera que se realiza mediante la definición de un perfil UML. La definición pesada es la que más se utiliza en la realidad y es en la que nos centraremos. Los principales pasos para la creación de un DSL son: 1. Análisis del dominio específico: Debemos de tener claro el objetivo del DSL y del dominio en el que nos encontramos para poder definir correctamente nuestro lenguaje. 2. Definición del metamodelo: Debemos de definir nuestro metamodelo, pensando en los elementos del lenguaje que queremos implementar, junto con la relaciones permitidas entre ellos y si debemos de especificar alguna restricción en algún elemento o relación. 43

58 Capítulo 3. Desarrollo de Software Dirigido por Modelos 3. Definir representación visual: Debemos de elegir adecuadamente una representación visual intuitiva y basada en el mundo real para representar cada elemento y conexión del lenguaje. 4. Desarrollar generadores: Los generadores se encargan de generar el código asociado a nuestro nuevo lenguaje creado, a un lenguaje concreto. Además de generar el código, también se encarga de producir la documentación, producir métricas, información de configuración, etc. 44

59 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE 4. HERRAMIENTA PARA EL MODELADO DE TRAZABILIDAD EN SPLE 4. Herramientas para el modelado de Trazabilidad en SPLE 4.1. Contexto: FPLA 4.2. Plataforma de desarrollo 4.3. Modelo de Características (Feature Diagram) Descripción del metamodelo Representación gráfica Iconografía Modificaciones del código (SRC) 4.4. Modelo de Trazabilidad (Traceability Diagram) Descripción del metamodelo Representación gráfica Iconografía Modificaciones del código (SRC) Restricciones OCL 4.5. Integración en la herramienta FPLA Este Trabajo Fin de Carrera parte de un trabajo previo que ha desarrollado una herramienta para la especificación de arquitecturas de líneas de producto (PLA) llamada FPLA. 14 El objetivo de este Trabajo Fin de Carrera es extender FPLA, para complementar su funcionalidad permitiendo la trazabilidad entre requisitos y PLAs. Concretamente, entre el modelo de características y el modelo de PLA 15. Para ello, FPLA será extendida incorporando una vista que permita definir modelos de características y otra vista que permita la especificación de dicha trazabilidad. En las líneas de producto la variabilidad es el elemento más característico de una SPL. La variabilidad debe especificarse tanto a nivel de requisitos (modelo de características) como a nivel de arquitectura (modelo de PLA). La trazabilidad de la variabilidad entre ambas especificaciones es imprescindible para poder reaccionar ante futuros cambios, modificaciones o cambios de requisitos que puedan afectar a los productos de la línea y que se sepa en todo momento, qué componentes (elementos de la arquitectura) se ven implicados o afectados al 14 Flexible Product Line Architecture 15 Product Line Architecture 45

60 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE efectuar un cambio en las primitivas para el modelado de trazabilidad entre el modelo de características y el modelo de PLA. Por lo tanto, la vista de trazabilidad, debe soportar de la trazabilidad necesaria entre la arquitectura de líneas de producto software (que describirá la estructura de toda la familia de productos) y el modelo de características. Puesto que FPLA permite definir modelos de PLA, se desarrollará en primer lugar una nueva vista que permita definir modelos de características (vista de características). Una vez construida esta vista, se desarrollará una nueva vista intermedia a estas dos (vista de trazabilidad), que permitirá soportar la trazabilidad necesaria entre ambos modelos (modelo de características y modelo de PLA). Desarrolladas las dos vistas, se integrarán en la herramienta FPLA para añadirla una especificación de trazabilidad entre requisitos. La Figura 4-1 muestra un esquema del objetivo que pretende este Trabajo Fin de Carrera. Integración de las dos vistas en FPLA Vista de Características Vista de Trazabilidad Vista de Arquitectura (definida en FPLA) Figura 4-1. Esquema del objetivo que persigue este trabajo CONTEXTO: FPLA El trabajo presentado parte de una investigación previa [Perez, 2009] [Perez, 2010], que tiene por objetivo la especificación de variabilidad en arquitecturas de líneas de producto software (PLAs). Para especificar la variabilidad se desarrollo la herramienta FPLA, mediante un proceso de desarrollo software dirigido por modelos (MDD) que facilita la creación de lenguajes específicos de dominio. FPLA define un conjunto de vistas arquitecturales para describir modelos de (PLAs). El Trabajo Fin de Carrera define dos nuevas vistas para FPLA. La primera vista (Feature Diagram) ofrece las primitivas para modelar modelos de 46

61 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE características, que especifican la variabilidad de la (SPL) a nivel de requisitos. La vista (Traceability Diagram) se encargará de dotar la trazabilidad necesaria entre diagramas de características y modelos de PLA PLATAFORMA DE DESARROLLO La aplicación ha sido desarrollada utilizando la plataforma Eclipse [ECL11]. Concretamente, las herramientas de modelado Eclipse Modeling Framework (EMF) [EMF11] y Graphical Modeling Framework (GMF) [GMF11]. Eclipse es una herramienta que permite integrar diferentes aplicaciones para construir un entorno integrado de desarrollo IDE 16. Eclipse además, es una plataforma de desarrollo de software abierto (open-source), con lo cual nos proporciona la ventaja de que disponemos de una fuente principal de documentación y descarga de aplicaciones y complementos en Internet sobre la plataforma Eclipse. En este sitio es posible encontrar recursos, documentos, tutoriales, wikis, comunidades de usuarios, referencias a proyectos relacionados, etc. EMF y GMF son herramientas de modelado específicas de dominio. GMF proporciona una herramienta para la generación de editores gráficos basados en EMF y GEF 17. Este último es el que permite al desarrollador crear un editor gráfico completo de forma rápida a partir de un modelo de una aplicación. GMF establece un proceso muy específico para construir una herramienta de este tipo. Éste se compone de los siguientes subprocesos: definición del metamodelo, generación automática de código, definición de la metáfora gráfica, definición de las herramientas del modelo, especificación de la correspondencia entre los elementos del modelo y la metáfora gráfica, y generación de la herramienta (ver Figura 4-2). Como se puede observar en el diagrama de la Figura 4-2, el centro del proyecto es el Domain Model, es decir el modelo del dominio o metamodelo que será el origen del proceso y del cual se derivarán el resto de subprocesos. El modelo del dominio se define utilizando EMF mediante un lenguaje de definición de modelos denominado Ecore. Todos y cada uno de los subprocesos de GMF están relacionados con el modelo y como indica su nombre, Ecore, constituirá el centro del proyecto en todo momento. Una característica destacable en GMF es la reutilización de la definición gráfica para diferentes dominios y aplicaciones. Esta 16 Integrated Development Environment 17 Graphical Editing Framework 47

62 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE característica se consigue modelando por separado las componentes gráficas que se corresponden con cada uno de los elementos del dominio y la definición de la paleta de herramientas, la cual tendrá una herramienta por cada primitiva. Para completar el proceso de generación de un editor gráfico de dominio, GMF proporciona una definición de mapping o correspondencia mediante la que se asocia cada primitiva de modelado con su componente gráfica y con su herramienta dentro del editor que se está generando. Figura 4-2. Desarrollo de un proyecto GMF. GMF precisa de un metamodelo y para ello se sirve de EMF. EMF es una herramienta que proporciona una estructura de modelado y facilidades para la generación de código al objeto de construir herramientas basadas en un modelo de datos estructurado. A partir de una especificación XML de un modelo, EMF suministra herramientas y soporte de ejecución para producir un conjunto de clases Java en base a ese modelo, un conjunto de clases Adapter, que permiten su visualización y edición basándose en comandos del modelo, y un editor básico. La Figura 4-3 muestra la estructura de proyectos que sigue GMF, concretamente la estructura de proyectos que componen FPLA, incluidos los proyectos de las vistas desarrolladas. 48

63 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Figura 4-3. Proyectos de FPLA. El proyecto principal es es.upm.syst.fpladefinition ya que contiene la definición del metamodelo Ecore, así como el resto de especificaciones GMF para la definición completa de la herramienta (ver Figura 4-4). Figura 4-4. Proyecto Principal Metamodelo Ecore. 49

64 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE A partir del metamodelo Ecore, así como del resto de especificaciones GMF, se realiza la generación automática del código de la herramienta FPLA. Así, todos los proyectos con el sufijo.diagram (ej. es.upm.syst.fplafeature.diagram) contienen código completamente generado por los plugins EMF y GMF de Eclipse. Este es también el caso de los proyectos es.upm.syst.fpladefinition.edit es.upm.syst.fpladefinition.editor que contienen código generado también automáticamente. Por último el código, de la carpeta src del proyecto principal es.upm.syst.fpladefinition es también código generado (ver Figura 4-5). Figura 4-5. Código generado automáticamente en el proyecto principal MODELO DE CARACTERÍSTICAS (Feature Diagram) El apartado 3.2 define un lenguaje específico de dominio como un lenguaje gráfico o textual para un propósito determinado adaptado a los problemas concretos de un dominio. En el dominio de SPL, los modelos de características son las herramientas básicas para modelar, analizar y configurar la variabilidad a nivel de requisitos. Estas tareas son complejas y por lo tanto, hacen necesarias herramientas que proporcionen funciones de modelado, configuración de los productos finales, etc. Por esta razón, se ha desarrollado la vista Feature Diagram, que define e implementa un lenguaje específico de dominio que modela los modelos de características utilizando la definición que propone FODA (Feature Oriented Domain Analysis) (ver apartado 2.2.1) junto con el metamodelo propuesto por Czarnecki que añadió cardinalidades a las características y grupos de características. En el metamodelo de Czarnecki [Czarnecki, 2005], los modelos de 50

65 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE características están formados por una característica raíz del árbol jerárquico, de la que cuelgan el resto de características, que a su vez pueden ser características simple o grupos de características, como se aprecia en el metamodelo de la Figura 2-4. Este metamodelo está definido en lenguaje MOF, que implementa la vista Feature Diagram, y cuya apariencia difiere un poco respecto al metamodelo implementado con EMF definido en lenguaje Ecore. Esto es así, ya que EMF permite crear modelos basados en Ecore (metamodelo de EMF para dar soporte al modelado) y cuyas relaciones entre metaclases se aplican y se definen con unos conceptos algo distintos al de las relaciones UML tradicionales. Por ejemplo, los metamodelos Ecore que definidos en EMF, necesitan de un elemento raíz (una metaclase) que relacione mediante agregación todas las metaclases del metamodelo. Así pues, el metamodelo Ecore definido para la vista Featur Diagram, es el representado en la Figura 4-6. Figura 4-6. Metamodelo Ecore que implementa Feature Diagram Descripción del metamodelo A continuación se detalla cada una de las metaclases con sus respectivos atributos, que componen el metamodelo Ecore de la Figura 4-6: 51

66 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE RootFeature: Hereda de Feature. Es utilizada para representar la raíz del modelo de características siguiendo una estructura de árbol jerárquica. Feature: Metaclase abstracta. Atributos: Name: De tipo string. Este atributo especifica el nombre de la instancia de la metaclase hija, pudiendo ser una SolitaryFeature, RootFeature, o GroupedFeature. FeatureGroup: Metaclase abstracta. Atributos: Group Cardinality: De tipo string. Especifica la cardinalidad del grupo, es decir, el número mínimo y máximo de elementos que puede tener el grupo. SolitaryFeature: Hereda de Feature. Representa una característica simple de un sistema software. GroupedFeature: Hereda de Feature. Representa una característica agrupada (es decir, una característica que pertenece a un grupo de características) de un sistema software. FeatureGroups: Conjunto de GroupedFeatures. Se distinguen dos tipos: Un grupo Or de GroupedFeatures, y un grupo Xor de GroupedFeatures. Or: Hereda de FeatureGroup. Representa un grupo Or de GroupedFeatures de las cuales al menos una de ellas será seleccionada si su padre es seleccionado cuando se defina un producto concreto de la SPL. Xor: Hereda de FeatureGroup. Representa un grupo Xor de GroupedFeatures de las cuales sólo una de ellas será seleccionada si su padre es seleccionado cuando se defina un producto concreto de la SPL. Feature Model: Metaclase raíz necesaria en el metamodelo Ecore en EMF que relaciona mediante agregación todas las metaclases del modelo. 52

67 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Representación gráfica Este apartado detalla la representación gráfica utilizada para la vista Feature Diagram. Esto es la forma en la que los elementos de la vista se representan en el tapiz, los iconos utilizados en los botones de la paleta, la forma en la que se ha dividido la paleta en subgrupos y también la forma en la que se ha representado las relaciones o links, etc. La Figura 4-7 muestra la representación gráfica utilizada de los distintos elementos y enlaces en el tapiz. Elemento Representación en tapiz Root Feature Solitary Feature Grouped Feature Or Group Xor Group Mandatory Feature Optional Feature FeatureGroup has Grouped Feature Figura 4-7. Representación gráfica en el tapiz de los distintos elementos en la vista Feature Diagram. 53

68 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE La justificación de la forma y colores escogidos para cada elemento (ver Figura 4-7) es la siguiente: Root Feature: Su representa mediante un rectángulo en cuyo interior se especifica el atributo Nombre. Se puede apreciar el grosor de este rectángulo con el objetivo de remarcar el elemento raíz (Root Feature) del modelo de características. En cuanto al color, se ha empleado un color naranja claro, apropiado para una impresión tanto a color, como a blanco y negro. Solitary Feature: La forma de este elemento es rectangular. La Solitary Feature debe de reflejar su cardinalidad. Para que su representación quede más legible, se ha separado el nombre de la Solitary Feature, de su cardinalidad mediante un línea de color negro. En cuanto al color, se ha utilizado un marrón claro, con el objetivo de poder ser impreso sin problemas y para que el color de fondo de la figura no distorsione el valor de sus atributos. Grouped Feature: Se representa mediante un rectángulo con los bordes redondeados y con una línea discontinua como borde del rectángulo para diferenciarse del resto de elementos del modelo. En cuanto al color, se representa con un color de fondo blanco. Or Group: Este elemento ha sido muy fácil de diseñar, ya que se ha seguido la simbología que propone Czarnecki [Czarnecki, 2005] y Phol [Pohl, 2005] (ver apartado 2.2.1). Por tanto, la forma de este elemento es un triángulo de color de fondo blanco, del cual saldrán sus enlaces correspondientes hacia los Grouped Feature. También mostrara la cardinalidad que por defecto vendrá con el siguiente valor: [a..b] y que el usuario podrá modificar. Xor Group: Su representación es similar a la de Or Group, exceptuando el color de relleno del triángulo que es negro. Su cardinalidad, al ser un grupo exclusivo siempre será de valor: [1..1]. Mandatory Feature: Sigue la simbología que propone Czarnecki y Phol para este tipo de elemento, es decir, una línea con una circunferencia de color negro en su destino. Optional Feature: Su representación es similar a la de Mandatory 54

69 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Feature, exceptuando que el color de relleno de la circunferencia en el destino es color blanco Iconografía FeatureGroup has Grouped Feature: La forma de este enlace es una simple línea que mediante una flecha, indica el sentido del enlace. Durante el proceso de desarrollo de un lenguaje especifico de dominio en GMF, en el subproceso de generación automática de código, GMF genera por defecto en la ruta miproyecto.edit\icons\full\obj16, los iconos en formato.gif que aparecerán en la paleta de la herramienta gráfica y en la ruta nombredemivista.diagram\icons\obj16 crea el icono asociado al nombre de la vista. Estos iconos generados por defecto, tienen el siguiente aspecto:,. Pero en este caso, se necesita que la paleta de la vista Feature Diagram, muestre los iconos con alguna imagen representativa, intuitiva y fácilmente comprensible del elemento a representar en el tapiz. Por ello, se han definido nuevos iconos, eliminando los anteriores y sustituyéndolos por los nuevos generados. La Figura 4-8 muestra los diferentes iconos que aparecen en la vista. Elemento Icono representativo Feature Diagram (nombre de la vista) Root Feature Solitary Feature Grouped Feature Or Group Xor Group Mandatory Feature Optional Feature FeatureGroup has Grouped Feature Figura 4-8. Iconos de la paleta de herramientas de la vista Feature Diagram. 55

70 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE la siguiente: La justificación del diseño de cada uno de los iconos de nodos y enlaces es Feature Diagram: Feature Diagram es el nombre de la vista. Debido a que el objetivo de esta vista es la realización y visualización de modelos de características, el icono pensado para su representación se basa en 4 piezas de puzle encajadas entre sí, que buscan asociar a ellas la idea de construcción, encajamiento o acoplamiento de piezas, etc. Los colores utilizados son muy llamativos con el objetivo de atraer a la vista. Root Feature: Como su propio nombre indica, al ser el elemento raíz de nuestro modelo de características, su icono debe de intentar reflejarlo. Por eso se pensó para su icono, en dibujar un elemento de mayor tamaño en el que nuestros ojos se centren a primera vista, y que de este elemento saliesen varios hijos o ramas más pequeños. Con esta forma de representación en árbol, cualquier usuario entiende que lo que se está representando es la idea de un elemento raíz. Si nos fijamos bien en detalle en el icono, se puede apreciar que del elemento raíz salen 3 ramas o hijos, en concreto 3 Solitary Feature (por el color azul de sus hijos) de las cuales dos ramas son mandatarias y una de ellas es opcional. En cuantos a los colores utilizados, se sigue utilizando la misma gama de colores utilizados que en el icono Feature Diagram. Solitary Feature: Se ha representado con un cuadrado de color azul. Se ha escogido un cuadrado ya que es una figura geométrica muy familiar y simple, y el color azul sigue la línea de los colores utilizados en el icono de la vista Feature Diagram. Grouped Feature: En este caso, la idea que se ha querido transmitir es la de agrupación de características. Los Grouped Feature son los elementos que descenderán en nuestro diagrama de los grupos de características OR y XOR. Por eso, en el icono que hemos diseñado aparecen 3 cuadrados agrupados y cada uno de un color siguiendo la gama de colores utilizados en el icono de la vista. Or Group: El icono escogido para la representación de un grupo Or de características ha resultado muy sencillo de decidir, ya que se 56

71 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE ha utilizado la representación propuesta por Czarnecki. [Czarnecki, 2005]. Es decir, se representa con un conjunto de arcos agrupados sobre un fondo de color blanco. Xor Group: Idem que el anterior, pero el conjunto de arcos agrupados sobre un fondo de color negro. Mandatory Feature: Este icono se ha representado siguiendo la simbología de Czarnecki, es decir, una línea que en el destino tiene una circunferencia de color negro. Optional Feature: idem que el anterior, excepto que la circunferencia en el destino de la línea es de color blanco. FeatureGroup has Grouped Feature: Para representar el icono de este enlace, se ha pensado en transmitir la idea que el propio link expresa en su nombre. Es decir, un Feature Group que tiene Grouped Feature, los cuales se ha intentado plasmar en el icono. Por tanto, como se puede apreciar en la Figura 4-8, se tiene un Feature Group, concretamente un Xor Group, del cual cuelgan dos ramas con sus correspondientes iconos de Grouped Feature. Es un icono bastante representativo de lo que quiere expresar. En cuanto a los colores utilizados, son los mismos que llevan utilizando en el resto de iconos. Se debe destacar, que en vez de el Xor Group dibujado en el icono, podríamos haber escogido un Or Group del que colgasen sus Grouped Feature, pero se eligió el primero, dado que lleva su fondo sobre color negro el cual se visualizaría mejor ya que son iconos pequeños de 16x16 pixeles Modificaciones del código (SRC) El código final generado automáticamente por GMF, ha sido necesario modificarlo para poder representar algunas funcionalidades que la propia herramienta GMF no incluía por defecto. GMF en su modelo para la representación gráfica en el tapiz de los enlaces, no contempla la creación de circunferencias pero si de elipses en la decoración del enlace. Por ello, ha sido necesario añadir código para poder representar nuestras circunferencias en el destino del enlace. 57

72 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Para representar los enlaces Mandatory Feature y Optional Feature se ha utilizado la representación que propone Czarnecki, la cual consiste en dibujar un círculo de color negro (obligatorio) o blanco (opcional) en la característica destino, como se vio en el apartado Para ello, se ha creado una nueva clase CircleDecoration (ver anexo), que herede de la clase Ellipse y que sobrecarga algunos métodos de su clase padre para poder representar una circunferencia, que no deja de ser una elipse en la que sus radios tienen el mismo valor. Esta clase ha sido añadida en la ruta es.upm.syst.featuretool.diagram\src\lps\lps\diagram\edit\parts\circle Decoration.java. Entonces, en las clases es.upm.syst.featuretool.diagram\src\lps\lps\diagram\edit\parts\featurelpsf_ha s_mandatoryfeditpart.java y es.upm.syst.featuretool.diagram\src\lps\lps\diagram\edit\parts\featurelpsf_ha s_optionalfeditpart.java (las cuales implementan el enlace Mandatory Feature y Optional Feature (respectivamente) se importa la clase Circle Decoration.java para poder llamar a los constructores de estos círculos y a alguno de sus métodos para definir por ejemplo el radio del circulo MODELO DE TRAZABILIDAD (Traceability Diagram) Esta vista debe de dotar de la trazabilidad necesaria entre el modelo de la PLA y el modelo de características que describe la variabilidad posible a nivel de requisitos en una SPL siguiendo una estructura jerárquica de árbol. La Figura 4-9 muestra el diagrama UML que implementa está vista. Este diagrama, debe de ser expresado en lenguaje Ecore para ser el metamodelo origen del proceso de desarrollo de GMF. Se debe mencionar, que los elementos del diagrama UML Solitary Feature, Component, Plastic Partial Component, Connector, Feature Group, Variability Point, AspectVP, FeatureVP, Grouped Feature, Variant, Variant Feature y Variant Aspect, son elementos que provienen de otras vistas definidas en la aplicación FPLA. Si han sido definidos en esta vista concreta, ha sido para poder probar la funcionalidad y funcionamiento de la vista por separado independientemente del resto de vistas, para garantizarnos que una vez integrada su funcionamiento sea el esperado. 58

73 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Figura 4-9. Metamodelo UML que implementa Traceability Diagram. El metamodelo de la Figura 4-10 es el metamodelo Ecore el cual debe de implementar la vista. 59

74 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Figura Metamodelo Ecore que implementa Traceability Diagram. 60

75 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Este es el metamodelo inicial de la vista Traceability Diagram. En él aparecen clases y relaciones redundantes, ya que definen un tipo de elementos o un tipo de enlaces similares como por ejemplo las clases PLAElementType1, PLAElementType2, PLAElementType4,Feature_with_Component_LinkageRule, Feature_with_OptionalComponent_LinkageRule,Group_with_VP_LinkageRule,Gro uped_with_variant_linkagerule. Esta redundancia supone un problema a la hora de llevar a cabo la implementación de esta vista, ya que estas clases y enlaces generaran sus correspondientes componentes gráficos en el tapiz de esta vista, y con ello en la paleta de herramientas sus correspondientes botones sobrecargándola en exceso. Esta sobrecarga no correspondería a un buen diseño eficiente del metamodelo. La Figura 4-11 muestra la paleta de herramientas sobrecargada. En ella se observa, como por cada uno de los 4 tipos de enlaces que define la clase SatisfactionLink_FPLA (LinkageRule Type1, LinkageRule Type2, LinkageRule Type3, LinkageRule Type4), aparecen dos links (un link origen y otro destino) con el fin de establecer las relaciones entre los elementos orígenes y elementos destino, formando un total de 8 links para establecer estas relaciones. Figura Representación de la paleta de herramientas sobrecargada. 61

76 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Debido a los inconvenientes citados, surge la necesidad de intentar conseguir un diseño del metamodelo mucho más eficiente y simplificado. Dado que las metaclases PLAElementType1, PLAElementType2 y PLAElementType4, son metaclases muy similares y la única función de estas clases es la de la distinción de las diferentes reglas que define la clase SatisfactionLink_FPLA, se pensó la creación de una nueva metaclase Super_LinkageRule, y que por medio de un atributo de tipo Enumerado, hacer la distinción entre los cuatro tipos de enlaces que define la metaclase SatisfactionLink_FPLA. De este modo, la metaclase SatisfactionLink_FPLA pasa de tener cuatro definiciones de reglas diferentes, a tener tan sólo una regla definida Super_LinkageRule y a través de su atributo de tipo Enumerado informará que tipo de regla de las 4 se está definiendo. Además de esto, aplicando restricciones OCL las reglas de enlace quedarán simplificadas a tan sólo 2 links (Source Link y Target Link) en la paleta de herramientas. Estas restricciones OCL, describen la semántica para la definición de links entre elementos del modelo de características y elementos del modelo de PLAs, en función del valor del atributo del Super_LinkageRule. Con todo ello, se pasa de tener (4x2) 8 links para representar los diferentes enlaces que el Super_LinkageRule puede definir, a tener tan solo 2 links. La Figura 4-12 muestra el metamodelo Ecore resultante simplificado apoyándose en las restricciones OCL las cuales se detallan en el apartado

77 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Figura Metamodelo Ecore simplificado de la vista Traceability Diagram. Con este metamodelo, el elemento SatisfactionLink_FPLA sólo tiene una relación de agregación con el Super_LinkageRule, y el Super_LinkageRule ahora define en su atributo (que es de tipo Enumerado) el tipo de regla o enlace que define. Se debe de prestar atención a como ahora un Super_LinkageRule sólo se encarga de relacionar elementos Source Link o Target Link, desentendiéndose de la tarea de gestionar que elementos origen se pueden relacionar a través del 63

78 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Super_LinkageRule con los elementos destino, ya que de esta tarea se encargaran la restricciones OCL implementadas en los enlaces Source Link y Target Link. La Figura 4-13 representa la paleta de herramientas después de estas simplificaciones. Figura Representación de la paleta de herramientas simplificada. Algunos elementos que aparecen en la paleta de la Figura 4-13, como por ejemplo los elementos que forman el grupo Source Elements y Target Elements, no aparecerán cuando se integre esta vista con el resto de vistas de la herramienta FPLA, ya que estos elementos vendrán definidos en otra paleta de herramientas correspondiente a otra vistas definidas en la aplicación FPLA. De hecho, la paleta final de esta vista, como aparecerá en apartados posteriores, será esta misma paleta de herramientas pero sin los grupos anteriormente citados Source Elements y Target Elements. Si estos grupos han sido definidos en esta vista concreta, ha sido con la intención de poder probar la funcionalidad y funcionamiento de la vista por separado independientemente del resto de vistas, para garantizarnos que cuando sea integrada su funcionamiento sea el esperado. 64

79 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Descripción del metamodelo A continuación se detalla cada una de las metaclases con sus respectivos atributos, que componen el metamodelo Ecore de la Figura 4-12: Raiz: Metaclase raíz necesaria del metamodelo Ecore en EMF que relaciona mediante agregación todas las metaclases del modelo. Model Element: Metaclase abstracta. De esta metaclase heredan todos los elementos que pueden aparecer representados gráficamente en el tapiz. Source Link: Metaclase abstracta. Abstrae atributos y operaciones mediante herencia, teniendo como descendientes los elementos que forman parte de los modelos de características. Target Link: Metaclase abstracta. Abstrae atributos y operaciones mediante herencia, teniendo como descendientes los elementos que forman parte de los modelos de la PLA. SatisfactionLink_FPLA: Ofrece las primitivas para instanciar el tipo del enlace de trazabilidad de satisfacción. Esta metaclase tiene 4 atributos los cuales definen propiedades como el nombre, la versión, el peso, y el grado de satisfacción del elemento SatisfactionLink. Estas propiedades basadas en el trabajo de Hauser y Clausing (1988), proporcionan información sobre la trazabilidad entre el modelo de características y el modelo de arquitectura (PLA). Esta metaclase además puede contener un elemento Super_LinkageRule que definirá el tipo de regla de enlace que se definirá. Atributos: Name: De tipo string. En este atributo podemos especificar el nombre de nuestra instancia de la clase. Version: De tipo string. Aquí podremos especificar la versión en la que es válido nuestro enlace satisfactorio. Weight: Mide el valor o importancia del enlace. Satisfaying: De tipo Satisfaying Type. Mide el grado de realización o cumplimiento del enlace. 65

80 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Super_LinkageRule: Esta metaclase proporciona las primitivas para instanciar las reglas lógicas que rigen los enlaces. Esta clase tiene solamente un atributo que define el tipo de regla de enlace que se va a definir. Cada tipo determina cuales son las trazabilidades permitidas entre los elementos de los modelos conforme a sus respectivos metamodelos y define la lógica para crear los enlaces entre ellos. Atributos: Type: De tipo LinkageRule_Type2. Especifica el tipo de regla de enlace que se va a definir. Enumeración LinkageRule_Type: Define las diferentes reglas de enlace que puede definir un elemento Super_LinkageRule. Valores: Feature_with_Component_LinkageRule Feature_with_OptionalComponent_LinkageRule GroupVP_with_LinkageRule Grouped_with_Variant_LinkageRule Representación gráfica Este apartado especifica la representación gráfica utilizada para la vista Traceability Diagram. Esto es la forma en la que los elementos de la vista se representan en el tapiz, los iconos utilizados en los botones de la paleta, la forma en la que se ha dividido la paleta en subgrupos y también la forma en la que se ha representado las relaciones o links, etc. La Figura 4-14 muestra la representación gráfica de los distintos elementos y enlaces en el tapiz. Se debe recordar que algunos elementos que se representaran en esta vista como son concretamente los elementos Solitary Feature, Component, Plastic Partial Component, Connector, Feature Group, Variability Point, AspectVP, FeatureVP, Grouped Feature, Variant, Variant Feature y Variant Aspect, son elementos definidos de otras vistas definidas de la aplicación FPLA y que por tanto no se analizan sus representaciones. 66

81 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Elemento Representación en tapiz Satisfaction Link Linkage Rule Source Link Target Link Figura Representación gráfica en el tapiz de los distintos elementos en la vista Traceability Diagram. A continuación, se analiza la forma, tamaño y colores escogidos para cada elemento (ver Figura 4-14 ): Satisfaction Link: Es representado mediante un rectángulo que muestra los valores de sus cuatro atributos. Para que su representación quede mucho más legible, se ha separado con una línea negra el nombre, de sus cuatro atributos. En cuanto al color, se ha utilizado el color blanco en el color de fondo del elemento para que pueda ser impreso sin problemas tanto a color como en monocromo. Linkage Rule: Se representa con una doble flecha bidireccional de color negro. La decisión de representar el Linkage Rule con una doble flecha bidireccional, se consideró que es la más intuitiva para representar gráficamente este elemento, ya que enlazará consigo dos elementos. En cuanto al color negro, es el más visible para su 67

82 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE impresión. Source Link: Se representa mediante una simple línea que a tavés de una flecha, indica el sentido del enlace. Target Link: Idem que el anterior Iconografía Durante el proceso de desarrollo de un lenguaje especifico de dominio en GMF, en el subproceso de generación automática de código, GMF genera por defecto en la ruta miproyecto.edit\icons\full\obj16, los iconos en formato.gif que aparecerán en la paleta de la herramienta gráfica y en la ruta nombredemivista.diagram\icons\obj16 crea el icono asociado al nombre de la vista. Estos iconos generados por defecto, tienen el siguiente aspecto:,. Pero en este caso, se necesita que la paleta de la vista Traceability Diagram, muestre los iconos con alguna imagen representativa, intuitiva y fácilmente comprensible del elemento a representar en el tapiz. Por ello, se han definido nuevos iconos, eliminando los anteriores y sustituyéndolos por los nuevos generados. La Figura 4-15 muestra los diferentes iconos que aparecen en la vista. Elemento Icono representativo Traceability Diagram (nombre de la vista) Satisfaction Link Linkage Rule Source Link Target Link Figura Iconos representativos que aparecen en la vista Traceability Diagram. 68

83 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE La justificación del diseño de cada uno de los iconos es la siguiente: Traceability Diagram: Traceability Diagram es el nombre de la vista. El objetivo de esta vista es modelar la trazabilidad entre los elementos, por ello, el icono pensado para su representación se basa en 4 rectángulos pequeños de los que salen 3 flechas de color rojo que establecen uniones entre ellos. En el diseño de este icono, se ha querido representar la trazabilidad como flechas que unen elementos. Se ha utilizado el color rojo ya que es un color bastante visible al contraste con los rectángulos que son de color negro. Satisfaction Link: Debido a que el objetivo de este elemento es unir o encadenar elementos del modelo de características y modelo de PLAS, el icono pensado para establecer este encadenamiento está formado por cuatro eslabones de una cadena que intentan representar este concepto. Linkage Rule: Para representar el icono de este elemento se ha utilizado la misma representación que la utilizada para representarlo en el tapiz, es decir, una doble flecha bidireccional de color negro. Source Link: El icono de este enlace está representado con un Linkage Rule, es decir, una doble flecha bidireccional, y en su parte inferior izquierda aparece un cuadrado pequeño que representa un elemento unido al Linkage Rule con una flecha pequeña de color rojo. Con esta representación se busca plasmar la idea de un elemento que está unido o enlazado al origen del Linkage Rule. Para representar el concepto de enlace origen, es intuitivo representar el enlace origen a la izquierda, ya que en nuestra cultura occidental leemos de izquierdas a derechas. Target Link: Representación similar a la de Source Link, excepto que ahora lo que se busca es plasmar la idea de enlace destino, por lo que el Linkage Rule, es decir, en la parte inferior derecha de la doble flecha bidireccional, es donde se encuentra un cuadrado pequeño que representa un elemento unido al Linkage Rule. 69

84 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Modificaciones del código (SRC) El código final generado automáticamente por GMF, ha sido necesario modificarlo para poder representar algunas funcionalidades que la propia herramienta GMF no incluía por defecto. GMF en su modelo para la representación gráfica en el tapiz de los enlaces, no contempla la creación de circunferencias pero si de elipses en la decoración del enlace. Por ello, ha sido necesario añadir código para poder representar nuestras circunferencias en el destino del enlace. Para realizar estas modificaciones, se ha realizado exactamente lo mismo que en el apartado Se recomienda la lectura de ese apartado si fuera preciso. La única diferencia que existe con lo realizado en el apartado 4.2.4, es que las clases que implementan los enlaces Mandatory Feature y Solitary Feature, ahora estarán en la ruta de la vista de trazabilidad, es decir, estarán en es.upm.syst.traceabilitytool.diagram\src\traceability\ traceability\diagram\ edit\parts\featurelpsf_has_mandatoryfeditpart.java y es.upm.syst.traceabilitytool.diagram\src\traceability\traceability\diagram\ edit\parts\featurelpsf_has_optionalfeditpart.java Restricciones OCL OCL es un lenguaje formal y tipado (ya que cada expresión OCL tiene asociado un tipo), utilizado para describir restricciones sobre modelos UML. En esta vista, se han añadido restricciones OCL al metamodelo UML de la Figura 4-9, para que pueda ser expresado en lenguaje Ecore (Figura 4-12) y resulte lo más simplificado posible. En concreto, se ha añadido restricciones a los enlaces o links Source Link y Target Link, y al elemento Linkage Rule cuya restricción es un tanto especial, ya que en este elemento no sólo se aplicarán las restricciones OCL para implementar el metamodelo Ecore, sino que además se pretende notificar al usuario por pantalla de que no está diseñando un modelo correcto en cuanto a la cardinalidad de la Or o Xor, las cuales deben de ser las mismas que las que definan sus correspondientes punto de variabilidad. 70

85 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Restricciones del link Source Link Las restricciones determinan qué tipo de enlace define en su atributo el elemento Linkage Rule, y con ello gestionar los enlaces para que sólo establezcan relación con el Linkage Rule los elementos orígenes válidos para ese tipo de enlace definidos en el metamodelo UML (Figura 4-9). Esta vista permitirá definir enlaces Source Link, siempre que cumplan al menos una de las siguientes condiciones que aparecen separadas por apartados (cada apartado debe de cumplir todas las condiciones que en él se definen para que permita definir enlaces Source Link ) : Restricción 1: El valor del atributo del Linkage Rule debe ser de tipo Feature_with_Component_LinkageRule, que el elemento origen sea un elemento Solitary Feature y que la cardinalidad de la Solitary Feature sea de [1..N]. Restricción 2: El valor del atributo del Linkage Rule debe ser de tipo Feature_with_OptionalComponent_LinkageRule, que el elemento origen sea un elemento Solitary Feature y que la cardinalidad de la Solitary Feature sea de [0..N]. Restricción 3: El valor del atributo del Linkage Rule debe ser de tipo GroupVP_with_LinkageRule y que el elemento origen sea un elemento Feature Group, es decir, que sean hijos de Feature Group o lo que es lo mismo, que el elemento origen sea de tipo Or o Xor. Restricción 4: El valor del atributo del Linkage Rule debe ser de tipo Grouped_with_Variant_LinkageRule y que el elemento origen sea un elemento Grouped Feature. La Figura 4-16 muestra el código fuente que implementa estas restricciones OCL en GMF, sobre el enlace Source Link. En esta figura de puede observar cómo cada una de estos cuatro grupos de restricciones anteriormente citados, corresponden con los cuatro bloques que aparecen en el código OCL separados por el operador Or. 71

86 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE ( (oppositeend.type=linkagerule_type2::feature_with_component_linkagerule) and (self.ocliskindof(solitaryfeature) ) and (self.oclastype(solitaryfeature).cardinality=solitaryfeature_cardinalitytype::one_to_n) ) or ( (oppositeend.type=linkagerule_type2::feature_with_optionalcomponent_linkagerule) and (self.ocliskindof(solitaryfeature) ) and (self.oclastype(solitaryfeature).cardinality=solitaryfeature_cardinalitytype::zero_to_n) ) or ( (oppositeend.type=linkagerule_type2::groupvp_with_linkagerule) and ( self.ocliskindof(featuregroup) ) ) or ( (oppositeend.type=linkagerule_type2::grouped_with_variant_linkagerule) and (self.ocliskindof(groupedfeature) ) ) Figura Código OCL en GMF, en el enlace Source Link. Restricciones del link Target Link Las restricciones aplicadas a este enlace, consisten en saber qué tipo de enlace tiene definido en su atributo el elemento Linkage Rule, y con ello, gestionar los enlaces para que sólo establezcan relación con el Linkage Rule, los elementos destino válidos y apropiados para ese tipo de enlace definidos en el metamodelo teórico. La vista Traceability Diagram debe permitir definir enlaces Target Link, siempre que cumplan al menos una de las siguientes condiciones que aparecen separadas por apartados: (cada apartado debe de cumplir todas las condiciones que en él se definen para que permita definir enlaces Target Link): Restricción 1: El valor del atributo del Linkage Rule debe ser de tipo Feature_with_Component_LinkageRule, que el elemento destino sea un elemento Component,o Connector, o Plastic Partial Component. Restricción 2: El valor del atributo del Linkage Rule debe ser de tipo Feature_with_OptionalComponent_LinkageRule, que el elemento destino sea un elemento Optional Component, o Optional Connector. 72

87 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Restricción 3: El valor del atributo del Linkage Rule debe ser de tipo GroupVP_with_LinkageRule y que el elemento destino sea un elemento Variability Point, es decir, que sean hijos de Variability Point, o lo que es lo mismo, que el elemento destino sea de tipo AspectVP o FeatureVP. Restricción 4: El valor del atributo del Linkage Rule debe ser de tipo Grouped_with_Variant_LinkageRule y que el elemento destino sea un elemento Optional Component, o Optional Connector, o Variant Aspect, o Variant Feature. La Figura 4-17 muestra el código fuente que implementa estas restricciones OCL en GMF sobre el enlace Target Link. En esta figura se puede observar cómo cada una de estos cuatro grupos de restricciones anteriormente citados, corresponden con los cuatro bloques que encontramos en el código OCL separados por el operador Or. ( (oppositeend.type=linkagerule_type2::feature_with_component_linkagerule) and ( self.ocliskindof(component) or self.ocliskindof(connector) or self.ocliskindof(plasticpartialcomponent) ) ) or ( (oppositeend.type=linkagerule_type2::feature_with_optionalcomponent_linkagerule) and ( self.ocliskindof(optionalcomponent) or self.ocliskindof(optionalconnector) ) ) or ( (oppositeend.type=linkagerule_type2::groupvp_with_linkagerule) and self.ocliskindof(variabilitypoint) ) or ( (oppositeend.type=linkagerule_type2::grouped_with_variant_linkagerule) and ( self.ocliskindof(optionalcomponent) or self.ocliskindof(optionalconnector) or self.ocliskindof(variantaspect) or self.ocliskindof(variantfeature) ) ) Figura Código OCL en GMF, en el enlace Target Link. 73

88 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Restricciones del elemento Linkage Rule Se ha definido una restricción OCL sobre el Linkage_Rule, que tiene como objetivo notificar al usuario por pantalla de que no está diseñando un modelo correcto en cuanto a la cardinalidad de la Or o Xor. Para establecer una trazabilidad entre un Or u Xor y un punto de variabilidad, se debe de controlar la cardinalidad de ambas partes definiendo la misma cardinalidad, tanto a nivel de requisitos como a nivel de arquitectura, tal y como muestra la Figura Figura Control de cardinalidad en Trazabilidad. Por tanto, cuando las cardinalidades entre ambas partes difieran se mostrará un mensaje por pantalla de advertencia, y se dejará en manos del usuario el definir aún así, la relación o no. La Figura 4-19 muestra el mensaje que se mostrara por pantalla para notificar al usuario. Figura Mensaje de notificación al usuario. 74

89 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE Las restricciones concretas son las siguientes: Restricción 1: El valor del atributo del Linkage Rule debe ser de tipo Feature_with_Component_LinkageRule, o Feature_with_OptionalComponent_LinkageRule, o Grouped_with_Variant_LinkageRule. Restricción 2: El valor del atributo del Linkage Rule debe ser de tipo GroupVP_with_LinkageRule, y que el elemento origen y destino del enlace esté sin definir, es decir, que no haya elemento origen ni destino. Restricción 3: El elemento destino del enlace debe de estar sin definir y que el elemento origen del enlace sea de tipo Or. Restricción 4: El elemento destino del enlace debe de estar sin definir y que el elemento origen del enlace sea de tipo Xor y por tanto su cardinalidad sea de [1..1]. Restricción 5: El elemento origen del enlace debe de estar sin definir y que el elemento destino del enlace este definido, es decir, que exista un enlace hacia algún elemento destino. Restricción 6: El elemento destino del enlace debe de ser de tipo Variability Point (es decir, que sean hijos de Variability Point, o lo que es lo mismo, que el elemento destino sea de tipo AspectVP o FeatureVP) con cardinalidad [1..1], y que el elemento origen del enlace sea de tipo Xor con la misma cardinalidad que su Variability Point destino, es decir, con cardinalidad [1..1]. Restricción 7: El elemento destino del enlace debe de ser de tipo Variability Point (es decir, que sean hijos de Variability Point, o lo que es lo mismo, que el elemento destino sea de tipo AspectVP o FeatureVP) con cardinalidad [1..1], y que el elemento origen del enlace sea de tipo Or con la misma cardinalidad que su Variability Point destino, es decir, con cardinalidad [1..1]. Restricción 8: El elemento destino del enlace debe de ser de tipo Variability Point (es decir, que sean hijos de Variability Point, o lo que es lo mismo, que el elemento destino sea de tipo AspectVP o FeatureVP) con la misma cardinalidad que el elemento Or origen del enlace. 75

90 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE La Figura 4-20 muestra el código fuente exacto que implementa estas restricciones OCL en GMF en el elemento Linkage Rule. En esta figura se puede observar cómo cada uno de estos ocho grupos de restricciones anteriormente citados, corresponden con los ocho bloques que encontramos en el código OCL separados por el operador Or. ( self.type=linkagerule_type2::feature_with_component_linkagerule or self.type=linkagerule_type2::feature_with_optionalcomponent_linkagerule or self.type=linkagerule_type2::grouped_with_variant_linkagerule or ( ( self.type=linkagerule_type2::groupvp_with_linkagerule and self.super_has_sourcelink.oclisundefined() and self.super_has_targetlink.oclisundefined() ) or ( self.super_has_targetlink.oclisundefined() and self.super_has_sourcelink.oclastype(or).ocliskindof(or) ) or ( self.super_has_targetlink.oclisundefined() and self.super_has_sourcelink.oclastype(xor).xorgroupcardinality=xorcardinalitytype::one_to_one ) or ( self.super_has_sourcelink.oclisundefined() and (not (self.super_has_targetlink.oclisundefined()) ) ) or ( ( self.super_has_targetlink.oclastype(variabilitypoint).cardinalityselection='[1..1]' and self.super_has_sourcelink.oclastype(xor).ocliskindof(xor) and self.super_has_sourcelink.oclastype(xor).xorgroupcardinality=xorcardinalitytype::one_to_one ) ) or ( self.super_has_targetlink.oclastype(variabilitypoint).cardinalityselection='[1..1]' and self.super_has_sourcelink.oclastype(or).ocliskindof(or) and self.super_has_sourcelink.oclastype(or).orgroupcardinality='[1..1]' ) ) or ( self.super_has_targetlink.oclastype(variabilitypoint).cardinalityselection= self.super_has_sourcelink.oclastype(or).orgroupcardinality ) ) Figura Código OCL en GMF, en el elemento Linkage Rule. 76

91 Capítulo 4. Herramienta para el modelado de Trazabilidad en SPLE 4.5. INTEGRACIÓN EN LA HERRAMIENTA FPLA Para conseguir la integración de las vistas desarrolladas Feature Diagram y Traceability Diagram en FPLA, lo que se debe integrar es el metamodelo Ecore que define cada vista, en el metamodelo Ecore de FPLA. La Figura 4-21 muestra el metamodelo resultante de la integración de ambas vistas en FPLA. En él, aparecen marcados en color verde los elementos y relaciones que implementan la vista Feature Diagram y en color rojo los que implementan la vista Traceability Diagram. 77

92 Capítulo 4. Herramienta para el modelado de trazabilidad en SPLE Figura Metamodelo final. 78

93 Capítulo 5. Caso de Estudio 5. CASO DE ESTUDIO Este capítulo describe un escenario para ilustrar el uso de la herramienta para el modelado de trazabilidad que describe este TFC, a través de varias capturas de la herramienta FPLA. Se mostrará un ejemplo típico de SPL de sistemas software para ventas de producto. Este tipo de sistemas constan normalmente de un servicio al cliente y un servicio de ventas. En este escenario, ambos servicios deben de satisfacer un requisito no funcional: disponibilidad de 24 horas, los siete días de la semana (disponibilidad24/7). La Disponibilidad en un sistema es el porcentaje del tiempo en el cual el sistema está disponible para el usuario. La ISO define disponibilidad como: <<La disponibilidad es una característica que se aplica a los activos. Un activo está disponible si está accesible y usable cuando una entidad autorizada lo necesita. En el contexto de este estándar, un activo puede ser información, sistemas, facilidades, redes y computadoras. Todos estos activos deberían estar disponibles para entidades autorizadas cuando necesiten acceder o hacer uso de ellos>>[iso AND ISO 27002] Algunos productos de esta SPL necesitan de esa disponibilidad estricta, sin embargo otros productos no necesitan satisfacer esa disponibilidad de forma estricta (disponibilidad no-estricta). La disponibilidad se define como un punto de variabilidad entre los productos de la SPL, que a nivel de requisitos (características) se define como muestra la Figura 5-1. Figura 5-1. Modelo de características del caso de estudio (captura de FPLA). 79

94 Capítulo 5. Caso de Estudio A nivel arquitectónico existen varias técnicas para implementar disponibilidad, de las cuales destacan dos: Redundancia Activa y Redundancia Pasiva. Estas técnicas utilizan nodos activos y redundantes (ver Tabla 1). Un nodo activo es un nodo que está a la escucha de peticiones. Un nodo redundante es un nodo de repuesto cuya identificalidad depende de la técnica utilizada. Con identificalidad nos referimos a la posibilidad de que ese nodo sea escogido o le toque el turno para escuchar peticiones, ya que un nodo redundante es una copia del nodo activo. La Figura 5-2 describe para cada técnica, el mecanismo de funcionamiento y el resultado que produce. La Figura 5-3 muestra un esquema de funcionamiento de las técnicas de disponibilidad. Técnica Mecanismo Resultado Redundancia Activa Configuración en la que todos los nodos (activos o redundantes), reciben y procesan idénticas entradas en paralelo, lo que permite la redundancia de repuesto. Redundancia Pasiva Repuesto Configuración en la que sólo los nodos activos procesan el tráfico de entrada, y en la que los nodos redundantes reciben actualizaciones periódicas del estado. Configuración donde los nodos redundantes permanecen fuera de servicio hasta que se produce un fallo. Debido a que el nodo redundante posee un estado idéntico al activo, la recuperación y reparación se pueden realizar en unos milisegundos. Consigue un equilibrio entre la disponibilidad más alta y más compleja de la técnica de Redundancia Activa y la menos disponible y menos compleja de la técnica de repuesto. El nodo redundante copia el estado del nodo activo justo antes de su puesta en servicio. Kazman, 2009] Figura 5-2. Técnicas para implementar disponibilidad en un sistema. [Scott and 80

95 Capítulo 5. Caso de Estudio Figura 5-3. Mecanismo de funcionamiento de las técnicas de Disponibilidad. [Scott and Kazman, 2009] De la Figura 5-2, podemos deducir que: 1. La técnica de la Redundancia Activa necesita un balanceador de carga con el fin de que, tanto los nodos activos como redundantes, procesen el mismo nivel de carga. La técnica de Redundancia Activa necesita además un sincronizador con el fin de mantener los nodos activos y redundantes ambos en el mismo estado. 2. La técnica de Redundancia Pasiva necesita un control periódico de datos para mantener los nodos activos y redundantes con el mismo estado a través de actualizaciones periódicas de su estado. Ambos servicios (servicio al cliente, y servicio de ventas) están implementados por dos Plastic Partial Components (PPCs) que son componentes de arquitectura que permiten especificar variaciones dentro de los propios componentes. Por tanto, los PPCs, tienen una parte común que es independiente del producto a derivar y una parte variable que es dependiente del producto a derivar. Ambos PPCs (ver serv_venta y serv_cliente en la Figura 5.4), definen dos Puntos de Variabilidad Aspecto (AVP) 18 para implementar la disponibilidad24/7 en dos variantes: stricta y no estricta. La Redundancia Activa es implementada por los aspectos Sincronizador y Balanceador de carga, 18 Aspect Variability Point 81

96 Capítulo 5. Caso de Estudio y la Redundancia Pasiva es implementada por el aspecto Controlador de Datos. La Figura 5-4 muestra la vista de variabilidad de la PLA del escenario, y cómo el modelo de esta PLA considera las dos variantes: disponibilidad estricta y noestricta. Figura 5-4. Modelo de la PLA del caso de estudio (captura de FPLA). Para conseguir esta funcionalidad, se ha utilizado el metamodelo de FPLA, el cual permite construir modelos conforme al metamodelo de FPLA. Las reglas de enlaces definidas en el apartado 4.4.1, hacen que sea mucho más fácil para los ingenieros de SPL especificar enlaces de trazabilidad. Las propiedades de trazabilidad (grado de satisfacción, peso, y versión) definidas en el apartado 4.4.1, proporcionan un conocimiento semántico a estos enlaces. Ambos, reglas de enlace y propiedades, son soportadas por la vista Traceability Diagram, en la aplicación FPLA. Esta herramienta ayuda a los ingenieros de SPL en la especificación de los enlaces satisfactorios entre el modelo de características y el modelo de la PLA. La Figura 5-5 muestra un modelo de trazabilidad representado en la vista Traceability Diagram. 82

97 Capítulo 5. Caso de Estudio Esta vista se encarga de definir la trazabilidad entre un modelo de características y un modelo de la PLA. El modelo de características representa la variabilidad de la SPL a nivel de requisitos y el modelo de la PLA representa la variabilidad a nivel de arquitectura. La vista de trazabilidad dispone, como se describió en el apartado 4.4.1, de las primitivas de modelado para la instancia de links de trazabilidad: SatisfactionLink proporciona información sobre la trazabilidad entre las dos vistas, y Super Linkage Rule define el tipo de regla de enlace que se va a definir. En la Figura 5-5 se puede observar, como la cardinalidad del Grupo Xor es la misma que la definida en el AVP, ya que estamos definiendo el mismo Punto de Variabilidad pero visto desde diferentes vistas (vista de características y vista de la PLA). La Figura 5-5 muestra la definición grafica de un subconjunto de enlaces de trazabilidad de satisfacción. Los enlaces de satisfacción 1 y 2 (ver Figura 5-5), establecen la correspondencia entre las SolitaryFeature del modelo de características y los PPCs del modelo de la PLA. Los enlaces 3 y 4 establecen la trazabilidad de la variabilidad entre el modelo de características y el modelo de la PLA. Es decir, la trazabilidad de los puntos de variabilidad entre la SolitaryFeature Disponibilidad24/7 y el AVP Actualizando (enlace 3) y Repartiendo (enlace 4). Los enlaces 5 y 6 marcan las GroupedFeature Estricta con los aspectos Sincronizador y Balanceador_de_carga repectivamente. El enlace 7 marca la GroupedFeature No-estricta con el aspecto Controlador_de_datos. En cuanto a las propiedades, por ejemplo, dado que el GroupedFeature Estricta impacta en los aspectos Sincronizador y Balanceador_de _carga el valor de satisfacción de cada enlace de trazabilidad es partly satisfied (parcialmente satisfecho), ya que un enlace de trazabilidad es parcialmente satisfecho cuando una característica (Feature) se implementa en más de un elemento arquitectural. El resto de características están completamente soportadas por un sólo elemento arquitectónico, por lo que el valor de satisfacción es fully satisfied (completamente satisfecho). Estos valores de satisfacción nos permiten medir el impacto de cada cambio. Este conjunto de enlaces de trazabilidad proporcionan un soporte completo para: garantizar que los requisitos de nuestro caso de estudio están implementados (verificación). las modificaciones futuras necesarias y analizar el impacto del cambio en el modelo de la PLA. asegurar la consistencia entre el modelo de Características y el 83

98 Capítulo 5. Caso de Estudio modelo de la PLA después de la evolución. Figura 5-5. Modelo de trazabilidad del caso de estudio. La trazabilidad entre requisitos y arquitectura es imprescindible para capturar y analizar el impacto del cambio de un requisito, así como para poder reaccionar ante futuros cambios en los requisitos que puedan afectar a la SPL. Es decir, el objetivo es proporcionar una herramienta que permita conocer qué componentes de la arquitectura se ven afectados al efectuar un cambio en los requisitos de la SPL. 84

99 Capítulo 6. Conclusiones y Trabajos futuros 6. CONCLUSIONES Y TRABAJOS FUTUROS 6. CONCLUSIONES Y TRABAJOS FUTUROS 6.1. RESULTADOS OBTENIDOS 6.2. PROBLEMAS ENCONTRADOS 6.3. CONCLUSIONES 6.4. TRABAJOS FUTUROS Este capítulo describe los resultados obtenidos, los problemas encontrados, las conclusiones básicas y los trabajos futuros con los que se podría ampliar el proyecto RESULTADOS OBTENIDOS A pesar de que el desarrollo de la aplicación ha sido costoso, el objetivo de este Trabajo Fin de Carrera que se ha llevado con éxito. Fruto del trabajo realizado, se ha desarrollado una herramienta de modelado que proporciona soporte a la trazabilidad entre requisitos (modelo de características) y modelo de la PLA. Esta herramienta ha sido desarrollada mediante un proceso de desarrollo software dirigido por modelos (MDD), utilizando los plugins de Eclipse GMF y EMF. Por tanto, la herramienta facilita la definición de modelos de trazabilidad entre requisitos y arquitectura en SPLs. La definición de estos modelos, se realiza gráficamente, lo que facilita la tarea del ingeniero software PROBLEMAS ENCONTRADOS Durante el desarrollo del proyecto, han surgido una serie de problemas a los cuales siempre se les ha ido buscando soluciones y mejoras continuas a nuestras soluciones. Un buen ejemplo de esto, es la gran simplificación obtenida que se mostró en la Figura 4-18, a la que fuimos llegando con pequeños pasos. A continuación se exponen los problemas más relevantes encontrados durante la realización de este Trabajo Fin de Carrera. Paradigmas aplicados para el desarrollo complejos: Los paradigmas SPL y MDD que hemos estudiado y aplicado para el desarrollo de nuestra herramienta, son paradigmas relativamente recientes y cuyo entendimiento al principio resultó bastante 85

100 Capítulo 6. Conclusiones y Trabajos futuros complejo. Son paradigmas bastante amplios y que se apoyan en muchos conceptos (metamodelos, modelos, transformaciones de modelos, variabilidad, etc) que hasta el momento de realización de este TFC de desconocía. Escasa información sobre los plugins EMF y GMF e Eclipse: Existe muy poca información sobre estos plugins en la red. Básicamente la poca información disponible sobre estos plugins se encuentra en la web de Eclipse [EMF11] y [GMF11] y aún así no se explica en detalle. El conocer bien el funcionamiento y la mayoría de las funcionalidades que nos aportan estas herramientas a costado meses de trabajo hasta poder dominarla. Por lo tanto, esto se ha traducido en mucho esfuerzo y tiempo dedicado al estudio de estos plugins, ya que han sido las herramientas con las que hemos desarrollado nuestra aplicación. Los problemas más relevantes relacionados con este tema han sido los siguientes: La curva de aprendizaje de la metodología de desarrollo MDD, así como de los plugins que lo soportan es costosa. Pero una vez que se aprende, facilita el desarrollo y reduce considerablemente el tiempo de desarrollo. GMF no lleva consigo la implementación de algunas figuras geométricas como por ejemplo una circunferencia. Debido a esto, se tuvo que investigar la forma en la que podríamos implementarla a partir de un Elipse, para poder representar correctamente los enlaces utilizados en el modelo de características. Por la definición de UML, surgió la necesidad de apoyarnos en restricciones OCL dentro del propio plugin GMF. De nuevo, nos encontramos con el problema anteriormente mencionado en el punto anterior: Poca información sobre el funcionamiento del plugin GMF y menos aún si queremos añadirle restricciones OCL. Debido a esto, aparte de previamente hacer un estudio y comprender las nociones básicas de OCL, surgió la necesidad de investigar con el propio GMF, la manera de poder aplicar restricciones OCL a nuestro metamodelo de trazabilidad. 86

101 Capítulo 6. Conclusiones y Trabajos futuros 6.3. CONCLUSIONES Los temas centrales en los que se ha basado el Trabajo Fin de Carrera como son los paradigmas SPL y MDD ya desde un principio cuando estaba buscando temas en los que basar mi proyecto, me resultaron atractivos. Me parecieron interesantes ya que hasta entonces estos paradigmas resultaban totalmente desconocidos para mí. Me pareció, una excelente oportunidad para poder conocer y estudiar estos paradigmas, ya que las ideas en las que se fundamentan me parecieron muy novedosas, interesantes y con futuro. SPL y MDD conllevan mucha información y conceptos ligados a ellos como variabilidad, puntos de variabilidad, componentes, metamodelos, MOF,CIM,PIM,PSM, transformaciones entre modelos, DSL, etc. Son temas muy extensos y complejos que requieren un esfuerzo para poder comprenderlos bien y tener una visión global de ellos. La complejidad de entendimiento de estos paradigmas, sumado a la poca información disponible de los plugins de Eclipse EMF y GMF me ha aportado una gran riqueza de conocimientos nuevos aprendidos. A pesar de que el camino ha sido costoso, en todo momento me he sentido motivado, con ganas de aprender y entender el objetivo y el método de aplicación de estos paradigmas y herramientas. Tras la realización del Proyecto se pueden sacar las siguientes conclusiones: La herramienta construida FPLA ha sido generada por las especificaciones que propone MDA y que los plugins EMF y GMF de Eclipse soportan. EMF y GMF son plugins muy útiles para la creación de lenguajes de modelado específicos de dominio. EMF y GMF nos permiten a partir de un metamodelo Ecore (subconjunto de UML) producir en muy poco tiempo un conjunto de clases Java y un conjunto de clases Adapter que permiten su visualización, tarea que tardaríamos horas en hacerlo. Pero se dispone de poca información sobre estos plugins. Empezar a utilizar estos plugins resulta costoso al principio, pero una vez que conoces la herramienta, la definición de lenguajes de modelado resulta muy cómoda y rápida. SPLE es un paradigma de desarrollo software fundamentado en la reutilización de software e inspirado en otros procesos de producción industriales existentes (aviones, coches, etc), en los que un alto 87

102 Capítulo 6. Conclusiones y Trabajos futuros porcentaje de los componentes utilizados son comunes. SPLE consiste en el desarrollo de una línea de producto software (SPL) para una familia de productos. La variabilidad es el elemento clave para definir una línea de productos satisfactoriamente. Esta variabilidad debe de quedar reflejada tanto a nivel de requisitos como a nivel de arquitectura de la PLA. Debido a que las SPL se diseñan para ser reconfiguradas en un futuro debido a posibles cambios en los requisitos que puedan afectar a los productos de la línea, la trazabilidad de la variabilidad entre ambas especificaciones (requisitos y arquitectura) es imprescindible para poder reaccionar ante futuros cambios, y que se sepa en todo momento, que componentes (elementos de la arquitectura) se ven implicados o afectados al efectuar un cambio en la SPL. Esta trazabilidad entre modelo de características y modelo de la PLA, se ha conseguido capturar y plasmar con nuestra herramienta FPLA, la cual además de esto nos permite implementar trazabilidad entre las diferentes vistas. MDD es un paradigma de desarrollo software cuya idea principal es elevar el nivel de reutilización y abstracción en el proceso de crear software, asumiendo la idea de que el proceso de creación de software debería ser dirigido por la formulación de modelos en vez de por la escritura manual de código. MDD nos permite construir modelos independientemente de la plataforma que se vaya a utilizar (PIM). Con MDD se reducen costes debido a la reutilización de los modelos que diseñemos, gracias a esta independencia de la tecnología. Sin embargo, el impacto que ha tenido MDD en la industria no ha sido especialmente relevante. Sólo las grandes empresas dedican un esfuerzo en investigación para aplicar este paradigma en sus procesos productivos. Aún así, la gran independencia de la plataforma que se consigue con MDD, su gran nivel de abstracción y reutilización que se consigue y su gran reducción de costes, no cierra la puerta a que el sector cambie de mentalidad, investigue y apueste por este paradigma. Según Paul Harmon (Consultor Senior de la compañía Americana de investigación en tecnología de la información Cutter Consortium ) MDA se incluirá dentro de los paquetes para el modelado Orientado a Objetos y herramientas de desarrollo, y es muy posible que el 88

103 Capítulo 6. Conclusiones y Trabajos futuros mercado de MDA crezca de forma rápida, gracias a todos los estándares que lleva detrás (UML, MOF, CWN, XML, etc.) [Harmon, 2003] TRABAJOS FUTUROS Este trabajo fin de carrera abre varías líneas de investigación relacionadas con el metamodelo de SPLs y el soporte que los modelos ofrecen tanto para el desarrollo como evolución de SPLs. En particular, la herramienta de modelado de trazabilidad podría completarse para soportar: Verificación entre el modelo de requisitos y el modelo de arquitectura. Analizar el impacto del cambio para soportar mantenimiento y evolución de SPLS. 89

104 90

105 Lista de acrónimos Lista de acrónimos: CASE CIM CM CMMI CMOF DSL DSLT DSM EMF EMOF FPLA GMF IEEE M2M M2T MDA MDD MOF OCL OMG PIM PLA PPC (Computer-Aided Software Engineering) (Computation Independent Model) (Code Model) (Capability Maturity Model Integration) (Complete MOF) (Domain Specific Language) (Domain Specific Languages Tools) (Domain Specific Model) (Eclipse Modeling Framework) (Essential MOF) (Flexible Product Line Architecture) (Graphical Modeling Framework) (Institute of Electrical and Electronics Engineers) (Model To Model) (Model To Text) (Model Driven Architecture) (Model Driven Development) (Meta Object Facility) (Object Constraint Language) (Object Management Group) (Platform Independent Model) (Product Line Architecture) (Plastic Partial Component) 91

106 Lista de acrónimos PSM QVT SEI SPL SPLE UML XML (Platform Specific Model) (Query Views Transformations) (Software Engineering Institute) (Software Product Line,) (Software Product Line Engineering) (Unified Modeling Language) (Metadata Interchange) 92

107 Anexo A: Manual de Usuario Anexo A: Manual de Usuario Vista la estructura con la que se presentan nuestros proyectos EMF y GMF en Eclipse, en los siguientes apartados se presentan los manuales de usuarios de las vistas incorporadas a FPLA (Feature Diagram y Traceability Diagram). Estos manuales guían al usuario paso a paso en el realización de un modelo en dichas vistas. La vista Feature Diagram permite definir modelos de características en SPLE. La vista Tracability Diagram permite definir trazabilidad entre modelos de características y modelos de PLA, en SPL. Vista modelo de características (Feature Diagram) El primer paso es arrancar la aplicación. Para ello, se debe seleccionar la carpeta FeatureTool.diagram, pulsar sobre ejecutar y seleccionar Run as Eclipse application. De esta forma aparecerá una nueva ventana de Eclipse (Figura A-1). Figura A-1. Ventana inicial de aplicación Eclipse. El siguiente paso es crear un nuevo proyecto java, haciendo click en: File New Project General Project. 93

108 Anexo A: Manual de Usuario Figura A-2. Selección del tipo de proyecto. Seguidamente se hace clic en Next, y se asigna un nombre al proyecto, por ejemplo Prueba1, y se pulsa Finish. Una vez hecho esto, se hace click con el botón derecho de ratón sobre Nuevo y se selecciona: New Example Feature Diagram. Ahora aparecerá una pantalla como la de la Figura A-2, en la que el usuario deberá escoger el tipo de elemento que desea añadir a su proyecto Prueba1. Se puede observar, que aparece cada una de las distintas vistas que integra FPLA, incluidas las vistas desarrolladas en el Trabajo Fin de Carrera. En este caso, se selecciona obviamente Feature Diagram, debido a que se desea modelar un modelo de característica de SPL. 94

109 Anexo A: Manual de Usuario Figura A-3. Selección del tipo de elemento a añadir al proyecto. Se hace click en Next, y se asignan los nombres que se deseen a los nuevos documentos, uno de ellos será el nombre que se le quiera dar al modelo de características y otro el fichero asociado con el lenguaje específico de dominio. Con esto, quedará arrancada la aplicación y se mostrará una pantalla como la de la Figura A-4, en la que se aparece un tapiz de modelado de fondo blanco que ocupa gran parte de la pantalla y en el que se representarán los lenguajes específicos de dominio o en este caso en particular en el dominio de las líneas de producto software (SPL). Por tanto, en este tapiz, se podrán representar diagramas de características que se utilizarán para definir la SPL. Debajo del tapiz, aparece una tabla de propiedades, que mostrará las propiedades del elemento del modelo representado en el tapiz, al seleccionarlo con el ratón. A la derecha del tapiz, aparece la paleta de herramientas (Figura A-8) con sus correspondientes iconos que instancian los diferentes tipos de elementos y relaciones entre ellos. Se debe señalar, que en estas propiedades, no se debe utilizar nunca los caracteres : o espacio en blanco, en las propiedades de ningún elemento, ya que el plugin GMF a la hora de transformar el modelo a código XML, el fichero XML generado queda 95

110 Anexo A: Manual de Usuario inconsistente, pudiendo generar errores inesperados en la herramienta. Tapiz Paleta Propiedades Figura A-4. Apariencia de la vista Feature Diagram. Figura A-5. Paleta de herramientas de la vista Feature Diagram. En la paleta se puede distinguir tres grupos o zonas: El grupo lps con 96

111 Anexo A: Manual de Usuario botones para crear los distintos tipos de características, el grupo Groups para crear grupos de características Ox y Xor, y el grupo Relationships para crear los enlaces entre las características. La herramienta Root Feature, permite crear la característica raíz del modelo, de la que colgaran el resto de características. La herramienta Solitary Feature permite crear características simples. Grouped Feature se utiliza para crear características agrupadas, es decir, las características que forman parte de un grupo de características. Or Group para crear a partir de una Solitary Feature o Grouped Feature, un grupo de características Or. Xor Group para crear a partir de una Solitary Feature o Grouped Feature, un grupo de características Xor. Mandatory Feature permite crear un enlace obligatorio entre dos Solitary Feature o entre una Root Feature y una Solitary Feature. Optional Feature idem que el anterior, exceptuando que define enlaces opcionales en vez de obligatorios. FeatureeGroup has Grouped Feature para crear los enlaces entre un grupo Or o Xor y las Grouped Feature que cuelgan de ellos. El modelado se realiza mediante drag and drop para cualquiera de las herramientas de la paleta, esto quiere decir que pulsando sobre una herramienta de creación, por ejemplo sobre Root Feature, y acto seguido se pulsa sobre el tapiz de modelado, se crea una nueva característica raíz (Figura A-6). Figura A-6. Modelado de una Root Feature. 97

112 Anexo A: Manual de Usuario Si lo que se desea ahora es definir un enlace obligatorio entre una SolitaryFeature y la RootFeature, perimero se debe de crear la SolitaryFeature y después, hacer click sobre la herramienta de creación de una MandatoryFeature en la paleta de herramientas y seguidamente pinchar sin soltar el botón pulsado del ratón, sobre el elemento origen del enlace (en este caso RootFeature), y arrastrar el cursor del ratón hasta el elemento destino del enlace (en este caso SolitaryFeature) (Figura A-7). Figura A-7. Modelado de una enlace MandatoryFeature. De forma similar a las representaciones anteriores, se representa una OptionalFeature. Se crea una SolitaryFeature y se une por ejemplo, con RootFeature, a través del enlace OptionalFeature. Los XorGroup y OrGroup, se definen dentro de una SolitaryFeature o GroupedFeature. Por tanto, para definir por ejemplo un XorGroup, se debe de hacer click sobre la herramienta de creación de una XorGroup en la paleta de herramientas y pulsar sobre la SolitaryFeature o GroupedFeature del modelo (Figura A-8). 98

113 Anexo A: Manual de Usuario Figura A-8. Modelado de un XorGroup. De forma similar a las representaciones anteriores, se representa un enlace FeatureGroup has GroupedFeature. Se crea en primer lugar un GroupedFeature, para enlazar el XorGroup con él, a través del enlace FeatureGroup has GroupedFeature (Figura A-9). Figura A-9. Modelado de un enlace FeatureGroup has GroupedFeature. 99

114 Anexo A: Manual de Usuario Vista modelo de trazabilidad (Traceability Diagram) Para crearnos una vista de trazabilidad, se hace click en New Example Traceability Diagram. Ahora aparecerá una pantalla como la de la Figura A-10, en la que el usuario deberá escoger el tipo de elemento que desea añadir a su proyecto Prueba1. Se puede observar, que aparece cada una de las distintas vistas que integra FPLA, incluidas las vistas desarrolladas en el Trabajo Fin de Carrera. En este caso, se selecciona obviamente Traceability Diagram, debido a que se desea modelar un modelo de trazabilidad. Figura A-10. Tipo de elemento a añadir al proyecto. Se hace click en Next, y se asigna el nombre que se le quiera dar al modelo de trazabilidad. Con esto, se muestra el tapiz en el que definiremos la trazabilidad y paleta de herramientas (Figura A-11) con sus correspondientes botones e iconos para instanciar los diferentes elementos y relaciones entre ellos. 100

115 Anexo A: Manual de Usuario Figura A-11. Paleta de herramientas de la vista Traceability Diagram. En la paleta de herramientas se puede distinguir dos grupos: El grupo traceability con botones que permiten configurar la trazabilidad, y el grupo links que permite enlazar elementos que forman parte del modelo de características o del modelo de la PLA. La herramienta SatisfactionLink, permite definir propiedades como el nombre, la versión, el peso, y el grado de satisfacción del elemento SatisfactionLink. Estas propiedades basadas en el trabajo de Hauser y Clausing (1988), proporcionan información sobre la trazabilidad entre el modelo de características y el modelo de la PLA, para instanciar el tipo del enlace de trazabilidad de satisfacción. LinkageRule se define dentro de un SatisfactionLink y define el tipo de regla de enlace que se va a definir. SourceLink permite unir un elemento del modelo de características (Solitary Feature, Grouped Feature, Or Group, Xor Group ) con el LinkageRule para que posteriormente se pueda establecer la trazabilidad entre éstos y los elementos del modelo de PLA. TargetLink permite unir un elemento de la PLA (Component, Plastic Partial Component, Connector, Optional Component, Optional Connector, AspectVP, FeatureVP, VariantAspect, VariantFeature) con un LinkageRule, para que posteriormente se pueda establecer la trazabilidad entre éstos y los elementos que forman parte del modelo de características. El modelado se realiza mediante drag and drop para cualquiera de las herramientas de la paleta, esto quiere decir que pulsando sobre una herramienta de creación, por ejemplo sobre SatisfactionLink, y acto seguido se 101

116 Anexo A: Manual de Usuario pulsa sobre el tapiz de modelado, se crea dicho elemento (Figura A-12). Cada SatisfactionLink, implementa un único enlace de trazabilidad. Figura A-12. Modelado de un SatistactionLink. Si lo que se desea ahora es definir la trazabilidad entre una característica de SPL y un componente del modelo de PLA, lo primero que se debe de hacer es definir un LinkageRule dentro del SatisfactionLink. Según el tipo de regla de enlace que se quiera definir, se deberá establecer los valores adecuados de las propiedades del LinkageRule. Una vez definido el tipo de enlace, se debe de enlazar el LinkageRule con un elemento del modelo de características por medio del enlace SourceLink (Figura A-13). Es en este punto, donde se ejecutan las restricciones OCL, que discriminarán según el tipo de regla que se haya definido en el LinkageRule, que tipos de enlaces de trazabilidad serán válidos y cuáles no (ver apartado 4.4.5). Para completar la trazabilidad, se debe de enlazar ahora el LinkageRule, con un elemento del modelo de PLA por medio del enlace TargetLink. En este punto, al igual que para el enlace SourceLink es donde se ejecutan las restricciones OCL. 102

117 Anexo A: Manual de Usuario Figura A-13. Modelado de trazabilidad. 103