Models in Software Engineering: Workshops and Symposia at MODELS 2007 Nashville, TN, USA, September 30 - October 5, 2007, Reports and Revised Selected

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial Board David Hutchison Lancaster University, UK Takeo Kanade Carnegie Mellon University, Pittsburgh, PA, USA Josef Kittler University of Surrey, Guildford, UK Jon M. Kleinberg Cornell University, Ithaca, NY, USA Alfred Kobsa University of California, Irvine, CA, USA Friedemann Mattern ETH Zurich, Switzerland John C. Mitchell Stanford University, CA, USA Moni Naor Weizmann Institute of Science, Rehovot, Israel Oscar Nierstrasz University of Bern, Switzerland C. Pandu Rangan Indian Institute of Technology, Madras, India Bernhard Steffen University of Dortmund, Germany Madhu Sudan Massachusetts Institute of Technology, MA, USA Demetri Terzopoulos University of California, Los Angeles, CA, USA Doug Tygar University of California, Berkeley, CA, USA Gerhard Weikum Max-Planck Institute of Computer Science, Saarbruecken, Germany

5002

Holger Giese (Ed.)

Models in Software Engineering Workshops and Symposia at MoDELS 2007 Nashville, TN, USA, September 30 - October 5, 2007 Reports and Revised Selected Papers

13

Volume Editor Holger Giese Hasso-Plattner-Institut für Softwaresystemtechnik Prof.-Dr.-Helmert-Str. 2-3 14482 Potsdam, Germany E-mail: [email protected]

Library of Congress Control Number: 2008930116 CR Subject Classification (1998): D.2, D.3, I.6, K.6 LNCS Sublibrary: SL 2 – Programming and Software Engineering ISSN ISBN-10 ISBN-13

0302-9743 3-540-69069-7 Springer Berlin Heidelberg New York 978-3-540-69069-6 Springer Berlin Heidelberg New York

This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. Springer is a part of Springer Science+Business Media springer.com © Springer-Verlag Berlin Heidelberg 2008 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper SPIN: 12282005 06/3180 543210

Preface

Following the tradition of previous instances of the MoDELS conference series, 11 workshops and two symposia were hosted in 2007. These satellite events complemented the main conference by providing room for important subject areas and enabling a high degree of interactivity. The selection of the workshops was organized like in former instances of the MoDELS conference series by a Workshop Selection Committee. The following well-known experts agreed to serve on this committee: – – – – –

Gabor Karsai, Vanderbilt University, USA Thomas K¨ uhne, Darmstadt University of Technology, Germany Jochen K¨ uster, IBM Research Zurich, Switzerland Henry Muccini, University of L’Aquila, Italy Sebastian Uchitel, Imperial College London, UK

The workshops provided collaborative forums for particular topics. They enabled a group of participants to exchange recent and/or preliminary results, to conduct intensive discussions, or to coordinate efforts between representatives of a technical community. They served as forums for lively discussion of innovative ideas, recent progress, or practical experience on model-driven engineering for specific aspects, specific problems, or domain-specific needs. As in previous editions, there were a Doctoral Symposium and an Educators’ Symposium. The Doctoral Symposium provided specific support for PhD students to discuss their work and receive useful guidance for the completion of their dissertation research. The Educators’ Symposium addressed how to educate students as well as practitioners to move from traditional thinking to an engineering approach based on models. These satellite-event proceedings published after the conference include summaries as well as revised versions of up to two best papers from the workshops, the Doctoral Symposium, and the Educators’ Symposium. I am grateful to the members of the Selection Committee who did a great job in reviewing the workshop proposals and selecting the best workshops. In particular Thomas K¨ uhne (member of the Selection Committee and my predecessor as Workshop Chair) was of great help to me and eased my work by generously sharing his experiences from the former year with me.

February 2008

Holger Giese

Organization

Sponsoring Institutions

ACM Special Interest Group on Software Engineering (www.sigsoft.org)

IEEE Computer Society (www.computer.org)

Table of Contents

Aspect-Oriented Modeling 11th International Workshop on Aspect-Oriented Modeling . . . . . . . . . . . . J¨ org Kienzle, Jeff Gray, Dominik Stein, Walter Cazzola, Omar Aldawud, and Tzilla Elrad

1

A Generic Approach for Automatic Model Composition . . . . . . . . . . . . . . . Franck Fleurey, Benoit Baudry, Robert France, and Sudipto Ghosh

7

MATA: A Tool for Aspect-Oriented Modeling Based on Graph Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jon Whittle and Praveen Jayaraman

16

Language Engineering 4th International Workshop on Language Engineering (ATEM 2007) . . . Jean-Marie Favre, Dragan Gaˇsevi´c, Ralf L¨ ammel, and Andreas Winter

28

Designing Syntax Embeddings and Assimilations for Language Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Martin Bravenboer and Eelco Visser

34

A Comparison of Standard Compliant Ways to Define Domain Specific Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ingo Weisem¨ oller and Andy Sch¨ urr

47

Model Driven Development of Advanced User Interfaces Third International Workshop on Model Driven Development of Advanced User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Andreas Pleuß, Jan Van den Bergh, Stefan Sauer, Daniel G¨ orlich, and Heinrich Hußmann Domain-Specific Methods and Tools for the Design of Advanced Interactive Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Guillaume Gauffre, Emmanuel Dubois, and Remi Bastide Transforming Discourse Models to Structural User Interface Models . . . . Sevan Kavaldjian, Cristian Bogdan, J¨ urgen Falb, and Hermann Kaindl

59

65 77

VIII

Table of Contents

Model Size Metrics Second International Workshop on Model Size Metrics . . . . . . . . . . . . . . . . Michel Chaudron and Christian F.J. Lange

89

On the Relation between Class-Count and Modeling Effort . . . . . . . . . . . . Ariadi Nugroho and Christian F.J. Lange

93

Measuring the Level of Abstraction and Detail of Models in the Context of MDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jens von Pilgrim

105

Model-Based Design of Trustworthy Health Information Systems First International Workshop on the Model-Based Design of Trustworthy Health Information Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ Akos L´edeczi, Ruth Breu, Bradley Malin, and Janos Sztipanovits Rigorously Defining and Analyzing Medical Processes: An Experience Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stefan Christov, Bin Chen, George S. Avrunin, Lori A. Clarke, Leon J. Osterweil, David Brown, Lucinda Cassells, and Wilson Mertens Modeling and Enforcing Advanced Access Control Policies in Healthcare Systems with Sectet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Michael Hafner, Mukhtiar Memon, and Muhammad Alam

115

118

132

Model-Driven Engineering, Verification and Validation 4th International Workshop on Model Driven Engineering, Verification, and Validation: Integrating Verification and Validation in MDE . . . . . . . . Benoit Baudry, Alain Faivre, Sudipto Ghosh, and Alexander Pretschner

145

Deriving Input Partitions from UML Models for Automatic Test Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stephan Weißleder and Bernd-Holger Schlingloff

151

Putting Performance Engineering into Model-Driven Engineering: Model-Driven Performance Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mathias Fritzsche and Jendrik Johannes

164

Table of Contents

IX

Ocl4All: Modelling Systems with OCL 7th International Workshop on Ocl4All: Modelling Systems with OCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . David Akehurst, Martin Gogolla, and Steffen Zschaler

176

Model-Level Integration of the OCL Standard Library Using a Pivot Model with Generics Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Matthias Br¨ auer and Birgit Demuth

182

Evaluation of OCL for Large-Scale Modelling: A Different View of the Mondex Purse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Emine G. Aydal, Richard F. Paige, and Jim Woodcock

194

[email protected] Second International Workshop on [email protected] . . . . . . . . . . . . . . . . . Nelly Bencomo, Robert France, and Gordon Blair

206

AMOEBA-RT: Run-Time Verification of Adaptive Software . . . . . . . . . . Heather J. Goldsby, Betty H.C. Cheng, and Ji Zhang

212

Model-Based Run-Time Error Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jozef Hooman and Teun Hendriks

225

Multi-Paradigm Modeling: Concepts and Tools Second International Workshop on Multi-Paradigm Modeling: Concepts and Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juan de Lara, Tiham´er Levendovszky, Pieter J. Mosterman, and Hans Vangheluwe

237

ModHel’X: A Component-Oriented Approach to Multi-Formalism Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C´ecile Hardebolle and Fr´ed´eric Boulanger

247

Domain-Specific Model Editors with Model Completion . . . . . . . . . . . . . . . Sagar Sen, Benoit Baudry, and Hans Vangheluwe

259

Quality in Modeling Third Intenational Workshop on Quality in Modeling . . . . . . . . . . . . . . . . . Ludwik Kuzniarz, Lars Pareto, Jean Louis Sourrouille, and Miroslaw Staron

271

Developing a Quality Framework for Model-Driven Engineering . . . . . . . . Parastoo Mohagheghi and Vegard Dehlen

275

X

Table of Contents

Doctoral Symposium Doctoral Symposium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Claudia Pons

287

Models in Conflict – Towards a Semantically Enhanced Version Control System for Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kerstin Altmanninger

293

Aspect-Oriented User Requirements Notation: Aspects in Goal and Scenario Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gunter Mussbacher

305

Educators’ Symposium Educators’ Symposium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Miroslaw Staron

317

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

321

11th International Workshop on Aspect-Oriented Modeling Jörg Kienzle1, Jeff Gray2, Dominik Stein3, Walter Cazzola4, Omar Aldawud5, and Tzilla Elrad6 1

McGill University, Canada University of Alabama at Birmingham, USA 3 University of Duisburg-Essen, Germany 4 University of Milano, Italy 5 Lucent Technologies, USA 6 Illinois Institute of Technology, USA [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] 2

Abstract. This report summarizes the results and discussions from the 11th Workshop on Aspect-Oriented Modeling (AOM). The workshop was held in conjunction with the International Conference on Model-Driven Engineering, Languages, and Systems (MODELS), which was located in Nashville, Tennessee, on September 30, 2007. Over 20 researchers and practitioners attended the workshop with various backgrounds in aspect-oriented software development and software model engineering. The workshop provided a forum for discussing the state of the art in modeling crosscutting concerns at different stages of the software development process: requirements elicitation and analysis, software architecture, detailed design, and mapping to aspect-oriented programming constructs. This workshop summary provides an overview of the accepted submissions and summarizes the results of the different discussion groups. Papers, presentation slides, and photos from the workshop are available at http://www.aspect-modeling.org/.

1 Introduction This brief summary reports on the outcomes of the 11th International AspectOriented Modeling Workshop. The workshop took place at the Marriott Hotel in Nashville, Tennessee, on Sunday, September 30, 2007. The workshop was part of the 10th International Conference on Model Driven Engineering Languages and Systems – (MODELS 2007). A total of 10 position papers were submitted and reviewed by the program committee, 7 of which were accepted to the workshop. Over 20 participants attended the presentation session and took part in afternoon working group discussions. Papers, presentation slides, and further information can be found at the workshop website, which is at http://www.aspect-modeling.org/. The website also has links to the previous editions of the workshop. The rest of this report is structured as follows: Section 2 provides a general overview of the motivation, goals, and challenges of aspect-oriented modeling. H. Giese (Ed.): MoDELS 2007 Workshops, LNCS 5002, pp. 1–6, 2008. © Springer-Verlag Berlin Heidelberg 2008

2

J. Kienzle et al.

Section 3 gives a summary of the papers that have been accepted to this workshop. Section 4 outlines the results of the discussion groups. Finally, section 5 concludes the report.

2 Overview to Aspect-Oriented Modeling Aspect-orientation is a rapidly advancing technology. New and powerful aspectoriented programming techniques are presented at many international venues every year. However, aspect-oriented software development techniques are often deeplyrooted in the “intimate essence” of a program, i.e., the syntax and structure of its code. As a consequence, developers may easily be overwhelmed with implementation details, while loosing track of the intentions and goals of the interacting (formerly crosscutting) concerns, as well as of where and how they interact. Aspect-oriented modeling has the potential to provide the necessary tool for abstracting from the essence of the problem and for taking root in the semantic nature of the interacting concerns and their interaction. Over the last five years, much research work has been presented at the various editions of this workshop, which all aim at helping developers not to get lost in the “code space” and its associated accidental complexities. Consolidating that work, three important fields of research have emerged that are frequently and recurrently tackled by different researchers. One major field of research is concerned with finding appropriate modeling abstractions for aspect-oriented programming language constructs, such as pointcuts, advice, introductions, stateful aspects, aspect-oriented hooks and connectors. The options are usually to define a new modeling language or modeling notation, or to extend an existing one. The goal is to provide aspect-oriented software developers with appropriate means to facilitate the analysis of their problems as well as the design of their solutions. The challenge is to find the right level of abstraction so that the invented modeling means are suitable for a variety of problems as well as for a variety of aspect-oriented implementation techniques (e.g., languages and frameworks). Another major field of research is concerned with bringing forth the benefits of aspect-orientation to the modeling level and, thus, to model-driven development. Much work in this field of research is concerned with model transformation, model composition, and/or model weaving. One key question is to determine the similarities, differences and relationships between these terms and techniques. A frequent issue that emerges is to what extent conventional transformation techniques can be used to implement aspect-oriented model weavers. The ultimate goal is to free aspect-oriented software developers from the need of using aspect-oriented programming languages. Yet another field for research that attained much research efforts recently is the specification of validation and verification frameworks for aspect-oriented software. Key concerns in this field include the detection of conflicts between different aspects, the confirmation whether or not aspects affect the correct points in the base application, and the disclosure of the presence of crosscutting in software. Some of the key questions are focused on the formalisms that should be used, how such formalisms can be adopted to aspect-orientation, and how its application can be facilitated for the ordinary aspect-oriented software developer.

11th International Workshop on Aspect-Oriented Modeling

3

These three core research concerns represent a non-exclusive list. Multiple researchers have addressed many other issues. Several of the papers presented at the current workshop edition fall into the second category. The workshop discussions considered all of these issues and other concerns, as noted in the next two sections.

3 Summary of Accepted Position Papers Jon Whittle from Lancaster University, UK, presented MATA [1], an approach to aspect-oriented modeling that can be applied to any modeling language with a welldefined meta-model. MATA provides expressive composition mechanisms. The weaving in MATA is based on graph transformations, and hence any composition technique is possible. MATA also provides support for detecting some aspect interactions automatically. The MATA tool is implemented as a bridge between IBM Rational Software Modeler (RSM) and Attributed Graph Grammar System (AGG). Frank Fleurey from IRISA/INRIA in France presented a generic approach for automatic model composition [2]. In the approach, the two models that are to be composed are first pre-processed, then merged, and finally the resulting model is post-processed. The composition is signature-based: if a signature matches, the elements are merged and recursively processed; in case there is no match, both elements are copied to the target model. He presented a reusable composition framework, in which a meta-model is extended to obtain a “composable meta-model”: mergeable model elements have to define getSignature operations that allow the composition algorithm to match them. Special signatures have to be defined that make sense for each model element. Hua Xiao from Queens University, Canada, presented an approach to weave business requirements into model transformations [3]. He argued that there is a gap between the business domain, the concerns of business stakeholders, and the technical domain, as considered by the developers. With their work, the authors want to help to integrate business requirements into generic design models and implementation models. BPEL (Business Process Engineering Language) is too limited to represent all requirements specified by the business analysts. The authors use AOM techniques to enhance a primary BPEL model with other concerns such as time, cost, resource usage, performance, and frequency. A weaver combines the BPEL and aspect models to yield a composed model, which is wrapped and can then be fed to a simulation engine. After the simulation, the developer can validate the successful achievement of business requirements (e.g., compare revenue and cost per request). Stefan Van Baelen from the Katholieke Universiteit Leuven, Belgium, presented an approach that composes application models and security models [4]. He highlighted the fact that security concerns are very spread out through an application and cannot easily be isolated in an application layer. He compared the advantages and disadvantages of the classical AOP approach, the MDD approach (a securityindependent application model is transformed to a security-aware application model, then mapped to an execution platform), and the AOM approach: generate a woven model, and then generate OOP code. They also support generation of CeasarJ code. Their approach allows the definition of company-wide access policies, which can be woven into many applications. At run-time, the application contacts an authorization

4

J. Kienzle et al.

engine to check access rights. The sample application he showed defined concepts with a UML class diagram. Access policy subjects and objects are also represented in UML class diagrams, and then “merged” or assigned to each other. Jaime Pavlich-Mariscal from the University of Connecticut, USA, presented his position paper on how to enhance UML to model custom security aspects [5]. He first presented different access control models (RBAC, MAC and DAC), and highlighted that UML does not explicitly support any of them. Also, it is not easily possible to use capabilities of different access control models in combination. As a result, traceability of access control policies is also difficult to achieve. Their approach adds four security-specific models, which are then composed with the application model to create a security-aware model. Security features that can be modeled include: positive/negative permissions, MAC or delegation rules. Model composition is achieved by merging meta-models. Jörg Kienzle from McGill University, Canada presented an aspect-oriented modeling approach for specifying reusable aspect models [6]. His aspect models define structure using class diagrams, and behavior using sequence diagrams. The weaver, based on existing class diagram and sequence diagram weavers, is capable of weaving aspects with other aspects or base models. In his talk, Jörg demonstrated the high degree of reusability of the aspect models by modeling the design of 8 interdependent aspects of the AspectOptima case study, an aspect framework that implements support for transactions. Based on this experience, he identified several modeling language features that seem essential to support reusable aspect modeling. Steffen Zschaler from the University of Dresden, Germany, presented a talk entitled “Aspect-Orientation for your Language of Choice” [7]. He presented Reuseware, a tool based on invasive software composition that makes it possible to define fragments of models, where each fragment can define interfaces in forms of slots. Later, elements identified as anchors within one model can be bound to the slots in another model using queries based on pattern-matching expressions.

4 Overview of Discussion Topics This section offers a summary of the most interesting and significant issues that were addressed during the discussion sessions. These issues also emerged during the questions and comments in the presentation sessions. What are the characteristics of a good aspect modeling language? Participants in the aspect composition group considered this question and stated that a good aspect modeling language would have a rigorous semantic definition with a mixture of external and internal behavior descriptions. A question arose in the discussion regarding whether the aspect modeling language needed to be similar to the base modeling language. If the modeled concern is close to the domain, there may be benefits in having the aspect and base modeling languages similar. Should an aspect modeling language be standardized? There was an overwhelming consensus that it is too early to have a standardized aspect modeling language. At this stage of AOM maturity, standardization may be too restrictive because no aspect language fits all concerns. An aspect modeling language that is too

11th International Workshop on Aspect-Oriented Modeling

5

general may lose its usefulness. Dedicated formalisms can have specific meaning, purpose, and analysis capabilities. What is the current status of model composition languages to address crosscutting concerns? Current model composition languages are very low-level and force a model engineer to bind too early in the life cycle. Precise bindings may be uncertain at early stages of development (e.g., there may not be clearly defined connections between early aspects and aspects in design). There is a need to model composition relationships over several abstraction levels. Some of the questions that remain to be answered include: Is a simple linear progression through the development phases too naïve? How soon should the aspect binding be realized? How to manage relationships in aspect models (e.g., new relationships appearing and old relationships disappearing)? What modeling language features enable the creation of reusable aspect models? A reusable aspect model should not refer to any base model element directly, or prescribe a binding to a particular base model element, or depend on the existence of a specific base element. A modeling formalism supporting reuse must provide means to define reusable aspect models in a base model independent way. Mappings between the reusable aspect model and the base should be established in separate bindings. In order to create reusable aspect libraries, the modeling formalism must be able to provide a means to describe aspect specifications, as well as the contexts in which the reusable aspect can be applied. Ideally, a means for detecting conflicts among reusable aspects when they are applied to the same base model should be provided as well.

5 Concluding Remarks The workshop continued the tradition of having a very diverse representation of participants. The authors came from nine different countries (Argentina, Belgium, Canada, France, Germany, Luxembourg, Netherlands, United Kingdom, and the United States.); likewise, the organizing and programming committees represented eleven countries (Belgium, Canada, France, Germany, Ireland, Italy, Netherlands, Portugal, Switzerland, United Kingdom, and the United States.). In addition to the geographical diversity, the AOM workshop also attracted participants with wide research interests in aspects across the entire spectrum of the development lifecycle. As a result, this provided opportunities for a variety of opinions that were wellinformed from the accumulated experience of the participants. The workshop provided a forum for presenting new ideas and discussing the state of research and practice in modeling various kinds of crosscutting concerns at different levels of abstraction. The workshop identified and discussed the impacts of aspect-oriented technologies on model engineering to provide software developers with general modeling means to express aspects and their crosscutting relationships onto other software artifacts. This workshop report is a summary of the activities for those who could not attend the workshop and provides an opportunity to gain insights to these issues, and to initiate a future research agenda in the field of aspect-oriented modeling.

6

J. Kienzle et al.

Acknowledgements We would like to thank the program committee members who have helped to assure the quality of this workshop: Mehmet Aksit (University of Twente), Aswin van den Berg (Motorola Labs), Thomas Cottenier (Illinois Institute of Technology), Sudipto Ghosh (Colorado State University), Stefan Hanenberg (University of DuisburgEssen), Andrew Jackson (Trinity University), Jean-Marc Jézéquel (IRISA), Kim Mens (University Catholic of Louvain), Alfonso Pierantonio (University of Aquila), Awais Rashid (Lancaster University), Raghu Reddy (Rochester Institute of Technology), Ella Roubtsova (Open University, Netherlands), Bedir Tekinerdogan (University of Twenty), Markus Völter (Independent Consultant), and Jon Whittle (Lancaster University). We also thank all submitters and workshop participants who helped to make this workshop a success.

References [1] Whittle, J., Jayaraman, P.: MATA: A Tool for Aspect-Oriented Modeling based on Graph Transformation [2] Fleurey, F., Baudry, B., France, R., Ghosh, S.: A Generic Approach For Automatic Model Composition [3] Zou, Y., Xiao, H., Chan, B.: Weaving Business Requirements into Model Transformations [4] Hovsepyan, A., Van Baelen, S., Yskout, K., Berbes, Y., Joosen, W.: Composing Application Models and Security Models: On the Value of Aspect- Oriented Technologies [5] Pavlich-Mariscal, J., Michel, L., Demurjian, S.: Enhancing UML to Model Custom Security Aspects [6] Klein, J., Kienzle, J.: Reusable Aspect Models [7] Heidenreich, F., Johannes, J., Zschaler, S.: Aspect Orientation for Your Language of Choice

A Generic Approach for Automatic Model Composition Franck Fleurey1, Benoit Baudry1, Robert France2, and Sudipto Ghosh2 1

IRISA/INRIA – Université de Rennes 1, Campus Universitaire de Beaulieu, 35042 Rennes, France {bbaudry,ffleurey}@irisa.fr 2 Colorado State University, Fort Collins, CO, USA {france,ghosh}@cs.colostate.edu

Abstract. Analyzing and modelling a software system with separate views is a good practice to deal with complexity and maintainability. When adopting such a modular approach for modelling, it is necessary to have the ability to automatically compose models to build a global view of the system. In this paper we propose a generic framework for composition that is independent from a modelling language. We define a process for adapting this framework to particular modelling language (defined with a metamodel) and illustrate how the generic composition has been specialized for class diagrams.

1 Introduction When using aspect-oriented modelling to build the model for a large system, the modellers identify different views. They model each view and reason about these separate models. They can also perform validation tasks on each model, for example using model checking techniques. Once all these models have been correctly built in isolation, it is necessary to compose these different models. The composed model can be used to • • •

check the global consistency of the system's model, better understand the interactions across the composed views analyze interactions to identify conflicts and undesirable emergent behaviours

When the models are small enough and developed by a single or a couple of designers, they can be composed manually. However, in most cases, the models are too large to be composed manually and it is necessary to develop an automatic composition operator to ensure that all the elements in the model are handled. Moreover, an automatic composition operator allows the designer to try different solutions for composition that correspond to different decision (e.g., try different orders for composition, or different solutions for one view…). There exist several solutions to automatically compose models in different languages (class diagrams [1, 2], statecharts [3], sequence diagrams [4]…). If there is no composition operator for one modelling language, it is necessary to build a completely new operator for this language. In the future, there might be more and more domain-specific modelling language developed for model-driven development. H. Giese (Ed.): MoDELS 2007 Workshops, LNCS 5002, pp. 7–15, 2008. © Springer-Verlag Berlin Heidelberg 2008

8

F. Fleurey et al.

In that case, we do not want to generate a new algorithm and a new environment for each language. It becomes necessary to reuse algorithmic and design knowledge from composition operators in other languages. In this paper we propose a generic framework for automatic model composition. There are two main steps for composition: matching and merging. The matching step is specific to a modelling language. It specifies which element in the language can match and how they can match. The merge step can be defined independently from any language. The framework we propose implements a generic merge operator. It defines, how two model elements that match are merged, as well as a mechanism for conflict detection. The framework also implements a language to specify composition directives as they are defined by Reddy et al. [2] and specifies a clear interface to specify a match operator. This framework can then be specialized for a particular metamodel in order to add composition capabilities to a particular language. In section 2 we discuss the generic framework for model composition. In section 3 we explain how this framework can be specialized to add composition capabilities to a particular metamodel and in section 4 we illustrate this specialization on an example.

2 A Generic Framework for Model Composition This section describes the generic composition algorithm that is implemented in the generic composition framework. The composition mechanism implemented in this framework is structured in two major steps: 1 2

Matching: Identifies model elements that describe the same concepts in the different models that have to be composed. Merging: Matched model elements are merged to create new model elements that represent an integrated view of the concepts.

The merging operator builds a new model from two models. It merges elements that match according to the matching operator and creates new elements in the target composed model. This operator is independent of a specific domain. It consists in going through the set of elements that match in both input models and if they can be merged the operator creates a new model element in the output model. If the elements can not be merged, a conflict is detected that has to be solved. This happens when elements that match based on a subset of their properties (e.g., when merging two class diagrams, classes with same names match) can not be merged because of other properties that do not match (e.g., if there is one concrete class and one abstract class). The whole process of conflict detection and model elements creation is generic. The semantics of matching is domain specific. The knowledge for detecting model elements that describe the same concept is based on information dependent on the meaning of the model. Thus, the matching operation has to be specialized for each modelling language. However, in order to interact correctly with the merging operator, the matching operator has to have a clear interface. The generic framework described in this section implements the behaviour of the merging operator and offers a precise interface for the definition of the matching operator. The framework can then be specialized by providing specific matching operators through this interface.

A Generic Approach for Automatic Model Composition

9

2.1 Generic Framework for Composition Figure 1 describes the class diagram of the generic composition framework. It defines the interface of a matching operator for a specific metamodel and it implements the merging operator that is independent of any metamodel. The abstract operation getSignature in MERGEABLE has to be specialized to define the algorithm for matching elements. The getSignature operation defines the signature of the model elements. This signature is compared with the signature of other model elements to check if these elements have to be merged. A default comparison is implemented in the equals operation of STRINGSIGNATURE. This operation can be specialized in other subclasses of SIGNATURE in order to compare signatures which are more complex than simple strings. For example, two methods in a class diagram can match because they have the same name or because they have the same name and the same parameters. In the first case, the getSignature operation will return the name of the methods and the default equals is sufficient. In the second case getSignature will return the name and the list of parameters and it is necessary to redefine the equals operation. The merge operation in class MERGEABLE implements the generic algorithm for merging two model elements. The complete algorithm is defined in [5]. If two model elements match according to their signature, this operation tries to merge them into a new model elements. The algorithm compares the values of each property of the elements to merge to detect possible conflict. If no conflict is detected the new model element is created, otherwise the conflict must be solved using composition directives. The class CompositionContext contains the data structures and utility methods that are used by the merge operation in order to create the merged elements and keep a traceability information between the input models and the composed model.

Fig. 1. Generic framework for Composition

2.2 The Composition Directives Modellers can specify composition directives that are used during composition to force matches, disallow merges, and to override default merge rules. Two types of composition directives are currently supported in the composition metamodel:

10

F. Fleurey et al.

•

•

Pre-Merge Directives: These directives specify simple model modifications that are to be made before the models are merged. These changes will force or disallow element matches. These directives can specify renaming model elements, removing or adding elements. Post-Merge Directives: These directives specify simple modifications to the merged model. For example, it may be the case that a security view requires the removal of associations that are present in other views. This restriction can be specified as post-merge directives that remove these associations from the merged model.

