Modelo de requisitos y modelo de dominio, trazabilidad mediante modelos de weaving

Transcripción

1 Modelo de requisitos y modelo de dominio, trazabilidad mediante modelos de weaving José Alfonso Aguilar-Calderón 1, Irene Garrigos 1, Jose Norberto Mazon 1 1 Grupo de Investigación Lucentia {ja.aguilar, igarrigos, jnmazon}@dlsi.ua.es Resumen. Las aproximaciones sistemáticas para el modelado, análisis y especificación de requisitos en ingeniería Web basadas en una arquitectura dirigida por modelos (Model-Driven Architecture, MDA) carecen de soporte para trazabilidad entre los modelos conceptuales, le dan poca relevancia, no la incluyen por completo o sus respectivas técnicas están pobremente aplicadas en el campo de la ingeniería Web. En este trabajo, se presenta una propuesta mediante el uso de los modelos de weaving para soportar la trazabilidad entre el modelo de requisitos y modelo de dominio, ambos, modelos conceptuales del método A-OOH (Adaptive-Object Oriented Hipermedia). 1 Introducción La ingeniería Web (WE) es una rama de la ingeniería de software (SE) que define técnicas, procesos y modelos para el ambiente Web. La ingeniería de requisitos (RE), por su parte, es la fase en que los requisitos pueden ser formulados como propiedades del problema que los stakeholders 1 quieren resolver por medio de su aplicación, sea en fase de desarrollo o como propiedades deseadas de la aplicación, es decir, se refiere a la etapa en el desarrollo de la aplicación en la cual los requisitos de los stakeholders son recolectados y procesados. En este sentido, un problema asociado con la RE es que los requisitos deben de ser consumados por completo, para lograrlo, es necesario que usuarios y stakeholders puedan observar que se han completado las transformaciones de los requisitos en el producto de trabajo final y distinguir cual de ellos pertenece a cierto requisito en particular, esto ayudará a determinar cuales de ellos serán impactados debido a la modificación de un producto de trabajo o viceversa. En este trabajo, definimos la trazabilidad de requisitos como la capacidad de describir y seguir la vida de un requisito, en ambas direcciones [1]: (i) determinar qué partes del modelo están relacionadas con cada uno de los requisitos, y (ii) determinar qué requisitos dieron origen a qué partes del modelo. Es importante destacar que el alcance de la práctica de la trazabilidad es considerada como una medida de la calidad del sistema y la madurez del proceso de desarrollo, además es una prescripción de muchas normas 1 Personas u organizaciones que afectan o son afectadas directa o indirectamente por el proyecto de forma positiva o negativa.

