Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 2, 2010

Transcripción

1 Adaptation of transformations to metamodel changes Jokin Garcia, Oscar Díaz Universidad del País Vasco San Sebastián {jokin.garcia, Abstract MDE is becoming mainstream. This implies facing scalability and complexity problems: larger meta-models and more intricate transformations. Additionally, metamodel evolution introduces even more stringent demands. Model transformation needs then to face an increase in both complexity and evolvability. Specically, assistance is required to guide how metamodel changes impact associated transformations. This paper focuses on changes in the source metamodel, and the impact on the associated transformations. Automatic propagations from metamodel changes to their transformation counterparts are seldom possible. However, some annotations can be added to provide a rst assistance to the designer. An annotated transformation is a transformation that includes suggestions about how changes have impacted the rule. The annotations are provided just as a guidance, leaving to the designer the nal acceptance. The annotator is realized as a set of HOT transformations: the input is a dierence model recording the metamodel evolution and the transformation while the output is a coevolved model transformation. The approach is illustrated with a sample problem. 1 Introduction Metamodels stay at the very heart of modeldriven engineering (MDE). This key role makes MDE processes be specially sensitive to metamodel evolution. Metamodel changes impact not only on its compliant models but also model transformations can be badly aected. Compared to metamodel instances, transformations are not so numerous but tend to be much more complex. This vindicates the need for some automatic assistance that guides the designer in co-evolving the aected transformations. This paper introduces some preliminary ideas about the automatic generation of transformation rules as aected by changes in the metamodel. A set of rule skeletons is generated where annotations are used to indicate which and how transformation rules are impacted. Hence, these rule skeletons are reckoned to help the designer to percolate the metamodel changes down to the corresponding transformation rules. Implementation wise, and along the lines of the approach presented in [3], higher-order model transformations are used. In Section 2 some background on model transformations is introduced, based on works which have categorized transformations from dierent point of views. Then, in Section 3, we realize that the recursive use of transformations can be benecial for some quality criteria, as adaptability or reusability. In Section 4 we explain a semiautomatic approach to adapt transformations to metamodel changes as a way to minimize metamodel coupling in transformations and an example transformation that is used later in Section 5 to illustrate some scenarios. 1 ISSN SISTEDES

2 2 Background 2.1 Metamodel evolution There is literature about metamodel evolution and how does it aect to other artifacts, mostly models. In [11], Wachsmuth exposes reasons of metamodel evolution: During design, alternative metamodel versions are developed and well-known solutions are customised for new applications. During implementation, metamodels are adapted to a concrete metamodel formalism supported by a tool. During maintenance, errors in a metamodel are corrected. Furthermore, parts of the metamodel are redesigned due to a better understanding or to facilitate reuse. Depending on the change type, the eect on other artifacts will be dierent. Changes in a metamodel can be [10]: generalize metaproperty (its multiplicity or type are relaxed), extract superclass (a superclass is extracted and a set of properties is pulled on), pull metaproperty (a metaproperty is pulled in a superclass and the old one is removed from a subclass), push metaproperty (it is deleted from a superclass and cloned in all the subclasses), atten hierarchy (eliminate a superclass and introduce all its properties into the subclasses), restrict metaproperty (its multiplicity or type are enforced), rename metaelement, eliminate metaclass, eliminate metaproperty, add metaclass, add metaproperty, move metaproperty, extract metaclass (create a new class and move the elds from the old class into the new one) and inline metaclass (move all its features into another class and delete the former). 2.2 Transformations We understand model transformation as a program that takes an input model and produces an output model, both models conforming to a metamodel. Some categorizations can be done depending on the relation between source and target metamodels [9], the linguistic perspective [6] or the approach used to specify the transformation [5]. In the example shown here we use ATL 1 as a model transforma- 1 tion language. It is a hybrid approach language, with both declarative and imperative constructs. On the other hand, the example is a structure transformation (or Model to Model -M2M- transformation in MDA terms), which maps an abstract syntax graph into another abstract syntax graph. 2.3 Role of Higher Order Transformations in quality improvement Higher Order Transformations (HOT ) are a kind of transformations that have another transformation model as input and/or output. In the classication made by Tisi et. al. [10] they describe as Transformation modication the pattern for HOTs that takes a transformation as input and generate a modied version of the same transformation. This is interesting as reusability technique if a similar transformation is needed: if a transformation wants to be developed but starting from another one because it is similar and we do not want to start from scratch, it can be modied with a transformation to adapt it. Moreover, it is generic because it is applicable to every transformation. To achieve this manipulation, the input or output transformation in a HOT must have been done in a transformation language which has a metamodel, and the HOT itself can be done with any transformation language. In ATL the transformations are represented by a transformation model conforming the transformation metamodel. This is probably the reason why most of the developers use ATL for HOTs. Bezivin et. al. in [2] highlight the importance of a descriptive point of view of transformation models, as well as the current executable descriptions. We have considered HOTs to improve adaptability in transformations, but there are many other applications concerning quality, such as refactoring or optimization. To understand how a HOT works, we must be familiarized with the metamodels of the input transformations. ATL metamodel s most important structures are shown in Figure 1 (taken from [10]), dispensing with OCL elements (ATL is heavily based on OCL). Unit is the root element, which can be a Module, ISSN SISTEDES

3 a Library or a Query. A Module is composed of ModuleElements, which are either Helpers (helpers are modules similar to Java methods, that make it possible to dene factorized ATL code that can be called from dierent points of a transformation) or Rules. Rules are abstract entities which concrete classes can be MatchedRules or CalledRules. A Rule is composed of InPattern and OutPattern, which are the left and the right part of the rule respectively. OutPattern is composed of OutPatternElements, one for each target class the source metamodel is mapped to. And OutPatternElement contains Bindings, which associate a value with a model element property. This value is encoded by an OCL expression. 3 Transformation co-evolution 3.1 Co-evolution process According to ISO [1], Adaptability characterizes the ability of the system to change to new specications or operating environments. Transformations can be aected by multiple type of changes: ˆ a change in the transformation logic: changes in the requirements (functional or not functional) can introduce or change some logic independent of the metamodels: Changes in the code: For instance, to improve the code we would like to introduce trace information [8]. Conditions in the mappings: Some lters can be added, removed or changed to apply a mapping under new conditions. 2 Changes in the mapping logic: domain-specic mapping decisions. ˆ a change in the metamodels (metamodel evolution). Cicchetti et. al. [3] did a classication of metamodel changes to study semi-automatic co-evolution of models. We use the same idea to study the impact 2 of changes on transformations, as shown in the table. Non-breaking changes means that transformations are not aected by those metamodel changes, breaking and resolvable changes means that transformations can be automatically adapted to metamodel changes and breaking and unresolvable changes means that human intervention is required to adapt the transformation. There are simple and complex changes: the later are composed by several simple changes. We have implemented a semi-automatic adaptation of transformations using a di-approach: we can use EMF Compare 3 or similar tools to retrieve the dierences between old and new versions of the metamodels and a HOT to adapt the transformation to the changes. As it can be seen in Figure 2, there can be changes in the source or target metamodel. We consider that changes in the source and in the target are not done simultaneously, because race conditions can happen in the adaptation. For instance, if we do a mapping to a metaclass or metaproperty of the target metamodel that will be later removed. Due to space restrictions, only changes in the source metamodel will be considered. EMF Compare is used to retrieve the dierences in a.emfdi le, which is a model conforming Di.ecore metamodel for dierences. This is one input of the HOT, and the other input is the initial transformation injected as a model (using AM3's injector to translate textual representation of the transformation to model representation). Then, we have to use a HOT that adapts the transformation to the changes, and after that, the adapted model is extracted to a.atl le (using AM3's extractor to serialize the transformation model into a textual transformation). This co-evolution process must be seen only as a help for the transformation designer, as there are intrinsic limitations in transformation adaptations, as it is a domain-specic task. Due to these 3 ISSN SISTEDES

4 Change type Classication Change Adaptation actions Non-breaking changes Breaking and resolvable changes Breaking and unresolvable changes Additive Additive Additive Subtractive Subtractive Subtractive Updative Subtractive Subtractive Generalize metaproperty Extract superclass Pull metaproperty Push metaproperty Flatten hierarchy Restrict metaproperty Rename metaelement Eliminate metaclass Eliminate metaproperty None None None None None Source MM: None. Target MM: A new rule could be necessary. Synchronize with the new value. Source MM: delete rules whose source is the deleted class, delete source conditions which contain data from the deleted class and delete target bindings which contain data from the deleted class. Target MM:delete outpatternelements whose target is the deleted class and delete target bindings which contain data from the deleted class. Source MM: delete source conditions which contain data from the deleted property and delete target bindings which contain data from the deleted property. Target MM: delete target bindings which contain data from the deleted property. Additive Add metaclass Source MM: One or more new rules, new condition in the source, new binding in the target and/or new binding fragment (it is code added to an existing binding and it is explained in [7]). Target MM: new outpatternelement, new bindings and/or new binding fragments. Additive Add metaproperty New condition in the source, new binding in the target and/or new binding fragment. Updative Move Eliminate metaproperty + add metaproperty cases metaproperty Updative Extract Add metaclass + Move metaproperty cases metaclass Updative Inline metaclass Move metaproperty + eliminate metaclass cases Table 1: Metamodel changes classication ISSN SISTEDES

5 Figure 1: Simplied ATL metamodel limitations, in the addition cases only a skeleton can be generated in most cases, leaving the implementation logic to the developer. And in the case of removal, we can synchronize automatically the transformation but not guarantee its semantic correction. On the other hand, in the case of update, where the changes are only in the nomenclature and are not structural, it is automatic. Possible impacts on transformations caused by a change in the requirements are shown in the table. 3.2 Example In this Section we present a source metamodel called Exam and a target metamodel called MVC (in Figure 3), based on [4]. The Exam metamodel describes exams and exam questions. An exam (Exam) is composed of one or more exam questions: open (OpenElement) and multiple choice (MultipleChoiceElement). On the other hand, MVC metamodel represents a Model- View-Controller architecture where three abstract metaclasses: ExamItem, View and Controller correspond to model, view and controller respectively. The following is the transformation between the metamodels we take as a base. module exam2mvc; create OUT : AssistantMVC from IN : ExamXML; rule Exams { from vexam : ExamXML!Exam to mvc : AssistantMVC!Exam ( examitems <- vexam.elements ) } rule OpenQuestion { from vexam : ExamXML!OpenElement to vopencontroller : AssistantMVC!OpenController(), vopenview : AssistantMVC!OpenView( controller <- vopencontroller, fontname <- 'Times', fontcolor <- 'Red' ), vopen : AssistantMVC!Open ( question <- vexam.question, observers <- vopenview ) } rule MultipleChoice { ISSN SISTEDES

6 Figure 2: Transformation co-evolution process Figure 3: Exam and MVC metamodels ISSN SISTEDES

7 from vmce : ExamXML!MultipleChoiceElement to vmcc : AssistantMVC! MultipleChoiceController(), vmcview : AssistantMVC!MultipleChoiceView( controller <- vmcc, fontname <- 'Times', fontcolor <- 'Red' ), vmc : AssistantMVC!MultipleChoice ( question <- vmce.question, observers <- vmcview ) } 3.3 Adaptation scenarios Based on the table, some examples of additive, updative and subtractive transformation adaptations are described for changes produced in the source metamodel. It must be commented that when we talk about metaproperties, both references and attributes are considered, as they are treated in the same way in transformations (EMFCompare does not tell the dierence between them either). ˆ In the cases where we move metaproperties from/to super/subclasses, no actions are needed because when we refer to a metaproperty in a rule, the transformation engine takes care about reaching it in the class or superclasses. This are the cases of the table: generalize metaproperty, extract superclass, pull metaproperty, push metaproperty and atten hierarchy. ˆ Add metaclass. We will show the specic case where the metaclass is a subclass: If we add a subclass ExerciseElement to ExamElement the output will be: --NEW RULE rule ExerciseElement { from vexerciseelement : ExamXML!ExerciseElement to vexercisecontroller : AssistantMVC!ExerciseController(), vexerciseview : AssistantMVC!ExerciseView ( controller <- vexercisecontroller, fontname <- 'tobedefinedfontname', fontcolor <- 'tobedefinedfontcolor' ), vexercise : AssistantMVC!Exercise ( question <- vexerciseelement.question, observers <- vexerciseview) } When adding a new metaclass, a rule can be partially generated: the left part of the rule is generated, leaving the implementation of the right part to the designer. If the added metaclass is a subclass, we can use as an heuristic the pattern in the mapping of sibling elements to help generating the right part of the rule. In this case, as the new subclass have siblings (OpenElement and MultipleChoiceElement) which rules are dened we could use the same pattern, as can be seen in the code above. When a constant is assigned, the HOT Assistant creates a constant by concatenating 'tobedened' + 'nameofthereceptionproperty'. In this case, new elements in the target are needed, so the designer should decide whether to modify or not the target metamodel. Sometimes the rule will not be necessary, since the target does not need that information, it is retrieved with a helper for another rule or that information is scattered through many bindings as in [7]. It will always be the decision of the designer to keep the generated rule or not. ˆ Add metaproperty: If we add mark metaproperty to the ExamElement metaclass, the output will be: rule OpenQuestion { from vopenelement : ExamXML!OpenElement ISSN SISTEDES

8 to vopencontroller : AssistantMVC!OpenController, vopenview : AssistantMVC!OpenView ( controller <- vopencontroller, fontname <- 'Times', fontcolor <- 'Red' ), vopen : AssistantMVC!Open ( question <- vopenelement.question, ) } observers <- vopenview, tobedecidedmarktarget <- mark rule MultipleChoice { from vmce : ExamXML!MultipleChoiceElement to vmcc : AssistantMVC!MultipleChoiceController, vmcview : AssistantMVC!MultipleChoiceView ( ( ) } controller <- vmcc, fontname <- 'Times', fontcolor <- 'Red' ), vmc : AssistantMVC!MultipleChoice question <- vmce.question, observers <- vmcview, tobedecidedmarktarget <- mark When adding a new metaproperty, we do not know the target metaclass and metaproperty it has to be mapped to. As an heuristic to complete our lack of information, we should check if there is another metaproperty in the metaclass we have added our metaproperty to, and use the same metaclass it is mapped to. However, as we do not know the target metaproperty, the HOT Assistant will write 'tobedecided' + 'MetapropertyTarget'. ˆ Update metaclass/metaproperty: If the name of MultipleChoiceElement class is changed to MCElement the output will be: rule MultipleChoice { from vmcelement : ExamXML!MCElement... This is a straightforward case since more information is not needed. Update metaproperty case is analogous. ˆ Eliminate metaclass: If OpenElement is deleted from the source, the rule Open- Question will be deleted and a comment will be shown: -- Deleted OpenQuestion rule We must be careful with deletion, because the deletion of the rule does not guarantee correction, as the metaclass in the target metamodel which was mapped to the deleted source metaclass continues existing. Instances of it will not be generated, so in the hypothetical case (does not happen in this example) it has a relation with cardinality bigger than 0 and there is not another rule generating elements of its type, the model will not be valid (gure 4). To avoid this situation a message will advise the designer to modify the target metamodel or the transformation: -- Target model can be invalid as elements of type C are not -- generated. Figure 4: Delete metaclass ISSN SISTEDES

9 4 Conclusions and future work The presented semi-automatic approach helps the transformation designer to adapt the transformation to metamodel changes proposing him an annotated transformation. This proposed transformation can have dierent degrees of automation, depending on the intrinsic diculty of the changes and the semantic gap s size between metamodels. As future work, the aim would be to rene the annotated transformation using heuristics to reach the higher level of automation. Acknowledgments We would like to thank Maider Azanza and the reviewers for their help and comments. This work has been partially supported by a Basque Government grant. References [1] Iso 9126: [2] Jean Bézivin, Fabian Büttner, Martin Gogolla, Frédéric Jouault, Ivan Kurtev, and Arne Lindow. Model transformations? transformation models! In MoD- ELS, pages Model Driven Engineering Languages and Systems, 9th International Conference, MoDELS 2006, Genova, Italy, October 1-6, 2006, Proceedings, [3] Antonio Cicchetti, Davide Di Ruscio, Romina Eramo, and Alfonso Pierantonio. Automating co-evolution in model-driven engineering. In EDOC, pages th International IEEE Enterprise Distributed Object Computing Conference, ECOC 2008, September 2008, Munich, Germany, [4] Jesús Sánchez Cuadrado and Jesús García Molina. Modularization of model transformations through a phasing mechanism. Software and System Modeling, 8(3):325345, [5] K. Czarnecki and S. Helsen. Featurebased survey of model transformation approaches IBM Syst. J., 45(3):621645, [6] Anneke Kleppe. Mcc: A model transformation environment. In ECMDA-FA, pages Model Driven Architecture - Foundations and Applications, Second European Conference, ECMDA-FA 2006, Bilbao, Spain, July 10-13, 2006, Proceedings, [7] I. Kurtev. Adaptability of model transformations, chapter 5. PhD thesis, University of Twente, Enschede, May [8] Ivan Kurtev, Klaas van den Berg, and Frédéric Jouault. Rule-based modularization in model transformation languages illustrated with atl. Sci. Comput. Program., 68(3):138154, [9] Tom Mens and Pieter Van Gorp. A taxonomy of model transformation. Electr. Notes Theor. Comput. Sci., 152:125142, [10] Massimo Tisi, Frédéric Jouault, Piero Fraternali, Stefano Ceri, and Jean Bézivin. On the use of higher-order model transformations. In ECMDA-FA, pages Model Driven Architecture - Foundations and Applications, 5th European Conference, ECMDA-FA 2009, Enschede, The Netherlands, June 23-26, Proceedings, [11] Guido Wachsmuth. Metamodel adaptation and model co-adaptation. In Erik Ernst, editor, Proceedings of the 21st European Conference on Object-Oriented Programming (ECOOP'07), volume 4609 of Lecture Notes in Computer Science, pages Springer-Verlag, July ISSN SISTEDES

10 Automatización de la Selección de Transformaciones Alternativas Basada en Atributos de Calidad Javier Gonzalez-Huerta Grupo de Investigación ISSI Depto. de Sistemas Informáticos y Computación. Universidad Politécnica de Valencia Valencia. jagonzalez@dsic.upv.es Emilio Insfran Grupo de Investigación ISSI Depto. de Sistemas Informáticos y Computación. Universidad Politécnica de Valencia Valencia. einsfran@dsic.upv.es Silvia Abrahão Grupo de Investigación ISSI Depto. de Sistemas Informáticos y Computación. Universidad Politécnica de Valencia Valencia. sabrahao@dsic.upv.es Resumen Las transformaciones de modelos son una pieza clave en el Desarrollo de Software Dirigido por Modelos. Una transformación de modelos es el proceso por el cual un modelo puede convertirse en otro modelo del mismo sistema, usando un lenguaje para describir dicha transformación. Dado un modelo origen se pueden obtener uno o varios modelos destino atendiendo a las transformaciones alternativas seleccionadas. Las transformaciones alternativas aparecen cuando una entidad del modelo origen puede ser transformado en más de una entidad distinta en el modelo destino. Estos modelos, aun siendo similares en cuanto a la realidad que representan, pueden ser muy diferentes con respecto a sus atributos de calidad. En este artículo se define cómo introducir atributos de calidad en los procesos de transformación con el fin de dirigir la selección de transformaciones alternativas. Finalmente se muestra una estrategia de automatización para transformar diagramas de secuencia de un modelo de requerimientos en diagramas de clase UML. Palabras clave: Transformación de modelos, Desarrollo de Software Dirigido por Modelos. 1 Introducción En los últimos años el Desarrollo de Software Dirigido por Modelos (DSDM) [15] ha ganado gran aceptación como una aproximación para el desarrollo de sistemas en el que los modelos pasan a ser artefactos de primer orden. El uso de modelos eleva el nivel de abstracción, posibilitando un incremento de la productividad en el proceso de desarrollo de software y de la calidad del código generado a partir de los modelos [16]. Una de las ideas clave en el DSDM es transformar modelos con un alto nivel de abstracción en modelos más concretos que serán finalmente transformados en el código final. Por tanto, la calidad de los modelos involucrados en el proceso de desarrollo pasa a ser un factor decisivo para obtener software de calidad. Una transformación es el proceso por el cual un modelo puede convertirse en otro modelo del mismo sistema, usando un lenguaje para describir dicha transformación [10]. En un proceso de transformación de modelos, un modelo origen puede ser transformado en uno o varios modelos destino, que aun siendo similares en cuanto a la realidad que representan, pueden ser muy diferentes con respecto a sus atributos de calidad. Para poder producir artefactos software con unos determinados atributos de calidad, es necesaria la identificación de transformaciones alternativas y el análisis de cómo la aplicación de esas transformaciones afecta a la calidad de los artefactos obtenidos [9]. A pesar de que en la propia definición de MDA [10], OMG sugiere que se podrán utilizar una amplia gama de requisitos de calidad de servicio para dirigir transformaciones, no se encuentran aproximaciones que introduzcan, de manera genérica y efectiva, los requisitos de calidad como factor de decisión a la hora de seleccionar entre transformaciones alternativas. En un trabajo previo se mostró una arquitectura genérica para dar soporte a las transformaciones de modelos dirigidas por atributos de calidad [6], presentando un conjunto de artefactos para representar la información adicional necesaria (un modelo de calidad y un modelo de transformaciones) y se definía un proceso para dar soporte a estas transformaciones. ISSN SISTEDES

11 En este trabajo, haciendo uso de dicha arquitectura, definimos un esquema para, partiendo de una transformación de modelos existente, automatizar la selección de transformaciones alternativas en base a los atributos de calidad que ha de tener el modelo destino. La organización de este trabajo es la siguiente: la sección 2 describe los trabajos relacionados. La sección 3 presenta una aproximación para la automatización de la selección de transformaciones alternativas. La sección 4 presenta una implementación del esquema de automatización propuesto a un dominio concreto. Finalmente, la sección 5 presenta las conclusiones y trabajos futuros. 2 Trabajos Relacionados En esta sección, analizamos algunas propuestas que abordan la problemática de la selección de transformaciones alternativas en procesos de transformación de modelos desde la perspectiva de algún atributo de calidad. Kurtev [9] propone una técnica formal para la definición de espacios de transformación que soporta el análisis de las transformaciones alternativas dado un modelo origen. Esta técnica ofrece operaciones de selección y reducción de los espacios de transformación basados en ciertas propiedades de calidad que se desea que tenga el modelo destino resultante del proceso de transformación. Para generar el espacio de transformación, se define un proceso que toma como entrada el modelo origen y su metamodelo, el modelo destino y un Modelo de Calidad. Los atributos de calidad son empleados como criterio de selección entre las distintas alternativas y son incluidas explícitamente en los espacios de transformación. Concretamente esta propuesta explora la adaptabilidad y reusabilidad de las transformaciones de modelos para obtener esquemas XML a partir de modelos de clase. Para lograr la automatización el autor desarrolla también su propio lenguaje de transformación llamado MISTRAL apoyándose en una aproximación para el procesamiento de XML basado en un framework de modelado basado en MOF. Merilinna [11] propone una herramienta para guiar, de manera automatizada, las transformaciones de modelos de arquitecturas software, basándose en criterios de calidad. La aproximación considera únicamente las transformaciones horizontales [13] (transformaciones PIM a PIM) que son aquellas que se ejecutan al mismo nivel de abstracción. Si aparecen múltiples alternativas, el arquitecto determina qué arquitectura es la mejor solución teniendo en cuenta la información recogida en una base de datos denominada StyleBase. Esta base de datos contiene un conjunto de patrones de diseño y estilos arquitectónicos. Para cada patrón se almacenan los atributos que maximiza. Los autores definen su propio lenguaje para dar soporte a las transformaciones Q-RDL (Quality- Driven Rule Definition) y llevan a cabo una implementación de una herramienta Q-TRA desarrollada en C++. En definitiva, ambas propuestas definen una infraestructura propietaria, definiendo su propio lenguaje de transformación (MISTRAL y Q- RDL). Nuestra propuesta se ha apoyado en herramientas abiertas y extensibles, haciendo uso de facilidades del proyecto Eclipse como EMF (Eclipse Modeling Framework) [3] y de lenguajes de transformación estándar como QVT-Relations [12]. Además ambas propuestas [9], [11], y otras que abordan esta problemática, cubren parcialmente el ciclo de vida del DSDM soportando únicamente transformaciones horizontales o verticales. Por el contrario, nuestra propuesta puede ser utilizada en cualquier dominio, definiendo adecuadamente los artefactos necesarios, y en los distintos procesos de transformación que aparecen en las distintas fases del ciclo de vida DSDM. Además permite trabajar con múltiples atributos de calidad de manera simultánea efectuando un análisis trade-off para ponderar la importancia relativa de cada uno de los atributos de calidad. 3 Transformación de modelos dirigida por atributos de calidad En esta sección se introducen un esquema de automatización para la selección de transformaciones alternativas en base a atributos de calidad empleando la arquitectura propuesta en [6]. La sección 3.1 presenta una visión general de una arquitectura para transformaciones de modelos dirigidas por atributos de calidad, y la sección 3.2 define la estructura de las reglas de ISSN SISTEDES

12 transformación para adaptarlas al proceso de transformación de modelos dirigido por atributos de calidad empleando haciendo uso de multimodelos. Un multimodelo es una colección de modelos que dan soporte a diferentes vistas de un sistema, caracterizados por la existencia de relaciones entre los elementos de sus correspondientes metamodelos [4]. 3.1 Una arquitectura para transformaciones de modelos dirigidas por atributos de calidad Para dar un soporte adecuado a la definición de transformaciones de modelos que tengan en cuenta atributos de calidad, se ha propuesto una arquitectura basada en transformaciones con multimodelos. A diferencia de las transformaciones convencionales, los modelos participantes en transformaciones con multimodelos están relacionados entre sí. En el caso del proceso de transformación de modelos dirigido por atributos de calidad se emplean tres modelos adicionales, dos de ellos de entrada y uno intermedio generado por el propio proceso. El primer modelo de entrada es el Modelo de Calidad. Permite al usuario de la transformación seleccionar los atributos de calidad que ha de tener el modelo destino. El Modelo de Calidad tiene una estructura jerárquica basada en el estándar ISO/IEC SQuaRE [8], con características, sub-características y atributos de calidad. El segundo modelo de entrada es el Modelo de Transformaciones que expresa las relaciones entre los atributos de calidad y las transformaciones alternativas. Los atributos de calidad que en el aparecen son un subconjunto de los que aparecen en el Modelo de Calidad y han sido identificados como relevantes por el experto del dominio. El tercer modelo, generado por el propio proceso es el Modelo de Reglas Activas, que representa, para un determinado conjunto de constructores en el modelo origen, que reglas de transformación han sido seleccionadas de entre las alternativas para llevar a cabo la transformación. La Figura 1 presenta la estructura general del proceso de transformación dirigido por atributos de calidad mostrando los artefactos, actividades y fases principales. En la primera fase, el experto de dominio lleva a cabo la Identificación de Transformaciones Alternativas que serán posteriormente adaptadas al proceso de transformación de modelos dirigido por atributos de calidad. El experto del dominio lleva a cabo además un Análisis Trade-Off entre los atributos de calidad y las diferentes transformaciones alternativas. El objetivo es establecer cómo la aplicación de las distintas transformaciones alternativas afectará a la calidad del modelo destino. Esto se puede llevar a cabo mediante el uso de evidencia empírica obtenida en experimentos controlados o con el conocimiento del experto del dominio. Con el fin de realizar el Análisis Trade-Off en el que se medirá por un lado la importancia relativa de cada uno de los atributos de calidad, y por otro el grado con que las transformaciones alternativas dan soporte a los atributos de calidad empleamos el Proceso de Análisis Jerárquico (AHP) [14]. El AHP es una técnica de toma de decisiones que ha sido frecuentemente utilizada para resolver conflictos de esta índole. Este proceso se realiza i) estudiando cada patrón estructural, definido como un conjunto de constructores del metamodelo origen, para el que se han identificado transformaciones alternativas, y ii) analizando cómo la aplicación de cada una de las alternativas afecta a los distintos atributos de calidad. Los resultados del Análisis Trade-Off son introducidos en el Modelo de Transformaciones, que contiene los atributos de calidad identificados como relevantes por el experto del dominio, los pesos de cada atributo de calidad (entendidos como la importancia relativa de cada uno de estos atributos de calidad) y la información de los patrones estructurales para los cuales se han podido identificar transformaciones alternativas. Para cada patrón estructural para el que han sido identificadas transformaciones alternativas, se asociará la información de cada una de las transformaciones alternativas: el conjunto de reglas de transformación asociadas, y el impacto que tiene la aplicación de cada alternativa sobre los atributos de calidad. Estos impactos son flexibles y podrán ser modificados con posterioridad si se constata que la aplicación de alguna de las alternativas no tiene el impacto esperado en los atributos de calidad de los modelos generados. ISSN SISTEDES

13 Figura 1. Fases y artefactos involucrados en el proceso de transformación A continuación, cada vez que el usuario cambie los atributos de calidad que ha de tener el modelo destino, se lleva a cabo la Selección de Reglas, que tomando como entrada el Modelo de Transformaciones y el Modelo de Calidad, en el que el usuario de la transformación ha seleccionado los atributos que ha de tener el modelo resultante, ejecuta un proceso de transformación que automáticamente genera el Modelo de Reglas Activas. En la segunda fase se utiliza el Modelo Origen y el Modelo Reglas Activas como entrada para generar el Modelo Destino (ver Figura 1) además de las reglas de transformación, con aquellas reglas que no son alternativas y las que son alternativas que serán discriminadas por el Modelo de Reglas Activas. De esta forma cuando en el Modelo Origen se encuentra un patrón estructural para el que se han identificado transformaciones alternativas se llevará a cabo la transformación haciendo uso de las reglas asociadas a este patrón en el Modelo de Reglas Activas. Las reglas de transformación aplicadas en esta fase aseguran que los atributos de calidad seleccionados sobre el Modelo de Calidad durante la fase 1 estén presentes en el Modelo Destino. 3.2 Definición de la estructura de las reglas de transformación Esta sección presenta la estructura de las reglas de transformación para adaptarlas al proceso de transformación de modelos dirigido por atributos de calidad y lograr con ello la automatización. Para ello, nos apoyaremos en conceptos del lenguaje de transformación QVT-Relations [12], aunque los conceptos definidos en esta sección y el proceso de transformación propuesto puedan ser aplicados a otros marcos tecnológicos y lenguajes de transformación de modelos. El punto de partida de este proceso es una transformación de modelos existente en la que existen patrones estructurales para los que se han identificado transformaciones alternativas. Una vez se han identificado el conjunto de reglas que representan transformaciones alternativas, se lleva a cabo una refactorización de las reglas de transformación, para conseguir reglas definidas sobre patrones estructurales con un tamaño homogéneo y lo más pequeño posible, con el fin de maximizar la cohesión y minimizar el acoplamiento. Las reglas de transformación se descomponen en dos niveles de reglas. Las reglas top se activan ISSN SISTEDES

14 cada vez que se encuentra el patrón estructural en el modelo de origen y las reglas non-top son invocadas directa o transitivamente desde la cláusula where de las reglas top. Las reglas de transformación incluidas en las transformaciones alternativas han de ser modificadas para adaptarlas a la estructura de la arquitectura. Por cada patrón estructural para el que se han identificado transformaciones alternativas generaremos una nueva regla top por composición de todas las alternativas, aplicando principios de composición análogos a los descritos en [2] para el contexto de transformaciones QVT- Operational. Esta regla tendrá discriminantes que le permitirán seleccionar apropiadamente la alternativa, y realizar las invocaciones a reglas non-top en función de las selecciones realizadas en la fase de análisis de reglas. La información de las distintas reglas a invocar se encuentra disponible en el Modelo de Reglas Activas. En QVT-Relations una transformación se define como una relación entre dos o más modelos. Una relación en una transformación define las restricciones que deben ser satisfechas por los elementos de los modelos participantes. Una relación se define por dos o más dominios y un par de predicados when y where que especifican la relación que debe mantener entre los elementos de los modelos participantes. La cláusula when especifica las condiciones bajo las cuales la relación debe ejecutarse. La cláusula where especifica la condición que debe ser satisfecha por todos los elementos del modelo que participan en la relación. Estas cláusulas pueden restringir alguna de las variables de la relación y sus dominios [12]. La estructura de una regla top, que agrupa las distintas alternativas, constará de tres dominios. El primer dominio es el Modelo Origen, donde son descritas con precisión las entidades del patrón estructural. El segundo dominio es el Modelo de Reglas Activas, donde se define la asociación entre el nombre de las alternativas para un patrón estructural dado y las distintas reglas non-top que crearán o modificarán los constructores del modelo destino. Por último en una regla top tendremos también el dominio del Modelo Destino donde se define aquellos elementos comunes que serán creados o modificados por las diferentes alternativas. La precondición de la regla top consta de restricciones sobre el dominio origen y sobre el Modelo de Reglas Activas, así como otras condiciones que limiten la ejecución de la regla. La postcondición de las reglas top son las llamadas, por composición de transformaciones [2], a las distintas reglas nontop, agregando un mecanismo de reutilización a las reglas top. En cuanto a las reglas non-top, su estructura será definida de la forma habitual para representar la relación entre patrones estructurales del modelo origen y sus correspondencias en el modelo destino. 4 Automatizando la selección de transformaciones alternativas Esta sección muestra la automatización del proceso de transformación de modelos dirigido por atributos de calidad en un dominio concreto. Por restricción de espacio, presentamos únicamente un breve resumen de la automatización de la transformación de un modelo de requisitos, en concreto de diagramas de secuencia a diagramas de clase UML. Esta implementación se ha llevado a cabo con la infraestructura Eclipse, empleando EMF para definir los metamodelos y la persistencia en XMI que brinda para serializar los modelos. Como lenguaje de transformación empleamos QVT- Relations y como motor de transformación empleamos MediniQVT. 4.1 Identificación de alternativas y atributos relevantes El proceso comienza con la identificación de transformaciones alternativas en el dominio específico. En este caso utilizamos el Catalogo de Reglas de Transformación propuesto por Insfran [7]. Este catálogo define las relaciones entre patrones estructurales del diagrama de secuencia y el diagrama de clases UML entre otros. En concreto analizando estas reglas de transformación mostramos como ejemplo un patrón estructural en el diagrama de secuencia que da lugar a más de una transformación alternativa para el diagrama de clases UML. Este patrón estructural se muestra en la Figura 2: "un mensaje con el estereotipo «Service/New» de la clase A a la B, y dos mensajes con el estereotipo «Connect» de la clase B a las clases C y D,". ISSN SISTEDES

15 A continuación se muestran algunas de las transformaciones que pueden aplicarse para este patrón estructural: Alternativa 1: aplicar dos veces la regla de transformación TR15 del catálogo de reglas de transformación que transforma un mensaje con el estereotipo «Connect» en una relación de asociación entre las clases [7]. Alternativa 2: Aplicar la regla de transformación TR39 que transforma un mensaje con el estereotipo «Service/New» de la clase A a la clase B, y dos mensajes con el estereotipo «Connect» de la clase B a las clases C y D, respectivamente, en una nueva clase asociación (B) y una relación de asociación entre las clases C y D [7]. Las diferentes transformaciones alternativas se definen mediante la creación de nuevas reglas top que agrupan las reglas alternativas para un determinado patrón estructural. Estas reglas top contienen la referencias al Modelo de Reglas Activas. Con la información que proviene del Modelo de Reglas Activas, el patrón se transforma por medio de llamadas a un conjunto de reglas non-top u otro. La regla non-top llamada desde la alternativa 1, crea una asociación entre dos clases. Esta regla será llamada dos veces, una con los argumentos B y C y otra con B y D. La regla non-top llamada desde la alternativa 2, crea una asociación entre dos clases y un enlace a clase asociación con una tercera clase. Esta regla será llamada una vez con los argumentos C, D y B. Se han identificado otros patrones: dos clases conectadas por un mensaje con el estereotipo «Service/New» o «Connect» que serán transformadas en asociaciones entre las clases, y para las que no identificamos transformaciones alternativas. Para la transformación de estos dos patrones definimos únicamente las reglas top y reutilizaremos las llamadas a las reglas non-top ya definidas para convertir ese patrón en una asociación entre las clases. En la precondición de la regla, habrá una llamada a una consulta para evitar colisiones entre reglas. Para el ejemplo que nos ocupa, se han seleccionado dos características de calidad que deben tener los modelos generados por el proceso Figura 2. Patrón estructural del modelo origen de transformación: operabilidad y mantenibilidad. En concreto, se utilizó una sub-característica de la operabilidad: Appropriateness Recognizability y la sub-característica de mantenibilidad: Changeability tal como se define en el nuevo estándar ISO/IEC SQuaRE [8]. Los atributos seleccionados serán, en ambos casos, la efectividad y la eficiencia de cada una de estas subcaracteristicas. En la actividad de trade-off el experto del dominio asigna pesos a cada una de las alternativas en relación a estos atributos, basándose en su propia experiencia o bien en evidencias empíricas obtenidas en experimentos controlados en los que se demuestre la relación entre las transformaciones alternativas y los atributos de calidad. La tabla 1 muestra los distintos pesos asignados en la fase de Trade-Off, la base de estos valores se basa en los resultados de dos experimentos controlados [1], [5]. Dichos valores se basan en, por un lado, que la presencia de clases asociación en un modelo de clases UML empeora la Appropriateness Recognizability con respecto a modelos de clases UML que contienen asociaciones [1] y, por otro lado, en el hecho de que el incremento del número de asociaciones en un modelo de clases UML empeora la mantenibilidad del modelo [5]. La alternativa 1 tiene mayor número de asociaciones (2 por cada aplicación) que la alternativa 2 (1 por cada aplicación). ISSN SISTEDES

16 La justificación de la asignación de los pesos a cada una de las alternativas se trata con mayor detalle en [6]. Tabla 1. Pesos de las diferentes alternativas Alternativa 1 (TR15) Alternativa 2 (TR39) Appropiatness Changeability Recognizability Efic. Efec. Efic. Efec Aplicación de las transformaciones Esta sección muestra como un Diagrama de Secuencia puede generar diferentes diagramas de clase UML en función de la selección realizada sobre el Modelo de Calidad por el usuario de la transformación. Para ello, utilizamos como modelo de origen un diagrama de secuencia de la especificación de un Sistema de Gestión Hotelera. Este diagrama de secuencia muestra la interacción entre los objetos para la especificación del caso de uso de alquiler de habitaciones, que es iniciado por el actor employee. Este caso de uso representa el alquiler de una habitación por un cliente. Por razones de brevedad, se presenta sólo uno de los diagramas de secuencia, mostrado en la Figura 3.a. En la actividad de Selección de Reglas, se ejecuta una transformación que, dependiendo de las selecciones hechas por el usuario sobre el Modelo de Calidad, tal como se muestra en la Figura 3.b, genera un Modelo de Reglas Activas. En este modelo, para el patrón estructural descrito en la Figura 2, se habrá seleccionado la regla de transformación alternativa que corresponde. En la actividad de Transformación Dirigida por Atributos de Calidad se aplica este Modelo de Reglas Activas para la generación de los posibles modelos destino mostrados en la Figura 4.a y 4.b. La selección por parte del usuario del atributo de calidad Changeability tal como se muestra en el Modelo de Calidad mostrado en la Figura 3.b da como resultado el diagrama de clase UML mostrado en la Figura 4.b en el que el patrón estructural formado por los mensajes 10 al 12 y el patrón estructural formado por los mensajes 13 al 15 del modelo origen se transforman en dos clases asociación. La selección del atributo de calidad Appropriateness Recognizability da como Figura 3. Modelos de entrada a la fase de transformación resultado el diagrama mostrado en la Figura 4.a en el que el patrón estructural formado por los mensajes 10 al 12 y el patrón estructural formado por los mensajes 13 al 15 en el modelo origen se transforman en relaciones de asociación entre las distintas clases. Las dos representaciones que se muestran para cada modelo en la Figura 4.a y b son, el modelo destino tal como es generado por la herramienta de transformación y su representación como diagramas de clase UML. ISSN SISTEDES

17 Room Room Customer Rental Cost Customer CostType Rental (a) CostType En esta sección se ha mostrado una implementación de la arquitectura a un contexto de transformaciones en los que se presentan alternativas, donde se puede observar el impacto de la selección de los atributos de calidad en el modelo de destino. Todos los conceptos descritos en este ejemplo pueden ser aplicados a transformaciones más complejas, bien sea por el tamaño de los modelos de origen y/o destino, como por el número de transformaciones alternativas identificadas. 5 Conclusiones y trabajos futuros Este artículo ha presentado la automatización de un proceso de selección de transformaciones alternativas basándonos en atributos de calidad en transformaciones de modelos. Se ha descrito el enfoque multimodelo para la definición de transformaciones donde aparecen alternativas, así como la estructura que han de tener las reglas de transformación. Este enfoque permite la automatización de las transformaciones, según la información de los atributos de calidad deseados. Si bien no se está analizando la calidad global durante el proceso de transformación sino como la aplicación de cada transformación impacta en la calidad del modelo generado, el enfoque global analizando la evolución de la calidad del modelo generado será abordado en trabajos futuros. La viabilidad del método se ilustra con un ejemplo en el que se automatiza la selección de transformaciones alternativas en la transformación de diagramas de secuencia en diagramas de clase Cost Figura 4. Modelos destino alternativos (b) UML. También se muestra cómo la selección de cada alternativa afecta a la calidad de los modelos destino generados, mostrando ejemplos generados de forma automática por la herramienta de transformación. La adopción de este enfoque puede extender los procesos de desarrollo de software dirigido por modelos actuales brindando directrices para la definición de procesos en los que aparecen transformaciones alternativas, para que la selección entre estas se lleve a cabo en base a atributos de calidad. Como trabajos futuros, se pretende aplicar este enfoque a otros dominios y poner a prueba el proceso de transformación con múltiples atributos de calidad. Se pretende definir métricas que evalúen aspectos estructurales de los modelos generales para medir la calidad de los modelos destino generados, complementándolas con valoraciones subjetivas de expertos que servirán para retroalimentar la actividad de trade-off. Se pretende además diseñar experimentos controlados que validen empíricamente la usabilidad y efectividad de la propuesta. También planteamos abordar un análisis de la calidad global del modelo generado, analizando el impacto que tiene la secuencia de aplicación de reglas y las posibles incompatibilidades que puedan aparecer. Agradecimientos Este trabajo ha sido cofinanciado por el Ministerio de Ciencia e Innovación, en el marco del proyecto MULTIPLE (ref. TIN ), y por la G.V- A (proyecto CALIMO con ref. GV/2009/103). ISSN SISTEDES

18 Referencias [1] Abrahão, S., Genero, M., Insfrán, E., Carsí, J. A., Ramos, I., & Piattini, M. Quality-Driven Model Transformations: From Requirements to UML Class Diagrams. In J. R. (Eds.), Model-Driven Software Development: Integrating Quality Assurance. IGI Global Publishing, USA, [2] Belaunde, M. Transformation Composition in QVT. First European Workshop on Composition of Model Transformations (CMT). Bilbao, Spain, [3] Budinsky, F., Steinberg, D., Ellersick, R., Merks, E., Brodsky, S.A., Grose, T.J. Eclipse Modeling Framework. Addison Wesley, [4] Boronat, A., Knapp, A., Meseguer, J. Wirsing, M. What is a Multi-Modeling Languaje? In: LNCS, vol 5486/2009, pp Springer, Heidelberg, [5] Genero, M., Manso, M. Esperanza, Visaggio, C. A., Canfora, G., Piattini, M. Building measure-based prediction models for UML class models maintainability. Empirical Software Engineering 12(5): , [6] Gonzalez-Huerta, J., Blanes, D., Insfran, E., Abrahão, S. Towards an Architecture for Ensuring Product Quality in Model-Driven Software Development. Procedings of the International Conference on Product Focused Software Development and Process Improvement (PROFES 2010) Limerick, In press, [7] Insfrán, E. A Requirements Engineering Approach for Object-Oriented Conceptual Modeling. Phd Thesis, Universidad Politécnica de Valencia, Valencia, [8] International Organization for Standardization ISO/IE Software engineering 2005 Software product Quality Requirements and Evaluation (SQuaRE), [9] Kurtev, I. Adaptability of Model Transformations. PhD Thesis. University of Twente, Twente, [10] MDA Guide Version pdf, [11] Merilinna, J. A Tool for Quality-Driven Architecture Model Transformation. PhD thesis. VTT Technical Research Centre of Finland, Finland, [12] Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification [13] Mens, T., Van Gorp, P. A Taxonomy of model Transformations Electronic Notes in Theoretical Computer Science Volume 152, 27 March 2006, Pages Proceedings of the International Workshop on Graph and Model Transformation (GraMoT 2005), [14] Saaty, T.L. The Analytical Hierarchical Process. McGraw-Hill, [15] Schmidt, D.C. Model-driven engineering. IEEE Computer 39, 2, 25-31, [16] Stahl, T., Völter, M. Model-Driven Software Development Technology, Engineering, Management, John Wiley and Sons, Ltd., Chichester, ISBN: , ISSN SISTEDES

19 De flujos de navegación a Spring Web Flow. Un primer acercamiento a las transformaciones verticales en MWACSL * A. M. Reina Quintero J. Torres Valderrama M. Toro Bonilla Departamento de Lenguajes y Departamento de Lenguajes y Departamento de Lenguajes y Sistemas Informáticos Sistemas Informáticos Sistemas Informáticos E.T.S. Ingeniería Informática E.T.S. Ingeniería Informática E.T.S. Ingeniería Informática Universidad de Sevilla Universidad de Sevilla Universidad de Sevilla reinaqu@lsi.us.es jtorres@lsi.us.es mtoro@lsi.us.es Resumen MWACSL es una propuesta orientada a aspectos y dirigida por modelos para el desarrollo de aplicaciones web, cuyo acrónimo se obtiene de la combinación de las iniciales de las principales áreas de investigación en las que se enmarca (Model-driven, Web, Aspect-oriented, Concern Specific Languages). La arquitectura de una aplicación MWACSL presenta dos niveles de separación de conceptos. Horizontalmente, los distintos aspectos técnicos que componen la aplicación se separan conceptualmente, y de forma explícita, mediante lenguajes específicos de dominio, de forma que un aspecto técnico puede especificarse mediante uno o varios lenguajes específicos de dominio. Verticalmente, la separación se realiza inspirándose en la arquitectura MDA. Así se consigue una separación de los modelos que son independientes de plataforma de los que son dependientes de la misma. Este artículo se centra en una parte de esta arquitectura, el paso de un modelo independiente de plataforma a uno dependiente de la misma, y en un aspecto técnico concreto, la navegación. El objetivo principal del artículo es doble, por una parte, realizar una primera categorización de los distintos tipos de transformaciones que pueden tener lugar en una arquitectura MWACSL, y, por otra, especificar * Este trabajo se ha financiado parcialmente por el Ministerio de Ciencia y Tecnología y fondos FE- DER: TIN C06-03 y TIN un caso concreto de uno de estos tipos transformaciones (la generación de flujos de Spring Web Flow a partir de modelos de flujos de navegación). 1. Introducción Algunos de los primeros trabajos publicados relacionados con la orientación a aspectos se centraban en describir una serie de lenguajes específicos de dominio (DSL s) para especificar algunos de los aspectos que componen un sistema. Así, por ejemplo, COOL y RIDL [20], especificaban la sincronización y la coordinación, respectivamente. Sin embargo, la comunidad optó por lenguajes de propósito general, tales como AspectJ [24]. Los principales inconvenientes que existían para tratar con DSL s y que hicieron que la comunidad optara por lenguajes de aspectos de propósito general eran: (1) el importante esfuerzo necesario para implementar un nuevo lenguaje de aspectos para un dominio específico (DSAL); (2) la dificultad para extender un weaver realizado ad-hoc para un lenguaje de aspectos de dominio específico; y, (3) la imposibilidad de combinar weavers para diferentes DSAL s. Por contra, el trabajar con este tipo de lenguajes tiene importantes beneficios, ya que proporcionan una representación declarativa de los constructores más importantes relacionados con el aspecto que se está tratando, permitiendo así razonar mejor sobre los conceptos y detectar errores a ISSN SISTEDES

20 nivel de dominio. Se puede decir que estas propuestas iniciales de DSAL s se movían en el espacio tecnológico de las gramáticas (o grammarware). Un espacio tecnológico, según [18], es un contexto de trabajo con un conjunto de conceptos, un cuerpo de conocimiento, herramientas y habilidades requeridas. Si se trabaja en el espacio tecnológico de los modelos (o modelware), algunos de los inconvenientes iniciales para trabajar con DSAL s se pueden superar gracias a los trabajos, avances y herramientas que se están obteniendo dentro del campo del desarrollo de software dirigido por modelos. Así, la idea subyacente en nuestra propuesta, MWACSL, es la de trasladar estos DSAL s iniciales al espacio tecnológico de los modelos, de forma que mediante el uso de múltiples lenguajes específicos de dominio, de manera similar a [14], las competencias se separan de una forma limpia, tratándose cada una de ellas con un lenguaje explícito. El nombre de la propuesta (MWACSL) surge de la combinación de las iniciales de las principales áreas de investigación en las que se enmarca (Model-driven, Web, Aspectoriented, Concern Specific Languages). Uno de los objetivos de MWACSL es ayudar a las aplicaciones a adaptarse de forma rápida a los cambios, tanto de la tecnología, como de los requisitos de usuario. Para conseguir este objetivo se mezclan las ideas de MDA y orientación a aspectos. La web aparece como contexto de aplicación, ya que es un ámbito que está en constante evolución. En MWACSL, por tanto, se separan los modelos en dos dimensiones distintas, horizontalmente se separan los distintos aspectos que componen el sistema, mientras que verticalmente hay una separación entre lo que es independiente de la plataforma de implementación y lo que no lo es. Dentro de esta arquitectura el artículo se centra en una de las dimensiones horizontales, el aspecto de navegación, y en la transformación de una competencia navegacional expresada con un modelo independiente de plataforma a una plataforma concreta (Spring Web Flow). Previamente se caracterizan los tipos de transformaciones que se pueden encontrar en MWACSL, para dedicarse luego a un tipo de transformación concreta, la que se ha categorizado como directa. Para conseguir su objetivo el artículo se estructura de la siguiente forma: En primer lugar, se da una visión general de MWACSL. Luego, el artículo se centra en una dimensión horizontal, la navegación, dedicándose la sección 3 a profundizar más en este aspecto. En esta sección se tratan especialmente dos competencias navegacionales: la navegación estructural y de utilidad, y los flujos de navegación controlados. Luego, se categorizan el tipo de transformaciones que nos podemos encontrar en MWACSL (sección 4), para más tarde, centrarse en la implementación de una de ellas en la sección 5. A continuación, se da un repaso a los trabajos relacionados de las distintas áreas de conocimiento con las que está relacionado MWACSL. Finalmente se concluye el artículo y se apuntan algunas líneas de trabajo futuro. 2. MWACSL MWACSL es un enfoque para el desarrollo de software en entornos web orientado a aspectos y dirigido por modelos. En MWACSL la separación de conceptos se realiza en dos dimensiones distintas (Figura 1). Horizontalmente se separan los distintos aspectos técnicos, mientras que verticalmente se separan aquellos aspectos dependientes de la plataforma de implementación de los que no lo son. Los aspectos técnicos se separan conceptualmente y se hacen explícitos mediante lenguajes específicos de dominio independientes, de forma que cada aspecto a nivel independiente de plataforma se especifica usando uno o varios lenguajes específicos de dominio. El mantenimiento de esta separación en la plataforma de implementación dependerá de la plataforma concreta. Lo ideal sería seguir manteniendo la separación en dicha plataforma, pero esto no es siempre posible, ya que muchas veces es el cliente el que escoge la plataforma en la que se va a desarrollar la aplicación. Así, por ejemplo, en la Figura 1 se ve reflejado el hecho de que navegación e interfaz de usuario son dos aspectos que ISSN SISTEDES

21 Figura 1: Arquitectura de modelos de una aplicación MWACSL se encuentran separados a nivel independiente de plataforma, sin embargo, no se mantiene esa separación a nivel específico de plataforma porque la implementación de estos dos aspectos se realiza con Java Server Faces(JSF)[21], un framework de programación Java que no tiene una separación limpia de interfaz y navegación. Una aplicación en MWACSL está compuesta de un modelo primario y una serie de modelos de aspectos (cada uno expresado utilizando uno o varios lenguajes específicos de dominio). Si los aspectos son suficientemente complejos, se pueden usar distintos lenguajes específicos de dominio para especificarlos. Un ejemplo de este tipo de aspectos es la navegación, ya que se puede descomponer en diferentes tipos de competencias o concerns[15]. Por ejemplo, en [15] se sugieren tres grandes tipos de competencias navegacionales: las relacionadas con tareas, las relacionadas con temas y las que los autores denominan puras. 3. La navegación en MWACSL De todos los aspectos técnicos mostrados en la Figura 1 este artículo se centra en la navegación, porque, en primer lugar, la navegación es un concepto distintivo de las aplicaciones web, llegando a convertirse en un factor importante a tener en cuenta en el éxito de las mismas; en segundo lugar, porque puede sufrir muchas variaciones a lo largo de la vida de la aplicación; y, finalmente, porque es una característica distintiva de MWACSL, ya que la mayoría de las propuestas de ingeniería web conciben la navegación como una vista del modelo conceptual, lo que, implícitamente, impone un modelo de desarrollo en cascada, puesto que hay que abordar antes el diseño del modelo conceptual que el de la navegación. En MWACSL se han separado dos competencias navegacionales a nivel independiente de la plataforma. Por una parte, la navegación estructural y de utilidad, y por otra, los flujos de navegación controlada. La navegación estructural y la de utilidad se tratan de forma conjunta porque presentan un comportamiento muy similar. Mientras que la navegación estructural puede verse como una categoría de navegación cuya función principal es la de enlazar páginas que se encuentran dentro la jerarquía del sitio, la navegación de utilidad conecta páginas que ayudan al usuario a utilizar el sitio y que complementan a la navegación principal, situándose cerca de ella. La navegación principal es un tipo de navegación estructural. Según [16] los enlaces que representan navegación estructural se pueden clasificar en dos grandes grupos: navegación principal y navegación local. La navegación principal es el menú o conjunto de enlaces que aparecen en casi todas las páginas del sitio web y que enlazan a las principales secciones del mismo. ISSN SISTEDES

22 La navegación local guía al usuario a ciertas secciones situadas a niveles más profundos del sitio. Finalmente, un flujo de navegación controlada es un flujo de navegación o diálogo en el que se restringe la libertad del usuario a la hora de navegar por el sitio web con idea de guiarlo para que complete un proceso de negocio. Figura 2: Tipos de competencias navegacionales En la Figura 2 se muestra cómo el aspecto de navegación está compuesto por varias competencias navegacionales. Una clasificación de los tipos de competencias navegacionales se puede encontrar en [15], donde se definen tres grandes grupos, las relacionadas con tareas, las relacionadas con temas y las puras. Atendiendo a esta clasificación, la navegación estructural y de utilidad estarían dentro del grupo de competencias navegacionales puras, mientras que los flujos de navegación controlada serían una competencia navegacional de tarea. El lenguaje específico de dominio para separar la navegación de utilidad y estructural se ha especificado en [25, 26]. Ambas competencias o concerns se tratan de forma conjunta porque la navegación de utilidad tiene un comportamiento muy similar a la navegación principal, lo que implica que con el mismo DSL se pueden especificar estos dos tipos de navegación. Este lenguaje específico de dominio se ha inspirado en los entregables conocidos como mapas del sitio o sitemap. Un ejemplo de modelo de navegación estructural y de utilidad definido utilizando este lenguaje se muestra en la Figura 3. Para tratar con la navegación controlada se han de tener en cuenta tres cuestiones [31]: el control de la navegación, la gestión del estado y la modularidad. Teniendo estas cuestiones en cuenta, los diagramas de estado son una de las notaciones más apropiadas para modelar este tipo de competencia. Así, el lenguaje específico de dominio que especifica la navegación controlada se basa en diagramas de estado y se inspira en una de las propuestas de modelado web que usa esta notación: StateWeb- Chart [33]. Un ejemplo de modelo de flujo de navegación utilizando este tipo de diagrama es el mostrado en la Figura 4, que representa un flujo de navegación controlada de un proceso de compra en una aplicación de comercio electrónico. A nivel dependiente de plataforma no siempre se puede mantener la separación de competencias, ya que depende la la plataforma concreta de implementación. Una plataforma que ayuda a tener separados los flujos de navegación controlados es Spring Web Flow [5]. Un lenguaje específico de dominio para trabajar con Spring Web Flow se especificó en [28, 27]. La navegación estructural y de utilidad, sin embargo, son más difíciles de separar en plataformas concretas. Hasta lo que alcanza nuestro conocimiento, no hay ninguna plataforma en la que se separe claramente este tipo de navegación, de forma que, en una primera aproximación, la plataforma escogida para implementar la navegación estructural y de utilidad es XHTML. En [26] se presenta una ampliación a metamodelo que especifica la sintaxis abstracta de XHTML y que se obtiene de forma automática mediante el importador de XSD de EMF [6]. 4. Categorización de las transformaciones en MWACSL En MWACSL hay dos grandes grupos de transformaciones, dependiendo del propósito de las mismas. Por una parte, hay transformaciones cuyo objetivo es la generación de artefactos que van a ser parte del proceso de desarrollo, y por otra, hay transformaciones cuyo objetivo es generar artefactos que tienen propósitos de validación. En la Figura 5 se muestran ejemplos de estos dos tipos de transformaciones. La subfigura 5(a) muestra ejemplos de ISSN SISTEDES

23 Figura 3: Modelo especificando la navegación estructural y de utilidad. transformaciones cuyo objetivo es la generación, mientras que en la subfigura 5(b) muestra ejemplos de transformaciones de validación. Otra clasificación de las transformaciones está relacionada con el nivel de abstracción en el que se expresan los modelos origen y destino, pudiendo ser verticales y las horizontales. Las transformaciones verticales son aquellas que obtienen artefactos de más bajo nivel a partir de modelos de alto nivel, mientras que las horizontales transforman artefactos situados al mismo nivel de abstracción. En la Figura 5, las transformaciones 1, 2, 3, 4 y 6 se pueden considerar transformaciones verticales. Entre las propias transformaciones verticales también hay diferencias. Las transformaciones 1 y 3 son transformaciones modelo a modelo, mientras que la 2, la 4 y la 6 son modelo a texto. También hay diferencias en relación a los artefactos generados. Así, la transformación 3 se puede considerar como una transformación directa en el sentido de que el flujo definido a nivel de PIM, tiene una correspondencia casi directa con el flujo Spring Web Flow, a nivel específico de plataforma. La transformación 1, sin embargo, no es directa porque genera un modelo XHTML incompleto, en el sentido de que el modelo XHTML generado solamente contiene información acerca de la navegación de utilidad y estructural. En cuanto al grupo de transformaciones de modelo a texto, la 2 y la 4 son similares. En concreto, la transformación 2 genera un archivo XHTML a partir de un modelo XHTML, y la 4 un flujo de navegación web a partir de un modelo de Spring Web Flow. Detalles más concretos de este último tipo de transformación se pueden obtener en [27]. La transformación 6, sin embargo, tiene propósitos de validación y su objetivo es obtener una especie de borrador de qué aspecto tendrían la navegación estructural y de utilidad. La transformación 5 es la única transformación horizontal, y tiene propósito de validación. Representa el proceso de composición de modelos. Nótese que dirección de la transformación es desde la navegación estructural hacia los flujos de navegación, y que la dirección contraria no se puede dar en este caso, ya que con el lenguaje específico de dominio definido para especificar la navegación estructural y de utilidad no se pueden expresar flujos de navegación. 5. De Flujos de navegación controlada a SWF mediante transformaciones QVT Tanto el metamodelo del flujo de navegación como el de Spring Web Flow se han implementado como modelos Ecore, es decir, usando el estándar de facto EMF [6] A estos metamodelo ISSN SISTEDES

24 (a) Generación. Figura 4: Modelo que especifica un flujo de navegación controlado. se le han adjuntado un conjunto de restricciones OCL, implementadas mediante el plugin OCL [8] que se incluye dentro de proyecto de modelado de Eclipse (EMP) [7]. Las transformaciones se han implementado usando QVT Operational Mapping [22] y el motor de QVT escogido es el implementado dentro de proyecto EMP 1. Por cada flujo de navegación definido a nivel de PIM se genera un flujo de navegación en Spring Web Flow, lo que se refleja en la correspondencia o mapping tospringwf. Esta correspondencia es la que desencadena la generación de todo el modelo de salida. En la Figura 6 se muestran otros dos ejemplos de mappings que se definen en la transformación. 1 Los metamodelos y transformaciones mencionados en este artículo pueden ser descargados de http: // (b) Validación Figura 5: Algunos tipos de transformaciones en MWACSL En la parte izquierda (la subfigura 6(a)), se muestra una correspondencia o mapping simple, pero central, ya que se encarga de generar un estado tipo ViewState por cada estado FrontEndView del flujo de navegación controlada. En la parte derecha (la subfigura 6(b)), se muestra otra correspondencia que necesita un poco más de elaboración. Esta necesidad se produce por el hecho de los estados finales en Spring Web Flow tienen asociada una vista, mientras que en el flujo definido a alto nivel las vistas siempre van asociadas a estados de tipo FrontEndView. De esta forma, para generar los estados de tipo EndState de Spring Web ISSN SISTEDES

25 Flow hay que quedarse con los estados finales del modelo de entrada, navegar por las transiciones que llegan hacia ellos para obtener los estados de tipo FrontEndView que conducen al estado final. (a) De FrontEndView a ViewState. (b) De FrontEndView + estado final a EndState Figura 6: Ejemplos de mapppings 6. Trabajos relacionados Al ser MWACSL una propuesta que se apoya en varias disciplinas emergentes, los trabajos relacionados hay que buscarlos en áreas tales como el modelado orientado a aspectos, los lenguajes específicos de dominio o la ingeniería web. En general, las propuestas de modelado orientado a aspectos pueden agruparse en dos grandes familias, por una parte, aquellas cuyo objetivo es el modelado de programas que se han implementado en una plataforma orientada a aspectos, tales como [13, 23, 9], y, por otra, las centradas en estructurar los modelos de acuerdo a los diferentes aspectos que lo componen, como [2, 10]. MWACSL está más alineado con la segunda familia, aunque no se descarta la primera en el caso en que la plataforma sea orientada a aspectos, ya que así se pueden generar aspectos de AspectJ o hiperslices de HyperJ. En relación a los lenguajes de aspectos específicos de dominio (o DSALs) se pueden encontrar muchas propuestas publicadas en las diferentes ediciones del Domain-Specific Aspect Languages Workshop. Muchos de los artículos presentados en esta serie de talleres definen nuevos DSALs, aunque la mayoría de ellos se mueven en el espacio tecnológico de las gramáticas. Una de las propuestas que aboga por la definición de múltiples lenguajes específicos de dominio para el desarrollo de aplicaciones web en el espacio de las gramáticas es WebDSL [32]. WebDSL está compuesto por varios sublenguajes: un lenguaje para el modelo de datos, un lenguaje para la presentación, un lenguaje de consultas, y un lenguaje de expresiones y acciones. Como extensión a WebDSL, los autores también han definido lenguajes específicos de dominio para tratar con el control de acceso y con workflows. En esta propuesta la generación de código se realiza mediante reglas de reescritura de programas. Con respecto a las propuestas de ingeniería web, y sobre todo, en relación al tratamiento que le dan a la navegación, hay que destacar que casi todas las propuestas modelan la navegación de forma separada al modelo conceptual y a la interfaz de usuario. En general, hay dos tipos de propuestas en relación a la navegación, aquellas que la modelan desde un punto de vista del comportamiento y las que lo hacen desde una perspectiva estructural. Las primeras se basan en la semántica operacional, y normalmente, lo que hacen es explorar el estado en el que quedará el sistema cuando un evento particular lanza una transición. Las segundas se centran en estructurar la información en contextos que representan trozos de información que se conectan mediante enlaces con significado. Las propuestas que se centran en el comportamiento suelen usar diagramas de estado para modelar la navegación. En este grupo están [3, 33, 19, 12, 4]. Las propuestas centradas en la estructura, normalmente conciben la navegación como una vista del modelo conceptual, lo que implícitamente, impone un desarrollo en cascada, en el sentido de que es necesario definir en primer lugar el modelo conceptual para luego poder definir el de navegación. Los autores de estas propuestas también las están extendiendo aplicando orientación a aspectos y un desarrollo de software dirigido por modelos. En este grupo están UWE [34], que usa la ISSN SISTEDES

26 orientación a aspectos para especificar control de acceso y la adaptatividad de la navegación; aspectwebml [29], que introduce los aspectos para tratar con la personalización en aplicaciones web ubicuas; SEAL [1], cuyo objetivo es la adaptación de contenido, para lo que se basan en la separación avanzada de conceptos; OOWS [30], que proponen la metáfora de tarea para describir competencias, y, finalmente, OOHDM [11], que propone separar y capturar de forma temprana las competencias que afectan a la navegación. 7. Conclusiones y trabajos futuros En el artículo se ha presentado de forma general MWACSL, y se han caracterizado los tipos de transformaciones que pueden ser necesarias dentro de la propuesta. Como primera aproximación el artículo ha presentado un caso concreto de transformación directa relacionado con la navegación, la generación de un flujo en Spring Web Flow a partir de un modelo de alto nivel que representa la navegación controlada. El trabajar con múltiples lenguajes específicos de dominio supone un reto, ya que se introducen una serie se problemas, como las validaciones cruzadas de los modelos. Como trabajo futuro nos proponemos comprobar si las transformaciones horizontales que se han categorizado en la sección 4 se pueden aligerar usando un lenguaje como EVL (Epsilon Validation Language) [17], que se usa para realizar chequeos de consistencia entre múltiples modelos, a diferencia de OCL, que solamente realiza comprobaciones en un modelo en cada momento. Finalmente, otra línea de trabajo es la ampliación de MWACSL, tratando con más plataformas de implementación, otros aspectos y competencias navegacionales. En paralelo, planeamos llevar a cabo una fase de experimentación, en la que se puedan cuantificar las ventajas de MWACSL. Referencias [1] S. Casteleyn, W. Van Woensel, and G.- J. Houben. A semantics-based aspectoriented approach to adaptation in web engineering. In Proceedings of the 18th conference on Hypertext and hypermedia (HT07), pages ACM, [2] S. Clarke and E. Baniassad. Aspect- Oriented Analysis and Design: The Theme Approach. Addison-Wesley Professional, [3] M. C. Ferreira de Oliveira, M. A. Santos Turine, and P.C. Masiero. A statechartbased model for hypermedia applications. ACM Transactions on Information Systems, January [4] Peter Dolog and Wolfgang Nejdl. Using uml and xmi for generating adaptive navigation sequences in web-based systems. In Proc. of «UML» Sixth International Conference on the Unified Modeling Language: Modeling Languages and Applic, number Springer-Verlag Lecture Notes in Computer Science, October [5] K. Donald and E. Vervaet. The spring web flow home page. Avalaible at: confluence/spring/display/webflow/ Home. [6] Eclipse. Eclipse Modeling Framework. [7] Eclipse-EMP-Project. Eclipse Modeling Project. Avalaible at: eclipse.org/modeling/, [8] Eclipse-MDT-Project. Model Development Tool. Avalaible at: mdt/?project=ocl#ocl, [9] Joerg Evermann. A meta-level specification and profile for aspectj in uml. In AOM 07: Proceedings of the 10th international workshop on Aspect-oriented ISSN SISTEDES

27 modeling, pages 21 27, New York, NY, USA, ACM Press. [10] R. France, I. Ray, G. Georg, and S. Ghosh. Aspect-oriented approach to early design modeling. IEE Software, 151: , June [11] S. Gordillo, G. Rossi, A. Moreira, J. Araújo, C. Vairetti, and M. Urbieta. Modeling and composing navigational concerns in web applications. requirements and design issues. In Proc. of the Fourth Latin American Web Congress, LA-Web 06., pages 25 31, Oct [12] E. A. Gorshkova and B. A. Novikov. Use of statechart diagrams for modeling of hypertext. Programming and Computer Software, 30(1):47 51, [13] Yan Han, Günter Kniesel, and Armin B. Cremers. A meta model and modeling notation for AspectJ. In Omar Aldawud, Grady Booch, Jeff Gray, Jörg Kienzle, Dominik Stein, Mohamed Kandé, Faisal Akkawi, and Tzilla Elrad, editors, The 5th Aspect-Oriented Modeling Workshop In Conjunction with UML 2004, October [14] Anders Hessellund, Krzysztof Czarnecki, and Andrzej Wasowski. Guided development with multiple domain-specific languages. In Gregor Engels, Bill Opdyke, Douglas C. Schmidt, and Frank Weil, editors, Proceedings of the Model Driven Engineering Languages and Systems, 10th International Conference, MoDELS 2007, volume 4735 of Springer-Verlag Lecture Notes in Computer Science, pages Springer, [15] J. Nanard, G. Rossi, M. Nanard, S. Gordillo, and L. Pérez. Concern-sensitive navigation: Improving navigation in web software through separation of concerns. In Proc. Conf. on Advanced Information Systems Engineering (CAISE 08), volume 5074, pages , Berlin, Heidelberg, Springer-Verlag Lecture Notes in Computer Science. [16] James Kalbach. Designing Web Navigation. O Reilly Media, Inc., [17] D. S. Kolovos, R. F. Paige, and F. A.C. Polack. Detecting and repairing inconsistencies across heterogeneous models. In Proceedings of 2008 International Conference on Software Testing, Verification, and Validation (ICST08, pages IEEE, [18] I. Kurtev, J. Bézivin, and M. Aksit. Technological spaces: An initial appraisal. In International. Federated Conf. (DOA, ODBASE, CoopIS), Industrial Track, [19] K.R.P.H. Leung, L.C.K. Hui, S.M. Yiu, and R.W.M. Tang. Modelling web navigation by statechart. In Proceedings of the 24th Annual International Computer Software and Applications Conference (COMPSAC 2000),, October [20] Cristina Videira Lopes. D: A Language Framework for Distributed Programming. PhD thesis, College of Computer Science, Northeastern University, [21] Oracle Sun Developer Network. Javaserver faces technology. com/javaee/javaserverfaces/, [22] OMG. Meta object facility (mof) 2.0 query/view/transformation specification. Technical report, OMG, Nov [23] Ilka Philippow, Matthias Riebisch, and Kai Böllert. The Hyper/UML approach for feature based software design. In Omar Aldawud, Mohamed Kandé, Grady Booch, Bill Harrison, Dominik Stein, Jeff Gray, Siobhán Clarke, Aida Zakaria Santeon, Peri Tarr, and Faisal Akkawi, editors, The 4th AOSD Modeling With UML Workshop, October [24] AspectJ Project. Aspectj home page. Avalaible at: aspectj/, ISSN SISTEDES

28 [25] A. M. Reina Quintero and J. Torres Valderrama. Metamodelling and transforming sitemaps for reconciling information architecture and navigation design. In J. R. Romero, O. Avila-García, and V. Pelechano, editors, Publicado en las Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos (TJISBD), volume 3. Sistedes, [26] A. M. Reina Quintero and J. Torres Valderrama. Sitemaps from a model driven perspective. a first step for bridging the gap between information architecture and navigation design. In Joaquim Filipe and José Cordeiro, editors, WE- BIST Proceedings of the 6th International Conference on Web Information Systems and Technology, volume 2, pages INSTICC. Institute for Systems and Technologies of Information, Control and Communication, April ISBN: [27] A. M. Reina, M. Toro, and J. Torres. Generating domain specific aspect code for navigation from platform specific models in mwacsl. In C. de la Riva J. Tuya A. Moreira, M. J. Suárez-Cabal, editor, Publicado en las Actas de las XIII Jornadas de Ingeniería del Software y Bases de Datos (JISBD 08), pages Sistedes, October [28] A. M. Reina, J. Torres, and M. Toro. El metamodelado de un framework: Spring web flow. In A. Vallecillo, V. Pelechano, and A. Estévez, editors, Publicado en las Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos (TJISBD), volume 1. Sistedes, [29] A. Schauerhuber, M. Wimmer, E. Kapsammer, W. Schwinger, and W. Retschitzegger. Bridging webml to model-driven engineering: from document type definitions to meta object facility. IET Software, 1(3):81 97, [30] P. Valderas, V. Pelechano, G. Rossi, and S. Gordillo. From crosscutting concerns to web systems models. In Proceedings of the Web Information Systems Engineering (WISE 2007), volume 4831, pages Springer-Verlag Lecture Notes in Computer Science, [31] E. Vervaet. The Definitive Guide to Spring Web Flow. APress, [32] Eelco Visser. Generative and Transformational Techniques in Software Engineering II, volume 5235/2008 of LNCS, chapter WebDSL: A Case Study in Domain-Specific Language Engineering, pages Springer Berlin / Heidelberg, [33] M.A. Alba Winckler. StateWebCharts: a Formal Notation for Navigation Modelling of Web Applications. PhD thesis, Institute de Recherche en Informatique de Toulouse, [34] Gefei Zhang, Hubert Baumeister, Nora Koch, and Alexander Knapp. Aspectoriented modeling of access control in web applications. In Mohamed Kandé, Dominik Stein, Omar Aldawud, Tzilla Elrad, Jeff Gray, and Jörg Kienzle, editors, 6th International Workshop on Aspect- Oriented Modeling, March ISSN SISTEDES

29 Mejorando el nivel de automatización en el desarrollo dirigido por modelos de editores gráficos Álvaro Jiménez Juan M. Vara Verónica Bollati Esperanza Marcos Grupo de Investigación Kybele Universidad Rey Juan Carlos Madrid (España) {alvaro.jimenez, juanmanuel.vara, veronica.bollati, Resumen En general, cualquier proceso de desarrollo dirigido por modelos implica la necesidad de definir modelos con un alto nivel de detalle, ya que los modelos acaban siendo un mapa del código final. No obstante, este nivel de complejidad suele resultar en modelos complejos y difíciles de manejar, por lo que resulta conveniente disponer de editores gráficos que omitan los detalles y proporcionen una visión global del modelo. Para este fin suelen utilizarse editores basados en arcos y nodos (o diagramadores) que proporcionan una visión general del modelo. Siendo otro artefacto software más, no sólo es posible si no recomendable, aplicar los principios de la Ingeniería Dirigida por Modelos al desarrollo de estos editores con el objetivo de automatizar al máximo posible al proceso de desarrollo. Por todo ello, este trabajo revisa las propuestas existentes hasta la fecha para el desarrollo dirigido por modelos de diagramadores en EMF, el marco de (meta)modelado más aceptado a día de hoy, y presenta un prototipo que mejora el nivel de automatización ofrecido por las propuestas existentes. 1. Introducción La Ingeniería Dirigida por Modelos (IDM) es el último paso en la tendencia a elevar el nivel de abstracción al que se diseña y construye el software. Los dos principios fundamentales de la IDM son: potenciar el rol de los modelos a lo largo de todo el ciclo de vida del software y potenciar el nivel de automatización en el proceso de desarrollo [9]. Así, en un proceso de desarrollo dirigido por modelos partiremos de modelos con un alto nivel de abstracción que servirán para especificar el sistema obviando detalles tecnológicos. Dichos modelos serán refinados semi-automáticamente por medio de transformaciones de modelos, hasta que su nivel de abstracción permita utilizarlos para generar el código final. Como cualquier otro paradigma de desarrollo software, la IDM debe proporcionar herramientas de soporte al proceso de desarrollo. En particular, igual que disponemos de IDEs que facilitan las tareas de codificación con cualquier lenguaje de programación, necesitamos de entornos que faciliten las tareas de edición de modelos. En este sentido, el elevado nivel de detalle que deben tener los modelos que manejamos (especialmente los que son directamente traducidos a código fuente) y la naturaleza de los documentos que almacenan dichos modelos (dialectos XML generalmente) hacen muy recomendables los editores en forma de árbol (tree-based), para facilitar la edición avanzada de modelos [7]. El ejemplo más conocido son los editores tree-based que proporciona EMF, la plataforma de (meta)modelado más adoptada a día de hoy en el ámbito de la IDM [11]. No obstante, precisamente el nivel de detalle de estos editores es el que les hace poco recomendables cuando el objetivo es simplemente tener una visión global de los componentes del sistema y de las relaciones entre ellos. Para este fin resultan mucho más apropiados los editores gráficos del tipo nodos y arcos (o cajas y flechas), también llamados diagramadores. Con estos editores los desarrolladores pueden, por un lado, definir de forma gráfica un esqueleto del modelo por el método clásico de arrastrar y soltar (drag and drop), y por otro, proporcionar una vista general del modelo al resto de implicados en el proceso de desarrollo. Nótese que el uso de los dos tipos de editores no resulta excluyente, sino ISSN SISTEDES

30 más bien al contrario, es recomendable que los entornos para DSDM soporten distintas formas de presentar un mismo modelo de cara a mejorar la usabilidad de la herramienta, uno de los principales inconvenientes para la adopción del DSDM en los últimos años [10]. Por otra parte, la idea de usar modelos para guiar u orientar el proceso de desarrollo no implica un gran cambio respecto a las prácticas clásicas. En realidad la novedad estriba en el papel central que juegan dichos modelos y sobre todo en aumentar el nivel de automatización. De hecho, la única forma de aprovechar al máximo las ventajas que ofrece la IDM, en términos de desarrollos más rápidos y baratos, pasa por automatizar al máximo posible las diferentes etapas del proceso de desarrollo [1]. Automatizar el proceso implica automatizar cada una de las tareas que lo componen y la única forma de hacerlo es a través de la construcción de herramientas de soporte. Como consecuencia, en los últimos años han aparecido numerosas herramientas para soportar las tareas relacionadas con la puesta en práctica de un proceso de DSDM. Así, se encuentran herramientas para definir y utilizar nuevos lenguajes de modelado; herramientas o lenguajes para desarrollar transformaciones de modelos; herramientas para asegurar que los modelos son consistentes y correctos, etc. Por otro lado, dado que estas herramientas son también componentes software, lo ideal sería que para su construcción también se siguieran los principios de la IDM. Un ejemplo de esta práctica es la idea de ver las transformaciones de modelos como modelos de transformación [2], de manera que puedan transformarse, validarse o generarse automáticamente, como cualquier otro modelo [14]. En este trabajo combinamos la necesidad de disponer de diagramadores con la idea de aplicar la IDM para su desarrollo. En particular nos centramos en la tecnología disponible para el desarrollo (dirigido por modelos) de editores gráficos en EMF. Concretamente revisamos las propuestas existentes, que giran todas en torno a GMF (Graphical Modelling Framework), el framework para generación de diagramadores para modelos EMF que proporciona el Eclipse Modelling Project [5] y presentamos una nueva herramienta que aumenta el nivel de automatización del proceso. 2. Desarrollo dirigido por modelos de diagramadores basados en EMF Esta sección revisa las soluciones existentes a día de hoy para soportar el desarrollo dirigido por modelos de editores gráficos (de tipo diagramador) para modelos EMF. En particular nos centraremos en cómo deben utilizarse, es decir, el proceso de desarrollo a seguir cuando se utilizan estas herramientas, y su nivel de automatización Graphical Modeling Framework (GMF) Como ya hemos mencionado, GMF es la base tecnológica sobre la que operan el resto de propuestas estudiadas en este trabajo. Concretamente, GMF es un plug-in de Eclipse que proporciona un componente generativo y una plataforma de ejecución para el desarrollo de la infraestructura de editores gráficos basados en EMF y GEF (Graphical Editing Framework). Básicamente, el proceso de generación de editores con GMF consiste en especificar un conjunto de modelos a partir de los cuales GMF generará automáticamente el código Java que implementa el diagramador y que podrá ser utilizado como un nuevo plugin de Eclipse. La Figura 1 detalla el proceso de desarrollo completo y los modelos que se manejan en cada paso. Nótese la distinción entre aquellos pasos que deben realizarse manualmente y aquellos que GMF realiza automáticamente. 1. Definir el metamodelo (también llamado modelo de dominio) del DSL (.ecore) 2. Generar el modelo.genmodel a partir del modelo.ecore. Este modelo contiene información específica de la plataforma donde se va a ejecutar la aplicación final y permite configurar cómo se llevará a cabo la generación de código. 3. Generar el código que implementa el editor tree-based a partir del modelo genmodel. Es importante tener en cuenta que gran parte del código del diagramador es directamente el código del editor tree-based. Es decir, muchas de las características gráficas del diagramador, como los editores de propiedades para cada elemento del modelo, son heredadas del editor tree-based. 4. Definición del modelo que especifica los elementos gráficos que utilizaremos para ISSN SISTEDES

31 representar los elementos del metamodelo cuando lo instanciemos (.gmfgraph). GMF Project Domain Model 1 2 EMF Generator Model EMF Project 3 EMF editor (tree-like).ecore.genmodel.gmfgraph Graphical Model 4 En la mayoría de los casos, * el resultado no es correcto Mapping Model 6 7.gmfmap 8 Tooling Model 5 GMF Generator Model 9 GMF editor (diagrammer).gmftool.gmfgen Ejecución Manual Automático LEYENDA Figura 1. Proceso de Desarrollo de un editor gráfico usando GMF 5. Definición del modelo que permite especificar los componentes de la paleta de herramientas del editor (gmftool). 6. Generación del modelo de correspondencias (.gmfmap) entre los elementos gráficos, los controles de la paleta y los elementos del metamodelo de nuestro DSL. Para ello GMF proporciona un asistente que genera este modelo a partir de los anteriores. 7. Es habitual que las correspondencias recogidas en el modelo generado no sean correctas, con lo que es necesario refinar dicho modelo manualmente. 8. Generar el modelo generador de GMF (.gmfgen) a partir del modelo de correspondencias. 9. Generar el código Java que implementa el diagramador. GMF proporciona un buen entorno para la generación automática de diagramadores, como prueba el hecho de que sea la base tecnológica del resto de propuestas que se estudian en este trabajo y de la contribución que presentamos. No obstante, el proceso de desarrollo que soporta no resulta trivial ni intuitivo, especialmente para desarrolladores inexpertos. Esta complejidad se debe fundamentalmente a la complejidad de los modelos asociados (gmfgraph, gmftool y gmfmap) y la cantidad de pasos que se deben llevar a cabo de forma secuencial y siguiendo un orden concreto. Otro problema inherente a GMF es su respuesta ante la evolución del metamodelo del DSL. En estos casos, dependiendo de la naturaleza de los cambios, es muy probable que sea necesario volver a generar y refinar el modelo de correspondencias, ya que los cambios realizados durante el refinamiento no fueron almacenados durante el proceso. Igualmente, conviene mencionar que la documentación disponible no es mucha y sobre todo, la complejidad y opacidad del código generado, que dificulta la tarea de modificarlo cuando se quiere que el diagramador soporte funcionalidades alejadas de las tradicionales GenGMF GenGMF [4] es una herramienta construida sobre EMF y GMF, cuya base teórica es la idea de que en muchos casos las representaciones de los distintos elementos varían en pequeños detalles, como por ejemplo el color, provocando que el desarrollador tenga que definir cada una de esas representaciones de forma independiente, dando lugar a modelos de gran tamaño y con información duplicada. Para solventar este problema GenGMF propone utilizar un nuevo modelo denominado gengmf. El objetivo de este modelo es definir ISSN SISTEDES

32 plantillas que contendrían la información que comparten diferentes representaciones gráficas y descriptores que realizan un mapeo entre las plantillas definidas, los elementos del metamodelo (ecore) y los elementos que compondrán la paleta de herramientas (gmftool). Tal como muestra la Figura 2, a partir de este nuevo modelo se genera de forma automática el modelo gráfico (gmfgraph) y el modelo de correspondencias (gmfmap). Así, el nuevo modelo introducido es una forma de guiar la generación del modelo de correspondencias, que es probablemente el más importante de todo el proceso de desarrollo. GMF Project Domain Model 1 2 EMF Generator Model EMF Project 3 EMF editor (tree-like).ecore.genmodel.gengmf GenGMF Model Tooling Model Graphical Model.gmfmap GMF Generator Model 7 Mapping Model 8 GMF editor (diagrammer).gmftool.gmfgraph.gmfgen Ejecución Manual Automático LEYENDA Figura 2. Proceso de Desarrollo de un editor gráfico usando GenGMF Con todo ello, podemos concluir que GenGMF no soluciona los problemas detectados al evaluar GMF, ya que la inclusión del nuevo modelo tan sólo permite automatizar una pequeña parte de todo el proceso. No obstante, GenGMF sí proporciona algunas ideas ventajosas (que de hecho estábamos explotando antes de la aparición de este proyecto) como el empleo de plantillas o la definición de un modelo que contenga información suficiente para generar de forma automática otros modelos implicados en el proceso EuGENia Epsilon es una plataforma para la construcción de DSLs para tareas relacionadas con la gestión de modelos [8] que incluye varios lenguajes para tareas como la transformación (ETL) o la validación de modelos (EVL). A su vez, la base de la plataforma es EOL (Epsilon Object Language), un lenguaje imperativo que permite crear, consultar y modificar modelos EMF. Además de esta familia de lenguajes, Epsilon proporciona varias facilidades para llevar a cabo tareas comunes en el marco de la IDM. Una de ellas es EuGENia, una herramienta para simplificar el desarrollo de editores GMF [3]. A partir del metamodelo ecore, o su especificación textual con Emfatic [6], EuGENia genera automáticamente los modelos gmfgraph, gmftool y gmfmap. Para generar estos modelos, es necesario haber anotado previamente el metamodelo utilizando un conjunto de anotaciones predefinidas. EuGENia utiliza dichas anotaciones para saber cuál queremos que sea la representación gráfica de un elemento concreto o el control correspondiente en la paleta de herramientas. No obstante, un conjunto predefinido de anotaciones no suele ser suficiente para que el editor generado tenga exactamente las características y comportamiento deseados. Por ello, EuGENia es capaz también de procesar tres ISSN SISTEDES

33 ficheros EOL (Ecore2GMF.eol, FixGenModel.eol y FixGMFGen.eol) que permiten personalizar el editor. La Figura 3 resume el proceso de desarrollo para generar un diagramador con EuGENia..ecore Annotated Domain Model 1 2 EMF Generator 3 Model.genmodel Domain Model (EMFATIC) GMF Project EMF Project.emf Synchronize genmodel - ecore 6 EMF editor (tree-like) 5 Graphical Model 4 Customization Models Tooling Model Mapping Model.gmfgraph.gmftool.gmfmap 7 8 GMF 9 Synchronize Generator gmfgen - ecore Model GMF editor (diagrammer).gmfgen Ejecución Manual Automático LEYENDA Figura 3. Proceso de Desarrollo de un editor gráfico usando EuGENia Nótese que los pasos 1, 2 y 3 son los mismos que se detallaban al hablar de GMF. 4. Definir los ficheros de personalización codificados en lenguaje EOL. 5. Generar, a partir del modelo ecore y los ficheros de personalización, los modelos GMF (gmfgraph, gmftool y gmfmap). 6. Sincronizar los modelos ecore y genmodel. 7. Generar, a partir del modelo de mapeo, el modelo generador de GMF (gmfgen). 8. Sincronización de los modelos ecore y gmfgen. 9. Generar el código Java que implementa el diagramador. Así, EuGENia no sólo reduce el número de modelos que debe definir el desarrollador, sino que, además permite la reutilización de los ficheros de personalización (o al menos parte de ellos) en diferentes desarrollos. Sin embargo, a pesar de estas mejoras el proceso de generación no es completamente automático, pues el desarrollador sigue siendo el encargado de generar el editor tree-based de EMF, el modelo generador de GMF (GMFgen) y el código Java que implementa el diagramador. Además, el uso de Eugenia añade dos nuevas tareas al proceso: la sincronización de los modelos genmodel y gmfgen con el metamodelo ecore. No obstante, las mejoras aportadas por EuGENia sirven de base para la propuesta de este trabajo. 3. Kybele GMF Generator En las secciones anteriores se ha planteado la importancia de automatizar el proceso de desarrollo de diagramadores en el contexto de la IDM y se han mostrado algunas de las herramientas que han surgido para soportar esta tarea. Igualmente, en el marco de trabajos anteriores a la aparición de GenGMF habíamos identificado ya esta necesidad, empezando a trabajar para dar respuesta al problema [13]. En esta tercera sección presentamos KybeleGMFgen (Kybele GMF Generator), nuestra contribución para soportar la generación automática de diagramadores para modelos EMF. ISSN SISTEDES

34 Nuestra solución, que está basada en GMF y Eugenia, pretende explotar las ventajas proporcionadas por estas herramientas y solucionar su principal desventaja, que no es otra que el número de tareas que el desarrollador debe realizar manualmente. Reducción del número de tareas a realizar por el desarrollador. A través de menús contextuales, EuGENia proporciona un conjunto de lanzadores para llevar a cabo las tareas 5, 6 y 8 de la Figura 3, mientras que GMF proporciona lanzadores para las tareas 7 y 9. La primera mejora que propone KybeleGMFgen es recoger la funcionalidad de estos cinco lanzadores en un único lanzador, de forma que podamos aprovechar las ventajas que proporciona la herramienta de Epsilon mientras reducimos los pasos a seguir para generar el diagramador. El siguiente paso para aumentar el grado de automatización del proceso pasa por liberar al usuario de las tareas relativas al desarrollo del editor tree-based de EMF. Para ello, bastará con que la herramienta realice de forma automática las tareas 2 y 3. Con todo, el proceso de generación de un diagramador GMF utilizando KybeleGMFGen se reduce a los tres pasos mostrados en la Figura 4..emf Domain Model (EMFATIC) 1.genmodel EMF Generator Model GMF Project Synchronize genmodel - ecore EMF editor (tree-like) Domain Model (ECORE).ecore Annotated 1 OR 3 Graphical Model Tooling Model.gmfgraph.gmftool Mapping Model 2.gmfmap Customization Models Synchronize gmfgen - ecore GMF Generator Model.gmfgen GMF editor (diagrammer) Ejecución Manual Automático LEYENDA Figura 4. Proceso de Desarrollo de un editor gráfico usando Kybele GMF Generator 1. Definir el metamodelo del DSL 2. Codificar los ficheros de personalización EOL 3. Generar el código que implementa el editor tree-based de EMF y el diagramador GMF (así como los modelos intermedios) utilizando el lanzador de KybeleGMFgen Además, el proceso de generación con KybeleGMFGen también puede partir de la especificación textual del metamodelo con Emfatic, pero al contrario que sucede en Eugenia, no es necesario generar el metamodelo ecore antes de lanzar la generación de los editores. La herramienta detecta automáticamente el tipo de modelo sobre el cual se invoca el lanzador y en caso de tratarse de un fichero con extensión.emf (Emfatic) genera de forma automática el modelo ecore Caso de Estudio Como caso de estudio (descargable desde amples/oracle10g_dsdm2010/), esta sección muestra el uso de KybeleGMFGen para la generación de un diagramador para una versión muy simplificada del DSL para el modelado de ISSN SISTEDES

35 Bases de Datos Objeto-Relacionales en Oracle 10g presentado en [12]. En particular se obtiene un diagramador para modelar tipos estructurados y tablas tipadas, de acuerdo al metamodelo (a) mostrado en la parte izquierda de la Figura 5 (nótese que alternativamente podíamos haber partido de la especificación textual del metamodelo con Emfatic). (b) Figura 5. (a) Metamodelo simplificado para modelado de BDOR en Oracle 10g (b) Vista parcial del metamodelo anotado Una vez definido el metamodelo, añadimos un conjunto de anotaciones GMF para dirigir el proceso de generación tal como muestra la parte derecha de la Figura 5. Por ejemplo, indicamos que la representación de los objetos Model será el diagrama completo y que los objetos Structured Type y TypedTable se representarán como nodos en el diagrama, que incluirán unas etiquetas, etc. En este punto podríamos generar directamente el diagramador, pero obtendríamos un editor muy simple que solo permitiría dibujar cajas que representaran tipos estructurados y tablas tipadas. Para obtener un editor más complejo codificamos los ficheros de personalización (Ecore2GMF.eol, FixGenModel.eol y FixGMFGen.eol). En este caso, utilizaremos el fichero Ecore2GMF.eol para definir algunos elementos gráficos, configurar la paleta de herramientas y especificar las correspondencias entre los elementos de los modelos GMF. Para facilitar la tarea de codificar ficheros de personalización hemos elaborado una librería de operaciones comunes que se recogen en el fichero Operations.eol y proporciona operaciones como la creación de etiquetas con un formato predefinido para representar estereotipos; inserción de compartimentos; inclusión de controles en la paleta de herramientas; definición de correspondencias, etc. La Figura 6 muestra una pequeña parte del fichero de personalización utilizado en el caso de estudio. Figura 6. Fichero de Personalización Ecore2GMF.eol ISSN SISTEDES

36 En particular, las líneas 22 a 36 muestran cómo se personaliza la representación gráfica de los tipos estructurados. Para ello se crea la etiqueta newlabel que contendrá el estereotipo <<udt>> (createstereotypelabel) y los rectángulos udt_rec1 and udt_rec2 donde se alojarán los compartimentos asociados a los atributos y métodos del tipo estructurado. (a) Una vez codificado el fichero de personalización, invocamos la generación automática que soporta KybeleGMFgen, invocando la opción Generate GMF editor code desde el menú contextual del metamodelo ecore (Figura 7 (a)). La herramienta informará sobre el resultado del proceso y a partir de ese momento podemos utilizar el nuevo diagramador, tal como muestra la Figura 7 (b). (b) Figura 7. (a) Invocación de la generación con KybeleGMFgen. (b) Ejemplo de uso del diagramador 4. Conclusiones y Trabajos Futuros En este trabajo hemos revisado las propuestas existentes para soportar el desarrollo dirigido por modelos de diagramadores para modelos EMF. En dicha revisión nos hemos centrado en estudiar el proceso de desarrollo que soporta cada una, constatando que eran susceptibles de mejora en cuanto al nivel de automatización. Así, hemos presentado KybeleGMFGen, una propuesta basada en algunos de los trabajos analizados que implementa dicha mejora, incrementando notablemente el nivel de automatización. Finalmente hemos mostrado su utilización mediante un caso de uso sencillo. La herramienta es totalmente operativa y se puede descargar desde: Update-Site: UpdateSite SVN (Código Fuente): Al automatizar completamente el proceso de generación del diagramador evitamos tener que reconciliar los cambios introducidos en nuevas versiones del metamodelo con los modelos GMF intermedios que dirigen el proceso de generación. Usando KybeleGMFGen introducimos los cambios en el metamodelo y lanzamos la generación. Como todas las opciones de personalización están codificadas en los ficheros EOL, el trabajo de personalización del editor no se perderá. De hecho, al regenerar el editor, se ejecutan de nuevo los ficheros EOL, aplicando todas las opciones de personalización sobre la nueva versión del diagramador, funcional para la nueva versión del metamodelo. No obstante, aunque la herramienta permite automatizar aproximadamente un 80% del proceso de desarrollo, no exime al desarrollador de conocer EMF y GMF si desea obtener diagramadores con funcionalidades muy concretas. Aunque podría ayudarse de otras herramientas para tal fin. Por ejemplo, si quisiera incluir soporte para validar los modelos elaborados con el diagramador, podría utilizar EVL (Epsilon Validation Language) para definir restricciones sobre el metamodelo del DSL, que luego se comprobarían sobre los modelos terminales. Por otro lado, tal y como hemos mencionado, se ha optado por construir una librería de operaciones típicas de personalización que puede invocarse luego desde cualquier fichero EOL. De esta forma se favorece la reutilización y se simplifica la tarea de personalización. De hecho, la primera dirección que se plantea para trabajo futuro es la definición de un conjunto de plantillas básicas, que junto a una API para utilizar las librerías de personalización, faciliten al desarrollador la definición de personalizaciones ad-hoc. ISSN SISTEDES

37 La otra dirección en la que ya hemos empezado a trabajar pasa por eliminar las anotaciones GMF del metamodelo, pues dichas anotaciones están contaminando el metamodelo con información que no es propia del dominio que representa. Así, estamos empezando a utilizar modelos de weaving como modelos de anotación. Adicionalmente, trabajando de esta forma podemos definir diferentes modelos de anotación para un mismo metamodelo, lo que permitirá generar distintos editores (es decir, distintas representaciones) para un mismo metamodelo sin ningún esfuerzo adicional. Agradecimientos Este trabajo se ha realizado en el marco de los siguientes proyectos: MODEL-CAOS (TIN /TIN), AGREEMENT-TECHNOLOGY (CSD ) financiados por el Ministerio Español de Educación y Ciencia, el proyecto IDONEO (PAC ) financiado por la Consejería de Ciencia y Tecnología de la Junta de Comunidades de Castilla-La Mancha y el subprograma de Personal Técnico de Apoyo (MICINN- PTA ), perteneciente al Programa Nacional De Contratación e Incorporación de RRHH cofinanciado por el Ministerio de Ciencia e Innovación. Referencias [1] Atkinson, C., & Kuhne, T. (2003). Modeldriven development: a metamodelling foundation. IEEE Software, 20(5). [2] Bézivin, J., Büttner, F., Gogolla, M., Jouault, F., Kurtev, I., & Lindow, A. (2006). Model Transformations? Transformation Models! 9th International Conference on Model Driven Engineering Languages and Systems, MoDELS 2006, Genève, Italy. [3] EuGENia GMF Tutorial. s/eugenia-gmf-tutorial/ [4] GenGMF Blog: [5] Gronback, R. C. (2009). Eclipse Modeling Project: A Domain-Specific Language (DSL) Toolkit: Addison-Wesley Professional. [6] IBM. (2004). Emfatic Language for EMF Development. [7] Irrazábal, E. Vara, J.M, Bollati, V. & Marcos, E. Gestión de Tipos Primitivos en propuestas de DSDM. Taller de Desarrollo de Software Dirigido por Modelos (DSDM 2009). [8] Kolovos, D., Paige, R., Rose, L., & Polack, F. (2008). The Epsilon Book. [9] Schmidt, D. C. (2006). Model Driven Engineering. IEEE Computer, Vol. 39, No. 2, pp [10] Selic, B. (2008). MDA Manifestations. UPGRADE, IX(2), [11] Steinberg, D., Budinsky, F., Paternostro, M., & Merks, E. EMF: EclipseModelling Framework, 2 nd Edition. Addison-Wesley Proffesional [12] Vara, J. M., Vela, B., Bollati, V., Marcos, E. (2009). Supporting Model-Driven Development of Object-Relational Database Schemas: a Case Study. ICMT2009, Zurich, Switzerland. [13] Vara, J. M. (2009). M2DAT: A Technical Solution for Model-Driven Development of Web Information Systems. Ph.D. Thesis. Universidad Rey Juan Carlos, Madrid. [14] Van Gorp, P. (2008). Model-Driven Development of Model Transformations. Paper presented at the 4th International Conference on Graph Transformations ICGT 2008, Leicester, United Kingdom ISSN SISTEDES

38 Ingeniería inversa de eventos GUI en aplicaciones RAD mediante MDD Óscar Sánchez Ramón Jesús Sánchez Cuadrado Jesús García Molina Facultad de Informática Facultad de Informática Facultad de Informática Universidad de Murcia Universidad de Murcia Universidad de Murcia Resumen La migración del código de manejo de eventos de la interfaz gráca de usuario (GUI) es uno de los retos que deben afrontarse cuando se aborda la modernización de un sistema heredado desarrollado con un entorno Rapid Application Development (RAD). Esta tarea conlleva varias dicultades, pues frecuentemente implica un cambio de lenguaje de programación o tecnología, y un cambio en la arquitectura del sistema, dado que las aplicaciones desarrolladas en entornos RAD no contemplan una separación de la arquitectura en capas. En este trabajo proponemos una aproximación MDD para realizar ingeniería inversa de los eventos GUI de aplicaciones RAD, con el objetivo de obtener información acerca del código original que sea de utilidad para un posterior proceso de rediseño e ingeniería directa. 1. Introducción En la actualidad existe un gran número de aplicaciones heredadas que fueron construidas con entornos RAD (Rapid Application Development), tales como Oracle Forms 6 o Borland Delphi 5, y que están siendo migradas a plataformas más modernas. Estas migraciones son realizadas manualmente en la mayoría de los casos. Recientemente ha emergido la Modernización Dirigida por Modelos, como forma de conseguir automatizar las tareas propias de los procesos de evolución de software a través de la aplicación de las técnicas básicas del Desarrollo Dirigido por Modelos (Model Driven Development, MDD). Cuando se realiza una migración entre plataformas, es necesario considerar todos los componentes de la arquitectura software de la aplicación existente. El componente relacionado con interfaz gráca de usuario (GUI) es fundamental en la mayoría de arquitecturas, y su migración requiere considerar varios aspectos, como la disposición de los controles grácos (layout) y el manejo de eventos. El primer aspecto se ha tratado en un trabajo previo [1], y este trabajo se centrará en el segundo aspecto en el contexto de la migración de aplicaciones RAD. Las tecnologías de desarrollo de GUI utilizan modelos de eventos para permitir la interacción del usuario con la aplicación (por ejemplo, en Java la librería Swing usa el Modelo de Delegación de Eventos). En el caso de la tecnología RAD, el modelo de eventos es simple y normalmente y los manejadores de evento se asocian directamente a los componentes. Sin embargo, cada entorno dene un conjunto de eventos propios, y el lenguaje y las facilidades de que se dispone para denir las acciones asociadas son dependientes de la tecnología. Una característica de los entornos RAD es que el código de los eventos puede interaccionar directamente con una base de datos, sin necesidad de invocar a funciones de la lógica de negocio que se encarguen de dicha tarea. Esto supone un problema cuando pretendemos abordar la modernización de este código, dado que hoy en día es una práctica habitual separar las aplicaciones en capas con el n de facilitar el mantenimiento, legibilidad y extensibilidad de la aplicación. ISSN SISTEDES

39 DECLARE DECL n Number; DECL val VARCHAR2(50); BEGIN n := 1; SELECT value INTO val FROM mappings Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 2, 2010 Refinamiento DECLARE DECL n Number; DECL val VARCHAR2(50); BEGIN n := 1; SELECT value INTO val FROM mappings M2M Código Fuente (PL/SQL) T2M Modelo de Código (PL/SQL) M2M Modelo Abstracto de Eventos Usuario Patrones conformes al DSL Repositorio de patrones (patrones Forms) M2M Figura 1: Arquitectura para realizar ingeniería inversa de eventos de GUI Es deseable, por tanto, analizar los eventos de GUI y disponer de una representación de los mismos que sea independiente de entornos, lenguajes y tecnologías, que pueda ser fácilmente estructurada en capas, y que en denitiva contenga toda la información que sea posible deducir del código fuente con el objetivo de automatizar los procesos de generación de nuevas aplicaciones en la mayor medida posible. Por tanto, el propósito de este trabajo es mostrar una aproximación de Modernización Dirigida por Modelos para aplicar ingeniería inversa de los eventos de aplicaciones RAD destinada a facilitar la migración a otras plataformas, lo que nos permitirá la automatización total o parcial del proceso. Se propone una representación independiente del lenguaje para el código de manejo de eventos, y un DSL para establecer la correspondencia entre patrones código y tal representación. También, se describen varias usos de esta representación al automatizar la ingeniería inversa. La sección 2 se muestra una visión general de la arquitectura de modelos para realizar el proceso de ingeniería inversa. La sección 3 muestra el metamodelo empleado para representar la información extraída de los eventos, en la sección 4 se describe el DSL de patrones, y en la sección 5 se describen varios ejemplos de aplicación. Las secciones 6 y 7 nalizan presentando respectivamente el trabajo relacionado, y las conclusiones y trabajo futuro. 2. Visión general de la arquitectura La arquitectura de modelos propuesta para realizar el proceso de ingeniería inversa del código de manejo de eventos en aplicaciones RAD se muestra en la Figura 1. Aunque esta arquitectura esta orientada a la extracción del comportamiento de los eventos de Oracle Forms y PL/SQL, el esquema puede ser generalizado para otras tecnologías RAD. En primer lugar, partimos de código de la aplicación RAD original, código PL/SQL de Oracle Forms en nuestro caso. El código se inyecta en un modelo que lo representa mediante una transformación texto a modelo(t2m ), y que conformará con un metamodelo de la sintaxis abstracta de PL/SQL. El segundo paso consiste en obtener el modelo abstracto de eventos, que se utiliza para: i) representar el código fuente de forma independiente a lenguajes y tecnologías, mediante acciones habituales en los entornos RAD (como por ejemplo leer de la interfaz o escribir en base de datos), y ii) eliminar detalles que son superuos para analizar el comportamiento de los eventos. La obtención de un modelo abstracto de eventos a partir del modelo de código PL/SQL se consigue mediante una transformación modelo a modelo (M2M). Como explicaremos más adelante, a su vez esta ISSN SISTEDES

40 0..n 0..n RADVariable 1 ModelRoot RADReadable 1 0..n 0..n in 0..1 out 0..n 1 EventDefinition + targetelement 0..n 1 0..n RADAction UIVar DBVar TempVar PredefinedVar ReadFromDB WriteToUI ManipulateData ControlFlow Figura 2: Metamodelo abstracto de eventos transformación se obtiene automáticamente a través de otra transformación modelo a modelo que toma como entrada un modelo que representa un conjunto de patrones que establecen reglas para construir el modelo abstracto de eventos a partir del modelo de código. La siguiente etapa del proceso consiste en renar el modelo abstracto de eventos. El objetivo es inferir información adicional acerca de los eventos, y representarla de forma explícita en el propio modelo abstracto de eventos. A partir del modelo renado es posible realizar diversas tareas de reingeniería, como generar informes y visualizaciones, restructurar el código o generar esqueletos de código (automatización parcial de la migración). La infraestructura se está desarrollando en la plataforma Eclipse, utilizado Ecore como lenguaje de metamodelado, Gra2MoL [3] para inyectar código PL/SQL en modelos, y RubyTL [4] para realizar las transformaciones modelo a modelo. 3. Representación de los eventos a alto nivel El modelo abstracto de eventos se utiliza para representar los eventos GUI a alto nivel. Tiene dos características principales: permite representar las acciones de los eventos con independencia de lenguajes y tecnologías, y omite detalles que no son relevantes para analizar el comportamiento del evento (por ejemplo cuál es la funcionalidad concreta de una operación de tratamiento de enteros), con lo cuál se simplica el posterior análisis de los mismos. En la Figura 2 se muestra de forma simplicada el metamodelo al que conforman los modelos abstractos de eventos. Principalmente distinguimos dos elementos en el metamodelo: variables (RADVariable) y acciones (RADAction). Las primeras son los datos que el evento maneja, mientras que las segundas son primitivas que utilizan esos datos. En base a la proveniencia de los datos tendremos los siguientes tipos de variables: Variables temporales (TempVar), que son variables locales a los eventos y que se utilizan para almacenar datos que resultan de lecturas y manipulaciones de datos. Variables predenidas (Predened- Var), son variables globales que tienen una semántica predenida en un entorno o tecnología. Variables de interfaz (UIVar), que representan los controles de la interfaz gráca. Variables de base de datos (DBVar), que representan un recurso que permite interaccionar con una base de datos, como puede ser un origen de datos. Igualmente, distinguimos diferentes tipos de primitivas para representar acciones. En el ISSN SISTEDES

41 Primitiva ReadFromUI WriteToUI WriteToVar ReadFromDB ModifyUI ManipulateData SelectionFlow ShowMessage Invoke Signicado Lee un valor de un control de la GUI Modica un valor de un control de la GUI Escribe un valor en una variable temporal Lee valores de base de datos Modica atributos grácos de los controles de la GUI Realiza una operación sobre datos, por ejemplo, la obtención de una subcadena en base a una cadena Control de ujo selectivo Muestra una ventana modal emergente Invoca a una función o procedimiento Cuadro 1: Primitivas semánticas cuadro 1 se muestran algunas de las primitivas identicadas. Las primitivas se aplican sobre una o más variables de entrada, y si se trata de una operación de escritura, tendrán una variable de salida asociada (referencia out). Además, como se observa en el metamodelo, la entrada de una primitiva (dependencia in entre RADAction y RADReadable) puede ser otra primitiva, lo que permite componer las primitivas para expresar acciones más complejas de un modo más compacto, esto es, sin necesidad de utilizar variables temporales para almacenar el resultado de otras primitivas. Esta representación mantiene, en cierta medida, la estructura del código original lo que facilitará análisis de grano grueso. Otras representaciones más atómicas (como SSA [9] [10]) son útiles para análisis de grano no, y serán consideradas en futuros trabajos. Estas primitivas conforman un subconjunto básico suciente para comprender la funcionalidad del evento a alto nivel. Sin embargo, si en fases posteriores del proceso de modernización pretendemos generar código a partir de los eventos, necesitamos anar más en la especicación de algunas de las primitivas para incluir información más detallada. Por ejemplo, sería necesario modelar las condiciones de las primitivas de control, o la funcionalidad de las primitivas de manipulación de datos. Con el objetivo de representar toda la información del sistema original, en un futuro se evaluará la posibilidad de relacionar el metamodelo abstracto de eventos con el metamodelo de la tecnología fuente, ya sea mediante un metamodelo propio que represente el código de forma independiente de la plataforma, o utilizando un metamodelo estándar como KDM [7] para este n. El elemento ModelRoot actua como raíz del metamodelo, y contiene los eventos (EventDefinition), así como las variables globales a los éstos, de modo que las variables de interfaz, las de base de datos y las predenidas puedan ser reutilizadas. La metaclase EventDenition tiene un nombre, un tipo de evento, está asociada al elemento targetelement que dispara el evento (normalmente un control de la interfaz), y contienen las variables y acciones que denen el comportamiento a realizar cuando se activa el evento. 4. Abstracción de código mediante un DSL de patrones Para obtener el modelo abstracto de eventos a partir del modelo de código fuente, la aproximación directa sería crear una transformación modelo a modelo. Sin embargo, este enfoque presenta dos problemas fundamentales: a) el codigo de la transformación sería muy verboso, b) incorporar nuevos casos de análisis implicaría modicar la transformación. Para superar estas desventajas, se ha diseñado un DSL para establecer correspondencias entre patrones de código PL/SQL y primitivas del modelo abstracto de eventos. La dinámica consiste en aplicar los patrones sobre el código de los manejadores de eventos del sistema heredado, de modo que para ca- ISSN SISTEDES

42 «from PL/SQL» Statement source 1..n FormsPattern target 1..n «from SemanticActions» RADAction «from PL/SQL» Statement GenericStatement «from PL/SQL» Expression GenericExpression +vargroup: string «from PL/SQL» Variable GenericVariable +id: string +pattern: RegExpr «Datatype» OpType AND OR «from EventAbstractMM» RADVariable RegExpr GenericVariable +id: string GenericVarGroup +id: string SimpleRegExpr +not: boolean +expr: string CompositeRegExpr +operator: OpType 1..n Figura 3: Metamodelo de la sintaxis abstracta del DSL de patrones. da patrón concordado se genera un fragmento de código de primitivas de alto nivel. Cuando existan varios patrones posibles, se informará al desarrollador para que seleccione una de las alternativas, siendo por tanto un proceso semiautomático. Con el objetivo de denir los patrones de forma concisa, se pretende que una sola sentencia del DSL empareje con un trozo de modelo de sintaxis abstracta mediante el uso de comodines (por comodin entendemos un elemento que permite emparejar una parte cualquiera del modelo de código). Además, se ha decidido extender la propia sintaxis de PL/SQL para facilitar la escritura de los patrones, pues es menos verboso que utilizar la sintaxis abstracta. Para facilitar la extensibilidad se ha denido un repositorio de patrones (escritos con el DSL). Así, es posible incorporar de un modo sencillo nuevos patrones que sean dependientes de las convenciones de las empresas de desarrollo, sin necesidad de modicar las transformaciones. Se observa que tanto el DSL y el repositorio de patrones son dependientes de la tecnología origen del proceso de modernización. En el futuro se pretende separar la compilación de los patrones de la sintaxis concreta utilizada, con el n de usar el mismo compilador con diferentes lenguajes. El DSL de denición de patrones podría ser generado automáticamente a partir de la gramática, lo que evitaría tener que realizar un DSL manualmente para cada tecnología origen. La sintaxis abstracta del DSL corresponde al metamodelo que aparece en la Figura 3. El metamodelo hace corresponder un conjunto de sentencias PL/SQL con un conjunto de primitivas. Este metamodelo tiene referencias cruzadas con el metamodelo de PL/SQL, de modo que las metaclases Statement, Expression y Variable representan sentencias, expresiones y variables de PL/SQL respectivamente. En ocasiones ocurre que para denir los patrones necesitamos especicar que algunos elementos de un trozo de código no son relevantes. Por esta razón, las metaclases Generic- Statement, GenericExpression y GenericVariable han sido denidas para actuar como comodines al expresar los patrones. Generic- Variable puede tener un identicador (id) para referirse a la misma variable en otra parte del ISSN SISTEDES

43 Patrón PL/SQL (parte izquierda) IF GenericExpression(varGroup=V) THEN statements END SELECT - INTO GenericVariable(id=X, pattern=:*.* AND NOT :system.*) FROM - WHERE GenericExpression(varGroup=V) GenericVariable(id=X, pattern=not :*) := GenericVariable(id=Y) GenericVariable(pattern=':*.*' and not ':system.*') Primitivas (parte derecha) SelectionFlow(GenericVarGroup(id=V)) { statements } WriteToUI(ReadFromDB( GenericVarGroup(id=V)), GenericVariable(id=X)) WriteToVar(GenericVariable(id=Y), GenericVariable(id=X)) UIVar Cuadro 2: Ejemplos de reglas del DSL de patrones, con la sintaxis de PL/SQL. patrón y/o en la parte derecha de la regla (nótese que con id no nos estamos reriendo al nombre de un variable concreta del código PL/SQL). Mediante el atributo pattern también es posible especicar aquellas variables cuyo nombre cumple con una determinada expresión regular. La metaclase GenericExpression reemplaza a cualquier expresión, y utiliza el atributo vargroup para especicar el identicador del grupo de variables que se usan en la expresión (de manera que pueda utilizarse en la parte derecha de la regla). Respecto al metamodelo abstracto de eventos se denen dos tipos nuevos, GenericVarGroup y GenericVariable que representan a las variables y grupos de variables respectivamente, que se han identicado en el modelo PL/SQL. En el cuadro 2 se muestran algunos de los patrones establecidos para la tecnología Oracle Forms. Para facilitar la comprensión de los mismos se utiliza una sintaxis más verbosa que corresponde directamente con el metamodelo del DSL. El primer patrón transforma una sentencia IF en una sentencia de control de ujo de selección (SelectionFlow). El elemento GenericExpression se utiliza para representar cualquier expresión, pues no nos interesa un tipo de expresión en concreto, aunque sí que nos interesan el conjunto de variables que se utilicen en dicha expresión, a las cuales identicaremos como V. El segundo patrón representa una consulta SELECT de base de datos que escribe en una variable. De momento no estamos interesados en almacenar el nombre de la tabla y los atributos, razón por la cuál en el patrón se especica un guión para ignorarlos. Se especica que la variable (que identicaremos por X ) en la que se almacene el resultado de la consulta debe concordar con un patrón, que concretamente es un patrón que dene las variables que se reeren a controles GUI. Por esta razón, este patrón se traduce como una lectura de base de datos (ReadFromDB) que se escribe en una variable de interfaz (WriteToUI). El tercer patrón traduce una asignación de una variable de cualquier tipo a una variable local. El cuarto patrón se utiliza para resolver variables de interfaz. Cuando se aplica un patrón, puede ocurrir que la parte derecha de la regla se reera a GenericVarGroup o Generic- Variable. En estos casos es necesario aplicar otras reglas para resolver estas partes. Por ejemplo, es necesario traducir los tipos GenericVariable del modelo abstracto de eventos en tipos de variables concretas (UIVar, Temp- Var,...). Por esta razón es necesario especicar patrones (como por ejemplo el cuarto patrón) para resolver estos casos. Vamos a ilustrar el proceso de aplicación de los patrones mediante un ejemplo. En el entorno Oracle Forms 6 se pueden asociar disparadores PL/SQL a la ejecución de un conjunto predeterminado de eventos. A continuación se muestra el código de un disparador asociado al evento WHEN_VALIDATE_ITEM del campo de texto USERNAME, que se ejecuta cuando se produce un cambio en el campo de texto. ISSN SISTEDES

44 1 DECLARE 2 name VARCHAR2 (50) ; 3 BEGIN 4 name := : USER_DATA. USERNAME ; 5 IF name IS NOT NULL THEN 6 SELECT INTO : USER_DATA. 7 FROM User WHERE username = name ; 8 END IF ; 9 END ; En la línea 4 se copia el contenido del campo de texto USERNAME a la variable local name. Se comprueba que esta cadena de caracteres no sea nula (línea 5), y de ser así se obtiene el valor de la la de la tabla de datos User cuyo nombre de usuario (username) coincida con el valor de la variable name. El valor obtenido de base de datos se almacena en el campo de texto . El efecto del código es el siguiente. Cuando un usuario introduce el nombre de usuario en el campo de texto USERNAME, la aplicación busca la dirección de correo electrónico asociada a dicho usuario, y la muestra en el campo de texto . Si aplicamos el conjunto de patrones denidos en el cuadro 2 al modelo PL/SQL antes descrito, se obtiene el siguiente modelo. Por simplicidad se han omitido algunos detalles de las primitivas, como la información relativa a la base de datos de la primitiva ReadFromDB, o la condición del SelectionFlow. Para cada conjunto de primitivas, se indica la línea o líneas que las originaron mediante la aplicación de los patrones y reglas. 1 WriteToVar (: USER_DATA. USERNAME, name ) /* línea 4 */ 2 SelectionFlow ( name ){ /* línea 5 */ 3 WriteToUI ( ReadFromDB (name ), : USER_DATA. ) /* líneas 6 y 7 */ 4 } planteamos dos posibles usos de esta representación que tienen como objetivo inferir información implícita: la búsqueda de dependencias entre variables y la categorización de fragmentos de código. Las dependencias entre variables de interfaz (que representan controles) pueden ser una fuente de información útil en el proceso de comprensión del comportamiento de los eventos. En las interfaces de usuario frecuentemente ocurre que un cambio en el valor de un control de la interfaz afecta a otro control. Por ejemplo, imaginemos una casilla de veri- cación que cuando es marcada, habilita una lista desplegable que antes estaba deshabilitada. En este ejemplo, los controles vendrían representados por variables de interfaz, de modo que existiría una dependencia entre la variable asignada a la casilla de vericación y la variable que representa la lista desplegable. Esta información puede ser interesante para determinar dependencias entre eventos, pues un evento E 1 que estuviese asociado a una variable de interfaz V 1 podría activar la ejecución de otro evento E 2 asociado a la variable de interfaz V 2 si V 2 depende de V 1. Es posible asociar automáticamente categorías a fragmentos de código a partir de la información de grano no sobre variables y acciones obtenida en el modelo abstracto de eventos. En la actualidad estamos diseñando un algoritmo que recorre el modelo buscando secuencias de sentencias que tienen la misma naturaleza(ui, base de datos, etc.) y las agrupa. Esta información puede ser a su vez utilizada para dividir la aplicación original en capas, ya que cada fragmento de código de cierta naturaleza puede ser asignado a la UI, al controlador, o a la lógica de negocio. 5. Usos del modelo abstracto de eventos El modelo abstracto de eventos pretende ser una representación de información sobre los eventos adecuada, que está implícita en el código fuente y que puede ser de utilidad en una fase posterior de ingeniería directa para crear un nuevo sistema. A continuación 6. Trabajo relacionado En el trabajo [2] se presenta una herramienta comercial que migra aplicaciones Oracle Forms a la plataforma.net. Los eventos de la plataforma origen para los cuales existe una correspondencia con semántica similar en la plataforma destino se migran directamente, mientras que el resto deben ser asistidos por ISSN SISTEDES

45 el usuario. En [5] se aborda la evolución de sistemas heredados a sistemas SOA en tres capas. En esta propuesta los fragmentos de código original se anotan manualmente según el aspecto con que se relaciona (interfaz, lógica de negocio o datos). La arquitectura presentada permitirá automatizar estas anotaciones, como se comenta en la sección anterior. En [6] se propone la reingeniería inversa de interfaces de usuario con el objetivo de realizar pruebas de interfaz. En este trabajo se utiliza un modelo de ujo de eventos que representa todos las caminos de ejecución de eventos posibles a partir de las ventanas de la aplicación. La reingeniería se centra en deducir las relaciones entre ventanas originadas por eventos. Existen numerosos trabajos relativos al estudio del ujo de datos [8], [9] que se utilizan en la optimización de código por parte de compiladores. Estos trabajos proponen el análisis estático de código, más especícamente Single Static Assignment Form (SSA) así como otras técnicas, con el objetivo de eliminar código redundante y optimizar la asignación de variables. En [10] se utiliza SSA para obtener un grafo de ventanas, que es un grafo que representa las relaciones entre las ventanas de una GUI. Estos trabajos guardan cierta relación con las etapa de simulación y con el análisis de variables, sin embargo en nuestro caso, el análisis que realizamos es más sencillo y está orientado especícamente al código de eventos de GUI. 7. Conclusiones y trabajo futuro En este trabajo hemos presentado una aproximación para analizar el código de los eventos de la GUI de aplicaciones RAD. Como resultado de este análisis se obtiene una representación de alto nivel con información útil para la comprensión de dichos eventos. La información recopilada puede ser utilizada posteriormente para efectuar un proceso de ingeniería directa con el objetivo de generar un nuevo sistema o de reingeniería para modicar el sistema existente. Se evaluará la posibilidad de representar el sistema original completo mediante KDM [7], de modo que el modelo abstracto de eventos mantenga referencias al modelo KDM. Como trabajo futuro, se espera probar el proyecto con casos de estudio reales. Como fruto de dicho trabajo, se incorporarán nuevas primitivas de alto nivel y se renará y ampliará el conjunto de patrones identicados e incluidos en el repositorio estándar. Se modicará también la arquitectura para que sea independiente de la tecnología origen en la medida de lo posible. También sería posible realizar generadores de DSLs de denición de patrones a partir de gramáticas. Agradecimientos Este artículo ha sido parcialmente nanciado por la Consejería de Universidades, Empresa e Investigación (proyecto 129/2009) y la Fundación Séneca (proyecto 08797/P1/08). Referencias [1] O. Sánchez Ramón, J. Sánchez Cuadrado, and J. García Molina. Model-Driven Reverse Engineering of Legacy Graphical User Interfaces. In Proceedings of the 25th IEEE/ACM International Conference on Automated Software Engineering, ASE'10, [2] L. F. Andrade, J. Gouveia, M. Antunes, M. El-Ramly, and G. Koutsoukos. Forms2net - Migrating Oracle Forms to Microsoft.NET. In GTTSE, pages , [3] J. L. Cánovas Izquierdo and J. G. Molina. A Domain Specic Language for Extracting Models in Software Modernization. In ECMDA-FA '09: Proceedings of the 5th European Conference on Model Driven Architecture - Foundations and Applications, pages 8297, Berlin, Heidelberg, Springer-Verlag. [4] J. S. Cuadrado and J. G. Molina. Modularization of Model Transformations Through a Phasing Mechanism. Software and System Modeling, 8(3):325345, ISSN SISTEDES

46 [5] R. Heckel, R. Correia, C. M. P. Matos, M. El-Ramly, G. Koutsoukos, and L. F. Andrade. Architectural Transformations: From Legacy to Three-Tier and Services. In Software Evolution, pages [6] A. M. Memon. An Event-Flow Model of GUI-Based Applications for Testing: Research Articles. Software Testing Verication and Reliability, 17(3):137157, [7] OMG. Knowledge Discovery Meta-Model (KDM) v [8] B. K. Rosen. Data Flow Analysis for Procedural Languages. J. ACM, 26(2): , [9] B. K. Rosen, M. N. Wegman, and F. K. Zadeck. Global Value Numbers and Redundant Computations. In POPL '88: Proceedings of the 15th ACM SIGPLAN- SIGACT symposium on Principles of programming languages, pages 1227, [10] S. Staiger. Reverse Engineering of Graphical User Interfaces Using Static Analyses. In WCRE '07: Proceedings of the 14th Working Conference on Reverse Engineering, pages , ISSN SISTEDES

47 A Technological Framework to support Model Driven Method Engineering 1 Mario Cervera 1, Manoli Albert 1, Victoria Torres 1, Vicente Pelechano 1, Javier Cano 2, Begoña Bonet 3 1 Centro de Investigación en Métodos de Producción de Software, Universidad Politécnica de Valencia, Valencia, Spain {mcervera, malbert, vtorres, pele}@pros.upv.es 2 Prodevelop S.L Valencia, Spain fjcano@prodevelop.es 3 Conselleria de Infraestructuras y Transporte, Generalitat Valenciana, Valencia, Spain bonet_beg@gva.es Abstract 1. Introduction Over the last two decades many approaches have contributed to establish a solid theoretical basis in the area of Method Engineering, but very few engineering tools have been developed to provide software support to their research results. This situation is mainly due to the complexity of developing Computer-Aided Method Engineering environments that enable the specification of Software Production Methods (SPM) and the construction of CASE tools to support them. In order to reduce this complexity, we advocate for the use of the MDD paradigm, which promotes the use of models as the primary artifact in the development process. Following this paradigm, in this paper we present a Model Driven Method Engineering approach to perform the automatic construction of tools that support SPMs by means of model transformations. This work is contextualized within a more challenging proposal that provides a methodological framework and a software infrastructure for the construction of SPM, covering from their specification to the construction of the tool support. Keywords Method Engineering, Model Driven Development, CAME environment, CASE tool generation. A Software Production Method (SPM) is an integrated set of activities, roles, products, guides and tools for providing efficient and effective support in the software development process. In the Software Engineering (SE) field, CASE environments provide software support to SPMs contributing to improve the software development process in terms of productivity, maintainability, reusability and quality of the developed software. However, despite the benefits that the use of CASE tools provides, these are not used as widely as expected. One of the reasons for this is that CASE tools are implemented to give support to a single SPM, paying no attention to the flexibility required by real software projects. As a result, developers find difficult to work with such tools as they do not allow them to adapt the SPM to the requirements of a specific project [21]. One way to overcome this problem is by reconsidering the way in which these tools are built. The construction of such tools is one of the main concerns of the Method Engineering (ME) discipline. ME is defined as the engineering discipline to design, construct and adapt methods, techniques and tools for the development of IS [2]. Within the ME field, Computer Aided Method Engineering (CAME) environments enable the construction of SPMs and the software tools that support them. However, providing such support is 1 This work has been cofinanced by the Conselleria de Infraestructuras y Transporte by means of the Fondo Europeo de Desarrollo Regional (FEDER) and the Programa Operativo de la Comunitat Valenciana ISSN SISTEDES

48 not an easy task being a clear example the low implementation degree and deficiencies found in existing CAME environments [17]. To improve this situation, in this work we advocate for the use of the MDD paradigm, which proposes using models as the primary artifact of the development process [1], in the ME field. Thus, this work provides a Model Driven Method Engineering approach to perform the construction of tools that support SPMs by means of model transformations. The work is being developed as part of a more challenging proposal [4]. This proposal contributes to the ME area by providing a methodological framework and a software infrastructure for the construction of SPMs. The methodological framework covers from the specification of the SPM to the construction of the tool support. The present work focuses on the last phase of this proposal where software tools are built from SPM specifications. The remainder of the paper is structured as follows. In section 2 we briefly present the state of the art focusing on the limitations of the existing CAME environments. Then, in section 3 we provide a brief overview of the ME proposal in which this work is contextualized. Section 4 presents the strategy designed to automatically obtain software tools to support specific SPMs. Finally, section 5 draws some conclusions and further work. 2. State of the art The first research work in the ME field was developed in the early nineties by Kumar and Welke who established the basis of this area [14]. Later, these foundations have been consolidated with several proposals such as Brinkemmper s [2] and Hofstede s [12]. Since then, different proposals try to provide an answer to the existing problems in this area. This is the case of proposals such as Ralyté s [15, 19], Henderson-Sellers [10], Prakash s [18] or Harmsen s [9] which tackle the method construction by assembling pieces or fragments, proposing techniques for the efficient selection and assembly of these pieces. These proposals have contributed to establish a solid theoretical basis for the ME area. However, the existing tool support for this basis does not live up to the expectations due to the complexity of putting this theory into practice. This problem becomes evident in [17] where a study of different CAME environments is presented. This study concludes that existent environments are incomplete prototypes that only cover part of the ME process. This is one of the reasons why these tools have not achieved the expected industrial success and just MetaEdit+ [13] has been commercialized. Examples of these CAME tools are MERU, which supports Prakash s and Gupta s proposals [7], DECAMERONE, which supports Brinkkemper s [3], MENTOR [22], MERET [11] or KOGGE [21]. These CAME environments, in general, present important deficiencies. Between these deficiencies we highlight: (1) lack of support to the definition of SPMs and (2) lack of support to the automatic generation of CASE tools from the SPM definitions. This situation points out that there is an actual need for tools that provide better support to ME. The problem is the high complexity that entails the construction of these tools as they must provide support both to the SPM specification and the CASE tool generation. In order to overcome this problem some approaches apply the MDD paradigm using metamodelling languages either to define design notations [6] or SPM specifications [11]. However, we find that these approaches do not really take advantage of the possibilities that the MDD techniques offer. As stated in [1], the application of MDD techniques improves developers short-term productivity by increasing the value of primary software artifacts (e.g. the models) in terms of how much functionality it delivers. Following this statement and contrary to what current ME approaches do, we want to leverage models going one step further. Defining the SPM as a model and considering this model as a software artifact allows us to face the implementation of the generation of software support tools by means of model transformations. The use of model transformations as the means to carry out the tool generation is the main concern of this paper and is thoroughly detailed in section ME proposal overview In order to put into context the work presented in this paper, this section briefly introduces the proposal presented in [4]. This proposal covers ISSN SISTEDES

49 different stages of the ME lifecycle, in particular from the specification of the SPM to its implementation (where the tool that supports the SPM is built). Figure 1 presents a graphical overview of the proposal. Each of its phases is detailed in the next subsections Method design During this phase, the method engineer builds the Method Model by identifying all the elements involved in the SPM. The most significant elements used in the Method Model construction are the following: Task: It represents an activity performed during the execution of a SPM instance (e.g. business process analysis, web specification, etc.). Product: It represents an artifact that is either consumed or generated in a task (e.g. business process model, structural model, etc.). Role: It represents an agent that participates in a SPM performing different tasks. This can refer to a human being agent (e.g. analyst, developer, etc.) or to an automated system. Flow Connector: It represents the order in which two associated tasks (each one in a different end) are executed. Gateways: It represents points within the SPM where the flow is diverged or converged depending on the gateway type. Guide: It is a document that provides some assistance to perform a task or to manipulate a specific product. We distinguish two parts in the Method Model, the product part, which represents the artifacts that developers should construct during the execution of a SPM project, and the process part, which consists of the procedures that developers must follow to construct such products. For the construction of the Method Model we provide a Method Base repository. The Method Base contains method fragments (descriptions of IS engineering methods, or any coherent part thereof [8]) that can be reused in the design of new Method Models. It is important to note that the Method Model does not contain details about the languages or technologies that are going to be used during the execution of the SPM; this is done in the next phase. Figure 1. ME proposal overview ISSN SISTEDES

50 Figure 2. Example of method fragment integration Figure 2 shows an example of integration of a method fragment into a Method Model, which in our proposal is created by means of the EPF Composer Editor, a Software Process Engineering Meta-Model (SPEM) [23] editor provided in the EPF Project [5]. The right side of this figure shows an Eclipse view implementing a repository client. Its content represents method fragments that are stored in the Method Base as reusable assets following the RAS (Reusable Asset Specification) standard [20]. Through this view, the method engineer can search for and select method fragments to integrate them into the Method Model Method configuration During this phase, the method engineer associates the elements included in the Method Model with metamodels, editors, transformations, etc., which are stored in the Asset Base repository. These assets configure the elements of the Method Model and determine how they will be managed in the tool built for supporting the SPM. The assets contained in the Asset Base can be built either in other SPMs or ad-hoc for the SPM under construction (the method engineer can use the tools provided in our CAME environment for this purpose). Specifically, in our proposal the assets contained in the Asset Base correspond either to Eclipse plugin/feature 2 projects that implement editors, metamodels or transformations, or to task guidelines. The elements of the Asset Base are specified following the RAS standard [20]. According to RAS, reusable assets are represented by zip files that contain a manifest describing the asset and one or more artifacts that compose the asset. Figure 3 shows an example of an asset containing a BPMN editor. This asset could be associated, for instance, to a SPM product called Business Process Model to specify that this product will be managed in the generated tool using a BPMN editor. At the end of this phase, the Method Model has evolved into a new stage where detailed information about the technological support of SPM tasks is given. We call Configured Method Model to the model resulting from this phase Method implementation During this phase a model transformation is executed to automatically obtain the tool that supports the SPM. This transformation takes as input the Configured Method Model previously obtained during the Method Configuration phase. The details of this phase, which are the focus of this paper, are given in the following subsection. 4. Automatic generation of tools for SPM support This section describes the part of the ME approach that deals with the construction of the software tool to support the SPM. The construction process is based on the application of the MDD paradigm; so, these software tools are generated from SPM specifications by means of model transformations. Figure 4 provides a graphical overview of this process. 2 An Eclipse feature is a group of Eclipse plugins. ISSN SISTEDES

51 Figure 3. Example of reusable asset: a BPMN editor Figure 4. Overview of the tool generation process The core of the generation process is a model transformation that obtains a software tool supporting the SPM specified in the Configured Method Model. As shown in the figure, the transformation uses the product and process parts of the SPM model to give support to both parts as follows: The support provided for the product part involves providing all the resources that enable the manipulation of the SPM products. This support is given by the software components that make up the infrastructure of the tool and correspond to the assets that were associated to the SPM elements in the Method Configuration. The support provided for the process part corresponds to a new component that enables the execution of SPM instances by means of a process engine. During the SPM execution, this component invokes the different software resources that allow the software engineers to create and manipulate the SPM products. The generation process of figure 4 has been implemented in the CAME environment developed to support the proposal [4]. In this context, the generated tools are built as Eclipse applications, in particular based on the MOSKitt tool [16]. This means that these tools are built as MOSKitt reconfigurations that only contain the set of plugins that implement the software support required by the SPM. The use of the MOSKitt platform implies that: (1) the software resources that give support to the product part of the SPM correspond to Eclipse plugins and (2) the final tool is obtained from a Product Configuration File (.product file). This type of files gathers all the required information to automatically 3 generate an Eclipse-based tool such as MOSKitt. So, considering that the tool is obtained from a Product Configuration File, the 3 The Eclipse Product Export Wizard (functionality provided in org.eclipse.pde) automatically generates an Eclipse-based application from a.product file. ISSN SISTEDES

52 model transformation is in fact a model-to-text (M2T) transformation implemented using the Xpand language [24]. This transformation takes as input the Configured Method Model and generates a.product file through which the final tool will be automatically generated. In order to generate this file, the M2T transformation must identify the software resources (Eclipse plugins) in charge of providing support to the SPM. Once these resources have been identified, the transformation includes in the Product Configuration File the list of features that need to be deployed in the final tool (MOSKitt construction is based on features). More insights on this M2T transformation and the tools obtained for product and process support in the final tool are presented in the next subsections Software support for the product part This section focuses on the part of the M2T transformation that obtains the tool support for the product part of the SPM. This product support refers to the tools (editors, transformations, etc.) that have to be integrated into the final tool to enable the manipulation of the SPM products and tasks. For instance, a SPM that includes a product such as a Business Process Model requires the inclusion within the tool supporting the SPM of a proper editor to manage this kind of models. Furthermore, to obtain a valid product support it is also necessary to solve the dependencies of the software components required to support the SPM product part with other software components. Therefore, we distinguish two steps in the M2T transformation that obtains the product support part: (1) identifying the software resources necessary to support the tasks and products of the SPM and (2) solving the dependences between software resources. Identifying software resources The M2T transformation explores the SPM model and identifies the software resources that are necessary to support the tasks and products of the SPM. The software resources are identified by means of the assets that were associated to these elements during the Method Configuration phase. Note that when a task or a product does not have an associated asset, the generated tool will not provide support to that element. It is also important to highlight that the integration of these resources into the MOSKitt reconfiguration representing the final tool can be automatically performed since these resources correspond to features and plugins created within the Eclipse/MOSKitt platform itself. Thus, the integration of tools developed outside of the context of Eclipse/MOSKitt cannot be guaranteed. In figure 5 two Xpand rules of the M2T transformation are shown. In these rules the list of features of the Product Configuration File is generated. The first rule is invoked for each instance of the class ContentElement (i.e. tasks and products). This rule invokes the second rule, which produces the output. The second rule accesses the property FeatureID of the content elements. This property is created during the asset association and contains the identifier of the feature (software resource giving support to the content element) packaged in the asset. Figure 5. Excerpt of the M2T transformation ISSN SISTEDES

53 Solving dependencies between software resources Once the required software resources are identified, it is necessary to solve the potential conflicts that can arise when integrating these resources (plugins) into the same platform (MOSKitt). To achieve this goal, we specify the dependencies between software resources within the assets. This specification allows the transformation to retrieve the dependencies for each software resource identified in the previous step and to include them in the Product Configuration File. As an example consider the asset of figure 3 containing the MOSKitt BPMN editor. This asset defines a dependency with the MOSKitt MDT component 4. Therefore its feature must also be included in the.product file so that the plugins implementing this component are also included in the final tool Software support for the process part In addition to the support provided for the product part of the SPM, according to our proposal, the generated tool also provides support for the process part. This support guides and assists users during the execution of SPM instances (projects). The process support is provided by means of a software component (the Project Manager Component) that is common to all SPMs. This component implements a graphical user interface (GUI) that enables the execution of SPM instances. To make this possible, the Project Manager Component uses the Configured Method Model at runtime (runtime in this context corresponds to the SPM instances execution in the CASE tool). Considering these aspects of the process support, the M2T transformation must always include in the product configuration file a predefined feature that groups the set of plugins that implement the Project Manager Component. The Project Manager Component endows the generated tool with a GUI composed of a set of Eclipse views (see Figure 6 5 ). Each of these views provides a specific functionality but their common goal is to facilitate the user participation in a specific project. The details of these views are the following: Product Explorer: This view shows the set of products that are handled (consumed, modified and/or produced) by the ongoing and finished tasks of the process. This view can be filtered by roles so that users belonging to a specific role have only access to the products they are in charge of. Then, from each product, the user can open the associated editor to visualize or edit its content. Process: This view shows the tasks that can be executed within the current state of the project. The execution of the tasks can be performed automatically (by launching the transformation associated to the task as a software asset) or manually by the software engineer (by means of the software resource associated to the output product of the task). Similarly to the Product Explorer, this view can be filtered by role, showing just the tasks in which the role is involved in. Guides: This view shows the list of guides associated to the task selected in the Process view. The objective of these guides is to assist the user during the execution of such task, providing some insights on how the associated products should be manipulated. These guides correspond to resources that were associated to tasks during the configuration step of the SPM. Product Dependencies: This view shows the dependencies that exist between the products that are handled in the project. So, it allows users to identify which products cannot be created or manipulated because of a dependent product has not yet been finished. In addition, these dependencies are organized by roles. This organization gives to the user the knowledge of who is responsible of those products he/she is interested in. 4 The MOSKitt MDT component implements the functionality that is common to all the MOSKitt graphical editors (such as copy & paste, view creation, etc.). 5 Available also at ISSN SISTEDES

54 Figure 6. Project Manager GUI Regarding the implementation of the Project Manager Component, it has been divided into four components of a lower level of granularity. The M2T transformation that generates the product configuration file always includes a feature that groups the Eclipse plugins that implement these four components. Even though the implementation of these components is independent of the SPM, as stated previously, they need the information stored in the Configured Method Model to work properly in the generated tool. Figure 7 depicts graphically these four components. Project Manager. This is the core component. It implements the GUI of the Project Manager Component and gives support to the process part of the final tool. To do so, this component uses the other three. Process Management. This component implements a light-weight process engine that keeps the state of the running SPM instances. Given a SPM instance it provides a set of methods that return the current tasks and also allow the method engineer to mark them as completed in order to enable the progress of the process. Note that, to make this progress possible, the component must access the SPM model and retrieve the distribution of the tasks along the SPM process. Product Management. This component is in charge of the management of the products and tasks. Regarding products, the component identifies the editor that is required to manipulate such product. Regarding tasks, we differentiate between automated and manual tasks. For automated tasks, the component obtains the transformations that have to be executed. For manual tasks it obtains the editor that allows creating and editing the products manipulated in this task. All this ISSN SISTEDES

55 Figure 7. Structure of the Project Manager Component information is contained in the SPM model, in particular in the assets associated to the tasks and products included in the model. Therefore, this component also needs to access the SPM model to get this information. Method Specification. This component loads the different elements of the SPM model (roles, tasks, products, etc.) to facilitate later access to them. All these elements are obtained from the SPM model. 5. Conclusions The development of CAME tools is a task that has proven itself as highly complex. When facing this challenge, the use of techniques that simplify this process becomes crucial. Considering this, some ME approaches have used MDD techniques using metamodelling languages either to define design notations [6] or SPM specifications [11]. The problem is that these approaches fall short when providing a solution to ME as they do not really take advantage of the possibilities that these techniques offer. Considering this lack, we want to leverage models going one step further. With this purpose we have presented a MDD approach that not only uses models for the specification of SPMs but also uses them as software artifacts, tackling the generation of tools to support them by means of model transformations. In particular, this work is contextualized within a broader proposal [4]. This proposal presents a methodological framework for the construction of SPMs, which covers from the SPM specification to the generation of the tool support. Specifically, this process is divided into two phases, being the last one the central focus of this paper. Regarding future work, we are working on the improvement of the CAME environment that supports our proposal. We are enhancing: (1) the management of the dependencies between the resources that have to be included in the final tool supporting the SPM under construction, and (2) the workflow engine that enables the execution of the SPM process and gives support to the process part of the proposal. References [1] Atkinson, C., Kühne, T.: Model-Driven Development: A Metamodeling Foundation. IEEE Software, IEEE Computer Society, 20, (2003) [2] Brinkkemper, S.: Method engineering: engineering of information systems development methods and tool. Information and Software Technology 38 (1996) [3] Brinkkemper, S., Saeki, M., Harmsen, F.: Meta-Modelling Based Assembly Techniques for Situational Method Engineering. Information Systems, (1999). [4] Cervera, M., Albert, M., Torres, V., Pelechano, V.: A Methodological Framework and Software Infrastructure for the Construction of Software Production Methods. International Conference on Software Processes, (2010) [5] Eclipse Process Framework Project (EPF), ISSN SISTEDES

56 [6] Grundy, J. C., Venable, J. R.: Towards an Integrated Environment for Method Engineering in Proceedings of the IFIP 8.1/8.2 Working Conference on Method Engineering, Hall, (1996) [7] Gupta, D., Prakash, N.: Engineering Methods from Method Requirements Specification. Requirements Engineering, Vol. 6 (2001) [8] Harmsen, A. F., Arnhem, T., Ernst, M., Consultants, Y. M., Gegevens, C., Bibliotheek, K., Haag, D., Frank, H. A.: SITUATIONAL METHOD ENGINEERING PROEFSCHRIFT [9] Harmsen, F., Brinkkemper, S.: Design and Implementation of a Method Base Management System for a Situational CASE Environment. APSEC (1995) [10] Henderson-Sellers, B.: Method Engineering for OO Systems Development. Communications of the ACM Vol. 46. Nº 10, pp , (2003) [11] Heym, M., Osterle, H.: A Semantic Data Model for Methodology Engineering. 5 th Workshop on Computer-Aided Software Engineering, pp IEEE Press, Los Alamitos (1992). [12] Hofstede, A., Verhoef, T. F.: On the Feasibility of Situational Method Engineering. Information Systems. 6/7 Vol. 22. (1997) [13] S. Kelly, K. Lyytinene, M.Rossi. MetaEdit+ A Fully Configurable Multi User and MultiTool CASE and CAME Environment. CAiSE [14] Kumar, K., Welke, R. J.: Methodology Engineering: A Proposal for Situation- Specific Methodology Construction. Challenges and Strategies for Research in Systems Development, John Wiley & Sons, Inc., (1992). [15] Mirbel, I., Ralyté, J.: Situational method engineering: combining assembly-based and roadmap-driven approaches. Requirements Engineering V.11, Nº 1, (2006) [16] MOdeling Software Kitt (MOSKitt), [17] Niknafs, A., Ramsin, R.: Computer-Aided Method Engineering: An Analysis of Existing Environments. CAiSE, (2008). [18] Prakash, N.: Towards a Formal Definition of Methods. Requirements Engineering. 1: Vol pp (1997) [19] Ralyté, J., Rolland, C.: An Assembly Process Model for Method Engineering. CAiSe. - pp (2001) [20] Reusable Asset Specification (RAS) OMG Available Specification version 2.2. OMG Document Number: formal/ [21] Roger, J. E., Suttenbach, R., Ebert, J., Süttenbach, R., Uhe, I., Uhe, I.: Meta-CASE in Practice: a Case for KOGGE. Springer, (1997) [22] Si-Said, S., Rolland, C., Grosz, G.: MENTOR: A Computer Aided Requirements Engineering Environment CAiSE, (1996) [23] Software Process Engineering Meta-model (SPEM) OMG Available Specification version 2.0. OMG Document Number: formal/ [24] Xpand, t=xpand ISSN SISTEDES

57 SOFIA: Smart Objects for Intelligent Applications ADK Jesús Fernández Gómez- Pimpollo Área Innovación Tecnológica (Soluciones Tecnológicas) Indra Sistemas, Anabel Segura nº , Alcobendas Madrid, Spain Raúl Otaolea ESI Tecnalia, Parque Tecnológico de Zamudio , Zamudio Bizkaia, Spain Abstract SOFIA (Artemis project: focuses on answering the challenge of creating smart environments and its goal is to make information that resides in the physical world available to current software services. This paper presents an open innovation platform for ambient intelligence applications including architecture, software engineering as well as an application development kit. Both, processing and implementation technologies have matured to such a level that using embedded technologies is beginning to make sense. It is therefore possible to begin to develop the concept of smart spaces, which have been investigated so extensively in the areas of Ubiquitous Computing, Ambient Intelligence and the Internet of the Future. This paper s core is based on how SOFIA has modeled its different domains and how software engineering together with the development environment will solve the development cycle of an intelligent application, starting from its semantic model to its implementation in a concrete programming language. 1. Introduction The ADK is a set of tools that provides several functionalities to the whole development life cycle. The Ontology Driven Development (ODD) [1] based on Ontology Driven Software Engineering approach has three phases: design, implementation, testing and deployment. 2. Design Figure 1. SOFIA development life cycle The Wizard plug-in centralizes the programmer decisions about the Knowledge Processor (KP). The wizard guides the developer to choose in between ontology concepts to use and their profile (producers and/or consumers), platform and programming language, communication protocol and project details like name, package names, etc. A new SOFIA project is created in the last wizard s step where all necessary middleware (all layers in the proper language, an editor for that language) is added and finally all the connectors selected, SSAP or communication protocol knowledge is not needed to start coding the logic of a KP. The plug-in selects a proper editor for the programming language chosen by the KP developer, and assigns it to the SOFIA project generated. Connectors are already coded for a variety of languages (partially programmed for Java) and ISSN SISTEDES

58 will be stored in a centralized server where the ADK connects to and downloads locally. Openness and scalability are major factors, therefore connectors for different communication protocols and different languages are feasible. The Smart Application Wizard includes the OWL2Classes facility, which translates several ontologies into programming languages classes in order to be used with the SOFIA middleware. When this class is used, all its interactions are sent to the SIB; therefore programmers do not need to have expertise knowledge about ontologies. 3. Implementation A KP is divided in four layers: 1. Logic. A developer is only responsible for programming this layer and it represents the functionalities a final user or a company wants to create. 2. Semantic model. This layer is automatically generated by the OWL2Classes tool of the ADK. It is an API with the classes in a specific programming language representing ontologies selected in the wizard tool. Thus, they are the concepts to exchange with the smart space. 3. SSAP. This layer gathers all APIs dedicated to deal with the SIB. The upper layer knows how to invoke the appropriate methods of this API.[2] Connection. The different connectors are plugged in this layer to connect with the SIB. It is also responsible for Semantic Information Broker (SIB) discovery. Hence, the complexity related with ontologies and communication protocols are totally encapsulated in a very easy API formed by plain classes (model layer). Developers only have to instantiate them and use their getters/setters in order to interact with the smart space. 4. Testing and Deployment The SIB is the responsible for the interoperability between heterogeneous smart applications and devices. Its core is differentiated in three parts; 1.Sessions. Refers to the KP connected to the SIB at a given moment. 2. Subscriptions. Subscribed nodes are notified when certain conditions in the semantic model are produced. 3. Semantic Model provides the interoperability level needed to connect different devices, platforms, sensors or data using the SOFIA Smart Space context. It also enables the knowledge processing, sharing and reuse between applications. The SIB OSGi Bundle exposes a set of services using the public interfaces ISIB (shows all the methods to interact with the SIB using SSAP Message type communication), which controls the communication between Gateways/KP and SIB, and IViewer (exposes methods to observe the content and to register changes within the SIB). The Semantic Model is based on Jena (Semantic Web Framework), which provides an API to allow the storage of ontologies, classes, individuals, properties and all data related to ontologies. It is assumed that languages can be used for the interaction with the model are OWL (or RDF-XML) and N3. Decisions are based on the definition of the SSAP Message Protocol defined in Description of XML encoding of SSAP document (internal Wiki). This model maintains a full class hierarchy of already connected nodes and the individuals (instances or triples) that has joined the SIB. All KPs must send in their first ontology model connection to the SIB, so that, all individuals defined in that KP can be understood by the SIB and other KPs in the Smart Space. When a KP is removed from the Smart Space all the information about this KP is also removed from the SIB Semantic Model, including all the inserted individuals. The ADK Subscription Manager is responsible for maintaining the information about the subscribed KPs and Session Manager manages the KPs connected to the SIB at a given moment. Only connected KP-nodes are allowed to perform the SSAP operations in the SIB. The SIB into a Sofia smart space needs to interoperate with the KPs of several smart applications that are running into the smart space, which enables the KP to change information into the SIB and the SIB communicates those change to several KPs subscribed to them. KP can be executed in any physical device with communication capabilities to interoperate with a SIB of the smart space. The use of Gateways is a solution to avoid problems when having devices with different communication protocols. A modular and extendible architecture is achieved by having the OSGI platform as a module container, where the SIB or the Gateways are OSGI bundles and SIB bundle changes will ISSN SISTEDES

59 not affect any Gateway bundle. This architecture will be enhanced with new Gateways supporting new communication protocols and increasing the amount of devices where smart applications can be deployed, freeing new Gateway developers of any responsibility regarding opened sessions (KPs-SIB) as the fragment bundle will be extended by the Gateway. Moreover, two specific Gateway OSGI Bundles are been looked at the moment to support TCP/IP and Bluetooth connections. The platform is also open to develop new Gateways supporting more connection protocols. SIB includes a server to represent any server visually, which main functions are start and stop the SIB and a viewer to visualize the content of the embedded SIB and has three tabs: Sessions, Subscriptions and Semantic model (to check insertions and removals among connected KPs and the SIB, key tool to test KP). 5. Conclusion The ADK has already achieved its main goal, to aid developers programming high quality smart applications; nevertheless SOFIA aims to push this concept to the limit allowing final users to build their own applications. To do so, we are now defining a smart application model (within ODD) to design easy applications visually linking the different parts semantically [2], [3]. This approach will gain high dynamicity and composability inside a smart space, as the dependencies are not established statically but semantically and could be solved at runtime based on semantics. This feature will be ready with the second version of the ADK. References [1] W3C, Ontology Driven Architectures and Potential Uses of the Semantic Web in Systems and Software Eng. online: ces/se/oda/, 2006 [2] Vanden Bossche, M., Ross, P., MacLarty, I., Van Nuffelen, B., Pelov, N.: Ontology driven software engineering for real life applications, in Proc. 3rd Intl. Workshop on Semantic Web Enabled Software Engineering, 2007 [3] de Oliveira, K. M., Villela, K., Rocha, A. R., Travassos, G. H.: Use of ontologies in software development environments, in Calero, C., Ruiz, F., Piattini, M. (eds) Ontologies for Software Engineering and Software, 2006 ISSN SISTEDES

60 A MDA Approach for Deriving Functional Testing Software for Validation of Active Applications in RDB * Harith Al-Jumaily Computer Science Department Carlos III University of Madrid Av. Universidad LEGANES - MADRID haljumai@inf.uc3m.es Dolores Cuadra Computer Science Department Carlos III University of Madrid Av. Universidad LEGANES - MADRID dcuadra@inf.uc3m.es Paloma Martínez Computer Science Department Carlos III University of Madrid Av. Universidad LEGANES - MADRID pmf@inf.uc3m.es Abstract The development of active applications in most database CASE tools has been insufficient because most of these tools do not provide the software necessary to validate these applications. Validation means ensuring whether a given application fulfils the user requirements. We suggest validation of active applications by using the functional testing technique, which is a fundamental black-box testing technique for checking the software without being concerned about its implementation and structure. Our main contribution to this work is in providing a MDA approach for deriving testing software from the OCL specification of the integrity constraints. Our approach is implemented as an add-in tool called OCL2TestSW. 1. Introduction The introduction of the MDA approach (Model- Driven Architecture) [1] in Software Engineering has provided good support and consolidation for automatic code generation. MDA focuses on using models to cover the life cycle of software development. MDA is suitably used to solve the interoperability problem between heterogeneities systems with different implementation platforms. However, a limitation of MDA is that it does not provide a way to validate the software. Thus, our approach focuses on deriving test cases from the specifications of OCL clauses in a class diagram. These test cases are used to ensure that active applications employed to enforce these specifications fulfill the user requirements. An active application is an extension of the traditional database applications with a set of active rules or triggers. Incorporating active rules significantly enhances the functionality of database systems and provides flexible alternatives to implement many database features, such as enforcing integrity constraints. An active rule is able to detect events and issue predefined actions to maintain a database state. An event in relational databases is a DML (Data Manipulation Language) statement such as insert, delete, and update. Once a trigger is activated and its condition evaluated to true, the predefined actions are automatically executed. The validation of triggers means ensuring that a set of triggers does exactly what the user requirements specify. Therefore, our research group is interested in making the development task of these applications easier through the automatic transformation of Object Constraints Language (OCL) specification into testing software for validation of active applications. The rest of this work is organized as follows. In section 2 previous related works are presented. In section 3 our approach is presented. In section 4, a complete example of applying the generated * This work is part of the project "Software Process Management Platform: modelling, reuse and measurement" (TIN2004/07083) and the project Thuban: Natural Interaction Platform for Virtual Attending in Real Environments (TIN ). ISSN SISTEDES

61 testing software for applications validation is performed. In section 5, some conclusions and future lines of research are presented. 2. Related Works In general, in order to validate the user requirements a wide range of traditional software, testing techniques have been proposed, but relatively little effort has been spent on the testing database applications [2]. In [3] the issues which make testing database applications different from other types of software have been identified, and a tool has been developed for populating a database with meaningful data which satisfies constraints. The cited work considers only the constraints which can be expressed in the database schema by using SQL s Data Definition Language. Our work agrees with the issues in testing database applications presented in the cited work. Nevertheless, the difference between the two works is that in our work the testing software is derived from the constraints which are expressed in a UML class diagram. These constraints can be a basic type such as (primary key, foreign key, and unique key) and specification of OCL clauses. Our approach joins the UML in aspects that have been widely accepted and supported by many CASE tools in the software validation field. In [4], static analysis techniques (also called white-box techniques) have been used to extract useful information in a web database application. Static analysis testing is a fundamental structural technique that depends on software structure and implementation. That is, the white-box approach has been used to construct an application graph which systematically generates selected paths based on that graph. Each path represents a possible scenario for use of the application. A test case is organized as an XML file and is automatically executed. In [5] [6] and [7], the white-box testing technique is also applied to validate a database application. The main objective is to validate all possible paths in the execution flow of a program. By means of these paths all the program statements are executed and examined at least once. In [8] a white box method for automatic generation of database instances is proposed. The input of this method consists of SQL statement, database schema, and assertions to define the user requirements. The output is a set of constraints to validate the desired database instances. We think that applying black-box techniques could be more simple and practical, especially when there are an enormous number of interactions with a database. An example of the difficulty in applying white-box techniques is the case of the validation of active database applications. Each trigger has an independent structure but in execution time it is very difficult to detect all possible paths to be validated. Thus, we believe that using the equivalence-class testing technique could make the validation of database applications easier. The equivalence-class testing is a fundamental technique for functional testing which checks the software without worrying about its implementation and structure [9]. In this type of testing, the examiner s responsibility is to provide input or initial data and to validate the output results. The main objective is to check whether the tested software fulfils the user requirements or not. Our approach starts from the specification of constraints in the design phase, which are then implemented according to the chosen database system (SQL Server, Oracle, MySQL). Not only are the basic constraints of the relational DBMS considered (primary keys, unique or foreign key), but also those constraints which are more complex and which can be implemented by triggers (see OCL2Trigger [12]). 3. MDA for Deriving Testing Software The main objective of deriving testing software from the OCL specifications is to ensure that triggers application used to enforce these specifications fulfills the user requirements. In this section, we will explain our approach for deriving functional testing software from the OCL specifications according to the MDA framework. There are three phases for adaptation of MDA to our approach (see figure 1). ISSN SISTEDES

62 PIM/UML PSM/SQL Testing Components Testing Cases Class Diagram OCL Validation Queries Transforming OCL to SQL Testing Software Model Transforming SQL Components to DBMS Testing Software Model Testing Software MS-SQL DB2 ORACLE Figura 1. Applying MDA to our approach The first one, called PIM, represents the logical view of the specification of integrity constraints using OCL clauses in a class diagram. The second one, called PSM, describes the technology used to build the necessary components of the testing software. In this phase, the SQL notation is used to refer to the recent 2003 standard [10]. The standard SQL is used to describe these components because we focus on testing relational database applications. The third phase is called Testing Software which describes the software technology which can be applied directly in a target commercial DBMS such as Oracle, DB2, and MS Server. Two models are used to carry out the transformation rules between these phases automatically: Transforming OCL to SQL components Model, and Transforming SQL components to DBMS testing software Model. In the following we present a brief description of these models Transforming OCL to SQL Testing Software Model According to Figure 1, each OCL constraint is transformed into two testing software components. Each one of these components is related to an issue in testing database application. These issues are defined in [16] as specifying database states, applying test cases, and observing database state after test execution. According to these issues, the testing software components are defined in our work as initial data to be inserted before the testing is begun, test cases to be applied for testing applications, and validation queries to ensure the correctness of the tested application. In this work, we consider the generating of test cases and validation queries while the examiner must prepare validated initial data to be inserted before the testing is begun Validation Queries To ensure the correctness of the integrity constraints each OCL clause in the class diagram is mapped to a validation query. Each query is applied after a test case is run. Although an OCL expression specifies invariant, pre-condition, postcondition, and other types of constraints, in this work the invariant constraints are considered. An invariant constraint is an OCL expression that can be associated with a class, a type or interface in a UML class diagram to define an integrity constraint [1]. It must be true for all instances of element type at any time. The OCL invariant constraints are also used to specify relationship constraints in a class diagram such as multiplicity, generalization, etc., although these constraints are already included in the diagram [11]. Let us consider that we have a scenario S i consisting of a set of classes (each class is mapped to a relational table), and each one of these classes contains a set of OCL clauses to define the integrity constraints. Each one of these OCL clauses is mapped to a SQL query. In this section, we will show the mapping rules which are used to transform OCL clauses to SQL queries ( i σ i ), where is an OCL expression, σ is a negation SQL expression corresponding to, and i is one of the mapping rules. We use the Relational ISSN SISTEDES

63 Algebra notations [18] to introduce abbreviations to simplify and make the theoretical results of our approach more readable. However, in practice the transformation of an OCL expression to a SQL standard expression is automatically performed. This transformation is a significant phase in our approach because this expression restricts the attribute values and the relationships between them. Hence, we perform this transformation first, and then proceed with the following phases of our validation approach. Let us consider the following OCL clause: i : Context A inv constraint_name : OCL_expression (self) A is a class name. Self is an instance of A. The Context specifies the class in which an OCL expression is defined. The OCL_expression is a logical expression that describes a relationship between one or more atomic expressions. An atomic expression contains no more than one operator. The OCL_expression is mapped using the logical and mathematical operators of SQL. For example, the mapping of mathematical operators ( -, +, *, / ) is performed directly. The logical operators (Θ) such as (and), (or), (not) are mapped using counterpart expressions of SQL. We can apply one of the following rules when: Rule(a) OCL_expression is defined on a target attribute in a class A. a A.x σ a (A.x) self.x Θ V 1 σ ( A. x Θ V1 ) Rule(b) OCL_expression is defined on target attributes in one or more class A, B. b A.x,B.z σ b (A.x,B.z) self.xθ 1 V 1 implies self.b.zθ 2 V 2 σ (( A. x Θ 1 V1 ) ( B. z Θ 2 V 2 )) Here, implies can be mapped using the logical operator AND and the logical negation is applied on the second operator Θ 2. This is because implies does not have a counterpart in SQL. Rule(c) OCL_expression is defined to specify an aggregate function (agg = {MAX, MIN, etc.) on target attributes in one or more class. c A.x,agg(B.z) σ c (A.x,agg(B.z)) self.b.z->agg()θself.x σ ( A. x Θ agg ( B. z )) Rule(d) OCL_expression is defined to specify navigation between two classes A, B. d A.a,B.a σ d (A.a,B.a) self.navigation >size()θv σ ( count ( B. a ) Θ V ) Rule(e) OCL_expression is defined to specify ocliskindof property to determine whether A is either the direct type or one of the subtypes. e A.a,B.a,C.a σ e.total (A.a,B.a,C.a) σ e.disjoint (A.a,B.a,C.a) self->forall(a.a ocliskindof(b.a)θocliskindof(c.a)) σ e.total = σ A. a IN ( π B ( B ) π ( ))) OR σ e.disjoint = σ (. a C. a C π B π ( A. a IN (. a ( B ) C. a ( C ))) OR Testing Cases The functional testing design is based on the definition of the equivalence classes. An equivalence class represents a set of valid or invalid states for certain input conditions [13]. To apply our approach, we first need to specify these input conditions. In database applications, input conditions can be divided into two classifications: critical events and the associated attribute values to these events. A critical event is an operation that could violate one database constraint; these events are: Insert, Delete, and Update. An event is used with its corresponding attribute values. Although insert a new tuple in a table means insert all the defined attributes values of that table, in this section we consider only the attribute which is defined in the SQL expression of a constraint because it is the only attribute that can affect the constraint. According to the SQL expression rules (section 3.1.1) critical events are specified. For example, any expression belonging to the type (σ a ) has as critical events: the insertion of new tuples and updating of the expression attributes. Table 1 shows the critical events considered in this work. Three equivalence classes are defined for these events, one for each event. These equivalence classes specify only the valid states of ISSN SISTEDES

64 the input conditions because no DBMS is able to execute any invalid state. It means that if there is any syntax error in the specification of these events, the DBMS itself will reject this operation by raising a compilation error. As in the case of the critical events, the validation of attribute values of the input conditions is also carried out by the DBMS itself. This means that the input conditions must always be valid. For example, if we insert a tuple into a table, the DBMS first verifies the correctness of the inserted tuple before placing it into the corresponding table, or when a tuple is deleted from a table, the DBMS validates first that the deleted tuple exists in the corresponding table before deleting it. Nevertheless, from the database semantic point of view, it is possible to identify two types of input conditions, valid and invalid classes. For example, the insertion of t 1 (x, y) into a table could be valid for the semantic, while the insertion of t 2 (x, z) into the same table could be invalid for the semantic. In these two cases, the DBMS accepts the insertion, but the difference is that the first case produces a correct semantic while in the second a false semantic is produced. In accordance with what we have stated above, table 1 specifies one valid class for each critical event and two equivalence classes for each attribute value: one valid class when the attribute value fulfils the corresponding constraint and one invalid class when the attribute value does not fulfil the constraint. Once the valid and the invalid equivalence classes are defined, in the next step the necessary testing cases corresponding to each one of these classes is derived. A test case is defined as a combination of classes from different classifications. For each test case exactly one class of each classification is considered [14]. In addition to that, to increase the confidence level in our approach we will increase the number of these cases by generating a test case for each tuple in the context relation (the relation in which the testing is performed). In this work, we will focus on applying the invalid testing cases because we believe that their executions contribute a certain confidence in detecting possible defects in the tested application. Test cases representing unexpected and invalid input conditions seem to have a higher errordetection yield than do test cases for valid input conditions [15]. Let us consider that a relation A contains the following schema: A={a 1.PK,, a n}, {(p 1, ), (p 2, ), (p m, )}. It has n attributes and m tuples, and a 1 is the primary key of A. {p 1, p 2,., p m} are the primary keys values. The testing cases which are defined on A are shown as follows: t k ={event(a.a i ),Invalid(a i.value), j=1 m)} ( p j A, where (t k) is an index number for each test case. The event(a.a i) is a critical event which modifies an associated attribute in the relation A. This event can violate the expression rules shown in the previous section. The Invalid(a i.value) is the associated invalid attribute value for that event. As we previously stated, we apply the invalid testing cases only. The ( p j A, j=1 m) means that the testing cases are applied for each primary key value (i.e., for each tuple) in the relation A. According to standard SQL for the Delete and the Update events we can define a condition (WHERE clause) to limit the modified tuples. For example, using the condition (WHERE a 1=p j) limits the event only on the tuple which has p j as a primary key value. For the Insert event no such condition is needed. Therefore, the testing cases for insertion will be applied only once for each relation, and the user needs to use a new primary key value to apply the insertions. ISSN SISTEDES

65 Table 1.The valid and invalid equivalence classes of the rules expression Rule (a) Critical events (1) Ins(A.x) (4) Upd(A.x) Valid equivalence classes (2) A.xΘV (5) A.xΘV Attribute values Invalid equivalence classes Attribute values (3) A.x ΘV (6) A.x ΘV (7) Ins(A.x) (8) A.xΘB.z (9) A.x ΘB.z (b) (10) Ins(B.z) (13) Upd(A.x) (11) A.xΘB.z (14) A.xΘB.z (12) A.x ΘB.z (15) A.x ΘB.z (16) Upd(B.z) (17) A.xΘB.z (18) A.x ΘB.z (19) Ins(B.z) (20) A.xΘagg(B.z) (21) A.x Θagg(B.z) (22) Upd(A.x) (23) A.xΘagg(B.z) (24) A.x Θagg(B.z) (c) (25) Upd(B.z) (26) A.xΘagg(B.z) (27) A.x Θagg(B.z) (28) Del(A.x) (29) A.xΘagg(B.z) (30) A.x Θagg(B.z) (31) Del(B.z) (32) A.xΘagg(B.z) (33) A.x Θagg(B.z) (34) Ins(A.a) (35) (count(b.a) Θ V) (36) (count(b.a) Θ V) (37) Ins(B.a) (38) (count(b.a) Θ V) (39) (count(b.a) Θ V) (d) (40) Del(A.a) (41) (count(b.a) Θ V) (42) (count(b.a) Θ V) (43) Del(B.a) (44) (count(b.a) Θ V) (45) (count(b.a) Θ V) (46) Upd(B.a) (47) (count(b.a) Θ V) (48) (count(b.a) Θ V) (49) Ins(A.a) (50) A.a IN (π B.a(B) π C.a(C)) (51) A.a IN (π B.a(B) π C.a(C)) (52) Ins(B.a) (53) A.a IN (π C.a(C)) (54) A.a IN (π C.a(C)) (e) (55) Ins(C.a) (56) A.a IN (π B.a(B)) (57) A.a IN (π C.a(C)) (58) Del(B.a) (59) A.a IN (π C.a(C)) (60) A.a IN (π C.a(C)) (61) Del(C.a) (62) A.a IN (π B.a(B)) (63) A.a IN (π B.a(B)) Once the valid and the invalid equivalence classes are defined, in the next step the necessary tests cases, corresponding to each one of these classes, are derived. A test case is defined as a combination of classes from different classifications. For each test case, exactly one class of each classification is considered [17]. In addition to that, to increase the confidence level in our approach we will increase the number of these cases by generating a test case for each tuple in the context relation (the relation in which the testing is performed). In order not to lengthen the paper, in this section we show how the testing cases of (σ a ) are generated, the testing cases of the other rules are generated in the same way. Let us consider the same previous relation A. IF EXISTS σ a THEN [ t 1..m ={ (4) Upd(A.a i ), (6) x 1..m ΘV,(p 1 ) (p 2 ).. (p m )} t m+1 ={ (1) Ins(A.a i ), (3) x m+1 ΘV,:new.a 1 } ] That is, if a mechanism is implemented to enforce σ a (A.a 1 ) on the relation A then (m+1) testing cases are needed to validate this mechanism. The t m+1 defines an insertion operation (1) Ins(A.a i ), with the invalid class (3) x 0 ΘV. The (:new) is used to indicate that these cases treat the insertion of new tuples. t 1..m defines an update operation for the attribute (4) Upd(A.a i ), with the invalid values (6) x 1..m ΘV and where x 1, x 2, x m are any invalid values corresponding to the attribute a i. ISSN SISTEDES

66 3.2. Transforming SQL Components into DBMS Testing Software Model Although most Relational DBMS use SQL components, there are some differences between the specific characteristics of these DBMS. These differences make that testing software of one system cannot be used directly with another system without modification, although sometimes these differences are too small to be significant. Once the standard SQL components are derived in the previous section, these components are mapped to target DBMS testing software. The mapping is performed directly, that is, each SQL component is mapped into one related component in a target DBMS (1 to 1). As shown in the following processes: Mapping standard SQL queries to target DBMS Select statement A standard SQL query is mapped to one Select statement of a target DBMS. To do this mapping, DBMS Select templates are used. A select template is a generic query template in which some values are established as parameters so that different particular constraint situations can be derived by giving different values to the parameters. There is one template function for each DBMS and for each expression rule considered in this work. The below example, a generic template of the expression rule (d) is presented to illustrate the transformation of the standard SQL query into Oracle 11g. SELECT * FROM Context_table WHERE PK IN (SELECT FK FROM Related_table GROUP BY FK HAVING COUNT(*) Operator Value); This select statement is used to validate the database state whenever a test case contains one of the following critical events ( (34) Ins(A.a), (37) Ins(B.a), (40) Del(A.a), (43) Del(B.a), (46) Upd(B.a)). All other templates are applied in the same way as the previous one Mapping test cases into target DBMS DML statement Once the test cases are calculated according to what has been stated in section (3.1.3), mapping the test case into standard DML statement is performed directly; that is, each SQL statement is transformed into a related statement in a target DBMS (1 to 1). Here, we are also using a template for each statement and for each DBMS. The execution of these templates is done according to a similar algorithm which has been shown in the case of mapping standard SQL queries to a target DBMS Select statement. The following statement is used for mapping the Update event as a DML statement corresponding to the expression rule (c) using the MS SQL Server. DML_Upd:= UPDATE Context_table SET a=v WHERE PK=Value; The other invalid test cases of the expression rules are generated in the same way as the previous one. 4. Application Example In this section, an application example is presented. The aim of applying testing software is to ensure that the application fulfils the user requirements. To do that, the initial data, test cases, and validation queries involved in this process are automatically generated. These components are saved into text files which are ready to be directly submitted to our tool. Before starting the testing, the class diagram or schema (SCH) is divided into subschema (Sub 1, Sub 2,, Sub n) or scenarios. Sub i is a subschema which contain relations (R 1, R 2,., R m) and constraint defined for these relations. Let us consider the following employees database; DEPT and EMP are two relations of a subschema (Sub i). DEPT (deptno PK, name, budget); EMP (empno PK, name, age, sal, deptno FK); Let us consider that the following integrity constraints are defined in the above schema. a : the age of an employee must be equal to or more than 24. Context EMP self.age>=24 c : the total salary of employees must not exceed the department s budget. Context EMP allinstances.sal->sum()>self.dept.budget d : every department has at least two employees. ISSN SISTEDES

67 Context DEPT self.navigation -> size() >= 1 Validation Queries: The following clauses show the negation and the SQL transformation of the constraints σ a, σ c, σ d Respectively. σ ( EMP. age < 24 ) σ a Select * From EMP Where age<24 (Q1) σ ( DEPT. budget < SUM ( EMP. salary )) σ c Select * From DEPT D Where deptno In (Select deptno From EMP E Group By deptno Having D.budget < SUM(E.salary))...(Q2) Select SUM(salary) From EMP E Group By E.deptno Having deptno In (Select deptno From DEPT D Where D.budget < SUM(E.salary)) (Q3) σ ( COUNT ( EMP. deptno ) < 2 ) σ d Select COUNT(deptno) From EMP Group By deptno Having COUNT(deptno)<2 (Q4) Initial Data: To make it easier for the reader, we will show a small number of tuples that have been inserted in the tables of the chosen scenario. These tuples satisfy the conditions of the above constraints, as follows: DEPT(10, Dept1, 10000); EMP (1, Emp1, 49, 1500, 10), (2, Emp2, 33, 1100, 10); Test Cases: a) To calculate the invalid test cases of a, the following testing rules are applied. t 1..m = { (4) Upd(EMP.age), (6) x 1..m <24, 1 2} t m+1 = { (1) Ins(EMP.age), (3) x m+1 <24, :new.age} These test cases are transformed into the following DML statements: Update EMP Set age=12 Where empno=1 (S1) Update EMP Set age=15 Where empno=2...(s2) Insert Into EMP Values (3, Emp3, 20, 2600, 10); (S3) b) To calculate the invalid test cases of c, the following test cases are applied. t 1..n ={ (22) Upd(DEPT.budget), (24) x 1..n <SUM(EMP.salary), 10} t 1..m ={ (25) Upd(EMP.salary), (27) x 1..m <SUM(EMP.salary), 1 2} t m+1 ={ (19) Ins(EMP.salary), (21) x 1..m <SUM(EMP.salary), 3} t 1..n ={ (28) Del(DEPT.budget), (30) x 1..n <SUM(EMP.salary), 10} t 1..m ={ (31) Del(EMP.salary), (33) x 1..m <SUM(EMP.salary), 1 2} Therefore, debugging test cases are shown as follows: Update DEPT Set budget=2000 Where deptno=10...(s4) Update EMP Set salary=12000 Where empno=1 (S5) Update EMP Set salary=8000 Where empno=2...(s6) Insert Into EMP Values (3, Emp3, 20, 15000, 10) (S7) c) To calculate the invalid test cases of d, the following test cases are applied. t n+1 ={ (34) Ins(DEPT.deptno), (36) (count(emp.deptno)<2), 20} t 1..m ={ (43) Del(EMP.empno), (45) (count(emp.deptno)<2), 10} t 1..m ={ (46) Upd(EMP.deptno), (48) (count(emp.deptno)<2), 1 2} t 1..n ={ (40) Del(DEPT.deptno), (42) (count(emp.deptno)<2), 1 2} t m+1 ={ (37) Ins(EMP.empno), (39) (count(emp.deptno)<2), 3 } With respect to the first test case (t n+1 = { (34) Ins(DEPT.deptno), ), we must take into account that inserting a new department without any related employee will violate the d, therefore this test case is ignored. In addition, our tool also ignores the test case (t 1..n = { (40) Del(DEPT.deptno),.) because of the foreign key definition. The case (t m+1 = { (37) Ins(EMP.empno),.) is ignored too because if an employee is inserted, this leads to increasing the participation with the related department which will not lead to the violation of the constraint ( d ). In this example, there is only one department, therefore the tool ignores the test case (t 1..m = { (46) Upd(EMP.deptno),..) because there is not a new generated value to be changed in EMP.deptno. Thus, in this case the following DML statements are generated: Delete From Emp Where empno = 1 (S8) Delete From Emp Where empno = 2 (S9) ISSN SISTEDES

68 As a result, our tool defines 8 test cases (s1,s2,,s8) for the employees database example. In the next step, we submit the previous test cases and the initial data to be evaluated according to the generated validation queries. The tool applies the DML statements upon the initial data and validates the results according to the algorithms shown in section (3.1.2). The final results of the validation are reported as shown in table (3). For example, if the invalid test case S1 is applied on the EMP table then our tool rejects S1 and no modification is performed. Therefore, we apply the validation query Q1 to check if there is any inconsistency data in EMP. Here the Q1 should not return any selected rows, which means that the data in EMP is still consistent. Of course, the examiner can include valid test cases for evaluating the application software; in this case the tool will accept the modification and the expected results No selected row of the validation queries is also returned because these queries are only looking for the rows which do not fulfil the corresponding constraints. The results shown in table (2) ensure the consistency of the generated initial data before applying them to validate the application. Table 2. Our tool report about the expected results when applying the test cases. Cases Table Event Tool Action Validation queries Expected Results S1 EMP Update Reject Q1 No selected row S2 EMP Update Reject Q1 No selected row S3 EMP Insert Reject Q1 No selected row S4 DEPT Update Reject Q2 No selected row S5 EMP Update Reject Q3 No selected row S6 EMP Update Reject Q3 No selected row S7 EMP Insert Reject Q3 No selected row S8 EMP Delete Reject Q4 No selected row S9 EMP Delete Reject Q4 No selected row 5. Conclusions Active rules/triggers systems from many studies are presented and some challenges and issues are addressed to control the execution of these systems. One of these challenges is to encourage commercial CASE tools to cover all analysis phases with extended conceptual models. Using triggers means additional effort in database development because the triggers execution model adds more complexity. Our principal objective in this work is to motivate database designers to use triggers for completing semantic specifications gathered in a conceptual schema through a CASE tool which shows triggers execution associated to a relational schema in an intuitive way. It is true that various studies have led to important results such as the creation of the current commercial CASE tools and some research prototypes to support software verification and validation. Nevertheless, in the context of Relational Databases we consider that current practice is not sufficient. Therefore, we present our approach to fill in some of the gaps that the current CASE tools generate during the development of Relational databases. The paper represents a first effort to check the viability of this approach through some of the most widely used constraints in the conceptual model. The generation task of initial data was not considered in our approach, so that, as a future work we would like to incorporate a mechanism to generate these types of data. In addition, we will adopt our tool to generate a huge volume of data in a totally automated manner. ISSN SISTEDES

69 Referencias [1] OMG, Object Management Group, Inc. [2] Kapfhammer G.M. and Soffa M.L., A Family of Test Adequacy Criteria for Database-Driven Applications. In The Journal Software Engineering Notes. VOL 28; PART 5, pages [3] Chays D., Dan S., Frankl P. G., Vokolos F., and Weyuker E. J., A Framework for Testing Database Applications. ACM SIGSOFT international symposium on Software testing and analysis. Portland, Oregon. [4] Deng Y., Frankl P.G., and Wang J., Testing web database applications. In Work. on Testing Analysis and Verification of Web Services (TAV-WEB), USA, pp [5] Chan M.Y. and Cheung S.C., Testing Database Applications with SQL Semantics. In the 2nd International Symposium on Cooperative Database Systems for Advanced Applications (CODAS'99), Wollongong, Australia, pp [6] Kapfhammer G.M. and Soffa M.L., A Family of Test Adequacy Criteria for Database-Driven Applications. In The Journal Software Engineering Notes. VOL 28; PART 5, pages [7] Chan H.W.R., Dietrich S.W., Urban S.D On Control Flow Testing of Active Rules in a Declarative Object-Oriented Framework. Proc. of 3rd Intl. Workshop on Rules in DatabaseSystems, RIDS 97, Skovde, Sweden [8] Jian Zhang, Chen Xu, S. C. Cheung, Automatic Generation of Database Instances for White-box Testing, Proceedings of the 25th International Computer Software and Applications Conference on Invigorating Software Development, p , October 08-12, 2001 [9] Pressman R. S Software engineering: a practitioner's approach. McGraw-Hill Higher Education. [10] ISO/IEC 9075 Standard, Information Technology Database Languages SQL:2003 International Organization for Standardization. [11] Cabot J., Teniente E., 2009, Incremental Integrity Checking of UML/OCL Conceptual Schemas. Journal of Systems and Software, vol 82, issue 9, pp [12] Al-Jumaily H.T., Cuadra D., and Martínez P., 2008, OCL2Trigger: Deriving Active Mechanisms for Relational Databases Using Model-Driven Architecture. Journal of Systems and Software, 81, pp [13] Pressman R. S Software engineering: a practitioner's approach. McGraw-Hill Higher Education. [14] Lehmann E. and Wegener J Test Case Design by Means of the CTE XL. Proc. of the 8th European Inter. Conf. on Software Testing, Analysis & Review (EuroSTAR 2000), Kopenhagen, Denmark. [15] Myers G.J The Art of Software Testing, 2Ed, Editor: John Wiley & Sons [16] D. Chays, S. Dan, P.G. Frankl, F. Vokolos, and E.J. Weyuker, A Framework for Testing Database Applications. ACM SIGSOFT international symposium on Software testing and analysis. Portland, Oregon. [17] E. Lehmann and J. Wegener, Test Case Design by Means of the CTE XL. Proc. of the 8th European Inter. Conf. on Software Testing, Analysis & Review (EuroSTAR 2000), Kopenhagen, Denmark. [18] Elmasri, R. Navathe, S., Fundamentals of Database Systems, Addison-Wesley, Third Edition. ISSN SISTEDES

70 Análisis de Comunicaciones como un enfoque de requisitos para el desarrollo dirigido por modelos Marcela Ruiz Centro de Investigación en Métodos de Producción de Software (ProS) Universidad Politécnica de Valencia Sergio España Centro de Investigación en Métodos de Producción de Software (ProS) Universidad Politécnica de Valencia Arturo González Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia agdelrio@dsic.upv.es Óscar Pastor Centro de Investigación en Métodos de Producción de Software (ProS) Universidad Politécnica de Valencia opastor@pros.upv.es Resumen El desarrollo de sistemas de información requiere de métodos de requisitos para fijar las necesidades de la organización. El paradigma del desarrollo de software dirigido por modelos (DSDM) puede dotar a los modelos de requisitos de un valor añadido: el potencial para derivar de ellos los modelos conceptuales que servirán para la generación automática de software. Este artículo presenta la integración del Análisis de Comunicaciones, en OO-Method, un entorno de DSDM orientado a objetos. Se presenta el proceso de integración, distinguiendo dos etapas: el soporte a la diagramación y el establecimiento de transformaciones de modelos. Se describe en detalle la primera etapa, que ya ha sido concluida con éxito, en la que se diferencia un metamodelo independiente de plataforma y un metamodelo dependiente de la plataforma elegida para la implementación de las herramientas (Eclipse Modeling Framework). La herramienta ha sido validada por expertos en el método y por usuarios. Palabras claves: DSDM, Análisis de Comunicaciones, ingeniería de requisitos, metamodelado. 1. Introducción El desarrollo de sistemas de información empresariales (SI) es una actividad de gran complejidad socio-tecnológica. Pese a una evolución favorable del ratio de éxito en proyectos software, las últimas cifras arrojadas por los informes CHAOS revelan todavía un 68% de proyectos fracasados o amenazados [1]. Academia e industria coinciden en señalar, entre los factores de riesgo que amenazan los proyectos software, la falta de participación del usuario como el más influyente [1, 2]. Implicar adecuadamente al usuario en el proceso de desarrollo permite la detección y corrección temprana de errores e incrementa la aceptación del producto final [3]. Una solución efectiva para implicar adecuadamente al usuario es la adopción de prácticas de ingeniería de requisitos. Sin embargo, la adopción de métodos de ingeniería de requisitos por parte de la industria no responde a las expectativas de la comunidad científica [4]. Entre los factores que dificultan la adopción industrial, destacan la inherente complejidad de la ingeniería de requisitos, la falta de entrenamiento en los nuevos métodos propuestos y la actitud reticente de los agentes industriales [5]. El auge del paradigma DSDM, puede permitir resolver algunas dificultades de la ingeniería de requisitos. Puesto que las especificaciones de requisitos constituyen un modelo abstracto de la práctica industrial que debe soportar el software, resultan compatibles con el DSDM [6]. Este paradigma permite aprovechar los modelos, no solo para documentar y comunicar las necesidades de la organización respecto al SI, sino también para derivar modelos posteriores. Este valor añadido mejora el retorno de inversión de los modelos de requisitos y, por lo tanto, puede facilitar su adopción industrial. A la Ingeniería de Requisitos se le plantea el reto de proveer métodos aplicables en entornos de DSDM, así como estrategias de transformación de modelos. Este reto se puede afrontar de, al menos, dos maneras: (i) bien mediante la provisión de nuevos métodos que hayan sido concebidos dentro del paradigma del DSDM (p.e. [7]), (ii) o bien mediante la integración de métodos existentes en entornos de DSDM (p.e. [8]). El presente trabajo sigue el camino ii) mediante la integración del Análisis de Comunicaciones, en el ISSN SISTEDES

71 marco de OO-Method. El objetivo es proveer un entorno completo de desarrollo de SI que permita partir del modelado de requisitos, derivar y completar el modelo conceptual y generar la aplicación software final mediante compilación de modelos. El artículo contribuye con la presentación del proceso de integración, así como con la descripción detallada de la primera etapa, que incluye la integración teórica, el metamodelado de los métodos, la implementación de una herramienta de modelado y su validación. El artículo está estructurado de la siguiente manera. La Sección 2 presenta el método de ingeniería de requisitos Análisis de Comunicaciones. La Sección 3 describe la integración del Análisis de Comunicaciones en el entorno de desarrollo dirigido por modelos OO- Method. La Sección 4 presenta la validación de la propuesta. Por último, la Sección 5 comenta las lecciones aprendidas, presenta las conclusiones y anticipa trabajos futuros. 2. Aproximación comunicacional a la ingeniería de requisitos Los SI son sistemas socio-técnicos, un conjunto de agentes de diferente naturaleza que colaboran con el fin de soportar las comunicaciones dentro de una organización y con su entorno [11]. Por esto, el Análisis de Comunicaciones es un método de ingeniería de requisitos que propone afrontar el análisis de SI desde una perspectiva comunicacional [12]; es decir, la captura, análisis, especificación y verificación de requisitos se centran en las necesidades de comunicación de la organización. El Análisis de Comunicaciones propone una estructura de requisitos que permite una aproximación por refinamientos sucesivos. La Figura 1 muestra los cinco niveles de requisitos propuestos por el Análisis de Comunicaciones y las actividades asociadas a cada nivel, solo incluye actividades relacionadas con la especificación de requisitos; aquellas relacionadas con la captura, análisis, verificación y gestión se omiten para simplificar. La justificación de la aproximación y la estructura propuesta se presenta en [13]. En proyectos complejos, el sistema completo se refina en subsistemas (1). Cada proceso se modela mediante un diagrama de sucesos comunicativos (2). Se identifican los principales objetos de negocio (3). Cada suceso comunicativo se describe mediante una plantilla de especificación (4). Los objetos de negocio se especifican con más detalle (5). A continuación, la interfaz se diseña para dar soporte a la comunicación asociada a los sucesos (6). Se procede al modelado de la memoria del sistema (7). En este artículo se presenta un metamodelo y una herramienta cuyo objetivo es la especificación de los niveles 1, 2 y 3 de requisitos propuestos por el Análisis de Comunicaciones, centrándose en la perspectiva dinámica. La perspectiva estática encuentra soporte en muchas técnicas ya consolidadas. El Análisis de Comunicaciones ha sido validado de varias maneras complementarias, Se han realizado varios experimentos, donde se ha buscado analizar la calidad, completitud y cantidad de errores cuando se realizan modelos conceptuales teniendo como base éste método [19]. El método se aplica actualmente en grandes proyectos de entornos industriales. Estas experiencias demuestran que el método puede ser adoptado y puesto en práctica con éxito por equipos de desarrollo. 3. Integración en un entorno de DSDM 3.1. Proceso de integración Con el objetivo de integrar el método de Análisis de Comunicaciones en el entorno (DSDM) OO- Method, hemos distinguido dos etapas principales con dos fases cada una (figura 2). El punto de partida para este trabajo es una definición del Análisis de Comunicaciones basada en manuales metodológicos que incluyen descripciones de las actividades del método y las notaciones para los diagramas, así como plantillas de especificación y ejemplos ilustrativos. Es posible aplicar el método para especificar los requisitos usando papel y lápiz, por lo que puede afirmarse que su descripción de partida es independiente de computación. La etapa 1 se ocupa de adaptar el Análisis de Comunicaciones para permitir su integración en un entorno DSDM. Consiste en el análisis y especificación teórica del método de requisitos (fase 1) y el diseño e implementación de una herramienta de diagramación (fase 2). ISSN SISTEDES

72 Figura 1. Estructura básica y flujo de actividades del Análisis de Comunicaciones La etapa 2 se ocupa de la definición de las transformaciones de modelos con el fin de derivar modelos conceptuales a partir de modelos de requisitos; consiste en el análisis y especificación teórica de las reglas de derivación (fase 3) y el diseño e implementación de un módulo de transformación de modelos (fase4). La fase 1 consta de un análisis ontológico que permite establecer correspondencias entre elementos de una ontología de referencia [14] y las primitivas de modelado del método. También se realiza el diseño del metamodelo correspondiente a los modelos del Análisis de Comunicaciones. A este nivel, el Análisis de Comunicaciones se describe sin tomar en consideración la tecnología de implementación. Consideramos que el resultado de esta fase proporciona una descripción del método que es independiente de plataforma y, por tanto, es llamado Metamodelo PIM de Análisis de Comunicaciones. La fase 2 implica el diseño e implementación de una herramienta que soporte el método y facilite la integración en un entorno de DSDM, para lo cual es necesario especificar el metamodelo del Análisis de Comunicaciones tomando en consideración la plataforma Eclipse Modeling Framework (EMF) [15] sobre la que se ha elegido desarrollar la herramienta. Se trata, por tanto, de un metamodelo específico para EMF, al que llamamos Metamodelo PSM del Análisis de Comunicaciones. El siguiente paso es la implementación de la herramienta de diagramación, que se lleva a cabo siguiendo un proceso iterativo incremental. Se han realizado tres iteraciones, en las cuales las sucesivas versiones de la herramienta se someten a distintos tipos de validación. La fase 3 básicamente se ocupa de la definición de guías que permitan a un analista derivar el modelo conceptual a partir del modelo de requisitos. Puesto que el objetivo es independiente de plataforma, consideramos que se trata de Guías de derivación PIM. Para ello es posible apoyarse en el alineamiento conceptual de ambos métodos (las correspondencias entre sus primitivas de modelado razonadas a partir de las correspondencias de cada método con respecto a la ontología de referencia). La fase 4, se concentra en la definición de reglas de transformación y su implementación sobre EMF (se toma como base la especificación del lenguaje QVT [16]). Consideramos que son dependientes de plataforma y las llamamos Reglas de transformación PSM. Las reglas se implementarán como un módulo (plug-in) de transformación de modelos integrado con la herramienta de diagramación. Actualmente la etapa 1 ha sido completada con éxito y está comenzando análisis y especificación teórica de las transformaciones de modelos (etapa 2, fase 3) Metamodelado Durante el proceso de integración se puso de manifiesto que convenía razonar el metamodelado del Análisis de Comunicaciones a dos niveles. ISSN SISTEDES

73 Figura 2. Proceso de integración del Análisis de Comunicaciones en OO-Method Por un lado, el nivel independiente de plataforma permite describir los lenguajes de modelado que ofrece el método desde una perspectiva teórica, sin preocuparse de las particularidades de la plataforma de implementación de la herramienta de soporte. El Metamodelo PIM del Análisis de Comunicaciones (ver Figura 3) está expresado mediante un diagrama de clases de UML y construido usando una librería de formas para Microsoft Visio [18]. Más adelante este metamodelo es punto de partida para definir un Metamodelo PSM del Análisis de Comunicaciones adecuado para el desarrollo de la herramienta de diagramación y la definición de Guías de derivación PIM. Para la elaboración de este metamodelo se ha realizado un análisis de la superestructura de UML; especialmente donde se define el Diagrama de Actividad, debido a su similitud con el Diagrama de Sucesos Comunicativos (por la gran similitud de sus primitivas y formas de uso). Se ha empleado principalmente el subconjunto que define el concepto de nodo interconectado y el uso de las compuertas lógicas. El significado de cada metaclase se ha clarificado usando una plantilla de especificación que se encuentra registrada en el reporte técnico que puede ser accedido en [23]. El metamodelo fue evaluado varias veces por un experto en el método, en cada iteración, el experto aportaba sus sugerencias y correcciones en la interpretación de las características del método. Dichas evaluaciones se realizaron hasta que el metamodelo fue válido tanto en expresividad como en la claridad de las definiciones. La especificación al nivel de la plataforma EMF (ver Metamodelo PSM de Análisis de Comunicaciones en la Figura 4) permite su implementación. Este metamodelo se ha elaborado a partir de las especificaciones y restricciones que tiene Eclipse para modelos de UML 2.0. El metamodelo PSM contiene todas las metaclases del metamodelo PIM, y adicionalmente contiene metaclases necesarias para la implementación. Por ejemplo, las metaclases MODEL y ELEMENT son requeridas por EMF como contenedores de elementos, la primera, como contenedora global de elementos del modelo, y la segunda para establecer el contenedor de los elementos gráficos del modelo. Las metaclases STICKY_FIGURE_PRIMARY y STICKY_FIGURE_RECEIVER son necesarias para proporcionar la primitiva gráfica que permite representar los actores primario y receptor del sistema. Adicionalmente, el metamodelo especifica tipos de datos para los atributos, roles y cardinalidades Soporte a la diagramación Para la construcción del diagramador se ha usado el metamodelo PSM, el plug-in EMF, las herramientas proporcionadas por el componente Graphical Modeling Framework, y el soporte de OCL. Se ha desarrollado la especificación gráfica, una barra de herramientas, restricciones, y definición del entorno de diagramación. ISSN SISTEDES

74 El uso de la infraestructura Eclipse acarrea grandes ventajas, como el apoyo de una comunidad de desarrollo de código abierto, y permitirá su inclusión en la herramienta MOSKitt [17], una plataforma promovida por la Conselleria d'infraestructures i Transport de la Comunidad Valenciana que provee un entorno versátil y extensible gracias a su arquitectura de plug-ins. Adicionalmente, Moskitt tiene implementado un soporte para los modelos conceptuales de UML y BPMN, lo cual garantiza que dichos modelos pueden ser empleados en la fase de transformación de modelos. En la Figura 5 se puede apreciar una captura realizada a un modelo de Análisis de Comunicaciones desarrollado en la herramienta de modelado. Adicionalmente, la herramienta puede ser descargada de [23]. 4. Validación de la herramienta La herramienta de diagramación construida debe soportar plenamente el método para que el analista pueda desempeñar su labor con eficacia y debe proporcionar una interfaz usable para incrementar su eficiencia. Para cumplir con este objetivo, se han realizado las siguientes validaciones de la herramienta (véase la fase 2 en la Figura 2): una evaluación heurística de usabilidad y de expresividad, y una evaluación de usabilidad con Figura 3. Metamodelo PIM del Análisis de Comunicaciones usuarios (user testing). Respecto a la evaluación heurística, un experto en el método probó la herramienta para garantizar la expresividad de los modelos y para elaborar un primer informe de su usabilidad. Como reglas heurísticas se han empleado los 10 principios propuestos por Nielsen [20] y para especificar los problemas encontrados durante la evaluación heurística, se ha empleado la plantilla CUP adaptada a las necesidades de la evaluación efectuada [21]. Se encontraron un total de 4 problemas de expresividad y 25 problemas de usabilidad, que fueron priorizados. Tras la corrección de aquellos más severos se obtuvo una versión mejorada de la herramienta de modelado. A partir de esta versión mejorada se llevó a cabo una evaluación de usabilidad con 24 usuarios cuyo perfil es cercano al usuario final de la herramienta. Para la evaluación, primero se realizó una demostración sobre el uso básico de la herramienta, luego, los usuarios podían explorar la. Un modelo de Análisis de Comunicaciones era entregado a los usuarios en formato impreso, éstos debían tomar dicho modelo, e informatizarlo empleando la herramienta. Después, los usuarios completaron un cuestionario demográfico y unas cortas preguntas donde se podía analizar el grado de conocimientos en herramientas de modelado, modelado de procesos de negocio y Análisis de Comunicaciones. ISSN SISTEDES

75 Adicionalmente, los usuarios completaban el cuestionario de usabilidad CSUQ [22] con unas preguntas de respuesta libre que indagaban sobre las percepciones acerca de la herramienta. Finalmente se llevó a cabo una sesión de mesa redonda, donde cada usuario expresaba en voz alta sus apreciaciones, características positivas y negativas, mejoras sobre la herramienta. Luego de esta evaluación de usabilidad, se han recolectado una cantidad considerable de mejoras a la herramienta, donde se han identificado diferentes tipos de problemas de usabilidad y expresividad presentes, tanto en problemas desde el diseño de metamodelo PSM, como problemas que acarrea la tecnología Eclipse. A pesar de dichos problemas, en general, los usuarios manifestaron que la herramienta era fácil, ágil y permitía llevar a cabo la totalidad de la tarea impuesta a realizar. 5. Trabajos relacionados Actualmente existen diferentes herramientas destinadas a soportar el modelado de procesos de negocio. AuraPortal BPM [9] es un software que ofrece herramientas para la gestión empresarial. El modulo de BPM permite dar soporte a la gestión de proyectos, el cual ofrece un control de los detalles a nivel de Modelos, Orquestación, Figura 4. Metamodelo PSM del Análisis de Comunicaciones Monitoreo y expresión de reglas de negocio; dicha herramienta es de distribución comercial. Moskitt es un marco de modelado desarrollado bajo Eclipse, que incluye plug-ins para soportar las notaciones de BPMN y UML [10], Dicha herramienta es de distribución libre y goza de los beneficios de pertenecer a una comunidad de desarrollo de código abierto, como se ha explicado anteriormente. Recientemente se ha desarrollado un plug-in para Microsoft Visio por parte de la compañía Interfacing Technologies Corporation [18] el cual permite dar un soporte a la diagramación de modelos de BPMN, la distribución de la misma es a nivel comercial. Todas estas herramientas se enfocan principalmente en proveer un entorno para elaborar modelos de BPM y/o Diagrama de Actividades de UML. Aunque cabe resaltar que ninguna de estas herramientas ofrece un soporte para representar modelos enfocados a las técnicas de Análisis de Comunicaciones y adicionalmente en su mayoría, no son de código libre y su distribución es solo a nivel comercial. 6. Conclusiones y trabajos futuros La conveniencia de disponer de diversas estrategias para la ingeniería de requisitos que se puedan usar para llevar a cabo DSDM motiva esta investigación. ISSN SISTEDES

76 Figura 5. Modelo de Análisis de Comunicaciones desarrollado en la herramienta de modelado El objetivo es integrar el Análisis de Comunicaciones, un método de ingeniería de requisitos orientado a comunicaciones, con OO- Method, un entorno de DSDM orientado a objetos. De esta manera se podrá ofrecer una aproximación al DSDM que abarque desde la captura de requisitos hasta la generación automática de código. El artículo contribuye con la definición de un proceso de integración que tiene el potencial para ser instanciado con otros métodos y entornos DSDM. Asimismo, la diferenciación de dos niveles de metamodelado se justifica con la posibilidad de separar el razonamiento del metamodelo del método sin considerar una plataforma de implementación, del razonamiento de un metamodelo para su implementación en una plataforma específica. Se describen también las validaciones que se han efectuado de la herramienta, una evaluación de usabilidad heurística y de expresividad, y una evaluación de usabilidad con usuarios. Actualmente se trabaja en definir las guías de derivación de modelos conceptuales a partir de modelos de requisitos. Como trabajos futuros se contempla la finalización de la etapa 2. La integración de las herramientas desarrolladas en el entorno MOSKitt y a revisar los manuales metodológicos para documentar la aplicación de los métodos usando MOSKitt. También se planea, la puesta en práctica de un proyecto piloto para validar el nuevo entorno de DSDM. Agradecimientos Esta investigación ha sido soportada por el Ministerio Ciencia e Innovación de España bajo el proyecto SESAMO (TIN ) y el programa FPU (AP ), por la Generalitat Valenciana bajo el proyecto ORCA (PROMETEO/2009/015), y fondos FEDER. Manifestamos nuestro agradecimiento a Mario Cervera y a Jean Vanderdonckt por su amable colaboración y disposición. Referencias [1] The Standish Group, CHAOS Summary , The Standish Group International, Inc. [2] Bussen, W. and M.D. Myers, Executive information system failure: a New Zealand case study. Journal of Information Technology, : p [3] Foster, S.T. and C.R. Franz, User involvement during information systems development: a comparison of analyst and user perceptions of system acceptance. Journal of Engineering and Technology Management, : p ISSN SISTEDES

77 [4] Juristo, N., A. Moreno, and A. Silva, Is the European industry moving toward solving Requirements Engineering problems? IEEE Softw., (6): p [5] Zowghi, D. and C. Coulin, Requirements elicitation: a survey of techniques, approaches and tools in Engineering and managing software requirements, A. Aurum and C. Wohlin, Editors. 2005, Springer-Verlag New York, Inc. p [6] Nuseibeh, B. and S. Easterbrook, Requirements Engineering: a roadmap, in Conference on The Future of Software Engineering, in ICSE' , ACM: Limerick, Ireland. p [7] Kabanda, S. and M. Adigun, Extending model driven architecture benefits to requirements engineering, in 2006 Annual Research Conference of the SAICSIT on IT Research in Developing Countries. 2006, South African Institute for Computer Scientists and Information Technologists: Somerset West, South Africa. p [8] Alférez, M., et al., A model-driven approach for software product lines requirements engineering, in 20th International Conference on Software Engineering & Knowledge Engineering (SEKE'2008). 2008: San Francisco, USA. p [9] AuraPortal BPMS; Available from: [10] MOSKitt Módulo para Modelado de Procesos; Available from: [11] Lockemann, P.C. and H.C. Mayr, Information system design: techniques and software support, in Information Processing 86, H.-J. Kugler, Editor. 1986, North-Holland: Amsterdam, The Netherlands. [12] España, S., A. González, and Ó. Pastor, Communication Analysis: a Requirements Engineering method for information systems, in 21st International Conference on Advanced Information Systems (CAiSE'09). 2009, Springer LNCS 5565: Amsterdam, The Netherlands. p [13] González, A., S. España, and Ó. Pastor, Towards a communicational perspective for enterprise Information Systems modelling, in IFIP WG 8.1 Working Conference on The Practice of Enterprise Modeling: from Business Strategies to Enterprise Architectures (PoEM 2008), J. Stirna and A. Persson, Editors. 2008, Springer LNBIP 15: Stockholm, Sweden. p [14] Pastor, O., S. España, and A. González, An ontological-based approach to analyze software production methods, in Information Systems and e-business Technologies. United Information Systems Conferences (UNISCON 2008), R. Kaschek, et al., Editors. 2008, Springer Lecture Notes in Business Information Processing (LNBIP): Klagenfurt, Austria. p [15] Eclipse. Eclipse Modeling Framework (EMF) ]; Available from: [16] OMG. Meta Object Facility (MOF) 2.0 Query/View/Transformation specification (version 1.0) [cited /2010]; Available from: [17] CIT. MOSKitt: MOdeling Software Kitt [cited ]; Available from: [18] Visio Stencil and Template for UML 2.2; Available from: [19] España, S., et al., An empirical comparative evaluation of requirements engineering methods. J. Braz. Comp. Soc., (1): p [20] Nielsen, J., Heuristic evaluation, in Usability inspection methods, J. Nielsen and R.L. Mack, Editors. 1994, John Wiley and Sons: New York, USA. [21] Vilbergsdóttir, S.G., E.T. Hvannberg, and E.L.-C. Law, Classification of usability problems (CUP) scheme: augmentation and exploitation, in 4th Nordic Conference on Human-Computer Interaction: changing roles. 2006, ACM: Oslo, Norway. p [22] Lewis, J.R., IBM computer usability satisfaction questionnaires: psychometric evaluation and instructions for use. Int. J. Hum.-Comput. Interact., (1): p [23] Communicational Analysis Tools; Available from: ols/ ISSN SISTEDES

78 Modernizing Legacy Systems through Runtime Models Ricardo Pérez-Castillo 1, Barbara Weber 2, Ignacio García-Rodríguez de Guzmán 1 and Mario Piattini 1 1 Alarcos Research Group, University of Castilla-La Mancha Paseo de la Universidad, , Ciudad Real, Spain {ricardo.pdelcastillo, ignacio.grodriguez, mario.piattini}@uclm.es 2 University of Innsbruck Technikerstraße 21a, 6020 Innsbruck, Austria barbara.weber@uibk.ac.at Resumen Software modernization advocates reengineering processes for legacy information systems taking model-driven development principles into account. Modernization projects consider different legacy software artifacts as knowledge sources like, for example, source code, databases, user interfaces. In addition, the knowledge necessary to modernize a respective legacy system is extracted by analyzing the legacy artifacts in a static way. Unfortunately, there is a large amount of knowledge that is only known during system execution. Thus, this paper suggests a technique based on dynamic analysis of source code to obtain runtime models representing the system execution events. The technique is contextualized within MARBLE, a modernization framework to obtain business processes form legacy information systems. Firstly, the technique obtains a runtime model that represents events related to the execution of the business activities of the business processes supported by the legacy system. Secondly, a model transformation is proposed to obtain a higher-level model from the runtime model, which is represented according to an extended event metamodel of the Knowledge- Discovery Metamodel standard. As a consequence, the runtime model can be integrated and used in any modernization scenario in a standardized manner. 1. Introduction Most companies have existing information systems which can be considered as legacy systems, because the code in these systems was written long time ago and in the meantime is technologically obsolete. Legacy Information Systems (LISs) are information systems that significantly resist modification and evolution to meet new and constantly changing business requirements [19]. The continuous evolution implies that the maintainability of LISs eventually diminishes below acceptable limits requiring the LISs to be modernized [15]. Modernization means that the LIS is re-implemented using another, better platform or an enhanced design, while the business knowledge of the system is preserved [11]. When a LIS evolves over time it embeds much business knowledge. The preservation of this knowledge during system modernization is a very important challenge to be addressed for two main reasons: (i) the embedded knowledge is not present in any other artifact, and (ii) it must be considered to align the new improved system with the current business processes of the organization [9]. In the past, reengineering was the main tool for addressing the evolutionary maintenance of legacy systems preserving the business knowledge [1]. However, reengineering is usually carried out in an ad hoc manner, thus it fails when it is applied to large and complex LISs [23]. Since reengineering lacks formalization and standardization it is very difficult to automate reengineering for those large systems. Nowadays, the typical reengineering concept has shifted to so-called Architecture-Driven Modernization (ADM) [16] as a solution to the formalization and standardization problems. ADM advocates carrying out reengineering processes following the MDA (Model-Driven Architecture) standard [12], i.e., it treats all the legacy software artifacts as ISSN SISTEDES

79 models and establishes model transformations between the different MDA abstraction levels. In addition, ADM defines the standard KDM (Knowledge Discovery Metamodel), which has also been recognized as standard ISO [10]. KDM provides a common repository structure that makes it possible to exchange information about existing software artifacts involved in LISs. KDM can be compared with the Unified Modeling Language (UML) standard; while UML is used to generate new code in a top-down manner, ADMbased processes involving KDM start from the legacy source code and build a higher level model in a bottom-up manner [13]. There are several works in literature that address the problem of preserving the embedded business knowledge in software modernization processes. Zou et al developed a MDA-based framework for extracting business processes through static analysis of source code based on a set of heuristic rules [26]. Pérez-Castillo et al. [20] propose MARBLE, an ADM framework that uses the KDM standard to obtain business processes from legacy source code. Source code, however, is not the only legacy artifact considered to recover business knowledge. Di Francescomarino et al, for example, consider graphical user interfaces of Web applications to recover business processes [5]. Paradauskas et al. [19], in turn, present a framework to recover business knowledge through the inspection of the data stored in databases. Ghose et al [7] propose a set of text-based queries in source code and documentation for extracting business knowledge. In addition, Cai et al. [2] propose an approach that combines the requirement reacquisition aided by system users with static analysis. All these works are mainly based on a static view of LISs, and runtime models are often ignored to preserve the business knowledge. However, since there exists much valuable information that is only known during system execution, there is a big potential for exploiting runtime knowledge as well. This paper presents, within MARBLE, a reverse engineering technique based on dynamic analysis (combined with static analysis) of source code to obtain runtime models. Firstly, the static analysis syntactically analyzes the source code and injects pieces of source code in a non-invasive way in specific parts of the system. Secondly, the dynamic analysis of the modified source code makes it possible to write events during system execution. The events are written according to the MXML (Mining XML) metamodel [8], an XML format used in the process mining field to obtain event logs. The proposed technique is further supported by specific information provided by business experts and system analysts who know the system. The runtime models represent the events related to the underlying business processes that occur during system execution, thus these models provide another valuable source of knowledge to understand what is actually going on in a LIS from a dynamic perspective [24]. To facilitate the use of runtime models for modernizing LISs, this paper provides a model transformation between levels L1 and L2 of the MARBLE framework to represent the runtime models according to the KDM standard. Due to the fact that KDM is considered as the common modernization format for representing any legacy artifacts, these models can be used for any modernization framework. The remainder of this paper is organized as follows. Section 2 briefly introduces MARBLE, the modernization framework for which the technique is proposed. Section 3 presents the reverse engineering technique to obtain runtime models, and Section 4 shows the model transformation defined to represent runtime models in KDM. Finally, Section 5 provides conclusions and discusses future work. 2. MARBLE MARBLE (Modernization Approach for Recovering Business processes from LEgacy systems) [20] is an ADM-based framework for recovering business processes from legacy systems and business knowledge preservation. MARBLE is organized into four abstraction levels (cf. Section 2.1) representing four different kinds of artifacts needed to obtain the embedded business processes. In addition, MARBLE specifies three model transformations (cf. Section 2.2) to complete the path obtaining each kind of model at a specific level from the previous one (see Figure 1) Abstraction levels defined in MARBLE MARBLE defines four abstraction levels related to four different kinds of models: L0 to L3. These ISSN SISTEDES

80 models are progressively refined from legacy software artifacts in L0 until business process models are obtained in L3 (see Figure 1). L0. Legacy information system. This level represents the entire legacy system in the real world, i.e. a set of interrelated software artifacts like source code, user interfaces, databases, documentation. L1. Software artifacts models. This level contains a set of models representing one or more software artifacts of the LIS. L1 models can be seen as platform-specific models (PSM) because they represent different views or concerns of the system from a technological point of view at a lower abstraction level. As a consequence, L1 models must be represented according to specific metamodels (e.g. a hypothetic L1 level could be formed by a code model represented according to the Java metamodel and a database model depicted according to the SQL metamodel). L2. KDM model. This level integrates all knowledge of the L1 models in a single model, but at a higher abstraction level. This model represents the entire LIS from a platform-independent point of view at an intermediate abstraction level (PIM). This model is represented according to the metamodel of the KDM standard. KDM provides a common repository structure that makes it possible to exchange information about artifacts involved in the LIS. L3. Business process model. L3 is the top level and corresponds to a business process model that represents the recovered business processes. This model can be seen as computer-independent models (CIM), since it depicts a business view of the system from a computation independent viewpoint at the highest abstraction level. MARBLE uses the metamodel of the BPMN (Business Process Modeling and Notation) standard [18] for representing the business process model. BPMN offers a well-known graphical notation that is easily understood by both system analysts and business experts. Reverse engineering techniques applied to different software artifacts as static/dynamic analysis, slicing, and so on L0 L1 code{ } MM L1 (Java MM) L2 L3 MM L1 L2 L3 (BPMN) PSM to PIM model transformation implemented through QVT MM L2 (KDM) QVT transformations based on pattern matching and business expert refinement KDM L0. LIS L1. LIS models L2. KDM models L3. BP models Figure 1. Abstraction level organization and model transformation in MARBLE. ISSN SISTEDES

81 2.2. Model transformations in MARBLE Besides different abstraction levels, MARBLE defines three model transformations between the four abstraction levels (see Figure 1). L0-to-L1 transformation. The first transformation takes the different software artifacts from the LIS (L0) and obtains a specific model for each artifact (L1). This transformation takes software artifacts into account depending on the specific business process recovery method based on MARBLE (since MARBLE defines a generic framework). So far, we consider a recovery method using MARBLE, which considers legacy source code as the unique software artifact, since it is the artifact that embeds most business knowledge [14]. In this case, the L0-to-L1 transformation consists of the static analysis of the source code files carried out by means of a syntactical parser, which generates a source code model according to the proper metamodel. L1-to-L2 transformation. The second transformation establishes the model transformation between the code model (the PSM model in L1) and the KDM code model (the PIM model in L2). The KDM metamodel is divided into different metamodel packages organized into four abstraction layers. Each package focuses on modeling a different concern of the LIS. Currently, the KDM model in L2 only considers the KDM packages code and action that conform to the program element layer. These packages are enough to represent all concepts of the code models of L1 at a higher abstraction level in L2. This model transformation is formalized by means of QVT (Query / Views / Transformations) [17]. L2-to-L3 transformation. The third transformation aims to obtain a business process model in L3 from the KDM model in L2. This transformation consists of two steps: (i) a model transformation that obtains a set of preliminary business process models; and (ii) an optional manual intervention by business experts for refining the obtained business processes to improve them. So far, the model transformation of the first step uses a set of business patterns [21], which define what pieces of the source code (represented in the KDM model) are transformed into wellknown structures of business processes. Then, the pattern matching following those patterns is implemented using QVT [22]. 3. A Technique to Obtain Runtime models Despite source code models are valuable models at level L1 of MARBLE, there are specific, relevant aspects of the source code (e.g. the accurate execution order of the pieces of source code, dead source code) which are lost if only static analysis is used. Thus, dynamic analysis can be used together with static analysis, additionally considering knowledge related to system execution, to obtain more meaningful business knowledge. For this reason, we propose a technique based on dynamic analysis to extract runtime models at level L1 of MARBLE. The technique proposes the representation of runtime models as event logs derived from the system execution. Event logs are commonly used in the process mining field as the input for several mining algorithms to discover the business process of an organization [3]. Thereby, event logs save the list of business activities carried out in an organization according to their business processes. Usually, these event logs are obtained from Process-Aware Information Systems (PAIS) [6], i.e., process management systems (e.g. Enterprise Resource Planning (ERP) or Customer Relationship Management (CRM) systems). The nature of these systems (in particular their process-awareness) facilitates the registration of events throughout process execution. The vast majority of LISs, however, are non process-aware systems that also support the business processes of organizations. Obtaining an event log of a non process-aware system and representing it in a model at level L1 of MARBLE implies five key challenges: Challenge C1. Missing Process-Awareness. Process definitions are implicitly described in legacy code. A traditional LIS consists of a control flow graph implicitly representing the business process it supports. Thus, it is not obvious which events (related to a specific business activity) should be recorded in the event log. To address this challenge, the technique considers the a callable unit / a ISSN SISTEDES

82 business activity principle proposed by Zou et al. [25]. Challenge C2. Granularity. While some of the callable units of LISs support the main business functionalities, many callable units are very small and do not directly support any business activity (e.g. setter/getter methods, printer methods, etc.). Challenge C3. Discarding Technical Code. Legacy source code not only contains business activities, but also technical aspects which have to be discarded when the runtime model is obtained. Challenge C4. Process Scope. Due to the fact that traditional LISs do not explicitly define processes, it has to be established when a process starts and ends. Unfortunately, this information is only known by business experts and system analysts. Challenge C5. Process Instance Scope. It is not obvious how business activities and the multiples instances of a process should be correlated. To solve this challenge the system analyst s knowledge is necessary. Our technique for obtaining runtime models representing an event log is based on a static analysis of source code combined with a dynamic analysis. Firstly, the static analysis examines the legacy source code and modifies it by injecting code for writing specific events during its execution (cf. Section 3.1). After the static analysis has been conducted, the modified source code is dynamically analyzed at runtime by means of the injected sentences (cf. Section 3.2). Figure 2 gives an overview of the technique, the tasks carried out and their inputs/outputs Static analysis to modify the source code The static analysis modifies the original source code in a non invasive way to enable the registration of events during system execution (see Figure 2). To address the previously introduced challenges, the static analysis is supported with information provided by business experts and system analysts. In Task 1, business experts establish the start and end business activities of the business processes to be discovered (Challenge C4). In parallel, system analysts examine in Task 2 the legacy source code and filter the domain set of the directories, files or specific callable units that support business activities. This information is used to reduce potential noise in the runtime model due to technical source code (Challenge C3). Task 3 consists of the mapping by system analysts between start/end business activities and the callable units supporting them (Challenge C4). In addition, system analysts establish through Task 4 the correlation data set for each callable unit which is uniquely identifying a process instance (Challenge C5). Each correlation data is mapped to one or more parameters of each callable unit by system analysts. Finally, Task 5 carries out the syntactic analysis of the source code. A parser analyzes and injects on the fly the sentences for writing the event long during system execution. Business Expert 1. Provide Starting/Ending Business Activities Starting/ Ending Business Activities 2. Set Files/ Directories of Problem Domain Problem Domain Callable Units 3. Map Starting/ Ending Activities with callable units Starting/ Ending Callable Units System Analyst 4. Define Correlation Set of Attributes Correlation Sets of Callable Units MARBLE Tool L0 Legacy Source Code 5. Inject Trace Senteces (Static Analysis) Modified Source Code 6. System Execution (Dynamic Analysis) L1 Runtime Model Figure 2. The overall process carried out by means of the proposed technique. ISSN SISTEDES

83 Task 5 is automated following the algorithm presented in Figure 3. During the static analysis, the source code is broken down into callable units (Challenge C1), although the algorithm only modifies the units of the domain set selected by system analysts in Task 3 (Challenge C3). In addition, fine-grained callable units (e.g., setter, getter, constructor, tostring and equals callable units) are automatically discarded (Challenge C2). After that, two sentences are injected at the beginning and the end of each filtered callable unit. The first sentence writes a start event related to the business activity mapped to the callable unit. This sentence is injected between the signature and the body of the callable unit. The second sentence writes an end event for the respective business activity and is injected at the end of the body. Both sentences have additional parameters like the correlation data defined for the unit and the information whether or not the unit represents a start or end activity. This additional information is used when the injected sentences invoke the writeevent function at runtime, which writes the respective event into the runtime model (cf. Section 3.2). injecttraces (CallableUnits, DomainCallableUnits, StartingCallableUnits, EndingCallableUnits) ModifiedCallableUnits ɸ c null For (c CallableUnits) If (c DomainCallableUnits and isfinegrainedunit(c)) If (c StartingCallableUnits) position first Else If (c EndingCallableUnits) position last Else position intermediate sentence 1 writeevent (c.name, start, position, c.correlationset) sentence 2 writeevent (c.name, complete, position, c.correlationset) c.signature c.signature c.body sentence 1 + c.body + sentence 2 ModifiedCallableUnits ModifiedCallableUnits {c } Else ModifiedCallableUnits ModifiedCallableUnits {c} Return ModifiedCallableUnits 3.2. Dynamic analysis to obtain runtime models After having modified the source code through static analysis it is released to production. The new code makes it possible to obtain runtime models representing the event log of the LIS. These runtime models are represented in MARBLE according to a metamodel based on the MXML format [8], which is used in the process mining field. Figure 4 shows the MXML metamodel, which provides the WorkflowLog metaclass to represent an event log as a set of instances of the Process metaclass. Each Process element contains several ProcessInstances, which have a sequence of AuditTrailEntry elements. Each AuditTrailEntry element represents an event and consists of four main elements: (i) the WorkflowModelElement that represents the executed activity; (ii) the EventType that represents if the activity is being executed (start) or was completed (complete); (iii) the Originator that provides the user who starts or completes the activity; and finally (iv) the Timestamp that records the date and time of the event. Moreover, all these elements can have a Data element including additional information endorsed into Attribute elements. Dynamic analysis is automatically carried out during system execution. Thus, when the control flow of the LIS reaches an injected sentence, a new event is added to the event log. The events are written by means of the writeevent function. Before adding the new event representing a business activity to the runtime model, it is necessary to find out the correct process and process instance where the event must be added. The adequate process and process instance are located by means of Xpath expressions [4]. If the process is null, then a new process is created. In addition, these expressions take the correlation data into account to establish the correct process instance. The attributes that contain the correlation data were already established during static analysis, however, their values are only known during system execution. Figure 3. Algorithm to inject trace sentences by means of static analysis. ISSN SISTEDES

84 Figure 4. MXML Metamodel used to represent runtime models in MARBLE. Figure 5. Finally, when the writeevent function has determined the correct process instance, it adds the event to that particular instance. The event, represented as an AuditTrailEntry element in the runtime model according to the MXML metamodel, is created using: (i) the name of the executed callable unit represents the WorkflowModelElement; (ii) the event type that is also a parameter of this function; (iii) the user of the system that executed the callable unit (or the user of the session if the system is a web application), which represents the originator element; and finally (iv) the system date and time when the callable unit was executed to represent the timestamp element. Event metamodel package in the KDM standard 4. Runtime Models in KDM This paper also provides the model transformation between levels L1 and L2 of MARBLE, in order to represent the runtime models according to the KDM standard. As a consequence, this runtime model can be used in any software modernization context. Specifically, the runtime models are represented using the event metamodel package of the runtime resource layer of the KDM metamodel [10]. Figure 5 shows the event metamodel package as well as other metaclasses of other KDM packages used in the runtime ISSN SISTEDES

85 models. The EventModel metaclass represents the runtime model, which contains a set of EventResource and EventAction elements. An EventResource element can be specialized into a State element, a Transition element, an Event element, or it can even be a container of other EventResources. The Event element is used to model the AuditTrailEntries of the runtime model represented according to the MXML metamodel in L1. The feature name represents the WorkflowModelElement, and the feature kind represents (with a start or complete value) the EventType. The transformation is formalized by means of QVT-Relations (the declarative language of the QVT standard). A relation transforms a MXML model in L1into an instance of the EventModel metaclass. This relation calls to the relation audittrailentry2event that transforms each AuditTrailEntry in L1 into an Event in L2 (see Figure 6). The event metamodel package of KDM makes it impossible to represent the process and process instance where the event belongs as well as the originator and timestamp of the event (see Figure 5). For this reason, the proposal uses the default extension mechanism of the KDM metamodel: the extension families. The EventModel includes an ExtensionFamily element (see Figure 6), which defines four Stereotype elements: <process>, <processinstance>, <originator> and <timestamp>. Each stereotype has a TagDefinition element that is used by stereotyped elements of the runtime model to put the specific value by means of a respective TaggedValue element. Therefore, the problematic elements are represented in KDM as follows: (i) A process is represented as an EventResource element annotated with the <process> stereotype and containing a TaggedValue with the name of the process. (ii) A process instance is also represented as an EventResource element, which is nested within another EventResource that represents a process. This EventResource is annotated with the <processinstance> stereotype and contains a TaggedValue with the process instance identification. (iii) The originator is represented as a TaggedValue associated to an Event stereotyped as <originator>. (iv) The timestamp is also represented with a TaggedValue in an Event annotated with the <timestamp> stereotype. <<checkonly>> p : Process name=xprocessname pi : ProcessInstance name=xprocessinstancename ate:audittrailentry eventtype <<checkonly>> <<checkonly>> type : EventType type = xeventtype MXML MXML e : WorkflowModelElement name = xeventname timestamp MXML When Where originator workflowmodelelement stp : Stereotype tp : TagDefinition tag = process t : Timestamp name = xdate o : Orignitaror name = xoriginatorname audittrailentry2event runtimeextension : ExtensionFamily stpi : Stereotype tpi : TagDefinition tag = processinstance vp:taggedvalue value=xprocessname tp : TagDefinition tag= process vo : TaggedValue value =xoriginatorname to : TagDefinition tag = originator so : Stereotype tp : TagDefinition tag = originator KDM Event st : Stereotype tt : TagDefinition tag = timestamp vpi:taggedvalue value=xprocessinstancename tpi : TagDefinition tag= processinstance vt : TagDefinition value=xdate tt : TagDefinition tag = timestamp nextevent : EventRelationship from : Event name =xeventname <<enforce>> eventmodel:eventmodel process : EventResource name= Process processinstance : EventResource name= ProcessInstance event : Event name=xeventname kind=xeventtype implementation : CodeElement name=xeventname to : Event name=querynextevent Figure 6. The QVT relation audittrailentry2event to transform runtime models in L1 to KDM models in L2. ISSN SISTEDES

86 Despite the fact that the order of the events can be derived from the timestamp information, the relation audittrailentry2event (see Figure 6) establishes at level L2 the same sequence of events register in the model at level L1. This order is represented as an EventRelationship element within each Event representing a reference to the next Event element. Finally, the relation audittrailentry2event (see Figure 6) maps each Event to a CodeElement of the KDM code model. The resource runtime layer of the event package is above the program element layer (that contains the code and action metamodel packages), thus the elements of a runtime model can be mapped to the callable units represented in the KDM code model. As a consequence, the feature location is also improved throughout the modernization of a LIS. 5. Conclusions and Future Work Software modernization projects typically take several software artifacts as source of knowledge into account like, for example, source code, databases, user interfaces. Thereby, modernization projects often recover knowledge from a static point of view. However, a dynamic approach allows modernization projects to extract more meaningful knowledge, which cannot be recovered analyzing artifacts in a static way only. For this reason, this paper proposes a technique, within a specific modernization framework (i.e., MARBLE), to obtain runtime models by means of dynamic analysis of source code. Firstly, the proposed technique statically analyzes the legacy source code, and modifies it by injecting special sentences that make it possible to register execution events. Secondly, during system execution, the modified code is dynamically analyzed through the injected sentences and a runtime model is written at level L1of MARBLE. The obtained runtime models represent an event log according to the MXML metamodel, and depict a sequence of executed events related to business activities of the business processes embedded in the source code. Moreover, the runtime model is transformed into a runtime model represented at level L2 of MARBLE according to the KDM metamodel. For this purpose, an extension of the event package of the KDM metamodel is proposed as well as a model transformations implemented by means of QVT-Relation. Due to the fact that the runtime model is represented following the KDM standard, the proposed technique can be used in other modernization frameworks based on ADM as MARBLE. The future work will focus on the validation of the proposal by means of a case study involving a real-life LIS in a healthcare context. Another research direction in the future will be the use of the runtime models combined with other models of KDM as the code and data model in order to obtain more meaningful business process models at level L3 of MARBLE. Acknowledgement This work was supported by the FPU Spanish Program; by the R+D projects funded by JCCM: ALTAMIRA (PII2I ), INGENIO (PAC ) and PRALIN (PAC ); and the PEGASO/MAGO project (TIN C02-01) funded by MICINN and FEDER. In addition, this work was supported by the Quality Engineering group at the University of Innsbruck. References [1] Bianchi, A., D. Caivano, V. Marengo, and G. Visaggio, "Iterative Reengineering of Legacy Systems". IEEE Trans. Softw. Eng., (3): p [2] Cai, Z., X. Yang, and W. Wang. "Business Process Recovery for System Maintenance - An Empirical Approach". in 25 th International Conference on Software Maintenance (ICSM'09) Edmonton, Canada: IEEE CS p [3] Castellanos, M., K.A.d. Medeiros, J. Mendling, B. Weber, and A.J.M.M. Weitjers, Business Process Intelligence, in Handbook of Research on Business Process Modeling, J. J. Cardoso and W.M.P. van der Aalst, Editors. 2009, Idea Group Inc. p [4] Clark, J. and S. DeRose, XML Path Language (XPath). 1999, World Wide Web Consortium (W3C). [5] Di Francescomarino, C., A. Marchetto, and P. Tonella. "Reverse Engineering of Business Processes exposed as Web Applications". in ISSN SISTEDES

87 13th European Conference on Software Maintenance and Reengineering (CSMR'09) Fraunhofer IESE, Kaiserslautern, Germany: IEEE Computer Society p [6] Dumas, M., W. van der Aalst, and A. Ter Hofstede, Process-aware information systems: bridging people and software through process technology. 2005: John Wiley & Sons, Inc. [7] Ghose, A., G. Koliadis, and A. Chueng. "Process Discovery from Model and Text Artefacts". in IEEE Congress on Services (Services'07) p [8] Günther, C.W. and W.M.P. van der Aalst, "A Generic Import Framework for Process Event Logs". Business Process Intelligence Workshop (BPI'06), LNCS 4103: p [9] Heuvel, W.-J.v.d., Aligning Modern Business Processes and Legacy Systems: A Component-Based Perspective (Cooperative Information Systems). 2006: The MIT Press. [10] ISO/IEC, ISO/IEC DIS Knowledge Discovery Meta-model (KDM), v1.1 (Architecture-Driven Modernization). snumber= , ISO/IEC. p [11] Khusidman, V. and W. Ulrich, Architecture- Driven Modernization: Transforming the Enterprise. DRAFT V , OMG. p. 7. [12] Miller, J. and J. Mukerji, MDA Guide Version : OMG. [13] Moyer, B. (2009) Software Archeology. Modernizing Old Systems. Embedded Technology Journal, y_4-mar-2009.pdf [14] Müller, H.A., J.H. Jahnke, D.B. Smith, M.-A. Storey, S.R. Tilley, and K. Wong. "Reverse engineering: a roadmap". in Proceedings of the Conference on The Future of Software Engineering Limerick, Ireland: ACM. [15] Newcomb, P. "Architecture-Driven Modernization (ADM)". in Proceedings of the 12th Working Conference on Reverse Engineering. 2005: IEEE Computer Society. [16] OMG. ADM Task Force by OMG /06/2009 [cited /06/2009]; Available from: [17] OMG, QVT. Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification. 2008, OMG. [18] OMG, Business Process Model and Notation (BPMN) , Object Management Group. p [19] Paradauskas, B. and A. Laurikaitis, "Business Knowledge Extraction from Legacy Information Systems". Journal of Information Technology and Control, (3): p [20] Pérez-Castillo, R., I. García-Rodríguez de Guzmán, O. Ávila-García, and M. Piattini. "MARBLE: A Modernization Approach for Recovering Business Processes from Legacy Systems". in International Workshop on Reverse Engineering Models from Software Artifacts (REM'09) Lille, France: Simula Research Laboratory Reports p [21] Pérez-Castillo, R., I. García-Rodríguez de Guzmán, O. Ávila-García, and M. Piattini. "Business Process Patterns for Software Archeology". in 25th Annual ACM Symposium on Applied Computing (SAC'10) Sierre, Switzerland: ACM p [22] Pérez-Castillo, R., I. García-Rodríguez de Guzmán, and M. Piattini. "Implementing Business Process Recovery Patterns through QVT Transformations". in International Conference on Model Transformation (ICMT'10) Málaga, Spain: Springer- Verlag p. In Press. [23] Sneed, H.M., Estimating the Costs of a Reengineering Project. Proceedings of the 12th Working Conference on Reverse Engineering. 2005: IEEE Computer Society. [24] van der Aalst, W., H. Reijers, and A. Weijters, "Business Process Mining: An Industrial Application.". Information Systems, (5): p [25] Zou, Y. and M. Hung. "An Approach for Extracting Workflows from E-Commerce Applications". in Proceedings of the Fourteenth International Conference on Program Comprehension. 2006: IEEE Computer Society p [26] Zou, Y., T.C. Lau, K. Kontogiannis, T. Tong, and R. McKegney. "Model-Driven Business Process Recovery". in Proceedings of the 11th Working Conference on Reverse Engineering (WCRE 2004). 2004: IEEE Computer Society p ISSN SISTEDES

88 Decisiones arquitectónicas y tecnológicas como líneas de producto en el desarrollo dirigido por modelos José García-Alonso, Javier Berrocal Olmeda, Juan M. Murillo Escuela Politécnica Universidad de Extremadura jgaralo@unex.es, jberolm@unex.es, juanmamu@unex.es Resumen Gran parte de los sistemas de desarrollo de software dirigido por modelos limitan a los desarrolladores a la hora de elegir la arquitectura software en la que se va a basar la aplicación a desarrollar o las tecnologías que se van a utilizar para la implementación. Este artículo adopta la forma de Position Paper en el que se argumenta cómo facilitar el paso de la arquitectura preliminar a la detallada y exibilizar la elección de la tecnología de construcción tratando la arquitectura como una línea de producto. 1. Introducción Los métodos y técnicas propuestos por la disciplina de Desarrollo de Software Dirigido por Modelos han demostrado su capacidad para crear sistemas de gran complejidad. Especialmente prolija ha sido el área de ingeniería web [23], donde han proliferado gran número de métodos y herramientas tanto a nivel académico como comercial. Algunos de los sistemas más representativos en este campo son WebML [7], UWE [19], OOWS [24] o RUX [20]. Utilizando estos sistemas es posible desarrollar grandes aplicaciones web a partir de diversos modelos del sistema. El código de la aplicación es generado a partir de dichos modelos. Generalmente, las aplicaciones creadas con estas técnicas utilizan arquitecturas software[25] avanzadas como arquitecturas multicapa [10] o arquitecturas Model-View-Controller (MVC) [18]. En este trabajo se atacarán dos problemas que se producen en este ámbito. De un lado, los problemas derivados de la complejidad de los modelos necesarios para desarrollar las aplicaciones. Por otro lado, los problemas motivados por la elección de una metodología de desarrollo dirigido por modelos como las citadas anteriormente. Los modelos que deben crearse durante un desarrollo capturan toda la información necesaria para generar la aplicación. Esto hace difícil la tarea de crear dichos modelos partiendo de un diseño de alto nivel de la aplicación que contenga los requisitos de la misma. Además, para simplicar estos modelos en la medida de lo posible, en la mayoría de los casos se utiliza una arquitectura software implícita que no puede ser modicada por los desarrolladores. Esto hace que todas las aplicaciones desarrolladas deban ceñirse a una arquitectura concreta. Por lo tanto, se imposibilita el uso de estos sistemas cuando la aplicación a desarrollar cuente con requisitos arquitectónicos que no se adaptan a la arquitectura proporcionada. Por otra parte, la elección de una metodología de desarrollo dirigido por modelos (WebML, UWE, etc.) compromete la elección de las tecnologías sobre las que se va a llevar a cabo el desarrollo. Usualmente, el código generado por estos sistemas hace uso de diversas tecnologías como frameworks orientados a objetos [12] o librerías. Sin embargo, no se permite a los desarrolladores decidir qué frameworks van a utilizarse o cómo estos van a ser utili- ISSN SISTEDES

89 zados. Esto hace que no sea posible utilizar uno de estos sistemas cuando la aplicación a desarrollar deba cumplir con requisitos tecnológicos distintos a los soportados. Este es un Position Paper en el que se argumenta cómo facilitar el paso de la arquitectura preliminar a la detallada y exibilizar la elección de la tecnología de construcción. Para ello se propone un enfoque novedoso en el que las arquitecturas software de las aplicaciones a desarrollar se tratan como líneas de producto [6]. El método presentado en este trabajo se encuentra en un estado inicial. El principal objetivo que se persigue con la presentación de este trabajo en un estado tan temprano es el de obtener las impresiones de la comunidad acerca de la validez del mismo y las posibles carencias que pueda contener. El resto del artículo se distribuye de la siguiente forma: en la segunda sección se detallan los antecedentes que han llevado al desarrollo de este trabajo; en la tercera sección se describe como modelar la arquitectura y los frameworks a utilizar y como, aplicando dicha información, transformar el diseño de alto nivel de la aplicación en un diseño detallado especíco de dichos frameworks y conforme a la arquitectura elegida; en la cuarta sección se enumeran algunas posibilidades para transformar dicho diseño en código y por último se detallan las conclusiones y los trabajos futuros. 2. Antecedentes La constantemente creciente complejidad de las aplicaciones hace necesaria la utilización de técnicas, cada vez más avanzadas a su vez, para abordar los desarrollos con ciertas garantías. Las arquitecturas software [25] y los patrones de diseño [15] son técnicas creadas en el ámbito de la ingeniería del software para tratar este problema. Con su utilización se pretende describir y reutilizar aquellas estructuras que dan lugar a aplicaciones estables y de calidad. Uno de los principales retos, a la hora de desarrollar una aplicación para una arquitectura concreta, consiste en adaptar el diseño preliminar de la aplicación a las peculiaridades de la arquitectura elegida. Este es un proceso complejo que requiere amplios conocimientos de la arquitectura y de los patrones de diseño que se van a aplicar. Para ejemplicar este proceso se puede pensar en una aplicación que deba soportar una gestión básica de clientes. La aplicación debe permitir almacenar los datos de los clientes, actualizarlos cuando sea necesario y realizar búsquedas sobre ellos. Para este ejemplo tan sencillo el diseño inicial de la aplicación podría estar compuesto de un diagrama de clases en el que aparezca la clase Cliente, con los atributos necesarios para almacenar toda la información relativa a los clientes y algunos métodos. Adicionalmente se podría disponer de un diagrama de casos de uso en el que aparezcan los casos de uso relativos a la gestión de los clientes y posiblemente algunos diagramas de secuencia o actividad. En la gura 1 se observa el diagrama de clases con la clase Cliente. Convertir el diseño preliminar obtenido exclusivamente a partir de los requisitos sin tener en cuenta los detalles de la arquitectura a utilizar, en un diseño especíco para una aplicación con una arquitectura en tres capas no es un proceso trivial. Además los diagramas que componen este diseño empiezan a complicarse. En la gura 2 puede verse el diagrama de clases para la aplicación de gestión de clientes adaptada a una arquitectura en tres capas. En él, la clase inicial Cliente se ha dividido en tres clases que encapsulan el comportamiento relativo a la persistencia de los datos de los clientes, a la lógica de negocio y a la presentación respectivamente. Este diseño se complica aun más si se establece una arquitectura con mayor grado de detalle. Aunque el diseño anterior corresponde a una arquitectura en tres capas, esta arquitectura raramente se utiliza en una forma tan sencilla. Habitualmente esta arquitectura se enriquece con patrones de diseño como el patrón Data Access Object (DAO) [31] para la capa de persistencia o con la utilización de MVC [18] para la presentación. Si incorporamos estos elementos al ejemplo utilizado se obtiene un diagrama de clases similar al mostrado en la gura 3. En este diagrama se observa como ISSN SISTEDES

90 Figura 1: Diagrama de clases para la aplicación de gestión de clientes la clase que se ocupaba de la persistencia de los datos de los clientes se ha descompuesto en dos clases para seguir el patrón DAO y la clase encargada de la presentación se ha descompuesto en varios elementos para seguir la arquitectura MVC. Este diseño empieza a parecerse a un diseño real, especíco de una aplicación en tres capas. Sin embargo, en un caso real el diseño se complica aun más al incorporar soporte a otros aspectos obviados hasta ahora como pueden ser la seguridad, el sistema de log o las pruebas unitarias y de integración. Puede verse claramente la complejidad de dar el paso del diseño inicial de una aplicación a un diseño adaptado a una arquitectura concreta. En el ejemplo mostrado aquí, una clase de diseño de alto nivel ha dado lugar a más de cinco clases en el diseño especíco de la arquitectura. En una aplicación real con decenas o cientos de clases en el diseño inicial, el paso a un diseño especíco supone una tarea ardua y difícil que requiere grandes conocimientos. Por otra parte, la mayoría de los sistemas de desarrollo dirigido por modelos, exceptuando los trabajos de Meliá y Gómez en WebSA [21] y más recientemente en aplicaciones RIA (Rich Internet Application) [22], se centran en la utilización de una única arquitectura software de forma implícita. Esta arquitectura no puede ser elegida ni modicada por los usuarios de este tipo de sistemas. Además, para utilizar estos sistemas es necesario convertir los dise- Figura 2: Gestión de clientes en una arquitectura en tres capas ños de alto nivel de la aplicación a desarrollar en los modelos especícos del sistema utilizado [3]. Como se ha podido ver en el ejemplo esta es una tarea difícil y que requiere grandes conocimientos tanto de la aplicación a desarrollar como del sistema de desarrollo utilizado. Esto conlleva una serie de consecuencias negativas, entre las que destacan la elevada curva de aprendizaje, que obliga a proporcionar una formación muy especíca, la dependencia del conocimiento de personas que pueden abandonar el equipo de desarrollo o la dependencia de un conocimiento que nunca acaba de residir en las empresas de desarrollo sino en las personas con la formación especíca. El segundo problema que se abordará en este trabajo se presenta una vez que se dispone de un diseño especíco para una arquitectura, como el que se muestra en el ejemplo. Partiendo de este diseño es posible pasar a la implementación del sistema, ya sea manualmente o mediante transformaciones de modelo a códi- ISSN SISTEDES

91 Figura 3: Gestión de clientes con patrón DAO y MVC go. Para facilitar la incorporación de arquitecturas software y patrones de diseño a los desarrollos han surgido un gran número de frameworks orientados a objetos [12]. La utilización de estos frameworks permite trasladar a la implementación de las aplicaciones estructuras y patrones altamente probados, estables y ecientes. Esto se debe a que dichos frameworks proporcionan un conjunto de conceptos, especícos de un dominio, que pueden ser reutilizados por la aplicación. Debido a estas ventajas, estos frameworks son ampliamente utilizados tanto en los desarrollos tradicionales como por las herramientas de desarrollo dirigido por modelos. No obstante, el uso de estos frameworks plantea una serie de inconvenientes. Uno de los principales inconvenientes es la dicultad de utilización de los mismos. La curva de aprendizaje de los frameworks suele ser muy elevada y requiere grandes esfuerzos por parte de los desarrolladores. Numerosos trabajos tratan de mitigar este problema [27] [11]. Además, un framework de este tipo no suele utilizarse de forma aislada, sino que se usa en conjunción con otros frameworks [13]. La composición de los diversos frameworks que intervienen en una aplicación para que se comuniquen de forma correcta entre sí y con el código de la aplicación es una tarea muy delicada. Adicionalmente, el código de la aplicación que hace uso de los conceptos proporcionados por los frameworks suele estar disperso por todo el proyecto, lo que diculta su mantenimiento y la actualización a nuevas versiones [1]. Gran parte de los problemas que plantea la utilización de frameworks de desarrollo puede solucionarse mediante la aplicación de técnicas de desarrollo dirigido por modelos, como puede apreciarse en los trabajos de Antiekwicz et al [1] [2]. Sin embargo, aunque un elevado número de las herramientas que permiten el desarrollo dirigido por modelos generan un código que hace uso de este tipo de frameworks, no se permite a los usuarios elegir el o los frameworks que va a utilizar el código generado de una aplicación, ni la forma en que dichos frameworks van a ser utilizados. Esto puede ser un inconveniente puesto que existen numerosos frameworks que cubren una misma funcionalidad o concepto cada uno con distintas características. El desarrollador debería poder decidir que framework o frameworks se adaptan mejor a las características de cada aplicación. El hecho de no permitir al desarrollador elegir los frameworks a utilizar conlleva una serie de consecuencias negativas. Entre ellas destacan la imposibilidad de utilizar estos sistemas con aplicaciones legadas que utilicen otra tecnología, la falta de adaptación a los requisitos tecnológicos de los clientes, los problemas o incompatibilidades surgidos de utilizar una versión de un framework en lugar de otra o la imposibilidad de adaptarse a nuevas versiones o frameworks que puedan aparecer. Volviendo al ejemplo de la aplicación para la gestión de clientes, el diseño especíco para una arquitectura en tres capas que utiliza el ISSN SISTEDES

92 Figura 5: Gestión de clientes utilizando Swing como framework de presentación Figura 4: Gestión de clientes con frameworks patrón DAO y MVC (que puede verse en la - gura 3) puede adaptarse para especicar el uso de un conjunto de frameworks. En la gura 4 puede verse el mismo diseño adaptado a la pila de frameworks compuesta por Hibernate [16], Spring [28] y Struts [30]. Este conjunto de frameworks es uno de los más utilizado para el desarrollo de aplicaciones web en Java. En la gura se observa como se han tenido que realizar importantes modicaciones para adaptar el diseño al uso de estos frameworks. Por motivos de claridad en el diagrama y espacio se han omitido en la gura las clases proporcionadas por los frameworks, pero que deben ser usadas por la aplicación para su correcto funcionamiento. Se han omitido también los numerosos archivos de conguración necesarios para el correcto funcionamiento de cada uno de los frameworks y para su integración. En la gura 5 puede verse como cambia este diseño simplemente cambiando uno de los frameworks que se van a utilizar. Esta gura muestra el diseño la aplicación para la gestión de clientes utilizando los frame- work Hibernate-Spring-Swing. Con el cambio de Struts por Swing [14] se mantiene la arquitectura en tres capas y el uso del patrón DAO y de MVC, pero se hace en una aplicación de escritorio en lugar de una aplicación web, puesto que Swing es un framework para la creación de interfaces de usuario que permite utilizar MVC [14]. De nuevo se han omitido del diagrama por motivos de claridad las clases propias de los frameworks y los cheros de conguración necesarios. En estos dos ejemplos puede verse la dicultad de obtener un diseño especíco para un conjunto de frameworks. Esta labor se complica aun más si se tiene en cuenta que en proyectos reales suele intervenir un número más elevado de frameworks para encargarse de otras tareas como la seguridad, el log o las pruebas. Estos diseños especícos para un conjunto de frameworks pueden modelarse de forma que los modelos capturen los frameworks a utilizar y como estos van a ser utilizados. Los trabajos de Antkiewicz [1] [2] muestran como pueden usarse modelos de características para llevar a cabo a esta tarea. El trabajo que se presenta aquí va enfocado a resolver los problemas indicados en la obtención de un diseño detallado de una aplicación, especíco para una arquitectura y unas tecnologías concretas, a partir de un diseño preliminar de la misma. ISSN SISTEDES

93 3. Hacia la exibilidad en el desarrollo dirigido por modelos Uno de los principales objetivos de este trabajo consiste en mitigar el paso de un diseño de alto de nivel de una aplicación a un diseño especíco para una arquitectura software. Para ello se propone tratar a la arquitectura software de las aplicaciones como a una línea de productos. A diferencia de las líneas de producto tradicionales, donde se dispone de una serie de activos que son utilizados para el desarrollo de un conjunto de sistemas de una misma familia, en este caso no se cuenta con ningún elemento reutilizable entre las distintas aplicaciones. Esto se debe a que no existe, a priori, ninguna funcionalidad común entre las aplicaciones a desarrollar que pueda utilizarse como un activo de la línea de productos. El punto en común entre las aplicaciones desarrolladas va a ser la utilización de una arquitectura similar. De esta forma es posible denir un núcleo común para cada arquitectura que se quiera soportar. Este núcleo común es compartido por todas las aplicaciones que utilicen dicha arquitectura. Las posibles variaciones sobre la arquitectura, como por ejemplo utilizar el patrón DAO para la persistencia en una arquitectura en tres capas, son tratadas como la variabilidad de la línea de productos. El primer paso para conseguir este objetivo pasa por modelar las arquitecturas software a utilizar y su variabilidad. Esta tarea puede llevarse a cabo utilizando modelos de características [9], una técnica para capturar los elementos comunes y la variabilidad en las familias de sistemas y las líneas de productos. Este tipo de modelos han demostrado su utilidad para reejar las características de arquitecturas software, en concreto la arquitectura de las aplicaciones RIA en el reciente trabajo de Meliá y Gómez [22]. Tomando como base el diseño inicial de la aplicación puede aplicarse una transformación que utilice la información de la arquitectura recogida en el modelo de características para generar un diseño especíco de una arquitectura concreta. De esta forma se consigue simplicar el paso de un diseño inicial a un diseño especico para una arquitectura, al estar este proceso asistido por una transformación automática. Además, se otorga a los desarrolladores la capacidad de denir la arquitectura de la aplicación de forma que esta se adapte a las necesidades de cada proyecto y las decisiones arquitectónicas se mantienen a lo largo de todo el proceso de desarrollo [26] en lugar de perderse en la complejidad de los desarrollos [8]. Adicionalmente, es posible obtener información de los patrones arquitectónicos que más se ajustan a una aplicación a partir de un modelo de requisitos de la misma [4]. Estos patrones arquitectónicos pueden utilizarse para seleccionar las características arquitectónicas más apropiadas en el modelo de características que guía la transformación. Con este trabajo también se ampliarán las posibilidades de los desarrolladores a la hora de escoger las tecnologías sobre las que se basará el desarrollo del sistema. Para ello se debe permitir que los desarrolladores decidan el framework o el conjunto de frameworks que van a ser utilizados en cada proyecto. Además, se debe permitir también que los desarrolladores decidan cómo se van a utilizar los frameworks seleccionados, puesto que muchos de ellos permiten realizar las mismas tareas de distintas formas. Por ejemplo el framework Hibernate [16] proporciona mapeos objeto-relacionales, pero estos mapeos pueden realizarse mediante un chero de conguración o mediante anotaciones en el código, utilizando la API propia de Hibernate o la API de JPA [5]. De esta forma se permite a los desarrolladores adaptarse a la aparición de nuevos frameworks o de nuevas versiones o evoluciones de los ya existentes sin perder los benecios aportados por las técnicas de desarrollo dirigido por modelos. Para conseguir este objetivo es necesario obtener un diseño, de la aplicación que se va a desarrollar, especíco para los frameworks que se han elegido y la forma en que se quieren utilizar. Sin embargo, adaptar el diseño de una aplicación para hacer uso de unos determinados frameworks requiere de un gran conocimiento técnico de los frameworks que se ISSN SISTEDES

94 utilicen. Además estos diseños pueden variar mucho en función de los frameworks seleccionados, como se ha mostrado en la sección anterior. Por lo tanto, el paso de un diseño detallado, conforme a una arquitectura software, a un diseño especíco para un conjunto de frameworks puede simplicarse si es visto como una transformación de modelos. Esta transformación debe tener en cuenta que se pueden utilizar distintos frameworks, para una misma labor, dentro de un mismo proyecto (por ejemplo en una aplicación web puede utilizarse Struts para la capa de presentación, pero utilizarse un framework AJAX para proporcionar mayor dinamismo a algunos apartados). También se debe soportar la utilización de frameworks en determinados subconjuntos de la aplicación (por ejemplo un framework de seguridad para la parte privada de una aplicación). Utilizando esta transformación se consigue un diseño especíco para los frameworks seleccionados por el desarrollador, a la vez que se mitigan los problemas que plantea el uso de avanzados frameworks de desarrollo. 4. Transformación a código Obtener el código de las aplicaciones modeladas no es uno de los objetivos principales de este trabajo. Sin embargo, disponer de un diseño especíco para un conjunto de frameworks simplica en gran medida la obtención del código. Los trabajos de Antiewkicz [1] [2] son un ejemplo de como es posible generar código especíco para frameworks de desarrollo a partir de unos modelos lo sucientemente detallados. Otras herramientas como Spring Roo [29] o JACA [17] (de los autores de este mismo trabajo) permiten generar código especíco para frameworks a partir de conceptos de más alto nivel. Cualquiera de estas alternativas podría adaptarse para generar el código de las aplicaciones modeladas según el método descrito en este artículo. 5. Trabajos relacionados Como se ha mencionado en secciones anteriores, numerosos trabajos en el área del desarrollo de software dirigido por modelos tratan con el desarrollo de sistemas con arquitecturas complejas y cuyo código utiliza frameworks de desarrollo como los tratados en este proyecto. Especialmente en el ámbito de la ingeniería web. con trabajos como WebML [7], UWE [19], OOWS [24], RUX [20], etc. Sin embargo estos trabajos no permiten a los desarrolladores tomar decisiones arquitectónicas o sobre los frameworks a utilizar. No obstante, en el mismo ámbito de la ingeniería web existe una excepción. El trabajo de Meliá y Gómez [21]. En este trabajo los autores proponen una extensión a los métodos anteriores denominada Web Software Architecture (WebSA). El propósito de esta extensión es exibilizar estos métodos incorporando a los mismos la posibilidad de denir la arquitectura que se quiere utilizar. Para conseguir este objetivo añaden dos modelos: el modelo de subsistemas y el modelo de conguración. En estos dos modelos se denen las características arquitectónicas de la aplicación web a desarrollar. Estos dos modelos se unen a los modelos funcionales de la aplicación (que pueden estar realizados con algunas de las metodologías anteriores: OO-H, WebML, etc) y mediante una serie de transformaciones se genera la aplicación. En un trabajo más reciente de los mismos autores [22], se realiza una propuesta similar orientada al desarrollo de aplicaciones RIA. En este trabajo se propone OOH4RIA como una ampliación de OOH especícamente diseñado para el desarrollo de RIAs. Los autores proponen la utilización de un modelo de características, como los utilizados en este trabajo, para denir las características de las RIAs y de un modelo de componentes RIA para representar explícitamente la arquitectura de una RIA. De nuevo estos modelos son utilizados junto a los modelos funcionales de OOH para generar las aplicaciones. Estos trabajos guardan una estrecha relación con el trabajo presentado aquí, especial- ISSN SISTEDES

95 mente el más reciente de ellos. Con ambos trabajos se persigue un mismo objetivo, permitir a los desarrolladores que utilizan las técnicas de desarrollo dirigido por modelos, inuir en la arquitectura de las aplicaciones que van a desarrollar. No obstante, los trabajos de Meliá y Gómez se centran en aplicaciones web y en RIA respectivamente, mientras que el trabajo presentado aquí pretende abarcar un mayor rango de aplicaciones, dando soporte para todas las aplicaciones que utilicen este tipo de arquitecturas. Adicionalmente, al contrario que en este trabajo, los trabajos aquí mencionados no permiten a los desarrolladores decidir acerca de los frameworks que van a ser utilizados para la implementación de las aplicaciones. Por otra parte, los trabajos de Antiekwicz [1] [2], como ya se ha mencionado anteriormente, permiten modelar diseños especícos para frameworks y obtener el código a partir de ellos. Sin embargo, a diferencia del trabajo aquí propuesto, estos diseños se quedan a un bajo nivel y obligan a los diseñadores a disponer de conocimientos técnicos muy detallados de los frameworks que se deseen utilizar. En el trabajo aquí presentado se elevará el nivel de abstracción partiendo de un nivel mucho más alto y llegando a un nivel de detalle suciente mediante la aplicación de una serie de transformaciones entre modelos. 6. Estado actual y trabajos futuros Como ya se ha mencionado en secciones anteriores, el método presentado en este trabajo se encuentra en un estado inicial y aún queda mucho trabajo por desarrollar. Uno de los principales puntos en los que se debe profundizar en el desarrollo de este métodos pasa por la denición exhaustiva de las características de las arquitecturas que se quieran soportar. Para ello se debe crear un modelo de características de cada una de las arquitecturas que permita capturar toda la variabilidad de las mismas, de forma que este modelo pueda instanciarse para cada aplicación concreta con unas características arquitectónicas válidas. Este modelo será aplicado en la transformación para obtener un diseño especíco de la arquitectura. Otro de los aspectos que requiere mayor profundidad consiste en la forma en que los frameworks deben aplicarse al diseño de la aplicación. Esto se debe a que, como ya se ha mencionado en secciones anteriores, distintas partes de una aplicación pueden utilizar distintos frameworks para cubrir la misma funcionalidad. Por lo tanto debe denirse un sistema que permita enlazar los frameworks a utilizar con distintos fragmentos del diseño de la aplicación a desarrollar. En esta misma linea de trabajo, se está trabajando en técnicas para gestionar las relaciones y restricciones existentes entre los diseños de las aplicaciones y los modelos de características que representan la arquitectura que va a seguir la aplicaciones. Para ello, se está estudiando la posibilidad de utilizar técnicas de model weaving para denir como la arquitectura debe inuir en el diseño de la aplicación. Por último, al tratarse la propuesta aquí presentada de una metodología eminentemente práctica sería una aportación interesante disponer de una implementación que permitiese validar la utilidad de la misma. Una parte de los métodos aquí propuestos están soportados por la herramienta JACA [17], como ya se ha mencionado anteriormente. Esta herramienta permite generar código para frameworks de desarrollo especícos a partir de conceptos de más alto nivel. Por lo tanto, este sistema sirve como prototipo de la propuesta aquí presentada y ayuda a identicar parte de los benecios de la misma. Sin embargo, sigue siendo necesario mucho trabajo para que la herramienta de soporte a la totalidad de las propuestas aquí presentadas. 7. Conclusiones En este articulo se ha presentado un método para ampliar las posibilidades de los desarrolladores a la hora de utilizar un sistema de desarrollo dirigido por modelos. La principal aportación de este método consiste en que se permite a los desarrolladores decidir las características arquitectónicas y los frameworks de desarrollo que se van a utilizar para generar ISSN SISTEDES

96 la aplicación. Debido a esto, es posible cubrir un mayor número de posibilidades a la hora de modelar una aplicación y se facilita la adaptación a nuevas arquitecturas o tecnologías que se deseen incorporar. Agradecimientos Este trabajo ha sido nanciado por los proyectos TIN , PDT08A034, PRE09156 y la Fundación Valhondo Cala. Referencias [1] Antkiewicz, M., Czarnecki, K., Stephan, M. Engineering of Framework-Specic Modeling Languages. IEEE Trans. Software Eng. 35(6): (2009) [2] Antkiewicz, M., Czarnecki, K. Framework-Specic Modeling Languages with Round-Trip Engineering. MoDELS 2006: [3] Bass, L., Clements, P., Kazman, R. Software Architecture in Practice chap. Architecture Based Development. SEI Series in software engineering, Addison-Wesley, 1998, [4] Berrocal, J., García-Alonso, J., Murillo, J.M. Facilitating the selection of architectural patterns by means of a marked requirements model. ECSA 2010 [5] Biswas, R., Ort, E. The Java Persistence API - A Simpler Programming Model for Entity Persistence. 2006, Articles/J2EE/jpa/ [6] Bosch, J. Design and Use of Software Architectures. Adopting and evolving a product-line approach. Addison-Wesley [7] Brambilla, M., Comai, S., Fraternali, P., Matera, M. Web Engineering: Modelling and Implementing Web Applications chap. Designing Web Applications with Webml and Webratio. Human Computer Interaction Series. Springer London, 2008, [8] Clements, P.C., Shaw, M. The Golden Age of Software Architecture Revisited. IEEE Software 26(4): (2009) [9] Czarnecki, K., Helsen, S., Eisenecker, U. W. taged conguration through specialization and multilevel conguration of feature models. Software Process: Improvement and Practice 10(2): (2005) [10] Eckerson, W. W. Three Tier Client/Server Architecture: Achieving Scalability, Performance, and Eciency in Client Server Applications. Open Information Systems 10, 1 (January 1995): 3(20). [11] Fairbanks, G., Garlan, D., Scherlis, W. Design fragments make using frameworks easier. SIGPLAN Not. 41, 10 (Oct. 2006), [12] Fayad, M., Schmidt, D. C. Objectoriented application frameworks. Commun. ACM 40, 10 (Oct. 1997), [13] Fayad, M., Schmidt, D. C., Johnson, R.E. Object-oriented Application Frameworks: Problems and Perspectives. Wiley, NY, [14] Fowler, A. A Swing Architecture Overview. /jfc/tsc/articles/architecture/ [15] Gamma, E., Helm, R., Johnson, R., Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software Addison-Wesley, Reading, MA (1995). [16] Hibernate. [17] Garcia-Alonso, J., Berrocal, J., Murillo, J.M. Java para Aplicaciones Corporativas de la Administración. Aceptado para su publicación en JISBD [18] Krasner, G. E., Pope, S. T. A cookbook for using the model-view controller user ISSN SISTEDES

97 interface paradigm in Smalltalk-80. J. Object Oriented Program. 1, 3 (Aug. 1988), [19] Kraus, A., Knapp, A. and Koch, N. Model-driven generation of web applications in UWE. 3rd International Workshop on Model-Driven Web Engineering (MDWE 2007). [20] Linaje, M., Preciado, J. C., Sánchez- Figueroa, F. Engineering Rich Internet Application User Interfaces over Legacy Web Models. IEEE Internet Computing 11(6): (2007) [21] Meliá, S., Gómez, J. The WebSA Approach: Applying Model Driven Engineering to Web Applications. J. Web Eng. 5(2): (2006) [22] Meliá, S., Gómez, J., Pérez, S., Díaz, O. Architectural and Technological Variability in Rich Internet Applications. IEEE Internet Computing 14(3): (2010) [23] Murugesan, S., Deshpande, Y., Hansen, S. and Ginige, A. Web Engineering: A New Discipline for Development of Webbased Systems. First ICSE Workshop on Web Engineering (WebE99), USA, [24] Pastor, O., Fons, J. and Pelechano, V. OOWS: a method to develop Web applications from Web-oriented conceptual models. International Workshop on Web-Oriented Software Technology (IW- WOST 2003), pp [25] Shaw, M., Garlan, D. Software Architecture. Perspectives on an emerging discipline. Prentice Hall, New Jersey, [26] Shaw, M., Clements, P.C. The Golden Age of Software Architecture. IEEE Software 23(2): (2006) [27] Shull, F., Lanubile, F., Basili, V. R. Investigating Reading Techniques for Object- Oriented Framework Learning. IEEE Trans. Software Eng. 26, [28] Spring Framework. [29] Spring Roo. /roo [30] Struts. [31] Sun Microsystems. Core J2EE Patterns - Data Access Object atterns/patterns/dataaccessobject.html ISSN SISTEDES

98 EMF4CPP: a C++ Ecore Implementation Andrés Senac Diego Sevilla Gregorio Martínez Dept. of Inf. & Comm. Eng. Dept. Comp. Eng. Dept. of Inf. & Comm. Eng. Dept. Comp. Eng. University of Murcia University of Murcia University of Murcia Murcia, Spain Murcia, Spain Murcia, Spain Abstract Eclipse, and its Ecore metamodel, have become a de facto standard for providing a complete working environment for model-driven development. However, being Java-centric, there is no established mapping from Ecore to the C++ language, partly because of the dif- culty in overcoming the dierences between these two programming languages in areas such as type mapping, memory management, and run-time capabilities. EMF4CPP lls this gap by providing a C++ implementation and type mapping for the Ecore metamodel. It oers a C++ code generator with a consistent type mapping, a reader and a serializer for XMI-encoded models and metamodels, being able to be used in model-to-model transformations, and establishing the basis for developing a set of tools for MDD in C++ that oer ef- cient construction, management, and usage of models and metamodels. The paper introduces the mapping, discusses performance issues and shows motivating usage scenarios. Preliminary tests show C++ code to manipulate models to be 1.5 times faster than the corresponding Java code, and using 35% less memory, also favoring its usage in embedded environments. 1 Introduction The Eclipse Project [3] and its EMF (Eclipse Modeling Framework) [15] have contributed to new and encouraging developments in the area of Model-Driven Development (MDD) in general, and to Metamodeling in particular. The EMF approach, with the Ecore metamodel, aimed at providing a simpleryet rich enoughmodel elements description that allowed, among other things, (1) describing model artifacts characteristics (such as classes and attributes) in a platform- and languageindependent way, and (2) to map those model elements to implementation technologies and programming languages constructs. Models conforming to the Ecore metamodel have a direct mapping to the Java language constructs. However, there is no established mapping to the C++ programming language, limiting the interoperability between the powerful set of tools available around the EMF technology and Model-Driven Developments (MDD) wanting to leverage libraries and techniques available in C++ (such as metaprogramming [6] and Embedded Domain- Specic Languages (DSL) [7].) to oer alternative tools and abstractions for text-to-model (T2M), model-to-model (M2M), and model-totext (M2T) transformations. EMF4CPP tries to ll this gap by being able to generate C++ implementation artifacts from Ecore-based metamodels. The generated code artifacts support the whole Ecore dened characteristics, including classes, attributes, operations, references, etc., as well as being able to read and write model and metamodel data using the XMI model interchange format [13], oering a reective mapping to work with models and metamodels in a generic way, and including a consistent mapping of Ecore types to C++ types. ISSN SISTEDES

99 Thus, the main advantages of EMF4CPP can be summarized as follows: There is no standard C++ type mapping for the Ecore metamodel. EMF4CPP can be seen as a rst step to standarize this mapping. This, not only has the direct benet of being able to use the dierent EMF tools (and Ecore metamodels) to describe the data model of C++ applications, but also it represents a basis to interoperate with future MDD tools that use C++ as the programming language. It oers a reective API for models and metamodels, being able to interoperate with other tools in intermediate model transformations (though XMI), and serving as a basis for tools that exploit C++ idioms and patterns for dealing with model creation and transformation. Also, projects that have to support several implementation languages can share metamodels, and steps can be done into automatic conversion of code between implementation languages. By providing a standard C++ mapping, we can easily embed scripting languages such as Python, Lua, or Ruby for writing tools that manage models and metamodels. We have already implemented preliminary support for Python (PyEcore). Finally, initial results (in Section 3) show C++ around 1.5 times faster and with 35% less memory footprint in managing model data structures. This is a key factor in embedded systems, that usually have strong memory and processing power constraints. Also, it represents a real-world advantage in dealing with bigger models (for instance, those resulting of using ADM/KDM [14].) Along with these benets, the development of EMF4CPP was motivated mainly by two industrial projects carried out under the Cátedra SAES-UMU [16]: Generic Interface Testing: We developed an abstract model for describing interfaces dened using either CORBA IDL, Java, or C++, and tests performed on them, including both static (e.g. output values given input values, either obtained from previous execution logs or using mathematical functions), and dynamic (e.g. workow-based) tests. A DSL was developed for specifying these tests. The test specication allowed us to automatically generate both testing clients and mocking servers. Finally, we also modelled the run-time behavior of the testing process, i.e. which tests have been performed, calls made, including input and output values, which tests failed or succeeded, etc. In the case, for example, of CORBA IDL/C++ clients, we needed a way of representing the modelled runtime tests state into C++ classes (as it can be done with the Java version using the EMF tools.) These classes were obtained using EMF4CPP. Usability assessment and Validation on GUIs: Another project for which we needed EMF4CPP was related to reasoning about Qt4-based GUIs [12], abstracting the properties and characteristics of Qt graphical widgets in order to do runtime usability assessment and validation of input and output values. The abstraction was actually performed by doing a model-to-model transformation of the original model of Qt widgets to the abstract model of widget properties needed for either usability or validation in GUIs. For instance, in some usability processes, we were interested in the containment relation of widgets, as well as relative positions, instead of the actual type of the widget (i.e. if a widget could be seen as a container widget.) Alternatively, for input validation, text boxes and spin boxes were treated just as widgets producing a value that could be checked for validity. The usability and validation algorithms were performed on the dierent abstract models for widgets. As Qt is based on C++, and as those algorithms are performed mostly at run-time, we needed a ISSN SISTEDES

100 way of representing, manipulating, and transforming models in C++ at run-time, hence the usage of EMF4CPP. Other similar eorts include EMF4Net [2], a port of EMF to the.net Platform, RMOF [8], an implementation of MOF and Ecore in Ruby, and RGen [11], a Ruby-based modeling and generator framework. This paper is structured as follows: Section 2 describes the main concepts behind the Ecore metamodel and introduces the C++ implementation, and examples of usage compared to the Java counterpart. Section 3 shows some performance measurements showing the viability of the approach. Finally, Section 4 shows some conclusions, the current implementation status, and future work. 2 The EMF4CPP Design and Implementation The Ecore metamodel denes the characteristics of several main abstractions, among the most important: Classes: Dene the class concept and their characteristics, such as inheritance, class attributes, operations, and references to other classes. References: Specify the characteristics of dependencies between class' instances (for example, the physical containment property.) DataTypes: State the intrinsic characteristics of general data types. Common data types such as integer (EInt), double precision oating point (EFloat), etc., are provided. Packages: Dene a name-space based containment architecture for data types, classes, and other packages. As we stated above, Ecore also provides trivial mappings of all those data types and concepts to Java implementation artifacts. However, Ecore is general enough to allow mappings to other programming languages to be built. The approach we followed when providing a C++ mapping for Ecore is depicted in Figure 1. In the current implementation, the source code generator was developed with EMF itself, particularly using Xpand and Xtend [4]. From the Ecore metamodel itself, it produces C++ source code that gets packed as a shared library. These classes allow us to manage, describe, and process any metamodel described using Ecore. Figure 2 shows the process followed by any metamodel conforming to Ecore. The generator creates C++ classes that allow manipulating entities of the types dened in the metamodel, and also reading model instances (i.e. data to ll the classes dened in the metamodel) and process them within a C++ application, linking the correct dynamic libraries. Thus, EMF4CPP consists of two parts: a source code generator from Ecore metamodels to C++ and two runtime support libraries. One of the runtime support libraries implements the Ecore metamodel (libecore). The other one allows to parse and serialize models in XMI format (libecorecpp). 2.1 Ecore to C++ Type Mappings One of the most challenging issues in bringing the mapping of Ecore to C++ was to ll the gap between the type system and the memory management of Java and C++. Table 1 shows the mapping arranged for the Ecore data types. The mapping comprises several parts: (1) mapping types and classes, (2) memory management, (3) the implementation of the re- ective API (which is used for serialization to and from XMI documents), and (4) the change notication API. Regarding the type mapping, we decided to map to the closest C++ type (for example EBoolean to bool and EClasses to C++ classes, EPackages to C++ namespaces, etc.), and ignore the dierences between boxed (EBooleanObject) and non-boxed ones (EBoolean), because this distinction does not make sense in C++ since it does not have a supertype Object. ISSN SISTEDES

101 ECORE to C++ generator C++ compiler Ecore.ecore (ECORE Metamodel) C++ source files libecore.so (Runtime library) Figure 1: EMF4CPP implementation workow. ECORE to C++ generator C++ compiler Foo.ecore (ECORE Metamodel) C++ source files libfoo.so (Runtime library) <conforms> <linked> C++ user application <linked> FooModel.xmi (a Foo model) libecore.so libecorecpp.so (Runtime libraries) Figure 2: Generating C++ classes from an arbitrary metamodel. The mapping of attributes and references of classes is as follows: For each attribute or reference P, accessor (getp()) and mutator (setp()) methods are provided. Unlike the Java mapping, accessor methods for attributes do not modify the object instance, so they usually return a constant C++ reference to the real attribute. If that attribute or reference is multiple, additional methods addp(), setpat(), and deletepat() are added to respectively add a new element to the list, set the nth element, and delete the nth element. A template method as<type>() is provided by the EObject class for explicit conversion between related types without the need of temporary variables. For the memory management, we decided to use raw pointers to represent references. Thus, a class named MyClass in the metamodel would be translated into both a class with the same name, and a type MyClass_ptr, with the semantics of a raw C++ pointer. Given the strict meaning of containment (ownership) vs. non-containment references in the Ecore metamodel, a class always knows which of its own structural features to free when an instance of that class gets reclaimed (as opposed to Java, where memory management is automatic.) The reective API allows accessing models using a generic API that does not depend on the actual types of the contained elements. This supposes a challenge, as C++ does not have a common object root, and its run-time reective capabilities are minimal compared to those oered by Java. So, we implemented enough API to be able to query and modify models in a generic way, but those model classes must have been previously generated by the generator (conversely, Java allows creating instances of metamodels without previously having to generate model classes.) The ISSN SISTEDES

102 EDataType C++ type EDataType C++ type EBigDecimal long double a EBigInteger long long a EBoolean bool b EBooleanObject bool b EByte unsigned char EByteArray std::vector<unsigned char> EChar char ECharObject char EDate time_t EDiagnosticChain (undened) EDouble double EDoubleObject double EEnumerator int EFeatureMap (undened) EFeatureMapEntry (undened) EFloat oat EFloatObject oat EInt int EIntObject int EJavaObject any c ELong long ELongObject long EResource (undened) EResourceSet (undened) EShort short EShortObject short EString std::string d EInvocationTargetExcept. (undened) a This may change to use, for example, types provided by the GMP library [5]. b We decided to use the same basic C++ type for boxed and non-boxed types for Java. (See Section 2.1.) c A type similar to the Boost library [1] boost::any. d The current implementation also allows the usage of std::wstring and wchar_t as character type, for example, in Windows platforms. Table 1: Ecore to C++ Type Mappings. full reective API is doable in C++, but left as a future work as it is not strictly needed to work with models and metamodels. Additionally, we mapped the EJavaObject type to an any type that can hold any C++ value. Finally, the change management API is not implemented in this rst version. It is left as a future work. An _initialize() method is provided to ensure the referential integrity of the model (see Figure 5.) 2.2 Model Usage and Comparison with Java In this Section we show the EMF4CPP API usage creating a simple metamodel and a model that conforms to that metamodel. In this case, we are going to create the company metamodel shown in Figure 3 using our C++ Ecore runtime library. It contains three meta-classes (Company, Department, and Employee). This metamodel example is slightly modied from [10]. Figure 4 shows an excerpt of the creation of the company metamodel using our Ecore runtime library. In particular, the creation of the Company meta-class is shown, with the addition of the name attribute of type EString. Figure 3: Example company metamodel (slightly modied from [10].) The API follows the conventions seen in Section 2.1: the setname() method for setting the name property, and the addestructuralfeatures() method to add a new structural feature to the property containing the list of them. Finally, the three new meta-classes are added to the company package. Correspondingly, listing in Figure 5(a) shows the creation of a simple model conforming to the metamodel. The Company class (and its corresponding Company_ptr type) have been previously generated by the EMF4CPP generator. Note how all the dif- ISSN SISTEDES

103 u s i n g n a m e s p a c e e c o r e ; EcoreFactory_ ptr ec orefac tory = E c o r e F a c t o r y : : _ i n s t a n c e ( ) ; EcorePackage_ptr e c o r e P a c k a g e = EcorePackage : : _ i n s t a n c e ( ) ; // C r e a t e a Company c l a s s E C l a s s _ p t r companyclass = e c o r e F a c t o r y > c r e a t e E C l a s s ( ) ; companyclass >setname ( "Company" ) ; // Add name a t t r i b u t e t o a Company c l a s s E A t t r i b u t e _ p t r companyname = e c o r e F a c t o r y > c r e a t e E A t t r i b u t e ( ) ; companyname >setname ( "name" ) ; companyname >setetype ( e c o r e P a c k a g e > g e t E S t r i n g ( ) ) ; companyclass >a d d E S t r u c t u r a l F e a t u r e s ( companyname ) ;... // C r e a t e a package t h a t r e p r e s e n t s company EPackage_ptr companypackage = e c o r e F a c t o r y >createepackage ( ) ; companypackage >setname ( "company " ) ; companypackage >s e t N s P r e f i x ( " company " ) ; companypackage >setnsuri ( " h t t p : / / / com. example. company. e c o r e " ) ; companypackage >a d d E C l a s s i f i e r s ( e m p l o y e e C l a s s ) ; companypackage >a d d E C l a s s i f i e r s ( d e p a r t m e n t C l a s s ) ; companypackage >a d d E C l a s s i f i e r s ( companyclass ) ; // Get t h e C l a s s i f i e r by name E C l a s s _ p t r companyclass = companypackage >g e t E C l a s s i f i e r ( "Company" ) >as< E C l a s s >() ; // C r e a t e an i n s t a n c e EObject_ptr company = companyfactory > c r e a t e ( companyclass ) ; // Get t h e name s t r u c t u r a l f e a t u r e by name E S t r u c t u r a l F e a t u r e _ p t r companyname = companyclass >g e t E S t r u c t u r a l F e a t u r e ( "name " ) ; // Set t h e name a t t r i b u t e E S t r i n g name ( " U n i v e r s i t y Of Murcia " ) ; any a(&name ) ; company >eset ( companyname, a ) ; // Get t h e name a t t r i b u t e a = company >eget ( companyname ) ; c o n s t EString obtained_name = any : : any_cast < c o n s t EString >(a ) ; std : : cout << obtained_name << std : : endl ; // Get t h e l i s t o f r e f e r e n c e s t o Departments E S t r u c t u r a l F e a t u r e _ p t r d e p a r t m e n t s = companyclass >g e t E S t r u c t u r a l F e a t u r e ( " d e p a r t m e n t s " ) ; a = company >eget ( d e p a r t m e n t s ) ; mapping : : E E L i s t B a s e _ p t r d e p _ l i s t = any : : any_cast< mapping : : EEListBase_ptr >( a ) ; // Obtain f i r s t d e p t. EObject_ptr d e p a r t m e n t = ( d e p _ l i s t ) [ 0 ] ; Figure 4: Excerpt. Company metamodel creation. Figure 6: Reective API example. ferent attributes and relations (references) are correctly established. A last call to _initialize() completes the model to ensure the referential integrity (e.g. opposite references). Here model deletion is performed automatically using a std::auto_ptr. Figure 5(b) shows the equivalent Java code for the example above. There is no need of the nal initialization pass, as EMF implements change notication, left as a future work. Figure 6 shows the usage of the reective API to create a Company class instance, establishing its name attribute, then reading it, and nally obtaining the list of references to Departments. Note the usage of the any type and the special covariant list type EEListBase. 3 Performance Comparison 3.1 Mapping-related Performance Considerations Our rst approach at memory management was using Boost boost::shared_ptr construct, as it manages the memory safely and automatically for pointers. However, this introduced performance tradeos, and was not usable in the case of circular references. As mentioned, using raw pointers and following the containment relationship for references was enough for a correct memory management. Also, using any for the reective API boxed all the features of classes, including data types and even list of references (those declared, for example, as 0..*), which implied a memory copy of the whole list of references. So, we had to tweak the reective API so that anys re- ISSN SISTEDES

104 u s i n g n a m e s p a c e company ; CompanyPackage_ptr companypackage = CompanyPackage : : _ i n s t a n c e ( ) ; CompanyFactory_ptr companyfactory = CompanyFactory : : _ i n s t a n c e ( ) ; // C r e a t e a company std : : auto_ptr<company> umu( companyfactory >createcompany ( ) ) ; umu >setname ( " U n i v e r s i t y Of Murcia " ) ; // C r e a t e a d e p a r t m e n t Department_ptr catsaes = companyfactory >createdepartment ( ) ; catsaes >setnumber ( ) ; // C r e a t e e m p l o y e e s Employee_ptr a s e n a c = companyfactory >createemployee ( ) ; asenac >setname ( " Andres Senac " ) ; catsaes >addemployees ( asenac ) ; Employee_ptr d s e v i l l a = companyfactory >createemployee ( ) ; d s e v i l l a >setname ( " Diego S e v i l l a " ) ; catsaes >addemployees ( d s e v i l l a ) ; // Set t h e d e p a r t m e n t manager catsaes >setmanager ( d s e v i l l a ) ; // Add t h e d e p a r t m e n t umu >adddepartments ( catsaes ) ; // I n i t i a l i z e t h e model umu >_ i n i t i a l i z e ( ) ; // ( model i s d e l e t e d a u t o m a t i c a l l y ) (a) C++ code. i m p o r t company ; CompanyPackage companypackage = CompanyPackage. einstance ; CompanyFactory companyfactory = CompanyFactory. einstance ; // C r e a t e a company Company umu = companyfactory. createcompany ( ) ; umu. setname ( " U n i v e r s i t y Of Murcia " ) ; // C r e a t e a d e p a r t m e n t Department catsaes = companyfactory. createdepartment ( ) ; catsaes. setnumber ( ) ; // C r e a t e e m p l o y e e s Employee a s e n a c = companyfactory. createemployee ( ) ; a s e n a c. setname ( " Andres Senac " ) ; catsaes. g e t E m p l o y e e s ( ). add ( a s e n a c ) ; Employee d s e v i l l a = companyfactory. createemployee ( ) ; d s e v i l l a. setname ( " Diego S e v i l l a " ) ; catsaes. g e t E m p l o y e e s ( ). add ( d s e v i l l a ) ; // Set t h e d e p a r t m e n t manager catsaes. setmanager ( d s e v i l l a ) ; // Add t h e d e p a r t m e n t umu. g e t D e p a r t m e n t s ( ). add ( catsaes ) ; // I n i t i a l i z e t h e model // ( not needed ) // ( model i s d e l e t e d a u t o m a t i c a l l y ) (b) Java code. Figure 5: Company model population. turned references to the class elements. Also, unlike Java, C++ standard containers are not covariant with the generic type (for example, std::list<b> is not a subclass of std::list<a> even if B is a subclass of A), so in case of having to obtain a set of references using the re- ective API, we had to build a new list with generic EObject references. To overcome this penalty, we implemented a covariant list type exclusively for the reective API. 3.2 Performance Evaluation To show the validity of the approach in the Ecore C++ implementation, we designed a performance evaluation test to compare it with the Eclipse Ecore implementation. The test consisted in reading a model conforming to the simple tree metamodel in Figure 7(a) with a non-terminal root node with one million children leafs, doing a trivial model transformation to build a model conforming to the metamodel in Figure 7(b), and serializing the resulting model. The transformation included simple model manipulations to measure the overhead of working with the model structure itself. In particular, it consisted on building an ordered non-balanced binary tree, lexicographically comparing the data attribute of the source model leafs. We implemented the same transformation in both Java and C++. For the comparison we measured the time of loading the model (48MB of XML), model ISSN SISTEDES

105 Table 3 shows the memory usage after loading the source model and making the transformation. The memory usage in Java has been measured after calling the garbage collector. Savings of around 35% were obtained. (a) Source metamodel. EMF EMF4CPP Reduction L&T (32b) 141,604,848 89,124, % L&T (64b) 234,417, ,354, % Table 3: Memory usage in bytes of load and transformation and percentage of reduction. (b) Destination metamodel. Figure 7: Metamodels used for perfomance testing. transformation, and the time of writing the resulting metamodel (164MB), in a 3.0 GHz AMD Phenom II X4 940 with 8GB of RAM under 64-bit Linux, and in an Intel Core2Quad Q8300 with 4GB of RAM under 32-bit Linux. The C++ code was compiled using GCC 4.4 with -O3 optimization. The Java code was run under Sun JDK We tested 32-bit and 64-bit because of the dierence in pointers size, as model data structures are mainly pointer-based. Table 2 shows the times obtained for both implementations. Model loading times are around 1.13 times faster in 32- bit systems, with a clear bigger speedup of 1.64 in 64-bit systems. Processing times vary from 1.6 (in 32-bit) to 2.37 (in 64-bit) times faster in C++ than in Java. Model writing times range between around 2 to 3.5 times faster in C++. EMF EMF4CPP Speedup Load (32b) Transf. (32b) Serialization (32b) Load (64b) Transf. (64b) Serialization (64b) Table 2: Times in milliseconds and speedup. 4 Conclusions, Current Status and Future Work EMF4CPP provides a consistent and ecient Ecore to C++ mapping that can be used to follow a model-driven approach for C++ developments. The current implementation allows to generate C++ code from Ecore metamodels and to manage and use models conforming to that metamodels. Thorough the paper we mentioned a set of features that were intended for future work, such as to complete the Ecore to C++ mapping, the fully reective API support, and the implementation of the change management API. Also, we plan to develop infrastructure tools to manage models, and provide T2M, M2M, and M2T transformations, leveraging the C++ metaprogramming techniques to the MDD paradigm. For example, as an alternative to the text-to-model workows in Eclipse, we want to explore using the metaprogramming, the embedded DSL-based Spirit parser [7] and monadic parsers similar to Haskell Parsec [9] to automatically generate models from C++-dened parsers. We also want to explore bringing the mapping to C++embeddable scripting programming languages such as Lua and Python. EMF4CPP is also being submitted to become an Eclipse Incubator project. 1 Another interesting area of future work is the specication of a higher level meta- 1 msg&goto=542311&. ISSN SISTEDES

106 metamodel (of which Ecore would be an instance) that allows a more seamless language mappings (for example, Ecore species the EJavaObject type, too tied to Java, instead of a more generic one). It could also include element characteristics such persistence or remote access properties, allowing to model distributed systems and Service Oriented Architectures (SOA). EMF4CPP has been developed by the Cátedra SAES Team as an Open Source contribution. Source code and additional information is avalible at wiki/emf4cpp under the LGPL License. Acknowledgements This paper has been partially supported by the Cátedra SAES of the University of Murcia [16], a joint eort between SAES (Sociedad Anónima de Electrónica Submarina, and the University of Murcia ( to work on open-source software, and real-time and critical information systems. References [1] Dawes, B., Abrahams, D., Rivera, R., et al.: Boost C++ Libraries (2010), http: //boost.org/ (last visited May 2010) [2] Eclipse Foundation: EMF4Net Proposal (2010), Proposal (last visited May 2010) [3] Eclipse Foundation: The Eclipse Project (2010), [4] Eclipse Foundation: Xpand and Xtend (2010), m2t/?project=xpand#xpand (last visited May 2010) [5] Free Software Foundation: The GNU Multiple Precision Arithmetic Library (GMP) (2010), (last visited May 2010) [6] Gurtovoy, A., Abrahams, D.: Boost MPL Library (2004), org/doc/libs/release/libs/mpl [7] de Guzman, J., Kaiser, H.: The Spirit Parser (2009), [8] Jim Steel, Franck Fleurey, Jesús Sánchez Cuadrado: RMOF (2005), rubyforge.org/ (last visited May 2010) [9] Leijen, D., Meijer, E.: Parsec: Direct Style Monadic Parser Combinators for the Real World. Tech. Rep. UU-CS , Departement of Computer Science, Universiteit Utrecht (2001), cs.uu.nl/daan/parsec.html [10] Litani, E., Merks, E., Steinberg, D.: Discover the Eclipse Modeling Framework (EMF) and Its Dynamic Capabilities (August 2005), com/java/article/29093/0/page/1 [11] Martin Thiede: RGen (2009), ruby-gen.org (last visited Jun 2010) [12] Nokia Corp.: Qt: A Cross-Platform Application and UI framework (2010), http: //qt.nokia.com/ [13] Object Management Group: XML Metadata Interchange (XMI), version (2007), document formal/ [14] Object Management Group: Architecture-Driven Modernization (ADM): Knowledge Discovery Meta- Model (KDM), version 1.2 (2010), document formal/ [15] Steinberg, D., Budinsky, F., Paternostro, M., Merks, E.: EMF, Eclipse Modeling Framework. Addison-Wesley, second edn. (2009) [16] University of Murcia, SAES: Cátedra SAES-UMU (2010), catedrasaes ISSN SISTEDES

107 Generación de modelos de servicios en SoaML desde modelos de procesos de negocio en BPMN con QVT Andrea Delgado Instituto de Computación Facultad de Ingeniería Universidad de la República 1300 Montevideo, Uruguay Ignacio García-Rodríguez de Guzmán Grupo Alarcos Departamento de Tecnologías y Sistemas de Información Universidad de Castilla La Mancha Ciudad Real ignacio.grodriguez@uclm.es Francisco Ruiz, Mario Piattini Grupo Alarcos Departamento de Tecnologías y Sistemas de Información Universidad de Castilla La Mancha Ciudad Real {francisco.ruizg,mario.piattini}@uclm.es Resumen El modelado de procesos de negocio en las organizaciones permite explicitar el conjunto de actividades que son necesarias para lograr los objetivos del negocio definidos. Tradicionalmente éstos han sido parte del área del negocio sin demasiada relación con su implementación tecnológica por el área de sistemas, que en general se ha realizado con una visión vertical de la organización por sus secciones. La incorporación de cambios a los sistemas y la interacción entre éstos ha requerido esfuerzos importantes, debido en parte a la visión vertical del desarrollo y al alto acoplamiento entre los procesos de negocio (muchas veces implícitos en los sistemas) y su implementación. La realización de procesos de negocio con servicios introduce una capa de intermedia, que permite mayor agilidad en los cambios en los procesos o las tecnologías. La generación automática de servicios en SoaML desde procesos de negocio en BPMN que se presenta, aporta a la agilidad organizacional proveyendo además trazabilidad entre los elementos involucrados. 1. Introducción El paradigma de Computación Orientada a Servicios (Service Oriented Computing, SOC) basa el diseño de aplicaciones masivas distribuidas y evolutivas en servicios [1] elementos de software reutilizables mediante los cuales consumidores y proveedores de servicios interactúan en forma desacoplada para realizar procesos de negocio en secuencias de invocaciones a servicios. La Arquitectura Orientada a Servicios (Service Oriented Architecture, SOA) es un estilo de arquitectura para la implementación con servicios [2][3]. Los servicios constituyen actualmente una de las implementaciones más utilizadas, junto con motores de procesos, para soportar las diversas etapas de la Gestión de Procesos de Negocio (Business Process Management, BPM) [4]. La introducción de una capa de servicios intermedia entre la capa de definición de los procesos de negocio y la capa de implementación en distintas tecnologías, aporta a reducir el acoplamiento entre las mismas, vía los servicios definidos. Los servicios realizan y por lo tanto se mapean a actividades, sub-procesos y/o procesos de negocio completos, relacionando el diseño de software con la definición de los procesos. A su vez, los servicios definidos son implementados por componentes y sistemas de software, mapeando el diseño de software con su implementación. De esta forma, se agiliza la introducción de cambios tanto en los procesos de negocio como en su implementación, minimizando el impacto de los cambios en una capa sobre la otra [2][3]. Sin embargo, las ventajas de la introducción de servicios en las organizaciones no han sido totalmente alcanzadas, en parte por la escasez o poca utilización de metodologías para guiar el desarrollo orientado a servicios. Si bien la implementación y ejecución de servicios en los últimos años ha madurado considerablemente, el modelado de servicios aún está en definición. Este modelado es fundamental entre otras cosas, para permitir la automatización de distintas etapas del desarrollo de software utilizando el paradigma de Desarrollo Dirigido por Modelos (Model Driven Development, MDD)[5], incluyendo la generación de código desde estos modelos. El estándar Soa Modeling Language (SoaML) [6] del Object ISSN SISTEDES

108 Management Group (OMG) es un paso en este sentido. SoaML define un metamodelo y un perfil UML para modelar servicios, extendiendo UML. En este artículo se presenta la definición de transformaciones QVT [7] desde modelos de procesos de negocio en Business Process Modeling Notation (BPMN) [8] a modelos de servicios en SoaML, para automatizar la obtención de servicios directamente desde los procesos de negocio. El estándar BPMN constituye actualmente el estándar más importante para modelado de procesos de negocio, y el estándar SoaML constituye la base para la homogeneización del modelado de servicios, que hasta su definición se realizaba con distintas notaciones y por lo tanto distintos elementos y distinta semántica asociada a los mismos []. Estas transformaciones se integran en la definición del marco MINERVA (Model driven and service oriented framework for the continuous business processes improvement & related tools) [9] que integra los paradigmas BPM, SOC y MDD para soportar la mejora continua de procesos de negocio. La utilización de estándares es la base del marco, por lo que además de BPMN y SoaML se utiliza QVT para las transformaciones. El resto del documento se organiza de la siguiente forma: en la sección 2 se presentan los principales elementos de SoaML y BPMN en base al modelo de proceso de negocio Otorgar Préstamo, en la sección 3 se describen las transformaciones QVT definidas, en la sección 4 se muestran las transformaciones sobre el ejemplo presentado, y finalmente en la sección 5 se presentan conclusiones y trabajo futuro. 2. Principales elementos de los estándares BPMN y SoaML Para ilustrar los elementos de BPMN se introduce en la Figura 1 el modelo de proceso de negocio Otorgar Préstamo que se utilizará como ejemplo a lo largo de este artículo. BPMN especifica un único tipo de diagrama, el Business Process Diagram (BPD), un conjunto de elementos núcleo con el cual modelar la mayoría de los procesos de negocio y un conjunto completo. Los elementos definidos se agrupan en: Swimlanes, Objetos de Flujo, Objetos de Conexión y Artefactos. En el grupo de Swimlanes se definen: Pool que representa una entidad o rol participante (ej. Banco), y Lane que representa una sub-partición Figura 1. Proceso de negocio Otorgar Préstamo en BPMN ISSN SISTEDES

109 dentro de un Pool para organizar actividades (ej. Servicios al Cliente). El grupo de objetos de Flujo contiene los distintos tipos de Actividad que representa el trabajo que la organización realiza, y puede ser atómica o un sub-proceso compuesto de otras actividades (ej. de Actividad atómica Solicitar Préstamo). También están entre los Objetos de Flujo, los puntos de decisión utilizados para controlar la divergencia y convergencia del flujo del proceso, que puede ser paralelo (AND, nodos con cruz horizontal en Autorización de Préstamo), exclusivo (XOR, nodos con cruz inclinada), inclusivo (OR, nodo con el círculo en blanco) o complejo. Incluye también los eventos que son algo que ocurre en el curso del proceso afectando su flujo, con una causa (trigger) y un impacto (result) y pueden ser de inicio, intermedios o fin, y pueden tener un tipo como tiempo o error (ej. eventos de inicio y fin simples). El grupo de objetos de conexión define los objetos de flujo de secuencia que muestran el orden en que las actividades del proceso se realizan, desde el inicio hasta el fin, y el flujo de mensajes entre dos participantes (las flechas enteras son de secuencia y las punteadas de mensajes). Los objetos de flujo de secuencia solo pueden utilizarse dentro de un mismo pool, entre distintos pools se deben utilizar los objetos de flujo de mensajes. En el grupo de Artefactos se definen objetos de texto, de datos y grupos. El estándar se encuentra actualmente bajo modificación ya que la última versión 2.0 beta1 introduce nuevos elementos y cambia otros existentes en los estándares previos. Por otro lado, el estándar SoaML define servicio (Service) como un recurso que permite el acceso a una o más capacidades provistas, mediante la interface definida, que es ejercitado consistentemente con restricciones y políticas especificadas en la descripción del servicio. La arquitectura general de servicios se especifica en la colaboración ServicesArchitecture, donde se muestran los roles participantes y los contratos de servicios definidos. En la Figura 2 se presenta una parte del modelo en SoaML correspondiente a la ServicesArchitecture para el proceso de negocio Otorgar Préstamo presentado antes, con tres contratos de servicio a modo de ejemplo. Un servicio se provee por una entidad (provider, ej. :Banco) para su uso por otros (consumers, ej. :Cliente), donde los consumidores del servicio pueden no ser conocidos para el proveedor. Un servicio puede tener una o más interfaces y un contrato asociado. Un contrato de servicio (ServiceContract, en el ejemplo uno es :Registrar solicitud) es una colaboración que define los términos, condiciones, interfaces y coreografía en que los participantes acuerdan para usar el servicio. Las interfaces pueden ser de tipo simple Figura 2. Parte de la Arquitectura de servicios para el Proceso de negocio Otorgar Préstamo en SoaML ISSN SISTEDES

110 UML Interface, o de tipo interface de servicio (ServiceInterface) que es una clase definida con tres secciones principales: las interfaces provistas y requeridas, la clase interface y el protocolo de comportamiento (choreograpy). Los participantes (Participant) son componentes de software, organizaciones o sistemas que proveen y usan servicios, ofreciendo capacidades en un ServicePoint y requiriendo otras en un RequestPoint, ambos especializando Port UML. Un canal de servicios (ServiceChannel) permite la comunicación entre estos, y los tipos de mensajes (MessageType) especifican el tipo de información a intercambiar en las operaciones. La arquitectura interna de cada participante se presenta en una ParticipantArchitecture que se realiza por cada participante, definiendo servicios internos que permiten proveer los servicios externos ofrecidos. El estándar se encuentra actualmente en su versión beta2, en la cual se introdujeron cambios como el nombre de ServicePoint y RequestPoint a Service y Request respectivamente, y la sustitución del uso de la ParticipantArchitecture por el mismo tipo de colaboración ServicesArchitecture para modelar la arquitectura interna de cada participante. 3. Transformaciones QVT de BPMN a SoaML Si bien la realización de procesos de negocio con servicios tiene asociadas las ventajas mencionadas previamente, la definición de los servicios correctos para soportar estos procesos es todavía un desafío. Existen varias iniciativas para proveer soporte metodológico para derivar servicios desde procesos de negocio y automatizar esta derivación cuando sea posible, pero el problema está aún en estudio. Para guiar el desarrollo orientado a servicios en MINERVA incluimos la metodología Business Process Service Oriented Methodology (BPSOM) [10] a la cual estamos agregando la generación automática de servicios desde procesos de negocio que se presenta, en las actividades de BPSOM definidas. La importancia de generar servicios automáticamente directamente desde los procesos de negocio es la de la generación automática: permitir el reuso de conocimiento, reducir los errores de diseño, registrar la trazabilidad de las relaciones entre elementos de los distintos modelos, y mejorar la productividad. Al diseñar o generar servicios otro aspecto importante a tener en cuenta es la existencia de servicios ya implementados en la organización que puedan ser reutilizados. En BPSOM se considera con una actividad que explícitamente requiere la revisión de un catálogo de servicios existentes, que serán incluidos en el modelo SoaML obtenido. En este sentido la re-ejecución de transformaciones deberá preservar estas definiciones. Un elemento clave para definir las transformaciones son las relaciones entre elementos de un modelo de procesos de negocio y un modelo de servicios. Para conceptualizar estas relaciones y los conceptos involucrados en cada modelo, definimos una ontología de modelado [11]] que se incluye en MINERVA para su utilización como referencia conceptual. Teniendo en cuenta la conceptualización realizada, hemos identificado varias correspondencias entre los conceptos involucrados en el modelado de procesos de negocio y servicios, que luego trasladamos a los metamodelos de BPMN y SoaML. En la Tabla 1 se muestran las principales correspondencias definidas entre los metamodelos involucrados, y las transformaciones QVT que los relacionan. Tabla 1. Principales relaciones y conceptos en las transformaciones QVT Modelo Procesos de Negocio Transformación QVT Modelo Servicios BusinessProcessDiagram Pool Lane Activity+IncomingMessages Activity+OutgoinMessages MessagingEdge+Target MessagingEdge+Source ProcessToModel PoolToParticipant LaneToParticipant ActivityMessageToServicePoint ActivityMessageToRequestPoint PoolMessageToServicePoint PoolMessageToRequestPoint ServicesModel Participant Participant ServicePoint RequestPoint ServicePoint RequestPoint ISSN SISTEDES

111 Las relaciones identificadas nos permiten obtener los primeros elementos en el modelo SoaML para definir la arquitectura de alto nivel. En la Tabla 2 se presenta un sub-conjunto de las transformaciones QVT definidas. De cada Pool se obtiene un participante en la arquitectura que serán quienes ofrezcan y requieran servicios, de cada Lane se obtiene un participante interno a éstos, que se utilizará en la definición de la arquitectura interna asociada al participante. Las actividades que se tendrán en cuenta para las transformaciones son las marcadas con el tipo Service que indica que esa actividad será soportada por un servicio. El marcado del modelo BPMN para generar servicios, lo realiza el Arquitecto de software como parte del diseño de servicios. Otras actividades podrán ser manuales o de cualquier otro tipo de BPMN y no serán transformadas. De los mensajes que entran a las actividades podemos identificar los servicios a proveer (para su ejecución) en los ServicePoint asociados al participante que corresponde al pool que contiene a la actividad. De los mensajes que salen de las actividades podemos identificar los servicios requeridos de otros participantes a los que corresponde el Pool que contiene a la actividad. En SoaML los ServicePoint y RequestPoint son conjugados, esto es si un participante brinda un servicio en un ServicePoint habrá otro que lo requiera en un RequestPoint. Debido a que en BPMN los mensajes pueden asociarse también a Pools sin necesidad de que estén específicamente asociados a una actividad en el Pool, deben ser identificados para generar también los servicios asociados. Esto ocurre generalmente cuando de un Pool no se conoce su Tabla 2. Sub-conjunto de las transformaciones QVT definidas de BPMN a SoaML. Reglas de relaciones definidas en QVT top relation ProcessToModel { checkonly domain bpmn bp : bpmn::bpmndiagram{name = pn}; enforce domain soaml sm : SoaML::Model{name = pn }; } top relation PoolToParticipant { checkonly domain bpmn p : bpmn::pool{name = pn}; enforce domain soaml s : SoaML::Participant{name = pn};} top relation LaneToParticipant { checkonly domain bpmn p : bpmn::lane{name = pn }; enforce domain soaml s : SoaML::Participant{ name = pn };} top relation ActivityMessageToServicePoint { checkonly domain bpmn c : bpmn::activity{lanes = p : bpmn::lane{}, activitytype = bpmn::activitytype::task, incomingmessages = im : bpmn::messagingedge{}, name = cn}; enforce domain soaml t : SoaML::ServicePoint { participant = s : SoaML::Participant {}, isservice = true, name = cn}; when { p.pool.bpmndiagram.pools.lanes.activities -> exists (x:bpmn::messagevertex (x.outgoingmessages.target = c.incomingmessages.target) and (x.oclastype(bpmn::activity). activitytype = c.activitytype)) or (p.pool.bpmndiagram.pools -> exists (x:bpmn::messagevertex (x.outgoingmessages.target = c.incomingmessages.target))); PoolToParticipant (p.pool, s); }} top relation PoolMessageToServicePoint { checkonly domain bpmn c : bpmn::messagingedge{ target = d : bpmn::messagevertex {name = cn} enforce domain soaml t : SoaML::ServicePoint { participant = s : SoaML::Participant {}, isservice = true, name = cn }; when {PoolToParticipant (d, s);}} ISSN SISTEDES

112 estructura interna (o no se quiere mostrar) y solo se definen los mensajes intercambiados con otros Pools. La granularidad de los servicios es un tema complejo y ampliamente tratado en la literatura [2][3]. Si bien en general es recomendable que la granularidad sea de tipo gruesa, servicios básicos generados podrán ser combinados en un servicio de mayor granularidad, si se considera adecuado. Como se puede observar en la Tabla 2, las primeras tres reglas permiten obtener el Model SoaML de servicios desde el diagrama de procesos con la regla ProcessToModel, y los participantes desde cada Pool y desde cada Lane dentro de los Pool, con las reglas PoolToParticipant y LaneToParticipant. Los primeros serán utilizados para definir la arquitectura de servicios para el proceso de negocio completo, los segundos serán utilizados para describir la arquitectura interna de cada uno de los anteriores. En la cuarta regla nombrada como ActivityMessageToServicePoint se generan los ServicePoint que serán los servicios provistos por los participantes con que esté asociada la actividad que los determina. En esta regla se recorren las actividades en el modelo BPMN para determinar las conexiones con mensajes existentes. Solo estamos transformando actividades conectadas con mensajes, esto es, actividades que se encuentran en distintos Pools, o Pools que se encuentran conectados con actividades. La expresión OCL en la cláusula when chequea que los mensajes entrantes a la actividad evaluada provenga de un Pool o de otra actividad. Esto es una restricción del metamodelo de la herramienta que estamos utilizando ya que los eventos y los gateways también están definidos como actividades, por lo que tuvimos que cambiar la restricción original de que el tipo de actividad fuera Servicio. La última regla denominada PoolMessageToServicePoint genera los ServicePoint que no están asociados con actividades sino directamente con Pools, como permite BPMN cuando un Pool no se encuentra expandido. Estas transformaciones no son las únicas que se pueden definir para obtener los elementos que estamos transformando, por lo cual estamos investigando también otras formas de obtenerlos, y de obtener el resto de los elementos para generar modelos SoaML completos. 4. Ejemplo de las transformaciones El ejemplo corresponde al proceso de negocio de un banco genérico Otorgar Préstamo en el cual hay tres participantes involucrados: el Cliente que solicita el préstamo, el Banco que recepciona la solicitud, la evalúa y autoriza o no el préstamo, y el Centro de Información de Créditos al cual el Banco le solicita información sobre la situación crediticia del Cliente, cuando la solicitud se encuentra en evaluación. En la Figura 1 en la sección 2 se puede ver el modelo del proceso de negocio Otorgar Préstamo en BPMN. Para realizar este ejemplo integramos varias herramientas al entorno Eclipse, ya que hemos definido en la dimensión de las herramientas de MINERVA el soporte [12] basado en Eclipse. Por lo que utilizamos para el modelado de procesos de negocio el plug-in de Eclipse BPMN Modeler [13], y para el modelado SoaML el plug-in Magic Draw Cameo SOA+ [14] debido a que no hay aún demasiadas implementaciones del estándar y queríamos una integración en Eclipse para tener todas las herramientas en el mismo entorno. Estamos definiendo nuestra implementación de un plug-in Eclipse para SoaML que integraremos. Desde el modelo SoaML es posible generar el código asociado con el motor MDA de ModelPro [15]. Para la definición y ejecución de las transformaciones QVT usamos el plug-in de Eclipse MediniQVT [16]. Como se observa en la Figura 1, además de los tres Pool mencionados el Banco tiene dos Lanes una para Servicios al Cliente y otra para Autorización de Préstamos. Existen tres mensajes enviados del Cliente al Banco, tres mensajes enviados del Banco al Cliente, y dos mensajes entre el Banco y el Centro de Autorización de Créditos. Los metamodelos del BPMN Modeler y de SoaML se cargan en el entorno Eclipse como metamodelos Ecore [17] mediante las facilidades que provee Eclipse, y el modelo del proceso de negocio Otorgar Préstamo en formato XMI, que cumple con el metamodelo de BPMN Modeler puede entonces ser transformada en un modelo SoaML en formato XMI que cumple con el metamodelo SoaML. Luego de ejecutar las transformaciones QVT se obtiene el archivo XMI que corresponde con el modelo SoaML generado. ISSN SISTEDES

113 Figura 3. Archivo XMI generado correspondiente al modelo SoaML La Figura 3 presenta el archivo XMI generado, y muestra los participantes generados correspondientes al Cliente, Banco y Centro de Información de Crédito, más los participantes internos al Banco Servicios al Cliente y Autorización de Préstamo. Para el Centro de Información de Crédito se obtiene el ServicePoint del mismo nombre, ya que al no estar expandido no se conocen sus actividades. Para el Banco se obtienen los ServicePoint: Registrar solicitud, Entregar contrato del préstamo, Registrar contrato del préstamo de la interacción de mensajes con el Cliente, y el ServicePoint Recibir información de crédito del cliente de la interacción con el Centro de Información. Para el Cliente se generan los ServicePoint: Recibir resolución, Firmar contrato del préstamo y Recibir dinero del préstamo de la interacción con el Banco. Todos los ServicePoint generados tienen el nombre de la actividad asociada, el atributo isservice en True, y tienen asociado el identificador del participante (interno) que los provee. Luego el archivo XMI se debe cargar en el modelador para visualizar los diagramas y desde estos generar el código. En la Figura 4 se muestra en forma gráfica la parte del diagrama Figura 4. Parte del Diagrama ServicesArchitecture en SoaML ISSN SISTEDES

114 ServicesArchitecture asociada con la generación de estos elementos básicos. El diagrama generado es parte del tipo de diagrama de ServicesArchitecture para definir la arquitectura de alto nivel para el proceso de negocio. Estamos trabajando en primera instancia con la vista estructural de servicios, para luego incorporar la generación de la parte dinámica asociada por ejemplo, a los contratos. La generación de los participantes involucrados y de los ServicePoint y RequestPoint asociados para proveer y requerir servicios entre ellos, corresponde a los elementos básicos con que se debe contar para presentar los diagramas SoaML completos. Como puede observarse en la Figura 4, se muestran los tres participantes del proceso de negocio generados, con ejemplos de puertos ServicePoint y RequestPoint asociados a cada uno, mostrando el tipo de las interfaces. Si bien aún no se generan los contratos de servicio, ni las interfaces asociadas con sus operaciones, parámetros y tipos de mensajes, la obtención de los elementos básicos de la ServicesArchitecture provee la base para el resto de las transformaciones. 5. Trabajos relacionados Existen varias propuestas para transformar y generar modelos de software desde procesos de negocio utilizando lenguajes existentes como QVT o ATL[18] o utilizando nuevos enfoques o lenguajes definidos. BPMN es la notación más utilizada para modelar procesos de negocio, y UML para el modelado de software y servicios. En [19] se proponen transformaciones de BPMN a UML pero con foco en elementos de seguridad agregados al modelo BPMN, para obtener primero un DA de UML y de ahí derivar casos de uso y clases de análisis. [20] también transforma BPMN en UML anotando el modelo BPMN con información a ser procesada por las transformaciones, obteniendo varios artefactos UML como DA, casos de uso y diagramas de colaboración y deployment. Ambos trabajos difieren del nuestro en que no usamos artefactos intermedios para pasar del modelo BPMN al modelo SoaML sino que lo hacemos directamente. En [21] se modela el comportamiento de sistemas Web con cuatro PIMs: servicios de usuario, casos de uso extendidos, proceso de servicios y composición de servicios, definiendo reglas de mapeo entre los modelos que se automatizan parcial o totalmente. En [22] se agrega un modelo de valor desde el cual se definen transformaciones a modelos de casos de uso, automatizadas con ATL, que también se usa en [23] definiendo dos tipos de reglas de transformación: de generación básica para crear elementos del modelo destino y de ligamiento para generar links entre éstos. A diferencia usamos metamodelos estándar existentes, derivando servicios directamente desde los procesos de negocio, con QVT. En [24] se definen transformaciones conceptuales basadas en la sucesiva aplicación de patrones desde la capa superior a la capa inferior, utilizando grafos para hacer pattern matching. [25] define dos pasos para transformar procesos de negocio en servicios: identificar tareas en los procesos que son invocaciones a servicios, luego integrando el modelado de procesos de negocio y objetos en un modelo de servicios del negocio (Business Service Model, BSM) mediador entre los requerimientos y su implementación. En contraste utilizamos modelo de diseño de servicios sin mediadores, y no proponemos nuevos patrones sino la utilización de patrones de procesos existentes, los patrones de procesos de negocio [26] principalmente para la validación de los modelos. Estamos explorando también su uso como guía en transformaciones más complejas. 6. Conclusiones y trabajo futuro La propuesta presentada para obtener modelos de servicios en SoaML desde modelos de procesos de negocio en BPMN mediante transformaciones QVT, pretende automatizar lo más posible la generación de servicios desde procesos de negocio, en base a la utilización de notaciones y lenguajes estándares. Si bien las transformaciones corresponden a un conjunto reducido de reglas para un conjunto reducido de elementos seleccionados de BPMN y SoaML, creemos que proveen la base para la definición de transformaciones para el resto de los elementos, que es en lo que estamos trabajando actualmente. Estas transformaciones se integran en la metodología BPSOM para desarrollo orientado a servicios desde procesos de negocio definido en el marco MINERVA que constituye el eje del trabajo de investigación. El marco está basado en ISSN SISTEDES

115 la integración y utilización de diversos estándares existentes para procesos de negocio, servicios y desarrollo dirigido por modelos. En ese sentido BPMN, SoaML y QVT, alineado con MDA, son estándares de OMG integrados para la generación automática de servicios presentada en este artículo. De la misma forma el soporte de herramientas definido está basado en el entorno Eclipse, integrando diversos plug-ins que soporten las distintas etapas del desarrollo. Adicionalmente estamos trabajando en la definición de un plug-in de Eclipse propio para implementar el estándar SoaML que se integre en el entorno. El conjunto completo de transformaciones QVT con el soporte metodológico y de herramientas integrado en el marco MINERVA servirá para guiar todo el proceso de desarrollo de aplicaciones orientadas a servicios desde procesos de negocio. Creemos que MINERVA puede resultar una guía útil y soporte de herramientas basado en Eclipse, para ser utilizado en organizaciones que requieran una integración rápida y fácil de metodologías, herramientas y conceptos para adoptar los paradigmas BPM, SOC y MDD. Agradecimientos. Este trabajo ha sido parcialmente financiado por la Agencia Nacional de Investigación e Innovación (ANII), Uruguay, proyecto ALTAMIRA (Junta de Comunidades de Castilla-La Mancha, España, Fondo Social Europeo, PII2I ), proyecto PEGASO /MAGO (Ministerio de Ciencia e Innovación MICINN, España, y Fondo Europeo de Desarrollo Regional FEDER, TIN C02-01). Referencias [1] Papazoglou, M.; Traverso, P.; Dustdar, S.; Leymann, F.: Service-Oriented Computing: State of the Art and Research Challenge, IEEE Computer Society, (2007). [2] Erl, T.,Service-Oriented Architecture: Concepts, Technology, and Design, PrenticeHall, (2005). [3] Krafzig, D., et.al, Enterprise SOA, SOA: Best Practices, Prentice Hall, (2005). [4] Smith,H.,Fingar,P.,Business Process Management: The third wave, Meghan- Kieffer, (2003). [5] Mellor, S., Clark, A., Futagami, T., Model Driven Development - Guest editors introduction, IEEE Computer Society, September/October, (2003). [6] Soa Modeling Language (SoaML),v.1.0 Beta1, OMG, (2009). [7] Query/Views/Transformations (QVT), v.1.0, OMG, (2008). [8] Business Process Modeling Notation (BPMN), OMG, (2008). [9] Delgado A., Ruiz F., García-Rodríguez de Guzmán I., Piattini M:, MINERVA: Model driven and service oriented framework for the continuous business processes improvement & related tools, In: 5th IW on Engineering Service-Oriented Applications (WESOA 09), in ICSOC, Stockholm, (2009). [10] Delgado A., Ruiz F., García-Rodríguez de Guzmán I.,Piattini M., Towards a Service- Oriented and Model-Driven framework with business processes as first-class citizens, In: 2nd IC on Business Process and Services Computing (BPSC 09),Leipzig, (2009). [11] Delgado A., Ruiz F., García-Rodríguez de Guzmán I., Piattini M., Towards an ontology for service oriented modeling supporting business processes, 4th. IC on Research Challenges in Information Science (RCIS 10), Nice, (2010). [12] Delgado, A., García - Rodríguez de Guzmán, I., Ruiz, F., Piattini, M.: Tool support for Service Oriented development from Business Processes, 2nd Int. Work. on Model-Driven Service Engineering (MOSE 10), in TOOLS, Málaga, (2010) [13] SOA Tools Platform (STP) BPMN Modeler, [14] Magic Draw Cameo SOA+, [15] ModelPro, [16] Medini QVT, ikv++ technlogies ag, [17] Eclipse Process Framework Composer (EPF Composer), [18] Jouault, F., Kurtev, I., Transforming Models with ATL (ATLAS Transformation Language), Satellite Events at MoDELS Conference (2006) [19] Rodríguez,A.; Fernández-Medina, E.; Piattini, M.: Towards CIM to PIM Transformation: From Secure Business Processes Defined in ISSN SISTEDES

116 BPMN to Use-Cases. 5th International Conference on Business Process Management (BPM 07), (2007). [20] Liew,P., Kontogiannis,K. Tong,T., A Framework for Business Model Driven Development,12th Int. Workshop on Sw. Tech. and Eng. Practice (STEP 04), (2004). [21] de Castro, V., Marcos, E., López Sanz, M., A model driven method for service composition modelling: a case study, Int. J. Web Engineering and Tech., Vol. 2, No. 4, (2006) [22] de Castro V., Vara Mesa J. M., Herrmann E., Marcos E., A Model Driven Approach for the Alignment of Business and Information Systems Models, (2008) [23] Touzi J., Benaben F., Pingaud H., Lorré J.P., A model-driven approach for collaborative service-oriented architecture design, Int. J. of Prod. Economics,Vol.121 Is. 1, (2009) [24] Gacitua-Decar V., Pahl C., Pattern-based business-driven analysis and design of service architectures, 3rd Int. Conf. on Software and Data Technologies SE (ICSOFT 08), (2008) [25] Rychly M., Weiss P., Modeling of SOA: from business process to service realization, 3rd Int. Conf. on Evaluation of Novel Approaches to SE, (ENASE 08), (2008) [26] van der Aalst, W.; ter Hofstede, A.; Kiepuszewski, B.; Barros, A Workflow Patterns, In Distributed and Parallel Databases, 14(3), pages ISSN SISTEDES

117 Variability Issues in MARTE for SPL Model Analysis Lorea Belategi, Goiuria Sagardui, Joseba Andoni Agirre, Leire Etxeberria Mondragon Unibertsitatea Loramendi 4, Arrasate-Mondragon {lbelategui, gsagardui, jaagirre, Abstract Nowadays, embedded systems are more and more common and their software is increasing its complexity dealing with quality, cost and time-tomarket among others. Quality attributes are an important issue to take into account in embedded software development where time issues may be critical. Development paradigms like Model Driven Development (MDD) and Software Product Lines (SPL) can be an adequate alternative to traditional software development and validation methods, facilitating software validation based on models like model analysis. In order to perform embedded SPL model analysis with MARTE profile, some variability aspects that take part in validation (like functional, quality attributes, platform and allocation) must be considered, modelled and managed. Thus, a study of variability issues in order to perform SPL model analysis with MARTE has been done. 1. Introduction Cost, quality and time-to-market have been the main concerns in software engineering since the beginning. In embedded systems, not only development time must be met and changing requirements managed as in other domains. Software architectures are usually complex and fragile, technological platforms evolve and change constantly and requirements such as reliability and safety add even more complexity to the development process. In this context, it becomes essential to use a development methodology that is flexible enough to capture this complexity. One of the main issues in software development is to ensure that the final product satisfies all requirements (functional and quality attributes) and this becomes more critical in embedded systems where heterogeneity (hardware/software), distribution (on potential multiple and heterogeneous hardware resources), ability to react (supervision, user interfaces modes), criticality, real-time and consumption constraints are their characteristics [1]. Embedded systems usually are systems with critical temporal aspects to meet among others because of their characteristics. Therefore, software validation from early development stages is crucial in embedded systems. However, making embedded software validation is not trivial. SPL and MDD development paradigms can be an adequate alternative to traditional embedded software development and validation methods. Embedded systems usually are similar products with some variability in hardware and/or software and SPL are able to manage common and variant features among members of the line. In an embedded product line different members of the line may vary from each other in terms of their behaviour, quality attributes, platform, network, physical configuration, middleware, and scale factors and in a multitude of other ways [19]. MDD abstracts from system complexity by the use of models, where information related to the critical quality attribute can be attached and used for model analysis (a model validation technique). Combining both paradigms facilitates the software architecture analysis by performing model analysis technique. The architecture is the first design artifact that addresses the quality goals of the system such as security, reliability, usability, modifiability and real-time performance [19]. MARTE (UML Profile for Modeling and Analysis of Real-Time and Embedded systems) [1] profile standardized by OMG, defines quantitative performance annotations (such as resource demands made by different software execution steps, performance requirements, etc.) to be included in a model. ISSN SISTEDES

118 MARTE profile allows annotating temporal aspects (information related to schedulability and performance) in models in order to analyze or determine whether they will meet those temporal requirements. Performance analysis uses stochastic techniques such as queuing theory or Petri nets to calculate response times, delays and resources requirements. Thus, they are aimed at determining the rate at which a system can perform a function [6]. Schedulability analysis is a set of mathematical analysis that allows a designer to determine the predictability of a system, i.e. whether it is able to meet its timing requirements [15]. All variability issues (system behaviour, platform, quality, etc.) that must be taken into account make variability management task essential in order to ensure quality of the products among other requirements. Variability management deals with specific product differences by handling: 1) variation points and variants that are essential for modelling a SPL and 2) deriving different products from the line. This paper presents a study about required variability in MARTE model analysis of embedded SPL. The study takes into consideration functional, quality attributes, platform, allocation and analysis variability and also justifies variability management necessity. The study has three phases: 1) identifying required variability types in model analysis, 2) associate those variability types with elements of the MARTE profile identifying mechanisms the profile has to model variability and 3) analyzing which other existing mechanisms can be combined to fill the gaps in MARTE. The paper is organized as follows: Section 2 presents how is performed analysis in MARTE, required variability in MARTE and mechanisms for modelling them is described in Section 3, Section 4 analyzes other works related to the same topic and Section 5 presents the conclusions and future work. 2. Analysis in MARTE - AnalysisContext MARTE analysis is intended to support accurate and trustworthy evaluations using formal quantitative analyses based on mathematical models [1]. Quantitative analysis techniques determine the output values such as response times, deadline failures, resource utilizations, etc. based on data provided as input; e.g., execution demands or deadlines. For this purpose, MARTE has a GQAM (Generic Quantitative Analysis Modelling) package that describes stereotypes (that map model elements into the semantics of an analysis domain) and tagged values used in analysis models. The main concern to perform model analysis with MARTE profile is the AnalysisContext. It identifies the model elements of interest (diagrams that gather information about system behaviour and workload, and execution platform and allocation) for the analysis and specifies global parameters of the analysis (global properties that describe different cases being considered for analysis). Therefore, stereotypes related with AnalysisContext term are classified in two concepts: WorkloadBehaviour: It is a container of a set of end-to-end system operations used for analysis and defined by a set of workload events triggered over time. These stereotypes are used in application models where constraints, scenarios and software design are specified, including functional and nonfunctional requirements. ResourcesPlatform: It is a container for the resources used by the system behaviour represented by the design model. These stereotypes are used in platform and allocation models where resources and their properties are described and platform design is specified. To conclude, AnalysisContext allows analyzing what it could be a real-time situation of the system by describing a specific scenario and the execution platform through analysis models with non-functional annotations (see Fig. 1). Thus, next table presents the stereotypes that are included in each group and are extended in specific schedulability (SAM) and performance (PAM) profiles (see Table 1): ISSN SISTEDES

119 Table 1. Stereotypes for analysis annotation MARTE Analysis Concept WorkloadBehaviour (application model) ResourcesPlatform (platform and allocation model) Annotation model element GaWorkloadEvent GaStep GaScenario ProcessingResource DeviceResource SchedulableResource Description It describes particular request stimulus that can occur repeatedly originated outside the system, inside the system or because of the passage of time. It describes an operation that demands a resource usage (ExecutionHost) and uses an operation system process (SchedulableResource). It is the description of system behaviour that executes in response to event occurrences. It is an active, protected resource that is allocated to the execution of schedulable resources. It represents an external device that may require specific services in the platform for its usage and/or management. It is an element that takes the processing capacity from another active protected resource (usually a ProcessingResource) and competed for it with others. Fig. 1 AnalysisContext concept definition [7] 3. Required variability in MARTE Variability is the key aspect of SPL that must be considered when analyzing models and as it was previously mentioned, embedded SPL may have diverse variability issues: Some functionality may vary from one product of the line to another. Not all products of the product line have the same functionalities. Two products with the same functionality may require different quality attributes, as well as the priority or degree of them. Impacts may also arise among different quality attributes and/or other variability issues [8]. Variability can be addressed at execution environment. Often, some of the hardware devices and other performance-affecting factors can vary from one product to another [6]. Different platform designs can also take part in the execution platform model. ISSN SISTEDES

120 All these variability issues make primordial to consider variability in model analysis as they represent software behaviour and platform. Different products of the line require performing different analysis varying from one product to another one. As a result, analysis process and AnalysisContext term must be extended to address SPL analysis. Therefore, this variability is related to the next analysis concepts in a lower abstraction level in a SPL development: Each product model requires analyzing specific behaviours (GaWorkloadBehaviour). Behaviour models must be developed or adapted for the specific model as not all products of the line may have same features. These models are composed by different model elements due to SPL features diversity (e.g., different objects, lifelines or activities). A scenario may be composed by different GaSteps, stimulated by different GaWorkloadEvent and composed by different scenarios (GaScenario). As software may run under different platforms, execution platform variability must be taken into account. Same scenario may run in different platforms (GaResourcesPlatform) and software to platform mapping (software allocation) may be different, e.g. in order to analyzed which allocation is the one that best suits required features. Non-functional properties may vary from one specific model to another, as not all products require same quality and not same model elements take part in the specific model. Information related to the quality attributes are attached by specific stereotypes (PaStep, SaStep, GaExecutionHost, etc.) and tagged values (hostdemand, ExecTime, etc.) that can be found in GQAM, PAM and SAM packages of the MARTE profile. Not all products of the line require same analysis, thus diverse AnalysisContext must be specified. MARTE profile is a UML profile specification for single real-time embedded systems. But when concepts from SPL paradigm like variability are faced for example, other mechanisms are necessary for a proper analysis and management. Therefore, analysis models have been studied to identify and specify required system variability in analysis (see Table 2). Table 2. Required variability in MARTE analysis elements Analysis Element End2EndFlow and GaWorkloadEvent GaWorkloadBehaviour and GaScenario GaStep PlatformResource Parameters and tagged values Variability 3.1. Variability in AnalysisContext Some functionalities may require particular End2EndFlows and/or GaWorkloadEvent. These terms may be mandatory, optional or alternative. A particular configuration requires specific scenarios that other configuration may not require. That is to say, some system behaviours can be analyzed in specific configurations. Different operations may be executed by a model element in a scenario. GaStep may be mandatory, optional or alternative depending on the model elements. Different execution platforms are necessary. Thus, different platform designs and alternative resources (DeviceResource or ProcessingResource) that take part and can be replaced easily in the system are required. Alternative deployment designs due to alternative platform designs are needed (software allocation). To represent alternative values (hostdemand, SchedPrioRange, etc.) in model elements. The aim of specifying AnalysisContexts is to evaluate critical quality attributes in a specific scenario that an embedded system may execute. In an embedded SPL different AnalysisContexts must be defined due to the high variability that can be found. This way, each specific product model can be validated in order to evaluate whether they satisfy required quality attributes. AnalysisContext itself also requires variability elements as a result of different behaviours of the specific product models of the line. This variability issues are specified below: GaWorkloadBehaviour: It is defined by End2EndFlows composed by GaScenarios and GaWorkloadEvents. In schedulability AnalysisContext (SaAnalysisContext), End2EndFlows may be optional due to functional variability. GaWorkloadEvent: A GaScenario can be activated by different GaWorkloadEvents and ISSN SISTEDES

121 these GaWorkloadEvents can have a different arrival pattern as defined in MARTE: periodic, aperiodic, sporadic, burst, irregular, closed and open. GaScenario: A scenario is composed by a set of GaSteps. Due to functional variability of the line, a GaStep or a set of them may be optional or alternative. GaResourcesPlatform: An execution platform may be built by different resources and different designs, concluding in execution platform variability. Besides, software to platform mapping may be different. Thus, variant resources (DeviceResources and ProcessingResources), optional SchedulableResources and alternative software allocation are required. As information related to quality attributes is attached in models representing behaviour and execution platform, and quality attributes may vary from one model of the line to another, stereotypes and tagged values may vary. Each quality attribute has its own stereotypes and tagged values. Tagged values may take alternative values and they may be dependent of other tagged values. Var: Each AnalysisContext is specified by a set of variables, a scenario and a platform. The set of variables depend on the scenario and the platform and they may be input, output or input/output variables. With the aim to be able to model required variability in AnalysisContext existing mechanisms have been analyzed: MARTE uses predefined model libraries to apply to real-time and embedded systems. These model libraries are containers of predefined data types, time, measurement units, etc. that are used for example, to specify data size unit kind of messages. As a container concept, it can store different model elements. Variables: Variables are a common mechanism that it may be applied to let an element in a generic way instead of instantiate into a specific element or until a decision is taken. MARTE defines variables by $ symbol. Any value of the same type can be assigned to that variable. Usually it is assigned to tagged values until instantiation time, instead of bounding a specific value from the beginning. They can also be used in value expressions in dependent tagged values. AnalysisContext: This concept is the variability mechanism specified by MARTE for model analysis. It identifies the model elements (diagrams) of interest and specifies global parameters of the analysis. A specific product model may have several AnalysisContexts. UML mechanisms: A combinedfragment defines an expression of iteration fragments [16]. There are different CombinedFragments, which are distinguished by its iteration operator, such us: OPT, ALT, LOOP, etc. For example, ALT operator designates that the CombinedFragment represents a choice of behaviour and at most, one of the operands can be chosen. On the other hand, OPT operator designates that the CombinedFragment represents a choice of behaviour in sequence diagrams where the only operand happens or nothing happens. Abstract stereotype, inheritance, interface implementation, etc. are also UML mechanisms that can help when analyzing SPL models, e.g., abstract stereotype can be applied in activity diagrams. Variability profiles: Functional variability has been a deep research topic. There are several UML profiles for specifying variability where some of them focus on functional aspects and extend use cases to specify variability; others, extend static models to specify variability and few works model variability in behavioural models. Gomaa s [10] product line profile called PLUS is one of the most complete profile. It takes into account feature modelling, use cases, static and dynamic interaction modelling, etc. Moreover it is a well developed method applied to real-time systems that it is concerned with the behaviour view needed for performance analysis [23]. Ziadi s UML profile for Product Lines [25] is also a representative profile. It extends class and sequence diagrams to include variability and provides support for product derivation via PL constraints that guide the derivation process. It is the only one that concerns UML2.0 models and not UML1.x models. UML-F [17], UML ISSN SISTEDES

122 profile for frameworks can be also useful when product-lines have been developed following a framework based approach. CVL (Common Variability Language) is a variability specification language (still in development), that follows a separate language approach, and allows expressing variability in a base model and relationships between possible choices and the base model [12]. Variability profiles apply stereotypes to include variability in UML models. More than one stereotype can be applied to UML elements. A UML class can be stereotyped as <<optional>> and <<DeviceResource>>. Thus, more than one profile can be used in a model. This mechanism may help to identify variable model elements in analysis. These mechanisms may help modelling variability in MARTE AnalysisContext. In Table 3 how the aforementioned variability mechanisms can be applied on MARTE analysis elements is detailed. Table 3. Mapping of analysis elements and variability mechanisms that can be applied Analysis Element Variability Mechanism Workload Behaviour Platform Resources GaWorkloadEvent GaScenario GaStep GaPlatformResource Allocation Variability profile CombinedFragments Variables AnalysisContext UML mechanisms Variability profile model library AnalysisContext Variables UML mechanisms Var ContextParameters Variability profile Variables AnalysisContext To perform a proper analysis of variable embedded systems, it is not enough with the mechanisms that UML and MARTE provide. It is necessary to be able to model and manage that variability. UML and MARTE afford variability modelling but not managing. Other mechanisms are necessary for that purpose, e.g. feature models. Feature modelling [13] was introduced as part of the domain analysis and domain modelling phase to systematically describe the common and variable features shared among the products of a product line. In [18] it is mentioned that feature modelling supports several areas of product line engineering, especially scoping and the configuration and derivation of products from the reuse infrastructure, but also activities like project planning and tracking, testing and customer negotiations Example Elements and/or concepts that have been aforementioned are intended to describe by the following example. A feature model of an embedded software product line and in particular of an elevator system is represented in Fig. 2. The feature model has been simplified for a better understanding such as required and excluded relations among features. The functional features described possible functionalities of the system to analyze and are related to those MARTE profile behaviour aspects (WorkloadBehaviour) and more specifically to the end-to-end operations of the system (EndToEndFlow) and scenarios (GaScenario and GaStep). In this case, self-healing optional feature will be related with an optional EndToEndFlow and a specific scenario. It also is related to the behaviour the variable design, e.g., if a system is centralized or distributed. The elevator system will behave in different ways in both cases, executing different GaSteps. Different types of processors with their properties, sensors, communication systems, etc. define the variable part of the platform used in PlatformResources. The analyses to perform may vary from one product to another product of the line due to require different quality attributes, or by the analysis type, method, etc. These concepts are related to the AnalysisContext and stereotypes and tagged values of the MARTE profile related to quality attributes, e.g., to perform performance analysis, the models have to be annotated by the stereotypes of the PAM package. The stereotypes and tagged values used when annotating quality attributes variability are also related to PlatformResources properties and also to WorkloadBehaviour. For example, ISSN SISTEDES

123 GaWorkloadEvent of an EndToEndFlow can be generated in different ways: by a timed event, by an arrival pattern By different properties, functionalities, quality attribute variability may be obtained as a result. Fig. 2 Feature model 4. Related Work To be able to validate variability of quality attributes at early development phases facilitates obtaining products with the same functionality but different quality levels through model analysis. Quality variability must be an issue to take into account during embedded software development and that affect the decision-making. Variability modelling is important for managing variability in software product families [21]. Different approaches have been proposed related to variability modelling and management, but those techniques rely on different technical background and most variability modelling techniques lack a description of a process [4]. Existing literature does recognize the importance of managing variability in a proper way. Bosch [3] emphasizes the importance of the variability management. Over the last years, several variability modelling techniques have been developed that are aimed to support variability management. Despite these mechanisms are suitable for managing variability and feature models are widely used in embedded systems domains [24] [20] [2], no standard way is defined yet and few works cover other phases of the SPL development like software validation. CVL allows expressing variability in a base model (in a separate way). It also allows defining the relationships between possible choices and the base model [12]. Modelling languages that have been specified for embedded systems like SysML [22] and EAST-ADL2 [2] can also be complementary on SPL analysis. SysML complements UML with two new diagrams (requirements and parametric) and modifies some existing (activity, block definition and internal block). EAST-ADL2 is a domain specific modelling language where functionalities are decomposed through different abstraction levels and development phases. It takes feature modelling as a reference and uses variation points concept. UML provides other mechanisms such as: abstract objects, interface implementation, inheritance and CombinedFragments to be able to represent variability in software. In [14] a model based methodology oriented to distributed embedded and real-time applications development is proposed. It focuses on the ISSN SISTEDES

124 requirements traceability management while variability and verification phase is left for future work. Tawhid and Petriu model a software product line with functional variability and annotated with MARTE profile to perform performance analysis [23]. Information related to performance is attached in a general way using variables. And in order to validate quality aspects, concrete values are assigned to those variables through ATL (Atlas Transformation Language) transformations that are also used to obtain a concrete product model, but variability management is slightly defined. Espinoza et al. [5] propose to use a similar diagram to SysML parametric diagrams in MARTE analysis for complex non-functional evaluation scenarios taking into account variations in the mapping from structure to architectural resources and parameterization i.e., propose to composite existing design models to experiment with different implementation or design decisions for the purpose of quantitative analysis. Groher et. al. [11] present a tool-based approach for managing crosscutting feature variability in software product lines using aspectoriented principles. The approaches mentioned before can be complementary to model analysis. None of them deals with all necessary issues for embedded software product line model analysis but the contributions made by them can be combined to reach variability goal in model analysis. 5. Conclusions and Future Trends In the present paper required variability issues in MARTE model analysis for SPL (as MARTE profile was defined for single systems analysis) and diverse variability modelling mechanisms have been analyzed. Modelling and management mechanisms can be complementary and a suitable combination of them could be beneficial to tackle SPL model analysis. The future work to be carried out includes the definition of a management mechanism for all variability types identified for model analysis. Functional, quality attributes, platform, allocation and analysis variability must be considered and properly managed in order to perform model analysis and identify critical analysis scenarios for each specific product model of the product line. Traceability links from features to analysis models will be required for that purpose too. Thus, the combination of the studied mechanisms for embedded SPL analysis will be specified and will enable the creation of new mechanisms for variability management. A case study will be also performed to identify possible conflicts or problems and validate the proposal. Another research way is to study whether existing tools could help in managing variability like pure::variants [9], a tool for managing variability that focuses on development. As most of the mechanisms focus on variability management of initial phases such as feature modelling, they lack of a way to represent lower level concepts. It becomes essential the study of how existing methods and mechanisms can be combined and/or extended for this purpose (next step) trying to give traceability and a proper variability management based on UML techniques and standard profiles. We intend to extend the work presented in [5] by Espinoza et al. to tackle SPL model analysis. They propose analysis composition view for analysis which can help on SPL analysis but there is a lack of how this approach may be linked to variability management or feature-oriented methods as it was a proposal for the analysis of a single-system. Acknowledgements. This work was partially supported by The Basque Government under grants PI (OPTIMA) and the Spanish Ministry of Science and Education under grants TIN (OPTIMA) and TSI (EVOLVE). It has been developed by the embedded system group supported by the Department of Education, Universities and Research of the Basque Government. References [1] UML Profile for Modeling and Analysis of Real-Time Embedded Systems. formal/ (2009) [2] Albinet, A., Begoc, S., Boulanger, J. -. et al.: The MeMVaTEx Methodology: From Requirements to Models in Automotive ISSN SISTEDES

125 Application Design, 4th European Congress Embedded Real Time Software - ERTS'08, Toulouse, France (2008) [3] Bosch, J.: Design and use of software architectures: Adopting and evolving a product-line approach. ACM Press/Addison- Wesley Publishing Co, New York, USA (2000) [4] Deelstra, S., & Sinnema, M.: Managing the Complexity of Variability in Software Product Families. (2008) [5] Espinoza, H., Servat, D., Gérard, S.: Leveraging Analysis-Aided Design Decision Knowledge in UML-Based Development of Embedded Systems, SHARK '08: Proc. of the 3rd int. workshop on Sharing and reusing architectural knowledge, ACM (2008) [6] Espinoza, H.: An Integrated Model-Driven Framework for Specifying and Analyzing Non-Functional Properties of Real-Time Systems, Thesis. DRT/LIST/DTSI/SOL/07-265/HE (2007) [7] Espinoza, H., Terrier, F., Gérard, S.: Model Driven Engineering and Real-Time Analysis of Embedded Systems: The UML MARTE Standard and its Challenges, ARTIST Workshop at CAV 2007, Berlin, Germany (2007) [8] Etxeberria, L., Sagardui, G., Belategi, L.: Quality Aware Software Product Line Engineering. Journal of the Brazilian Computer Society (JBCS), 14 (2008) [9] GmbH, p.: Variant Management with Pure::Variants, Technical Paper, Available from (2007) [10] Gomaa, H.: Designing software product lines with UML: From use cases to pattern-based software architectures. Addison Wesley Longman Publishing Co., Inc, Redwood City, CA, USA (2004) [11] Groher, I., Krueger, C. W., Schwanninger, C.: A Tool-Based Approach to Managing Crosscutting Feature Implementations. AOSD'08, (2008) [12] Haugen, Ø., Oldevik, B., Olsen, J.: Adding Standardized Variability to Domain Specific Languages, 12th International Software Product Line Conference, SPLC'08. (2008) [13] Kang, K., Cohen, S., Hess, J. et al.: Feature- Oriented Domain Analysis (FODA) Feasibility Study, Technical Report, SEI (1990) [14] Le Dang, H., Dubois, H., Gérard, S.: Towards a Traceability Model in a MARTE- Based Methodology for Real-Time Embedded Systems. Innovations in Systems and Software Engineering, Springer-Verlag London Limited, 4 (2008) [15] Martins, P.: Integrating Real-Time UML Models with Schedulability Analysis, Technical Report, Tri-Pacific Software Inc... (2003) [16] Superstructure Version 2.2. Object Management Group, formal/ (2009) [17] Pree, W., Fontoura, M., Rumpe, B.: Product Line Annotations with UML-F, SPLC 2: Proc. of the 2nd Int. Conference on Software Product Lines (2002) [18] Schwanninger, C., Groher, I., Elsner, C. et al.: Variability Modelling Throughout the Product Line Lifecycle. MODELS 2009, 5795 (2009) [19] SEI: A Framework for Software Product Line Practice, Version [20] Shi, J.: Model and Tool Integration in High Level Design of Embedded Systems, Thesis. (2007) [21] Sinnema, M., & Deelstra, S.: Classifying Variability Modeling Techniques. Inf.Softw.Technol., 49 (2007) [22] OMG System Modeling Language (OMG SysML) V1.0. formal/ (2007) [23] Tawhid, R., & Petriu, D.: Integrating Performance Analysis in the Model Driven Development of Software Product Lines, MODELS 08, 5301 LNCS (2008) [24] Zha, X. F., Fenves, S. J., Sriram, R. D.: A Feature-Based Approach to Embedded System Hardware and Software Co-Design, ASME DETC. (2005) [25] Ziadi, T., Hélouët, L., Jézéquel, J.: Towards a UML Profile for Software Product Lines, 5th Int. Workshop on Product Familly Engineering (PFE-5), LNCS 3014 (2003) ISSN SISTEDES

126 Un motor de generación de código dirigido por modelos de base de datos, como punto de partida para la implantación de una plataforma MDA en la administración balear. Víctor García Pau Facultatiu Superior Informàtic Conselleria de Treball i Formació Comunitat Autònoma de les Illes Balears Palma de Mallorca vgarcia@sgttif.caib.es José A. Carsí Titular de Universidad Dpto. de Sistemas Informáticos y Computación Universidad Politécnica de Valencia Valencia pcarsi@dsic.upv.es Resumen Para poder beneficiarse de una orientación fabril de la producción de software en una administración pública: aumento de la productividad, estandarización de la calidad del producto y reducción drástica del plazo de los entregables, incluido el prototipo ejecutable; parece imponerse el uso de las tecnologías dirigidas por modelos. Ahora bien, se debería considerar qué tipo de modelo es el más adecuado para la especificación del motor MDD, si no se dispone de la suficiente cultura UML ni de la confianza en el dominio de las técnicas de MDA. Una alternativa en este caso es utilizar un PSM origen poblado a partir del propio esquema relacional obtenido mediante ingeniería inversa. Este modelo de diseño relacional ha sido aplicado de forma homogénea a todos los sistemas de información de la organización. A partir del PSM destino el motor genera un prototipo ejecutable compuesto por un árbol de mantenimientos siguiendo el patrón previamente definido de maestro-multi-detalle, integrado con la gestión documental de la Conselleria de Treball i Formació y la plataforma telemática del Govern Balear. A partir de los resultados obtenidos con el motor, se estudia su integración con la plataforma ofrecida por Moskitt.org, con el objeto de abrir brecha hacia una arquitectura dirigida por modelos y la implantación efectiva de Métrica3 en esta administración pública. Palabras Clave generación de código dirigida por modelos de base de datos, ingeniería inversa, administración electrónica, Moskitt, Métrica3 1. Introducción La implantación de Métrica3 y de cualquier otra metodología de desarrollo de software en una organización, pasa inevitablemente por la evaluación de su viabilidad y aplicabilidad. En el caso de las administraciones públicas la metodología de uso obligado es Métrica3. Diseñada con espíritu unificador, tanto en su vertiente orientada a objetos como en la estructurada, define una nutrida secuencia de actividades, técnicas y prácticas a realizar, cubriendo en su totalidad el ciclo de vida del sistema de información. Por contra penaliza su aplicabilidad incrementando el coste de utilización. Son bien conocidos los beneficios y las ventajas derivados de la implantación de una metodología de desarrollo, pero para que pueda ser una realidad se requiere la provisión de instrumentos que permitan compensar los grandes costes requeridos, con los limitados recursos disponibles. Requiere una herramienta que esté enfocada a la automatización, reutilización y transferencia automática de los requisitos capturados desde una fase a las siguientes. Una transformación de los modelos de elicitación de requisitos a los entregables requeridos en plazo, incluido el sistema final ejecutable, sus pruebas y/o prototipos. Para ello se impone un enfoque dirigido por modelos, que mediante la generación automática de los entregables conformaría una implantación ágil de la metodología. Siguiendo los mismos criterios de economía de medios, la solución que se adopte necesita ser viable para la coyuntura de la organización que pretenda acogerse a este enfoque. Se parte de una ISSN SISTEDES

127 situación en la que no existe una cultura UML suficiente, ni dominio de las técnicas de MDA[19] con las que dirigir el proceso software que se pretende implantar. Por otra parte, no se cuenta con un equipo de técnicos estable y suficientemente capacitados en todas las tecnologías a cubrir para poder desarrollar el software requerido por los estrictos estándares de desarrollo definidos por la Direcció General de Tecnologia i Comunicacions (DGTiC) y la propia Conselleria de Treball i Formació (CTiF) de la Comunitat Autònoma de les Illes Balears (CAIB). Inicialmente se evaluaron las herramientas de generación de código de JBoss como Hibernate Tools y el framework de Seam, tanto su configuración como personalización mediante la adaptación de sus plantillas y procesos de ingeniería inversa. Pero debido a la antigüedad de las versiones requeridas por la plataforma se imposibilitaba o dificultaba en exceso su utilización. Además, el hecho de no tener pleno conocimiento de los metamodelos empleados por estas herramientas penalizaba el coste de desarrollo de una solución suficientemente adaptada a la plataforma. Por tanto y con el objeto de convencer con tangibles se comenzó con el desarrollo de un motor de generación de código propio que permitiera dar resultados modestos pero estables y conformes a los requerimientos definidos por los estándares a cumplir. Para ello se definió previamente una solución arquitectónica conforme a la plataforma que permitiera cubrir mediante una solución genérica, las necesidades de gestión de las aplicaciones corporativas. Básicamente se pretendía migrar a la plataforma JEE oficial un conjunto de aplicaciones desarrolladas en Ms Access, entre otras razones debido a la cancelación de las licencias de uso por parte de esta administración. Para ello, se identificó la solución maestro-detalle de Ms Access como una interfaz deseable a la que se le debía añadir una integración con la gestión documental de la CTiF y con la plataforma telemática de la CAIB. Por otra parte debido a la carencia de técnicas y recursos, y a la implantación extensiva de un estricto estándar de base de datos en todos los sistemas de información de la organización, se eligió utilizar el PSM relacional de la base de datos obtenido mediante ingeniería inversa para dirigir el proceso de generación de código. Ya que el esquema relacional representa una proyección unívoca de la especificación entidad-relación del sistema conforme al estándar corporativo. De esta forma se salva el desnivel tecnológico del equipo y se cubre la totalidad de los sistemas de información de forma casi automática, únicamente definiendo la lista de patrones de nombres de tablas que conformarán la aplicación a generar, así como cierta información de configuración de la generación. La solución arquitectónica ha sido iterada según evolucionaba y con ella el propio motor de generación. En paralelo se han evaluado diferentes plataformas y herramientas para facilitar la implantación de la metodología del proceso software. Entre otras cabe destacar las herramientas de Visual Paradigme, Enterprise Architect y Moskitt. El hecho de que Moskitt sea una plataforma MDE que soporta a Métrica3 y además de código abierto sobre Eclipse (el IDE de desarrollo utilizado por la CTiF) determinó su elección. Por lo que se procedió a estudiar los posibles caminos de integración con dicha herramienta. El presente artículo pretende describir el proceso de definición, construcción e integración de un motor de generación de código estructural, Es.Caib.SwFactory, para una estricta arquitectura JEE/ ExtJs en un contexto desfavorable, orientado a formar parte esencial en una plataforma MDA para la administración balear. En la siguiente sección se presentan los detalles del motor de generación de código. En el tercer apartado se estudian posibles vías de integración con Moskitt y finalmente en la cuarta sección se expondrán las conclusiones y trabajos futuros. Figura 1. Etapas del proceso de generación. ISSN SISTEDES

128 2. Motor de generación de código dirigido por modelos de datos: Es.Caib.SwFactory. El motor de generación de código es una sencilla herramienta escrita en Java que implementa el proceso de generación en base a un metamodelo que es instanciado por un motor de ingeniería inversa a partir de los metadatos de la base de datos. El proceso de generación de código descrito en la figura 1, costa de cuatro etapas: obtención y análisis de argumentos, extracción de los metadatos del esquema relacional mediante ingeniería inversa, cálculo de los elementos del modelo instanciado y generación de los ficheros del proyecto. En la primera etapa, la herramienta obtiene del usuario una sencilla especificación de la configuración y nombre de la aplicación así como un fichero de propiedades donde se especifican los detalles de conexión con la base de datos y de algunos parámetros utilizados en la generación, junto a la lista de patrones de nombres de tablas empleadas en el proyecto de la aplicación a generar que define el subconjunto de las tablas a analizar. En la segunda etapa, se procesa la lista de tablas seleccionada obteniendo sus metadatos, primero añadiendo las tablas con sus columnas para luego iterar sobre las claves ajenas de cada una de ellas. En la tercera etapa, una vez poblado el metamodelo se calcula el mapeo objeto-relacional y la interfaz de usuario web. Finalmente, se lanzan los procesos de generación basados en el motor de plantillas de FreeMarker (ver ejemplo en la figura 2) para generar los artefactos requeridos en base a la plataforma definida (ver la figura 5 para más detalles). La primera herramienta utilizada para la generación de código fue Velocity pero rápidamente se apreciaron más prestaciones a FreeMarker. Además, Hibernate tools acababa de decantarse por él. La principal ventaja que ofrece FreeMarker es la sencillez de uso y aprendizaje, ya que basta con instanciar los objetos de las clases del metamodelo para poder disponer de su información en la plantilla. Para ello han de ser cargadas las instancias de las variables en el contexto del motor de plantillas mediante un mapa, en el que cada instancia requerida por la plantilla ha de asociarse a una etiqueta en el mapa de contexto. Y es esta misma etiqueta la que debe declararse en el contexto de la plantilla junto con el clasificador de la instancia (su tipo básico o clase) para poder ser reconocido por el editor y el asistente de código integrados en Eclipse, como se muestra en el ejemplo de la figura 2. El metamodelo utilizado por el motor se compone de tres paquetes principales: Relational Database, Object Relational Mapping y Web, Figura 2. Ejemplo de plantilla de generación de scripts DDL de Oracle. ISSN SISTEDES

129 Figura 3. Paquetes del metamodelo del motor Es.Caib.SwFactory. como se puede observar en la figura 3. Cada uno de estos paquetes tiene un cometido, el paquete principal contiene a la metaclase Model encargada de recoger y coordinar las operaciones sobre los diferentes componentes del mismo, incluidos los datos de configuración. En el paquete Rdb (abreviatura de Relational Database) se agrupan las metaclases que soportan la estructura del esquema relacional utilizado por la etapa de Reverse Engineering, como son las tablas con sus columnas y las claves ajenas enriquecidas con metainformación útil para la posterior generación de los artefactos del proyecto. En el paquete Orm (abreviatura de Object Relational Mapping) se definen las metaclases requeridas para capturar la estructura y relaciones en las entidades con sus atributos y sus asociaciones. Por último en la capa web se guarda metainformación relacionada con la correspondencia de los atributos de las entidades con los parámetros web. Si se observa con detalle el metamodelo de la figura 4 se puede reconocer una estructura en la que se define una correspondencia objetorelacional, entre tablas y entidades, entre columnas y atributos y entre claves ajenas y asociaciones. Curiosamente, se puede observar una gran similitud entre el paquete Rdb y el metamodelo definido por las DbTools de Eclipse, por lo que se puede adivinar la facilidad de integración con herramientas estándar de Eclipse. Cabe señalar que el metamodelo cuenta con atributos y asociaciones derivadas que podrían evitarse pero cuya definición simplifican el código necesario en las plantillas, decrementando el número de componentes de FreeMarker necesarios, como en el de Entity donde se reagrupan los atributos (atts) de las entidades en dos subgrupos derivados, los atributos que forman parte de la primary key que identifican a la entidad (attspk) y el resto de atributos que no (attsnopk). Lo mismo ocurre con las columnas de las tablas (cols, colspk y colsnopk). En general es más sencillo realizar cálculos o procesos complejos como funciones de las metaclase del metamodelo, que intentar proporcionar esa misma funcionalidad mediante recursos del lenguaje de marcado de las plantillas. Esta cuestión está mejor resulta por openarchitectureware utilizando XPand [8], ya que permite definir extensiones a las metaclases sin necesidad de adornar el metamodelo con información derivada. Está característica se intentará aprovechar en trabajos futuros. Figura 4. Metamodelo detallado del motor Es.Caib.SwFactory. ISSN SISTEDES

130 Figura 5. Metamodelos y transformaciones del motor de generación de código Es.Caib.SwFactory aplicados a la arquitectura definida por la CTiF - CAIB. Igual que la arquitectura, el motor ha evolucionado y el siguiente paso deberá abordar su adaptación a MDA. Para ello se debería redefinir el metamodelo en un PIM y tres PSM (como muestra la figura 5) para poder descargar de complejidad a la lógica de las plantillas de FreeMarker que actualmente cuestan mantener, y migrarlas a XPand para implementar las transformaciones M2T. Y en segundo lugar, redefinir los cálculos implementados por métodos Java en el metamodelo como transformaciones M2M en ATL e integrarlas en el gestor de sincronización utilizado por Moskitt. Gracias a las características y potencia expresiva de XPand se podrían definir en unas pocas plantillas lo que ahora requieren 8 procesos escritos en Java y otras 22 plantillas de FreeMarker, para generar los artefactos de la misma arquitectura. Ésto es debido a que a partir una sola plantilla XPand se pueden generar diferentes tipos de ficheros, mientras que con FreeMarker se necesita una plantilla por cada fichero generado. Lo que ahora hacen los procesos de generación eligiendo qué partes del modelo necesitan para generar con las plantillas adecuadas cada una de las colecciones de ficheros del proyecto, se podría definir en una sola plantilla y un fichero de extensiones de XPand. De esta forma parece obvia la mejora de la mantenibilidad del motor. Para poder ilustrar la complejidad de la que se está hablando haremos un breve recorrido por los componentes arquitectónicos requeridos por la plataforma. En primer lugar, existen dos partes claramente diferenciadas en la figura 5 que componen los dos proyectos JEE de la aplicación. De una parte, JEE/EJB Business Project, que define el modelo de negocio en POJOs de la aplicación, donde por cada entidad del modelo se implementa una clase DAO en tecnología JDBC y un EJB Stateless Session Façade para ofrecer los servicios de negocio al resto de componentes, bien clientes externos bien los servlets y JSPs del proyecto web. De otra parte, el JEE/ExtJs Web Project, además de definir los controller con servlets y el maquetado con JSPs, se implementan las pantallas de la interfaz de usuario mediante ISSN SISTEDES

131 módulos ExtJs (una librería en Javascript orientada a objetos y patrones con soporte AJAX y multimedia bastante popular y llamativa). Son estos módulos ExtJs los que invocan a los servlets mediante peticiones JSON, razón por la cual requieren de al menos un JSON Reader para deserializar los datos, un Store para interpretar el contenido de los mismos y una lista de ítems para definir el aspecto, propiedades y validaciones de los campos. Síntesis Generación n Ingeniería Inversa Serialización Import / Export JEE Figura 6. Jerarquía de clases IModelPersistor que facilitan la definición y extensión del motor. ISSN SISTEDES

132 El motor ha sido refactorizado para poder dar soporte a operaciones distintas de la generación de aplicaciones en base a partes de esquemas relacionales. El diseño se ha basado en la interfaz IModelPersistor y su jerarquía de clases (figura 6) que ofrece las operaciones de carga load y descarga save de una instancia del modelo (conforma al metamodelo del motor) en base a unos argumentos de configuración. Clase Abstracta AbstractModelPersistor implementa los métodos load y save, es útil para persistores simétricos de serialización y deserialización, tales como en el caso de: JavaModelPersitor EcoreModelPersistor AbstractModelRevEngLoader solo permite la implementación del método load para las operaciones de ingeniería inversa, tales como en el caso de: OracleRevEngModelLoader AccessRevEngModelLoader JavaReflectionRevEngModelLoader AbstractModelGeneratorSaver solo permite la implementación del método save para las operaciones de generación de textos, como: CaibOracleDDLScriptGenerationSaver CaibModelVoPkLayerGenerationSaver CaibDaoJdbcLayerGenerationSaver CaibBusinessEjbLayerGenerationSaver CaibWebServletLayerGenerationSaver CaibWebExtJsLayerGenerationSaver CaibJEEApplicationGenerationSaver Figura 7. Clases abstractas de asistencia para la definición de procesos del motor. Para facilitar la implementación de las clases Persistor se han definido tres clases abstractas de apoyo que cumplen las siguientes características (ver tabla de la figura 7). Las operaciones definidas permitirán evolucionar al motor para ofrecer nuevas prestaciones de generación y de ingeniería inversa sobre Ms Access o paquetes Java. También se ha implementado un mecanismo de serialización mediante clases Java generadas (JavaModelPersistor) que además de permitir trabajar sin conexión a base de datos servirá de prototipo para el desarrollo de los serializadores XMI mediante técnicas de EMF dinámico con el objeto de facilitar la integración MDA. 3. Estudio de integración con Moskitt, hacia una plataforma MDA para Métrica3. Se parte de una situación en la que se cuenta con un estándar anticuado de desarrollo de aplicaciones, más orientado a facilitar las tareas de administración de servidores de aplicaciones que a favorecer la productividad y calidad del proceso software, que imposibilitan o dificultan en extremo, la aplicación de herramientas ágiles de desarrollo. En consecuencia, no hay recursos para utilizar la metodología que se declara de obligado cumplimiento, Métrica 3, y por ende sirve de pretexto para realizar una captura de requisitos exigua e insuficiente, con lo que ello supone. Por tanto, se pretende resolver esta situación mediante la implantación ágil de una metodología que estandarice el trabajo, guiada por una herramienta que le de soporte a los métodos y técnicas para la elaboración de requisitos y la generación temprana de prototipos para validar y aceptar las diferentes iteraciones de las fases de requisitos, análisis y diseño, alineado con las restricciones arquitectónicas de la CAIB. El Modeling Software Kit (Moskitt)[6] es la primera herramienta open source orientada a dar soporte desde un enfoque MDA a la metodología Métrica3 sobre la plataforma de Eclipse, aunque podría configurarse para cualquier otra metodología de desarrollo. Existen otras herramientas o planteamientos pero ni son open source ni están basadas en MDA. Para implantar con éxito en una organización una metodología de desarrollo de software, se requiere la adecuada instrumentación de las prácticas definidas mediante el uso de herramientas específicas con el objeto de disponer de: Un procedimiento de desarrollo adaptable a la organización y a cada uno de los roles. La construcción de modelos según las técnicas y prácticas definidas por la metodología. La automatización del proceso de elaboración de modelos y entregables. La integración con las herramientas corporativas de gestión de proyectos y control de versiones. ISSN SISTEDES

133 El objetivo primero y último de la aplicación de la metodología a través de esta herramienta, es conseguir un incremento de la calidad y una reducción drástica de los costes de la producción y plazos de los entregables del proceso software, incluidos el sistema de información final, sus prototipos y pruebas. Esta herramienta ofrece una plataforma MDE open source con soporte a la elaboración del análisis, diseño e implementación de sistemas software mediante la extensibilidad y personalización de los diferentes editores disponibles. Utiliza metamodelos estándar de UML2, BPMN y DB Tools de Eclipse. También dispone de un DSL propio para la definición de interfaces de usuario, UIM. Cuenta con editores gráficos integrados como un solo recurso, lo que permite la navegación entre diagramas y por tanto trazabilidad de requisitos. Un editor del propio proceso software instanciado para Métrica3. Así como editores textuales de metamodelos ECORE con los que elaborar artefactos textuales como el glosario, el documento de alcance o el estudio de viabilidad. Para poder ofrecer una automatización efectiva del proceso software se proporcionan las siguientes transformaciones, M2M en ATL[2]: BPMN a UC, BPMN a UML, UML a DB, UML Análisis a Diseño. Y la M2T con Xpand[8], DB a DDL. La sincronización de las fases y sus artefactos se implementa mediante el control de las máquinas de estados de los artefactos, recursos y transformaciones relacionadas en cada una de las actividades definidas en el proceso software de Métrica3 calculando las dependencias y propagando las inconsistencias dinámicamente. Esta herramienta ofrece una infraestructura para el desarrollo de herramientas de modelado y generación de código, pero no dispone de un generador de código alineado con las restricciones arquitectónicas de las aplicaciones de la CTiF- CAIB. Sus generadores de código en PHP, denominado gvhidra, y en JEE basado en Spring Roo, denominado gvnix, no pueden ser aprovechados por no cumplir con los requisitos definidos por la arquitectura. Por lo que se provee migrar el motor de generación código Es.Caib.SwFactory a las tecnologías utilizadas por Moskitt: EMF[7], openarchitectureware[8] y ATL[2], para así poder integrarlo en su gestor de sincronización de transformaciones. Además se requiere el desarrollo de una transformación UML2 a DB personalizada para el estándar CTiF-CAIB, dos transformaciones de ingeniería inversa. DB to UML2 y Java to UML2. También sería deseable la integración de Medini QVT en el gestor de sincronización de transformaciones, utilizado por Moskitt. Algunas de estas mejoras están planificadas en la hoja de ruta de Moskitt, pero otras son únicamente de interés para este proyecto. 4. Conclusiones y trabajos futuros. Respecto del motor de generación de código Es.Caib.SwFactory ha servido principalmente para cambiar la percepción y desconfianzas que se albergaban hacia el enfoque DSDM de la producción de software. De hecho se han incrementado los recursos destinados y se ha asegurado una línea de mantenimiento del motor, pero todo ello después de ver, aunque modestos, ciertos resultados. Por tanto se puede concluir que a pesar de que el motor se ha construido con escasísimos recursos, tecnologías y prestaciones ya que tan sólo está guiado por un proceso de ingeniería inversa, ha conseguido demostrar la capacidad y beneficios que aporta el desarrollo de software dirigido por modelos en el entorno de una administración pública. Del metamodelo cabe señalar que lejos de ser la mejor y sin haber sido premeditado, la solución construida: las entidades, atributos y asociaciones representadas en el metamodelo se han ido añadiendo paulatinamente al mismo, a medida que eran requeridas durante el proceso de diseño de la herramienta. Primero por el proceso de ingeniería inversa y después por el motor de generación. Curiosamente el resultado final es muy semejante, abstrayéndose de los detalles, al metamodelo de las DB Tools en lo que respecta al metamodelo relacional. Lo cual viene a demostrar que el espacio de soluciones de un problema parece estar caracterizado por un alto grado de similitud. Actualmente el proceso de ingeniería inversa de base de datos ha sido implementado únicamente para bases de datos Oracle mediante la extracción de las características estructurales del esquema relacional acotado por el conjunto de tablas a procesar a partir de las vistas sobre su diccionario de datos. Se identificó la conveniencia de crear una siguiente versión basada en las ISSN SISTEDES

134 características getmetadata de JDBC con el objeto de universalizar el motor a cualquier base de datos pero se dejo para más adelante por dos razones: en primer lugar, la extracción de los metadatos del diccionario se consiguió antes que de la api de JDBC; y en segundo lugar se pretende conectar el metamodelo relacional con las Db Tools de Eclipse que son capaces de manipular cualquier base de datos vía JDBC. En una segunda fase se abordarán las bases de datos de Ms Access para obtener las modificaciones que se hayan podido añadir y en una tercera fase los archivos de paquetes Java para recuperar las jerarquías de clases de los sistemas en producción. En futuros trabajos dentro del proceso de migración a MDA se terminará la implementación de EcoreModelPersistor y de las transformaciones de síntesis, sincronización e ingeniería inversa del metamodelo del motor con los metamodelos de las Db Tools y UML2 que aún no se han implementado o no han sido suficientemente probadas. Además queda pendiente migrar las transformaciones implementadas por métodos Java a ATL y la generación basada en FreeMarker a las plantillas de Xpand. También convendrá construir un editor de parámetros de configuración con la ayuda de XText para convertir el motor en un plug-in de Eclipse. A pesar de disponer Moskitt de buenos argumentos a su favor, se ha intentado realizar una búsqueda sistemática de trabajos similares en el mercado limitada a la información disponible en la web y a la iniciativa de respuesta de los consultados. Existen otras herramientas o planteamientos pero ni son open source ni están basados en MDA. La búsqueda de trabajos similares se inició consultando al propio Consejo Superior de Administración Electrónica [96], emisor de la metodología que aseguró no conocer herramienta alguna que le diera soporte y reconocieron no haber dedicado recursos a Métrica 3 desde hace más de 3 años, si bien por parte del CSI la última herramienta ofrecida fue para la versión 2. Después de insistir se indicó que se consultara el mercado y a las grandes consultoras de software como Accentur, Indra o Everis que a día de hoy no han dado su respuesta. Buscando productos en el mercado se encontraron diferentes consultores y cursos donde se proponían varios conjuntos de herramientas que intentaban dar soporte a la metodología, básicamente con una integración en mayor o menor medida de editores UML con gestores de proyectos, como Enterprise Architect [95][98], Rational Rose [100] o similares herramientas [97] que permiten dar soporte a una metodología, pero no consiguen transformar los requisitos capturados en una fase en los de la siguiente, manteniendo la trazabilidad desde el principio hasta el producto final. A su vez, integrados con gestores documentales ad-hoc como Documentum [97] o Alfresco [98]. Pero que en cualquier caso y tal como reconocen diversas fuentes [97][98], más bien se ha utilizado una infraestructura para generar la documentación exigida por Métrica3 que un verdadera utilización de la metodología. De hecho, Roberto Canales, gerente de Autentia [98], propone en su libro [24] la aplicación de metodologías ágiles y luego un mapeo del proceso con la generación de los artefactos exigidos. De esta búsqueda se puede concluir que Moskitt es la única plataforma abierta basada en MDA sobre Eclipse que soporte el proceso software definido para la metodología Métrica3. Después de contactar con la dirección informática de la Conselleria de Transportes e Infraestructuras de la GVA ([91][92]) y parte del grupo de investigación PROS [93][27] que ha asesorado a ProDevelop en la construcción de Moskitt, se han podido esbozar los criterios para adaptar Moskitt a las particularidades de la CAIB. La dirección informática de la CIT-GVA ([91][92]) y la propia empresa ProDevelop a través de sus listas de soporte y técnicos [94] han ofrecido asesoramiento a este proyecto. Con el objeto de clarificar el conjunto de tecnologías a emplear, se ha contado con el asesoramiento de investigadores de Pros [93] y de técnicos de ProDevelop [94]. En el ámbito de la infraestructura para el seguimiento de proyectos y métricas software se ha contado con las observaciones y críticas a las herramientas integradas por Javier González Álvarez, arquitecto JEE de Ahead Technology [95]. Finalmente, se pretende aprovechar estos resultados para hacer converger los trabajos futuros con la hoja de ruta de Moskitt, con el objetivo final de implantar Métrica3 y su plataforma MDA, en la producción de software de la Conselleria de Treball i Formació del Govern Autònom de les Illes Balears. ISSN SISTEDES

135 Referencias [1] Apache Velocity project, - velocity.apache.org [2] ATLAS Group (INRIA & LINA) Univ. Nantes, ATL (ATLAS Transformation Language) [3] Begoña Bonet Pérez de León, Tecnimap MOSKitt: herramienta libre que da soporte a la aplicación de metodologías de desarrollo, [4] Christian Bauer, Gavin King., Java Persistence with Hibernate. Manning, [5] Consejo Superior Administración Electrónica, Métrica3. Metodología de Planificación, Desarrollo y mantenimiento de sistemas de información. - [6] Conselleria d'infraestructures i Transport - GVA, Modeling Software Kit (MOSKitt) ( [7] Eclipse Modeling Framework Project (EMF) [8] Eclipse Open Architecture Ware [9] Elena Litani, Discover the Eclipse Modeling Framework (EMF) and Its Dynamic Capabilities., Ed Merks, [10] Frank Truyen, The fast guide of Model Driven Architecture [11] Ikv++ technologies ag, medini QVT - projects.ikv.de/qvt [12] Javier Cano, Multiple diagrams in single resource support for MOSKitt, [13] Javier Muñoz, Begoña Bonet., SemanaInformatica-2010-Herramienta de Modelado UML y Soporte a la Ingeniería del Software, [14] Javier Muñoz, Integrating Transformations into the MOSKitt Transformation Manager, [15] José Abellán, MOSKit Day - ProDevelop - Metodologías y Herramientas, [16] Mario G. Piattini Velthuis, Javier Garzás Parra., Fábricas de Software: Experiencias, tecnologías y organización. Ra-Ma, [17] Markus Völter, MD* Best Practices, [18] Miguel Llácer San Fernando, Tech. Report - Traceability and Synchronization, [19] Object Management Goup, Inc., Model Driven Architecture - [20] OpenXava Project - [21] Pau Giner Blasco, Automating the development of Physical Mobile Workflows. A Model Driven Engineering approach (hdl.handle.net/10251/8272), [22] Red Hat, Inc., Hibernate Tools - [23] Red Hat, Inc., Seam Framework JBoss Seam - seamframework.org [24] Roberto Canales Mora. Autentia., Informática Profesional: Las reglas no escritas para triunfar en la empresa. Starbook, [25] Sencha Inc., ExtJs - [26] Spring, Spring ROO - [27] Vicente Pelechano, MOSKitt. Una plataforma libre para el desarrollo de métodos y herramientas DSDM, [28] Visigoth Software Society, FreeMarker - freemarker.sourceforge.net Fuentes consultadas Se desea presentar agradecimientos por la atención, críticas, observaciones y asesoramiento ofrecidos. [91] Martín García Hernández - Jefe del Servicio de Organización e Informática - Conselleria d'infraestructures i Transport - GVA. [92] Begoña Bonet Pérez de León - Servicio de Organización e Informática - Conselleria d'infraestructures i Transport - GVA. [93] Vicente Pelechano Titular de Universidad Sistemas Informáticos y Computación - Universidad Politécnica de Valencia. [94] Miguel Llácer San Fernando, Master e Ingeniero Software ProDevelop. [95] Javier González Álvarez, Arquitecto JEE Ahead Tecnology. [96] Mª Dolores Hernández, Métrica 3 - Consejo Superior Administración Electrónica. [97] Victoriano Gómez Garrido, Ilustra Consultoria. [98] Roberto Canales Mora Autentia [99] Pau Giner - Investigador, Ph.D. - Sistemas Informáticos y Computación - Universidad Politécnica de Valencia. [100] Patricio Letelier Torres, Ph.D. - Sistemas Informáticos y Computación - Universidad Politécnica de Valencia. ISSN SISTEDES

136 Definición y ejecución de métricas en el contexto de ADM Javier Luis Cánovas Izquierdo, Belén Cruz Zapata, Jesús García Molina Universidad de Murcia {jlcanovas, b.cruzzapata, jmolina}@um.es Resumen La Modernización de Software Dirigida por Modelos ha surgido como una nueva disciplina centrada en la utilización de técnicas de Desarrollo de Software Dirigido por Modelos en los procesos de evolución de software. La iniciativa Architecture Driven Modernization (ADM) de OMG define un conjunto de metamodelos estándar para representar como modelos la información involucrada en las tareas de una modernización o reingeniería de software. Para la representación de métricas, ADM incluye el metamodelo Software Metrics Metamodel (SMM). Sin embargo, la definición de SMM solamente proporciona la sintaxis abstracta, pero no una notación. En este artículo se dota a SMM de una sintaxis concreta textual y se define un motor de ejecución que permite ejecutar métricas y calcular mediciones sobre modelos Ecore. 1. Introducción Las técnicas del Desarrollo de Software Dirigido por Modelos (DSDM) no sólo son útiles para la creación de nuevos sistemas software, sino que también pueden ser aplicadas en procesos de modernización o reingeniería de software. Para ello, es necesaria una etapa inicial que convierta los artefactos software del sistema existente en modelos que los representen. Sin duda, la iniciativa más ambiciosa sobre modernización dirigida por modelos es Architecture Driven Modernization (ADM) [1] lanzada por OMG en El propósito de ADM es favorecer la interoperabilidad entre herramientas de modernización de software mediante la definición de un conjunto de especificaciones estándares de metamodelos que representan la información gestionada, normalmente, en las tareas de modernización, como análisis estático o refactoring. Del total de siete especificaciones previstas, en la actualidad sólo se han publicado tres de ellas: Abstract Syntax Tree Metamodel (ASTM), que permite representar el código fuente como árboles de sintaxis abstracta; Knowledge Discovery Metamodel (KDM), destinado a representar el código en diferentes vistas arquitecturales y que es la base para la interoperabilidad; y Software Metrics Metamodel (SMM), que permite representar tanto métricas como mediciones. El resto de metamodelos están relacionados con el análisis de programas, las pruebas, el refactoring, la visualización y las transformaciones. En el desarrollo de software, como sucede en otras disciplinas de ingeniería, las mediciones de ciertas propiedades o características de un sistema o proceso de software son esenciales para conocer tanto la calidad del producto o del trabajo realizado, como para controlar el proceso y establecer planes de mejora. En un proceso de modernización de software las métricas ayudan en actividades como el análisis del código existente, la evaluación del resultado de la evolución o el control del proceso aplicado [2]. SMM fue publicado en mayo de 2009 y sólo incluye el metamodelo de la sintaxis abstracta. En este trabajo se dota a este metamodelo de una sintaxis concreta textual para definir completamente un lenguaje específico de dominio (DSL), denominado Medea, destinado a la definición y ejecución de métricas. Las métricas son expresadas textualmente y se pueden aplicar sobre cualquier artefacto software representado mediante un modelo conforme a un metamodelo MOF o Ecore, como por ejemplo KDM. Se ha construido un motor que ejecuta especificaciones Medea y obtiene modelos con las mediciones que resultan de aplicar las métricas. La aportación de este trabajo abre la posibilidad de experimentar con el metamodelo SMM mediante la definición de métricas ejecutables para KDM u otros ISSN SISTEDES

137 metamodelos. Por lo que sabemos se trataría del primer motor de ejecución de SMM disponible. La organización de este documento es la siguiente. La Sección 2 describe el metamodelo SMM y comenta sus principales elementos. La Sección 3 presenta la sintaxis textual propuesta, mientras que la Sección 4 describe el motor de ejecución implementado. La Sección 5 muestra unos ejemplos de definición de medidas con Medea, los cuales han sido utilizados en un caso de estudio real. La Sección 6 presenta el trabajo relacionado y la Sección 6 finaliza el artículo con las conclusiones y trabajo futuro. 2. El metamodelo SMM Como hemos indicado, SMM es un metamodelo que proporciona un formato estándar para representar tanto las métricas de software como las mediciones con dichas métricas. Aunque se ha definido en el contexto de ADM, SMM permite representar métricas de cualquier tipo referidas a todo tipo de artefacto software representado mediante elementos de un modelo conforme a un metamodelo (MOF según la especificación). Figura 1. Elementos principales de SMM La Figura 1 muestra los principales elementos de SMM. Los dos conceptos principales del metamodelo son medida (measure) y medición (measurement). Mientras que una medida define un proceso de evaluación (esto es, una métrica), una medición es el resultado de la aplicación de una medida. Cada medición tiene asociada (a través de la referencia measurand) el conjunto de elementos que han sido medidos (en nuestro caso elementos de modelos Ecore). Además, las mediciones también tienen asociada información (observation) acerca del momento y la herramienta que ha sido utilizada para calcularla. SMM incluye una jerarquía de medidas que representan distintas formas de evaluar características de un elemento. La Figura 2a muestra una parte de esta jerarquía y en ella se observa que las medidas se clasifican en dos categorías: las que asignan un valor numérico de acuerdo a una unidad de medida (DimensionalMeasure) y las que retornan un símbolo que indica que la característica considerada tiene un valor en cierto rango (Ranking). Existen varios tipos de DimensionalMeasure, como las medidas simples o de aplicación directa (DirectMeasure), por ejemplo la medida que comprueba si un elemento satisface una propiedad retornando 0 o 1 (Counting); y las medidas compuestas que representan operaciones que involucran a varias medidas. Hay dos tipos de medidas compuestas: las que realizan el cálculo entre dos elementos (BinaryMeasure) y las que son aplicadas a un conjunto de elementos (CollectiveMeasure). RatioMeasure es una subclase de BinaryMeasure que representa una relación entre dos medidas bases (por ejemplo, el número medio de líneas por módulo) y AdditiveMeasure y MaximalMeasure son tipos de CollectiveMeasure que representan una suma de mediciones y la obtención de la medición máxima, respectivamente. Ambos tipos de medida compuesta especifican las medidas en las que se basan. Así, BinaryMeasure especifica sus operandos con las referencias basemeasure1 y basemeasure2, mientras que CollectiveMeasure utiliza la referencia basemeasure. Para aquellas medidas que puedan ser descritas por su nombre, ya que son bien conocidas, como la complejidad ciclomática de McCabe, SMM ofrece la metaclase NamedMeasure. Como se observa en la Figura 2a, todas las medidas en SMM tienen asociado el ámbito de aplicación (scope) y la característica que se está midiendo (characteristic). El ámbito permite especificar el dominio de la medida, esto es, sobre qué tipos de elementos va a aplicarse. La característica es una cadena de texto que describe la propiedad que se mide, por ejemplo, líneas de código o longitud de un fichero. De forma paralela a la jerarquía de medidas, SMM incluye una jerarquía de mediciones. Esta jerarquía permite reproducir la estructura de una medida pero con el objetivo de representar el resultado de la medición. Por ejemplo, para las medidas de tipo CollectiveMeasure existe la medición CollectiveMeasurement. La Figura 2b muestra una parte de la jerarquía de mediciones. ISSN SISTEDES

138 Figura 2. Jerarquías principales de SMM. (a) Jerarquía de medidas. (b) Jerarquía de mediciones SMM también incluye conceptos básicos para organizar las medidas y mediciones en librerías y categorías. La Figura 3 (basada en uno de los ejemplos usados en la especificación de SMM) muestra un modelo SMM que representa el resultado de contar el número de módulos existentes en un modelo KDM. Esta figura muestra cómo los modelos SMM incluyen elementos relacionados con las medidas, las mediciones y los elementos evaluados. La Figura 3a muestra los elementos necesarios para la definición de la medida, estos son, una medida compuesta de tipo AdditiveMeasure que suma las mediciones de una medida directa de tipo Counting que devuelve 0 o 1 según el elemento sea o no de tipo code::module. La medida compuesta define como ámbito los elementos del paquete Code de KDM de tipo CodeModel y especifica el atributo accumulator a sum para indicar que la operación a realizar con los resultados de las medidas que la componen es la adición. Por otro lado, la medida Counting es una medida simple que define como ámbito los elementos del paquete Code de KDM de tipo AbstractCodeElement y especifica en el atributo operation la operación OCL a realizar para comprobar que un elemento es del tipo indicado en el Scope. Conviene destacar que SMM utiliza OCL para expresar las operaciones asociadas a cualquier medida directa. La Figura 3b muestra los elementos de tipo medición asociados a las medidas anteriores, indicando los valores numéricos calculados para cada una de ellas. En este ejemplo, la medición se ha realizado para un modelo KDM que sólo contiene un módulo. Obsérvese que las mediciones calculadas hacen referencia a los elementos del modelo que son objeto del cálculo de la medida, en el ejemplo las mediciones referencian a los elementos CodeModel y Module del modelo KDM (Figura 3c). 3. Definición de la sintaxis concreta Dado que la especificación de SMM solamente proporciona el metamodelo de la sintaxis abstracta, decidimos dotarla de una notación o sintaxis concreta para facilitar la tarea de crear ISSN SISTEDES

139 Figura 3. Ejemplo de modelo de sintaxis abstracta en SMM extraída del documento de especificación. Las medidas definidas cuentan el número de módulos en los modelos de código de un modelo KDM modelos que expresen medidas SMM. De este modo, los usuarios dispondrían de un DSL completo, en vez de tener que definir las medidas como instancias de los elementos de la sintaxis abstracta con algún editor. La ejecución de las especificaciones de medidas expresadas con dicho lenguaje permitiría realizar las mediciones sobre artefactos software representados como modelos Ecore y obtener los correspondientes modelos SMM. A continuación presentaremos la sintaxis del DSL Medea y comentaremos el proceso de definición de dicha sintaxis, y en la siguiente sección describiremos su motor de ejecución. Consideramos que una sintaxis concreta textual sería más apropiada que una gráfica, por la naturaleza de las métricas, el tipo de usuario, y sobre todo porque según nuestra experiencia es conveniente comenzar antes por un DSL textual que por uno gráfico, como también se indica en [3]. Es importante destacar que la definición de la sintaxis concreta textual solamente afecta a la parte de SMM encargada de la definición de medidas, que es la parte que debe ser definida manualmente. La parte de SMM dedicada a la definición de mediciones se obtiene como resultado de la ejecución de las medidas, por lo que no es necesaria su especificación por parte del usuario. Existen diversas herramientas para crear DSLs textuales basados en un metamodelo, las cuales se pueden clasificar en dos categorías: i) las que parten de la gramática para generar el metamodelo y el parser que extrae modelos de la especificación textual, como por ejemplo xtext [4]; y ii) las que generan el parser a partir del metamodelo, por ejemplo TCS [5] y EMFText [6]. Nosotros hemos usado el lenguaje Gra2MoL, creado especialmente para extraer modelos a partir de código fuente de un lenguaje de programación [7, 8], ya que realmente posibilita la extracción a partir de cualquier especificación textual conforme a cualquier gramática libre de contexto. Por tanto se puede ver como un tercer enfoque para crear DSLs: dado un metamodelo destino y una gramática origen se establece la correspondencia entre ellos mediante una transformación cuya ejecución produce el modelo a partir de una especificación conforme a la gramática, como expresa el esquema de la Figura 4 para el caso de Medea y SMM. Figura 4. Proceso de extracción de un modelo SMM que representa medidas Gra2MoL incorpora un lenguaje de consultas especialmente creado para resolver las referencias entre elementos del código fuente, lo que lo hace especialmente apropiado para utilizarlo en este ISSN SISTEDES

140 caso como veremos más adelante. Esta característica es una ventaja frente a aproximaciones como TCS o EMFText, donde es necesario proporcionar un mecanismo para dicha resolución de referencias. Una definición de transformación en Gra2MoL consiste en un conjunto de reglas que especifican las relaciones entre los elementos de la gramática y los elementos del metamodelo. Cada una de estas reglas expresa cómo crear un elemento del metamodelo a partir de un elemento de la gramática como se describe en [7]. Como muestra la Figura 4, el motor de ejecución de Gra2MoL recibiría como entrada cuatro elementos: (1) la gramática G Medea definida para SMM, (2) el metamodelo MM SMM de la sintaxis abstracta de SMM, (3) la definición de la transformación Gra2MoL T Gra2MoL y (4) la especificación Medea conforme a la gramática. Como resultado de la transformación, se obtiene un modelo conforme al metamodelo destino, en este caso SMM. La creación de un DSL con Gra2MoL requiere como primer paso la definición de una gramática en formato ANTLR. Esta gramática libre de contexto permite expresar tanto la sintaxis abstracta como la concreta. Como es bien conocido, metamodelos y gramáticas son dos formalismos para representar la sintaxis abstracta de un lenguaje y existen algoritmos para convertir gramáticas en metamodelos y viceversa [9]. En general, dado un metamodelo, cada clase corresponde a un símbolo no-terminal y para cada uno de ellos hay una producción o regla gramatical cuya parte izquierda es dicho símbolo no-terminal y la derecha está formada por una concatenación deducida de sus atributos y asociaciones, uno por cada atributo y clase destino de cada asociación contenedora y referencia, aunque es posible aplicar diferentes estrategias para simplificar la gramática o mejorar la legibilidad. Por ejemplo, una jerarquía de herencia puede ser representada como una producción con una alternativa por cada subclase, en la que cada alternativa está formada por el símbolo no terminal que representa a la subclase, por otro lado, también pueden incluirse caracteres delimitadores, como por ejemplo las llaves, para definir bloques en el texto y facilitar la legibilidad. A continuación mostramos un fragmento de la gramática definida, el cual nos permitirá describir la estructura de una especificación Medea para el ejemplo de la Figura 3a. El símbolo inicial es smm_model y la primera producción expresa que un modelo de medidas SMM está formado por un conjunto de elementos, así como que una especificación Medea comenzará por la palabra clave smm_model seguida del identificador que denota el nombre del modelo y de la definición de los elementos encerrada entre llaves. Según la segunda producción cada elemento puede ser de los diferentes tipos considerados en SMM (librería, ámbito, característica, etc.). La tercera establece que una librería contiene cero o más medidas y se expresa con la palabra clave libraries seguida del nombre de la librería y las definiciones de las medidas entre llaves. La cuarta establece que hay dos tipos de medidas: ranking y dimensional. La quinta y la sexta definen la estructura de una medida dimensional que puede ser de dos tipos: directa y compuesta. smm_model: 'smm_model' ID { elements* } ; elements : libraries scopes charac... ; libraries : 'library' ID { measures+ } ; measures : ranking dimensional ; dimensional : 'dimensionalmeasure' name=id { 'scope' sc=id ('trait'tr=id)? 'unit' un=id 'type' type } ; type : 'direct' { 'operation' OP } 'collective' { 'accumulator' accumulator 'basemeasure' bm=id }... ; El ejemplo de la Figura 3a podría ser expresado en Medea del siguiente modo: smm_model mymodel { characteristic ModuleCount scope codemodel{ class code::codemodel } ISSN SISTEDES

141 scope AbstractCodeElement{ class code::abstractcodeelement } library mylibrary{ dimensionalmeasure ModuleCount{ scope codemodel trait ModuleCount unit code::module type collective{ accumulator sum basemeasure ModuleCountRecognizer } } dimensionalmeasure ModuleCountRecognizer{ scope AbstractCodeElement trait ModuleCount unit code::module type direct{ operation "oclistypeof(code::module)" } } } } La especificación del modelo de medidas SMM se ha llamado mymodel y contiene un conjunto de declaraciones de medidas, ámbitos y características. Primero se define la característica a medir ModuleCount y los ámbitos codemodel y AbstractCodeElement utilizados por las medidas. Luego se define la librería mylibrary que engloba las definiciones de la medida compleja ModuleCount y de la medida simple ModuleCountRecognizer. La primera de ellas es una medida que suma el resultado de la segunda. En el ejemplo se han subrayado aquellos identificadores que actúan como referencias a elementos definidos en otro ámbito de la especificación. Por ejemplo, cuando se define la medida ModuleCount se referencia a la medida ModuleCountRecognizer. Dichas referencias se pueden comprobar en el modelo de ejemplo de la Figura 3. Tal y como se ha comentado anteriormente, la resolución de estas referencias para la obtención del modelo se ha visto facilitada por el uso del lenguaje de consultas integrado en Gra2MoL [7]. 4. Motor de ejecución El motor de ejecución creado es capaz de interpretar una especificación de medidas expresada en Medea, ejecutarla y finalmente crear un modelo que contenga las mediciones asociadas a las medidas. La Figura 5 muestra el esquema del proceso de interpretación y ejecución de los modelos de medidas SMM. Las entradas del intérprete son: (1) la especificación Medea, denotada como Metrics Medea en la figura (2) el metamodelo al que conforman los modelos sobre los que aplicar las medidas, MM KDM en la figura y (3) el modelo sobre el que aplicar las medidas, M KDM en la figura, que conformará con el metamodelo MM KDM. El primer paso es generar un modelo SMM a partir de la especificación Medea, para lo cual el intérprete interactúa con el motor de ejecución de Gra2MoL (pasos 1, 2 y 3 en la figura) Conforme son interpretadas, en un segundo paso las medidas del modelo generado son ejecutadas sobre el modelo a evaluar M KDM. Este proceso de ejecución utiliza un motor de ejecución de expresiones OCL (OCLManager) y un gestor de modelos (ModelManager). El primero permite ejecutar las expresiones OCL con las que se expresan las operaciones a ejecutar, las cuales son interpretadas por el framework EMF Validation de la plataforma Eclipse; y el segundo se encarga de recorrer el modelo de entrada. Conforme se van ejecutando las medidas, se va construyendo un modelo SMM que contiene los elementos de medición resultantes (M SMM en la figura). La mayor parte de las operaciones relacionadas con la navegación y consulta del modelo sobre el cual calcular las métricas son realizadas por el componente ModelManager (formado por una única clase Java). Sin embargo, dado que se utiliza el API generada por EMF para el metamodelo KDM, se ha creado el componente adicional KDMModelManager, el cual especializa el comportamiento del manejador de modelos para hacer uso de los elementos de dicho API. El componente KDMModelManager se genera automáticamente junto con el API de EMF y del mismo modo se podrían crear especializaciones para otros metamodelos. Como resultado de la ejecución del proceso, se obtiene un modelo conforme al metamodelo SMM que contiene las mediciones resultado de haber aplicado las medidas, junto con las referencias al modelo evaluado. 5. Ejemplo Con el propósito de presentar un proceso para la creación de herramientas de modernización basadas en ADM, en [10] se utiliza un caso de estudio de medición de métricas relacionadas con la complejidad de migrar aplicaciones Oracle ISSN SISTEDES

142 Figura 5. Proceso definido para el motor de ejecución de métricas SMM. Forms a la plataforma Java. En dicho proceso, primero se obtienen modelos KDM del código PL/SQL de una aplicación Oracle Forms (Figura 6a), utilizando ASTM para crear un modelo intermedio que representa el código como un árbol de sintaxis abstracta. A continuación, por medio de una trasformación modelo-a-modelo, se calculan una serie de métricas que permiten medir el nivel de acoplamiento del código PL/SQL con la interfaz de usuario. El objetivo de calcular dichas métricas es disponer de información que ayude a cuantificar el esfuerzo para llevar a cabo la migración del código PL/SQL. De esta forma, cuanto mayor es el nivel de acoplamiento, mayor es el esfuerzo para efectuar la migración. En aquel contexto, las mediciones se representaban por medio de un metamodelo ad-hoc, dado que la especificación SMM todavía no había sido publicada. La transformación modelo-a-modelo tomaba como entrada el modelo KDM generado y obtenía el modelo de mediciones a partir de las operaciones de medición expresadas en las reglas de la transformación, esto es, no se manejaba un modelo de medidas, solamente de mediciones. Ahora hemos modificado el proceso anterior para utilizar el motor SMM y el metamodelo SMM como formato de representación de las medidas y mediciones. La Figura 6b muestra la incorporación del motor de métricas en el proceso sustituyendo a la transformación modelo-modelo mencionada. Según la forma de acceder a la interfaz gráfica, se definieron tres niveles de acoplamiento: reflexivo (por ejemplo, mediante el uso de las funciones NAME_IN o COPY), declarativo (por ejemplo, utilizando sentencias select) e imperativo (por ejemplo, mediante el uso de sentencias de asignación). El acoplamiento reflexivo es el más complicado de migrar debido a que es necesario estudiar el contexto de ejecución del código. Las métricas definidas están basadas en la localización y conteo de los diferentes tipos de sentencias que hacen uso de la interfaz gráfica en un modelo KDM. Los modelos KDM representan a los triggers PL/SQL como elementos CallableUnit, los cuales están formados por un conjunto de ActionElements que describen las sentencias que contienen. Los elementos ActionElement contienen elementos AbstractActionRelationship que describen de forma atómica el comportamiento de la sentencia. Por ejemplo, los elementos Reads y Writes describen la lectura y escritura de variables, respectivamente. El atributo kind de los elementos ActionElement permite identificar el tipo de sentencia, esto es, declarativo o imperativo. Por otra parte, la identificación de sentencias reflexivas se realiza por medio de la localización de elementos de tipo Call, los cuales representan una llamada a un método, en este caso, debe comprobarse si el método llamado es reflexivo. Por tanto, se ha definido una especificación Medea con tres medidas compuestas basadas en tres directas, cuyo objetivo es localizar y contar el número de sentencias asociadas a cada nivel de acoplamiento. La medida compuesta impcount basada en la medida directa impcountrecognizer se encarga contar el número de sentencias imperativas que interactúan con la interfaz gráfica en un trigger. Su definición textual sería la siguiente: ISSN SISTEDES

143 Figura 6. (a) Proceso de extracción de modelos KDM a partir de código PL/SQL. (b) Uso del motor SMM para el cálculo de métricas characteristic imperativecount scope CallableUnit{ class code::callableunit } scope AbstractActionRelationship { class action::abstractactionrelationship } dimensionalmeasure impcount{ scope CallableUnit trait imperativecount unit action::abstractactionrelationship type collective { accumulator sum basemeasure impcountrecognizer } } dimensionalmeasure impcountrecognizer{ scope AbstractActionRelationship trait imperativecount unit action::abstractactionrelationship type direct { operation "if(self.oclistypeof(action::reads)) then let rvar : action::reads = self.oclastype(action::reads) in rvar.from-> exists(e e.kind <> 'select' or e.kind <> 'insert' or e.kind <> 'update') and rvar.to. ocliskindof(code::storableunit) and rvar.to.name.substring(1, 1) = ': else if(self.oclistypeof(action::writes)) then let wvar : action::writes = self.oclastype(action::writes) in wvar.from-> exists(e e.kind <> 'select' or e.kind <> 'insert' or e.kind <> 'update') and wvar.to. ocliskindof(code::storableunit) and wvar.to.name.substring(1, 1) = ':' else false endif endif" } } La estrategia seguida para definir esta medida es parecida a la mostrada en el ejemplo de la Sección 3 para calcular el número de módulos en un modelo. El objetivo genérico es contar el número de elementos de un modelo que cumplen una determinada condición. La forma de describir este comportamiento en SMM es utilizando una medida compleja que sume el resultado de una medida simple, la cual comprueba si el elemento cumple la condición. De esta forma, en la definición anterior, la medida impcount es una medida de tipo CollectiveMeasure que se encarga de sumar el resultado de la medida directa impcountrecognizer. Esta última medida aplica la expresión OCL especificada para comprobar que una sentencia es de tipo imperativa y comienza con el carácter :, que es el formato para representar variables de la interfaz gráfica. Además, se define la característica imperativecount que representa a las medidas, así como los ámbitos principales, los cuales también serán utilizados en las siguientes medidas. El primer ámbito, llamado CallableUnit, establece el elemento CallableUnit, que representa a los triggers en el modelo KDM, como ámbito de la medida impcount. El segundo ámbito, llamado AbstractActionRelationship, establece el elemento AbstractActionRelationship, que representa a las sentencias del trigger, como ámbito de la medida impcountrecognizer. La segunda métrica compuesta, llamada declcount, está basada en la medida directa declcountrecognizer y se encarga de contar el número de sentencias declarativas que interactúan con la interfaz gráfica en un trigger. Su definición es similar a la anterior exceptuando la expresión OCL utilizada, la cual comprueba que el atributo kind sea igual a alguno de los valores que identifican a una sentencia declarativa (select, ISSN SISTEDES

144 insert, update, en el ejemplo). Por cuestiones de espacio, no incluimos la definición de esta medida, la cual puede ser descargada desde la web de la herramienta. Finalmente, la métrica compuesta refcount basada en la medida directa refcountrecognizer se encarga de contar el uso de sentencias reflexivas que interactúan con la interfaz gráfica. characteristic reflectivecount scope AbstractActionRelationship{ class action::calls } dimensionalmeasure refcount{ scope CallableUnit trait reflectivecount unit action::actionelement type collective{ accumulator sum basemeasure refcountrecognizer } } dimensionalmeasure refcountrecognizer{ scope AbstractActionRelationship trait reflectivecount unit action::calls type direct{ operation "self.to. ocliskindof(code::methodunit) and (self.to.name == name_in or self.to.name == copy )" } } La definición de medida directa anterior difiere de las dos anteriores en que el ámbito es AbstractActionRelationship en vez de AbstractCodeElement. En este caso la medida simple se encarga de comprobar si un elemento es de tipo Calls y llama a un método reflexivo. Las métricas fueron aplicadas al código PL/SQL de una aplicación Oracle Forms utilizada como parte del Sistema de Gestión Académica de alumnos de la Universidad de Murcia. Del modelo de mediciones obtenido, se aplicó una transformación modelo a código para obtener un fichero de valores separados por comas para poder representarlos gráficamente. La Figura 7 muestra el nivel de acoplamiento detectado en los triggers de tres de los formularios de la aplicación. La información visualizada ayuda a comprender la dificultad del proceso de migración para cada formulario. Considerando el acoplamiento de la interfaz de usuario, en este caso el formulario EUProjects sería más difícil de migrar que los otros dos, sin embargo, también debería tenerse en cuenta otros aspectos como el tamaño y complejidad del código. Figura 7. Nivel de acoplamiento de tres formularios Oracle Forms en un sistema de gestión de alumnos. Cada barra indica la proporción de triggers que contiene un tipo concreto de acoplamiento. Un trigger puede contener más de un tipo de acoplamiento. 6. Trabajo relacionado En la actualidad, dada la reciente aparición de la especificación SMM, no existe un gran número de trabajos relacionados con este metamodelo. Precisamente, en [11, 12] se presentan aproximaciones generativas dirigidas por modelos para la construcción de software de cálculo de métricas, sin embargo, no utilizan los metamodelos de ADM. En [13] se presenta una aproximación con el mismo propósito que Medea. En ella los modelos de medidas SMM se generan a partir de reglas que capturan patrones de métricas expresados como operaciones OCL. Los diferentes tipos de medidas de un modelo SMM se derivan de las tuplas que resultan al ejecutar el código OCL de la regla y un motor de ejecución SMM produce el modelo de medición. La principal diferencia con nuestra propuesta es que no se proporciona un DSL para expresar medidas sino que el usuario debe usar las reglas existentes o crear nuevas reglas. Aunque se comenta la implementación de un prototipo de motor SMM, la herramienta aún no está disponible y no hemos podido evaluarla. MoDisco [14] forma parte del proyecto GMT de Eclipse y es un framework creado para obtener modelos en el contexto de modernización dirigida por modelos. Ofrece una implementación para el metamodelo KDM y actualmente acaba de publicar una implementación del metamodelo SMM. Sin embargo, no dispone todavía de herramientas para la definición o ejecución de modelos SMM. ISSN SISTEDES

145 Existen diversas propuestas para definir métricas basadas en OCL pero no son genéricas y se definen para modelos UML [15, 16]. 7. Conclusiones En este artículo se ha presentado Medea, que según nuestro conocimiento es el primer lenguaje de definición de medidas SMM ejecutables. Un motor de ejecución permite ejecutar las medidas y obtener modelos de medición SMM. Se ha utilizado Gra2MoL para dotar de una sintaxis concreta textual al metamodelo de sintaxis abstracta de SMM. Hemos mostrado la aplicación de Medea a un caso de estudio real que anteriormente se había abordado mediante un metamodelo de métricas adhoc. Con el uso de SMM nos ahorramos la definición de los metamodelos de métricas y mediciones y ganamos en interoperabilidad ya que todos los metamodelos empleados son estándar: KDM y SMM. Con el motor de ejecución de SMM implementado será posible que la comunidad experta en métricas pueda probar y validar el metamodelo SMM y valorar su utilidad real. El motor de ejecución puede descargarse desde la dirección Como trabajo futuro, creemos interesante estudiar cómo mejorar la sintaxis concreta para elevar su potencial y dotarlo de constructores más complejos que puedan permitirnos definir métricas más eficientemente, como por ejemplo, sentencias para definir directamente medidas de conteo de elementos sin tener que utilizar una medida compuesta que sume el resultado de otra simple. Otra tarea a abordar es la integración de la herramienta en la plataforma AGE [16], ofreciendo un editor específico para el lenguaje definido. Finalmente, como objetivo a largo plazo, sería la identificación de métricas software y su organización en librerías, permitiendo disponer de un repositorio de métricas expresado en Medea. Agradecimientos Este artículo ha sido parcialmente financiado por las ayudas Seneca 08797/PI/08 y 129/2009 de la Consejería de Universidades e Investigación (Murcia). Javier Luis Cánovas Izquierdo dispone de una beca FPI de la Fundación Séneca Referencias [1] ADM. [2] Tom Mens, Serge Demeyer, Future Trends in Software Evolution Metrics. In: Proc. Int l Workshop on Principles of Software Evolution (IWPSE 2001), pp ACM Press. [3] Markus Völter: MD* Best Practices. Journal of Object Technology, (6): (2009) [4] Xtext. [5] F. Jouault, J. Bèzivin, and I. Kurtev, TCS: a dsl for the specification of textual concrete syntaxes in model engineering", in GPCE, pp (2006). [6] Emftext. [7] J. Cánovas Izquierdo, J. G. Molina. A domain specific language for extracting models in software modernization en ECMDA 2009, LNCS 5562, pp , 2009 [8] J. Cánovas Izquierdo, O. Sánchez, J. Sánchez Cuadrado, J. G. Molina. DSLs para la extracción de modelos en modernización, V Taller DSDM 2008, Gijón (España). [9] Jack Greenfield, Software Factories (capítulo 8), John Wiley & Sons, [10] J. Cánovas Izquierdo, J. García Molina. An Architecture-Driven Modernization Tool for Calculating Metrics, IEEE Software, Software Evolution SI, Julio/Agosto [11] M. Montperrus, J. M. Jézéquel, B. Baudry, J. Champeau, B. Hoeltzener. Model-driven generative development of measurement software. Software and Systems Modeling (SoSyM), To be published. [12] SMF Tool. [13] M. Engelhardt, et al. Generation of Formal Model Metrics for MOF based Domain Specific Languages, OCL Workshop, MODELS, [14] MoDisco Eclipse Tool website. [15] M. Clavel, M. Egea, V. Torres da Silva. Model Metrication in MOVA: A Metamodelbased Approach using OCL. (2007) [16] A.L. Baroni, et al.., Using OCL to Formalize Object Oriented Design Metrics Definitions. In: Proc. of QAOOSE Málaga, Spain (2002) [17] J. S. Cuadrado, J. G. Molina. Building Domain-Specific Languages for Model-Driven Development, IEEE Software 24(5): (2007) ISSN SISTEDES

146 Modelos de weaving para trazabilidad de requisitos Web en A- OOH José Alfonso Aguilar Grupo de investigación Lucentia Dpto. de Lenguajes y Sistemas Informáticos Universidad de Alicante ja.aguilar@dlsi.ua.es Irene Garrigós Grupo de investigación Lucentia Dpto. de Lenguajes y Sistemas Informáticos Universidad de Alicante igarrigos@dlsi.ua.es Jose-Norberto Mazón Grupo de investigación Lucentia Dpto. de Lenguajes y Sistemas Informáticos Universidad de Alicante jnmazon@dlsi.ua.es Resumen En este artículo, se presenta una propuesta con base en MDWE (Model Driven Web Engineering) para soportar trazabilidad (elemento-a-elemento) aplicando modelos weaving. El método de diseño Web A-OOH (Adaptive Object Oriented Hypermedia) es aplicado para representar el modelo de requisitos, equivalente al modelo independiente de computación (CIM) y los modelos conceptuales de dominio y navegación, ambos representantes del modelo independiente de la plataforma (PIM) en contexto con Model- Driven Architecture (MDA). 1. Introducción El diseño de una aplicación Web debe considerar los problemas derivados de aspectos de navegación, presentación y datos. En este contexto, MDWE [9] se ha convertido en una alternativa valiosa para solventar dichas carencias de manera sistemática, estructurada, integrada y completa mediante la utilización de modelos como artefactos principales en el proceso de desarrollo de aplicaciones Web. Por otro lado, debido a la heterogeneidad de los usuarios de una aplicación Web, cualquier método de ingeniería Web debe considerar una fase de análisis de requisitos donde se especifiquen las necesidades de los diferentes actores implicados en la aplicación Web y que sirva para poder determinar cada una de las características que dicha aplicación debe cumplir para satisfacerlas [7]. Aunque en la actualidad existen varias propuestas para la especificación de requisitos Web [8, 17], la mayoría de ellas sólo proponen un conjunto de guías de diseño informales para la derivación manual de modelos conceptuales a partir de los requisitos Web [1]. Ante esta situación, es necesario conocer el posible impacto derivado del cambio de un requisito, es decir, si un requisito cambia, por ejemplo, debido al desarrollo gradual de las necesidades del usuario, es necesario saber las partes de los modelos conceptuales de la aplicación Web que serán afectadas. De proceder similar, si un modelo conceptual es modificado, obligado por el cambio constante en las tecnologías de implementación de las aplicaciones Web, es indispensable conocer qué requisitos serán afectados. En este sentido, en MDWE es imprescindible habilitar la trazabilidad entre los requisitos y los modelos conceptuales derivados del proceso de desarrollo de la aplicación Web. La trazabilidad de requisitos se define como la capacidad de describir y seguir la vida de un requisito, en ambas direcciones [13]: (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. Cabe destacar que la trazabilidad se considera como una medida de la calidad del sistema y la madurez del proceso de desarrollo, además es una prescripción de muchas normas o 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 [19]. La carencia de soporte para trazabilidad, es un problema común en la mayoría de las aproximaciones metodológicas en MDWE que debe de ser solucionado [1]. En un proceso MDWE, esto permitirá a obtener costos y ISSN SISTEDES

147 planificaciones más exactas en lugar de depender del programador para determinar que áreas serán afectadas por los cambios [2]. En este trabajo, se presenta una propuesta para verificar la consistencia entre el modelo de requisitos y los modelos conceptuales en el proceso de desarrollo de una aplicación Web. Para lograr esto son aplicadas un conjunto de técnicas entre las que destacan los modelos weaving [5]. Un modelo weaving es un tipo especial de modelo utilizado para establecer y manejar las relaciones (links) entre los elementos de los modelos, es decir, está formado por una (o varias) relación(es) entre los elementos del modelo de entrada y los elementos equivalentes en el modelo de salida. La propuesta presentada en este articulo se ha realizado en el marco del método de ingeniería Web A-OOH [10] y está alineada con MDA (Model Driven Architecture) pero es aplicable a otras aproximaciones de ingeniería Web. Finalmente, proveer de soporte para trazabilidad en MDWE permitirá dotar al equipo de desarrollo de información de gran utilidad para realizar: (i) un análisis de impacto (analizar como cambiar un modelo podría afectar a otro modelo relacionado a él), (ii) sincronización entre modelos (reflejar la modificación de un modelo en otro relacionado a él), (iii) depuración basada en modelos (mapear la ejecución paso a paso de una implementación de nuevo a su modelo de alto nivel) así como determinar el objetivo de una transformación [4]. Este artículo está organizado de la siguiente manera: la sección 2 resume la aplicación de modelos weaving en ingeniería Web y delimita el área de interés de este trabajo. En la sección 3 se describe nuestra propuesta para la trazabilidad de requisitos Web aplicando un running example. Finalmente, la sección 4 presenta las conclusiones y trabajo futuro. 2. Trabajos relacionados En el aspecto de trazabilidad, actualmente existen dos estrategias para gestionar y almacenar la información necesaria 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 [6]. La primera de estas dos opciones tiene como desventaja que la información es almacenada en el mismo modelo, de esta forma el modelo será contaminado con información poco relevante para su contexto y por lo tanto el uso y mantenimiento será difícil. Por otro lado, la segunda estrategia consiste en almacenar la información en un modelo aparte, de esta forma se pueden corregir las desventajas mencionadas, esto debido a que, almacenando la información en un modelo conforme a un metamodelo con una semántica claramente definida se permite un análisis automático por herramientas de Ingeniería de Software de una forma más fácil. Es importante destacar que los modelos de weaving corresponden con la segunda estrategia mencionada en este apartado. Continuando con esta idea, existen propuestas que proveen una base técnica para el soporte de trazabilidad en un contexto dirigido por modelos. En [14], el autor manifiesta como modificar transformaciones especificadas en el lenguaje ATL para dotar de soporte para trazabilidad en el entorno de las transformaciones entre modelos. El trabajo que toma como base nuestra propuesta es [3], donde se presenta una extensión del metamodelo base para weaving [5] con la que es posible soportar trazabilidad en transformaciones entre modelos aplicando modelos de weaving. En [6], por su parte, el autor presenta una propuesta para trazabilidad aplicando diversos lenguajes de modelado para establecer y mantener links de trazabilidad semánticamente ricos entre los elementos de los modelos participantes en las transformaciones, incluso coincide con nuestra propuesta con el uso del framework i* para especificación de requisitos. Actualmente existen algunos trabajos relacionados al campo de la MDWE que implementan modelos weaving para solucionar distintos problemas, pero ninguno de ellos se enfoca en resolver los problemas asociados a la trazabilidad entre modelos conceptuales en un proceso MDA a partir de la fase de especificación de requisitos. Sin embargo, los modelos de weaving han sido aplicados en distintos escenarios relacionados a la ingeniería Web, por ejemplo, en las aplicaciones Web orientadas a servicios (SOWA), en donde se muestra como un modelo weaving puede ser utilizado como contenedor para información extra (decisiones de diseño) en el momento de la ejecución de la transformación de un modelo [20]. Otro escenario de aplicación de los modelos de weaving es en la integración de ISSN SISTEDES

148 características de usabilidad en aplicaciones Web desde la fase de elicitación de requisitos [18]. Nuestro trabajo contiene una serie de características que lo diferencian del trabajo previo presentado en esta sección, esto debido a que es aplicado un método de desarrollo Web (A- OOH) en contexto con el desarrollo Web dirigido por modelos, lo anterior para paliar la carencia de trazabilidad en MDWE desde los niveles CIM - PIM y PIM - CIM de MDA, para un mejor entendimiento, esta propuesta está orientada a la evaluación del impacto del cambio de un requisito en los modelos conceptuales de la aplicación Web y viceversa. 3. Uso de modelos de weaving para trazabilidad en ingeniería Web Nuestra propuesta se resume en la figura 2 expresada en UML (Unified Modeling Language) donde se utilizan tres metamodelos diferentes para la obtención de los modelos conceptuales a partir del modelo de requisitos, estos son (i) 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 de los modelos de dominio y de navegación en varios PIMs y (iii) la extensión del metamodelo weaving propuesto en [3], para su uso en la trazabilidad entre nuestros CIM y PIM. Figura 1. Modelo de trazabilidad al derivar modelos conceptuales a partir del modelo de requisitos en A-OOH. Como se puede observar en la figura 1, a partir de un modelo de entrada (modelo de requisitos) conforme al metamodelo i* para requisitos Web se obtienen dos modelos mediante transformaciones en lenguaje QVT (Query View Transform). El primero se denomina modelo de salida (puede ser un modelo de dominio o de navegación) y el segundo corresponde al modelo weaving para trazabilidad entre los modelos de entrada y de salida. Para ilustrar nuestro trabajo consideramos un running example en el cual el escenario es el siguiente: una compañía que se dedica a la venta de libros quiere administrar la venta de libros por medio de una tienda en línea y de está forma, atraer la mayor cantidad de clientes como sea posible. Los pasos a seguir consistirán en: (i) especificar un modelo de requisitos (CIM) y (ii) obtener los modelos de dominio y navegación (PIMs) a la par del modelo de trazabilidad (modelo weaving) Especificación de requisitos en un CIM El desarrollo de aplicaciones Web involucra diferentes tipos de stakeholders con diferentes necesidades y metas. Interesante resulta el hecho de que estos stakeholders dependen uno del otro para poder lograr sus metas y realizar sus tareas. En nuestra propuesta, los requisitos Web se definen un modelo de requisitos a nivel CIM utilizando i* [12]. El modelo de requisitos sirve para especificar las necesidades del clienteusuario de la aplicación, en él es modelada la ISSN SISTEDES

149 funcionalidad completa de la aplicación Web a desarrollar. Para modelar esta funcionalidad es utilizado i*, una técnica orientada a metas para analizar y modelar explícitamente las relaciones entre múltiples stakeholders (actores en la notación i*). El marco de modelado i* [22] 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, ha sido probado útilmente para representar las intensiones de los stakeholders (motivaciones y metas), las dependencias entre los stakeholders para alcanzar sus metas así como los efectos positivos o negativos de las metas en cada stakeholder. De esta forma, es posible seleccionar alternativas de diseño para la aplicación a desarrollar y con ello maximizar el cumplimiento de las metas. El framework i* consiste básicamente en dos modelos: SD (Strategic Dependency), el cual sirve para describir las relaciones de dependencia entre varios actores en un contexto organizacional y el modelo SR (Strategic Relational), utilizado para describir los intereses del actor y como podrían abordarse. El framework i* lo constituyen una serie de elementos en donde encontramos los elementos intencionales, formados por metas (goals), tareas (tasks), recursos (resources) y softgoals. Finalmente, las relaciones intencionales, las cuales son links del tipo means-end encargados de representar formas alternativas para satisfacer metas, los task decomposition links quienes representan los elementos necesarios para que una tarea sea realizada y los contribution links que sirven para modelar como es que un elemento intencional contribuye a la satisfacción de una softgoal. La tabla 1 muestra la notación utilizada para modelar en i*. Para una explicación más amplia consultar [21-22]. Símbolo Nombre Símbolo Nombre SD resources SR Softgoals actor goals tasks Tabla 1. Notación i*. meands-end decomposition link contribution link Como explicamos en [12], nuestra propuesta utiliza la taxonomía de requisitos Web presentada en [7], la cual esta compuesta por requisitos de contenido (Content), servicio (Service), navegación (Navigational), interfaz (Layout), personalización (Personalization). Para poder utilizar esta taxonomía y el framework i* dentro del marco de MDA se ha implementado un perfil UML. Los requisitos no funcionales se modelan directamente utilizando elementos de i*. La figura 2 muestra el modelo de requisitos (extracto) en i* (CIM) para la tienda de libros en línea, cabe destacar que cada elemento que conforma la figura 2 corresponde a un requisito de acorde a la taxonomía mencionada en el párrafo anterior. En la figura 2 se pueden apreciar requisitos de contenido (Content) representados con la notación resources de i* y requisitos de navegación (Navigational), con el símbolo task de i*, ambos con sus respectivas asociaciones (decompositions links). Figura 2. Modelo de requisitos especificado en i* Definición de modelos conceptuales en un PIM En este trabajo, nos centramos en el método de modelado A-OOH [10-11] para derivar los modelos conceptuales de dominio y navegación a partir de los requisitos. A continuación, se describen de manera breve estos modelos [10]: Modelo de dominio. El modelo de dominio se expresa como un diagrama de clases UML. Este modelo refleja la parte estática del sistema Web, encapsulando su estructura y funcionalidad requerida. Modelo de navegación. El modelo de navegación se compone de nodos de navegación y relaciones entre ellos indicando los caminos de navegación que el usuario. ISSN SISTEDES

150 puede seguir en la Web (enlaces de navegación). Hay tres tipos de nodos: (i) clases navegacionales, (ii) destinos y (iii) colecciones (C-collection) que actúan como menú agrupando enlaces de navegación (transversal links y service links) Definición de modelos de weaving para trazabilidad de requisitos Web En la definición del modelo de weaving para trazabilidad se ha utilizado el metamodelo base para weaving [5] formado por los elementos: WElement, WModel, WLink, WElementRef, WLinkEnd y WModelRef. Básicamente, este metamodelo permite crear un modelo de weaving (WModel) conformado por un conjunto de links (WLink) los cuales almacenan el nombre de la regla de transformación utilizada en las transformaciones entre los elementos. Mediante el elemento WLinkEnd, se permite asociar de 1 a varios elementos de un modelo con 1 o varios elementos de otro modelo haciendo uso de refrencias (WElementRef). Además, se ha utilizado una extensión [3] para proveer a dicho metamodelo con elementos útiles para representar la trazabilidad, estos son: (i) TraceModel, representa al modelo de trazabilidad, (ii) TraceModelRef, representa referencias a otros modelos, (iii) ElementRef, identificador utilizado para señalar cada elemento que integra a los modelos ligados, (iv) TraceLink, es un link de rastreo utilizado para representar las correspondencias entre las referencias de los elementos de los modelos enlazados, almacena el nombre de la regla de transformación que ha sido ejecutada, finalmente (v) TraceLinkEnd, 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). El metamodelo y la extensión se presentan en la figura 3, en la parte superior se encuentra el metamodelo base para modelos weaving, en la parte inferior se ilustra la extensión del metamodelo para trazabilidad. Figura 3. Metamodelo para weaving. ISSN SISTEDES

151 3.4. Obtención de los modelos de dominio y trazabilidad Se pretende obtener el modelo de dominio a partir del modelo de requisitos (figura 2) de la tienda de libros en línea mediante la aplicación de un conjunto de reglas de transformación en QVT. Con estas reglas, obtendremos también un modelo weaving para segurar trazabilidad bidireccional entre ambos modelos. Las principales reglas QVT utilizadas son: Content2DomainClass. Dado un conjunto de elementos que representan un requisito del tipo Content en el modelo de requisitos se crea una clase tipo Class en el modelo de dominio (modelo de dominio). Service2Operation. Detecta un conjunto de elementos en el modelo de requisitos que corresponden con un requisito del arquetipo Service asociado a un requisito del tipo Content. Una vez detectado este patrón de elementos, se crea en el modelo de dominio una clase Operation dentro de la clase correspondiente. Navigation2Relationship. Crea asociaciones entre clases en el modelo de dominio. Sí existen dos o más requisitos del arquetipo Content como origen y éstos requisitos se usan para cumplir el mismo requisito de navegación (Navigational), entonces se crea asociación entre las clases del modelo de dominio. Al aplicar las reglas, se considera que para cada requisito de contenido etiquetado como Content en el modelo de requisitos (CIM), la regla de transformación Content2DomainClass crea una nueva clase en el modelo de dominio (PIM). En este caso han sido detectados tres requisitos de contenido en el CIM: Categoría, Autor y Libro, por lo tanto se crean tres clases en el PIM. El siguiente paso es la ejecución de la regla Service2Operation. Para nuestro ejemplo, la regla no aplica debido a que el CIM no cuenta con requisitos del tipo Service. Finalmente, se ejecuta la regla Navigational2Relationship para crear las asociaciones entre las clases del modelo de dominio. Finalmente, una vez obtenido el modelo de dominio, el diseñador es él encargado de refinarlo, es decir, especificar la cardinalidad y definir (en caso de existir) las relaciones jerárquicas. El modelo de dominio resultante se muestra en la figura 4. 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 crea un modelo de trazabilidad. Por cada vez que una regla QVT es ejecutada, empareja uno o varios elementos del modelo de requisitos y crea una serie de referencias a los elementos de los modelos de requisitos y de dominio, es decir un nuevo TraceLink en el modelo de weaving para trazabilidad (figura 6). Esta regla se repite hasta haber recorrido cada uno de los elementos del modelo de entrada. Figura 4. Modelo de dominio (extracto). El modelo de weaving para trazabilidad se obtiene en paralelo a la obtención del modelo de dominio. La figura 6 muestra el modelo de weaving para trazabilidad obtenido tras la generación del modelo de dominio en notación UML. La primera parte de la figura 6 (izquierda), representa las referencias al modelo de entrada, es decir, al modelo de requisitos, el 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 (dominio), el cual se encuentra al lado derecho de la figura 6. En este contexto, la referencia sourceelements se refiere a los elementos del modelo de entrada, por ejemplo, el elemento Libro etiquetado como Content (parte izquierda de la figura 6). La referencia targetelements se refiere a los elementos del modelo de salida generados, en ISSN SISTEDES

152 este caso la Clase Libro del modelo de dominio (lado derecho de la figura 6). El atributo rulename contiene el nombre de la regla (Content2DomainClass). 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, 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. Por motivos de espacio son omitidos los TraceLinks que originaron las asociaciones entre las clases del modelo de dominio. Figura 5. Modelo de navegación (extracto). Figura 6. Modelo de weaving para trazabilidad requisitos-dominio (extracto) Obtención de los modelos de navegación y trazabilidad A partir del CIM se obtiene también el modelo de navegación (PIM) de la aplicación Web de la tienda de libros en línea. Las reglas QVT para la obtención del modelo de navegación son: Navigation2NavClass. Cuando se detecta en el CIM un requisito estereotipado como Navigational unido a un requisito del tipo Content, entonces se crea una clase estereotipada como NavigationalClass en el modelo de navegación (PIM). Además cada una de estas nuevas clases es el destino de una nueva asociación TransversalLink desde una C-Collection previamente creada por la función createmenu que se encuentra en la cláusula when. Personalization2NavClass. Detecta los requisitos de personalización (estereotipo Personalization) que tienen un requisito de contenido (Content) asociado en el CIM. Se derivan en el modelo de navegación los mismos elementos que en la regla anterior. Navigation2TransversalLink. Permite crear asociaciones entre clases navegacionales en el modelo de navegación. Existen dos requisitos origen del arquetipo Content en el CIM, sí los dos requisitos se usan para cumplir con el mismo requisito de navegación (Navigational) (comprobado en la cláusula when con la operación SameNavigationOrigin), entonces se crea una asociación estereotipada como TransversalLink entre las clases del modelo de navegación (PIM) que las representan. Service2Service&SLink. Detecta un conjunto de elementos en el CIM que corresponden con un requisito etiquetado como Service asociada ISSN SISTEDES

153 a un requisito Content, detectado este patrón de elementos se crea en el PIM una clase Operation en la clase correspondiente. Además, se crea una asociación estereotipada como ServiceLink para cada operación añadida. El modelo de navegación, representado en la figura 5 con notación UML, es generado de igual forma que el modelo de dominio aplicando las transformaciones QVT anteriormente descritas. La primera regla que se ejecuta es Navigation2NavClass que crea las clases navegacionales, en este caso en concreto son creadas tres clases navegacionales (Autor, Libro y Categoría) como puede verse la figura 5. Previamente fue creada una C-Collection con su respectiva asociación estereotipada como TransversalLink (entre las clases del modelo de navegación) como resultado de la ejecución de la funcion createmenu, definida en la cláusula when de la regla Navigation2NavClass. En este ejemplo en particular, las reglas de transformación restantes (Personalization2NavClass, Navigation2TransversalLink, Service2ServiceLink) no aplican, es decir no existe en este ejemplo los requisitos que las satisfacen. De igual forma que en la obtención del modelo de trazabilidad correspondiente al modelo de dominio, las transformaciones anteriores son ejecutadas secuencialmente para especificar un modelo de trazabilidad entre el modelo de requisitos y el de navegación. Por lo tanto, se necesita también del concurso de la transformación CreateModelTrace para crear los elementos del modelo de trazabilidad. El modelo de trazabilidad (extracto, figura 7) se encuentra dividido en tres partes. La parte izquierda representa las referencias a los elementos del modelo de requisitos (TraceModelRef1), en este ejemplo, formado por los elementos Categoría (tipo Content) y Libros por categoría (tipo Navigational). El lado derecho-superior de la figura representa un TraceLink formado por el nombre de la regla QVT ejecutada (Navigation2NavClass). Por último, el lado inferior-derecho de la figura (TraceModelRef2) representa la correspondencia de las referencias de los elementos del modelo de navegación (ElementRef: Clase Categoría) con los elementos correspondientes en el modelo de requisitos (ElementRef: Categoría y Libros por categoría). En la figura 7 puede verse la trazabilidad requisitos-navegación. En este particular caso, la regla QVT busca el patrón requisito de contenido (Content) unido con un requisito de navegación (Navigational) para crear una clase de navegación en el modelo de navegación. Figura 7. Modelo de trazabilidad requisitos-navegación (extracto). ISSN SISTEDES