The language for model directives is domain independent and is part of the generic composition framework. The metamodel for this language is shown Figure 2. There are two main types of directives: CREATE and CHANGE directives. CREATE directives are used to create new model elements. CHANGE directives are used to modify model elements. These directives can be used to remove an element from a namespace, set a property value associated with an element, and add an element to a namespace. A CHANGE directive is associated with a reference to the model element it modifies. A SET directive is associated with two instances of ELEMENTREF one is the target property and the other is the new value for the property. Elements can be reference by (1) a name that is an instance of NAMEREF, (2) their literal value, or (3) a unique identifier that is an instance of IDREF.

Fig. 2. The composition directives language

3 Specializing the Framework for a Particular Metamodel This section summarizes how to specialize the generic framework to add composition capabilities to a metamodel. The framework has been defined in such a way that it can be specialized for any metamodel that conforms to EMOF. The specialization process is described in Figure 3.

A Generic Approach for Automatic Model Composition

11

Specific for M meta-model Generic and reusable Meta-model M (ex. Class Diagram)

Composition Strategy for M

+

Generic Composition Framework

Directive Meta-model

Composition

Composable Meta-model M'

Fig. 3. Adding composition capabilities in a metamodel

To specialize the generic composition framework, for a metamodel M, it is necessary to define a composition strategy. This strategy specifies which elements of the metamodel can be merged. This consists in selecting the classes in the metamodel that will have composition capabilities, i.e., the classes which instances will be composable in models that conform to M. The strategy defines the equality between elements, and the signature of these elements. The composition strategy is a model with major parts: the classes of the metamodel M that are mergeable and how the signatures are computed and the classes that define comparison between signatures. The classes of M that are mergeable inherit from MERGEABLE in the strategy and they implement the getSignature operation. The other classes of the strategy specialize the SIGNATURE class of the generic framework. These subclasses specialize the equals operation that defines the equality between two model elements. We can notice that the generic framework defines a default behaviour for the equals operation. Thus, it is not mandatory to specialize the SIGNATURE class. Once the strategy is modelled it can be composed with the metamodel M. As a result of the composition, the metamodel M is augmented with the classes and methods that are necessary to provide composition capabilities. Moreover, the resulting metamodel M’ inherits form all the operations implemented in the generic framework through inheritance relationships with the MERGEABLE and SIGNATURE classes. M’ is obtained using the composition mechanism of Kermeta1 [6]. This composition only allows adding operations and classes in a metamodel and ensures that every model that conforms to the original metamodel can be viewed as an instance of the composed metamodel. Thus the models that conform to M also conform to M’ and can be composed thanks to the capabilities added in M’. 1

It can be noticed that the composition operation in Kermeta is a specialization of the generic framework presented here.

12

F. Fleurey et al.

4 An Example for Composing Ecore Models In this section we illustrate the specialization of the framework to compose models that conform to the Ecore metamodel. Figure 4 shows the Ecore metamodel that is very close to the metamodel for class diagrams. The metamodel defines packages that are composed of classifiers. There are two types of classifiers: classes or data types. The enumeration is the only data type present here. Classes are composed of structural features which can be attributes or references to other classes. Classes also contain operations which have attributes. This metamodel can be seen as a simplified metamodel for class diagrams. For the composition of two models that conform to the Ecore metamodel, it is necessary to define a specific matching operator. The merging operator is reused from the generic framework. Figure 5 shows the model of the composition strategy for Ecore models. This model specializes the generic framework to define a specific matching operator for Ecore models. According to the model in Figure 5, EMODELELEMENT (of the Ecore metamodel) inherits from MERGEABLE (from the generic framework). This means that all model elements from Ecore have to implement the getSignature operation. However, the operation only has to be implemented three times in the case of the Ecore meta-model.

Fig. 4. The Ecore metamodel

A Generic Approach for Automatic Model Composition

13

A default signature corresponding to their name is associated with all ENAMEDELEMENT. This signature is used to match classes, data types, attributes and references. For operations and parameters specific signatures have to be defined. Two operations will match only if they have the same names, parameters that match and the same return type. Two parameters will match only if they have both the same name and the same type. Both the generic framework presented in the previous section and its specialization for adding composition capabilities to the Ecore meta-model have been implemented in an open-source tool called Kompose [7]. Kompose was built using the Kermeta language and integrated in the Eclipse IDE as a plug-in. A complete demo of the tool

Fig. 5. The composition strategy model for Ecore package ecore; require "http://www.eclipse.org/emf/2002/Ecore" @aspect "true" class EModelElement inherits kompose::Mergeable {} @aspect "true" class ENamedElement { method getSignature() : kompose::Signature is do var s : kompose::StringSignature init kompose::StringSignature.new s.sign := name result := s end } Fig. 6. The composition strategy model for Ecore

14

F. Fleurey et al.

can be found in [7]. Figure 6 presents an excerpt of the Kermeta listing corresponding to the extension depicted in Figure 5. The first line specifies the working package and the second line imports the original Ecore meta-model. The class EMODELELEMENT is then reopened to add the inheritance relation to class MERGEABLE of Kompose and the class ENAMEDELEMENT is reopened to specify how signatures should be computed. These extensions do not break the conformance of existing Ecore models and thus allow directly composing them.

5 Conclusion In this paper we detailed a reusable framework for model composition. This framework implements a generic model composition operator that can be specialized for any specific meta-model. This operator is based on signatures associated with model elements for matching objects and uses a generic algorithm for merging objects. We have defined a generic composition directive language for the resolution of potential composition conflicts. It allows both to adapt input models and to fix the composed model. The proposed technique has been implemented as an open-source tool using the Kermeta language. The main advantage of the proposed approach is to allow easily defining composition operators for new modelling languages. This is especially interesting in a context where domain specific modelling languages are more and more popular. The generic framework is specialized by decorating the meta-model of the language with signatures. These signatures allow capturing semantic elements of the modelling language in order to produce a meaningful composition operator. The principal limitation of the proposed approach is that to be reusable the framework only relies on the structure of the models to compose. The signatures are the only elements which can be used to take into account some semantics of models to compose. Our current experiments show that it is not an issue when working with structural models such as class diagrams, database schemas or components model but it becomes a clear limitation when working with modelling languages such as sequence diagrams. To produce a meaningful composition operator for sequence diagrams, the order in which events and messages have to be composed is based on the semantics of sequence diagrams [8]. Using the current version of our composition framework, the only way to implement such a composition operator is to redefine the generic merge operation for the classes of the sequence diagram meta-model which contain properties that have to be semantically composed. For these classes there is no clear benefit from extending the generic framework as the merging algorithm has to be fully redefined. As a future work to what is presented in this paper we are currently investigating a finer-grained redefinition mechanism that allows redefining independently the composition strategy for each property of the modelling language meta-model. This allows focusing on properties that require special semantic composition and benefit from the generic implementation for the others.

A Generic Approach for Automatic Model Composition

15

References 1. Baniassad, E., Clarke, S.: Theme: An Approach for Aspect-Oriented Analysis and Design. In: Proceedings of ICSE 2004 (Int. Conference in Software Engineering), Edinburgh, Scotland, pp. 158–167 (2004) 2. Reddy, R., Ghosh, S., France, R., Straw, G., Bieman, J.M., McEachen, N., Song, E., Georg, G.: Directives for Composing Aspect-Oriented Design Class Models. Transaction on Aspect Oriented Development 1(1), 75–105 (2006) 3. Nejati, S., Sabetzadeh, M., Chechik, M., Easterbrook, S.M., Zave, P.: Matching and Merging of Statecharts Specifications. In: Proceedings of ICSE 2007 (International Conference on Software Engineering), Minneapolis, USA, pp. 54–63 (May 2007) 4. Klein, J., Helouet, L., Jézéquel, J.-M.: Semantic-based Weaving of Scenarios. In: Proceedings of AOSD 2006 (International Conference on Aspect-Oriented Software Development), Bonn, Germany (2006) 5. Reddy, R., France, R., Ghosh, S., Fleurey, F., Baudry, B.: Model composition - a signaturebased approach. In: Proceedings of Aspect Oriented Modeling (AOM) Workshop associated to MoDELS 2005. Montego Bay, Jamaica (October 2005) 6. Muller, P.-A., Fleurey, F., Jézéquel, J.-M.: Weaving executability into object-oriented metalanguages. In: Briand, L.C., Williams, C. (eds.) MoDELS 2005. LNCS, vol. 3713, pp. 264–278. Springer, Heidelberg (2005) 7. Fleurey, F.: Kompose : a generic model composition tool. 2007, http://www.kermeta.org/kompose/ 8. Klein, J., Fleurey, F., Jézéquel, J.-M.: Weaving multiple aspects in sequence diagrams. Trans. on Aspect Oriented Software Development (2007)

MATA: A Tool for Aspect-Oriented Modeling Based on Graph Transformation Jon Whittle1 and Praveen Jayaraman2 1

Dept of Computing, Lancaster University, Bailrigg, LA1 4YW, UK [email protected] 2 Dept. of Information and Software Engineering, George Mason University, Fairfax VA 22030 [email protected]

Abstract. This paper describes MATA (Modeling Aspects Using a Transformation Approach), a UML aspect-oriented modeling tool that uses graph transformations to specify and compose aspects. Graph transformations provide a unified approach for aspect modeling. The methods presented here can be applied to any modeling language with a well-defined metamodel. This paper, however, focuses on UML class diagrams, sequence diagrams and state diagrams. MATA takes a different approach to aspect-oriented modeling since there are no explicit join points. Rather, any model element can be a join point and composition is a special case of model transformation. We illustrate MATA on structural and behavioral models for a cell phone example.

1 Introduction Broadly speaking, there have been, to date, two approaches for modeling aspects in UML. The essence of the first approach is that two models are composed by identifying common elements and applying a generic merge algorithm. This is a symmetric form of aspect modeling and common elements are found according to some matching criteria, e.g., two classes with the same name are merged. Examples of this approach include Theme/UML [1] as well as work by France et al. [2]. The essence of the second approach is to reuse, at the modeling level, mechanisms for specifying and weaving aspects from aspect-oriented programming. There has been a significant amount of research, for example, that identifies a join point model for a modeling language and then uses the AspectJ advices of before, after, and around for weaving. Examples of this type include [3, 4]. These two kinds of approaches are not always sufficient. In the first approach, a merge algorithm based on general matching criteria will never be expressive enough to handle all model compositions. Matching by name, for example, may not work for state diagrams. Given two states with the same name, the states may need to be merged in one of a variety of ways depending on the application being modeled: (1) the two states represent the same thing, which implies making the states equal; (2) the two states represent orthogonal behaviors of the same object, which implies enclosing the states by a new orthogonal region; (3) one state is really a sub-mode of the other, H. Giese (Ed.): MoDELS 2007 Workshops, LNCS 5002, pp. 16–27, 2008. © Springer-Verlag Berlin Heidelberg 2008

MATA: A Tool for Aspect-Oriented Modeling Based on Graph Transformation

17

which implies making one state a substate of the other; (4) the behaviors of the two states must be interleaved in a complex way, which implies weaving the actions and transitions in a very application-specific way to achieve the desired result. Only the first of these can be accomplished based on merge-by-name. Furthermore, these are only four of many possible options so it is not generally sufficient to provide a number of pre-defined merge strategies. In the second approach, specific elements are allowed to be defined as join points and others are not. For example, in state diagrams, some approaches define events as join points. Others, however, define states as join points. One could even imagine more complex join points, such as the pointcut of all orthogonal regions. (This pointcut might be used, for example, by an aspect that sequentializes parallel behaviors.) Defining only a subset of a model’s elements as join points seems to be overly restrictive. In addition, limiting advices to before, after, and around is also rather restrictive since it may be desired to weave behavior in parallel, or as a subbehavior of a behavior in the base, for example. MATA is an aspect-oriented modeling tool that tackles these problems by viewing aspect composition as a special case of model transformation. In MATA, composition of a base and aspect model is specified by a graph rule. Given a base model, MB, crosscut by an aspect model, MA, a MATA composition rule merges MA and MB to produce a composed model MAB. The graph rule, r: LHS → RHS defines a pattern on the left-hand side (LHS). This pattern captures the set of pointcuts, i.e., the points in MB where new model elements should be added. The right-hand side (RHS) defines the new elements to be added and specifies how they should be added to MB. MATA graph rules are defined over the concrete syntax of the modeling language. This is in contrast to almost all known approaches to model transformation which typically define transformations at the meta-level, that is, over the abstract syntax of the modeling language. The restriction to concrete syntax is important for aspect modeling because a modeler is unlikely to have enough detailed knowledge of the UML metamodel to specify transformations over abstract syntax. MATA currently supports composition for UML class, sequence and state diagrams. In principle, however, it is easy to extend MATA to other UML models (or, indeed, other modeling languages as long as a metamodel for the language exists) because the idea of using graph rules is broadly applicable. The focus in this paper is on the MATA tool and so the presentation will be by example. Details can be found elsewhere. [5] describes MATA’s expressive pointcut mechanisms for state diagrams. [6] describes an application of MATA to composition in software product lines.

2 The MATA Language MATA considers aspect composition as a special case of graph transformation. In general, a graph consists of a set of nodes and a set of edges. A typed graph is a graph in which each node and edge belongs to a type. Types are defined in a type graph. An attributed graph is a graph in which each node and edge may be labeled with attributes where each label is a (value, type) pair giving the value of the attribute and its type. The UML metamodel can naturally be represented as a type graph. Each metaclass becomes a node in the type graph and each meta-association becomes an edge in the type graph. A UML model, therefore, can be represented as an instance of

18

J. Whittle and P. Jayaraman

this type graph and a graph rule, defined over the type graph, will transform the UML model into another model that also conforms to the type graph (i.e., another UML model). In this way, existing graph theory can be used to transform UML models. type

1 (a) Type Graph

(b) UML Model

(c) Graph Rule

(d) Transformed UML Model

Class name: String

0..1

* ownedAttr

Attribute name: String

class1

class2

attr1 : class3

attr2 : class4

|X

|X

new : class3

class1

class2

attr1 : class3 new : class3

attr2 : class4 new : class3

Fig. 1. Graph Rules for UML

Figure 1 illustrates these concepts, using a simple example that adds an attribute to an existing class. (a) is a type graph defining a very simple metamodel for a subset of UML class diagrams. (b) is a UML class diagram that will undergo a transformation. The result of applying the rule in (c) to this class diagram is given in (d). Note that the left-hand side (LHS) of the rule in (c) defines a pattern over which the rule applies. Variables are prefixed by ‘|’. Hence, ‘|X’ matches any class. The right-hand side (RHS) describes elements that should be added or removed. Any element that matches a variable on the LHS and does not appear on the RHS is removed. New elements on the RHS are added. The effect of applying the rule in (c) twice is to add two new attributes since ‘|X’ matches against both class1 and class2. MATA uses graph rules to define aspects. The pattern on the LHS essentially defines the pointcuts to match against. The RHS defines new model elements that should be added at these pointcuts (or it defines existing model elements that should be removed). There are two points of note about the graph rules in MATA. Firstly, graph transformations are typically defined over the type graph. For UML models, this means that approaches such as FUJABA [7] and others define rules over UML’s metaclasses. Whilst this is the most powerful approach, it is very inconvenient for a modeler because s/he must have a detailed knowledge of the UML metamodel. MATA instead represents graph rules in UML’s concrete syntax, as given in the example in Figure 1(c), although minor extensions to the concrete syntax are introduced to allow for powerful pointcut expressions and variable expressions. Secondly, it is also rather inconvenient to write graph rules using both a LHS and a RHS because elements that are unchanged must be repeated on both sides. Hence, MATA follows approaches such as VIATRA2 [8] in that the rule is given on one diagram. This is done by using a MATA profile which defines three new stereotypes:

MATA: A Tool for Aspect-Oriented Modeling Based on Graph Transformation

19

• <>, which can be applied to any model element, states that an element should be created by a graph rule. • <<delete>>, which can be applied to any model element, states that an element should be removed by a graph rule. • <> is used with container elements to avoid elements being affected by <> or <<delete>> (see below). Figure 2 gives an example MATA graph rule to add parallel behavior in a sequence diagram. (a) is the MATA rule itself and (b) shows the application of the rule to a particular example. (a) has two parts to it—the pattern to match against and elements to add. In this case, the pattern is defined in two ways. Elements without a stereotype are matched against. In addition, any elements stereotyped as <> are also matched against. This is because the semantics of <> and <<delete>> are defined such that if these stereotypes apply to an element, then they also apply to all of the element’s immediate neighbors. This is done simply to avoid having to write a <> or <<delete>> stereotype for all neighbor elements. For example, in Figure 2(a), the immediate neighbors of the par fragment include any messages inside the fragment. Hence, <> also applies to messages r and s. To avoid <> being applied to p, it is marked with <>. Therefore, the match defined in 2(a) is any pair of lifelines with a message p from one lifeline to the other. Note that not specifying an instance and type for a lifeline is equivalent to using two variables, |x:|X. The effect of applying the rule in Figure 2(a) is to introduce a new par fragment around all instances of message p, and this new fragment will have messages r and s occur in parallel with p.

a:A p <>

par

b:B

a:A R1

<>

par

p

q r s

b

r s

q

R2

(a) MATA rule, R1

b a:A

p <>

par <>

b:B

p

b:B p

par

q

any

b b

<>

r r s

s (c) Application of rules R1 and R2

(b) MATA rule, R2

Fig. 2. MATA Rules

20

J. Whittle and P. Jayaraman

As stated earlier, the notion of immediate neighbor is used to reduce the number of elements that must be stereotyped with <> or <<delete>>. This is purely a convenience for the modeler. The definition of immediate neighbor is specific to each model element. For a class, its immediate neighbors are all its associations. For a state, its immediate neighbors are its transitions and its actions. For a combined fragment in a sequence diagram, its immediate neighbors are all model elements contained inside the fragment. Figure 2 also shows an example how sequence pointcuts can be defined in MATA. A sequence pointcut is a match against any number of consecutive model elements— for example, a sequence of messages, or a sequence of transitions. Sequence pointcuts are handled naturally since the approach is based on patterns. In the example, the MATA combined fragment any is used to match against a sequence of messages of unknown length. So the rule R2 in Figure 2(b) will match any two lifelines with messages p and b with any number of messages between p and b. The result of applying the rule is shown in Figure 2(c). Note how the result is different than if rule R1 is applied. For R2, the pointcut is the sequence of messages p, q, b, and so, these messages all appear in the first operand of the par fragment. These examples show that expressive pointcut expressions can be naturally specified using MATA. Figure 2 only shows examples for sequence diagrams. Similar rules for state diagrams can also be specified in the current implementation of MATA.

3 Extended Example This section provides an extended example of MATA that includes both static and dynamic models. A cellphone application is used to illustrate how aspects can be specified and composed in MATA. We will model three use cases for a simple cellphone—Receive a Call, Take a Message, and Notify Call Waiting. Following Jacobson and Ng’s use case slice approach [4], we consider each use case as an aspect. We use MATA to maintain the use case separation throughout the modeling process. This avoids the traditional problem in OOAD of multiple dimensions of decomposition—that is, the requirements are decomposed in terms of use cases but the design models are captured in terms of objects. Maintaining multiple dimensions of decomposition can lead to difficulties when updating the requirements and design models. We will consider Receive a Call to be the base use case since all cellphones will have this functionality. In contrast, Take a Message and Notify Call Waiting might not be available for all phones and so are modeled as aspects. (Even if they are available for all phones, it is still useful to model them as aspects since this will maintain a clear separation of each use case from other use cases.) The base use case is modeled in UML whereas the aspect use cases are modeled as MATA models, that is, as increments of the base models. Note that the models for the aspect use cases refer only to those elements in the base that are needed for the modifications to take place. Also, each aspect is modeled independently from the other aspects, that is, it is modeled only in terms of the base (although this is not a limitation of MATA). Figure 3 shows (simplified) static and dynamic models for the base use case, Receive a Call. The phone contains a ringer, a phone component, a display unit and a

MATA: A Tool for Aspect-Oriented Modeling Based on Graph Transformation

21

keypad. Upon receiving an incoming call, the phone notifies the user by displaying the caller information on the display unit and sending a ring message to the ringer. The user is allowed to either accept the call (then hang up later) or not accept (i.e., disconnect) the call. Ringer

Phone

Display

+Ring()

Hang up/

Idle

Keypad

On call

(a) Phone System Classes Caller

User

Phone

Ringer

Display

Incoming call/ Display ,call info, Ring

Pick up/

Waiting Disconnect/ Incoming call Display call info

(c) State Diagram for Controller

Ring

alt

Pick up Hang up Disconnect

(b) Receive a Call Scenario

Fig. 3. Models for the Base Use Case

Figure 4 gives the behavior models for the two aspects, Take a Message and Notify Call Waiting. 4(a) is a sequence diagram for Take a Message. If the phone rings for a specified amount of time, the call goes to a messaging system. In MATA, this is specified by creating a new alt fragment since forwarding to voice mail is an alternative scenario to the case where the callee accepts the call. Note that an any fragment is used to match against all messages coming after Ring in the base. This is needed since once a message is taken, the user should not be able to pick up the call or disconnect it. Hence, the alt fragment must be wrapped around all messages in the base concerned with call pick up or disconnect. In Figure 4(b), the aspect rule matches any two states which have a transition between them with an event named Incoming call. The effect of the aspect is to add an additional transition capturing the voicemail behavior. When this rule is applied, the two states will match against Idle and Waiting in Figure 3(c). The effect is to add a transition from Waiting back to Idle. Figure 4(c) introduces messages for putting an incoming call on hold when a call is already underway. These new messages are only relevant when a call is taking place, that is, in between messages Pick Up and Hang Up in the base. Hence, the loop fragment is marked with a <> stereotype and this fragment is inserted in between Pick Up and Hang Up. Note that, in this case, it would be sufficient to leave

22

J. Whittle and P. Jayaraman

out the Hang Up message in 4(c), which, in effect, would insert the new behavior after Pick Up. However, we include Hang Up because there may eventually be other occurrences of Pick Up which should not be affected by the aspect. Figure 4(d) introduces a new state, Waiting for hold prompt, into the base to capture the new behavior for the call waiting use case. Note that the two transitions in 4(d) implicitly have <> stereotypes because they are immediate neighbors of the newly created state. Phone

Ringer

Incoming call/

Voice

Ring alt

<>

timeout

Forward to voice mail

<>

timeout/Forward to voice mail any

(a) Take A Message Scenario

Caller

User

Phone

(b) Take A Message States Ringer

Display Waiting for hold prompt <>

Pick up loop

Incoming call

<>

Display call info

OK Put on hold

Incoming call/ Display call info

OK/ Put on hold On call

Hang up

(c) Notify Call Waiting Scenario

(d) Notify Call Waiting States

Fig. 4. Aspect Models for Take a Message and Notify Call Waiting

3.1 Interactions between Aspects MATA comes with some support for automatically detecting interactions between aspects. Since aspects in MATA are graph rules, the technique of critical pair analysis (CPA) [9] can be used to detect dependencies and conflicts between rules. CPA examines rules in a pair wise fashion and declares a dependency if one rule requires a model element introduced by another rule. A conflict is declared if one rule modifies the base in such a way that another rule can no longer be applied. Conflicts and dependencies usually imply that the rules should be applied in a particular order since the result may be different depending on the order. A conflict may also mean that two rules that should both be applied cannot be, and therefore, the rules themselves should be modified. In any case, CPA provides a degree of automatic feedback to the modeler that both provides assistance in ordering rules and provides some assurance that the composition is correct.

MATA: A Tool for Aspect-Oriented Modeling Based on Graph Transformation

23

Considering the example again, we can see that there is a dependency between the two state diagram rules for Take a Message and Notify Call Waiting. This dependency arises because Notify Call Waiting creates a transition with event Incoming Call (Figure 4(d)) whereas Take a Message matches against the event Incoming Call (Figure 4(b)). Hence, if Take a Message is applied to the base before Notify Call Waiting then any incoming call that is received during an existing call cannot be sent to voicemail. Figure 5 gives the results of composing the two aspects with the base in either order. In 5(a), Take a Message is applied to the base before Notify Call Waiting. In 5(b), it is applied after. The difference is that there is an extra transition from Waiting for hold prompt to On call in 5(b) which captures the fact that an incoming call may be sent to voice mail even when there is currently an active call taking place. The difference in the composed state diagrams arises because the rule for Notify Call Waiting introduces a new transition with event Incoming call. Hence, when the Take a Message rule is applied in 5(b), there are two transitions with event Incoming call and so the rule applies twice. MATA detects these kinds of dependencies automatically. Ultimately, the modeler must decide which order is the correct one, but MATA can at least provide some assistance in flagging cases that must be considered more carefully. If there are no conflicts or dependencies found by CPA, then the rules can be applied in any order. CPA is particularly important when aspects are reused in a different context than originally intended since new conflicts and dependencies may then arise inadvertently. Waiting for hold prompt

timeout/ Forward to voice mail

OK/Put on hold Incoming call/ Display call info

Hang up/ timeout/ Forward to voice mail Incoming call/ Display call info, Ring

Waiting Pick up/

OK/Put on hold Incoming call/ Display call info

Idle

OnOncall call

Waiting for hold prompt

Disconnect/

(a) Take A Message before Notify Call Waiting

Hang up/ Idle timeout/ Forward to voice mail Incoming call/ Display call info, Ring

OnOncall call

Waiting Pick up/

Disconnect/

(a) Take A Message after Notify Call Waiting

Fig. 5. Base and Aspect State Diagrams Composed

4 Tool Implementation This section describes the implementation of MATA. MATA is designed as a vendorindependent tool but currently works on top of IBM’s Rational Software Modeler (RSM). Each aspect is modeled as a package. Within this package, the class diagrams, sequence diagrams and state diagrams for the aspect are maintained. Users may select

24

J. Whittle and P. Jayaraman

a subset of the aspects and the tool generates the composed model for all of these aspects and the base. The user may also define an ordering of aspect composition in the case that one aspect needs to be composed before another. If an ordering is not specified, the tool selects an order nondeterministically. Figure 6 illustrates this process. Base Model Slice

Aspect Model Slice

<>

UML UML Models Models

Aspect Model Slice

<> <>

MATA MATA Models Models

<>

MATA MATA Models Models

<>

Ordering

Composed Composed UML UMLModels Models

Conflict & Dependency Detection

Composed Model Slice

Fig. 6. MATA Tooling

Since MATA uses graph transformations as the underlying theory, it relies on an existing graph rule execution tool to apply graph rules. The graph rule execution tool used is AGG [10]. MATA converts a UML base model, captured as an instance of the UML2 metamodel by RSM, into an instance of a type graph, where the type graph represents a simplified form of the UML2 metamodel. MATA composition rules are converted into AGG graph rules and are executed on the base graph automatically. The results are converted back into a UML2 compliant model and are displayed in RSM. Critical pair analysis is done by AGG and the results are converted into RSM so that detected dependencies and conflicts can be understood by the user. In principle, MATA could use any existing graph rule execution tool (e.g., VIATRA2 or FUJABA) as its underlying engine, but AGG was chosen because of its support for critical pair analysis. Although built on top of an existing engine, MATA provides some unique features that make it very suitable for aspect modeling and composition, namely: (1) graph rules are defined graphically using the concrete syntax of UML rather than using metaclasses; (2) MATA supports sequence pointcuts, that is, an aspect may match against a sequence of messages or a sequence of transitions. This is supported directly in the MATA rule syntax; (3) the stereotype <> is unique to MATA; (4) dependencies and conflicts between aspects can be detected automatically using critical pair analysis.

MATA: A Tool for Aspect-Oriented Modeling Based on Graph Transformation

25

5 Related Work Most research on aspect-oriented modeling has focused on static models (e.g., [1, 2]). Some work has addressed behavioral models (e.g., [3, 11-13]). This paper is different from previous work in three key respects. Firstly, there are no explicit join points but instead composition is viewed as a special case of model transformation. Secondly, graph transformations provide a formal foundation for aspect composition. Finally, there is support for statically analyzing aspect interactions via critical pair analysis. Related work that is closest to ours includes join point designation diagrams (JPDDs) [14]. JPDDs are similar to defining patterns using graph rules. The advantage of using graph rules is the existence of formal analysis techniques. In addition, JPDDs focus on defining join points and are not so much concerned with composition. MATA provides a full composition tool in which very expressive composition relationships can be specified. This is not possible with JPDDs. More generally, model composition has been addressed outside of the AOSD community. In particular, [15] investigates how to merge state machines using composition relationships and category theory. This is similar in many respects to our work but has a different goal in that it addresses how to reconcile state machines produced by different development teams. Model composition is also important in feature-based approaches to software product lines.