2 2 A. José Alfonso et al (estándares), tales como CMMI (Capability Maturity Model Integration), específicamente en el nivel 2, en el Área de Proceso de Gestión de Requisitos [2]. Por lo anterior, definir trazabilidad de requisitos es importante debido a que se debe hacer explícita la relación entre éstos y los demás modelos generados como resultado de transformaciones entre modelos a lo largo del ciclo de vida de desarrollo de software. De esta manera, se puede observar que se ha completado satisfactoriamente la transformación de los requisitos al código final y, además, ser capaces de distinguir qué parte del diseño proviene de qué requisito, lo que ayuda a determinar cómo se ve afectado un requisito cuando se modifique alguna parte del código o viceversa. Por tanto, una propuesta de desarrollo dirigido por modelos debe garantizar una trazabilidad entre el modelo de requisitos y los demás modelos implicados [3]. Sin embargo, en la ingeniería Web dirigida por modelos realizar el seguimiento de los requisitos durante la etapa de desarrollo hasta su implementación final no es una tarea fácil. Es conocido que a partir de un modelo de requisitos se obtienen diferentes modelos (de dominio, de navegación, etc.) que resultarán en la aplicación Web final, aún así, los modelos cambian en el tiempo debido al desarrollo gradual de las necesidades de los usuarios, por lo cual, la trazabilidad de requisitos resulta compleja, en este orden de ideas, se debe tener en cuenta (i) cada uno de los diferentes tipos de requisitos que conforman un modelo, sean estos funcionales o no-funcionales, y (ii) el impacto causado por cambios en los requisitos. Debido a que la trazabilidad es un factor muy importante para la ingeniería Web, como se ha motivado anteriormente, un problema común en los procesos de desarrollo Web dirigidos por modelos es que la mayoría de las aproximaciones carecen de soporte para trazabilidad y las que lo tienen, carecen de trazabilidad entre los modelos conceptuales derivados de la especificación de requisitos. Un estudio sobre esto se encuentra en nuestro trabajo previo en [4]. En este trabajo se pretende paliar esta deficiencia debido a la importancia de la trazabilidad para evaluar el impacto de los cambios potenciales en futuras etapas del proceso de desarrollo de aplicaciones Web [5]. Con el fin de aportar soluciones a esta problemática, se presenta una propuesta alineada con MDA para soportar la trazabilidad entre los modelos conceptuales en el marco del método de ingeniería Web A-OOH (Adaptive Object Oriented Hypermedia) [6] a partir de la especificación de requisitos Web, esto en un modelo de requisitos orientado a objetivos basado en i* [7]. La propuesta consiste en la obtención de un modelo de trazabilidad en paralelo a la obtención del modelo de dominio, ambos derivados del modelo de requisitos por medio de una serie de transformaciones. Esto permitirá obtener información relevante para la trazabilidad entre modelos, por ejemplo, saber que elementos del modelo de salida (modelo de dominio) son el resultado de que elementos del modelo de entrada (modelo de requisitos) y viceversa. El resto de este artículo esta estructurado de la siguiente manera: la sección 2 presenta las bases y los conceptos principales sobre los cuales se ha desarrollado esta propuesta. En la sección 3, es descrita la propuesta para soportar la trazabilidad entre los modelos conceptuales en marco del método A-OOH a partir de la especificación de requisitos. En la sección 4, es presentado un caso de estudio y por último, las conclusiones de este trabajo.

