See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/236735489

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

weaving

Conference Paper · September 2010

CITATION READS

1 1,678

3 authors:

José Alfonso Aguilar Irene Garrigós

Universidad Autónoma de Sinaloa University of Alicante
47 PUBLICATIONS   345 CITATIONS    97 PUBLICATIONS   833 CITATIONS   

SEE PROFILE SEE PROFILE

Jose-Norberto Mazón
University of Alicante
145 PUBLICATIONS   2,181 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Agile Software Development- A Way to Produce Successful Software Product View project

BPMN4ETL project View project

All content following this page was uploaded by José Alfonso Aguilar on 31 May 2014.

The user has requested enhancement of the downloaded file.

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

José Alfonso Aguilar-Calderón1, Irene Garrigos1, Jose Norberto Mazon1

1
Grupo de Investigación Lucentia
{ja.aguilar, igarrigos, jnmazon}@dlsi.ua.es
http://www.lucentia.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 stakeholders1 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 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.
 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 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:
 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 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.
 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 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).
 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 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.
 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 A. José Alfonso et al

Agradecimientos

Este trabajo es apoyado por los siguientes proyectos: ESPIA (TIN2007-67078) del
Ministerio de Educación y Ciencia de España y QUASIMODO (PAC08-0157-0668)
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.
1994.
2. J. Nicolás,A. Toval, On the generation of requirements specifications from software
engineering models: A systematic literature review. Information and Software
Technologies, 2009. 51(9): p. 1291-1307.
3. N. Aizenbud-Reshef, et al., Model traceability. IBM Systems Journal, 2006. 45(3): p.
515-526.
4. 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. 187-190.
5. P. Valderas,V. Pelechano, Introducing requirements traceability support in model-
driven development of web applications. Information and Software Technologies,
2009. 51(4): p. 749-768.
6. 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. 151-165.
8. A. Brown, Model driven architecture: Principles and practice. Software and
Systems Modeling, 2004. 3(4): p. 314-327.
9. 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’08. 2008. 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. 2006. 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. 2007. Haifa, Israel Citeseer.
13. M. Escalona,N. Koch, Requirements engineering for Web Applications: a
comparative study. Journal of Web Engineering, 2004. 2: p. 193-212.
14. E. Yu. Towards modelling and reasoning support for early-phaserequirements
engineering. in Requirements Engineering. 1997.

View publication stats