6 Conclusion and Future Work This paper presented a new approach for modeling and composing aspect models written in UML. Tool support for MATA is built on top of IBM’s Rational Software Modeler. A prototype has been implemented and a number of case studies have been modeled with this prototype. MATA uses the graph rule execution tool AGG as a back-end for executing graph transformations and performing critical pair analysis. There are a number of interesting avenues for further work that would build upon MATA. Firstly, base models in MATA are currently completely open, in the sense that any base model elements can be accessed by aspect models. This has shown to be absolutely essential in some application areas. In particular, for the software product line method PLUS [16], which can be handled in MATA by modeling features as aspects, models of non-kernel features can be added to models of the kernel in many and varied different ways. It would not have been possible to restrict the join point model and still allow the case studies from [16] to be modeled faithfully. However, it may be desirable for other application areas to restrict the join point model so that only certain base model elements can be affected by an aspect. This kind of approach would potentially support improved modular reasoning for aspects. MATA could support such a technique easily as interfaces could be designed on top of the existing language. In any case, we feel that the modeler should be in control of whether or not full access is required by the aspects and it is not up to the language designer to restrict the join point model for him/her. Another area where MATA could potentially be extended is to provide domainspecific composition operators, built on top of the existing language. A key contribution of this paper is that MATA allows all modeling languages to be handled

26

J. Whittle and P. Jayaraman

in a uniform way. However, the current composition operators in MATA are quite low level because they are at the same level as the underlying modeling language. One could imagine defining more abstract operators, for example, in software architecture composition, that would be then mapped down to MATA’s operators. This would raise the level of discourse of aspect modelers but would retain the strong benefits of the MATA foundations. Such a path should be taken with caution, however. A great deal of effort has already gone into language design for existing modeling languages and it is not completely clear that an additional layer of abstraction would be beneficial. Along similar grounds, MATA’s composition is purely syntactic currently. This means that aspect modelers define aspects based on the syntactic elements of the underlying modeling language. Whilst this is in line with current practice in modeling, it would be interesting to investigate semantics-based composition techniques, similar to those developed for aspect-oriented requirements engineering languages [17]. This would allow modelers to specify aspects in terms of semantic concepts of the domain rather than syntactic modeling elements. For example, one might wish to define the pointcut of all model elements related to access control. The techniques in [17] rely on natural language processing techniques to extract semantic content from textual requirements documents and it is not clear how such an approach could be adapted to analysis and design models. However, it is certainly an open area of research that could provide fruitful solutions to the fragile pointcut problem in aspect-oriented modeling. Finally, we hope that the expressive composition mechanisms provided by MATA might have some consequences for aspect-oriented programming. Whilst modeling is different from programming, it seems that AOP could also benefit by more expressive pointcut languages or more expressive advices. We believe that the rich language in MATA might offer some insights as to how such languages should be developed.

References 1. Clarke, S., Baniassad, E.: Aspect-Oriented Analysis and Design: The Theme Approach. Addison Wesley, Reading (2005) 2. France, R., Ray, I., Georg, G., Ghosh, S.: Aspect-oriented approach to early design modeling. IEE Proceedings - Software 151, 173–186 (2004) 3. Cottenier, T., van den Berg, A., Elrad, T.: Motorola WEAVR: Model Weaving in a Large Industrial Context. In: Aspect-Oriented Software Development (AOSD), Vancouver, Canada (2007) 4. Jacobson, I., Ng, P.-W.: Aspect Oriented Software Development with Use Cases. AddisonWesley Professional, Reading (2004) 5. Whittle, J., Moreira, A., Araújo, J., Rabbi, R., Jayaraman, P., Elkhodary, A.: An Expressive Aspect Composition Language for UML State Diagrams. In: Engels, G., Opdyke, B., Schmidt, D.C., Weil, F. (eds.) MODELS 2007. LNCS, vol. 4735, pp. 514– 528. Springer, Heidelberg (2007) 6. Jayaraman, P., Whittle, J., Elkhodary, A., Gomaa, H.: Model Composition in Product Lines and Feature Interaction Detection using Critical Pair Analysis. In: Engels, G., Opdyke, B., Schmidt, D.C., Weil, F. (eds.) MODELS 2007. LNCS, vol. 4735, Springer, Heidelberg (2007)

MATA: A Tool for Aspect-Oriented Modeling Based on Graph Transformation

27

7. Nickel, U., Niere, J., Zuendorf, A.: The FUJABA Environment. In: International Conference on Software Engineering, Limerick, Ireland, pp. 742–745 (2000) 8. Csertan, G., Huszerl, G., Majzik, I., Pap, Z., Pataricza, A., Varro, D.: VIATRA - visual automated transformations for formal verification and validation of UML models. In: Automated Software Engineering, 2002 (ASE), Edinburgh, UK, p. 267 (2002) 9. Heckel, R., Küster, J., Taentzer, G.: Confluence of Typed Attributed Graph Transformation Systems. In: Corradini, A., Ehrig, H., Kreowski, H.-J., Rozenberg, G. (eds.) ICGT 2002. LNCS, vol. 2505, pp. 161–176. Springer, Heidelberg (2002) 10. Taentzer, G.: AGG: A Graph Transformation Environment for Modeling and Validation of Software. In: Pfaltz, J.L., Nagl, M., Böhlen, B. (eds.) AGTIVE 2003. LNCS, vol. 3062, pp. 446–453. Springer, Heidelberg (2004) 11. Klein, J., Helouet, L., Jézéquel, J.-M.: Semantic-Based Weaving of Scenarios. In: AspectOriented Software Development (AOSD), Vancouver, Canada, pp. 27–38 (2006) 12. Araújo, J., Whittle, J., Kim, D.-K.: Modeling and Composing Scenario-Based Requirements with Aspects. In: International Conference on Requirements Engineering, Kyoto, Japan, pp. 58–67 (2004) 13. Mahoney, M., Elrad, T.: Generating Code from Scenario and State Based Models to Address Crosscutting Concerns. In: Sixth International Workshop on Scenarios and State Machines (2007) 14. Stein, D., Hanenberg, S., Unland, R.: Expressing Different Conceptual Models of Join Point Selections in Aspect-Oriented Design. In: Aspect-Oriented Software Development (AOSD), Bonn, Germany, pp. 15–26 (2006) 15. Nejati, S., Sabetzadeh, M., Chechik, M., Easterbrook, S., Zave, P.: Matching and Merging of Statecharts Specifications. In: International Conference on Software Engineering, pp. 54–64 (2007) 16. Gomaa, H.: Designing Software Product Lines with UML: From Use Cases to Patternbased Software Architectures. Addison-Wesley Object Technology Series (2005) 17. Chitchyan, R., Rashid, A., Rayson, P., Waters, R.: Semantics-Based Composition for Aspect-Oriented Requirements Engineering. In: Aspect-Oriented Software Development (AOSD), Vancouver, Canada, pp. 36–48 (2007)

4th International Workshop on Language Engineering (ATEM 2007) Jean-Marie Favre1, Dragan Gašević2, Ralf Lämmel3, and Andreas Winter4 1 University of Grenoble, France http://www-adele.imag.fr/~jmfavre 2 Athabasca University, Canada http://www.sfu.ca/~dgasevic/ 3 Universität Koblenz-Landau, Germany http://homepages.cwi.nl/~ralf/ 4 Johannes Gutenberg-Universität Mainz, Germany http://www.gupro.de/~winter/

1 ATEM Workshop Series Following the great success of previous editions, ATEM2007 is the 4th edition of the ATEM workshop series. The first two editions were held with WCRE in 2003 and 2004, while the 3rd one was held with MoDELS 2006. ATEM has always been focused on engineering of language descriptions. In order to cover as many aspects of language descriptions important for greater success and adoption of model-driven engineering, ATEM has been evolving so as its scope: • The first edition was about metamodels and schemas. • The second about was metamodels, schemas and grammars. • The third edition was about metamodels, schemas, grammars and ontologies. Throughout the interaction with the MDE community and based on the papers submitted to and topics discussed about in the previous ATEM editions, we have decided that ATEM2007 is about language engineering. Thus, the intention of ATEM2007 is to further encourage and expand inter-disciplinary work (e.g., natural language engineering) on language descriptions that should bring many promising opportunities for the area of model-driven engineering. If Software Engineering is “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software” [1], then Software Language Engineering (SLE) can be viewed as the application of a systematic, disciplined, quantifiable approach to the development, use, and maintenance of languages in software engineering [2]. SLE is particularly concerned with (i) the life cycle of software languages including design, implementation, documentation, testing, deployment, evolution, recovery, and retirement; (ii) the treatment of language descriptions as software artifacts, akin to programs, subject to tailored engineering principles and methods such as modularization, refactoring, refinement, composition, versioning, and analysis; H. Giese (Ed.): MoDELS 2007 Workshops, LNCS 5002, pp. 28–33, 2008. © Springer-Verlag Berlin Heidelberg 2008

4th International Workshop on Language Engineering (ATEM 2007)

29

(iii) programming support and engineering principles for transformations (or mappings, translations, conversions) between different software languages or different manifestations of the same software language such as those in X/O/R mapping; (iv) the management of coupling and cohesion in software systems caused by the invasive use of languages; (v) consistency management for the uses of languages in software systems; (vi) language integration for interrelated uses of software languages. ATEM 2007 aimed a providing a forum to discuss software language engineering from various perspectives to facilitate a broad knowledge of methods and techniques and enable an integrated use of these.

2 ATEM 2007 Workshop The objective of ATEM2007 was to bring together researchers from different communities to study the use of various language descriptions and technical spaces in order to further expand frontiers of their synergetic use in model-driven engineering. The intended audience of the workshop was researchers and practitioners using various language descriptions (e.g., metamodels, models, ontologies, grammars, and schemas) for forward/reverse engineering, recovery, and reengineering in modeldriven software development. 2.1 Scope The importance of language descriptions, which include models, schemas, grammars, and ontologies, is generally acknowledged by the model-driven engineering community, but, as yet, the study of these artifacts lacks a common umbrella. Language engineering (in the context of software engineering) promotes language descriptions to first class citizens, just like programs, data, and models based on the systematic, programmatic (e.g., rule-based) analysis and manipulation of these language descriptions. The typical ATEM paper studies language descriptions in the context of engineering of software systems and languages. The language engineering view is generally consistent with MDE; it is specifically aligned with approaches for grammar engineering, Domain Specific Language (DSL) engineering, software factories, ontology engineering, schema engineering and others. To have a deeper focus on the language engineering perspective of MDE, ATEM2007 pays attention to the fact that language descriptions that are used in developing software systems can be defined in different ways and used to define for different software artifacts (e.g., source code, binaries, databases contents, database schemas, UML diagrams, XML files, XML schemas, software architecture descriptions, passive or active web pages, versioned repositories, configuration files, service descriptions, XML style sheets, user interfaces descriptions, RDF or OWL ontologies, natural text documents, and SQL, XQuery, RDQL queries), but still they have to be used together in integrated software development and software evolution. Thus, we need ways that enable us to take advantage of all these various language descriptions when engineering, re-engineering, recovering, and testing software systems. Since

30

J.-M. Favre et al.

most of language descriptions have rather different technological, research and cultural origins, the synergic use is rather a complex task that requires join efforts of different communities. 2.2 Program From 27 submitted papers, 13 papers were accepted to be presented in Nashville, TN. The papers accepted were into two main categories: full and short papers. All papers accepted as full papers showed important approaches and applications of language engineering by various techniques and led to interesting and fruitful discussions during the workshop. Short papers presented either work in process or discussed controversial issues in the field or describe interesting or thought-provoking ideas that are not yet fully developed. Out of 13 accepted papers, 5 were accepted as full papers, and 8 as short papers, which were presented into four workshop sessions based grouped around the following topics: foundations, domain-specific languages, transformations and modeling techniques, and data mapping/migration. Besides the peer-reviewed paper presentations, the program included a panel. 2.2.1 Selected Papers This workshop proceedings of the ACM/IEEE 10th International Conference on Model Driven Engineering, Languages and Systems (MODELS 2007) contains two summarized versions of the full papers presented at ATEM 2007: • A Comparison of Standard Compliant Ways to Define Domain Specific Languages by Ingo Weisemoeller and Andy Schuerr investigates various approaches to define DSLs, focusing on architectural description languages as an example. • Designing Syntax Embeddings and Assimilations for Language Libraries by Martin Bravenboer and Eelco Visser overviews the design space and research questions in language library realization, in particular, the identification of research issues for realizing an independently extensible language library framework. 2.2.2 Full Papers The full papers, not summarized in this proceedings, include: • A Language Description is More than a Metamodel by Anneke Kleppe proposes a framework for defining software languages by emphasizing the fact that a language’s concrete syntax and semantics are as important as abstract syntax (i.e., metamodel), which currently a common misconception in model-driven engineering of languages. • Metamodel-based UML Notations for Domain-specific Languages by Achim D. Brucker and Juergen Doser presents a metamodel-based approach for specifying UML notations for domain-specific modeling languages. • Zhi# - Programming Language Inherent Support for Ontologies by Alexander Paar proposes a novel compiler framework that facilitates the cooperative usage of external type systems based on the XML Schema and OWL languages with C#.

4th International Workshop on Language Engineering (ATEM 2007)

31

2.2.3 Short Papers The short papers presented at ATEM 2007 include: • Making Modeling Languages Fit for Model-Driven Development by Thomas Kühne argues that a modeling language that aspires to be used in a model-driven development context must fulfill more requirements than traditional notations that have been primarily used for solution sketching. • Towards Semantic Integration of Multiple Domain-Specific Languages Using Ontological Foundations by Henrik Lochmann and Matthias Bräuer presents an approach that facilitates the integration of domain-specific languages on a semantic level by mapping language constructs to concepts in an upper ontology. • Prototyping Domain-Specific Languages for Wireless Sensor Networks by Daniel A. Sadilek proposes a language engineering approach that allows rapid prototyping of domain-specific languages. • CoCloRep: A DSL for Code Clones by Robert Tairas, Shih-Hsi Liu, Frederic Jouault, and Jeff Gray describes an investigation into the development of CoCloRep, a domain-specific language for the representation of code clones. • Model-based Aspect Weaver Construction by Suman Roychoudhury, Frederic Jouault, and Jeff Gray describes an approach that combines model engineering with program transformation techniques to construct aspect weavers for generalpurpose programming languages. • An Algebraic Approach for Composing Model Transformations in QVT by Claudia Pons presents a software tool supporting the algebraic formalization for composing model transformations in QVT. • Text-based Modeling by Hans Groenniger by Holger Krahn, Bernhard Rumpe, Martin Schindler, and Steven Voelkel discusses the advantages of text-based modeling over commonly used graphical representations. • Biological Data Migration Using a Model-Driven Approach by Abel Gomez Llana, Jose A. Carsi, Artur Boronat, Isidro Ramos, Claudia Taeubner, and Silke Eckstein shows how model-driven software development can be applied in the bioinformatics field by expressing biological data structures by means of models. 2.2.4 Proceedings All papers presented at ATEM 2007, are published in [1] and all of them are online available at both the publisher’s website and the workshop’s website: http://planetmde.org/atem2007/. 2.2.5 Panel ATEM 2007 featured a panel on Grand Challenges in Software-Language Engineering that involved panelist from different technical spaces to discuss the future of software language engineering: Ralf Lämmel (moderator), Anneke Kleppe, Thomas Kühne, Eelco Visser, Krzysztof Czarnecki, and Dragan Gašević. The panel is video recorded and the video clip of the panel is available at ATEM 2007 website: http://planetmde.org/atem2007/.

32

J.-M. Favre et al.

3 Beyond ATEM 2007 There are several activities planned to further stimulate the exchange of research results in software language engineering. First, we decided to scale the ATEM workshop series up into a new series of conferences entitled – International Conference on Software Language Engineering (SLE). The steering committee of the MODELS conference series has kindly accepted our proposal to host SLE 2008 as two days long conference at ACM/IEEE 11th International Conference on Model Driven Engineering, Languages and Systems (MODELS 2008) that will be held in Toulouse in France in the period September 28 – October 3, 2008. The SLE 2008 conference will be organized by joining the forces with the community organizing the International Workshop on Language Descriptions, Tools and Applications (LDTA). Second, the editorial board of IEEE Transactions on Software Engineering kindly accepted our proposal to organize a special issue dedicated to Software Language Engineering to be published in May-June Issue of 2009 [2]. This call for papers has been complied based on the discussions at ATEM 2007, and it helped us define a scope of software language engineering to be explored in the special issue

Acknowledgement We, the organizers, thank the program committee and additional reviewers who reviewed the submissions and provided useful feedback to the authors within a very short period of time. The program committee of ATEM 2007 consisted of: • • • • • • • • • • • • • • • • • • • •

Dave Akehurst, University of Kent at Canterbury, UK Colin Atkinson, University of Mannheim, Germany Artur Boronat, Universidad Politecnica de Valencia, Spain Charles Consel, INRIA, Bordeaux, France Jim Cordy, Queen's University, Canada Krzysztof Czarnecki, University of Waterloo, Canada Juan De Lara, Universidad Autonoma de Madrid, Spain Arie Van Deursen, Delft University of Technology, The Netherlands Stephane Ducasse, University of Savoie, France Gregor Engels, University of Paderborn, Germany Mike Godfrey, University of Waterloo, Canada Martin Gogolla, University of Bremen, Germany Jeff Gray, University of Alabama at Birmingham, USA Reiko Heckel, University of Leicester, UK Frederic Jouault, INRIA/UAB, France/USA Gabor Karsai, Vanderbilt University, USA Elisa F. Kendall, Sandpiper Software, USA Pierre-Alain Muller, University of Mulhouse, France Richard Paige, University of York, UK Jeff Z. Pan, University of Aberdeen, UK

4th International Workshop on Language Engineering (ATEM 2007)

• • • • • • • • • • • • • • •

33

Juergen Rilling, Concordia University, Canada Steffen Staab, University of Koblenz, Germany Juha-Pekka Tolvanen, Metacase, Finland Laurence Tratt, King's College, London, UK Daniel Varro, Budapest University, Hungry Chris Verhoef, Vrije University Amsterdam, The Netherlands Eelco Visser, Delft University of Technology, The Netherlands Joost Visser, Software Improvement Group, The Netherlands Jos Warmer, The Netherlands René Witte, University of Karlsruhe, Germany The additional reviewers of ATEM 2007 are: Dimitrios Kolovos, University of York, UK Mirco Kuhlmann, University of Bremen, Germany Robert Tairas, University of Alabama at Birmingham, USA Pieter van der Spek, Vrije Universiteit, The Netherlands Vadim Zaytsev, Vrije Universiteit, The Netherlands

We thank our authors for their papers and interesting talks, and the participants for intensive and valuable discussions. Our thanks also go to the MODELS 2007 organizers of for accepting ATEM 2007 as part of the conference program. We also thank our supporters, who helped in advertising and organizing ATEM 2007: • planetmde.org, the community web portal on model-driven engineering; • SRE, the German GI special interest group on software reengineering; • RIMEL, the French special interest group on Reverse Engineering, Maintenance and Software Evolution.

References 1. IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12-1990), Institute IEEE, Los Alamitos, CA (1990), http://ieeexplore.ieee.org/iel1/2238/4148/00159342.pdf? tp=&arnumber=159342&isnumber=4148 2. Call-for-Papers: Special Issue on Software Language Engineering. IEEE Transactions on Software Engineering 33(12), 891 (2007), http://www.computer.org/portal/cms_docs_transactions/transactions/tse/CFP/389.pdf 3. Favre, J.M., Gašević, D., Lämmel, R., Winter, A. (eds.): Proceedings of the 4th International Workshop on Software Language Engineering (ateM 2007), Technical Report, Informatik Bericht 4/2007, Johannes Gutenberg-Universität Mainz (2007), http://www.informatik.uni-mainz.de/867.php

Designing Syntax Embeddings and Assimilations for Language Libraries Martin Bravenboer and Eelco Visser Software Engineering Research Group, Delft University of Technology, The Netherlands [email protected], [email protected]

Abstract. Language libraries extend regular libraries with domain-specific notation. More precisely, a language library is a combination of a domain-specific language embedded in the general-purpose host language, a regular library implementing the underlying functionality, and an assimilation transformation that maps embedded DSL fragments to host language code. While the basic architecture for realizing language libraries is the same for all applications, there are many design choices to be made in the design of a particular combination of library, guest language syntax, host language, and assimilation. In this paper, we give an overview of the design space for syntax embeddings and assimilations for the realization of language libraries.

1 Introduction Software libraries provide reusable data structures and functionality through the builtin abstraction facilities of a programming language. While functionally complete, the interface through regular function or method calls is often not appropriate for efficiently and understandably expressing programs in the domain of the library. Language libraries extend regular libraries with domain-specific notation. More precisely, a language library is a combination of a domain-specific language embedded in a generalpurpose host language, a regular library for the underlying functionality, and an assimilation transformation that maps embedded DSL fragments to host language code. In recent years case studies of language libraries have been conducted for a number of host languages and types of applications, including concrete object syntax for meta-programming [3,24], embedding of domain-specific languages in general purpose languages (MetaBorg) [11,6], and syntax embeddings for preventing injection attacks (StringBorg) [7]. While there is a common architecture underlying all these language libraries, there are many design choices to be made in filling in the parameters to the architecture. For example, a recent innovation is type-based disambiguation of syntax embeddings [26,10], which uses the type system of the host language to disambiguate quoted code fragments, thus allowing a more lightweight syntax. In this paper, we present an overview of the design space for syntax embeddings and assimilations for the realization of language libraries. The contribution of this paper is an overview of the state-of-the-art, providing insight in the design space, and research questions in language library realization, in particular, the identification of research issues for realizing an independently extensible language library framework. In the next H. Giese (Ed.): MoDELS 2007 Workshops, LNCS 5002, pp. 34–46, 2008. c Springer-Verlag Berlin Heidelberg 2008 

Designing Syntax Embeddings and Assimilations for Language Libraries

35

section we give an overview of the various types of applications of language libraries illustrated with examples. In the remaining sections we discuss technical considerations and trade-offs in the realization of language libraries.

2 Applications of Language Libraries In this section we consider different types of applications, which are characterized by the target of assimilation. We distinguish four types of language libraries; libraries for transformation, generation, string generation, and DSL embedding. We consider each of these categories in turn and show typical examples. Figure 1 gives an overview of some libraries that we have realized. Transformation of structured data is typihost language cally used for program transformation, but also guest lang. Stratego Java Perl PHP for transformation of other structured data, such as XML documents. Direct manipulation of the Stratego T structures through their API can lead to tedious Tiger T coding in which the natural structures are hard ATerm T T to recognize. Syntax embeddings can be used C G(T) to provide concrete syntax for patterns used to Java G(T) G match and construct code fragments [24]. The XML G(T) G target of assimilation in these applications is an SQL S S S API for analysing and constructing abstract synShell S S S tax trees. For example, consider the following XPath S S S Stratego rewrite rule that defines the desugaring Swul D of the sum construct in terms of a for loop with Regex D an auxiliary (fresh) variable: DefSum : |[ sum x = e1 to e2 ( e3 ) ]| -> |[ let var y := 0 in (for x := e1 to e2 do y := y + e3); y end ]| where y := x

Fig. 1. Examples of realized embeddings with host languages in columns and embedded languages in rows. The letters indicate the type of embedding with G = generation, T = transformation, S = string generation, D = DSL embedding.