3 Modelos de weaving para trazabilidad en A-OOH 3 2 Background Esta sección presenta los fundamentos teóricos que dieron origen a esta propuesta. 2.1 Desarrollo dirigido por modelos El desarrollo dirigido por modelos (Model Driven Development, MDD) se ha convertido en una alternativa para resolver los problemas asociados con SE y WE de una manera sistemática, estructurada y completa. Fue presentado por el OMG (Object Management Group) para definir modelos que representen el sistema a desarrollar. Dentro de MDD, fue establecido MDA como arquitectura para el desarrollo de aplicaciones, la cual está formada por un conjunto específico de capas y transformaciones que proporcionan un marco conceptual en donde encontramos tres tipos de modelos, el primero de ellos es modelo independiente de la computación (Computational Independent Model, CIM), utilizado para la especificación de los requisitos de la aplicación a desarrollar, el segundo es el modelo independiente de la plataforma (Platform Independent Model, PIM), como su nombre lo indica, éste modelo se caracteriza por ser independiente de la plataforma de implementación de la aplicación, finalmente, el modelo específico de la plataforma (Platform Specific Model, PSM), el cual es obtenido del PIM y está formado por la información sobre una plataforma de desarrollo o alguna tecnología en especifico donde será implementada la aplicación final, esto es, el código fuente de la aplicación. La idea principal de esta arquitectura es que si el desarrollo del software es guiado por modelos que representen el producto final a desarrollar se podrán obtener beneficios en aspectos como funcionalidad, interoperabilidad y mantenimiento.[8] (Fig. 1). act Diagrama MDA CIM Transformación PIM Transformación PSM (JAVA) PSM (C#) PSM (PHP) Figura 1. Arquitectura MDA. 2.2 Modelos de weaving Un modelo de weaving es un tipo especial de modelo utilizado para establecer y manejar las relaciones (links) entre los elementos de los modelos, es decir para

4 4 A. José Alfonso et al representar la trazabilidad entre modelos. Está formado por una relación entre los elementos del modelo de entrada y del modelo de salida. En la figura 2, se puede observar un modelo de weaving que contiene dos relaciones, la primera relación está formada por el elemento E1 y el elemento S, la segunda relación por el elemento E2 y E3 con el elemento S2 del modelo de salida. Figura 2. Un modelo de weaving. El propósito del modelo de weaving es almacenar información sobre las operaciones realizadas en él, esto es, cuando un modelo se transforma en otro, la información relacionada permite saber qué elementos del modelo de entrada se utilizan para obtener los elementos del modelo de salida. Dicha información es de gran utilidad para analizar cómo los cambios en un modelo podrían afectar a otro modelo relacionado a él (análisis de impacto) [9]. 2.3 Estrategias para trazabilidad entre modelos Actualmente, existen dos estrategias para gestionar y almacenar la información para la trazabilidad entre modelos: (i) la información se puede integrar en los modelos a los que se refiere y (ii) la información de trazabilidad se puede almacenar por separado en otro modelo [10]. La primera de estas dos opciones tiene como desventaja que si la información es almacenada en el mismo modelo, el modelo será contaminado con información poco relevante para el contexto del modelo y por lo tanto, será difícil de mantener y utilizar. Por otro lado, la segunda estrategia consiste en almacenar la información en un modelo aparte, llamado modelo de trazabilidad. De esta forma se pueden corregir las desventajas mencionadas. Este trabajo consiste en aplicar la segunda estrategia mencionada anteriormente utilizando modelos de weaving. Para esto se presenta el metamodelo base para weaving [11] y una extensión para proveer a dicho metamodelo con elementos útiles para representar la trazabilidad entre modelos [12]. El metamodelo se presenta en la figura 3:

5 Modelos de weaving para trazabilidad en A-OOH 5 WElement. Es el elemento base del cual los seis elementos restantes heredan, esta formado por los atributos nombre y descripción. WModel. Representa el elemento raíz que contiene a todos los elementos del modelo. Está compuesto por las referencias y relaciones a los modelos de entrada y salida. WLink. Sirve para representar un enlace entre los elementos del modelo. WLinkEnd. Este elemento representa el extremo final de un enlace. WElementRef. Este elemento se asocia a una función de identificación, creando un identificador único para cada elemento del modelo ligado, por tanto WElementRef permite referenciar el mismo elemento del modelo enlazados por diversos elementos WLinkEnd. WModelRef. Representa un identificador único de un modelo. En la parte inferior de la figura 3, se ilustra la extensión del metamodelo para weaving que permite la representación de la trazabilidad. Esta extensión la forman los siguientes elementos: TraceModel. Es el elemento que representa al modelo de trazabilidad, esta integrado por referencias a otros modelos. TraceModelRef. Representa la referencia a otros modelos, es decir, es un único identificador para los modelos que conforman el modelo de trazabilidad. ElementRef. Es un identificador para señalar cada elemento que integran los modelos ligados. TraceLink. Un enlace de rastreo, utilizado para representar las correspondencias entre las referencias de los elementos de los modelos enlazados. Como información de trazabilidad, almacena el nombre de la regla de transformación que ha sido ejecutada. Figura 3. Metamodelo para modelos de weaving.

6 6 A. José Alfonso et al TraceLinkEnd. Su función es similar al elemento WLinkEnd del cual hereda, pues permite crear una relación uno a muchos (1 *) entre las referencias de los elementos del modelo de entrada (sourceelements) y los del modelo de salida (targetelement). En la sección siguiente se describe nuestra propuesta para resolver el problema de trazabilidad de requisitos en el dominio de la MDWE mediante el uso de A-OOH. 3 Modelos de weaving para trazabilidad en A-OOH En esta sección, se presenta una propuesta para utilizar modelos de weaving en A- OOH con el fin de soportar trazabilidad en los modelos conceptuales de dominio y de navegación dentro de un marco MDA, lo anterior utilizando la taxonomía de requisitos Web presentada en [13]. La figura 4, muestra una visión general de nuestra propuesta. Se utilizan tres metamodelos diferentes para la obtención de los modelos conceptuales a partir del modelo de requisitos, estos son (i) extensión del metamodelo de UML, por medio de la definición de un perfil UML para la especificación de requisitos en Web en un CIM mediante el uso de i*, (ii) metamodelos utilizados en la definición del modelo de dominio en varios PIMs, y (iii) metamodelo de weaving propuesto en [12], para su uso en la trazabilidad entre nuestros CIM y PIM. Figura 4. Modelo de trazabilidad en la derivación de modelos conceptuales a partir del modelo de requisitos en A-OOH. Tal y como se puede observar en la figura 4, a partir de un modelo de requisitos conforme al metamodelo i* para Web (modelo de entrada) se obtienen dos modelos mediante transformaciones QVT. El primero se denomina modelo de salida, y corresponde al modelo de dominio. El segundo modelo será el modelo de weaving que asegure la trazabilidad entre modelo de entrada y modelo de salida.

7 Modelos de weaving para trazabilidad en A-OOH 7 El modelo de requisitos, se define en un CIM utilizando nuestra propuesta [7] para usar el marco de modelado de requisitos i*. Este marco de modelado [14] es uno de los más usados para analizar los objetivos de los actores y cómo el sistema a diseñar debería satisfacerlos. Una vez se define el modelo de requisitos (veremos un ejemplo en la sección siguiente), se deben definir el resto de los modelos conceptuales, explicados a continuación. Para definir una aplicación Web debemos definir tres modelos conceptuales: un modelo de dominio, en el cual se define la estructura de los datos de dominio, un modelo de navegación, en el cual se define la estructura y el comportamiento de la vista de navegación sobre los datos de dominio, y finalmente un modelo de presentación, en el cual se define la presentación de la aplicación. En este trabajo nos centramos en la trazabilidad de requisitos para el modelo de dominio. El modelo de dominio de A-OOH se expresa como un diagrama de clases UML. Este modelo refleja la parte estática del sistema Web, encapsulando su estructura y funcionalidad requerida (una definición más detallada, así como los metamodelos y perfiles UML asociados puede consultarse en [6]). Se pretende obtener el modelo de dominio a partir de los modelos de requisitos en i* tras la aplicación de un conjunto de reglas de transformación en QVT. Con estas reglas, obtendremos también un modelo de weaving, el cual mantendrá la trazabilidad bidireccional entre ambos modelos (a nivel de sus respectivos elementos). Las principales reglas QVT para generar el modelo de dominio y el modelo de trazabilidad desde el modelo de requisitos son las siguientes: Content2DomainClass. El dominio origen de esta relación está compuesto por un conjunto de elementos que representan una clase estereotipada como Content. Cuando se detecta este patrón en el modelo de entrada se fuerza la creación de una clase tipo Class en el modelo destino (modelo de dominio). Por tanto, por cada requisito de contenido se obtiene una clase en el modelo de dominio. Service2Operation. Esta relación detecta un conjunto de elementos en el modelo de entrada (modelo de requisitos) que corresponden con una clase estereotipada como Service asociada a una clase estereotipada como Content. Una vez detectado este patrón de elementos, se crea en el modelo de salida (modelo de dominio) una clase Operation en la clase del modelo de dominio correspondiente. Navigation2Relationship. Esta relación permite crear asociaciones entre clases en el modelo de dominio. Existen dos clases como origen para detectar clases estereotipadas como Content. Si estas dos clases se usan para cumplir el mismo requisito de navegación, entonces se crea una clase Association entre las clases del modelo de dominio que las representan (figura 5). Figura 5. Relación QVT para obtener las asociaciones entre las clases del modelo de dominio.

8 8 A. José Alfonso et al Además de las transformaciones anteriores, se ha creado una transformación con reglas adicionales para crear los elementos del modelo de trazabilidad: CreateModelTrace. Al ejecutarse por primera vez, esta regla crea un modelo de trazabilidad. Este modelo representa al modelo de entrada y al modelo de salida. Cada vez que una regla QVT empareja un elemento del modelo de entrada (modelo de requisitos) crea un nuevo TraceLink en el modelo de trazabilidad, este link representa los elementos del modelo de entrada y del modelo de salida por medio de referencias a sus respectivos elementos. En la sección siguiente es explicado un ejemplo paso a paso de la aplicación de esta propuesta. 5 Prototipo de aplicación En este apartado es presentado un ejemplo de la propuesta explicada en la sección anterior, el ejemplo está basado en una compañía que se dedica a la venta de libros en-línea. En este caso de estudio, la compañía quiere administrar la venta de libros por medio de una tienda en línea, de esta forma atraer la mayor cantidad de clientes como sea posible. También dispondrá de un administrador Web para gestionar a los clientes. 5.1 Especificación de requisitos En primera instancia tenemos especificado el modelo de requisitos en i*, tal y como se muestra en la figura 6 (por cuestiones de espacio sólo se muestra la parte del modelo de requisitos relevante a este trabajo). Figura 6. Modelo de requisitos de la tienda de libros en línea, especificado en i*. A continuación, este modelo de entrada se representa en el contexto del metamodelo de weaving. En la figura 7, podemos observar que cada elemento del modelo de entrada esta formado por dos etiquetas, una se utiliza para almacenar el nombre del elemento y la otra para contener su descripción (la cual es opcional).

9 Modelos de weaving para trazabilidad en A-OOH 9 Figura 7. Una parte del modelo de requisitos en el contexto de los modelos de weaving. 5.2 Obtención del modelo de dominio. El paso siguiente consiste en aplicar las reglas de transformación QVT. Al aplicar las reglas, se considera que para cada requisito de contenido etiquetado como Content en el CIM (modelo de entrada), la regla de transformación Content2DomainClass crea una nueva clase en el PIM (modelo de salida de dominio). En este caso, han sido detectados tres requisitos de contenido en el CIM, estos son: Categoría, Autor y Libro. Por lo tanto se crean tres clases en el modelo de dominio. El siguiente paso es la ejecución de la regla Service2Operation. Para nuestro ejemplo, se aplica la regla en dos ocasiones, creándose dos operaciones en la clase Libro del modelo de salida de dominio: Met_BuscarLibroPorISBN() y Met_BuscarLibroPorAutor(). Finalmente, se ejecuta la regla Navigational2Relationship, la cual se encarga de crear asociaciones entre las clases del modelo de dominio. El modelo de dominio resultante se muestra en la figura 8. Figura 8. Modelo de dominio obtenido. 5.3 Obtención del modelo de trazabilidad. El modelo de trazabilidad se obtiene en paralelo a la obtención del modelo de dominio: se crea el modelo de trazabilidad mediante la representación del modelo de

10 10 A. José Alfonso et al entrada y del modelo de salida así como de las referencias a los elementos de ambos modelos. Después, cada vez que una regla se ejecuta, emparejando un elemento del modelo de entrada, por ejemplo el elemento Libro, se crea una referencia a dicho elemento y al que será su elemento equivalente en el modelo de salida (Clase Libro del modelo de dominio). Es decir, en el contexto de los modelos de weaving, crea un nuevo TraceLink (ver figura 9) en el modelo de trazabilidad. Este paso se repite hasta haber emparejado cada uno de los elementos del modelo de entrada. La figura 9 muestra el modelo de trazabilidad obtenido tras la generación del modelo de dominio. La figura está dividida en tres partes, la primera (parte izquierda) representa las referencias al modelo de entrada, es decir, al modelo de requisitos, la segunda parte (centro de la figura) está formado por los TraceLinks, los cuales contienen el nombre de la regla que se ejecutó para obtener el elemento correspondiente en el modelo de salida. Finalmente, la tercera parte (lado derecho de la figura 9) corresponde al modelo de salida obtenido, que de forma similar al modelo de entrada está formado por referencias a los elementos reales del modelo de salida. En este contexto, la referencia sourceelements se refiere a los elementos del modelo de entrada, por ejemplo, el elemento BuscarLibroPorISBN etiquetado como Service, como podemos ver en la parte izquierda de la figura 9. La referencia targetelements se refiere a los elementos del modelo de salida generados, en este caso la Clase Libro, método BuscarLibroPorISBN() del modelo de dominio, representado al lado derecho de la figura 9. El atributo rulename contiene el nombre de la regla (Content2DomainClass, descrita anteriormente) que es ejecutada en el Motor de Transformaciones QVT. Este atributo, permite mantener un seguimiento a la regla de transformación que originó el(los) elemento(s) del modelo de salida y no solamente de los elementos del modelo de entrada. Por su parte, la clase TraceLinkEnd representa los elementos de entrada y salida, es decir, los puntos finales de las correspondencias entre los elementos de ambos modelos. La referencia elemento (del core Weaving Metamodel) se refiere a la clase ElementRef. Este elemento es una representación a los verdaderos elementos vinculados, es decir, guarda un identificador que permite la identificación únicamente de los elementos del modelo de entrada o salida.

11 Modelos de weaving para trazabilidad en A-OOH 11 Figura 9. Modelo weaving para la trazabilidad del modelo de dominio. 6 Conclusiones Se ha presentado una propuesta teórica para obtener trazabilidad entre el modelo de requisitos y el modelo de dominio en marco del método de desarrollo Web A-OOH. En concreto, nuestra propuesta ofrece una solución a la (i) carencia de aproximaciones metodológicas que cubran la construcción de modelos de diseño mediante la especificación de requisitos considerando las metas y necesidades de los actores del sistema (por medio del perfil UML para aplicar i* en Web), (ii) trazabilidad entre modelos conceptuales (mediante la aplicación de modelos de weaving), y (iii) carencia en herramientas de soporte (con nuestra propuesta constituida en la plataforma Eclipse). Es importante mencionar que ésta propuesta podría aplicarse en el contexto de otra metodología Web a pesar de que se ha utilizado A-OOH como método de modelado. Actualmente, se está trabajando en complementar la propuesta presentada con la adición de la derivación de los modelos conceptuales de navegación, personalización y de usuario en A-OOH. Finalmente, también se está implementando la propuesta con la plataforma de desarrollo Eclipse, mediante el desarrollo de plugins con los perfiles de UML y metamodelos necesarios para el modelado del CIM y el PIM, así como el conjunto de transformaciones QVT y los modelos de weaving. La validación formal de esta propuesta teórica deja en claro que es factible la aplicación de la misma a los modelos A-OOH y de esta forma lograr que esta aproximación satisfaga la carencia de trazabilidad como primer paso ante las carencias detectadas en las aproximaciones metodológicas en marco del desarrollo Web dirigido por modelos (consultar [4]).

12 12 A. José Alfonso et al Agradecimientos Este trabajo es apoyado por los siguientes proyectos: ESPIA (TIN ) del Ministerio de Educación y Ciencia de España y QUASIMODO (PAC ) del Ministerio Regional de Educación y Ciencia de Castilla-La Mancha. José Alfonso Aguilar Calderón es subvencionado por el Programa de Formación de Recursos Humanos en Áreas Estratégicas de la Universidad Autónoma de Sinaloa, México y el Concejo Nacional de Ciencia y Tecnología, México (CONACYT). Referencias 1. O.C. Gotel,C.W. Finkelstein. An analysis of the requirements traceability problem. in Proceedings of the First International Conference on Requirements Engineering J. Nicolás,A. Toval, On the generation of requirements specifications from software engineering models: A systematic literature review. Information and Software Technologies, (9): p N. Aizenbud-Reshef, et al., Model traceability. IBM Systems Journal, (3): p J.A. Aguilar, I. Garrigos, J.-N. Mazon, Web Engineering Approaches For Requirement Analysis - A Systematic Literature Review, in 6th Web Information Systems and Technologies (WEBIST). 2010, Proceedings of the 6th Web Information Systems and Technologies (WEBIST): Valencia, Spain. p P. Valderas,V. Pelechano, Introducing requirements traceability support in modeldriven development of web applications. Information and Software Technologies, (4): p I. Garrigós, A-OOH: Extending Web Application Design with Dynamic Personalization, in Dept. Software and Computing Systems. 2008, University of Alicante. 7. I. Garrigós, J.-N. Mazón, J. Trujillo, A Requirement Analysis Approach for Using i* in Web Engineering, in 9th International Conference on Web Engineering. 2009, Springer-Verlag: San Sebastian, Spain. p A. Brown, Model driven architecture: Principles and practice. Software and Systems Modeling, (4): p K. Czarnecki,S. Helsen. Classification of model transformation approaches. 2003: Citeseer. 10. N. Drivalos, et al. Towards rigorously defined model-to-model traceability. in Proc. 4th Workshop on Traceability, ECMDA Berlin, Germany. 11. M. Del Fabro, J. Bézivin, P. Valduriez. Weaving Models with the Eclipse AMW plugin. in Eclipse Modeling Symposium, Eclipse Summit Europe Esslingen, Germany: Citeseer. 12. M. Barbero, M. Del Fabro, J. Bézivin. Traceability and provenance issues in global model management. in 3rd Proceedings of the European Conference on MDA Traceability Workshop Haifa, Israel Citeseer. 13. M. Escalona,N. Koch, Requirements engineering for Web Applications: a comparative study. Journal of Web Engineering, : p E. Yu. Towards modelling and reasoning support for early-phaserequirements engineering. in Requirements Engineering