The terms between |[ and ]| are quotations of Tiger code patterns that are used both to pattern match and to compose code. For example, the left-hand side |[ sum x = e1 to e2 (e3) ]| of the rewrite rule is assimilated to the term pattern Sum(Id(x), e1, e2, e3), where x, e1, e2, and e3 are meta-variables, i.e. variables that match subterms when the rule is applied. (newname is used to create a fresh variable in order to avoid accidental capture of free variables.) A similar idea can be used with Java as host language. While Stratego natively supports terms for representing abstract syntax trees, Java requires such structures to be defined using objects. A syntax embedding of terms in Java (JavaATerm) can be used to make analysis and construction of term structures in Java programs easier. For example, the following is a code fragment from a transformation from an ATerm representation of bytecode files to a BCEL representation of bytecode: private void addInstructions(ATerm code) { ATerm optlocals = null, optstack = null;

36

M. Bravenboer and E. Visser ATerm is = null, excs = null; match code with Code(MaxStack(optstack), MaxLocals(optlocals) , Instructions([...] and is) , ExceptionTable([...] and excs) , Attributes(_));

The embedding provides (among other things) concrete syntax for term patterns and the match <expr> with construct, which is assimilated to statements that implement the matching by analyzing the ATerm argument against the declared pattern. An important requirement for the use of syntax embeddings in transformations is that the structure of the quoted pattern coincides with the structure of the program to which it is applied. This does not hold in scenarios where the abstract syntax tree of a program is heavily analyzed, modified, and/or attributed before being transformed. For example, abstract syntax trees for C and Java require static semantic analysis before they can be properly transformed. Code generation involves the composition of programs from templates based on input such as a DSL program or user input. Construction of large pieces of code using string concatenation is tedious and error-prone. Templates are not checked statically for well-formedness and meta characters need to be escaped. Furthermore, a textual representation does not allow further processing. Use of an API provides a structured representation, but is not suitable for encoding (large) templates. Syntax embeddings allow encoding templates in the concrete syntax of the language, but at the same time producing structured code. Embedded code fragments are assimilated to API calls for constructing structured data (such as ASTs). The API does not need to support transformation of patterns derived from concrete syntax. For example, the back-end of the Stratego compiler uses rules such as TranslateStrat(|S,F) : |[ s1 < s2 + s3 ]| -> stm|[ { ATerm ~id:x = t; ~stm:s1 ~stm:s2 ~id:F’ : t = ~id:x; ~stm:s3 } ]| where x := ; F’ :=

to implement schemes for translating Stratego to C. In this example two languages are embedded in the host language; the left-hand side of the rule is a Stratego code fragment, while the right-hand side is a C code fragment. The right-hand side template uses recursive calls to generate code for the subterms of the left-hand side pattern. The results are integrated by anti-quotations such as ~stm:t and ~id:t that convert a Stratego term into the right syntactic sort. Note that quotations and antiquotations are tagged with syntactic sorts such as stm|[ and ~id:, this is necessary to avoid ambiguities in parsing. The same technique is used for other host languages. For example, the following fragment shows a Java method generating Java code represented using the Eclipse JDT. public CompilationUnit run(ClassDescriptor cd) { CompilationUnit result = |[

Designing Syntax Embeddings and Assimilations for Language Libraries

37

import java.util.*; public class #[ cd.getName() ] { #[ attributes(cd) ] } ]|; return result; }

Note that unlike in the Stratego case, the (anti)quotations are not tagged; this information can be deduced from the types of the host language (e.g., CompilationUnit) [10]. String generation is commonly used in libraries supporting domain-specific languages such as XML, XPath, regular expressions, and SQL to provide an interface that uses character strings to communicate programs in these language. For example, a method execQuery from an SQL library might take a string containing an SQL query as argument, such as execQuery("SELECT * FROM Users where username = \’" + name + "\’");

Insertion of run-time data (e.g., user input) is done by composing queries using string concatenation from constant parts and dynamic parts provided by variables. The approach suffers from a number of problems. First, strings are not statically guaranteed to be well-formed, which may lead to run-time errors. Second the approach requires escaping of meta-symbols (such as the quotes in the example above), which can lead to tedious and obfuscated code. Worst of all, the approach leads to software that is prone to injection attacks, where ill-formed user input may lead to breakdown or security compromises. For example, insertion of the string ’ OR 1=1-- in the query above would lead to dumping a list of all users. These problems can be avoided by using syntax embeddings instead of string concatenation [7]. By quoting a query, as in the following code fragment SQL.QueryExpr q = <| SELECT * FROM Users WHERE username = $str{arg} |>; execQuery(q);

the query is syntactically checked at compile-time, no spurious escaping is needed, and insertion of run-time data is guaranteed to be properly escaped to avoid injection attacks. Embedded queries are assimilated to calls to methods in a syntax API, which provides for each production in the syntax definition a corresponding method. This ensures that well-formedness of queries is verified by the type system of the host language. Domain-specific language (DSL) embedding is concerned with providing better notation for programming in a certain domain, and are typically designed around an existing library. The DSL abstracts over normal usage of the library, and assimilation is to sequences of library calls. For example, JavaRegExp is a DSL built on top of the Java regular expression library. In the first place it provides a syntax for quoting regular expressions without spurious escaping, similar to the string generation examples above. Building on this basic embedding, JavaRegExp provides a DSL for defining and combining string rewrite rules in Java. For example, the following code fragment defines several string rewrite rules for escaping HTML special characters, their composition with a choice operator <+, and the application of the rules to the contents of a string in variable input:

38

M. Bravenboer and E. Visser regex regex regex regex input

amp = [/ & /] -> [/ & /]; lt = [/ < /] -> [/ < /]; gt = [/ > /] -> [/ > /]; escape = amp <+ lt <+ gt; ~= all(escape);

Another example in this category is JavaSwul, an embedding in Java of a dedicated language for creating Swing user-inteface widgets, following the hierarchical structure of the class hierarchy of Swing [11,6].

3 Syntax Embedding and Assimilation Language libraries are realized by means of syntax embeddings and assimilations as illustrated by the architecture diagram in Figure 2. An implementation typically consists of four components, i.e. a parser, typechecker, assimilator, and pretty-printer. Together these components transform programs in the extended language to programs in the host language only. Each of the components is parameterized with data that are spe- Fig. 2. Components for syntax embedding and assimilation. Solid arrows denote data-flow, dashed arrows pacific for the syntax embedding at rameters of tools in the chain. hand. The parser is parameterized with the syntax of the extended language. This requires syntax definitions for the host language and the guest language, and a definition of how guest language fragments are inserted in host language programs. The parser converts a textual representation of a program in the combined language to a tree structure that is suitable for further processing. Type rules extend the typechecker of the host language to check extended programs. This component is optional. Having an extensible typechecker avoids type error messages expressed in terms of assimilated programs. The assimilator transforms embedded guest language fragments to an implementation in the host language. The assimilator is parameterized with a set of assimilation rules that define the translation schemes for the guest language. For certain applications the assimilation rules may be generic in the guest language. A pretty-printer converts the tree structure produced by the assimilator to text, which can be fed to a host language compiler or interpreter. Pretty-printing can be avoided if transformations are expressed directly on parse trees, rather than abstract syntax trees. Another option is not to produce a textual representation of the assimilated program at all, but instead link assimilation into the host language compiler. This is done for example in Stratego, where assimilation of concrete object syntax is built into the compiler [24]. Finally, the assimilator may generate code that makes calls to an API corresponding to the guest language (the ‘run-time system’ for the embedding).

Designing Syntax Embeddings and Assimilations for Language Libraries

39

3.1 Syntax Embedding A syntax embedding is an ex- module TinySQL exports tension of the syntax of the lexical syntax 1 host language with the syn[A-Za-z]+ -> Id tax of a guest language. Such [A-Za-z0-9\ \"\-\;] -> Char "\’" ("\’\’" | Char)* "\’" -> CharString 2 an extension is achieved by an extension of the grammar context-free syntax 3 "SELECT" Id* "FROM" Id Where?-> Query of the host language, which 4 "WHERE" Expr -> Where introduces the language con5 Expr "=" Expr -> Expr {left} structs of the guest language CharString -> Expr at specific places in the host Id -> Expr language. To illustrate the basic principles of syntax embedFig. 3. Syntax definition for a tiny subset of SQL dings, we use an embedding of SQL in PHP using SDF [23], a modular syntax definition formalism for defining the lexical as well as context-free syntax of language in a single formalism. Figure 3 shows the syntax definition for a tiny subset of SQL, the guest language of this example. We omit the syntax definition of the host language. The module TinySQL defines the lexical and context-free syntax of a stylized subset of SQL in reversed EBNF notation, namely simple queries 3 with where clauses 4 , equivalence expressions 5 , identifiers 1 and character strings with escaped quotes 2 . The syntax of 6 TinySQL is embedded module SQL-in-PHP imports PHP TinySQL exports in PHP by creating a context-free syntax 7 "<|" Query[[SQL]] "|>" -> Expr[[PHP]] new SDF module (Fig8 "${" Expr[[PHP]] "}" -> Expr[[SQL]] ure 4) that imports the "$str{" Expr[[PHP]] "}" -> CharString[[SQL]] 9 syntax definitions of PHP as well as TinySQL 6 Fig. 4. Embedding of syntax for SQL in syntax for Java and defines how the languages are combined, i.e. where TinySQL can be used in PHP and vice versa. The productions of this module use parameterized non-terminals, e.g. Expr[[PHP]] and Expr[[SQL]], which are used to indicate the language of the non-terminal. The first production 7 of SQL-in-PHP defines the quotation of SQL queries, i.e. that they can be used as PHP expressions between the quotation tokens <| and |>. The second 8 and third 9 productions define the antiquotations of this embedding, which allow an SQL expression or character string to be constructed by an arbitrary PHP expression. In this way, queries can be composed dynamically. From this combined syntax definition a parser is generated, which is used to parse PHP programs that use the SQL syntax extension. After that, the resulting parse tree or abstract syntax tree is transformed to a plain PHP program by an assimilation. 3.2 Assimilation The assimilation phase provides the actual implementation of the embedded syntax of the domain-specific language. In this phase the embedded language constructs are

40

M. Bravenboer and E. Visser

removed from the source program by a translation to the host language, using any necessary translation scheme. The implementation of the assimilation phase largely depends on the application for which the embedded language is intended. The complexity of the implementation depends on the particular combination of the embedded language and the host language. The design of the assimilation is influenced by the requirements to make embeddings (a) easy to understand, (b) composable, and (c) analyzable. Assimilation rules are the basic transformation 10 steps of the assimilation Assimilate : ArrayType(type ) -> e|[ _ast.newArrayType(e ) ]| that have a pattern of guest where e := type code at their left-hand side and produce a pattern of Assimilate : 11 host code at their rightField(e ,y ) -> |[ hand side. In our exam{| FieldAccess x = _ast.newFieldAccess() ; ples the assimilation rules x .setExpression(e1 ); x .setName(e2 ); | x |} are implemented in the ]| Stratego program transforwhere "expr" => x ; mation language. Figure 5 [e1 ,e2 ] := <map(Assimilate)> [e ,y ] illustrates two assimilation rules for the embedding Assimilate = 12 of Java in Java. The first ?AntiQuote() rule 10 assimilates an array type by generating invoca- assimilate-strat = 13 tions of the Eclipse JDT alltd(?Quote()) API for the representation of Java programs in Java. Fig. 5. Assimilation of Java in Java The second rule 11 assimilates a field access by creating a FieldAccess object and invoking some methods on it for initialization. The assimilation rules are applied by an assimilation strategy 13 , which traverses the program and applies the rules where necessary. Most assimilation strategies have the same structure: they traverse the program topdown and apply the assimilation rules if a quotation is found. If an anti-quotation is found 12 , then assimilation is stopped and the assimilation strategy is invoked recursively.

4 Design Issues There are many variation points in the realization of syntax embedding and assimilation for a language library. In this section we give an overview of the main issues. An in depth discussion of the issues and the range of solutions and their relative advantages and disadvantages is beyond the scope of this paper. 4.1 Syntax Embedding The grammar formalism that is used for defining the syntax embeddings should allow modular extension of grammars. A modular grammar formalism implies support for

Designing Syntax Embeddings and Assimilations for Language Libraries

41

the full class of context-free grammars, since that is the only class that is closed under composition. In particular, grammar classes such as LL and LR, which are supported by conventional parser generators are not adequate. Similarly, the lexical syntax is usually defined using a collection of regular expressions. However, the class of regular grammars is also not closed under composition. Solutions to composition of lexical syntax that are used in practice are: (1) Ignoring the problem, which entails that the lexical syntax of host and guest language are merged, e.g. keywords of one become keywords of the other. Used in Bali, from the pioneering AHEAD/JTS tool set [3] (see [11] for a discussion). (2) Use lexical states to distinghuish the context in which a program fragment should be interpreted. In language libraries for program generation such as Meta-AspectJ [26] and JavaJava [10] with explicit quotation symbols this is a possible solution (3) Control the state of the lexical analyzer from the parser. While this a major complication of the interface between the scanner and the parser and seems to be rather unpopular in practice, it has recently been applied in the Silver extensible compiler system [22]. (4) Let the scanner produce all possible interpretations of tokens. This is only possible if the token boundaries of the host and guest languages are exactly the same, which is often not the case. (5) Integrate lexical syntax and context-free syntax in the same formalism as is realized in the syntax definition formalism SDF, which implemented by using scannerless parsing This means that a separate lexical analysis phase is omitted and the parser operates directly on the individual characters of a source file. This is the only solution that can gracefully deal with combinations of languages. Requiring support for the full class of context-free grammars reduces the number of parsing algorithms that can be used. Currently, the best studied algorithms for parsing possibly ambiguous context-free grammars are generalized-LR [21,18] and Earley [12] parsing. Scannerless parsing [19], which is an important feature for syntax embedding, has been integrated with generalized-LR in the implementation of SDF [23]. Known issues with (S)GLR are the poor quality of error messages and the absence of error recovery. Packrat parsing [13] is another candidate for parsing syntax embeddings. Packrat parsers are used to parse languages defined by parsing expression grammars, which are closed under composition, intersection and complement. Scannerless packrat parsers are available and have been shown to perform very well [14] compared to current GLR parser implementations. Unfortunately, packrat parsers are not able to produce all possible alternatives for ambiguities. When the basic requirements for modularly combining grammars are met, there are additional modularity features a grammar formalism should have to support syntax embeddings. A notion of namespaces is needed to manage the scope of definitions in grammars to be combined. The host and guest language grammar may use the same non-terminal, which will become a single syntactic category when combined. To keep such non-terminals separated and to control exactly which non-terminals are identified, a namespace or renaming mechanism is necessary. A related issue is that the set of identifiers that should be considered as reserved keywords depends on the context. For example, class is a keyword in Java, but not in SQL. Also the rules for layout (whitespace and comments) are different depending on the context. For example, // is a comment symbol in Java, but an operator in XPath. In a declarative syntax definition

42

M. Bravenboer and E. Visser

of AspectJ [8], the notion of grammar mixins was introduced to deal with these issues (except for modular layout). The parameterized sorts and modules of SDF, along with a mixin generator, were used to implement grammar mixins. A proper language design for grammar mixins is needed. In code and string generation, quotations and anti-quotations are often highly ambiguous if the quotations of the various guest non-terminals all use the same syntax. There are three solutions to this problem. (1) The number of quotations can be restricted. For example, if the embedding allows the quotation of a list of statements as well as a single one, then a quotation of a single statement will always be ambiguous. In some applications, having only a quotation for the list of statements might be sufficient. (2) The quotations and anti-quotations can be explicitly tagged with their syntactic type, basically introducing different quotation symbols for every quotable non-terminal. This solves the ambiguity problem, but the user now needs to know when and how to use these tags. Furthermore, the tags obfuscate the code and often feel redundant to the user. In some cases explicit tagging can be made less unattractive by using keywords from the guest language. For example, the anti-quotation of an optional where clause of an SQL query can be tagged using WHERE?, which looks like the keyword WHERE from SQL. "WHERE" "?" "${" E "}" -> Where[[SQLCtx]]?

(3) The ambiguities can be preserved by parsing the ambiguous source file to a parse forest. The ambiguity can then be dealt with at a later phase (for instance, by leveraging the type system of the host language [10]), or can even be ignored if the exact representation is irrelevant. For the user this is by far the most attractive solution, since the embedding is not restricted and no knowledge about the ambiguities is required. Having a single extension of a host language available is useful, but many applications require multiple extensions to be available in a single source file. For example, in web applications, the main application domain of StringBorg, XML, SQL, Javascript, and Shell, are often used together. Extensions should preferably not be deployed as closed extensions of the host language, but rather as separate plugins that can be selected by the user and combined on the fly by the system. This requires independent extensibility of the host language, that is truly modular implementations of language libraries. 4.2 Assimilation The scope of a transformation [25] indicates the parts of the source and target program that are involved in the transformation. Scope has a major impact on the complexity of assimilations. We distinguish the following types of scopes. (1) Local-to-local assimilations map guest code fragments directly to host code fragments, which are at the exact same place in the abstract syntax tree as the original guest code. Local-to-local rules are easy to implement, since the rules are all independent and do not influence the assimilation strategy. (2) Local-to-global assimilations do not just locally replace guest code fragments, but in other places in the abstract syntax tree as well. These assimilations are typically needed when fragments to be generated cannot be expressed locally. For example, executing statements, declaring new methods, or introducing import declarations. (3) Global-to-local assimilations need context information from the

Designing Syntax Embeddings and Assimilations for Language Libraries

43

original program for a local assimilation, such as the current package, class, method, or even type information. (4) Global-to-global assimilations need context information from the source program and also produce global host code. Dynamic rewrite rules [9] are typically used to implement context-sensitive transformations, that is all but those with local-to-local scope. To avoid name capture, assimilation rules should be hygienic, that is, generated names should all be unique. This can be achieved easily with a gensym-like mechanism that guarantees generation of unique names. If the embedding is part of a family of embeddings that all implement a similar assimilation, the assimilation may be generic in the guest language. For example, the representation of object programs in Stratego is directly based on the syntax definition of the object language, thus the transformation from the guest code to Stratego is implemented generically [24]. In some cases the assimilation can even largely be host language independent [7]. If the host language can be typechecked statically, then it is useful to typecheck before assimilation, to keep the error reports as close to the original source as possible. This requires extension of the typechecker of the host language with type rules for the guest language.

5 Related Work Syntax Embedding. Macro systems usually restrict the syntax that can be introduced. For an extensive review of the relationship to JSE [1], Maya [2], Metafront [5], JTS [3], and camlp4 [20] we refer to [11] and [10]. There are a number of parser generators that could be applied for the parsing of syntax embeddings. Harmonia’s Blender [4] and Cardelli’s extensible syntax have been discussed in detail in [11]. Packrat parsing [13,14] has been discussed in Section 4.1. The Polyglot parser generator [17] supports modular adaptation of LR-grammars, which has been discussed in [7]. Furthermore, there is a wide range of applications that apply a form of syntax embedding. In these particular applications (Template-Haskell, MetaOCaml, Meta-AspectJ, SafeGen, etc.) the parsing problem is often reduced because the host language is embedded in itself or development time for parsing this combination of languages is acceptable. Hence, no general method for language libraries is required, though they could profit from such a facility. Recently, support for quoting expressions has been introduced in C#. C# does not introduce a syntax for quotation, but infers quotations from the type of variables and parameters. One of the main purposes of this facility is to use C# expressions to express query expressions, e.g. SQL, without introducing syntax (see also [7]). Assimilation. Macro systems usually only allow a straightforward local-to-local mapping from the introduced syntax to the host language. Our assimilation rules and strategies allow local-to-global and global-to-local transformations, which is somewhat related to the desire for macros to reach out and touch somewhere [15], one of the ideas leading to AspectJ. Macro systems that allow context-free grammars as macro

44

M. Bravenboer and E. Visser

arguments often provide more advanced facilities for transformations. For example, Metafront [5] associates transformations to all productions and additionally guarantees termination of the transformation. Open Compilers. Open compilers such as Polyglot [17] are not designed to facilitate DSL embedding in particular. Instead, they are designed for the introduction of new language features that invade the language, such as new types, optimizations, concurrency features, etc. The requirements for a system that supports the implementation of syntax embedding and assimilation by non-compiler experts are rather different. More experience with extensions is needed to give definite answers on the requirements. Methodology. In [16] the authors state that work is needed on DSL development methodologies, since the use of a DSL can provide major benefits, but the development of DSLs often raises many questions without clear answers or resources on the right decisions to make. Though our work chooses a particular approach to DSL development, our analysis of the design space in this area contributes to the discussion on methodologies. Also, a major focus of our work is to make the implementation of extensions as easy as possible by not imposing technical constraints on the syntax embedding and assimilation. Domain-Specific Embedded Languages. The term domain-specific embedded (or internal) language (DSEL/EDSL) is often used for a DSL defined within the host language, that is, without syntactically extending the host language. DSELs are popular in languages that have a flexible syntax, such as Haskell (user-definable infix operators) and Ruby. In the case of Ruby, there is extensive support for introspection, intercession, code generation, evaluation and bindings, which reduces the need for interpreting the DSL. The heavy use of run-time code generation is largely cultural (since similar functionality is available in languages such as Perl and Python) and due to seemingly irrelevant details, such as multi-line string literals. Considering the syntax, the main disadvantages of embedded domain-specific language approaches is that the syntax cannot be clearly defined separately, but has to be crafted carefully, based on the constraints imposed by the host language. Acknowledgments. This research was supported by NWO/JACQUARD projects 638.001.201, TraCE: Transparent Configuration Environments, and 638.001.610, MoDSE: Model-Driven Software Evolution.

References 1. Bachrach, J., Playford, K.: The Java syntactic extender (JSE). In: Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2001), pp. 31–42. ACM, New York (2001) 2. Baker, J., Hsieh, W.: Maya: multiple-dispatch syntax extension in java. In: Programming Language Design and Implementation (PLDI 2002), pp. 270–281. ACM, New York (2002) 3. Batory, D., Lofaso, B., Smaragdakis, Y.: JTS: tools for implementing domain-specific languages. In: International Conference on Software Reuse (ICSR 1998), pp. 143–153. IEEE, Los Alamitos (1998)

Designing Syntax Embeddings and Assimilations for Language Libraries

45

4. Begel, A., Graham, S.L.: Language analysis and tools for input stream ambiguities. In: Language Descriptions, Tools and Applications (LDTA 2004). ENTCS, Elsevier, Amsterdam (April 2004) 5. Brabrand, C., Vanggaard, M., Schwartzbach, M.I.: The metafront system: Extensible parsing and transformation. In: Language Descriptions, Tools and Applications (LDTA 2003), ACM, New York (April 2003) 6. Bravenboer, M., de Groot, R., Visser, E.: MetaBorg in action: Examples of domain-specific language embedding and assimilation using Stratego/XT. In: L¨ammel, R., Saraiva, J., Visser, J. (eds.) GTTSE 2005. LNCS, vol. 4143, pp. 297–311. Springer, Heidelberg (2006) 7. Bravenboer, M., Dolstra, E., Visser, E.: Preventing injection attacks with syntax embeddings. A host and guest language independent approach. In: Lawall, J. (ed.) Generative Programming and Component Engineering (GPCE 2007), pp. 3–12. ACM, New York (October 2007) 8. Bravenboer, M., Tanter, E., Visser, E.: Declarative, formal, and extensible syntax definition for AspectJ. A case for scannerless generalized-LR parsing. In: Object-Oriented Programing, Systems, Languages, and Applications (OOPSLA 2006), ACM, New York (October 2006) 9. Bravenboer, M., van Dam, A., Olmos, K., Visser, E.: Program transformation with scoped dynamic rewrite rules. Fundamenta Informaticae 69(1–2), 123–178 (2006) 10. Bravenboer, M., Vermaas, R., Vinju, J.J., Visser, E.: Generalized type-based disambiguation of meta programs with concrete object syntax. In: Gl¨uck, R., Lowry, M. (eds.) GPCE 2005. LNCS, vol. 3676, pp. 157–172. Springer, Heidelberg (2005) 11. Bravenboer, M., Visser, E.: Concrete syntax for objects. Domain-specific language embedding and assimilation without restrictions. In: Object-Oriented Programing, Systems, Languages, and Applications (OOPSLA 2004), pp. 365–383. ACM, New York (October 2004) 12. Earley, J.: An efficient context-free parsing algorithm. Communications of the ACM 13(2), 94–102 (1970) 13. Ford, B.: Packrat parsing: simple, powerful, lazy, linear time, functional pearl. In: International Conference on Functional Programming (ICFP 2002), pp. 36–47. ACM, New York (2002) 14. Grimm, R.: Better extensibility through modular syntax. In: Cook, W.R. (ed.) Programming Language Design and Implementation (PLDI 2006), ACM, New York (June 2006) 15. Kiczales, G., Lamping, J.: L.H.R., Jr., Ruf, E.: Macros that reach out and touch somewhere. Technical report, Xerox Corporation (December 1991) 16. Mernik, M., Heering, J., Sloane, A.M.: When and how to develop domain-specific languages. ACM Computing Surveys 37(4), 316–344 (2005) 17. Nystrom, N., Clarkson, M.R., Myers, A.C.: Polyglot: An extensible compiler framework for Java. In: Hedin, G. (ed.) CC 2003 and ETAPS 2003. LNCS, vol. 2622, pp. 138–152. Springer, Heidelberg (2003) 18. Rekers, J.: Parser Generation for Interactive Environments. PhD thesis, University of Amsterdam (1992) 19. Salomon, D.J., Cormack, G.V.: Scannerless NSLR(1) parsing of programming languages. ACM SIGPLAN Notices 24(7), 170–178 (1989); In: PLDI 1989 (1989) 20. de Rauglaudre, D.: Camlp4 reference manual (September 2003) 21. Tomita, M.: Efficient Parsing for Natural Languages. A Fast Algorithm for Practical Systems. Kluwer Academic Publishers, Dordrecht (1985) 22. Van Wyk, E., Schwerdfeger, A.: Context-aware scanning for parsing extensible languages. In: Lawall, J. (ed.) Generative Programming and Component Engineering (GPCE 2007), pp. 63–72. ACM, New York (October 2007) 23. Visser, E.: Syntax Definition for Language Prototyping. PhD thesis, University of Amsterdam (September 1997)

46

M. Bravenboer and E. Visser

24. Visser, E.: Meta-programming with concrete object syntax. In: Batory, D., Consel, C., Taha, W. (eds.) GPCE 2002. LNCS, vol. 2487, pp. 299–315. Springer, Heidelberg (2002) 25. van Wijngaarden, J., Visser, E.: Program transformation mechanics. a classification of mechanisms for program transformation with a survey of existing transformation systems. Technical Report UU-CS-2003-048, Institute of Information and Computing Sciences, Utrecht University (May 2003) 26. Zook, D., Huang, S.S., Smaragdakis, Y.: Generating AspectJ programs with Meta-AspectJ. In: Karsai, G., Visser, E. (eds.) GPCE 2004. LNCS, vol. 3286, pp. 1–19. Springer, Heidelberg (2004)

A Comparison of Standard Compliant Ways to Define Domain Specific Languages Ingo Weisem¨oller and Andy Sch¨ urr Real-Time Systems Lab Technische Universit¨ at Darmstadt D-64283 Darmstadt, Germany {weisemoeller,schuerr}@es.tu-darmstadt.de http://www.es.tu-darmstadt.de/

Abstract. Domain specific languages are of increasing importance for today’s software development processes. Their area of application ranges from process modeling over architecture description and system design to behavioral specification and simulation. There are numerous approaches for the definition and implementation of DSLs. Among others, the OMG offers UML profiles as a lightweight extension of a predefined multipurpose language and MOF as a metamodeling language, which can be used to define DSLs from scratch. This contribution investigates various approaches to define DSLs, focusing on architectural description languages as an example. Besides the usage of UML profiles and the definition of an entirely new language with MOF, the adaption of the UML based on a metamodel extension is also considered. As a consequence of the shortcomings depicted for the different approaches, we suggest to combine UML profiles and metamodeling in order to compensate their weaknesses and take advantage of their benefits.

1

Introduction

Nowadays the usage of domain specific languages (DSLs) is of growing importance in software development processes. Languages like BPMN [13], ACME [5] or MATLAB/Simulink [19] offer support for various phases of the software development process. Most of them are built up from scratch, often by means of a proprietary metamodeling language. As a matter of fact this results in high efforts, when building tools based on these languages. The Object Management Group (OMG) has, therefore, introduced profiles as a mechanism to describe lightweight extensions of the Unified Modeling Language [16,17] (UML) as well as the Meta Object Facility [14] (MOF) as a meta modeling language to provide standard methods for the definition of domain specific languages. From the coexistence of different standards for the definition of DSLs arises the question for which languages UML profiles are appropriate and in which cases we need to define a heavyweight extension or specify a new metamodel. On the one hand, UML is wide spread and well known, and commercial tool support is available at least for editing UML diagrams. Constraints on the models can H. Giese (Ed.): MoDELS 2007 Workshops, LNCS 5002, pp. 47–58, 2008. c Springer-Verlag Berlin Heidelberg 2008 

48

I. Weisem¨ oller and A. Sch¨ urr

be defined in the Object Constraint Language [15] (OCL), for which support is currently available in some research projects [3] and in a few commercial tools. On the other hand, customized languages do not only offer potentially greater expressive power than profiles, and allow the usage of domain specific modeling elements. Their users also benefit from the availability of code generators, which results in lower efforts to build analysis tools and editors with a customized concrete syntax. Besides that, a customized language may be smaller and easier to learn than is UML. The following sections deal with various approaches to define a DSL for software architectures and architecture families. As we primarily address users of UML, we focus on profiles and MOF as metamodeling techniques. Indeed we accept to run the risk of omitting the advantages of other languages, but this makes it much easier to bring together the benefits of metamodeling and profiles, since we already have MOF-QVT [11] as a standard for model-to-model transformations, which we want to use to combine profiles and metamodeling in the future. Altogether, we distinguish between three approaches of metamodeling: – The description of a lightweight extension of the UML by using profiles and the equivalent extension of the UML metamodel. (Section 3) – Using inheritance to extend the UML metamodel fragment that deals with components, thus introducing subclasses of the metaclasses defined in the UML 2.1 specification. (Section 4) – The specification of a metamodel for MVC architectures in MOF. (Section 5) For each approach we will consider the models and the metamodel of both the MVC design pattern and the architecture of the “Java Pet Store” (cf. section 2). We will then survey each approach with respect to the clarity of the corresponding metamodels and their semantics, usability for modelers and metamodelers, ease of defining constraints, and tool support.

2

Running Example

Each approach to define DSLs will be discussed based on the example of a language for software architectures. In particular, we will focus on the formal description of architectural guidelines and how to provide tool support for the automated checking of these guidelines. As an example for a concrete software architecture the Java Pet Store 1.1 web application, Sun’s sample application for J2EE technology, will be used. It has been designed according to the Model View Controller (MVC) design pattern, and a detailed textual description of the architectural concepts [20] is available. Thus we have sufficient information about its architectural concerns without being biased due to the usage of a certain modeling language. Figure 1 shows an excerpt from the architecture in a notation based on UML component diagrams. The basic idea of the MVC design pattern is to decouple a system into three areas of responsibility, each of which is improved in terms of extensibility, maintainability and replacability. We want to ensure architectures preserve this separation of concerns by demanding that each component of a system may only

A Comparison of Standard Compliant Ways to Define DSLs View

49

Controller Render in browser

HttpRequest

Show Page

EJB Tier Controller

RequestFilter

ScreenView ScreenFlowManager

FilteredRequest

FrontControllerServlet

ViewHelper

Events

Get status Track page flow screens

Retrieve session information

Register Listeners

Business Model

SessionModel

Commands

Command Handler

Modify session state Edit objects

Model

Retrieve model data

Fig. 1. Simplified architecture model of the Java Pet Store

provide interfaces of the same area of responsibility as the component. Additionally, we will distinguish between critical, stable, and unstable components, and define whether the usage of a component is strict, in which case the used component must be at least as stable as the one that uses it.

3

Using UML Profiles

Profiles have been introduced by the OMG to allow users to adapt the UML to their personal needs. According to the UML Superstructure specification [17], profiles are not supposed to extend the UML metamodel. Thus they are conceptually interchangeable between tools, using XMI [12] as data format, though this results in technical difficulties in practice, because most commercial tools do not completely comply to the standard. However, although the specification states that the UML metamodel is not extended by profiles, it describes metamodels that are equivalent to a given profile. There has been a considerable amount of publications on the modeling of architectural styles with UML profiles before, most of which deal with UML 1.x (cf. section 6). A sample profile for the distinction between model, view or controller elements is shown on the left side of figure 2. To keep the example small, the separation into the three areas of responsibility is limited to Interfaces and Components. The right side of the same figure shows an extension of the UML metamodel that is equivalent to the profile according to the UML Superstructure specification [17]. For the specification of the desired stability of a Component we introduce the stereotype Importance, which provides an attribute of the Stability enumeration type. An abstract stereotype Responsibility that generalizes the three stereotypes Model, View, and Controller has been defined for the decoupling of the system

50

I. Weisem¨ oller and A. Sch¨ urr «enumeration»

«profile» MVC

Stability

Importance

«stereotype»

Importance

«metaclass»

«metaclass»

Component

Interface

+ stability: Stability

+ stability: Stability {required} {required}

CRITICAL STABLE UNSTABLE

{required}

1

extension_Importance

1

base_Component

«enumeration»

Stability CRITICAL STABLE UNSTABLE

Component

«stereotype»

Interface

Responsibility base_Component

1

1

base_Interfa

1

1 Responsibility extension_Responsibility «stereotype»

«stereotype»

«stereotype»

Model

View

Controller

Model

extension_Responsibilit

View

Controller

Fig. 2. A UML profile for MVC architectures and its MOF equivalent

into areas of responsibility. This should ensure that only one of the stereotypes can be applied to each instance of the extended metaclasses. In fact this depends on the mapping of inheritance between stereotypes to the metamodel. It relies on the creation of an extension Responsibility link each time a substereotype is applied. This is what commercial tools like Enterprise Architect in fact pretend to do, but the UML specification does not clarify how to handle inheritance of stereotypes. Therefore, the creation of associations for the concrete classes with properties base Interface, base Component, extension model, extension View and extension Controller must also be taken into consideration. If these associations are marked as subsets of the one shown in the figure, the application of only one stereotype would be ensured for the above reason. If a tool behaves different in this point, this may force the user to introduce appropriate constraints and make model interchange by means of XMI difficult or even impossible. Figure 3 shows a small example of inheritance between an abstract and a concrete stereotype (A) and possible mappings to an equivalent MOF model (B–C). It must be pointed out that none of them can be applied by a tool directly, since this cannot modify its own metamodel at runtime. Instead, appropriate behavior must be ensured by other means, but the implementation is left up to the tool base_Class MyClass

MyClass

MyClass

base_Class MyClass

1

{required}

1

base_Class

1

extension_SuperST

1

base_Class

1

extension_SuperST

«Stereotype» SuperST

SuperST

SuperST

«Stereotype» SubST

SubST

SubST

A

B

1 1

base_Class

1

extension_SuperST

SuperST

0..1

SubST

extension_SubST

C

D

0..1 extension_SubST {subsets extension_SuperST}

Fig. 3. Generalization of stereotypes (A) and mappings to a MOF model (B–D)

A Comparison of Standard Compliant Ways to Define DSLs

51

developers. Getting back to the figure, we see that Mapping B is the one applied in figure 2, introducing a single association in the MOF model. This ensures exactly one subtype of SuperST (only SubST is available in the example) is applied to each instance of MyClass. Mapping C introduces an additional association between each substereotype and the extended class, but this association does not subset the one between the superclass and the extended class. If the superclass is abstract and the stereotype is required (as in the example), there are three possible ways to reflect the application of SubST to a MyClass instance. The first one is to set only the extension SuperST property, in which case the other association is useless. The second way is to set only the extension SubST property, which results in a violation of the 1 multiplicity of the extension SuperST association end, though we would expect this to result in a valid model. The third possibility is to create two links (one for each association), which will result in a violation of the 1 multiplicity of the extension SuperST association end in case multiple substereotypes are applied to an element. The mapping shown in figure 3 D is only affected by the latter problem, since the application of an instance of SubST to an instance of MyClass results in a link in both associations due to the subsets property of the extension SubST association end. For the remainder of this section we will assume that the extension of classes by stereotypes is mapped to the metamodel as shown in figures 2 and 3 B. Based on this, the following constraint can be added to Responsibility to ensure that all Interfaces and their providing Components are of the same responsibility: context Component inv: self.provided->forAll(i | i.extension_Responsibility.getMetaClass() = self.extension_Responsibility.getMetaClass()) As you will have noticed, the provided property and getMetaClass() method are not defined in our profile, but are available from the UML metamodel respectively the MOF reflection. Moreover we want to specify whether a Usage relation between Components is strict, i.e. whether it may point from a component of a certain level of stability to a less stable one. Therefore, we introduce a stereotype Strict, which extends the Usage metaclass, and attach this constraint to it: context Usage inv: Stability.ownedLiteral->indexOf( self.client.extension_Importance.stability) >= Stability.ownedLiteral->indexOf( self.supplier.extension_Importance.stability) Finally, let us look at the appliance of this profile to the concrete architecture (figure 4). We will restrict this to the EJB Tier Controller, since the effect on other components is basically the same. The concrete syntax for our extended metamodel is defined by the UML specification. A minor issue is the presentation of the stability tag in a note, where an additional attribute for the EJB Tier Controller would be preferable. Altogether, modeling of architectural styles based on UML profiles is quite an extensive approach. It requires an OCL expression for the rather simple constraint on relationships between components and interfaces. All constraints are

52

I. Weisem¨ oller and A. Sch¨ urr «Controller»

Events : Importance «Controller, Importance»

«Importance»

EJB Tier Controller

stability = STABLE

stability = STABLE

EJB Tier Controller: Component

Events: Interface

: Controller

: Controller

Commands: Interface

: Controller

«Controller»

Commands

Fig. 4. The UML profile applied to the architecture and an equivalent object diagram

rather complicated since we have to navigate between stereotypes and the extended classes, and there are some ambiguities concerning inheritance between stereotypes. The advantage of UML profiles, besides reusability of the UML metamodel, is the variety of existing tools we can use to describe architectures now. Support for UML profiles is provided by a series of commercial products, though not all of them do support UML 2 yet. These tools allow the definition of profiles as well as their appliance to a model, thus being usable as an editor not only for UML, but also for DSLs defined by means of UML profiles. Unfortunately, the validation of OCL constraints does not work properly in general.

4

Extending the UML Metamodel

This section addresses heavyweight extensions of the UML by means of a MOF tool. This differs from the approach described in section 3, for which a UML tool supporting profiles is sufficient. Unfortunately, the definition of a metamodel extension is not that easy. If the creation, deletion and modification of arbitrary elements was allowed, it might be “extended” to any other metamodel. To our knowledge there is no generally accepted definition of a metamodel extension. However, the OMG suggests to use the package merge concept from the UML Infrastructure [16, pp 162ff] for this. Therefore, we limit extensions of a metamodel to the merge of an arbitrary package into the outermost package of the original metamodel. Based on this, one obvious way to distinguish between interfaces provided by model, view and controller components is to introduce subclasses for Component and Interface from the UML metamodel. Unfortunately, we cannot make existing metaclasses abstract to ensure only the subclasses are instantiated. This is due to the definition of package merge: “For all matching classifier elements: if both matching elements are abstract, the resulting element is abstract, otherwise, the resulting element is non-abstract”, which implies that a non-abstract UML metaclass remains non-abstract in our extended metamodel. Therefore, we have to attach the constraints shown in figure 5 to Component and Interface to ensure no instances of them can be created. The new subclasses do not necessarily have additional attributes, but they allow us to redefine associations and introduce constraints for our needs to describe MVC architectures. As with UML profiles, we will try to express that an interface of a specific type must be provided by a component of the same type. Therefore, we introduce an association between each subclass of Component and the corresponding subclass

A Comparison of Standard Compliant Ways to Define DSLs «enumeration» Stability CRITICAL STABLE UNSTABLE

53

UML::Classes:: Dependencies:: Usage

UML::Components:: PackagingComponents:: Component {subsets supplier} {redefines supplier}

{subsets supplierDependency} {redefines supplierDependency}

Component

ComponentUsage {subsets client} {redefines client}

+ stability: Stability

{subsets clientDependency} {redefines clientDependency}

+ strict: Boolean

inv: self.strict implies self.client->forAll(c: Component| self.supplier->forAll(s: Component| Stability.ownedLiteral->indexOf(s.stability) <= Stability.ownedLiteral->indexOf(c.stability)))

inv: not self.oclIsTypeOf (Component)

ModelComponent

ControllerComponent

ViewComponent

UML::Classes:: Interfaces:: Interface *

+/required

*

Interface

+/provided

inv: not self.oclIsTypeOf (Interface)

{redefines provided}

ModelInterface {redefines provided}

ControllerInterface

ViewInterface {redefines provided}

Fig. 5. Excerpt from the UML metamodel extended by subclasses

of Interface, which redefines the association between the superclasses as shown in figure 5. We can also define several categories of stability in an enumeration and add a new attribute of this type to a subclass of Component. Additionally, we introduce a subclass ComponentUsage of the Usage relation from the UML metamodel and add the attribute strict to it. The association ends between this class and Component redefine those from the UML metamodel. Thus all usages of components must be properly modeled by an instance of the new ComponentUsage class. The following constraint ensures a component does not depend on a less stable one if the strict attribute is set: inv: self.strict implies self.client->forAll(c: Component| self.supplier->forAll(s: Component| Stability.ownedLiteral->indexOf(s.stability) <= Stability.ownedLiteral->indexOf(c.stability))) Each component and interface in a model must now be represented by an instance of one of the new subclasses instead of Component and Interface from the original UML metamodel. The association refinements and the constraints make sure components provide only interfaces of appropriate types and do not strictly depend on less stable components. The concrete architecture will basically look the same as the one shown in Figure 1, except that a concrete syntax for the new subclasses and relation needs to be introduced.

54

I. Weisem¨ oller and A. Sch¨ urr

The FrontController component from our sample architecture provides a view interface which offers frequently used pages, e.g. login or error screens. This violates the association refinements specified above, so a tool based on our extended metamodel would have prevented a software architect from creating this model. Instead, he might have introduced an additional view component, which gets status information from the FrontController and creates status screens from it. As we see, the formulation and check of some basic constraints can be accomplished in an UML metamodel extended by inheritance. On the other hand, elements from the original metamodel which have become unnecessary are still present in the extended metamodel. The most serious problem is the loss of compatibility to existing UML tools. So, in order to apply this approach, one would have to modify an existing or write a new tool according to the new metamodel.

5

Defining a New Metamodel

The last approach discussed in this contribution is the specification of domain specific languages from scratch by means of a metamodeling language. In contrast to an increasing number of proprietary metamodeling languages, the Meta Object Facility [14] (MOF) has been introduced by the OMG to describe models of metadata in a format independent of platform and manufacturer. A small number of tools supporting the specification of models using MOF [1] or its less expressive subset EMOF is available. In this section, the adequacy of MOF for the specification of DSLs will be discussed. Figure 6 shows a simple metamodel to distinguish between model, view and controller components or interfaces. It is similar to the extended UML metamodel discussed in section 4, but there are some differences due to the fact that we did not start with a predefined metamodel: First of all, the subsystems of inv: self.dependsOn->forAll(c | Stability.owndedLiteral->indexOf(c.stability) <= Stability.owndedLiteral->indexOf(self.stability)) 1

«enumeration» Stability CRITICAL STABLE UNSTABLE

* Module

1

ModelModule

required

+ stability: Stability *

ControllerModule

dependsOn

ViewModule

* Interface

/provided {union} *

{redefines provided} {subsets provided}

{redefines provided} {subsets provided}

ModelInterface

ControllerInterface

ViewInterface

{redefines provided} {subsets provided}

Fig. 6. A MOF model for the MVC design pattern

A Comparison of Standard Compliant Ways to Define DSLs

55

an architecture are no longer referred as components, but as Modules. When building a metamodel from scratch, arbitrary names can be given to the model elements, which allows the usage of identifiers specific to the users organisation for instance. Second, the superclasses Module and Interface can be abstract classes, so we do not have to define a constraint to ensure they cannot be instantiated. Third, the provided property of a Module is the derived union of its subsets (which may be determined by a different derivation rule in turn), instead of the derivation rule taken over from the UML into our extended metamodel. viewHelper: ViewModule stability = STABLE

required registerListeners: ModelInterface

provided

businessModel: ModelModule stability = CRITICAL

dependsOn

Fig. 7. An excerpt from the architecture model of the Pet Store

Since we have not introduced any notation, an excerpt from the architecture of our sample application is shown as an object diagram in figure 7. To be able to build a graphical editor for DSLs, a concrete syntax needs to be defined; frameworks for building editors and tools based on MOF or EMOF models are currently being developed by several organisations, e.g. [10]. The figure shows the coupling of the model and the view subsystem, which is realized by the registerListeners interface. Due to the usage of this interface the viewHelper module depends on businessModel, which requires the businessModel to be at least as stable as the viewHelper. The corresponding constraint from the metamodel is fulfilled in the example, so this is a valid model. As we have seen, the most important advantage of building a new metamodel are the extensive possibilities to adapt it to our needs and preferences. The association concepts of MOF provide a more precise and convenient way to specify relationships. Besides that, the elements can be defined in a way that makes the OCL constraints more compact than in UML profiles. Basic support for MOF based metamodeling is available as well as support for building tools on top of these metamodels. Nevertheless, building tools is still a complex and extensive task. Moreover, the introduction of a new language may require more practice than the extension of UML by means of profiles, which requires neither an entirely new concrete syntax nor new tools for the introduction of domain specific modeling elements.

6

Related Work

Several publications address the definition of DSLs, many of which deal with extensions of the UML or the specification of a new DSL by means of MOF. Dong and Yang suggest to use UML profiles to describe architectural styles in [4], but they focus on the visualization of patterns in system design rather than consistency checking, though a few examples of constraints are given.

56

I. Weisem¨ oller and A. Sch¨ urr

A publication of Henderson-Sellers and Gonzalez-Perez [7] investigates the differences between stereotypes in UML 1 and UML 2 and points out some issues about their specification from a set theoretical point of view. However, it contains some serious flaws. For instance, the authors state that “the Stereotype metaclass in UML 2.0 is a subtype of Class, so only classes can be stereotyped”, where the first has nothing to do with the latter (and it should be mentioned that “classes” in this sense are more than classes in class diagrams), or they point out the “inability of stereotypes to express behavior”, although this does obviously not hold for stereotypes which extend behavioral constructs. The authors of [6] use a framework for model-to-model transformations to map domain specific languages to UML. As discussed in the previous sections of this contribution, they state that code generation and automated model analysis usually come along with the introduction of DSLs, whereas UML is primarily used as a target language for the visualization of models. However, their approach does not make use of UML profiles yet, but is focused on basic UML instead. Besides these scientific projects there are a few commercial, proprietary meta-case-tools available [8], which in general lack interoperability, because they do not comply to a standard meta modeling language, and modularization concepts.

7

Conclusions

Our comparison of various approaches to define domain specific languages has shown the benefits and drawbacks of UML profiles and metamodeling. Profiles are supported by current CASE tools, but the concepts to refine associations are rather weak in comparison to those of a metamodeling language. They also suffer from a lack of flexibility, which makes the specification of constraints for consistency and integrity checking more complicated than necessary. In addition to these issues, there are some uncertainties about how to map profiles to an equivalent metamodel. Domain specific languages built up from scratch or as a heavyweight extension of the UML are better suited for these purposes, but they require high effort on tool building to be really usable for model editing. Table 1. Overview of approaches to specify DSLs

Expressive power Flexibility Clarity of semantics Simple constraints Model Notation Tool support

UML profiles +

UML extension + o + o -

New Metamodel + + + + + -

A Comparison of Standard Compliant Ways to Define DSLs

8

57

Future Work

From the benefits and drawbacks of the approaches discussed in the previous sections follows the desire to combine the advantages of UML profiles and metamodeling. More precisely, a way to define DSLs and make them usable without building entirely new tools is required. For this purpose, we suggest to define a mapping from a limited set of domain specific languages to UML profiles and vice versa, which will make the use of commercial CASE tools as editors possible, but enable us to revert to the possibilities provided by metamodeling tools for integrity and consistency checking of the models. For the definition of a DSL and adaption of existing tools to this language we want to perform the following steps as shown in figure 8:

UML Profile

Triple Graph Grammar

MOF/OCL Metamodel

Standard UML Tool

Translator

MOF Tool MOFLON

Fig. 8. Combination of UML profiles and metamodel based technologies

1. The abstract syntax of a DSL is defined in a MOF-compliant metamodeling tool like MOFLON [1]. OCL constraints may be used to define static semantics of models described in the DSL. 2. A UML Profile is used to define the concrete syntax of the new language with constructs similar or identical to those used by UML. 3. An implementation of QVT based on Triple Graph Grammars [9,18] is used to translate the stereotyped UML model into an instance of the metamodel and vice versa. The combination of UML profiles and metamodel based technologies is supposed to be a systematic replacement for extensive usage of profiles [2], reducing the effort of implementations to ensure the proper use of such profiles.

References 1. Amelunxen, C., K¨ onigs, A., R¨ otschke, T., Sch¨ urr, A.: MOFLON: A StandardCompliant Metamodeling Framework with Graph Transformations. In: Rensink, A., Warmer, J. (eds.) ECMDA-FA 2006. LNCS, vol. 4066, pp. 361–375. Springer, Heidelberg (2006) 2. Basin, D., Doser, J., Lodderstedt, T.: Model driven security for process-oriented systems. In: SACMAT 2003: Proceedings of the eighth ACM symposium on Access control models and technologies, pp. 100–109. ACM Press, New York (2003) 3. Chiorean, D., Demuth, B., Gogolla, M., Warmer, J.: OCL for (Meta-)Models in Multiple Application Domains. In: K¨ uhne, T. (ed.) MoDELS 2006. LNCS, vol. 4364, pp. 152–158. Springer, Heidelberg (2007)

58

I. Weisem¨ oller and A. Sch¨ urr

4. Dong, J., Yang, S.: Visualizing design patterns with a uml profile (2003) 5. Garlan, D., Monroe, R.T., Wile, D.: Acme: Architectural description of componentbased systems. In: Leavens, G.T., Sitaraman, M. (eds.) Foundations of ComponentBased Systems, pp. 47–68. Cambridge University Press, Cambridge (2000) 6. Graaf, B., van Deursen, A.: Visualisation of Domain-Specific Modelling Languages Using UML. In: ECBS 2007: Proceedings of the 14th Annual IEEE International Conference and Workshops on the Engineering of Computer-Based Systems, Washington, DC, USA, pp. 586–595. IEEE Computer Society, Los Alamitos (2007) 7. Henderson-Sellers, B., Gonzalez-Perez, C.: Uses and abuses of the stereotype mechanism in uml 1.x and 2.0. In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 16–26. Springer, Heidelberg (2006) 8. Isazadeh, H., Lamb, D.A.: CASE Environments and MetaCASE Tools. Technical report, Queen’s University School of Computing (1997) 9. K¨ onigs, A.: Model Integration and Transformation – A Triple Graph Grammarbased QVT Implementation. PhD thesis, Technische Universit¨ at Darmstadt (to appear, 2007) 10. Minas, M.: Generating Visual Editors Based on Fujaba/MOFLON and DiaMeta. In: Proc. 4th Fujaba Days, Technical Report tr-ri-06-275, pp. 35–42, University Paderborn (2006) 11. Object Management Group, Inc. Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification (November 2005), http://www.omg.org/cgi-bin/apps/doc?ptc/05-11-01.pdf 12. Object Management Group, Inc. MOF 2.0/XMI Mapping Specification, v2.1 (September 2005), http://www.omg.org/cgi-bin/apps/doc?formal/05-09-01.pdf 13. Object Management Group, Inc. Business Process Modeling Notation Specification (February 2006), http://www.omg.org/cgi-bin/apps/doc?dtc/06-02-01.pdf 14. Object Management Group, Inc. Meta Object Facility (MOF) Core Specification (January 2006), http://www.omg.org/cgi-bin/apps/doc?formal/06-01-01.pdf 15. Object Management Group, Inc. Object Constraint Language (May 2006), http://www.omg.org/cgi-bin/apps/doc?formal/06-05-01.pdf 16. Object Management Group, Inc. Unified Modeling Language: Infrastructure (February 2007), http://www.omg.org/cgi-bin/apps/doc?formal/07-02-06.pdf 17. Object Management Group, Inc. Unified Modeling Language: Superstructure (February 2007), http://www.omg.org/cgi-bin/apps/doc?formal/07-02-05.pdf 18. Sch¨ urr, A.: Specification of Graph Translators with Triple Graph Grammars. In: Mayr, E.W., Schmidt, G., Tinhofer, G. (eds.) WG 1994. LNCS, vol. 903, pp. 151– 163. Springer, Heidelberg (1995) 19. Simulink - simulation and model-based design (1994–2007), http://www.mathworks.com/products/simulink/ 20. Sun Microsystems, Inc. Java pet store architectural overview (2001), http://java.sun.com/blueprints/code/jps11/archoverview.html

Third International Workshop on Model Driven Development of Advanced User Interfaces Andreas Pleuß1 , Jan Van den Bergh2 , Stefan Sauer3 , Daniel G¨ orlich4 , 1 and Heinrich Hußmann 1

University of Munich, Germany {Andreas.Pleuss,Heinrich.Hussmann}@ifi.lmu.de 2 Hasselt University, Belgium [email protected] 3 University of Paderborn, Germany [email protected] 4 University of Kaiserslautern, Germany [email protected]

Abstract. The workshop Model Driven Development of Advanced User Interfaces (MDDAUI ) aims at integrating results from the area of humancomputer interaction and user interface modeling with the concepts of model-driven engineering. This paper provides a summary on the third edition of MDDAUI held as part of the MoDELS 2007 conference in Nashville, USA. In particular, it presents the results of the two group discussions of the workshop.

1

Workshop Topic

The user interface of an application is often one of the core factors determining its success. While model-based user interface development is an important line of research in the human-computer-interaction (respectively human-machineinteraction) community, model-driven application development is an important area in the software engineering community. This workshop aims at integrating the knowledge from both domains, leading to a model-driven development of user interfaces. Thereby, the focus of the workshop is on advanced user interfaces corresponding to the current state-of-the-art in human-computer-interaction, such as multimedia or context-sensitive user interfaces or multimodal interaction techniques. The workshop builds up on the results of the previous editions in 2005 [1] and 2006 [2]. While the first two editions mainly provided an overview of the topic, the current edition aims at addressing more advanced topics in this area, including usability of the approaches, their integration with informal techniques like visual design and prototyping, and a better utilization of concepts from model-driven engineering, e.g., more flexible transformations leading to better adapted user interfaces. The research area is still evolving as new user interface technologies and paradigms are coming along and model-driven technologies are becoming more mature. H. Giese (Ed.): MoDELS 2007 Workshops, LNCS 5002, pp. 59–64, 2008. c Springer-Verlag Berlin Heidelberg 2008 

60

2

A. Pleuß et al.

Submissions, Participants, and Program

Interested participants were invited to submit a paper of four pages length in double-column format. We mainly asked for technical papers presenting concrete solutions that consider the concepts of model-driven engineering, e.g., specified in terms of a concrete metamodel. We received fourteen submissions and accepted nine of them as the result of an intensive peer-review process by the programme committee. Five papers were selected to be presented as long presentations and four for short presentations at the workshop. Workshop participants basically came from two different groups: Some were frequent participants of the MoDELS conference who have a strong background in model-driven development while others were mainly based in the area of human-computer interaction (or humanmachine interaction). The workshop took one day during the MoDELS conference. In the morning sessions all accepted papers were presented; according to the foregoing selection process either in a long presentation or a short presentation. After each talk there was some discussion and in addition there was time for additional discussion and general questions at the end of each session. In the afternoon the topics for group discussions were selected and participants joined one of the two discussion groups. The detailed program can be found on the workshop Web page [4]. Official proceedings including all accepted papers are available electronically [3].

3

Workshop Discussions

After paper presentations two discussion groups were formed around the following topics: – Usability of Model-Driven UI Development for the Developers – Combination of Modeling Techniques At the end of the workshop, both groups presented their discussion results which are summarized in the following. 3.1

Usability of Model-Driven UI Development for the Developers

A core issue in user interface development is usability: The user interfaces resulting from a user interface development process must be usable, and the development process should ensure usability as much as possible. In addition, the development tools and methods itself should be usable as well. This, in turn, will improve the usability of the developed user interfaces. The discussion summarized here focuses on the usability of a model-driven user interface development process. A specific characteristic of user interface development is the participation of different experts, like graphic designers, interaction designers, and programmers. The integration of these experts is one of the main benefits models can provide in user interface development. The discussion group aimed at further specifying the role of models in user interface development. Finally, the following statement was found adequate:

Third International Workshop on MDDAUI

61

Models shall act as a kind of bridge between input from various people involved in UI development (end users, domain experts, UI developers, management people, etc.) to integrate all this knowledge and to transfer it into the software engineering process. Participants agreed that currently no modeling language completely satisfies in covering all aspects of all the different experts. Moreover, it was considered likely that a “universal” language of this kind, covering all possible situations and projects, will be too complex to be used in practice. An attractive solution may come from domain-specific user interface modeling languages (DSUL) and corresponding tools. It was mentioned that the required meta-tools for this approach are not easy to handle, and probably the definition of a DSUL for a specific project, company or domain may be expert work or a consultancy task. In order to actually be accepted by user interface developers, such a modeling approach has to offer significant practical advantages. From the comparison with other technologies, which were around for some time before having been embraced by the developer community (code version management, IDEs), it becomes clear that a successful tool must leverage reuse of previous work. Things to be reused in the user interface context are, among others: patterns, anti-patterns, usability heuristics, usability metrics, interface components, etc. In particular, reuse here includes knowledge about the usability of user interfaces. Furthermore, it has to be taken into account that the people who will actually work with a modeling tool are quite heterogeneous, as mentioned above. Each of these user groups will have a specific view on a model. So for instance, end users and domain experts can be involved best if the tool comprises a facility to carry out prototyping experiments or to incorporate the results of such experiments. For modeling experts, tools for creating abstractions from actual interaction sequences will be most important. For user interface developers, the tool shall provide detailed technical information; maybe even on code level. In order to keep all these views consistent under modifications in various views, techniques like those known as “round-trip engineering” from CASE tools are desirable. 3.2

Combination of Modeling Techniques

In model-driven user interface development, a large spectrum of different approaches exists. Although there are many commonalities between these approaches, they are often isolated from each other. However, there is variability between them because of their distinguished focus or the particular application domain. For example, some of them support context-sensitive user interfaces, collaborative applications, mixed interactive systems, multimedia user interfaces, etc. This discussion aims at a better understanding of the relationships between the different models and concepts in user interface modeling. The resulting benefits can be in first place a better general understanding. In longer terms, it might also be possible—considering the concepts of model-driven engineering— to provide operations on the different metamodels in user interface development

62

A. Pleuß et al.

to support a seamless spectrum of user interfaces to be developed. For example, a user interface can be multimedia and context-sensitive. In the ideal case, modeling support for such a user interface can be provided by reusing and combining modeling concepts (metamodels) for these two aspects. The combination of metamodels probably has to be performed manually, but a general overview on the landscape of existing modeling concepts can strongly help the modeling experts to identify and reuse the required concepts. It should be mentioned that basically it would also be possible to construct an overall metamodel for user interface development which already covers all possible aspects of user interfaces, but in practice this would be a very hard and error-prone task. In the discussion we identified the following issues as the starting point: – Identify relevant dimensions to structure the models. – Identify relationships between user interface models. – Identify relationships from user interface models to other kinds of models (of the software engineering domain) in application development. Initially, two dimensions were identified to be most relevant for structuring the user interface metamodels: Semantic aspects: The aspects of the user interface represented by a specific metamodel; i.e., the kind of information in the model. Examples are the user tasks to be supported by a user interface or its dynamic behavior. A specific aspect of the user interface can be represented by different modeling concepts, i.e., different metamodels. For example, the user tasks can be represented by ConcurTaskTrees, or MAD. Discourse Models do not directly represent user tasks but can (partially) replace task models as they also specify the purpose of the user interface but on a different level of abstraction. The dialogue or interaction to be performed by the user interface can be specified for example using Statecharts or Petri Nets. Level of abstraction: The level of abstraction on which a metamodel represents the respective aspects of the system. Usually, the level of abstraction is related to the position of the model within the development process: In early stages the user interface will be modeled in a more abstract way while models specifying the final implementation must be very concrete. However, the concrete temporal order of models within a development process depends on the chosen process. In particular, it might be possible that some very concrete information is already available at an early stage of the development. In this case, it can be useful to be able to specify it immediately. Figure 1 provides a first attempt to arrange some typical user interface models within these two dimensions. Two kinds of relationships are specified: Contributes to: A (meta-)model contributes to another (meta-)model, i.e., the target model is created based on information from the foregoing model. In particular, this can mean that the target model is derived by a transformation from the source model. For example, the Abstract Presentation and the Dialogue are usually created based on a Task model.

Third International Workshop on MDDAUI

63

Abstraction

Business Domain

Task

Dialogue/ Interaction

Abstract Presentation

Dialogue/ Interaction

Semiconcrete Presentation

Dialogue/ Interaction

Concrete Presentation

User

Environment

Platform Contributes to Refers to Semantics

Fig. 1. A first sketch towards a schema structuring common metamodels in user interface modeling and their relations

Refers to: If a model refers to another, existing model, this means that some model elements in the former model contain references to model elements specified in another, the latter model. For example, the Dialogue usually refers to the Domain model as for example interactive user interface elements usually trigger some operations from domain classes. The models in the presented schema basically can be applied to the development of any kind of user interface. Some domains require models for additional information, e.g.: – user interfaces for mixed interactive systems require specification of physical objects, – user interfaces for multimedia applications require specification of media objects.

4

Conclusion

The area of model driven engineering is continously evolving and, as the workshop discussions show, the area of user interface modeling can directly profit from

64

A. Pleuß et al.

these advances. This does not only concern better tool support but also the foundations. Currently, well-defined metamodels allow comparing and reusing user interface modeling concepts. Tunability of transformations can be used as mechanism to ensure the usability of developed user interfaces. In the future, advanced concepts of model driven engineering, like model weaving, might be used for more flexible integration of different concepts for advanced user interfaces, like for user interfaces supporting collaboration, multimedia, and mixed-reality. Acknowledgements. We thank the workshop participants for their high quality contributions as well as the program committee members for their valuable reviews.

References [1] Pleuß, A., Van den Bergh, J., Hußmann, H., Sauer, S.: Workshop Report: Model Driven Development of Advanced User Interfaces (MDDAUI). In: Bruel, J.-M. (ed.) MoDELS 2005. LNCS, vol. 3844, pp. 182–190. Springer, Heidelberg (2006) [2] Pleuß, A., Van den Bergh, J., Hußmann, H., Sauer, S., B¨ odcher, A.: Model Driven Development of Advanced User Interfaces (MDDAUI) - MDDAUI 2006 Workshop Report. In: K¨ uhne, T. (ed.) MoDELS 2006. LNCS, vol. 4364, pp. 100–104. Springer, Heidelberg (2007) [3] Pleuß, A., Van den Bergh, J., Hußmann, H., Sauer, S., G¨ orlich, D.: MDDAUI 2007 – Model Driven Development of Advanced User Interfaces 2007. In: CEUR Workshop Proceedings, vol. 297 (2007), http://ceur-ws.org/Vol-297 [4] Third International Workshop on Model Driven Development of Advanced User Interfaces (MDDAUI 2007) (2007), Workshop Web page, http://planetmde.org/mddaui2007/

Domain-Specific Methods and Tools for the Design of Advanced Interactive Techniques Guillaume Gauffre, Emmanuel Dubois, and Remi Bastide IRIT – University of Toulouse 118, route de Narbonne 31062 Toulouse Cedex 9, France {gauffre,emmanuel.dubois,bastide}@irit.fr

Abstract. Novel interactive systems such as Augmented Reality are promising tools considering the possibilities they offer, but no real development methods exist at the moment to help designers in their work. We present in this paper a design method for tightly coupling early interaction design choices and software design solutions. Based on an existing model used for abstract UI design, our work introduces a second model dedicated to the software UI specification and the model-based process used to derive one from the other. To achieve this, we present here a framework based on domain-specific models and transformations to link them and thus support the development process. Keywords: Mixed Interactive Systems, Model-Driven Engineering, DomainSpecific Languages, Metamodeling, Model Transformations, Design Process.

1 Introduction In the past 10 years, a new HCI trend has emerged: traditional “Window, Icon, Menu, Pointing device” interfaces tend to be replaced by new forms of interaction that involve physical artifacts, easily manipulated by users. Augmented Reality systems, for example, are interactive systems in which the realization of a physical task is enriched by the presence of digital data and/or services. Tangible User Interfaces and ubiquitous systems are other forms of interactive systems which merge physical and digital worlds. Because they deal with similar concepts and techniques, we group these approaches under the single term: Mixed Interactive Systems (MIS). To support the development of such systems, MIS frameworks have been developed and adopt bottom-up or top-down approaches. Each of them brings consequent advances at different levels of abstraction of the design [7], but interlacing them remains difficult to accomplish, thus limiting the coverage of the development process. As the use of MIS increases, enhancing the robustness, efficiency and quality of these systems is required. In this sense, elaborating a convenient development process becomes necessary. To cover the different steps of such a process, our approach promotes the results gathered in the early design phases and bridges the gap between the abstraction levels of these results and the implementation. To do so, we articulate H. Giese (Ed.): MoDELS 2007 Workshops, LNCS 5002, pp. 65–76, 2008. © Springer-Verlag Berlin Heidelberg 2008

66

G. Gauffre, E. Dubois, and R. Bastide

models to progress along the development process and adopt an MDE approach, thus introducing a Domain-Specific Language [1] for MIS.

2 MIS Engineering Framework Common processes for HCI development include four phases: requirements gathering, design, implementation and evaluation. Figure 1 presents how our tools cover the first three phases. Following interviews and observations, task modeling is one of the major tools used to support the requirements gathering. Task models are used to characterize the sequence of sub-tasks with their type (i.e., user’s activities, system’s activities or interactive activities), the domain objects involved and the events triggered, and to structure these sub-tasks in a hierarchical form corresponding to the global system task. The design phase can be decomposed into two separate steps: UI design and the related software specification. The former step is concerned with user interaction aspects. It may be linked to requirements gathering by combining users’ observation, brainstorming or focus-groups to collect user needs, and an interaction model to organize them according to the specificities of MIS [4]: domain objects description, user abilities, physical and digital artifacts, forms of interaction. During the latter step, design aspects related to the software architecture are considered, using a model dedicated to the description of MIS architectures. The next step is the implementation of the system by using component-based platforms improving flexibility and adaptability. Finally an evaluation can be carried out in different ways such as user experiments or ergonomic inspection.

Task Modeling

Component-based Implementation

Focus-Group Mixed Interaction Modeling

Software Architecture Modeling

Fig. 1. MIS domain-specific process

At each step, a set of existing models, notations and tools exists: task model in the requirements gathering, dialog and interaction models in the UI design, software architecture and system objects models in the software specification. In this context, rather than modifying the different models involved in order to articulate their usage, we describe a DSL to support this process. Indeed, the current state of the design approach is consistent with two major aspects that are well addressed by an MDE approach:

Domain-Specific Methods and Tools for the Design of Advanced Interactive Techniques

67

• Multiple models are required in each phase of the development process and one role of MDE is to “promote models to primary artifacts that drive the whole development process” [1]. MDE will facilitate their articulation and permit the elicitation of coherence rules. • The MIS domain, with regards to its applications in our every day life, produces emergent systems. Elaborating methods for developing them requires to evaluate the adequacy of models and to support their evolution when required. The MIS domain is in a phase of empiricism and begins to develop theories; MDE will be a powerful support of this evolution.

3 Two Domain-Specific Models The core of the MIS Domain-Specific Language is based on two models: • ASUR [4], a model which describes the user’s interaction with a Mixed Interactive System. It can be used by itself or as mentioned before, in combination with a focus-group. • ASUR-IL [4], a complementary model that have been introduced to cover the description of the software decomposition and structure. Its aim is to prepare the implementation step by producing a coherent architecture, promoting the forms of interaction chosen in a technological perspective. After an overview of the ASUR metamodel in the next section, we present the ASUR-IL metamodel to enable the collaboration of our two domain-specific models. 3.1 ASUR Overview For a given task, the role of ASUR is to support the description of the physical and digital entities that make up a mixed interactive system and the boundaries among them. ASUR components are adapters (AIn, AOut) that bridge the gap between both digital and physical worlds, digital tools (STool) or concepts (SInfo, SObject), the user (U) and physical artifacts that are used as tools (RTool) or objects of the task (RObject). Components can be interconnected by several kinds of relationships. The most important one, data exchange, is used to describe the kind of data that is transmitted. In the physical part, the relationships represent the information channels between components, and in the digital part the way the system treats them. The representation link is used to express the fact that two components are two representations (one digital and one physical) of the same concept: this link is characterized in terms of behavior and rendering. Finally, real associations express the physical proximity of two physical components and triggers represent an action of one component on another. On the basis of previous works in the domain, design-significant aspects have been identified and added to the model as objects attributes: ASUR characteristics improve the specification of components (perception/action sense, location, etc.) and relationships (type of language, point of view, dimension, etc.). By analyzing the characteristics of each element, the model supports the predictive analysis of two properties: continuity and compatibility of interactions.

68

G. Gauffre, E. Dubois, and R. Bastide

To illustrate ASUR (Figure 2), let us consider a system for 3D object modeling. This system offers, among other features, a dedicated physical artifact for translating, scaling and rotating the 3D object during its edition. This tool embeds a marker for video-based detection of its position and a pressure sensor for switching between each mode (translation, scale and rotation). The physical tool is modeled in ASUR as an RTool, manipulated by the user. The 3D object is the main digital concept of the task and is modeled as an SObject. The second digital concept is the interaction mode and is typed as an STool. Two adapters for input (AIn) collect data (marker detection and pressure sensor) to control each digital concept. These are in turn connected to one AOut for visual output: the mode is rendered as textual data and the 3D object in a 3D scene.

Fig. 2. ASUR model of the 3D object modeler example

3.2 ASUR-Implementation Layer: Towards the Implementation Phase For each ASUR model, i.e. a given mixed interactive task, an ASUR-IL model is associated. The main contribution of this model is to identify the software components and relationships required to implement this specific task. Only the components involved in the interaction part of the system are described. The description of functional parts of the system is out of ASUR-IL scope. This model is also the frontier between Platform Independent Model (PIM) and Platform-Specific Model (PSM): it describes the software components involved in the task and their communications, the next step being the transfer to a PSM where each ASUR-IL component will be associated to existing software component or new ones. An ASUR-IL model is an assembly of components which contains two kinds of sub-assemblies: adapters and entities. Each of them is related to ASUR components (ASUR adapters Æ ASUR-IL adapters, ASUR system components Æ ASUR-IL entities). Each sub-assembly regroups several components with specific roles in the architecture (devices, APIs, models, controllers, and views). ASUR-IL adapters for input or output, corresponds to the adapters in the ASUR model and group devices and software libraries (APIs), used to connect physical and digital worlds. Devices are used to capture/render data from/to the physical world. They can translate physical phenomenon into digital data and vice versa. APIs permit to combine several computing facilities to obtain required data: for example, ARToolKit is a specific toolkit for Augmented Reality, which grabs a video frame and produces 3D coordinates of the recognized markers. Therefore adapters compose the system part which is likely to be reused: a software implementation of an adapter can either exist and satisfy the

Domain-Specific Methods and Tools for the Design of Advanced Interactive Techniques

69

ASUR modeling, or be developed on the basis of a combination of existing devices and APIs. ASUR-IL entities are the other kind of sub-assemblies that make up an ASUR-IL model. They correspond to the digital concepts that are involved during interaction and which are identified in ASUR as STool, SObject or SInfo. They are triplets of three ASUR-IL components called models, views and controllers, inspired by the MVC decomposition [8]. Controllers interpret the physical phenomena and translate data from adapters into commands on model parts. Models are the entry point to the functional core. They are an abstraction of it, enabling the dialog with the application core. Finally, views are in charge of the computation required to reflect the state of each digital concept on each output adapter connected. Finally, the relationships named data flows connect each component by using the interfaces port. The correctness of the data flow between two components is ensured by the value given to the attribute data type of each port. The ASUR-IL model (Figure 3) that describes the 3D object modeler cited in the previous section is composed of 13 components. A first adapter collects the pressure level on the tool using only one device component. A second one produces a 4x4 matrix for position and orientation of a marker, captured by a camcorder device and computed by the ARToolKit API. The last adapter is in charge of rendering the digital concepts, using a screen device connected to a window API. To render each concept, two API components are added: a text field and a 3D canvas. The two ASUR-IL entities follow the MVC decomposition. For example, the 3D object is composed of one model which contains the object’s characteristics (position, size, etc.). One controller transforms a 4x4 matrix into a scale/rotation/translation factor. Finally, one view is in charge of inserting the object into the 3D scene by using 3D primitives. The second entity, the interaction mode, follows the same decomposition: one model containing the three states, one controller to convert one level of pressure into one of these three values and a view to express the current mode as a string of characters.

Fig. 3. ASUR-IL model of the 3D object modeler example

3.3 MIS Design Support ASUR has its own editor: GuideMe [6]. It is a graphical editor which can export diagrams as XML files. After its metamodel was defined [3], a second version of the editor

70

G. Gauffre, E. Dubois, and R. Bastide

was developed using EMF to separate graphical editing from model manipulation. As mentioned above, ASUR and ASUR-IL are two models required at different steps of a MIS design process. Other models could also be required such as task models for requirements gathering or system models for functional core specification. To support the integration of our two models and further evolution, we adopt an MDE approach and choose to instrument it with tools from the Eclipse Modeling Project (EMP [5]). This enables the creation of dedicated tools for each model with EMF, GMF, and others. Therefore each model can be edited using the corresponding plug-ins in Eclipse (cf. Figure 4). Using these tools, the designer can manipulate the two models easily. The main challenge is now to link them by model transformations to rapidly observe the consequences of modifying the description of the interactive situation modeled with ASUR on the software architecture described with ASUR-IL. The next section presents the transformation between ASUR and ASUR-IL and finally introduces the transformation between ASUR-IL and a software component model: WComp [2]. Eclipse GuideMe Plugins ASUR-IL

ASUR

EMF .codegen .edit

EMF .codegen .edit

GMF .diagram

GMF .diagram

ASUR2IL ATL

WComp

Fig. 4. Tools integration

4 Domain Transformations In order to implement domain transformations, the Atlas Transformation Language (ATL) was chosen. One of the main reasons is that ATL is now fully integrated with the Eclipse Modeling Project [5] and so ensures complete coherence between the different tools. ATL also provides some precious characteristics for the manipulation of our models: transformation rule inheritance (as class inheritance in object-oriented language) and three ways to define a rule: using a declarative paradigm, an imperative or a mixed one. A model-2-text engine (JET) is also used to produce the PSM for the WComp platform, from the PIM ASUR-IL. The metamodel of the software component model WComp is currently only expressed as code in the platform itself. Thus at the moment, only platform-specific code generation is supported in the framework.

Domain-Specific Methods and Tools for the Design of Advanced Interactive Techniques

71

4.1 ASUR2ASUR-IL: Software Modeling Initialization The goal of this transformation is to prepare the construction of a component-based architecture. ASUR identifies several digital concepts and describes their roles in the interaction: this is the left-hand side of the transformation. On the right-hand side, ASUR-IL is in charge of describing the different kinds of software components involved in the interactive part of the system, with adequate ports and data flows between them. Practically, the principles of the correspondence between these two parts are well-known, but verbally or textually expressed and not formalized. With ATL, these rules are expressed using a transformation specification language and thanks to the transformation engine, are applied on the models. Each ATL rule follows roughly the same behavior: the type of each ASUR component plus the characteristics of the relationships between them are identified, and the satisfying rules are applied. It consists, for example, in creating for each ASUR adapter, an ASUR-IL adapter (Figure 5-1) that contains one default device and some APIs that account for the kind of interaction modalities described in the ASUR model. The rules include imperative code to interconnect components (Figure 5-3) and to factorize common processes. When ASUR digital components are transposed into ASURIL (Figure 5-2), they potentially trigger the creation of multiple views and controllers after models have been created: one controller per modality used to interact on the digital component, one view per modality used to reflect its state. This transformation is the starting point of the software architecture design. From the characterization of a mixed interactive situation with ASUR, it produces the basis of the software architecture. It offers to rapidly design the software components structure of a concrete system before starting its implementation. This combination supports the designers during design phases, by linking abstract UI design and software UI specification. Following the transformation, designers can extend the specification ASUR-2-ASUR-IL transformation ASUR model

Adapters

(1)

Adapters :

APIs + Devices

SObjects

(2)

Entities : M+V+C

(3)

ASUR-IL model ASUR-IL-2-WComp transformation

Components

(4)

Components

WComp configuration

Assembly

(5)

Components (6)

Repository

Fig. 5. Specific transformations of MIS process

72

G. Gauffre, E. Dubois, and R. Bastide

by additional design decisions, such as the instantiation of other APIs or devices considering some technical limitations. Based on this software specification, the next step is defining a platform-specific model of the system. We present in the next section another transformation process to support this final transition. 4.2 ASUR-IL2WComp: Platform-Specific Model Definition Assuming, that during ASUR-IL editing the designers carefully identified each component of the system, they now must be transposed to the platform model. The currently chosen platform is WComp [2] which is dedicated to rapid prototyping of wearable and ubiquitous interactive systems. Considering these purposes, this platform allows the creation of assemblies of components with a small granularity and the runtime adaptation to the platform context (i.e., low battery level, devices disconnected, etc.). Its flexibility and its simplicity are the major reasons that motivated its use. The definition of this transformation is on-going work using the model-2-text engine of EMF: JET. It will build the bridge from the PIM (ASUR-IL) to the PSM (an assembly of WComp components), with two goals: • Creation of software components. It consists in: − describing the data manipulated and the associated interfaces (Figure 5-4), − identifying an existing software component in a repository (Figure 5-6) that contains previously developed components or standard APIs and devices, • Management of the assembly of components (Figure 5-5) to establish the connections between each component in accordance with the ASUR-IL model. The code required for implementing new components that will be generated by the transformation includes the definition of constructors, interfaces and the common files to generate ready-to-use libraries for the platform. Finally, the assembly corresponding to the system will be expressed as an XML file, in accordance with an XML schema specific to the WComp platform. The generated XML file contains the kind of components to instantiate and the communication channels between each interface. Once the definition of this set of transformations is complete, our work will provide MIS designers with a range of tools from interaction design to implementation. It will help to rapidly experiment with designed interactive situations from the ASUR results to the WComp assembly of components dedicated to MIS. To illustrate the kind of process it will create, we next describe our tools on a case study.

5 TUI for Museum Exhibitions The goal of this case study is to design innovative interactive situations in the context of museum exhibitions. Our task is to design solutions promoting knowledge transmission and entertainment in a science museum for particular themes: in this case the evolution of species. By using this approach, we can rapidly experiment with advanced interaction and adapt them to other themes by reusing components.

Domain-Specific Methods and Tools for the Design of Advanced Interactive Techniques

73

Fig. 6. Schema of the mixed interactive system

The current project aims at proposing visitors to discover species evolution by elaborating an evolution tree based on phylogenetic criteria. Adopting MIS in that context offers the opportunity to keep the visitors away from technologies as much as possible, by letting them manipulate physical objects: visitors thus remain focused on the content and are not impressed or afraid of the use of technologies such as mouse, keyboard, complex 3D devices, etc. Using MIS also increases the visitor’s experience by adding digital rendering (video, 3D, sound, etc.). To elaborate the evolution tree, the user manipulates physical representations of species (a frog, a crocodile, etc.) to add them to the tree which is rendered by video on the interactive space with related phylogenetic criteria (Figure 6). The first solution (Figure 7) uses marker-based detection to capture tangible objects (species) and visual rendering to report the data. These two facets of the interaction are described by three adapters on the ASUR model. The first one, marker-detection, is able to determine the position and orientation of each physical component representing species. The second one is capable of visually rendering the state of each digital component of the system. Another adapter for output is used for displaying the evolution tree to the rest of the audience using a large display. When describing with ASUR the task of inserting a species in the tree, an ASUR system component is identified to depict the digital object that includes the characteristics of the selected species. A second system component is required to depict the digital information related to the hierarchical classification of the species: this is a second digital concept manipulated in this task. These two digital concepts are thus connected to the three ASUR adapters: these relationships express the fact that information captured by the adapter for input (the camcorder) will affect the two digital concepts and that these two digital concepts are also affecting the adapters for output (namely the video-projection and the large-display). Figure 8 shows the ASUR-IL model resulting from the asur2asur-il transformation. Each adapter has been translated into an ASUR-IL adapter, combining a default device connected to one API component which will be used to adapt the data emitted or needed by each device. In this case, the localization of each physical object

74

G. Gauffre, E. Dubois, and R. Bastide

Fig. 7. ASUR model for evolution-tree construction

Fig. 8. Asur2asur-IL transformation result

representing one species will be made using a camcorder, producing a picture used by the API ARToolkit to obtain the 3-dimensional coordinates. For each ASUR digital component, an ASUR-IL entity is created with the correct amount of controllers and views depending on the number of modalities used during the interaction. In this case, only one controller and one view are necessary for the interaction with the species, and only one view is used to render the evolution tree (same modality on each adapter: video-projection and large-display). The core behavior of each digital concept will be implemented in the model components, and the interaction with them will be coded into controllers for input and views for output. To illustrate the dependencies between the two models, we focus on the case where the system also provides vocal feedback when selecting a species. This way, the user gets a description of the selected species. It results (Figure 9) in the addition of an AOut in the ASUR model, an adapter for output corresponding to Voice synthesis, and its translation to the ASUR-IL model. The transformation will produce another view component for the species because of the two modalities used. Once the architecture is designed, the next step is to use the ASUR-IL model for the implementation of the system on the WComp platform, a .NET platform using C# code. This transformation will generate component skeletons, such as interfaces, constructors and parameters, to be loadable into the platform. This is the behavior for

Domain-Specific Methods and Tools for the Design of Advanced Interactive Techniques

75

Fig. 9. Model evolution

novel components. The other choice is to specify a component that has already been developed and is described in a repository. Following this step of choosing or generating components, an XML file will be generated containing the assembly description of the system, used by WComp to run it. In the example, the components for ARToolkit API and camera device but also the frame component based on the device for video-projection, have been yet developed. Finally only entities and PiccoloCanvas components must have to be developed on the platform WComp.

6 Conclusion and Future Work This work is a step toward the definition and instrumentation of a design process for Mixed Interactive Systems. This process will permit us to increment on the designed solution until obtaining a convenient degree of usability. The advances presented here, ASUR-IL model and related transformations, offer rapid navigation between the abstract design of innovative interaction techniques, expressed with ASUR, their concrete specification, expressed in ASUR-IL, and the final realization corresponding to their implementation by a WComp assembly. The Domain-Specific Language developed is an efficient tool for promoting the characteristics issued from the usercentered design into the crucial phase of implementation. As this approach uses models as primary artifacts, thanks to the MDE tools, each level of abstraction defined in the development process embeds properties standing for the usability of the interactive system. The ASUR model defines some properties related to the quality of the interaction between a user and a mixed environment. Our goal is to integrate them throughout the entire process, to finally evaluate their evolution during each cycle of the process. Further work will aim at identifying additional properties, relevant at the software design level (ASUR-IL) such as computing time or hardware constraints, and structuring their impacts on the remaining design steps of our process. It will increase the ability to evaluate the quality of each interactive situation. Another perspective is to study the feasibility of reverse transformations between each step and their impact on the higher levels of abstraction. A modification of a

76

G. Gauffre, E. Dubois, and R. Bastide

WComp assembly (choosing one device instead of another) could be evaluated at the ASUR level to determine the consequences of such choices. Finally, we focus here on specific models for MIS. To make possible the development of concrete systems, other aspects could be included: collaboration with business models for the connection with the functional core, interactive modalities ontology to support the choice of specific devices and APIs, and also description of the behavior of the components using dialog models for example (State charts, Petri nets, etc.). As already mentioned, the MDE approach is very helpful to articulate and transform models. However, it appears that designing MIS may rely on a lot of models and maintaining the coherence among all of them may be difficult. The management of this combination of models and transformations needs to be investigated to better assess the usability of the MDE approach for a MIS development process.

References [1] Bézivin, J., Jouault, F., Kurtev, I., Valduriez, P.: Model-based DSL frameworks. In: 21st ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, Portland, USA, pp. 602–616 (2006) [2] Cheung, D.F.W., Tigli, J.Y., Lavirotte, S., Riveill, M.: WComp: a Multi-Design Approach for Prototyping Applications using Heterogeneous Resources. In: Proceedings of the 17th IEEE International Workshop on Rapid System Prototyping, Chania, Crete, pp. 119–125 (2006) [3] Dupuy-Chessa, S., Dubois, E.: Requirements and Impacts of Model Driven Engineering on Mixed Systems Design. In: Gérard, S., Favre, J.-M., et Xavier Blanc, P.-A.M. (eds.) Proceedings of the conference IDM 2005, Paris, France, pp. 43–54 (2005) [4] Dubois, E., Gauffre, G., Bach, C., Salembier, P.: Participatory Design Meets Mixed Reality Design Models. In: Conference Proceedings of Computer Assisted Design of User Interface (CADUI 2006), Bucarest, Romania. Information Systems Series, pp. 71–84. Springer, Heidelberg (2006) [5] Eclipse modeling Project, http://www.eclipse.org/modeling/ [6] GuideMe, http://liihs.irit.fr/guideme [7] Hampshire, A., Seichter, H., Grasset, R., Bilinghurst, M.: Augmented Reality Authoring: Generic Context from Programmer to Designer. In: Proceedings of the 20th conference CHISIG of Australia, OZCHI 2006, pp. 409–412. ACM Press, Sydney, Australia (2006) [8] Krasner, G.E., Pope, T.: A cookbook for using the Model-View-Controller User Interface Paradigm in Smalltalk-80. The Journal of Object Oriented Programming, 26–49 (1988)

Transforming Discourse Models to Structural User Interface Models Sevan Kavaldjian, Cristian Bogdan, J¨ urgen Falb, and Hermann Kaindl Institute of Computer Technology Vienna University of Technology, Vienna, Austria {kavaldjian,bogdan,falb,kaindl}@ict.tuwien.ac.at

Abstract. User-interface design is still a time consuming and expensive task to do, but recent advances allow generating them from interaction design models. We present a model-driven approach for generating user interfaces out of interaction design models. Our interaction design models are discourse models, more precisely models of classes of dialogues. They are based on theories of human communication and should, therefore, be more understandable to humans than programs implementing user interfaces. Our discourse models also contain enough semantics to transform them automatically into user interfaces for multiple devices and modalities. This paper presents a two-step transformation approach with an intermediate user interface model. By showing specific transformation rules, we concentrate on a major part of the first step, transforming discourse models to structural user interface models.

1

Introduction

In previous work [7], we have already been able to automatically generate usable user interfaces (UIs), even for multiple devices and for real-world applications. We generated such UIs from models, but since these models included finite-state machinery they were more in the spirit of abstract UIs (abstracting from the interaction modality) rather than high-level interaction design. More recently, in the OntoUCP1 project, we wanted to work with models that are more understandable to humans and possibly more easily to build. Therefore, we studied several theories of human communication from various fields. Based on insights from some of these theories, we focus on high-level specifications of discourse in the form of models. These models specify discourse in the sense of dialogues, where monologues are embedded and connected. According to the reference framework [3], these discourse models are located at the “task and concepts” level. From our previous work, we inherit the use of communicative acts (and references to domain knowledge). Communicative acts are derived from Speech 1

OntoUCP (A Unified Communication Platform both for Machine-Machine and Human-Machine Interaction based on Ontologies), partially funded by the FIT-IT Program of the Austrian FFG as project number 809254/9312. We also acknowledge ¨ the (financial) support of the PSE division of Siemens AG Osterreich.

H. Giese (Ed.): MoDELS 2007 Workshops, LNCS 5002, pp. 77–88, 2008. c Springer-Verlag Berlin Heidelberg 2008 

78

S. Kavaldjian et al.

Act Theory [13] and express intentions in the sense of desired effects on the environment. By integrating communicative acts with some results from Rhetorical Structure Theory (RST) [10] and Conversation Analysis [9], we developed a new discourse metamodel [1,5]. The metamodel defines what the discourse models should look like in our approach. So, we strive for high-level modeling of discourse, including dialogues. Such a discourse model is inspired by human communication and serves as an interaction design for a traditional information system. Currently we do not support the generation of UIs with direct manipulation. From such an interaction design, user interfaces for several devices are to be generated automatically. Since we knew already how to generate them from a kind of abstract UI model, we strived for generating UI models from our new interaction design models. In general, this involves partitioning of a given discourse tree, which is described in [1]. The remainder of this paper is organized in the following manner. First, we explain our model-driven transformation approach on the basis of self-defined metamodels. Then we focus on concrete transformation rules for mapping a discourse model to a structural UI model. Finally, we briefly discuss our approach as compared to related work.

2

Overall Approach

Our approach to fully automated UI generation is a two-step process. Model-tomodel and model-to-code transformations are necessary to transform a discourse model to structural UI models, and further to multiple UIs for diverse platforms. In the following, we present the first step (see Figure 1) and explain the input (discourse model), the output (structural UI models) and the transformation rules for the model-to-model transformations. Our discourse models use a self-defined Domain Specific Language (DSL) for specifying the classes of possible dialogues or interactions between the human and the machine. The abstract syntax of the DSL is based on the conceptual

M2

Discourse Model

ra MT

a orm nsf

n tio

M2M Transformation M2 MT ran sfo rm ati on

Structural UI Model for Mobile Phone

Structural UI Model for Desktop PC

Structural UI Model for PDA

Fig. 1. The model-to-model transformation step

Transforming Discourse Models to Structural User Interface Models

Discourse

79

inserted sequence 0..*

+rootNode

1

Node +child

+

Adjacency Pair

name

2..*

+parent 0..1 RST Relation + + +

nucleiCondition nucleusSatelliteCondition satelliteCondition

Communicative Act + +

contentCondition degreeOfStrengh

1

0..1 is adjacent to >

Fig. 2. Conceptual discourse metamodel

metamodel shown in Figure 2, which illustrates the concepts used. Every discourse is composed of a tree, where leaf nodes are Communicative Acts and inner nodes are Rhetorical Relations based on RST. The UML class diagram shown in Figure 2 is not as restrictive as our interpretation, since it would allow the creation of more general kinds of graphs than tree structures. The association class Adjacency Pair is needed to model Inserted Sequences. The Communicative Acts are used to model the intention of a communication and refer to elements of the domain of discourse. Figure 3 shows a selection of the most important Communicative Acts used in our approach. Two corresponding Communicative Acts, like Offer and Accept, form a sequence, which is called Adjacency Pair. The Adjacency Pairs build up the dialogue structure. The Rhetorical Relations are used to connect Communicative Acts or, again, Rhetorical Relations with each other. They represent the dependencies between single interactions of dialogues. Examples for Rhetorical Relations are Condition, Joint and Background. The Condition relation is used to model dependencies between adjacency pairs in the way that one branch (satellite) has to be executed and its Boolean expression fulfilled before the other (nucleus) can start. The Joint Relation is used to group Communicative Acts of the same type. No presentation order is presumed. The Background Relation is used to express that the satellite branch contains background information related to the nucleus branch. Figure 4a shows a small part of an online shop discourse model, which we use as a running example throughout the paper. The example describes an interaction between the user and the online shop with the purpose of demanding the customer to select one product category and supporting her with background information to ease her choice. The nucleus branch N of the Background relation conveys the main interaction sequence. The online shop system offers a list of product categories to the user. The user accept s one of them. During the offering process the satellite branch S provides background information about

80

S. Kavaldjian et al. Node Communicative Act + +

Assertion

Informing

contentCondition: degreeOfStrength:

Directive

Answ er

Question

Request

Commissive

Accept

is adjacent to

Offer

is adjacent to

is adjacent to

Fig. 3. Selection of communicative act taxonomy

the product categories to the user. This part of an online shop discourse model gets transformed to the structural UI model shown in Figure 4b by applying the rules Light Background, Adjacency Pair, Offer-Accept and Informing to the corresponding discourse model elements in the listed order. Details on each rule are described in section 3. The structural UI model is basically a tree representing the UI structure independently of any toolkit (e.g., Web, Java Swing, etc.). It is not completely independent of the target device, however, since the device’s real-estate is taken into account for building up the UI structure. Still, our structural user interface model is completely independent of the considered UI toolkit. This tree structure will be transformed to a toolkit-specific (final) UI. The concepts used in such a structural UI model are specified in the structural UI metamodel shown

Panel (flow layout) Panel (grid layout)

Background N Shop

Offer (product categories)

ListWidget

S Informing (category details)

adjacentTo

Customer

Accept (one category)

(a) Subtree of an online shop discourse.

Panel (grid layout)

Button (category)

ListWidget

Label Widget (cat. details) (nucleus !f(x))

(b) Resulting structural UI model.

Fig. 4. Online shop example showing a part of its discourse (a) and the resulting structural UI model (b) of its model-to-model transformation

Transforming Discourse Models to Structural User Interface Models

Widget

InputWidget

Textbox

Panel

ComboBox

81

Choice

ListWidget

Button

OutputWidget

Label

Fig. 5. Part of conceptual metamodel of structural UI models

conceptually in Figure 5. It only shows the parts that are important to our running example. The most important concept of the metamodel is the Widget class. It is specialized into four functional categories: OutputWidget s, InputWidgets, ListWidgets and Panel s. The OutputWidget s present information to the user in different ways like text and images and the InputWidgets gather information from the user. Nevertheless, InputWidgets also convey information to the user like defaults, current values and type and quantity of required information. The main issue that we address in this paper is how to transfer models as exemplified in Figure 4a to structural user interface models at the abstract widget level as in Figure 4b. In particular, it means a transformation from a mainly declarative model of a discourse to the toolkit-independent structure of a user interface. The general principle behind our approach is that the structural UI model is made up of “presentation” units that are made visible when the logic of the interaction with the user so requires. Once this principle is established, our problem can be specified as follows: – Given a discourse tree with communicative acts as leafs, generate the possible set of presentation units, and the transitions between these presentation units. Since each presentation unit has to be a coherent discourse itself, it corresponds to a subtree of the overall discourse tree. As such, we call this problem the discourse tree partitioning problem. This problem and a solution to it is described in [1]. – Given a presentation unit as a discourse subtree, generate a structural UI model based on heuristic rules. Since this effectively “pre-renders” a discourse tree into a structural UI model, we call this problem the pre-rendering problem.

82

S. Kavaldjian et al.

Ecore

conformsTo

Discourse Metamodel

conformsTo

mapping

conformsTo

Discourse Model

Structural UI Metamodel

conformsTo

transformation

Structural UI Model

Fig. 6. The transformation process

In the structural UI model, a complete tree or subtree with a Panel as its root element represents a presentation unit. Hence, a complete structural UI model can, in general, be a forest consisting of possibly several trees. Trees in the structural UI model that are alternatives, i.e., trees on the same level resulting from discourse partitioning or Joint relations, will be linked in the structural UI model via a Choice element as shown in the metamodel in Figure 5. The Choice element is used to specify alternative presentation units, which can be used to fill in the same space. Our example in Figure 4a represents exactly one presentation unit that corresponds to the tree shown in Figure 4b. Figure 6 illustrates that the transformation of one presentation unit is fulfilled by mapping elements of the discourse metamodel to elements of the structural UI metamodel. Both metamodels are based on the Ecore2 meta-metamodel. Transformation languages like ATL3 (ATLAS Transformation Language) or MOLA4 (MOdel transformation LAnguage), which is used in this paper to graphically specify the transformation rules, support this transformation approach. At the same time a state machine is generated from the discourse model which controls the sending and receiving of Communicative Acts. This latter generation is beyond the scope of this paper, however.

3

Pre-rendering Rules for Transforming to a Structural UI Model

After having introduced the general transformation principles, we concentrate on the pre-rendering problem and introduce concrete rules for mapping a discourse model to a structural UI model. They are specific to certain structural patterns 2

3 4

Essential MOF like core meta model of the Eclipse Modeling Framework (http://www.eclipse.org/emf/) http://www.eclipse.org/m2m/atl/ http://mola.mii.lu.lv/

Transforming Discourse Models to Structural User Interface Models Discourse Model

Structure of UI x

Panel (flow layout)

Background N

Structural UI Model

83

widget for nucleus N (in most cases a panel)

S Hyperlink (satellite)

subtree

heavy subtree

Widget (nucleus)

link to satellite S

Fig. 7. Heavy Background Rule

occurring in the discourse models. We have found many such patterns during our modeling experience, and we continue to find new ones. Due to limited space, we only exemplify five rules which we believe illustrate the principle. Heavy Background Rule: Figure 7 shows a rule for a “Heavy Background” relation, which associates a nucleus subtree with a “large” satellite subtree, i.e. a subtree that has a large number of nodes compared to the nucleus subtree and can lead to clutter if rendered in its entirety. The “nuclear” part is rendered directly since, as per the definition of RST nucleus, it is the most important part to convey, but if there is no space for its background information, the background information is rendered in a separate presentation unit. A link to the latter is presented together with the “nuclear” part, so an appropriate widget for a link (e.g., hyperlink, button) will be generated by the transformation process. Also, the action of the respective button can be generated to activate the separate presentation unit corresponding to the background. Light Background Rule: Figure 8 shows another rule specific to the Background RST relation. The satellite is rendered on the right side of the presentation unit, while the nucleus occupies the left area, as an “aside”. In accordance to the rule above, the “most nuclear part” takes the interface space that is of highest surface and most central to the user focus. Following this principle further, the layout management of the presentation unit will always give precedence to the “nuclear” side, e.g., when the window is resized by the user. This rule is used in our example to generate the basic tree structure of Figure 4b, i.e., this rules generates the root panel and places the transformation results of the prerendering of the nucleus and satellite subtrees next to each other by a flow layout manager. The Light Background Rule can also be localized (adapted), e.g., for cultures that write from right to left, where it may be more suitable to place the satellite at the left side. A system-wise style configuration can also render light backgrounds to the top and to the left, like it is, e.g., customary when the concrete user interface will be an HTML page. However, even there the space allocation and re-allocation in case of resizing will prioritize the nuclear part. Figure 9 illustrates the formalized Light Background Rule in MOLA, composed of the following elements. The outer bold rectangle symbolizes a for-each loop. The rounded rectangle inside represents the actual rule that will be repeated for

84

S. Kavaldjian et al. Discourse Model

S Widget (nucleus)

subtree

light subtree

Structure of UI x

Panel (flow layout)

Background N

Structural UI Model

widget for nucleus N (in most cases a panel)

widget for satellite S (in most cases a panel)

Widget (satellite)

Fig. 8. Light Background Rule

Fig. 9. Light Background Rule

each matched element. The small boxes inside the rule represent different kinds of classes, depending on their borderline style. When the thickness of the border line is regular, they represent a “normal” class. A bold border lined box represents a loop variable. A dashed lined box border represents a class that will be created by the transformation rule. The small black circle represents the starting point of the rule. The double rounded circle represents the end point of the rule. In particular, the Light Background rule iterates over all Background RST relations. Whenever a Background relation connects a nucleus tree and a satellite tree, the rule matches. In this case, a root Panel element of the structural UI model is generated. Next the execution is handed over to the rule responsible for the nucleus and subsequently to the rule transforming the satellite. Both rules get the panel as a parameter, so that they can add their results to the panel. Adjacency Pair Rule: Each adjacency pair is transformed to a Panel element of the structural UI model containing widgets according to the related commu-

Transforming Discourse Models to Structural User Interface Models

85

Fig. 10. Adjacency Pair Rule

nicative acts. In our example, the first panel on the second level in Figure 4b results from the application of the Adjacency Pair Rule to the Offer-Accept adjacency pair. Figure 10 illustrates the formalized Adjacency Pair Rule in MOLA. It iterates over all Adjacency Pairs of the Discourse Model and creates a Panel element each. It also creates an association to the parent panel which the rule gets as a parameter. In our example, the Adjacency Pair Rule adds the created panel to the root panel of Figure 4b. Offer-Accept Rule: Each Offer -Accept adjacency pair is transformed either to a Button or to a ListWidget element containing Buttons, depending on the cardinality of the content offered. Because our example online shop can offer more than one product category, the ListWidget element is needed to model an undefined number of categories. Since the acceptance of an Offer requires a user action, a Button element is embedded in the ListWidget in Figure 4b. As a result, the subtree of the ListWidget is repeated according to the actual number of product categories in the final UI. Figure 11 illustrates the formalized Offer-Accept Rule in MOLA. It iterates over all Offer s that are associated with an Accept via an Adjacency Pair. The parameter container of type panel represents the parent panel and allows the rule to add the generated widgets to the panel. Depending on the type of the communicative act’s content, one of two alternative rules is selected. If the content is a kind of List (consisting of more than one element) a ListWidget and a Button are generated. In all other cases only a Button is generated in the structural UI model. Informing Rule: Each Informing communicative act is transformed either to a Label element or to a ListWidget element containing a Label element, depending on the cardinality of the content. This rule assumes that the information will be

86

S. Kavaldjian et al.

Fig. 11. Offer-Accept Rule

forwarded in textual form, otherwise, e.g., a PictureBox or AudioPlayer element will be used. In the online shop example, information is conveyed for each product category and, therefore, a ListWidget containing Label s is generated. If a communicative act is not part of an adjacency pair, as it is the case with the Informing in Figure 4a, a Panel element is also created as a container for the communicative act. More detailed information about the automatic generation that is used as a basis for this approach can be found in [6,7].

4

Related Work

Model-based UI design methods developed and published in the nineties including OVID [12], and Idiom [14] focus on creating different kinds of models, like user’s conceptual models, task models and interaction models. Unlike our approach, which is model-driven, all the mentioned approaches above are modelbased. That is, they allow expressing an interactive system by task, concept

Transforming Discourse Models to Structural User Interface Models

87

and/or abstract models in a first step and use them in an informal process or in a sequence of systematic steps to construct a user interface. In contrast, UI Frameworks like XUL5 (XML User Interface Language) are able to generate UIs automatically but they rely on UI models at the abstract widget level, which is on a lower level than our discourse models. An advanced approach to specifying multi-device user interfaces based on task models instead of discourse models is presented in [11]. Its basic approach is to start modeling tasks and to generate user interfaces for diverse devices according to specific device characteristics. In contrast to our approach, some of the transformations between models are done semi-automatically or manually. A major difference between task models and our discourse models is that task models express richer temporal dependencies whereas our discourse models specify causal dependencies, too. The semantic mapping of task models to dialog models based on UML State Machines is explained in [4]. A similar approach is used to generate the UI behavior from our discourse models. Florins et al. describe in [8] transformation rules for pagination of UIs on different levels. Partitioning our discourse models into presentation units in the first transformation step provides important guidance for pagination [1]. Botterweck shows in [2] a model-driven approach that starts on the abstract UI level, but contains rich procedural UI descriptions together with UI elements. Thus, it requires UI modeling as well as dialogue modeling.

5

Conclusion

In this paper, we present a new approach to generating structural user interface models by applying model-driven transformations to discourse models. Our discourse models are derived from results of human communication theories, cognitive science and sociology and are used for specifying interaction design of human-computer interaction of information systems. Thus, they contain additional metainformation, like the intention of an interaction, which allows us to define sophisticated pre-rendering rules to transform the discourse models to structural UI models. Our transformation takes already device constraints into account to generate a UI structure well suited for the target device, but the resulting UI models are still independent of UI toolkits. Taking this together with our previous work on automatically generating UIs from abstract models, this paves the way for automatic generation of UIs from our new interaction design models.

References 1. Bogdan, C., Falb, J., Kaindl, H., Kavaldjian, S., Popp, R., Horacek, H., Arnautovic, E., Szep, A.: Generating an abstract user interface from a discourse model inspired by human communication. In: Proceedings of the 41th Annual Hawaii International Conference on System Sciences (HICSS-41), Piscataway, NJ, USA, IEEE Computer Society Press, Los Alamitos (2008) 5

http://www.mozilla.org/projects/xul/

88

S. Kavaldjian et al.

2. Botterweck, G.: A model-driven approach to the engineering of multiple user interfaces. In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, Springer, Heidelberg (2006) 3. Calvary, G., Coutaz, J., Thevenin, D., Limbourg, Q., Bouillon, L., Vanderdonckt, J.: A unifying reference framework for multi-target user interfaces. Interacting With Computers 15/3, 289–308 (2003) 4. den Bergh, J.V., Coninx, K.: From task to dialog model in the UML. In: Winckler, M., Johnson, H., Palanque, P. (eds.) TAMODIA 2007. LNCS, vol. 4849, pp. 98–111. Springer, Heidelberg (2007) 5. Falb, J., Kaindl, H., Horacek, H., Bogdan, C., Popp, R., Arnautovic, E.: A discourse model for interaction design based on theories of human communication. In: CHI 2006 extended abstracts on Human factors in computing systems CHI 2006 (2006) 6. Falb, J., Popp, R., R¨ ock, T., Jelinek, H., Arnautovic, E., Kaindl, H.: Using communicative acts in interaction design specifications for automated synthesis of user interfaces. In: Proceedings of the 21th IEEE/ACM International Conference on Automated Software Engineering (ASE 2006), Piscataway, NJ, USA, pp. 261–264. IEEE Computer Society Press, Los Alamitos (2006) 7. Falb, J., Popp, R., R¨ ock, T., Jelinek, H., Arnautovic, E., Kaindl, H.: Fullyautomatic generation of user interfaces for multiple devices from a high-level model based on communicative acts. In: Proceedings of the 40th Annual Hawaii International Conference on System Sciences (HICSS-40), Piscataway, NJ, USA, January 2007, IEEE Computer Society Press, Los Alamitos (2007) 8. Florins, M., Simarro, F.M., Vanderdonckt, J., Michotte, B., Michotto, B.: Splitting rules for graceful degradation of user interfaces. In: AVI 2006: Proceedings of the working conference on Advanced visual interfaces, pp. 59–66. ACM Press, New York (2006) 9. Luff, P., Gilbert, N., Frohlich, D.: Computers and Conversation. Academic Press, London (1990) 10. Mann, W.C., Thompson, S.: Rhetorical Structure Theory: Toward a functional theory of text organization. In: Text, pp. 243–281 (1988) 11. Mori, G., Paterno, F., Santoro, C.: Design and development of multidevice user interfaces through multiple logical descriptions. IEEE Transactions on Software Engineering 30(8), 507–520 (2004) 12. Roberts, D., Berry, D., Isensee, S., Mullaly, J.: Developing software using OVID. IEEE Software 14(4), 51–57 (1997) 13. Searle, J.R.: Speech Acts: An Essay in the Philosophy of Language. Cambridge University Press, Cambridge (1969) 14. van Harmelen, M.: Object oriented modelling and specification for user interface design. In: Interactive Systems: Design, Specification and Verification (1994)

Second International Workshop on Model Size Metrics Michel Chaudron1,2 and Christian F.J. Lange1 1

Technische Universiteit Eindhoven, PO Box 513, 5600 MB Eindhoven, The Netherlands 2 Leiden Institute of Advanced Computer Science, Leiden University, The Netherlands [email protected], [email protected]

Abstract. This paper reports on the Model Size Metrics (MSM) workshop held as satellite event of the MODELS 2007 conference. The focus of the workshop is to develop metrics for use in model-centric software development. As a starting point for discussion we focused on size. The workshop aim was to bring together researchers in this area, share experiences and discuss future directions. This paper summarizes the presentations that were given and the highlights of the discussion that followed and summarizes open issues for future work. Keywords: Models, Metrics, Size, Model-driven architecture (MDA), UML.

1 Introduction A standardized method for determining sizing concepts for software models that allows the effective base lining and comparison of model concepts is a crucial need within the MODELS community. Such metrics enable the effective estimation and quality management of model development. Additionally measuring the model size is important to provide context information for empirical studies using models. One of the most commonly used measures of source code program size is the source lines of code (SLOC) metric. However, the concept of lines of code does not readily apply to modeling languages such as UML and SDL. Furthermore, software models are heterogeneous in nature (consisting of several different types of diagrams), can exist at varying levels of abstraction and can be created using different modeling styles. As a result, researchers face many challenges when trying to define the size of a software model. The first workshop on this topic was held in 2006 [1]. 1.1 Presentations The workshop received eight submissions. From these submissions four papers were selected for presentation at the workshop. The workshop was attended by a mix of practitioners and researchers. During the workshop ample time was spent on discussions. The papers presented are listed below. Out of these four, two papers were selected for inclusion in these proceedings (papers no. 2 and no. 3). H. Giese (Ed.): MoDELS 2007 Workshops, LNCS 5002, pp. 89–92, 2008. © Springer-Verlag Berlin Heidelberg 2008

90

M. Chaudron and C.F.J. Lange

1. 2. 3.

4.

Counts count by M. Monperrus, J. Champeau, B. Hoeltzener (ENSIETA, Brest, France) Measuring the Level of Abstraction and Detail of Models in the context of MDD by Jens von Pilgrim (FernUniversität in Hagen, Germany) On the Relation between Class Count and Modelling Effort by Ariadi Nugruho (Leiden University, Netherlands), Christian Lange (Technische Universiteit Eindhoven, Netherlands) Effort distribution in model based development by Werner Heijstek (Leiden University, Netherlands) and Michel Chaudron (Technische Universiteit Eindhoven and Leiden University, Netherlands)

The first paper was presented by Monperrus. He argued that basic count metrics, such as ‘number of classes’, are undervalued in current research on metrics for models. He proposed several arguments in support of this statement: • • • •

Count metrics are needed for defining more complex metrics More elaborate metrics do not necessarily guarantee better results Count metrics are adopted in industrial practice Counting is a fully fledged modeling goal

The paper goes on to discuss what types of entities of a model should be counted and lists several requirements for the definition and automation of measures for counting. The second presentation was by Von Pilgrim who discussed his approach for measuring ‘level of abstraction’ and ‘level of detail’ in order to assess efficiency of transformation chains in model-driven development. The notion of efficiency that is proposed is the amount of work that is needed for updating the models if the platform changes. Von Pilgrim bases his approach on “General Model Theory” by Stachowiak [2] and works towards defining a syntactic size and a semantic size of a model. The ratio between these is an indicator for the level of abstraction. Even though the approach cannot provide absolute numbers on level of abstraction, it is possible to use these metrics for relative comparison of models. The third presentation, by Lange, explored the existence of a relation between the number of classes as a size measure of a model and the effort required for constructing a model. The data is based on two controlled experiments: in both experiments M.Sc.-level students are asked to design a UML model of a system given a description of the requirements. The first finding is that there is a large variation in the size of the models that is produced by different students for the same system. The second finding is that no significant correlation was found between the size of a model and the effort spent on constructing the model. This suggests that the number of classes is not a good predictor for the amount of effort needed for constructing a model. The differing number of classes may be explained by the following factors: •

•

Models may be used for different purposes like understanding what needs to be built, or detailed description for the implementation. For such different purposes, designers target different levels of abstraction, completeness and detail. Different designers have different styles in modeling: some focus on representing the required functionality, others on the architectural structure.

Second International Workshop on Model Size Metrics

• •

91

Disproportion: Complex parts of a system are described in more detail than ‘easy’ parts. Experience: Experienced engineers create models with more classes than novice engineers.

The fourth paper, presented by Chaudron, discussed the ratio of effort spent on modeling compared to the effort spent on other disciplined in RUP-based software development projects. Also, it studied the distribution of effort over the RUP disciplines over time. This presentation included graphs that were based on around 20 RUP-based projects. One finding that was considered surprising given the prominent role of UML in RUP projects was that only a small amount of time was spent on modeling. Another finding was that the trend in the ‘RUP Humps’ picture is quite realistic, but in practice effort distribution has much more spikes. Summarizing, the workshop raised more questions than answers. This indicates that this is an emerging field with opportunities for research and empirical studies. There will not be one universal notion of size in model-based development. The large variation in uses and purposes of models requires that more context information (such as constraints, assumptions) need to be taken into account when defining size measures for models. One particular factor that was identified in the discussions was to relate size to the level of abstraction of a model. This raises the issue of how to characterize the level of abstraction of a model. Another parameter that was considered to be of influence on the size of the model is the target level of quality. This may influence completeness of the model. Based on the experience of the workshop participants, the choice of what to model and what not to model is influenced by factors such as domain knowledge, complexity of subsystem, criticality/risk of subsystem. In general, such factors should be taken into account when investigating how model-size is related to other quantities such as requirements size and implementation size, as well as for quality and productivity measurement.

2 Issues Identified for Future Work and Future Workshops We list some of the issues identified in the workshop as directions of collaboration and future work: • • • •

How to measure the level of abstraction of models Empirical studies in general and in particular: Case studies on the use of model size metrics (measurement of size throughout development, size measurement in estimation; metrics driven process improvement) One of the main difficulties in empirical studies remains obtaining access to industrial UML models and related data such as associated implementation, effort, defects. Hence collecting and sharing of UML models and case study data. One suggestion to ease the sharing of data was to develop an ‘anonymization tool’ that transforms names of entities in a model such that the model can not be traced back to the organization from which it originates. However, in order to allow interesting analyses of a model it would be desirable that such an anonymization tool would maintain some properties of names of entities such as:

92

M. Chaudron and C.F.J. Lange

• • •

names of patterns identical subterms in the names of different entities characteristical metrics properties

It was observed that no UML models have been found in the open source community. 2.1 Future Workshops The workshop ended with a discussion on the future of MSM. There was consensus that the scope of the workshop should be broadened, such that it would also include some context that would give a purpose for interpreting metrics, such as: Economics of Modeling, Estimation and Measurement.

References 1. Weil, F., Neczwid, A.: Summary of the 2006 Model Size Metrics Workshop. In: Kühne, T. (ed.) MoDELS 2006. LNCS, vol. 4364, pp. 205–210. Springer, Heidelberg (2007) 2. Stachowiak, H.: Allemeine Modelltheorie. Springer, Wien (1973)

On the Relation between Class-Count and Modeling Effort Ariadi Nugroho1 and Christian F.J. Lange2 1

LIACS – Leiden University, Niels Bohrweg 1, 2333 CA Leiden, The Netherlands 2 Technische Universiteit Eindhoven, P.O. Box 513, 5600 MB Eindhoven, The Netherlands [email protected], [email protected] http://www.liacs.nl/∼ anugroho http://www.tue.nl/∼ clange

Abstract. The knowledge of size of models can be very useful to perform many kinds of estimations such as effort, cost, and productivity in software development. However, to the best of our knowledge there is no universally accepted model size measure available to date. In this paper we investigate the usefulness of class-count as a size measure of models (represented with the UML). Using empirical data collected from two student experiments we validate this measure by assessing its correlation with effort spent in modeling. The results show that merely using classcount might not provide sufficient and accurate estimation of modeling effort. Furthermore, we identify some factors that hinder class-count as a good estimate of modeling effort. Keywords: UML, Model Size, Modeling Effort, Experiment.

1

Introduction

The size of a system has long been considered as an important attribute for measurement practice in software engineering. The most popular size measure of a system might be the SLOC (Source Lines of Code) that is still used in many measurement activities nowadays. By knowing the size of a system software engineers or project managers can calculate many other attributes related to the system or project such as productivity. As an example, a programmer’s productivity can be measured from the number of lines of code he writes per day. However, the SLOC measure has been criticized as a measure of productivity, because it encourages a verbose style of programming. Another interesting use of size measure is its application to determine modules’ or components’ error proneness. For instance, some believed that there is an optimal size of a system’s modules or components – the ‘Goldilocks Conjecture’. It is believed that when a module’s or a component’s size is below or above the optimal size it will be more prone to error [1]. Although many computer scientists object to this hypothesis, yet this shows how size measure is very easy to use – and misused – in measurement practices. H. Giese (Ed.): MoDELS 2007 Workshops, LNCS 5002, pp. 93–104, 2008. c Springer-Verlag Berlin Heidelberg 2008 

94

A. Nugroho and C.F.J. Lange

With the emergence of model-driven software development, measurements are no longer solely applied to source code. As a model of a system is generally expected to be realized in the actual system, measuring the models of a system might give important information about some attributes of the actual system. This non-conventional measurement approach has the advantage of better prediction, prevention, and control over the quality of the system since the early stages of software development. In the UML, class diagrams are used to depict the static structure of a system. In describing the dynamic behaviors of the system, each class will be represented by one or more instantiations that interact with instantiations of other classes in sequence diagrams or collaboration diagrams. The main motivation of using class-count as an estimate of modeling effort lies in the assumption that there is a relation between the way the structure and the behaviour of a system are modelled. Hence, we presume that this will subsequently influence the effort required in the modeling activity. Additionally, the choice of using class-count as a measure was also due to the frequent usage of class diagrams in practice. A recent survey reported in [2] revealed that class diagram, use case diagram, and sequence diagram were ranked as the three mostly used UML diagram types. Having these factors in mind, in this paper we explore the usefulness of class-count as an estimate of modeling effort. In a controlled experiment with students we investigated the relation between class-count and the effort spent in modeling. This paper is organized as follows. In Section 2 we provide some related work in this research area. Section 3 describes the experiments and how they were conducted. In Section 4 we discuss the results of the experiments and finally conclusions and future work are provided in Section 5.

2

Related Work

Effort estimation is an important activity in software development projects. The ability to estimate the effort required in developing a system will help project managers to plan, monitor, and assess the productivity of a software development process. However, effort estimation is no simple task. When it comes to accurate effort estimations, experience shows that even an average of 32% estimation error rate can be considered outstanding [3]. Furthermore, the use of Function Points in [3] to solve estimation problems in fact resulted in an average of 100% estimation error rate. Most methods of effort estimation require an estimate of the size of software systems [4], which imply that accurately estimating the size of a system is extremely important. In this respect, many studies have been done to develop size estimates of software. Many of the previous studies on software size estimation were mainly based on the notion of Function Points (FPs) [5]. In [4] and [6] the size estimation of object-oriented systems was performed by mapping some object-oriented concepts into function point concepts. From this mapping an estimation of the system size is then calculated. Other similar approaches can be seen in [7] and [8].

On the Relation between Class-Count and Modeling Effort

95

More recent work on system size estimation can be found in [9]. An approach called Class Point approach was proposed to estimate system-level size. The Class Point approach combines OO measures, which take into account specific aspects of each class such as complexity. This work is different from the above-mentioned studies in that we focus on size estimate of software models (as represented with UML). Furthermore, we limit our attention to class-count in UML models and investigate its relation with the effort spent in modeling. In this paper we also underline some important issues with respect to the use of class-count as a basis of model size measurements.

3

Empirical Data

The empirical data used in this paper originates from student experiments conducted at the TU/e (Technische Universiteit Eindhoven). The recent experiment, hereafter referred to as Experiment A, involved 12 post-master students who have sufficient knowledge and experience in system specification and design. Of the 12 participants, seven participants had one or two UML courses in the past and five participants hold UML certifications. Nevertheless, only two students have industrial experience with UML. Although the participants seem to have moderate industrial experience with UML, their knowledge and current education/training focus have made them eligible for participating in the experiment. In Experiment A we asked the participants to develop a UML model of a Car Navigation System based on a written requirement specification. This requirement specification was high level and was given on one page of A4 (the materials can be found in [10]). Given this requirement specification, each participant was given four hours to create a UML model of the system using Rational Rose RealTime 7. Hence, the delivered models are based on the same set of requirements and the same amount of effort was spent during their creation. We are interested to find out whether the size in terms of class-count is similar for these models, given that the we controlled the aforementioned context factors. The results and the analysis are discussed in Section 4. In addition to the main findings obtained from Experiment A, we also provide supporting findings from a student experiment discussed in [11] – hereafter referred to as Experiment B. The experiment was quite similar in that it also asked 35 teams of three master students (in total 106 students participated) to develop UML models based on certain requirements. Experiment B was originally conducted to investigate the influence of modeling conventions on (syntactic) model quality and modeling effort. To this aim three treatments were applied in creating the UML models, namely: no modeling conventions, with modeling conventions, and tool-supported modeling conventions. In this experiment we use the delivered models for analyzing the relationship between modeling effort and size. The experiment materials are available in [12].

96

4

A. Nugroho and C.F.J. Lange

Is There a Correlation between Class-Count and Modeling Effort?

In this section we discuss whether there is a correlation between class-count and the effort spent in modeling. However, we must note a few points with regard to the resulting classes in Experiment A and B. First, we found that the resulting classes are in a high level of abstraction. The classes represent key abstractions of the system and they are technology-independent — as such we found no framework classes being modeled. Second, the level of abstraction used also implies that the models are non-executable. We should keep these as a context in understanding the findings discussed in the rest of this paper. 4.1

Class-Count Varies Across Models

The result from Experiment A, as shown in Figure 1, shows that in the given time limit (4 hours) the participants delivered models with a varying size. The class-count varied from 7 up to 23. We can also see that most of the models created have between 11 and 16 classes. There were two participants that created seven classes and only one participant that created 23 classes. The median of the class-count is 13. The variability of the class-count reveals that although the same requirements, time, and tool were provided to the participants, the resulting models were quite varied in size. One explanation behind this result might be that there are other confounding factors that influence class-count – thus requirement, time, and tool support may only explain the variability of class-count to some degree. In the next section we explore whether there is a correlation between class-count and modeling effort.

Fig. 1. Frequency distribution of class-count across models

On the Relation between Class-Count and Modeling Effort

4.2

97

No Significant Correlation Is Found

To clarify the result discussed previously, we perform a correlation analysis between class-count and the effort spent in modeling from the data set of Experiment B. However, since in the experiment there were treatments applied to three groups of the participants, we first had to make sure that the treatments had no effects on the variables we want to assess – that is, class-count and the time spent on modeling. To this aim we performed independent t-tests for the two variables amongst the three different groups. The result confirmed that one of the treatments, i.e., tool-supported modeling conventions, had significant effects on the time spent on modeling. Thus we must exclude the teams that received this treatment before continuing with the correlation analysis. Additionally, we omitted two influential outliers from the data, which might affect the results of the analysis.

Fig. 2. Scatter plot showing the relation between class-count and effort in modeling

The scatter plot in Figure 2 shows the correlation between class-count and the time spent in modeling (in person hours). It shows that the data points are relatively dispersed, which might indicate the absence of significant trend between both variables. Since the assumption of normality in the data is rejected, we performed Spearman correlation analysis between class-count and modeling effort. The result of the analysis is shown in Table 1. The spearman’s correlation coefficient in Table 1 shows that there’s no significant correlation between Class-count and the effort spent in modeling. As suggested in [13], with 22 participants a significant correlation at p < 0.05 is obtained when the correlation coefficient equals to 0.422. The correlation analysis has revealed that there is no significant correlation between class-count in a model and the effort spent in creating the model. To get the explanations of this phenomenon, we performed deeper analysis on the

98

A. Nugroho and C.F.J. Lange

Table 1. Spearman correlation coefficient between class-count and the effort spent in modeling Effort(hours) Class-count Significance (2-tailed)

.302 .171

UML models (especially the class diagrams). The result of the analysis has led us to believe that the main explanation of the absence of significant correlation between class-count and modeling effort is because class-count is not an accurate measure of model size. In particular this is due to the fact that many factors can influence class-count in a model. In the following section we discuss those factors further.

5

Why Class-Count Is Not a Good Estimate of Modeling Effort?

The main finding discussed in the previous section has shown that there is no significant correlation between the number of classes in a model and the effort spent in modeling. In this section we discuss the phenomenon based on deeper analysis of the data from Experiment A. 5.1

Designer’s Approaches in Modeling

Deeper analysis of the class diagrams reveals that the participants’ approaches in modeling might have strong influence on the resulting class diagrams. By analyzing the number of classes, attributes, and methods we can categorize the models into three categories, namely: 1) functionality-driven; 2) architecturedriven; and 3) a combination of both. The characteristics of these categories are described as follows. – The participants with the functionality-driven approach tend to focus on the required functionality in creating classes. This type of participants generally creates only a few classes, but with complete role and functionality assigned to the classes (i.e., in terms of class attributes and methods). As a result, the classes are low in number, but have many attributes and methods defined. – The participants with the architecture-driven approach tend to focus on architectural considerations in developing classes. The structure of the classes is given high importance to gain some benefits such as reusability and maintainability. Participants with this type of interest generally do not specify all class functionality explicitly. Thus, the number of class attributes and class operations created are relatively low. – The participants that have both concerns in mind tend to focus on both functionality and architectural aspects of the classes. As a result, the number of classes, class attributes, and class operations are generally high.

On the Relation between Class-Count and Modeling Effort

99

Fig. 3. Scatter plot showing the relation of class-count with method-count and attribute-count

The above points show that designers may have different approaches in modeling classes. In this respect, we have witnessed that different approaches tend to result in different number of classes, attributes, and methods in the models. The scatter plot in Figure 3 visualizes the relation of class-count with methodcount and attribute-count of UML models in Experiment A. The diamonds and squares represent attribute-count and method-count, respectively. The upper regression line fits the method-count data points while the regression line underneath fits the attribute-count. We can see that the results, although not statistically significant (with these data points, class-count only contributes six percent and five percent to the variability of method-count and attribute-count respectively) support the trend we have discussed previously. Nevertheless, this is an indication that class-count in models may vary depending on the designer’s approach in modeling. 5.2

The Level of Abstraction Used in Modeling

The level of abstraction in modeling is generally related to the distance of the created models from the actual implementation. Models with a high level of abstraction only specify a system in a ballpark view. In this level of abstraction many details are omitted because they might not be relevant to the main concerns in the current level of abstraction. On the other hand, models with a low level of abstraction have a very close similarity to the intended implementation. As a consequence model with low level of abstraction are generally large and very detailed. Nevertheless, depending on the situation designers can apply more than one level of abstraction in their models. The notion of level of abstraction in modeling as discussed above adds to the difficulty in using class-count as a size measure. As we have mentioned above, designers can use different levels of abstraction in modeling the same system –

100

A. Nugroho and C.F.J. Lange

not to mention the fact that they can also switch from one level of abstraction to another. This has become the main hurdle of using class-count as a measure of size because we simply cannot compare attributes of models that have different levels of abstraction. Models with higher levels of abstraction have fewer classes than those with lower levels of abstraction. From the class diagrams created in Experiment A we did not see the use of different levels of abstraction. Most of the diagrams can be categorized as analysis models – they address only the key elements of the system. Nevertheless, although the same level of abstraction was used in the modeling, the level of detail used may be different – the next section discusses this notion of level of detail in modeling. 5.3

The Practice of Proportion in Modeling

We define proportion in modeling as the use of details in models that is proportional to certain aspects of a system such as complexity or importance of components. When designers model a system regardless of this consideration they generally tend to model all parts of a system at an equal level of detail – hence being disproportionate in modeling. However, practices in the industry reveal that this has seldom been the case [14]. Figure 4 shows how the drive of being simplistic, the drive of being comprehensive, and time constraint influence designer’s decisions in modeling. We have learnt from a case study conducted in the industry that designers generally try to develop models as simple as possible [15]. In order to keep the model simple, designers must make decisions concerning which parts of the system need to be modeled or which parts of the system need greater details. When simplicity is opted, designers will generally focus on modeling system components that are important or complex. For these types of components more detail might be applicable. However, the readers of the models (e.g., programmer, client, etc.) might request more comprehensive models. Thus, in the end designers must take into account all these factors so that models with appropriate level of detail can be delivered.

Fig. 4. The factors behind proportion in modeling

On the Relation between Class-Count and Modeling Effort

101

It must be clear at this point that the notion of proportion in modeling also hinders the validity of class-count as a measure of model size. The main argument is that class-count does not take into account the properties of each class such as attributes and operations, which reflect the level of detail used in modeling the classes. Hence, although two models with 100 classes are identical in terms of class-count, they might require different effort in the modeling process because they have different levels of detail. The data presented in Figure 5 illustrates the situation. We took a sample of 12 class diagrams created in Experiment B, which have class-count ranging from 30 to 38. Although the class-counts are quite similar, the class attributes and methods can be quite varied in number. This phenomenon can also be observed from the result of Experiment A as presented in Figure 3. However, please also note that here we do not see the trend as discussed previously in Section 5.1, which might due to the fact that there was no time-limit applied in Experiment B.

Fig. 5. Method-count and attribute-count amongst models with similar class-count

5.4

Designer’s Knowledge and Experience

We investigated whether the participant’s expertise affects class-count in the models. To this aim we perform another correlation analysis between the participants’ knowledge background and experiences. We use the data obtained from the participant characterization questionnaire in Experiment A. In the questionnaire we asked a couple of multiple-answer questions related to participants’ knowledge and experience in the following areas: – – – –

Object oriented design Object-oriented programming UML Different UML diagram types (i.e., use case, class, and sequence diagram)

102

A. Nugroho and C.F.J. Lange

Fig. 6. Scatter plot showing the relation between participant’s background scores and class-count

For each question, a higher point indicates higher knowledge/experience in a particular area. Figure 6 shows the scatter plot of the relation between the participants’ total score and class-count in the models. Please note that there are only 11, instead of 12, data points shown in the scatter plot. This is simply because there are two identical data points. Further analysis with spearman’s correlation analysis reveals the correlation as shown in Table 2. Please note that we also use spearman’s correlation analysis because the assumption of normality of the data is rejected. The result in Table 2 shows that there is a positive correlation between the participant’s knowledge/experience score and class-count in the models. This correlation might indicate that the participants with higher scores of knowledge/experience in the aforementioned areas tend to create more classes than those with lower scores. This result actually raises another interesting question: why do the participants with better knowledge/experience tend to produce more classes? Is it because the knowledge and experience make them more productive? Or is it because the knowledge and experience make them aware of some ‘best practices’ in modeling, which result in better structured class diagrams (often also means more classes)? Answering these questions would require further analysis of the UML models and is beyond the scope of this paper. Table 2. Spearman correlation coefficient between participant’s knowledge/experience and class-count Participant background score Class-count Significance * indicates correlation significant at 0.05 level (2-tailed)

.580* .048

On the Relation between Class-Count and Modeling Effort

103

Please also note that the productivity of an individual participant can be influenced by many factors including knowledge and experience in modeling. In this respect, we assumed that the influence of other factors might not be significant, hence we did not take further measures to control other factors that might have influence on individual productivity in modeling.

6

Conclusions and Future Directions

In this paper we investigated the relation between the number of classes (classcount) in models and the effort (time) spent in modeling. The analysis of empirical data leads to the conclusion that there is no significant relation between class-count in models and the effort spent in modeling. We conclude that the main reason behind this is because class-count is not a good measure of model size, which is mainly due to the fact that different factors have influence on class-count in a model. In this respect we identified the following influential factors: – – – –

Designers’ approaches in modeling The level of abstraction used in modeling The practice of proportion in modeling Designer’s knowledge and experience

Additionally, from an analysis of the class diagrams we found an interesting observation with respect to designers’ approaches in modeling. We identified the following approaches: 1) Architecture-driven; 2) Functionality-driven; 3) An approach that put emphasis on both architectural and functional aspects. These approaches seemed to have influence not only on class-count in the models, but also on the number of class attributes and methods. Based on the exploratory observations of this study, we propose directions for future work to provide a better understanding of measuring model size. Future work should address the relation between the structural view and other views. Additionally, the factors that potentially influence the model size that were identified in this paper should be addressed in more specific studies.

Acknowledgments This work is accomplished under the Finesse project which is funded by the STW (Stichting Technische Wetenschappen), the Netherlands. We also like to thank the students of TU/e who have participated in the experiments.

References 1. Emam, K.E., Benlarbi, S., Goel, N., Melo, W., Lounis, H., Rai, S.N.: The optimal class size for object-oriented software. IEEE Trans. Softw. Eng. 28(5), 494–509 (2002) 2. Dobing, B., Parsons, J.: How UML is used. Communications of the ACM 49(5), 109–113 (2006)

104

A. Nugroho and C.F.J. Lange

3. Vicinanza, S.S., Mukhopadhyay, T., Prietula, M.J.: Software-effort estimation: An exploratory study of expert performance. Information Systems Research 2(4), 243– 262 (1991) 4. Caldiera, G., Antoniol, G., Fiutem, R., Lokan, C.: Definition and experimental evaluation of function points for object-oriented systems. In: METRICS 1998: Proceedings of the 5th International Symposium on Software Metrics, Washington, DC, USA, p. 167. IEEE Computer Society, Los Alamitos (1998) 5. Albrecht, A.: Measuring application development productivity. In: Press, I.B.M. (ed.) IBM Application Development Symp., October 1979, pp. 83–92 (1979) 6. Fetcke, T., Abran, A., Nguyen, T.H.: Mapping the OO-Jacobson approach into function point analysis. In: TOOLS 1997: Proceedings of the Tools-23: Technology of Object-Oriented Languages and Systems, Washington, DC, USA, p. 192. IEEE Computer Society, Los Alamitos (1997) 7. Whitmire, S.A.: An introduction to 3D function points. Softw. Dev. 3(4), 43–53 (1995) 8. Minkiewicz, A.: Measuring object oriented software with predictive object points. In: Applications in Software Measurements (ASM 1997) (1997) 9. Costagliola, G., Ferrucci, F., Tortora, G., Vitiello, G.: Class point: an approach for the size estimation of object-oriented systems. Software Engineering, IEEE Transactions 31(1), 52–74 (2005) 10. Nugroho, A.: Experiment materials, http://www.liacs.nl/∼ anugroho 11. Lange, C.F.J., DuBois, B., Chaudron, M.R.V., Demeyer, S.: An experimental investigation of uml modeling conventions. In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 27–41. Springer, Heidelberg (2006) 12. Lange, C.F.J.: Experiment replication package, http://www.tue.nl/∼ clange 13. T.C.U. of Hongkong: Minimum significant correlation coefficient r for a sample size, Hongkong, http://department.obg.cuhk.edu.hk/researchsupport 14. Lange, C.F.J., Chaudron, M.R.V., Muskens, J.: In practice: UML software architecture and design description. IEEE Softw. 23(2), 40–46 (2006) 15. Nugroho, A., Chaudron, M.R.V.: Managing the quality of uml models in practice. In: Rech, J., Bunse, C. (eds.) Model-Driven Software Development: Integrating Quality Assurance, Idea Group Inc. (to appear, 2008)

Measuring the Level of Abstraction and Detail of Models in the Context of MDD Jens von Pilgrim FernUniversit¨ at in Hagen, 58084 Hagen, Germany [email protected]

Abstract. In model driven development (MDD), models are transformed automatically into other models. This leads to transformation chains. The goal of MDD is to set up efficient transformation chains, i.e. adding semantics first and platform detail later. When the platform is changed, only the later, platform specific models have to be replaced. This paper constructs metrics for measuring and comparing the models obtained through transformations in MDD processes, in order to help to set up the more efficient transformation chains.

1

Introduction

In model driven development (MDD), models are transformed automatically into other models and code. This leads to transformation chains, in which the models are connected via transformations. Usually, abstract (and platform independent) models are used to define the system’s semantics. These abstract models are then transformed automatically to more concrete (and platform specific) models, in which platform detail is added as required. Finally, code is generated from these concrete models. If the platform is changed, only platform specific models have to be redefined while the first, more abstract models can be reused. This leads to a higher productivity compared to manual coding if the transformation chain is configured well. That is, we have to ensure that semantics is added first and platform detail later. As suggested by the Goal Question Metrics approach (GQM, [1]), we define a goal. Goal: Set up or improve an efficient transformation chain. Here “efficient” means that semantics is defined in early, abstract models, while platform detail is added later in more concrete, platform specific models. Figure 1 illustrates this goal. The figure is taken from [4] and slightly modified. The whole issue is also discussed in [6] which also contains a very similar figure [6, p. 32]. The arrows labeled “manually” and “automatically” are introduced in section 3. 1 1

Unlike the figures in [4,6] the y axis is reversed in order to visualize the raised level of abstraction.

H. Giese (Ed.): MoDELS 2007 Workshops, LNCS 5002, pp. 105–114, 2008. c Springer-Verlag Berlin Heidelberg 2008 

106

J. von Pilgrim Abstraction

manually

Transformation Chain B b Transformation Chain A

a x

Platform Detail

automatically

Fig. 1. Transformation chains, adapted from [4]

The figure shows two transformation chains (A and B). The x axis indicates the platform detail (in [4], the term “metamodel” is used), the y axis the abstraction. That is, abstract and platform independent models are located top left, while concrete and platform specific models are located bottom right. If the platform is changed (indicated with the vertical line at x, i.e. models at the right side of this line have to be ported to a new platform), we can observe that transformation chain A is more efficient than chain B, since in case of chain A only a very small amount of semantics has to be added (a), while in case of chain B much more semantics has to be added again (b). The goal is to define transformation chains such as A. We can now pose some questions in order to refine the goal. This paper tries to develop metrics for answering the following questions. Questions Is a model M1 more abstract than model M2 ? Does model M1 contain more platform details than model M2 ? Do we define most of the semantics in early models? Where do we define most of the platform detail? This paper is organized as follows. In the next section, we will introduce different definitions of model. We then develop metrics in order to answer our questions in section 3. Section 4 proposes an additional transformation before actually measuring a model, which is implicitly used in section 5 which presents a sample to illustrate the calculation of the proposed metrics. Section 6 describes related work, followed by the conclusion and directions for future work in the last section.

2

Model Definitions

What is a model? Models can be defined as mathematical structures. Since this definition is too general to work with, models are defined here as graphs G = (V, E) with vertices V and edges E or labeled graphs G = (V, E, l) with labels l. In MDD, these graphs have to be valid according to a meta model, that is

Measuring the Level of Abstraction and Detail of Models

107

the elements of the graph are associated to elements of the meta model. A formal definition of models as graphs according to meta models can be found in [2]. In his “General Model Theory”[8] Stachowiak defines models using three features: Mapping feature: A model is always a model of some original, in which the original can be a model itself. Reduction feature: A model does not reflect all attributes of the original. Pragmatic feature: Models are assigned to an original by some subject (human or machine). While defining a model as a graph specifies the syntax of the model, Stachowiak’s features define the semantics. We combine both definitions by introducing an interpretation working on “attributes”. We use the term “attribute” here in a very abstract way, they are defined as pure semantics here. But, semantics cannot be expressed without symbols. So we use the interpretation to express attributes by elements of the graph. Definition 1. Attributes and Graphs of a Model An interpretation I : V ∪ E → A of a model is a mapping of vertices V and edges E to attributes A, such that for all attributes α ∈ A Vα ∪ Eα → α, (Vα ∪ Eα )\{x} → / α ∀x ∈ Vα ∪ Eα in which Vα ⊆ V, Eα ⊆ E. In the following, for a model Mk we write Ak to refer to its attributes. Definition 1 maps minimal subsets of nodes and vertices to attributes, that is no element of Vα ∪ Eα must be removed. The “original” in Stachowiak’s first feature can be a model itself. In a transformation chain, this feature is transitive, i.e. if M1 is a model of M2 , and M2 is a model of M3 , then M1 is also a model of M3 . Eventually all models of a transformation chain are models of the system under construction. How does a subject assign a model to an original – in MDD this is done by automatic transformations. Stachowiak introduces a function called “icostructural image”. This function maps subsets of the orignal attributes to subsets of the model attributes.2

3

Metrics

For answering our questions, we are interested in abstraction and (platform) detail. The first metric we define here is the semantic size of a model. We define 2

Since we defined attributes differently to Stachowiak, here this assignment is a function mapping graph elements to attributes; still a subject has to interpret a model, that is define subsets of the graph elements representing an attribute.

108

J. von Pilgrim

this metric simply as the cardinality of the attribute set. While the graph reflects certain properties defined by the metamodel, attributes were defined as “pure” semantics. For example an UML association between two classes requires the two classes, the association, and – this is usually not visible in diagrams – several properties “gluing” these parts together. This “structural glue” is not present in the attribute set. We will use this first metric as an indicator for the abstraction level of a model. Definition 2. [Semantic Size of a Model] The semantic size of a model M is defined here as the number of its attributes A, i.e. sem(M ) = |A| For sem(M1 ) we also write sem1 or |A1 |. The second metric defined is simply the size of the graph. Since the graph contains the “structural glue”, we not only count the semantics when counting the nodes and edges of a graph, but the (platform) detail, too. We use this second metric for measuring the platform detail of a model. Definition 3. [Size of a Model] The size of a model M is defined here as the sum of the vertices of the model graph, its edges and the graph itself. That is size(M ) = |V | + |E| + 1 in which V and E are the vertices and edges of the graph of the model. For size(M1) we also write size1 . We add 1 to the number of vertices and edges in order to count the graph itself. Besides, we use this formula later as a denominator in a fraction and this way we avoid division by zero problems. In a first approach we state that a model M1 is more abstract than a model M2 , if it omits more attributes, i.e. if it defines less attributes. We can also say that a model M1 contains less platform detail than a model M2 , if it contains less “structural glue”, i.e. if less graph elements represent the attributes expressed by the model. It is almost impossible to actually define the attributes, at least it requires additional effort. In order to develop a metric, we need to use the data present in the models and the transformation chain. So we have a closer look at transformations. A model transformation transforms a model M1 into a model M2 . We expect a transformation to preserve semantics. In [10], Steimann proposes the following consideration: An automatic transformation preserves semantics or it adds semantics.3 If it adds semantics, it must do this randomly, since otherwise adding new semantics would be based on information found in the model which leads to preserving semantics. Usually we do not want a transformation to add semantics randomly, thus we assume here that a transformation preserves semantics. According to figure 1 this means 3

The case of reducing semantics should not be considered here.

Measuring the Level of Abstraction and Detail of Models

109

that a transformation can “move” a model only horizontal; semantics can only be added manually. This is indicated by the two arrows in figure 1. As a matter of fact, a completely different point of view can be taken, too. We can also state that it is the transformation which adds semantics, and a model itself does not contain any semantics (this position can be found for example in [9]). If we take this position, which is of course reasonable, we can only measure syntactical properties of a model without a transformation. How can we solve this issue? The answer is already given here by definition 1. An “interpretation” is a special kind of transformation, and it is used here as an transformation mapping syntactical elements to semantics. Then, a transformation in a transformation chain cannot add semantics. Figure 2 illustrates this process using a commutative diagram. It shows a transformation chain (with models M1 to Mn ) and their interpretations. t

t

tn−1

M1 −−−1−→ M2 −−−2−→ . . . −−−−→ Mn



interpretation





A1 −−−−→ A2 −−−−→ . . . −−−−→ An Fig. 2. Transformation and Interpretation

It is important to note that “attributes” and the attribute sets A cannot be defined explicitly. They are used here as a theoretical construct for distinguishing between platform and the semantics. We now use a simple transformation chain for the following considerations. To distinguish between automatic transformations and manual editing, we write “→” for transformation and “;” for manual enrichment. Let a model M1 be automatically transformed into a model M2 . According to the first model definition, the models are graphs, i.e. G1 = (V1 , E1 ) and G2 = (V2 , E2 ). But these models also represents attribute sets A1 and A2 . If model M1 is automatically transformed to model M2 , no additional attributes could have been added by the transformation. If the transformation preserves semantics (what we assume here), after the transformation A1 = A2 must be true. During the development process, model M2 is enriched manually, i.e. M2 ; M2 with A2 = A2 ∪ Aman = A1 ∪ Aman (Aman are the attributes added manually). In a transformation chain, both models are expected to be models of the same system (or original). But M1 is also a model of M2 . That is, the manually added attributes Aman are omitted in M1 . The following table summarizes the transformation chain and the terms defined above: M1 → M2 ; M2  A1 A1 = A2 Aman A2 = A1 ∪ Aman sem1 = |A1 | sem2 = sem1 semman sem2 = sem1 + semman size1 size2 |Vman | + |Eman | size2 = size2 + |Vman | + |Eman |

110

J. von Pilgrim

Because of definition 1 we know that the elements of the graph and the attributes are somehow related. Even if we cannot define the interpretation mappings exactly, we can calculate how many elements of the graph are average needed to represent a single attribute, or vice versa, how much semantics is stored in a single graph element. We call this the “ratio of abstraction and detail”: Definition 4. [Ratio of Abstraction and Detail] The ratio of abstraction and detail of a model M is defined here as the semantic size of a model divided by its size. That is sem(M ) |A| rad(M ) = = size(m) |V | + |E| + 1 While we can measure the size of the models (as defined above), we cannot measure the semantic size nor the platform detail. In a transformation chain M1 → M2 ; M2 → . . . ; Mn , M1 was not generated by a transformation. We assume that a special domain specific language was used to create that model, and thus we minimize the necessary glue elements. We simply assume |A1 | = |V1 | + |E1 |, i.e. sem1 = |A1 | = size1 − 1 (1) We further assume that the ratio of abstraction and detail of a model is constant during manual enrichment. That is, the language used to formulate a model (i.e. its metamodel), determinates this ratio, and since we do not change the metamodel, the ratio is expected to stay constant. Thus we can say rad(M2 ) = rad(M2 ) ⇒

|A1 | |A2 | = size2 size2

(2)

That is, we can calculate the semantic size of M2 , i.e. the number of its attributes, by solving (2) for |A2 |: sem2 = |A2 | =

|A1 |size2 size2

(3)

We can apply equation 3 for all manually edited models Mi , i > 1 in our transformation chain