Models in Software Engineering: Workshops and Symposia at MODELS 2009, Denver, CO, USA, October 4-9, 2009. Reports and Revised Selected Papers ... Programming and Software Engineering)

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris ...

Author: Sudipto Ghosh

97 downloads 690 Views 7MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

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 TU Dortmund University, Germany Madhu Sudan Microsoft Research, Cambridge, 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

6002

Sudipto Ghosh (Ed.)

Models in Software Engineering Workshops and Symposia at MODELS 2009 Denver, CO, USA, October 4-9, 2009 Reports and Revised Selected Papers

13

Volume Editor Sudipto Ghosh Colorado State University, Department of Computer Science Fort Collins, CO 80523-1873, USA E-mail: [email protected]

Library of Congress Control Number: 2010923417 CR Subject Classiﬁcation (1998): D.2, D.3, I.6, K.6, F.3 LNCS Sublibrary: SL 1 – Theoretical Computer Science and General Issues ISSN ISBN-10 ISBN-13

0302-9743 3-642-12260-4 Springer Berlin Heidelberg New York 978-3-642-12260-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, speciﬁcally the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microﬁlms 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.com © Springer-Verlag Berlin Heidelberg 2010 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientiﬁc Publishing Services, Chennai, India Printed on acid-free paper 06/3180

Preface

The MODELS series of conferences is the premier venue for the exchange of innovative technical ideas and experiences relating to model-driven approaches in the development of software-based systems. Following the tradition of previous conferences, MODELS 2009 hosted several satellite events in Denver. There were ten workshops and two symposia. The selection of the workshops was performed by a Workshop Committee, which consisted of the following experts: – – – –

James M. Bieman, Colorado State University, USA (Chair) Peter Clarke, Florida International University, USA Holger Giese, University of Paderborn, Germany Frank Weil, Hengsoft, USA

The workshops and symposia were held during the ﬁrst three days of the conference. They provided a collaborative forum for groups of participants to exchange recent and preliminary results, conduct intensive discussions on a particular topic, and to coordinate eﬀorts between representatives of a technical community. They discussions were lively and the attendance was high. The focus of the Educators’ Symposium was on sharing experience related to teaching modeling techniques and on developing resources to support eﬀective training of future practitioners of model-driven development. The Doctoral Symposium provided a forum in which PhD students presented their work in progress. The symposium fostered the role of MODELS as a premier venue for research in model-driven engineering. The symposium provided the students with independent and constructive feedback about their already completed work, and more importantly, their planned research work. Organizers of nine workshops and both symposia invited the authors of one or two of their best papers to revise and extend the papers for publication in these proceedings. The selected papers went through two rounds of review before being included in the proceedings. Each workshop and symposium also provided a summary. I would like to thank everyone involved in making the satellite events a success, especially, Rob Pettit, General Co-chair of MODELS, and Geri Georg, Vice-Chair of the MODELS Steering Committee. January 2010

Sudipto Ghosh

Organization

Sponsoring Institutions ACM Aerospace Colorado State University IEEE SIGSOFT Springer

Table of Contents

Doctoral Symposium The Doctoral Symposium at MODELS 2009 . . . . . . . . . . . . . . . . . . . . . . . . . Juergen Dingel Catch Me If You Can – Debugging Support for Model Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Johannes Schoenboeck, Gerti Kappel, Angelika Kusel, Werner Retschitzegger, Wieland Schwinger, and Manuel Wimmer A Coordination-Based Model-Driven Method for Parallel Application Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stefan Gudenkauf

1

5

21

Educators’ Symposium Essentials of the 5th Educators’ Symposium at MODELS 2009 . . . . . . . . Robert France and Martin Gogolla

36

Teaching Object-Oriented Modeling and UML to Various Audiences . . . . Sabine Moisan and Jean-Paul Rigault

40

Teaching Modeling: Why, When, What? . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jean Bezivin, Robert France, Martin Gogolla, Oystein Haugen, Gabriele Taentzer, and Daniel Varro

55

Workshop — ACES-MB Model Based Architecting and Construction of Embedded Systems (ACES-MB 2009) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stefan Van Baelen, Thomas Weigert, Ileana Ober, Huascar Espinoza, and Iulian Ober Using Higher-Order Transformations to Derive Variability Mechanism for Embedded Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Goetz Botterweck, Andreas Polzer, and Stefan Kowalewski Model-Based Extension of AUTOSAR for Architectural Online Reconﬁguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basil Becker, Holger Giese, Stefan Neumann, Martin Schenck, and Arian Treﬀer

63

68

83

VIII

Table of Contents

Workshop — AOM Report of the 14th International Workshop on Aspect-Oriented Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . J¨ org Kienzle, Jeﬀ Gray, Dominik Stein, Thomas Cottenier, Walter Cazzola, and Omar Aldawud HiLA: High-Level Aspects for UML State Machines . . . . . . . . . . . . . . . . . . Gefei Zhang and Matthias H¨ olzl

98

104

Workshop — [email protected] 4th International Workshop on [email protected] . . . . . . . . . . . . . . . . . . . . . Nelly Bencomo, Gordon Blair, Robert France, Freddy Mu˜ noz, and C´edric Jeanneret Incremental Model Synchronization for Eﬃcient Run-Time Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Thomas Vogel, Stefan Neumann, Stephan Hildebrandt, Holger Giese, and Basil Becker Generating Synchronization Engines between Running Systems and Their Model-Based Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hui Song, Yingfei Xiong, Franck Chauvel, Gang Huang, Zhenjiang Hu, and Hong Mei

119

124

140

Workshop — MoDeVVa MoDeVVa Workshop Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Levi L´ ucio and Stephan Weißleder

155

From UML to Alloy and Back Again . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Seyyed M.A. Shah, Kyriakos Anastasakis, and Behzad Bordbar

158

Generating Class Contracts from Deterministic UML Protocol Statemachines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ivan Porres and Irum Rauf

172

Workshop — MoDSE-MCCM “Models and Evolution”: Joint MoDSE-MCCM 2009 Workshop on Model-Driven Software Evolution (MoDSE) Model Co-Evolution and Consistency Management (MCCM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dalila Tamzalit, Dirk Deridder, and Bernhard Sch¨ atz Model Patches in Model-Driven Engineering . . . . . . . . . . . . . . . . . . . . . . . . . Antonio Cicchetti, Davide Di Ruscio, and Alfonso Pierantonio

186 190

Table of Contents

Limitations of Automating Model Migration in Response to Metamodel Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Markus Herrmannsdoerfer and Daniel Ratiu

IX

205

Workshop — MPM Recent Advances in Multi-paradigm Modeling . . . . . . . . . . . . . . . . . . . . . . . Vasco Amaral, C´ecile Hardebolle, Gabor Karsai, L´ aszl´ o Lengyel, and Tiham´er Levendovszky Deriving Correspondence Relationships to Guide a Multi-view Heterogeneous Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Andr´es Yie, Rubby Casallas, Dirk Deridder, and Dennis Wagelaar Explicit Transformation Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Thomas K¨ uhne, Gergely Mezei, Eugene Syriani, Hans Vangheluwe, and Manuel Wimmer

220

225 240

Workshop — OCL Ninth International Workshop on the Pragmatics of OCL and Other Textual Speciﬁcation Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jordi Cabot, Joanna Chimiak–Opoka, Martin Gogolla, Fr´ed´eric Jouault, and Alexander Knapp Extending OCL with Null-References: Towards a Formal Semantics for OCL 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Achim D. Brucker, Matthias P. Krieger, and Burkhart Wolﬀ On Better Understanding OCL Collections or An OCL Ordered Set Is Not an OCL Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fabian B¨ uttner, Martin Gogolla, Lars Hamann, Mirco Kuhlmann, and Arne Lindow

256

261

276

Workshop — NFPinDSML The 2nd International Workshop on Non-functional System Properties in Domain Speciﬁc Modeling Languages (NFPinDSML2009) . . . . . . . . . . . Marko Boˇskovi´c, Dragan Gaˇsevi´c, Claus Pahl, and Bernhard Sch¨ atz

291

On the Speciﬁcation of Non-functional Properties of Systems by Observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Javier Troya, Jos´e E. Rivera, and Antonio Vallecillo

296

Modeling Heterogeneous Points of View with ModHel’X . . . . . . . . . . . . . . Fr´ed´eric Boulanger, Christophe Jacquet, C´ecile Hardebolle, and Elyes Rouis

310

X

Table of Contents

Workshop — TWOMDE Second Workshop on Transforming and Weaving Ontologies in Model Driven Engineering (TWOMDE 2009) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fernando Silva Parreiras, Jeﬀ Z. Pan, and Uwe Assmann

325

Towards Semantic Modeling of Network Physical Devices . . . . . . . . . . . . . Krzysztof Miksa, Marek Kasztelnik, Pawel Sabina, and Tobias Walter

329

Using Ontology Reasoning for Reverse Engineering Design Patterns . . . . Awny Alnusair and Tian Zhao

344

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

359

The Doctoral Symposium at MODELS 2009 Juergen Dingel School of Computing, Queen’s University Kingston, Ontario, Canada [email protected]

Abstract. The research of nine doctoral students was selected for presentation at the symposium from a total of nineteen submissions. All submissions received detailed feedback via written reviews by three members of the program committee. At the symposium, the research described in the accepted submissions was presented, discussed, and additional, detailed feedback was provided. This summary provides a brief overview of the symposium.

1

Introduction

The Doctoral Symposium at the 13th International Conference on Model Driven Engineering Languages and Systems (MODELS’09) took place on October 5, 2009 in Denver, Colorado, USA. It was preceeded by the submission and review of nineteen papers from nine countries. Reviews were conducted by a program committee which consisted of the following twenty international experts: – – – – – – – – – – – – – – – – – – – –

Ruth Breu, University of Innsbruck, Austria Betty Cheng, Michigan State University, USA Juergen Dingel, Queen’s University, Canada (Chair) Gregor Engels, University of Paderborn, Germany Robert France, Colorado State University, USA Vahid Garousi, University of Calgary, Canada Aniruddha Gokhale, Vanderbilt University, USA Jeﬀ Gray, University of Alabama at Birmingham, USA Gerti Kappel, Vienna University of Technology, Austria Jochen K¨ uster, IBM Research Z¨ urich, Switzerland Ingolf Kr¨ uger, University of California at San Diego, USA Yvan Labiche, Carleton University, Canada Pieter Mosterman, The MathWorks, USA Iulian Ober, University of Toulouse, France Alexander Pretschner, Fraunhofer IESE and Kaiserslautern University of Technology, Germany Bernhard Sch¨atz, Munich University of Technology, Germany Holger Schlingloﬀ, Humboldt University, Germany Michal Smialek, Warsaw University of Technology, Poland St´ehane Som´e, University of Ottawa, Canada Janos Sztipanovits, Vanderbilt University, USA

S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 1–4, 2010. c Springer-Verlag Berlin Heidelberg 2010

2

J. Dingel

Each submission received three reviews and was evaluated with respect to the overall quality of the submission itself and the potential impact of the completed and proposed research. The following nine submissions were selected for presentation at the symposium: – Application Reconfiguration Based on Variability Transformations Andreas Svendsen, University of Oslo, Norway – Model Transformation by Demonstration Yu Sun, University of Alabama at Birmingham, USA – Advanced Conflict Resolution Support for Model Versioning Systems Konrad Wieland, Vienna University of Technology, Austria – TROPIC: A Framework for Building Reusable Transformation Components Angelika Kusel, Johannes-Kepler-University at Linz, Austria – Transformation Nets: A Runtime Model for Transformation Languages Johannes Schoenboeck, Vienna University of Technology, Austria – Combining Domain-Specific Languages and Ontology Technologies Tobias Walter, University of Koblenz-Landau, Germany – A Semantic Framework for DSMLs Zekai Demirezen, University of Alabama at Birmingham, USA – A Coordination-based Model-Driven Method for Parallel Application Development Stefan Gudenkauf, Christian-Albrechts-University at Kiel, Germany – Towards an Adaptable Framework for Modeling, Verifying, and Executing Medical Guidelines Janos Mathe, Vanderbilt University, USA Each presentation was about 20 minutes in length and followed by a 25minute discussion which included the program committee members present and the students. The discussion was always lively, but also friendly and respectful. Apart from chair, the committee members Betty Cheng, Gregor Engels, Robert France, Aniruddha Gokhale, Ingolf Kr¨ uger, Bernhard Sch¨ atz, and Michel Smialek attended all or some of the presentations and participated in the discussions. After the symposium, the two papers – Transformation Nets: A Runtime Model for Transformation Languages Johannes Schoenboeck, Vienna University of Technology, Austria – A Coordination-based Model-Driven Method for Parallel Application Development Stefan Gudenkauf, Christian-Albrechts-University at Kiel, Germany were selected for inclusion in the MODELS’09 Workshop and Symposia Proceedings after two additional review and revision cycles.

2

Summary of Presentations and Feedback

The papers listed above can be found in [Din09]. In the following, we will summarize some of the advice and suggestions that were given repeatedly and that seem most relevant to a larger audience.

The Doctoral Symposium at MODELS 2009

3

– Issues related to the scope of the thesis: • Often, comments indicated that the scope of thesis was not deﬁned precisely enough. More precicely, it was not clear exactly what kinds of problems the thesis work would address and which it would not. • Students were cautioned against being overly ambitious and making the scope of the thesis is too broad. If a problem does not have a general, “one-size-ﬁts-all” solution, it should be narrowed down by, e.g., making appropriate simplifying assumptions or only addressing certain important instances of the problem. Sample scenarios include the automatic adaptation of test cases for model transformations across all possible kinds of transformations or the automatic learning of all kinds of transformations by demonstration. Closely studying many instances (“incarnations”) of the problem will help develop an understanding under which circumstances the problem is actually solvable. The resulting classiﬁcation will provide useful guidance to the student and can itself be an important contribution of interest to other researchers in the ﬁeld. • A related problem occurs when central properties that the research result is supposed to have are not deﬁned clearly enough (e.g., what exactly does the “preservation of correctness” or “facilitating reuse” mean in the context of the thesis?). Failing to do this can cause misunderstandings and will make it harder to demonstrate convincingly that the result of the research actually has these properties. – Issues related to the evaluation of research: • It is important to be very clear on what contribution and improvement the work makes over existing research. Failure to do this will invite questions about the signiﬁcance of the work. • In cases where the research produces some kind of tool that is supposed to accomplish some kind of task better than other tools, a direct, fair, repeatable comparison should be carried out, ideally using 3rd-party data that is publically available. In other words, evaluating a tool on data or examples that has been hand-crafted by the tool developer is typically insuﬃcient to claim one tool is better than another. For illustration, the discussion of the state-of-the-art in the comparative evaluation of software model checkers in [DHR+ 07] may be helpful. However, it was acknowledged that conducting these kinds of ideal comparisons may not always be possible given the available resources. In these cases, a reasonable compromise should be found. • In case the research contains empirical work, the study of some of the recent texts on how to conduct empirical software engineering research is highly recommended. Examples include [SSS07, SHH+ 05, WRH+ 00] and more books and papers on this topic can be found at, e.g., [Eas10]. For empirical work, this kind of background is vital, because it will prevent the researcher from using wrong terminology (e.g., “is this really a ‘case study’ or just a ‘challenge problem’ ”?), the wrong technique (e.g., “which kind of statistical test is appropriate here?”, “how much data do I need to collect?”), or drawing the wrong conclusions from the data

4

J. Dingel

(e.g., “which ‘threats of validity’ does this experiment have?”, “which other phenomena do I need to control for?”) More advice not only on how to conduct PhD-level research, but also on other aspects of PhD-student life (e.g., how to give presentations, how to write technical papers, how ﬁnd a job after graduation), can be found on the web. For instance, Tao Xie’s advice collection [XX10] provides a good starting point.

3

Conclusion

The Doctoral Symposium at MODELS’09 continued the successful tradition of previous doctoral symposia. It featured high-quality presentations and mutually beneﬁcial and enjoyable interaction. The chair would like to thank the members of the program committee for their excellent work, Alexander Pretschner for sharing his experience from the symposium in 2008, and the MODELS’09 general chairs Robert Pettit and Sudipto Ghosh for their support.

References [DHR+ 07]

[Din09]

[Eas10] [SHH+ 05]

[SSS07] [WRH+ 00]

[XX10]

Dwyer, M.B., Hatcliﬀ, J., Robby, Pasareanu, C.S., Visser, W.: Formal software analysis: Emerging trends in software model checking. In: International Conference on Software Engineering, Workshop on the Future of Software Engineering (FOSE 2007), Minneapolis, USA (May 2007) Dingel, J.: Proceedings of the Doctoral Symposium at MODELS 2009. Technical Report 2009-566, School of Computing, Queen’s University, Kingston, Canada, October 2009, 58 pages (2009) Easterbrook, S.: Course page for CSC2130S: Empirical Research Methods in Software Engineering, http://www.cs.toronto.edu/~ sme/CSC2130 (last accessed January 11, 2010) Sjoeberg, D.I.K., Hannay, J.E., Hansen, O., By Kampenes, V., Karahasanovic, A., Liborg, N.-K., Rekdal, A.C.: A survey of controlled experiments in software engineering. IEEE Transactions on Software Engineering 31, 733–753 (2005) Shull, F., Singer, J., Sjoberg, D.I.K. (eds.): Guide to Advanced Empirical Software Engineering. Springer, Heidelberg (2007) Wohlin, C., Runeson, P., H¨ ost, M., Ohlsson, M.C., Regnell, B., Wessl´en, A.: Experimentation in software engineering: an introduction. Kluwer, Dordrecht (2000) Xie, T., Xie, Y.: Advice collection (2010), http://people.engr.ncsu.edu/txie/advice.htm (last accessed January 11, 2010)

Catch Me If You Can – Debugging Support for Model Transformations Johannes Schoenboeck1 , Gerti Kappel1 , Angelika Kusel2 , Werner Retschitzegger2 , Wieland Schwinger2, and Manuel Wimmer1 1

Vienna University of Technology, Austria {schoenboeck,kappel,wimmer}@big.tuwien.ac.at 2 Johannes Kepler University Linz, Austria {kusel,retschitzegger}@bioinf.jku.at, [email protected]

Abstract. Model-Driven Engineering places models as ﬁrst-class artifacts throughout the software lifecycle requiring the availability of proper transformation languages. Although numerous approaches are available, they lack convenient facilities for supporting debugging and understanding of the transformation logic. This is because execution engines operate on a low level of abstraction, hide the operational semantics of a transformation, scatter metamodels, models, transformation logic, and trace information across diﬀerent artifacts, and provide limited veriﬁcation support. To tackle these problems, we propose a Domain-Speciﬁc Language (DSL) on top of Colored Petri Nets (CPNs)—called Transformation Nets—for the execution and debugging of model transformations on a high level of abstraction. This formalism makes the afore hidden operational semantics explicit by providing a runtime model in terms of places, transitions and tokens, integrating all artifacts involved into a homogenous view. Moreover, the formal underpinnings of CPNs enable comprehensive veriﬁcation of model transformations. Keywords: Model Transformation, Debugging, CPN, Runtime Model.

1

Introduction

The availability of model transformation languages is the crucial factor in MDE, since they are as important for MDE as compilers are for high-level programming languages. Several kinds of transformation languages have been proposed, comprising imperative, declarative, and hybrid ones [5]. Imperative approaches allow the speciﬁcation of complex transformations more easily than declarative approaches, e.g., by providing explicit statefulness, but induce more overhead code as many issues have to be accomplished explicitly, e.g., speciﬁcation of control ﬂow. Although hybrid and declarative model transformation languages relieve transformation designers from these burdens, speciﬁcation of transformation logic is still a tedious and error prone task due to the following reasons.

This work has been funded by the Austrian Science Fund (FWF) under grant P21374-N13.

S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 5–20, 2010. c Springer-Verlag Berlin Heidelberg 2010

6

J. Schoenboeck et al.

First, languages such as the Atlas Transformation Language (ATL) [10], Triple Graph Grammars (TGGs) [12], and QVT Relations [17] specify correspondences between source and target metamodel elements (cf. Fig. 1 (a)) on a high level of abstraction, whereas accompanying execution engines operate on a considerably lower level. For example, ATL uses a stack machine and TGGs are ﬁrst translated to Fujaba [21], and then to Java. As a consequence, debugging of model transformations is limited to the information provided by these engines, most often just consisting of variable values and logging messages, but missing important information, e.g., why certain parts of a transformation are actually executed. Thus, only a snapshot of the actual execution state is provided during debugging while coherence between the speciﬁed correspondences is lost. Therefore, these execution engines act as a black-box to the transformation designer hiding the operational semantics. Second, comprehensibility of transformation logic is further hampered as current transformation languages provide only a limited view on a model transformation problem. For example in ATL, metamodels, models, the transformation speciﬁcation, and trace information are scattered across different artifacts. Graph transformation approaches using graph patterns also only reveal parts of the metamodel. Additionally, both approaches hide the transformation of concrete model elements. Finally, comprehensive veriﬁcation support of model transformations is missing, although ﬁrst approaches are available, e.g., work in the area of graph transformations such as [3].

Fig. 1. Model Transformation Architecture

To tackle the aforementioned limitations of current approaches and their underlying execution engines we propose Transformation Nets (TNs), a DSL on top of Colored Petri Nets (CPNs) [9], for developing, executing and debugging model transformations (cf. Fig. 1(b)). In particular, for every metamodel element, places in TNs are derived, whereby a corresponding place is created for every class, every attribute and every reference. Model elements are represented by tokens which are put into the according places. Finally, the actual transformation logic is represented by transitions. The existence of certain model elements (i.e., tokens) allows transitions to ﬁre and thus stream these tokens from source places to target places representing instances of the target metamodel to be

Catch Me If You Can – Debugging Support for Model Transformations

7

created. This approach follows a process-oriented view towards model transformations allowing debugging on an appropriate level of abstraction. Furthermore, TNs provide the explicit statefulness of imperative approaches through tokens contained within places. The abstraction of control ﬂow known from declarative approaches is achieved as the net’s transitions can ﬁre autonomously, thus making use of implicit, data-driven control ﬂow. Nevertheless, the stepwise ﬁring of the transitions makes explicit the operational semantics of the transformation logic and thereby enables simulation-based debugging (cf. (1) in Fig. 2). The ability to combine all the artifacts involved, i.e., metamodels, models, as well as the actual transformation logic, into a single representation makes the formalism especially suited for gaining an understanding of the intricacies of a speciﬁc model transformation. Moreover, TNs form a runtime model, serving as an execution engine for diverse model transformation languages, e.g., QVT Relations. As the runtime model itself is formally speciﬁed in terms of a metamodel [24], it can be exploited for model-based debugging by using OCL queries to ﬁnd the origin of a bug (cf. (2) in Fig. 2). Finally, the formal underpinnings of CPNs enable veriﬁcation-based debugging by state space exploration, which contains all possible ﬁring sequences of a CPN (cf. (3) in Fig. 2). This allows the application of generally accepted behavioral properties, characterizing the nature of a certain CPN, e.g., to verify if a certain target model can be created with the given transformation logic. Whereas previous work [22,23,24] focused on distinct aspects of the TN formalism, this work aims at providing a comprehensive consideration of the diverse debugging features. The rest of the paper is structured as follows. Section 2 presents the concepts of the runtime model. Subsequently, Section 3 shows how to exploit the runtime model for model-based debugging. In Section 4, we introduce properties of CPNs, Correspondences transformation ClassToRel (class:Class, rel:Relational){ top relation PackageToSchema{ checkonly domain class p:Package{classes=c:Class{ isPersistent=true}}; enforce domain rel s:Schema {tables=t:Table{}}; }

Source Metamodel

Target Metamodel

QVT Relations

TGGs

implements

executed by

Transformation Net

conforms

Source

Transformation Logic

conforms

Target

Transitions

2

Tokens Transitions

Development and Debugging Environment Model-Based Debugging

Places

Source Model

New Target Model

1

Runtime Model Simulation-Based Debugging

based on

3

Colored Petri Nets Verification-Based Debugging

Fig. 2. Expected Main Contributions

8

J. Schoenboeck et al.

which can be used to formally verify model transformations. Section 5 reports on lessons learned, whereas Section 6 discusses related work. Finally, Section 7 provides an outlook on future work.

2

Runtime Model for Simulation-Based Debugging

In this section, we introduce the proposed runtime model by ﬁrst describing the static parts thereof, i.e., metamodels and models, followed by the dynamic parts, i.e., transformation logic itself. In order to exemplify this, Fig. 3 depicts a small excerpt of the metamodels of the well-known UML2RDBMS case study [17] serving as a simple running example throughout the rest of the paper. UML

RDBMS UMLModelElement UMLModelElement

Metamodels (M2)

name name :: String String

RModelElement RModelElement Package Package

PackageElement PackageElement

Attribute Attribute

element * namespace

Classifier Classifier

general *

PrimitiveDatatype PrimitiveDatatype 1

type

name name :: String String

* attribute

Class Class

*

generalOpposite

Schema Schema

* schema

table

kind kind :: String String

Table Table

Column Column type type :: String String * column

Fig. 3. Metamodels of the UML2RDBMS Example

Static Parts. When employing TNs, the static parts of a model transformation, i.e., metamodels and models, need to be represented in our formalism. This incurs transitioning from the graph-based paradigm underlying MDE into the set-based paradigm underlying Petri Nets (cf. Fig. 4). The abstract syntax of TNs is formalized by means of a metamodel (see [24]) conforming to the Ecore meta-metamodel, the Eclipse realization of OMG’s MOF standard. The design rationale behind this transition is the following: We rely on the core concepts of an object-oriented meta-metamodel (MOF), i.e., the graph which represents the metamodel consists of classes, attributes, and references, and the graph which represents a conforming model consists of objects, data values and links. Therefore, we distinguish between one-colored places containing one-colored tokens for representing the nodes of graphs, i.e., objects, and two-colored places containing two-colored tokens. These two-colored tokens represent on the one hand links between objects, i.e., one color represents the source object and the other the target object, and on the other hand attribute values, i.e., one color represents the containing object and the other one the actual value. The color is realized through a unique value that is derived from the object’s id. TNs also support modeling concepts beyond classes, attributes and references. Subclass relationships are currently represented by nested places whereby the place corresponding to the subclass is contained within the place corresponding to the superclass. The tokens contained in the subplace may also act as input tokens for a transition connected to the superplace. For deep inheritance hierarchies we represent the classes by separated places whereby the is-a relationship

Catch Me If You Can – Debugging Support for Model Transformations

9

between objects is expressed by duplicating the tokens in every place involved in the inheritance hierarchy, e.g., for representing a class object, a token is put into the place Class and another, same-colored, token into the place Classifier. Ordered references in the metamodel are represented similar to ordinary references but induce a FIFO semantics when ﬁring the transition in the TN. To represent multiplicities of references deﬁned in the metamodel accordingly, places may be annotated with a relative capacity constraint to restrict the number of tokens of a speciﬁc outer-color. Finally, places may be annotated with an absolute capacity to restrict the total number of their tokens, e.g., for enforcing sequential processing. Meta Object Facility (MOF)

Metamodel Elements

Concept

Example in UML

Class

Class Class

Attribute

Class Class

Reference

Class Class

Generalization

Classifier Classifier

Ordered Reference

Model Elements

Object (Instance of Class) Value (Instance of Attribute) Link (Instance of Reference)

C2

Class_kind

TwoColoredPlace

kind kind :: String String attr

*

Attribute Attribute

kind kind :: String String

Class Class kind kind :: String String {ordered} *

kind kind :: String String

attr

Attribute Attribute

Class_attr

TwoColoredPlace

NestedPlace

ordered

C1:Class C1:Class

OneColoredToken (contained in a OneColoredPlace)

kind=`persistent´ kind=`persistent´

C1:Class C1:Class kind=`persistent´ kind=`persistent´

Buffer 1 Attribute_type

Relative Capacity

C1:Class C1:Class

C 2

OrderedPlace

Attribute Attribute type 1 PrimitiveType PrimitiveType

kind=`persistent´ kind=`persistent´

Classifier Class Class_attr

Absolute Capacity

Not used in metamodels

Multiplicity

Example Class

OneColoredPlace

kind kind :: String String

Class Class

Transformation Nets Concept

1 Class C1

TwoColoredToken (contained in a TwoColoredPlace)

Class_kind

TwoColoredToken attr A1:Attribute A1:Attribute (contained in a TwoColoredPlace)

Class_attr

C1

persistent

C1 A1

Fig. 4. Representing MOF concepts within Transformation Nets

Dynamic Parts. The transformation logic is embodied by Petri Net transitions and additional trace places which reside in-between those places representing the original input and output metamodels. A transition consists of input placeholders (LHS of the transition) representing its pre-condition, whereas output placeholders (RHS of the transition) depict its post-condition. To express these conditions, meta tokens are used, prescribing a certain token conﬁguration by means of color patterns. By matching a certain token conﬁguration from the input places, i.e., fulﬁlling the pre-condition, the transition is ready to ﬁre. The production of output tokens fulﬁlling the post-condition once a transition ﬁres depends on the matched input tokens. Finally, TNs exhibit a speciﬁc ﬁring

10

J. Schoenboeck et al.

behavior where tokens are not consumed per default since typically all combinations of tokens fulﬁlling a certain precondition are desired in a transformation scenario, e.g., to correctly resolve 1:n relationships between objects. This is realized by a transition’s history which logs the already ﬁred token combinations. Since meta tokens are just typed to one-colored and two-colored tokens, but not to certain metamodel classes, transitions can form reusable transformation patterns which can be applied in diﬀerent scenarios (cf. Fig. 5). For example, when a simple one-to-one correspondence should be implemented, the colors of input and output meta tokens are equal, meaning that a token is streamed through the transition only, e.g., to map Attributes to Columns (cf. Streamer in Fig. 5(a)). In order to set inverted references, transition (b) in Fig. 5 matches a two-colored token from its input place, and produces an inverted token in the output place, thus building up the Inverter pattern. To get the value of an attribute or the target of a link which is represented by the inner color of the twocolored token, transition (c) matches two-colored tokens from input places and peels oﬀ the outer color of the token (cf. Peeler in Fig. 5). Finally, transition (d) represents a variation of the Streamer pattern called ConditionalStreamer adding additional preconditions. For example, this pattern may be used to ensure that objects have been created before a link can be set between them. These patterns represent basic building blocks recurring in diverse model transformation scenarios. Complementary research focuses on how these ﬁne grained patterns can be employed in more coarse grained reusable mapping operators [14]. (a) Streamer

(b) Inverter

(c) Peeler

(d) Conditional Streamer CondStreamer

Streamer

Attribute

Inverter

Peeler

TopClasses p

Column Class_general Class_generalOpposite Class_general SuperClass Class_attr

Table_cols

Attribute

Fig. 5. Transitions forming Transformation Patterns

Summarizing, TNs allow the transformation process to be executed stepwise revealing which tokens enable a certain transition and which tokens get produced by ﬁring this transition, enabling simulation-based debugging. This is possible because TNs provide a white-box view on model transformation execution, i.e., the speciﬁcation needs not to be translated into another low-level executable artifact but can be executed right away. As already mentioned, this runtime might act as an execution engine for various declarative transformation languages which have a close correspondence to TNs, e.g., for QVT Relations as shown in [23], to beneﬁt from our debugging features.

3

Development Environment for Model-Based Debugging

For exemplifying model-based debugging features integrated into a development environment, we make use of the running example, whereby an OR-mapping

Catch Me If You Can – Debugging Support for Model Transformations

11

strategy of creating a table for every persistent class is pursued. Moreover, attributes inherited from base classes should result in additional columns. As shown in Fig. 6, our example input model comprises three classes whereby class C2 inherits from class C1 and class C3 inherits from class C2 (cf. link general) but only class C1 and C2 are marked persistent. Therefore, the desired output model should contain two Tables, one for class C1 and one for class C2, whereby table C2 gets an additional column originating from the attribute name of class C1. In the following we use this example to demonstrate our debugging facilities. UML

RDBMS element

Models (M1)

namespace

C1 C1 :: Class Class kind kind == 'Persistent' 'Persistent' name name == ‘Person‘ ‘Person‘ general

element

P1 P1 :: Package Package name name == ‘University‘ ‘University‘ namespace namespace

attribute

name name == ‘name‘ ‘name‘

attribute

kind kind == 'Persistent' 'Persistent' name name == ‘Student‘ ‘Student‘ general

C3 C3 :: Class Class kind kind == 'NonPersistent' 'NonPersistent' name name == ‘Tutor‘ ‘Tutor‘

C1 C1 :: Table Table name name == ‘Person‘ ‘Person‘

schema

P1 P1 :: Schema Schema

A2 A2 :: Attribute Attribute

name name == ‘University‘ ‘University‘ schema

Pr2 Pr2 :: PrimitiveDatatype PrimitiveDatatype

attribute

A1 A1 :: Column Column

column name = ‘name‘ name = ‘name‘ type type == ‘String‘ ‘String‘

name name == ‘String‘ ‘String‘

name name == ‘registrNo‘ ‘registrNo‘

generalOpposite element

table type

Pr1 Pr1 :: PrimitiveDatatype PrimitiveDatatype type

generalOpposite

C2 C2 :: Class Class

A1 A1 :: Attribute Attribute

name name == ‘Integer‘ ‘Integer‘

A3 A3 :: Attribute Attribute name name == ‘lecture‘ ‘lecture‘

type

column

A2 A2 :: Column Column name name == ‘name‘ ‘name‘ type type == ‘String‘ ‘String‘

C2 C2 :: Table Table table

name name == ‘Student‘ ‘Student‘

A3 A3 :: Column Column name name == ‘registrNo‘ ‘registrNo‘ column type type == ‘Integer‘ ‘Integer‘

Fig. 6. Source and Target Models – Transforming Persistent Classes only

Our development and debugging environment is based on Eclipse including two editors, one presenting the transformation speciﬁcation, e.g, QVT Relations code (cf. Fig. 7(a)) and another one that shows the graphical representation thereof in terms of TNs (cf. Fig. 7(b)), realizing the above example. To provide common debugging functionalities, such as stepwise debugging, an editor toolbar (cf. Fig. 7(c)) is oﬀered. Furthermore, functionalities to save the generated target model, i.e., to switch from the token representation to a model representation, and to load a new source model into the debugging environment are included. Besides these standard functionalities, there are additional debugging features resulting as a beneﬁt of using a dedicated runtime model (cf. model-based debugging). In particular, OCL is employed for two diﬀerent debugging purposes. First, OCL is used to deﬁne conditional breakpoints at diﬀerent levels of granularity. Thus, it cannot only be deﬁned that execution should stop if a certain token is streamed into a certain place, but also if a certain combination of tokens occurs. Second, OCL is used to tackle the well-known problem in debugging that programs execute forwards in time whereas programmers must reason backwards in time to ﬁnd the origin of a bug. For this, a dedicated debugging console based on the Interactive OCL Console of Eclipse (cf. Fig. 7(d)) is supported, providing several pre-deﬁned debugging functions to explore and to understand the history of a transformation by determining and tracking paths of produced tokens [23]. The TN in its ﬁnal state realizing the introduced example is depicted in Fig. 7(b). By comparing this generated target model to the expected one (cf. Fig. 6) we can see that more columns have been created than intended, e.g., two tokens labeled with A3 in the place Column. The graphical representation shows that the tokens have been created by transition (4) but we do not know

12

J. Schoenboeck et al.

Interactive Debugger QVT Relations

c

Transfromation Net

transformation umlToRdbms(uml:SimpleUML, rdbms:SimpleRDBMS){

Source UMLModelElement

b

PackageElement

top relation ClassToTable{ cn: String; checkonly domain uml c:Class{ name=cn, kind=’Persistent’}; enforce domain rdbms t:Table{name=cn}; where { AttributeToColumn(c,t); } } relation AttributeToColumn{ an, pn :String; checkonly domain uml c:Class{ attribute= a:Attribute { name=an, type= p:PrimitiveDataType{ name=pn}}}; enforce domain rdbms t:Table{ column= cl:Column { name=an, type=pn}}; where{ SuperAttributeToColumn(c,t); } }

Classifier

a

Column

structural feature mapping name=cn

1

A1 A2 A3 A2 A3

kind=‘Persistent‘ name=cn kind=‘Persistent‘

Attribute A2

C1 C2

getCreator(A3)

trace

Pr1 Pr2

A1

Table

Step 1

t:Table

c:Class

C1 C2 C3 PrimitiveDatatype

RModelElement

ClassToTable

domain object mapping

Class

Target

PackageToSchema

……………. …………….

name=cn

2

Step 3

A3

getCreator(T5) domain object mapping

AttributeToColumn

trace

Class_kind Persistent Persistent

...

3

RModelElement_name

C1 Person C2 A1 Student name A3 A2 registrNo lecture A3 A2 registrNo lecture

NonPersistent UMLModelElement_ name

structural feature mapping Table_column

4

C1 Person C2 Student C3 Tutor

column=

attribute=

cl:Column

a:Attribute{

A1 A2 name registrNo A3 Pr1 lecture String

name=an

name=an

Step 2

Pr2

Column_type

type=

Integer Class_attribute

getInputTokens(A3)

A1 A2 String Integer

p:PrimitiveDT{ name=pn

type=pn

Attribute_type

domain object mapping

SuperAttributeToColumn

A3 String

A2 Integer A3 String

Class_general

trace

recursive call

relation SuperAttributeToColumn{ checkonly domain uml c:Class{ generalOpposite= sc:Class {}}; enforce domain rdbms t:Table {}; where{ AttributeToColumn(sc, t); } }

Class_generalOpposite

generalOpp= sc:Class

6

5

Interactive Debugger Console

selectedElement().getCreator() result: Transition (4) result.getInputTokens(selectedElement()) result: Sequence(Token) {t1, t2, ..., t7} result -> first().getCreator() result: Transition (5)

d

Fig. 7. Development Environment for Transformation Nets

which source tokens were used to create exactly these target tokens. To get this information, the transformation designer may use the interactive debugging console. Within this console, s/he can use standard OCL functions and predeﬁned OCL debugging functions to formulate queries that can be invoked on the runtime model. In our example, the transformation designer selects the top-right token labeled with A3 of the place Column, representing a wrongly created column lecture and invokes the function getCreator(A3) (cf. Step 1 in Fig. 7) which highlights transition (4) in the editor and additionally returns the result of the function in the debugging console. This transition reads an input token from a trace place (ﬁrst LHS meta token) which receives tokens from transition (3) and (6). Therefore, it is unclear which one of these two transitions is responsible for providing the trace token used for creating the selected Column token. To determine the responsible transition, the developer invokes the function getInputTokens(A3) on transition (4) (cf. Step 2 in Fig. 7) returning a sequence of input tokens which has been bound to produce the token A3. The elements in this sequence are ordered with respect to their graphical location within the transition, thus the ﬁrst token in the sequence is the token that matched the top-most LHS metatoken. To get this token, the transformation designer applies the standard OCL function first() on the previously computed sequence which returns the single trace token. Now, the transformation designer applies the function getCreator(T5) (cf. Step 3 in Fig. 7) to determine which transition

Catch Me If You Can – Debugging Support for Model Transformations

13

is responsible for producing this trace token, which yields transition (5), as transition (6) only streams the token through. Taking a closer look at transition (5), one can see that this transition uses tokens of the wrong source place, namely Class generalOpposite instead of Class general (see error sign in Fig. 7(b)), being the origin of the problem. The respective QVT code selects the super class instead of the base class causing the inclusion of wrong columns to the table.

4

Formal Properties for Verification-Based Debugging

Because TNs are based on CPNs, formal properties for verifying the correctness of model transformations can be applied (cf. veriﬁcation-based debugging). For this, the state space of the CPN, being a directed graph with a node for each reachable marking and an arc for each occurring binding element, has to be constructed to calculate diverse behavioral properties. UML

RDBMS

Models (M1)

C1 C1 :: Class Class

attribute name name == ‘Person‘ ‘Person‘ general generalOpposite

A1 A1 :: Attribute Attribute

C2 C2 :: Class Class

attribute name name == ‘Student‘ ‘Student‘ general generalOpposite

A2 A2 :: Attribute Attribute

attribute

A3 A3 :: Attribute Attribute

C3 C3 :: Class Class name name == ‘Tutor‘ ‘Tutor‘

name name == ‘name‘ ‘name‘

C1 C1 :: Table Table name name == ‘Person‘ ‘Person‘

column

column

name name == ‘registrNo‘ ‘registrNo‘

name name == ‘lecture‘ ‘lecture‘

A1 A1 :: Column Column name name == ‘name‘ ‘name‘

A2 A2 :: Column Column name name == ‘registrNo‘ ‘registrNo‘

column

A3 A3 :: Column Column name name == ‘lecture‘ ‘lecture‘

Fig. 8. Source and Target Models – Transforming Top Classes only

In order to exemplify the veriﬁcation potential, we make again use of the running example – this time pursuing a diﬀerent OR-mapping strategy, namely a one-table-per-hierarchy approach according to the case study presented in [2]. As shown in Fig. 8, our example comprises the same input classes and attributes as introduced before. Therefore, the desired output model should now contain one Table, aggregating three Columns (all attributes of the three classes). At a ﬁrst glance the generated target model in Fig. 9(a) seems to be correct, but a closer look reveals that a link from table C1 to column A3 is missing (cf. missing two-colored token in place Table column), compared to the desired target model depicted in Fig. 8. Even in this small example the error is hard to observe manually, suggesting the need for formal veriﬁcation. In order to accomplish this, the speciﬁed transformation logic in TNs is translated to a corresponding CPN (see Fig. 9(b)), which allows to reuse formal veriﬁcation capabilities of existing Petri Net engines, e.g., CPN Tools1 . The ﬁrst step in the veriﬁcation process is the calculation of the state space (see Fig. 9(c)), further on used to determine behavioral properties, i.e. the veriﬁcation process is based on a certain input model (see Fig. 9(d)). In the following, we show how these properties (cf. [16] for an overview) can be used to enable veriﬁcation-based debugging. 1

http://wiki.daimi.au.dk/cpntools/cpntools.wiki

14

J. Schoenboeck et al.

UMLModelElement

TopClasses

TransitiveClosure

PackageElement

Linker

CondStreamer

CondPeeler

Classifier Class

a

3 1

C1 C2 C3

2

TopClasses C1

RModelElement Table

Attribute

C1 A1

A3 A2

Table_cols

Column

CondStreamer A1

LiftAttr

Class_attribute

A3 A2

5 Table_column

Class_general

4 Attr_Buffer Streamer

6

Trace A1

translate

A2

C2C A3

verify

b

export

construct

c

… Integer Bounds Upper Lower … Table_cols 2 0 d ….. Upper Multi-Set Bounds … Table_cols 1`(1200,"Person",1,"name")++ 1`(1200,"Person",2,“registrNo")++ … Home Markings [1320] Dead Markings [1320] Dead Transition Instances TransitiveClosureLinker

Fig. 9. Transformation Veriﬁcation Prototype showing the UML2RDBMS example

Model Comparison using Boundedness Properties. Typically, the ﬁrst step in verifying the correctness of a transformation speciﬁcation is to compare the target model generated by the transformation to the expected target model. To identify wrong or missing target elements in terms of tokens automatically, Boundedness properties (Integer Bounds and Multiset Bounds) can be applied. In our example, the upper Integer Bound of the Table cols place is two (cf. Fig. 9(d)) whereas the desired target model requires three tokens, as every column has to belong to a certain table. By inspecting the Multiset Bounds one recognizes that a link to the column A3 originating from an attribute of class C3 is missing. If such erroneous parts of the target model are detected, the owning target place is highlighted in the TN (see error sign besides the Table cols place in Fig. 9(a)). Properties going beyond concrete input models can be checked by using custom functions, e.g., expressing that for all possible corresponding input and

Catch Me If You Can – Debugging Support for Model Transformations

15

output models the number of attributes in the input model is always equal to the number of columns in the output model. Transition Error Detection using Liveness Properties. Errors in the transformation speciﬁcation occur if either a transition is speciﬁed incorrectly or the source model is incorrect. Both cases might lead to transitions which are never enabled during execution, so called Dead Transition Instances or L0Liveness [16]. The state space report in Fig. 9(d) shows that transition 2 in the TN is a Dead Transition Instance, which is therefore marked with an error sign. The intention of transition 2 in our example is to calculate the transitive closure, thus there should be an additional link from class C3 to class C1 as class C3 also inherits from class C1 (see Fig. 8). When investigating the LHS of transition 2 in Fig. 9(a) we see that the inheritance hierarchy is faulty; the pattern speciﬁes that a class X (white color) is parent of a class Y (black color) and of a class Z (gray color). To ﬁx the color pattern we need to change the outer and inner colors of the second input token of the transition. After ﬁxing the error, the state space can be constructed again and will not contain any dead transitions anymore. Termination and Confluence Verification using Dead and Home Markings. A transformation speciﬁcation must always be able to terminate, thus the state space has to contain at least one Dead Marking. This is typically ensured by the history concept of TNs, which prevents ﬁring recurring token combinations. Moreover, it has to be ensured that a dead marking is always reachable, meaning that a transformation speciﬁcation is conﬂuent, which can be checked by the Home Marking property requiring that a marking M can be reached from any other reachable marking. The generated report in Fig. 9(d) shows that in our example a single Home Marking is available which is equal to the single Dead Marking (both identiﬁed by the marking 1320), meaning that the transformation speciﬁcation always terminates and is conﬂuent. To achieve a correct transformation result, an equal Home Marking and Dead Marking is a necessary but not a suﬃcient condition, as it cannot be ensured that this marking represents the desired target model. By exploring the constructed state space, it is possible to detect if a certain marking, i.e., the target marking derived from the desired target model, is reachable with the speciﬁed transformation logic. If this is the case, and if this marking is equal to both, Home Marking and Dead Marking, it is ensured that the desired target model is created with the speciﬁed transformation logic in any case.

5

Lessons Learned

This section presents lessons learned from already conducted transformation examples with our TN formalism and thereby discusses key features as well as current limitations of the TN approach. Colored Tokens Representing Model Elements Reveal Traceability. The source model to be transformed is represented by means of one-colored tokens and two-colored tokens residing in the source places of the TN whereby

16

J. Schoenboeck et al.

the actual transformation is performed by streaming these tokens to the target places. Through this mechanism traceability is ensured since the source – target relationship can be derived by simply searching for same-colored tokens in source places and target places, respectively. Visual Syntax and Live Programming Fosters Debugging. TNs provide a visual formalism for deﬁning model transformations which is especially useful for debugging purposes. Since the ﬂow of model elements undergoing certain transformations can be directly followed by observing the ﬂow of tokens, undesired results can be detected easily. Another characteristic of TNs that facilitates debugging is live programming, i.e., some piece of transformation logic can be executed and thus tested immediately after deﬁnition without any further compilation step. Therefore, testing can be done independently of other parts of the TN by just setting up a suitable token conﬁguration in the input places. Implicit Control Flow Eases Evolution. The control ﬂow in a TN is given through data dependencies between various transitions. As a consequence, when changing a transformation, one needs to maintain a single artifact only instead of requiring additional eﬀorts to keep control ﬂow and transformation logic (in form of rules) synchronized. For instance, when a rule needs to be changed to match for additional model elements, one would have to take care to call this rule at a time when the elements to be matched already exist. Transitions by Color-Patterns Ease Development but Lower Readability. Currently, the precondition as well as the postcondition of a transition are just encoded by one-colored as well as two-colored tokens. On the one hand, this mechanism eases development since, e.g., for changing the direction of a link it suﬃces just to swap the respective color patterns of the meta tokens of the input placeholders and the output placeholders. On the other hand, the larger the TN grows the less readable this kind of encoding gets. Therefore, it has been proven useful to assign each input as well as each output placement a human-readable label, that describes the kind of input and output, respectively. State Space Explosion Limits Model Size. A known problem of formal veriﬁcation by Petri Nets is that the state space might become very large. Currently, the full occurrence graph is constructed to calculate properties leading to memory and performance problems for large source models and transformation speciﬁcations. Often a marking M has n concurrently enabled, diﬀerent binding elements leading all to the same marking. Nevertheless, the enabled markings can be sorted in n! ways, resulting in an explosion of the state space. As model transformations typically do not care about the order how certain elements are bound, Stubborn Sets [13] could be applied to reduce the state space nearly to half size, thus enhancing scalability of our approach.

6

Related Work

In the following, related work regarding (i) debugging support, (ii) understandability, and (iii) formal veriﬁcation of transformation languages is discussed.

Catch Me If You Can – Debugging Support for Model Transformations

17

Debugging Support of Transformation Languages. In general, there is little debugging support for transformation languages. Most often only low-level information available through the execution engine is provided, but traceability according to the higher-level correspondence speciﬁcations is missing. For example, in the Fujaba environment, a plugin called MoTE [21] compiles TGG rules [12] into Fujaba story diagrams that are implemented in Java, which obstructs a direct debugging on the level of TGG rules. In [7], the generated source code is annotated accordingly to allow the visualization of debugging information in the generated story diagrams, but not on the TGG level. In addition to that, Fujaba supports visualization of how the graph evolves during transformation, and allows interactive application of transformation rules. Approaches like VIATRA [1], which produce debug reports that trace an execution, only, but do not provide interactive debugging facilities. Although the ATL debugger [11] allows the step-wise execution of ATL byte-code, only low-level debugging information is provided, e.g., variable values. This limited view hinders observing the execution of the whole transformation, e.g., the coherence between diﬀerent rules. SmartQVT and TefKat [15] allow for similar debugging functionality. Hibberd et al. [8] present forensic debugging techniques for model transformations by utilizing the trace information of model transformation executions for determining the relationships between source elements, target elements, and the involved transformation logic. With the help of such trace information, it is possible to answer debugging questions implemented as queries which are important for localizing bugs. In addition, they present a technique based on program slicing for further narrowing the area where a bug might be located. The work of Hibberd et al. is orthogonal to our approach, because we are using live debugging techniques instead of forensic mechanisms. However, our approach allows to answer debugging questions based on the visualization of the path a source token has taken to become a target token. Summarizing, what sets TNs apart from these approaches is that all debugging activities are carried out on a single integrated formalism, without the need to deal with several diﬀerent views. Although there are declarative approaches based on relational languages, e.g., Prolog-based approaches [18], that do not induce a gap between the speciﬁcation and the execution, their debugging features are considered not that adequate for our purposes since the uniﬁcation and backtracking processes in Prolog give rise to the possibility of an increased confusion about the location of errors [4]. Furthermore, our approach is unique in allowing interactive execution not only by choosing rules or by manipulating the state directly, but also by allowing to modify the structure of the TN itself. This ability for live-programming enables an additional beneﬁt for debugging and development: one can correct errors (e.g., stuck tokens) in TNs right away without needing to recompile and restart the debug cycle. Understandability of Transformation Languages. Concerning the understandability of model transformations in terms of a visual representation and a possibility for a graphical simulation, only graph transformation approaches like Fujaba allow for a similar functionality. However, these approaches neither

18

J. Schoenboeck et al.

provide an integrated view on all transformation artifacts nor do they provide an integrated view on the whole transformation process in terms of the past state, i.e., which rules ﬁred already, the current state, and the prospective future state, i.e., which rules are now enabled to ﬁre. Therefore, these approaches provide snapshots of the current transformation state, only. Verification Support of Transformation Languages. Especially in the area of graph transformations, some work has been conducted using Petri Nets to check formal properties of graph transformation rules. Thereby, the approach proposed in [20] translates individual graph transformation rules into a Place/Transition Net and checks for its termination. Another approach is described in [6], where the operational semantics of a visual language in the domain of production systems is described with graph transformations. The models of the production system, as well as the graph transformation rules are transformed into Petri Nets in order to make use of the formal veriﬁcation techniques for checking properties of the production system models. Varr´ o [19] presents a translation of graph transformation rules to transition systems (TS), serving as the mathematical formalism of various diﬀerent model checkers to achieve formal veriﬁcation of model transformations. Thereby, only the dynamic parts of the graph transformation systems are transformed to TS to reduce the state space. Summarizing, these approaches only check for conﬂuence and termination of the speciﬁed graph transformation rules, but compared to our approach, they do not consider additional properties which might be helpful to point out the origin of an error. Additionally, these approaches are using Petri Nets only as a back-end for automatically analyzing properties of transformations, whereas we are using TNs as a front-end for fostering debuggability.

7

Future Work

Since the research is in its initial phase, currently a ﬁrst prototype is available only, which should be evaluated on basis of the following two research questions: Question 1: Does the proposed approach foster the detection of bugs? Regarding this issue, an empirical study will be conducted with students from our model engineering courses (around 200 master students). The aim of this empirical study is to evaluate if the oﬀered debugging facilities lead to decreased time required for detecting a certain bug. In this respect, the students will be divided into subgroups and each subgroup will be provided with an erroneous example in a certain transformation language like ATL, QVT and the TN formalism. Then the students will have to debug the examples with the provided debugging facilities. The evaluation will take place by measuring the time required to ﬁnd the bug. A source to acquire complex transformations scenarios for evaluating this research question could be the GraBaTs tool contest2 . Question 2: Do the oﬀered veriﬁcation possibilities help in ﬁnding bugs? Concerning this question, a test set of erroneous transformation examples will be 2

http://is.tm.tue.nl/staﬀ/pvgorp/events/grabats2009/

Catch Me If You Can – Debugging Support for Model Transformations

19

collected by asking the students of our model engineering course to not only submit the correct version of the assigned transformation example but also to submit preceding erroneous examples. Thereby, we will collect a set of erroneous examples with “real-world” bugs. This test set will then be used to check whether our proposed veriﬁcation possibilities are useful in detecting these bugs.

References 1. Balogh, A., Varr´ o, D.: Advanced model transformation language constructs in the VIATRA2 framework. In: Proc. of SAC 2006 (2006) 2. B´ezivin, J., Rumpe, B., Sch¨ urr, A., Tratt, L.: Model Transformations in Practice Workshop of MoDELS 2005, Montego Bay, Jamaica (2005) 3. Biermann, E., Ermel, C., Taentzer, G.: Precise Semantics of EMF Model Transformations by Graph Transformation. In: Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., V¨ olter, M. (eds.) MODELS 2008. LNCS, vol. 5301, pp. 53–67. Springer, Heidelberg (2008) 4. Brna, P., Brayshaw, M., Esom-Cook, M., Fung, P., Bundy, A., Dodd, T.: An Overview of Prolog Debugging Tools. Instructional Science 20(2), 193–214 (1991) 5. Czarnecki, K., Helsen, S.: Feature-based Survey of Model Transformation Approaches. IBM Systems Journal 45(3), 621–645 (2006) 6. de Lara, J., Vangheluwe, H.: Translating Model Simulators to Analysis Models. In: Proc. of 11th Int. Conf. on Fundamental Approaches to Software Engineering, Budapest, Hungary, April 2008, pp. 77–92 (2008) 7. Geiger, L.: Model Level Debugging with Fujaba. In: Proc. of 6th Int. Fujaba Days, Dresden, Germany, September 2008, pp. 23–28 (2008) 8. Hibberd, M.T., Lawley, M.J., Raymond, K.: Forensic Debugging of Model Transformations. In: Engels, G., Opdyke, B., Schmidt, D.C., Weil, F. (eds.) MODELS 2007. LNCS, vol. 4735, pp. 589–604. Springer, Heidelberg (2007) 9. Jensen, K., Kristensen, L.M.: Coloured Petri Nets - Modeling and Validation of Concurrent Systems. Springer, Heidelberg (2009) 10. Jouault, F., Allilaire, F., B´ezivin, J., Kurtev, I.: ATL: A Model Transformation Tool. Science of Computer Programming 72(1-2), 31–39 (2008) 11. Jouault, F., Kurtev, I.: Transforming Models with ATL. In: Bruel, J.-M. (ed.) MoDELS 2005. LNCS, vol. 3844, pp. 128–138. Springer, Heidelberg (2006) 12. Koenigs, A.: Model Transformation with TGGs. In: Proc. of Model Transformations in Practice Workshop of MoDELS 2005, Montego Bay, Jamaica (2005) 13. Kristensen, L., Valmari, A.: Finding Stubborn Sets of Coloured Petri Nets without Unfolding. In: Desel, J., Silva, M. (eds.) ICATPN 1998. LNCS, vol. 1420, pp. 104– 123. Springer, Heidelberg (1998) 14. Kusel, A.: TROPIC - A Framework for Building Reusable Transformation Components. In: Proc. of the Doctoral Symposium at MoDELS, Technical Report 2009566, School of Computing, Queen’s University, Kingston, Canada (2009) 15. Lawley, M., Steel, J.: Practical Declarative Model Transformation with Tefkat. In: Bruel, J.-M. (ed.) MoDELS 2005. LNCS, vol. 3844, pp. 139–150. Springer, Heidelberg (2006) 16. Murata, T.: Petri nets: Properties, analysis and applications. Proc. of the IEEE 77(4) (1989) 17. Object Management Group. Meta Object Facility (MOF) 2.0 Query/View/ Transformation Speciﬁcation (2007), http://www.omg.org/docs/ptc/07-07-07.pdf

20

J. Schoenboeck et al.

18. Sch¨ atz, B.: Formalization and Rule-Based Transformation of EMF Ecore-Based Models. In: Gaˇsevi´c, D., L¨ ammel, R., Van Wyk, E. (eds.) SLE 2008. LNCS, vol. 5452, pp. 227–244. Springer, Heidelberg (2009) 19. Varr´ o, D.: Automated Formal Veriﬁcation of Visual Modeling Languages by Model Checking. Journal of Software and Systems Modelling 3(2), 85–113 (2003) 20. Varr´ o, D., Varr´ o-Gyapay, S., Ehrig, H., Prange, U., Taentzer, G.: Termination Analysis of Model Transformation by Petri Nets. In: Proc. of Int. Conf. on Graph Transformation, Natal, Brazil, pp. 260–274 (2006) 21. Wagner, R.: Developing Model Transformations with Fujaba. In: Proc. of the 4th Int. Fujaba Days 2006, Bayreuth, Germany, pp. 79–82 (2006) 22. Wimmer, M., Kappel, G., Kusel, A., Retschitzegger, W., Schoenboeck, J., Schwinger, W.: Right or Wrong? - Veriﬁcation of Model Transformations using Colored Petri Nets. In: Proc. of 9th OOPSLA Workshop on Domain-Speciﬁc Modeling, Orlando, USA (2009) 23. Wimmer, M., Kappel, G., Sch¨ onb¨ ock, J., Kusel, A., Retschitzegger, W., Schwinger, W.: A Petri Net based Debugging Environment for QVT Relations. In: Proc. of the 24th Int. Conf. on ASE 2009, pp. 1–12 (2009) 24. Wimmer, M., Kusel, A., Reiter, T., Retschitzegger, W., Schwinger, W., Kappel, G.: Lost in Translation? Transformation Nets to the Rescue! In: Proc. of 3rd Int. United Information Systems Conf., Sydney, Australia, pp. 315–327 (2009)

A Coordination-Based Model-Driven Method for Parallel Application Development Stefan Gudenkauf1,2 1

1

OFFIS Institute for Information Technology, R&D-Division Energy, Escherweg 2, 26121 Oldenburg, Germany 2 Software Engineering Group, Department of Computer Science, Christian-Albrechts-Universit¨ at zu Kiel, Christian-Albrechts-Platz 4, 24118 Kiel, Germany [email protected]

Motivation

A continuous trend in computing is the demand for increasing computing performance. Provided that the problem space allows a solution that can be separated in parts to be computed independently, parallel systems oﬀer a performance that exceeds that of sequential systems. To continue to improve processor performance, companies such as Intel and AMD have turned to hyper-threading and multi-core architectures [1]. With the advent of multi-core processors in the consumer market in 2005, parallel systems have moved out of the scientiﬁc niche and became a commodity [2]. Industry today is relying on hyper-threading and increasing processor count per chip as the new performance drivers since physical limitations impede further performance gains that are based on increasing clock speed and optimizing execution ﬂow1 . These new performance drivers make it necessary to explicitly consider concurrency. Unfortunately, after years of sequential programming practice the majority of software developers today are short on parallel programming experience, and at least in the near future there will be no tools and techniques to fully exploit concurrency automatically. Although being the predominant model for generalpurpose parallel programming, the threading model makes parallel programming harder than it has to be because it is enormously nondeterministic and requires software developers to cut away unwanted nondeterminism by means of synchronization [3]. The immense number of possible interleavings of thread instructions makes it extremely diﬃcult to reason about the actual behavior of a threaded application. There already exist communities with rich parallel computing knowledge, but often this knowledge only applies to solve distinct problems in well-understood domains (e.g., simulation). Even though many concepts of parallel programming are sound, parallel software engineering practice 1

Although cache size remains as a performance source one can easily beneﬁt from, the number of processors per chip increases much faster than the size of on-chip cache and the available memory channels. On-chip cache is therefore a severe performancelimiting factor.

S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 21–35, 2010. c Springer-Verlag Berlin Heidelberg 2010

22

S. Gudenkauf

is still immature, and traditional parallel programming communities are solely concerned with increasing performance but not software engineering in general. However, concurrency now has to be exploited in applications of all kinds and application domains, whether distributed or not. The challenge is not solely software performance and speedup in comparison to an equivalent serial application, but also to provide a convenient way to participate in the new performance drivers in general, and to facilitate reuse and portability. Especially the latter aspects may turn out to be of major importance in parallel programming in the large because of the high development costs of (re-)developing failure-safe parallel software. This raises several questions. What is the adequate level of abstraction on which concurrency should be explicitly considered by ordinary software engineers? How should appropriate methods and tooling to facilitate the development of parallel programs for ordinary software developers look like? The goal of this work is to address these questions by providing a top-down methodology that supports ordinary software developers in the development of parallel applications, that can be applied to a broad spectrum of application domains, and that integrates well with diﬀerent technological platforms. The overall approach is based on combining coordination modeling with model-driven development. The expected contributions of this work are a coordination metamodel, at least one concrete syntax for the metamodel as a DSL, appropriate prototype tooling, and an extensive evaluation of method application. The rest of this paper is organized as follows. In Sec. 2, we describe the targeted domain. Subsequently, we present our method in Sec. 3 and discuss the envisioned DSL in Sec. 4. In Sec. 5 we illustrate our plans on evaluation. In Sec. 6 we present related work, followed by future work in Sec. 7 and a conclusion in Sec. 8.

2

Domain Description

We deﬁne our target domain as parallel systems software engineering. Regarding the software development stages construction, debugging, and performance tuning (cf. [4]), we focus on program construction. Also, we regard the threading model as the primary technology from which we abstract. We further focus on the behavioral view, regarding the behavior of a software system as processes that represent active entities that lie within a global object space. Within a process, application engineers are encouraged to decompose their problem in terms of sub-processes (partitions of a process) and tasks (nodes of computation) to be performed sequentially or in parallel, and control ﬂows between them. Data ﬂows and passive data objects are also parts of the domain. Table 1 presents an overview of these concepts.

3

Method Overview

As an answer to the challenges motivated in Sec.1, we propose a top-down method that supports ordinary software developers in the development of parallel applications. This method emphasizes top-down problem decomposition (1),

A Coordination-Based Model-Driven Method

23

Table 1. Overview of domain concepts Concept

Description

Process

An active entity within a global object space (virtual address space) that executes tasks and sub-processes in a predeﬁned order whereas the number of processes does not have to equal the number of actual processing units (processors) and is determined by the problem decomposition. A process that is a partition of a superordinateprocess in the same global object space. An atomic active entity (node) of computation that can be executed sequentially or in parallel with other tasks and sub-processes, and that can create, read, and consume data objects. A passive entity within the global object space of a superordinate process that can be created, read, and consumed by tasks. The explicit speciﬁcation of the order of activity of active entities including decisions such as parallel-and, or, and exclusive-or. The explicit speciﬁcation of the availability of data objects as a prerequisite or postcondition of task activity within the global object space of a superordinate process.

Sub-Process Task

Data Object Control Flows Data Flows

and the introduction of nondeterminism when it is needed, instead of cutting it away when it is not needed (2). Also, the method shall be applicable to diﬀerent application domains (3) and target platforms (4). Problem decomposition shall be separated from the actual mapping of logical units of execution (UEs) to physical processing entities (PEs) (5), thus leaving the mapping to subsequent activities, for example, model transformations or run-time scheduling. Finally, the development of large-scale parallel programs shall be facilitated (6). The overall approach is based on combining coordination modeling [5,6] with model-driven software development (MDSD) [7]. In general, a coordination model deﬁnes the interaction of active and independent entities, whereas the interaction is subject to certain coordination laws that specify how entities coordinate themselves through the given coordination media [8]. In our domain, these entities are processes or tasks, see Sec. 2. Coordination modeling is then the creation of a coordination model. Since such a model represents a highlevel abstraction of a parallel program that focuses on coordination, it can be subject to reusable coordination patterns [9,10,11]. Model-driven software development (MDSD) [7], on the other hand, regards models as ﬁrst class development artifacts that are speciﬁed using suitable modelling languages denoted as domain-speciﬁc languages (DSL). These models are signiﬁcantly more abstract and domain-oriented than executable implementation code, and usually cannot be executed per se. Instead, they have to be translated into executable code for a speciﬁc platform by using model transformations and model transformation infrastructures. A series of model transformations typically ends with a modelto-code transformation that results in the executable code.

24

S. Gudenkauf uses

Outline creates

Coordination Model

element Of

DSL

source Application Engineer

Transformation Developer Transformations

creates

target

creates

Domain Engineer

Domain-Specific Sequential Code

target

Coordination Code

target

Framework optional

target Platform Software Product

Fig. 1. Method overview

Figure 1 presents an overview of the method. The ﬁrst step is to create a coordination model of the intended parallel application. This is done by so-called application engineers by using an appropriate DSL. The DSL essentially emphasizes the introduction of nondeterminism when it is needed, instead of cutting it away when it is not needed, as discussed in Sec. 4. Secondly, the coordination model is transformed into the source code of the target platform that represents the coordination structure of the parallel program (i.e., the implementation of coordination in source code). The required model-to-code transformations are provided by transformation developers. The coordination code is then complemented with application domain-speciﬁc sequential code that is provided by domain engineers. Table 2 presents an overview of the diﬀerent roles that are involved in the method. The beneﬁts of the approach are as follows: Knowledge capture: Models provide a basis for communication between application engineers, transformation developers, and domain engineers. Reuse and portability: Reference models and transformations can be reused, providing a basis for software product families [12]. Diﬀerent target platform transformation sets can also be applied to the same coordination model. Quality: Model bugs, as well as the respective responsibilities, are separated from implementation bugs – the former having to be corrected only once in the transformation descriptions instead of multiple times in the source code. Information hiding: Transformations encapsulate platformspeciﬁc coordination implementation, thus relieving application engineers and domain engineers. Development time reduction: Reusing models and transformations can save development time. However, we expect the approach to be biased towards object-orientation. Regarding the notion of active tasks, data objects, and composability, the implementation of the actual model-to-code transformations can be highly oriented

A Coordination-Based Model-Driven Method

25

Table 2. Overview of the roles that are involved in the proposed methodology Role

Responsibilities

Description

Application Design coordiEngineer nation model, apply coordination patterns, specify target platform

The role is tightly related to the transformation developer since transformations may have to be adapted for reuse or developed from scratch. Application engineers are software developers (architects) that gained experience in coordination modeling.

Transformation Developer

Provide model-tocode transformations as concrete embodiment of coordination

The role is tightly related to the application engineer in that the application engineer speciﬁes the target platform and technologies to be used for coordination implementation. Transformation developers are experts in parallel programming using the respective target platform technologies.

Domain Engineer

Design sequential code as concrete embodiment of application-speciﬁc computation

The role is concerned with designing and implementing application-speciﬁc functionalities as sequential code that is required by the generated coordination code in order to represent a complete software product. Domain engineers are software developers (programmers) that gained experience in implementing thread-safe sequential code.

towards object-oriented target platforms. The implementation with non-objectoriented programming languages may therefore turn out to be at least cumbersome.

4

Coordination DSL

Developing parallel applications using traditional programming languages can be tedious and error-prone due to the linearity of textual source code. Visual DSLs are multi-dimensional, thus able to present multiple concurrent control ﬂows naturally, while ﬁne-grained concurrency control may be encapsulated in appropriate language feature semantics [13,14]. With the purpose of modeling the coordination of the active entities of a parallel program, the intended DSL can clearly be characterized as a coordination language, “the linguistic embodiment of a coordination model” [5]. Since it is also process-oriented, it can also be identiﬁed as a process language. Outgoing from these characterizations we require our DSL to conform to the requirements presented in Tab. 3. Figure 2 illustrates the domain concepts from Sec. 2 by annotations to an example notation that is based on the Business Process Modeling Notation (BPMN)2 . RQ-1 and RQ-2 are obviously addressed by providing a visual graphbased notation. RQ-3 (domain orientation) is a subject to domain modeling and 2

For illustration, we selected BPMN in favor to, for example, UML Activity Diagrams because we ﬁnd BPMN to result in more compact diagrams.

26

S. Gudenkauf Table 3. DSL requirements

Key

Description

RQ-1

Visuality. The DSL must be visual to present multiple concurrent control ﬂows naturally. Graph Orientation. The DSL must be graph-based. Domain Orientation. Language constructs must conform to domain concepts, ideally providing distinct constructs for each distinct concept. Orthogonality. The DSL must be orthogonal to existing sequential programming languages without forcing them to modify their functionality, cf. [5,15]. Simplicity. The vocabulary of the language shall be as small as possible, providing a clear and manageable set of core concepts. Performance. Language constructs shall enable performance of application [16] by matching well to the underlying technological platforms, cf. [16]. Portability. Programming abstractions must be provided that may be implemented on top of various types of parallel computing systems [15]. These abstractions must allow the use of language features without mandating them [16]. Overall generality in the sense of a general purpose coordination model is desirable[5]. Composability. The DSL must provide means for hierarchical abstractions to allow the composability of models, cf. Fig. 2. Coordination Explicity. Concurrency must be expressed explicitly as the interaction of active entities, whereas the interaction is subject to certain coordination laws that specify how entities coordinate themselves through the given coordination media [8]. Control-Driven Modeling. The language should foster control-driven before data-driven modeling since modeling should be concerned with the actual order of computation before considering data availability and data transformations.

RQ-2 RQ-3 RQ-4 RQ-5 RQ-6 RQ-7

RQ-8 RQ-9

RQ-10

the provision of an abstract syntax for the DSL, for example, in the form of a metamodel. RQ-4 (orthogonality) is met since the diagram does not specify any computational aspects. Tasks simply represent nodes of computation. A language that is based on the domain description can therefore be clearly characterized as a coordination language [5]. Regarding RQ-5, it is important to remember that simplicity does not necessarily mean that the overall number of concepts is restricted. Instead, it is more important that the number of concepts that the user must learn to achieve a certain goal, along with the number of exceptions and special cases of usage, is not too large [16]. However, whether RQ-5 is met is hard to determine since it is not clear what a manageable number of concepts is, because this highly depends on the concrete language and its abstract syntax. When it comes to evaluation, expert statements on language simplicity can be considered as a metric. RQ-6 (performance) is closely related to RQ-3. It can be addressed by sound abstractions from the underlying technological platform and the expressiveness to model scalable algorithms and patterns [9]. RQ-7 (portability) can be met by providing a DSL that abstracts from diﬀerent types of

A Coordination-Based Model-Driven Method

27

parallel computing systems and models, thus allowing a widespread adoption. RQ-8 (composability) is addressed by the notion of sub-processes that represent partitions of a process, composable data objects, and a hierarchical object space (possibly as a special kind of data object). Considering processes and tasks as the fundamental active entities also meets RQ-9 (coordination explicity) and RQ-10 (control-driven modeling), whereas the concurrent execution of the same computation may be encapsulated in appropriate language feature semantics that represents multiple-instantiability to reduce the cognitive load of the application engineer during modeling [13,14]. For data ﬂow modeling, we intend to employ a data-sharing approach for tasks and data objects that is based upon object orientation and generative communication [15,17]. While object-orientation provides composable, self contained entities that are protected by their interfaces, generative communication allows communication partners to be uncoupled from each other. Originally, the idea of generative communication was introduced by the Linda coordination model [17]. In the Linda model, processes (i.e., the coordination entities) communicate by publishing tuples (i.e., ordered collections of primitive data items) into a socalled tuple space by out operations and by reading or consuming tuples from the tuple space by read or in operations. Thereby, processes wait until a tuple to be read or consumed actually has been inserted into the tuple space. The decision which tuple is to be read or consumed is made by a template speciﬁcation on the side of the reader or consumer, and tuple matching is performed by the tuple space. Both tuples and tuple templates may consist of actual fields (i.e., typed values) and formal fields (i.e., placeholders for speciﬁc data types). A tuple is regarded as matching a given template if their arities are equal, and if each actual ﬁeld in the tuple matches an actual ﬁeld of the same type and value, or a formal ﬁeld of the same type in the template. Additionally, an eval operation invokes new processes by publishing active tuples that ﬁnally turn into passive tuples after evaluation. Figure 3 illustrates data ﬂow modeling for the envisioned DSL. With respect to the Linda model, we currently regard out, in, and read data ﬂows. An out data ﬂow publishes one or more data objects into an object space, in consumes objects from an object space, and read simply reads objects without alteration or modiﬁcation. An eval data ﬂow is omitted since it would require active data objects that ﬁnally turn into passive ones, and since it conﬂicts with RQ-9 because of implicit concurrency. We denote this design as Linda-style concurrency due to the following two properties (cf. [17]): Time decoupling: A task A with an out-statement may run to completion before a task B with an in-statement is executed. Space decoupling: An object in an object space may be input by any number of object space-disjoint tasks. However, the consideration of Linda-Style concurrency for data ﬂow modeling between active tasks and passive objects is ongoing work and will be elaborated in future work, for example, regarding object matching, an (hierarchical) object model and the deﬁnition of data ﬂow operations.

28

S. Gudenkauf

Fig. 2. Domain concepts illustrated by Fig. 3. Data ﬂows and data objects illusannotations to a BPMN diagram trated by annotations to a BPMN diagram

5

Plans on Evaluation

Figure 4 shows an overview of our evaluation method. In the ﬁrst step, we identify the evaluation subject by deﬁning requirements and checking possible candidates. Table 4 presents these requirements. When the subject is identiﬁed, we determine the type of evaluation. This will also be done by deﬁning requirements and checking evaluation type candidates. Essentially, the outcome of this step speciﬁes if the evaluation is based, for example, on case studies, lab experiments or controlled experiments. The following step is to employ a goal-question-metric (GQM) approach [18] in order to perform the actual evaluation. The ﬁnal step will be the analysis of the results for conformance with the hypotheses. The hypotheses that underly the GQM approach are: Development : Using a method that is based upon the combination of explicit coordination modeling of a parallel program and model-driven techniques for code generation facilitates the development of parallel programs for ordinary software engineers. Participation: Using such a method enables to participate in the new performance drivers

Fig. 4. Evaluation methodology

A Coordination-Based Model-Driven Method

29

Table 4. Evaluation subject requirements Key

Description

RQ-A1

The source code of a possibly underlying (sequential) version of the application must be open source. The documentation of the solution algorithms and the functional principles must be available. The solution algorithms and functional principles must allow to realize a parallel application that is functionally equivalent to a sequential version, if available. Application size and complexity must be aligned to the organizational frames of the evaluation. In particular, it must be possible to design and implement the application regarding the given time frame. The technical realization of concurrency-related aspects of the application must be based on the threading model. The exemplary application should have a purpose that is relevant to the respective domain. The parallelization of the application should provide a reasonable speedup in contrast to a sequential version of the application, and should represent an added value (e.g., cost reduction, increased quality) to the respective domain.

RQ-A2 RQ-A3

RQ-A4

RQ-A5 RQ-A6 RQ-A7

multicore and hyper-threading. Scope: The method is applicable to a number of application domains – i.e., it is not restricted to a single application domain. We plan the actual evaluation to be two-fold: The ﬁrst part is to examine what coordination and parallel programming patterns can be expressed by the envisioned DSL, for example, those that are described in [15,11] and [19]. The second part is concerned with conducting experiments or case studies on developing an exemplary parallel application using the proposed method. A currently considered application candidate is the BZip23 compression tool that is available unter a BSD-style license. Its algorithms are well-documented and there are parallel C++ versions available4 that may possibly be used as control samples within a controlled experiment. Regarding threats to validity, the most important threat is the fact that we intend to use expert statements to address some of the questions in the GQM approach. Experts must, however, be identiﬁed beforehand and also must be able and willing to allocate enough time and effort to provide qualiﬁed statements. We will address this by providing backup statements ourselves if experts cannot be consulted.

6

Related Work

The following related work is separated in challenges in parallel programming, related model-driven approaches, aspect orientation, and software architecture description. 3 4

http://www.bzip.org/ C++ w/ PThreads (http://compression.ca/pbzip2/), and MPI (http://compression.ca/mpibzip2/)

30

6.1

S. Gudenkauf

Challenges in Parallel Programming

Lee argues that most of the diﬃculties in parallel programming are a consequence of our concurrency abstractions [3]. He shows that the threading model, although being a minor syntactical extension to existing languages, implies severe consequences to programming since it is enormously nondeterministic and requires to cut away unwanted nondeterminism by means of synchronization. This is because the immense number of possible interleavings of thread instructions makes it extremely diﬃcult to reason about the actual behavior of an application. Coordination languages can provide a solution, since they are orthogonal to established programming languages, focus on deterministic communication and cooperation between the computational parts of a program, and can be subject to coordination patterns [5,6,8,15,9]. Pankratius et al. present a case study on parallelizing the open source compression program BZip2 for multicore systems [20]. At least in the context of this study, it is shown that considerable speedup can be gained by exploiting concurrency on higher abstraction levels, and that parallel patterns turned out to be more signiﬁcant to speedup than ﬁne-grained loop parallelization. In contrast, it is noted that industry often claims the feasibility of incremental parallelization by simply inserting such ﬁne-grained parallelization constructs in existing sequential code, and the use of parallel libraries. These approaches limit the amount of exploitable concurrency since the overall problem solution remains sequential. Lee also speculates that most existing multithreaded programs have concurrency bugs that do not show up only because the underlying computer architectures and operating systems currently provide modest parallelism, so that only a small percentage of possible interleavings of thread instructions occurs [3]. Also, even if a programmer’s code never creates a thread, frameworks may create threads on behalf of the programmer, and thus require the code that is called from these threads to be thread-safe [21]. 6.2

Model-Driven Software Development

There are few approaches in model-driven parallel program development. IBM alphaWorks provides a tool that generates parallel code from UML models and supports concurrent patterns for multicore environments [22]. Using the tool involves diﬀerent activities such as the creation of concurrency patterns by pattern developers and so-called serial computing kernels by C++ developers. The approach requires Rational (e.g., Rational System Developer), and a C++ compiler that supports OpenMP. There is few information available and the current status of the project is unclear. In [23], Tan et al. present an infrastructure to use generative design patterns to generate parallel code for distributed and shared memory environments. The approach requires programmers to select appropriate parallel design patterns, and to adapt the selected patterns for the speciﬁc application by selecting codeconﬁguration options from a set of such options.

A Coordination-Based Model-Driven Method

31

Hsiung et al. present an approach on the model-driven development of multicore embedded software [24]. The approach is based on using SysML models as an input, and generates multi-core embedded software code in C++. The code architecture consists of an OS, the Intel Threading Building Blocks library [25], a framework for executing concurrent state machines, and the application code. In [26], Pllana et al. propose an intelligent programming environment that targets multi-core systems and proactively supports a user in program composition, design space exploration, and resource usage optimization. This environment is envisioned to combine model-driven development with software agents and high-level parallel building blocks to automatize time-consuming tasks such as performance tuning. UML extensions are proposed for graphical program composition. In his Intel white paper, Lingam brieﬂy presents the Microsoft Integration Services platform as a means for building parallel applications by the example of a video conversion and FTP example, emphasizing that “Model Driven Development is a fantastic way to take advantage of multi-core computing infrastructure” [27]. While the article falls short on presenting actual realization details of the example, we regard it as an evidence that model-driven software development is gaining momentum in the parallel programming domain. The presented related work has commonalities with our aproach, but there are also diﬀerences and drawbacks that justify our approach. For example, [22] and our approach share the emphasis on separation of concerns. However, in contrast to [22] our approach is not restricted to a speciﬁc target platform. [23] and the proposed approach share the abstraction of architectural details, but our approach does not require to modify generated code for ﬁne tuning. [26] also intends to apply model-driven techniques for parallel program development, but focuses on multi-core systems and task automation, for example, for performance tuning. [24] is restricted to multi-core embedded software only and abstracts from a very speciﬁc target platform. Our approach instead intends to be applicable for both parallel and distributed systems. 6.3

Aspect Orientation

Aspect orientation regards the modularization of cross-cutting concerns (CCCs) in software systems [28], where CCCs are concerns that can not normally be associated with a single module or component in the respective systems because of the limited capabilities of the underlying programming languages and platforms. While aspect orientation in general aims at the modularization and localization of such CCCs, aspect oriented programming (AOP) speciﬁcally aims at introducing programming language constructs to handle CCC modularization. Although there are many commonalities between AOP and MDSD, we regard our approach clearly as an MDSD approach because of the following reasons (cf. [28]). Abstraction level : A fundamental concept of MDSD is to express a problem solution on a higher level of abstraction that is more closely aligned with the problem domain. To do so, MDSD employs domain-speciﬁc languages. AOP, on the contrary, is bound to the level of abstraction of the system for

32

S. Gudenkauf

which it handles CCCs. Pre-run-time: MDSD transformations are typically executed before the run-time of the system to be developed. Therefore, MDSD approaches can generate non-programming language artifacts such as conﬁguration ﬁles, build scripts and documentation. On the contrary, AOP is dynamic in nature and contributes behaviour to speciﬁc points during the run-time of a system, but can not aﬀect any artifacts that are relevant before runtime. However, as Favre notices, separation of concerns is an intrinsic property of model engineering (i.e., “the disciplined and rationalized production of models” [29]) that naturally leads to aspect-oriented modeling [29]. Since the presented approach is based upon separation of concerns by coordination modeling as the underlying principle to ease parallel program development, our approach may also be denoted as aspect-oriented modeling (AOM). 6.4

Software Architecture Description

Software architecture can be deﬁned as “the structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time” [30,31]. It can be speciﬁed by architectural description languages (ADLs) – formal languages that deal with the speciﬁcation of a systems global structure by deﬁning its basic elements denoted as components, and the interactions between them in form of interfaces as connectors. Thereby, ADLs can both describe single architectures denoted as configurations, or whole families of architectures denoted as architectural styles. Coordination theory, on the other hand, can be deﬁned as “the management of dependencies between activities” [32]. This is achived by using coordination languages (CLs), whereas a coordination language is “the linguistic embodiment of a [comprehensive] coordination model” [5]. Although ADLs and CLs have evolved separately and with diﬀerent goals and emphasis, they share common abstractions. This is especially the case when the architectures of complex parallel and distributed systems are considered. ADLs have at least the potential to coordinate interactions between the components of a software architecture and can therefore also be considered as CLs or dynamic ADLs, and a certain coordination model can be described either as an architectural style or as the foundation of an ADL [33]. Conversely, CLs can describe the structures of programs (i.e., their architectures) that change over time, and can therefore also be considered as dynamic ADLs. Although we emphasize the coordination of activities before architectural description, thus denoting our DSL as a coordination language, we regard the two terms dynamic architecture description language and coordination language as interchangeable. For the sake of brevity, we do not provide an overview of existing ADLs and CLs, but recommend [34,6] as a starting point for an extensive study for the interested reader. In their work on dynamic coordination architecture through the use of reﬂection, Cuesta et al. provide a good overview of the interrelationship between coordination theory and software architecture, and provide PiLar as an example that is both considered as a dynamic ADL and a CL.

A Coordination-Based Model-Driven Method

7

33

Future Work

To provide a reﬁned domain model, relevant concepts, their (shared and diﬀerentiating) features, and additional requirements have to be further identiﬁed. This can be done by identifying and analyzing reference applications for repetitive patterns [14]. Since the targeted domain is technical, we will focus on applications that employ the same underlying technologies but target diﬀerent business domains in order not to identify business domain concepts as target domain concepts by mistake. Also, the consideration of Linda-Style concurrency is ongoing work, for example, regarding object matching, an (hierarchical) object model and the deﬁnition of data ﬂow operations. There are a number of coordination languages that target to reduce complexity by representing parallel program behavior visually [13,6,35]. We will examine them for applicability as a DSL. We also suppose that (stereotyped) UML activity diagrams and the Business Process Modeling Notation (BPMN) meet many of the DSL requirements. Both are well-known and may provide a basis for the visual DSL with prospect of broad dissemination, provided that the underlying semantics remain fundamentally intact. Prototype tooling may comprise a modeling environment based on the Eclipse Modeling Tools5 and the openArchitectureWare MDA/MDD generator framework6 , and appropriate model transformations. Regarding DSL construction, we intend to develop a textual DSL prototype using the Xtext framework and an Ecore metamodel (omitting RQ-1 and RQ-2) in the ﬁrst place. Then, we will provide a mapping to a visual DSL as soon as we regard the domain model as sound.

8

Conclusion

In this position paper we discussed the need for higher abstractions in parallel software development. This need is motivated by the inappropriateness of the threading model since it requires to tame nondeterminism, the lack of parallel programming experience, and the supposed impact of higher-level abstractions on application performance. To satisfy this need, we proposed a model-driven method that regards the coordination model of parallel programs as the ﬁrst development artifact, and envisioned an adequate coordination language.

References 1. Sutter, H.: The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software. Dr. Dobb’s Journal 30 (2005) 2. Marowka, A.: Parallel Computing on any Desktop. Commun. ACM 50, 74–78 (2007) 5 6

http://www.eclipse.org http://www.openarchitectureware.org/

34

S. Gudenkauf

3. Lee, E.A.: The Problem with Threads. IEEE Computer 39, 33–42 (2006) 4. Zhang, K., Ma, W.: Graphical Assistance in Parallel Program Development. In: Proc. of the 10th IEEE Intl. Symp. on Visual Languages, pp. 168–170 (1994) 5. Gelernter, D., Carriero, N.: Coordination Languages and their Signiﬁcance. Communications of the ACM 35, 97–107 (1992) 6. Papadopoulos, G.A., Arbab, F.: Coordination Models and Languages. In: Advances in Computers, pp. 329–400. Academic Press, London (1998) 7. V¨ olter, M., Stahl, T.: Model-Driven Software Development, 1st edn. Wiley & Sons, Chichester (2006) 8. Ciancarini, P.: Coordination Models and Languages as Software Integrators. ACM Computing Surveys 28, 300–302 (1996) 9. Freisleben, B., Kielmann, T.: Coordination Patterns for Parallel Computing. In: Garlan, D., Le M´etayer, D. (eds.) COORDINATION 1997. LNCS, vol. 1282, pp. 414–417. Springer, Heidelberg (1997) 10. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns. In: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, Reading (1995) 11. Mattson, T.G., Sanders, B.A., Massingill, B.L.: Patterns for Parallel Programming, 3rd edn. Addison-Wesley/Pearson Education, Inc., Boston (2007) 12. Withey, J.: Investment Analysis of Software Assets for Product Lines. Technical Report CMU/SEI-96-TR-010, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA (1996), http://www.sei.cmu.edu 13. Browne, J.C., Dongarra, J., Hyder, S.I., Moore, K., Newton, P.: Visual Programming and Parallel Computing. Technical report, University of Tennessee, Knoxville, TN, USA (1994) 14. Kleppe, A.: Software Language Engineering: Creating Domain-Speciﬁc Languages Using Metamodels. Addison-Wesley Professional, Reading (2008) 15. Freisleben, B., Kielmann, T.: Object-Oriented Parallel Programming with Objective Linda. Journal of Systems Architecture (1997) 16. Gropp, W.: Learning from the Success of MPI. In: HiPC, pp. 81–94 (2001) 17. Gelernter, D.: Generative Communication in Linda. ACM Trans. Program. Lang. Syst. 7, 80–112 (1985) 18. Basili, V.R., Caldiera, G., Rombach, H.D.: The Goal Question Metric Approach. In: Encyclopedia of Software Engineering, pp. 528–532. Wiley, Chichester (1994) 19. van der Aalst, W.M.P., Hofstede, T.A.H.M., Kiepuszewski, B., Barros, A.P.: Workﬂow Patterns. Distributed and Parallel Databases 14, 5–51 (2003) 20. Pankratius, V., Jannesari, A., Tichy, W.F.: Parallelizing BZip2. A Case Study in Multicore Software Engineering. Technical report, University of Karlsruhe (2008) 21. Goetz, B.: Java Concurrency in Practice, 7th Printing edn. AddisonWesley/Pearson Education, Inc. (2009) 22. IBM alphaWorks: Model-Driven Development Tool for Parallel Applications, http://www.alphaworks.ibm.com/tech/ngspattern (Date posted November 1, 2007) (last visited December 21, 2009) 23. Tan, K., Szafron, D., Schaeﬀer, J., Anvik, J., MacDonald, S.: Using Generative Design Patterns to Generate Parallel Code for a Distributed Memory Environment. ACM SIGPLAN Notices 38, 203 (2003) 24. Hsiung, P.A., Lin, S.W., Chen, Y.R., Hsueh, N.L., Chang, C.H., Shih, C.H., Koong, C.S., Lin, C.S., Lu, C.H., Tong, S.Y., Su, W.T., Chu, W.C.: Model-Driven Development of Multi-Core Embedded Software. In: ICSE Workshop on Multicore Software Engineering, pp. 9–16 (2009) 25. Reinders, J.: Intel Threading Building Blocks. O’Reilly, Sebastopol (2007)

A Coordination-Based Model-Driven Method

35

26. Pllana, S., Benkner, S., Mehofer, E., Natvig, L., Xhafa, F.: Towards an Intelligent Environment for Programming Multi-core Computing Systems. In: Eduardo, C., Alexander, M., Streit, A., Tr¨ aﬀ, J.L., C´erin, C., Kn¨ upfer, A., Kranzlm¨ uller, D., Shantenu, J. (eds.) Euro-Par 2008 Workshops - Parallel Processing. LNCS, vol. 5415, pp. 141–151. Springer, Heidelberg (2009) 27. Lingam, C.: Rapid Parallel Application Development. Technical report, Intel Software Network (2009) 28. V¨ olter, M.: Patterns for Handling Cross-Cutting Concerns in Model-Driven Software Development. Technical report, EuroPLoP 2005 (2005); copyright 2005 Markus V¨ olter. Permission is hereby granted to copy and distribute this paper for the purposes of the EuroPLoP 2005 conference 29. Favre, J.M.: Foundations of Model (Driven) (Reverse) Engineering: Models Episode I: Stories of The Fidus Papyrus and of The Solarus. In: Language Engineering for Model-Driven Software Development (2004) 30. Garlan, D., Perry, D.E.: Introduction to the Special Issue on Software Architecture. IEEE Trans. Softw. Eng. 21, 269–274 (1995) 31. IEEE Computer Society: IEEE 1471-2000 Recommended Practice for Architectural Description for Software-Intensive Systems. Technical report. IEEE Computer Society (2000), http://ieeexplore.ieee.org/servlet/opac?punumber=7040 32. Malone, T.W., Crowston, K.: The Interdisciplinary Study of Coordination. ACM Comput. Surv. 26, 87–119 (1994) 33. Quintero, C.E.C., de la Fuente, P., Barrio-Sol´ orzano, M.: Dynamic Coordination Architecture through the use of Reﬂection. In: SAC, pp. 134–140 (2001) 34. Medvidovic, N., Taylor, R.N.: A Framework for Classifying and Comparing Architecture Description Languages. In: ESEC/SIGSOFT FSE, pp. 60–76 (1997) 35. Lee, P.A., Webber, J.: Taxonomy for Visual Parallel Programming Languages. Technical report, School of Computing Science, University of Newcastle upon Tyne, Technical Report CS-TR-793 (2003)

Essentials of the 5th Educators’ Symposium at MODELS 2009 Robert France1 and Martin Gogolla2 1 2

Colorado State University, USA University of Bremen, Germany

Abstract. This paper reports on the Educators’ Symposium held at the MODELS 2009 conference. It shortly explains motivation of the symposium, shows the accepted papers of the symposium and mentions the people who have contributed.

1

Motivation

As in past years, the 5th MODELS Educators’ Symposium was held at the MODELS conference, which was held in Denver, Colorado. The focus of the this version of the symposium was on analyzing experience related to teaching modeling techniques and on developing resources to support eﬀective training of future MDD practitioners. In the call for papers we encouraged authors to submit articles on 1. education artifacts that can be eﬀectively shared through a community-based MDD resource, 2. descriptions of existing community-based MDD education resources, and 3. plans for developing and maintaining community-based education resources.

2

Contributions

We received four very good submissions to the symposium which were presented in the morning sessions. The paper titled “Teaching Model Engineering in the Large” by Petra Brosch et al. describes experience related to teaching an advanced course on model engineering at Vienna University of Technology, Austria. Students in the course were required to build their own modeling environments. The environments included domain speciﬁc languages, model transformations and code generators. The paper titled “Experiences of Teaching Model-Driven Engineering in a Software Design Course” by Peter J. Clarke et al. describes the authors’ experience with incorporating software modeling material into a software design course at Florida International University (FIU), Florida, USA. The paper described the communication service framework that was used as the basis for the class project. The authors also discussed the results of a student survey on the eﬀectiveness of current modeling techniques and tools. S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 36–39, 2010. c Springer-Verlag Berlin Heidelberg 2010

Essentials of the 5th Educators’ Symposium at MODELS 2009

37

The third paper that was presented at the symposium is titled “Abstract thinking: A predictor of modeling ability?” and was written by Patricia Roberts. In that paper, the author discussed a survey mechanism used in a study on the relationship between abstract thinking abilities and success in the Computer Science discipline. The fourth paper that was presented, titled “Teaching Models@BIG: On Efﬁciently Assessing Modeling Concepts”, written by Marion Brandsteidl et al., discussed the experience of the authors from Vienna University of Technology gained when teaching an introductory course on object-oriented modeling. The paper focused on how student modeling skills and knowledge were assessed and the tests used in the assessments. The submitted papers are all available on the following website: http://www. cs.colostate.edu/models09/edusymp.html#acceptedPapers In addition to the presentation of submitted papers, we invited educators with signiﬁcant experience or working on major projects to present their views on issues related to the focus area. Oystein Haugen was invited to give an opening talk in which he presented his experience with teaching modeling techniques at the University of Oslo. Sabine Moisan and Jean-Paul Rigault presented their experience with teaching object-oriented modeling techniques to students and industry practitioners in France. This paper is included as a selected long paper in this volume. Betty Cheng and Robert France presented an overview of the ReMoDD (Repository for Model Driven Development) project that aims to provide a resource for sharing models and educational MDD materials. Jordi Cabot gave an invited talk on a new initiative to deliver a diploma program in MDD. The symposium ended with a panel. A summary of the panel is given later in this report.

3 3.1

Abstracts Abstract Thinking: A Predictor of Modelling Ability?

by Patricia Roberts (University of Westminster) In this paper, we describe a study of the abstract thinking skills of a group of students studying object-oriented modelling as part of a Masters course. Abstract thinking has long been considered a core skill for computer scientists. This study is part of attempts to gather evidence about the link between abstract thinking skills and success in the Computer Science discipline. The results of this study show a positive correlation between the scores of the students in the abstract thinking test with the marks achieved in the module. However, the small numbers in the study mean that wider research is needed. 3.2

Experiences of Teaching Model-Driven Engineering in a Software Design Course

by Peter J. Clarke, Yali Wu, Andrew A. Allen (Florida International University), Tariq M. King (North Dakota State University)

38

R. France and M. Gogolla

Educators continue to face major challenges in getting their students to use models eectively when developing software artifacts. As software systems become more complex it is essential that students not only learn how to create good models during software design activities but also use the models created as the blueprint for implementation. Experts in the software engineering and models communities advocate that introducing students to the concepts of Model-Driven Engineering (MDE) provide students with the insights, techniques and tools to ameliorate the diﬃculties associated with designing complex software systems. 3.3

Teaching Models@BIG: On Eﬃciently Assessing Modeling Concepts

by Marion Brandsteidl, Martina Seidl, Gerti Kappel (Vienna University of Technology) Approximately 1000 students of computer science and business informatics attend the course Introduction to Object- Oriented Modeling (OOM) oﬀered by the Business Informatics Group (BIG) of the Vienna University of Technology each year in order to learn the basic concepts of the Uniﬁed Modeling Language (UML) and to obtain a certiﬁcate. For ﬁnishing the course successfully, the students must pass three small tests where they have to prove their theoretical knowledge about UML concepts as well as their ability to apply this knowledge in practical exercises. In this paper we report our experiences in assessing the modeling knowledge of our students and we reveal how we design the tests. 3.4

Teaching Model Engineering in the Large

by Petra Brosch, Gerti Kappel, Martina Seidl, and Manuel Wimmer (Vienna University of Technology) Traditionally, models are considered as pretty pictures supporting merely the documentation of a software development project. With the rise of model-driven engineering (MDE) this viewpoint has to be reconsidered. Models become rstclass artifacts which yield the basis for the generation of executable program code. In modern university curricula of computer science and related elds this paradigm shift must not be ignored. At the Business Informatics Group (BIG) of the Vienna University of Technology we oer an advanced modeling course called Model Engineering where we elaborate current trends, development, and state-of-the-art techniques necessary to realize the visions of MDE. In this paper we report which concrete concepts and approaches we teach and how we structure and organize a practical hands-on lab where the students have to build their own model-driven development environment consisting of their own modeling languages, certain types of model transformations, and code generation facilities.

4

People Involved

The success of the symposium is a direct result of the eﬀort put into the reviews and discussions on invited speakers and papers that took place in the online

Essentials of the 5th Educators’ Symposium at MODELS 2009

39

program committee exchanges. We greatly appreciate the eﬀort of the program committee members, all of which are listed below: – – – – – – –

Jordi Cabot Peter Clarke Jeﬀ Gray Oystein Haugen Ludwik Kuzniarz Timothy Lethbridge Michal Smialek

Teaching Object-Oriented Modeling and UML to Various Audiences Sabine Moisan1 and Jean-Paul Rigault2 1

Pulsar Team — INRIA 2004 route des Lucioles — BP 93 06902 Sophia Antipolis, France [email protected] 2 Polytechnic Engineering School University of Nice - Sophia Antipolis 930 route des Colles — BP 145 06903 Sophia Antipolis, France [email protected] Abstract. This paper summarizes the experience of teaching objectoriented modeling and UML for more than a decade to various audiences (academic or corporate, software developers or not). We present the characteristics of the audiences. We investigate which modeling concepts are well accepted and which are not. We identify several general problems: attendee background, object-oriented language as a prerequisite, limitations of tools, methodological issues, impact of company organizations. We propose (partial) solutions and a list of pragmatic advices.

1

Introduction

Both authors have more than 20 years experience in practicing and teaching object-oriented programming, mainly with C++, Java, and various objectoriented Lisp’s, at beginner’s as well as advanced levels. About 15 years ago, we started courses on object-oriented analysis and design, ﬁrst using various object-oriented methods (Coad-Yourdon, Shlaer-Mellor, OMT) and we switched to UML [8] about 10 years ago. We have also run courses on Design Patterns [7,5] and their application in C++ and Java, for more than 10 years. We are teaching in academic as well as corporate contexts. At the Computer Science department of the Engineering School of the University of Nice, the students are preparing an Engineering degree in Software Development, roughly equivalent to a MSc. We also teach in-house short training sessions (a few days) for professionals belonging to companies dedicated to software development and applications. These companies are located mainly in France and the United Kingdom, but also in the United States and Australia. Concerning object-oriented modeling, we have taught this topic to more than one thousand academic students and at least as many professionals. This paper presents our personal experience and feeling with teaching objectoriented modeling to these audiences. These are not rigorously quantiﬁed experiments. The somewhat provocative style is meant to give rise to a debate. The S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 40–54, 2010. c Springer-Verlag Berlin Heidelberg 2010

Teaching Object-Oriented Modeling and UML to Various Audiences

41

paper is organized as follows. In the next section we present the various contexts of our teaching, the nature of the courses, and the characteristics of the audiences. In section 3 we remind the diﬀerent ways of using UML and the impact on teaching. In section 4, we present our experience by listing what works well and what seems to fail. Then in section 5 we discuss some general issues. Before concluding, we summarize some pragmatic proposals.

2 2.1

Context of the Teaching Academic Training (MSc Level)

The classes gather about 80–100 students for lectures, and about 20 for practical labs. Each course lasts usually for one semester (12–14 weeks) with about 3 hours per student and per week (1 hour of formal lecture, 2 hours of supervised practical labs). As far as object-oriented modeling is concerned, we are presently running a UML semester course. The lab part consists of a case study which lasts for the whole semester and which is dealt with by four students working together. Most of the job is done as home work; the time needed is estimated as 3 to 5 hours per week and per student. Each week, the group of four students meets their assigned teaching assistant for about half an hour. During this meeting the group presents the work done during the week and discusses it with the assistant; then, the work for the next week is scheduled in common. No predeﬁned methodology is followed, the students are just given a rough “work ﬂow” describing the various tasks that they will have to perform along the project (see 5.2). The students are supposed to use tools, but no particular choice is imposed. Popular ones are Rational Rose or Rational System Modeler (freely available under the IBM academic initiative), or Poseidon, ArgoUML, Umbrello, dia, Eclipse, etc. The audience is a typical student one: essentially technical background (knowledge of Java, possibly of C++, basic capabilities in algorithms and data structures), no experience of software development “in the large”, little methodology awareness (just trial and error!), contentment with apparent result (“it works!”), no recognition of the importance of tests and maintenance. Some students have little perception of the diﬀerence between using a computer and developing software for it. They focus on short term programming, preferably in a playful way. Their motivation is not really for software development but rather for exam, mark, a line in their rsum. More and more often, they are lacking abstraction, analysis capabilities, and scientiﬁc culture, a general problem in our country(ies) where scientiﬁc studies attract fewer and fewer students. 2.2

Training for Software Developers

We also run in-house corporate training sessions for professional programmers. The companies are of various sizes (from a few to several thousands people). They are involved in software development, but with diﬀerent maturity levels.

42

S. Moisan and J.-P. Rigault

They cover a variety of domains: data persistence, CAD in electronics, real time, networking and communications. They are mostly international companies, with employees from various countries, thus these sessions are usually taught in English. Each training session gathers from 6 to 12 attendees, lasts between 2 and 5 days, and is devoted to a speciﬁc topic. In the domain of object-oriented modeling our main oﬀer to this population is a UML for Analysis and Design course but we also teach Design Patterns in C++ or in Java (2 days), Basic C++ (5 days), or Advanced C++ (3 days). The UML for Analysis and Design course lasts 3 or 4 days. It summarizes use case and scenario models using hierarchical use case diagrams, text scenarios in Cockburn’s forms [2], and simple activity diagrams (this part is a digest of the UML for Product Definition described in the next section). Then it insists on analysis models using class diagrams, collaborations as a means to trace between use cases and their realizations, sequence diagrams as a formal way to express Cockburn’s scenarios in term of object interactions, and state diagrams to describe the object behavior (across all scenarios). Finally, the course skims over design models, introducing class diagram extended notations and reﬁnements, state-charts (for “object protocols”) and showing examples of component and deployment diagrams, as well as of code generation. The training relies on a case study treated individually or by groups of two, which accounts for about half of the time. The objective is to sketch a use case and an analysis model for a simple application. The tool we use is usually Rational Rose, a frequent corporate choice. The attendees are professional programmers of various ages: some are just getting out of school, others may have numerous years of practice. The ﬁrst population is of course very similar to the aforementioned students, but with stronger and more realistic motivations since they are in the “real life”. The second population is indeed delicate to handle. These attendees often do not master object-oriented languages and they lack general culture in computer science. However, they have some culture in software development, positive by many aspects, but keeping them with old habits: for instance, practice of low level languages (C, even assembler) or of corporate environments that mask the diﬃculties and even the programming language itself (e.g., heavy use of macros in C and C++). They do not trust anything but code and may be reluctant to accept requirement models established by non developers! Their motivations are variable: some expect that the new acquired knowledge will help them to be promoted or assigned to more interesting projects; others come to the training because their manager order them to do so. Some will certainly use UML right after the training, others are just looking for general information. Another diﬃculty is due to the multinational nature of these audiences and differences in background and culture. Some concepts or ways of teaching can be accepted by some people and rejected by others, depending on their country of origin. An example is the use of “role games”, e.g., Class-Responsibility-Collaboration (CRC) card sessions that seem to be well accepted in the United States and that are rejected by many Europeans. If we were to dare an explanation, we would say

Teaching Object-Oriented Modeling and UML to Various Audiences

43

that there is a tradition of “learning as a game” in the US. By contrast, in most European countries, learning is taken as a serious matter. Therefore, our students do not expect to “play” at school and they fear to expose themselves to a possible ridicule in front of their colleagues. This fear endures through professional life, but here the colleagues may also be their superiors. Moreover, it is not considered decent that a highly responsible (and highly paid) engineer play games when working! Thus, for students as for professionals, it seems to be both a problem of culture and of image. 2.3

Training for Non Developers

We also teach in-house corporate training sessions for non programmers. The session format is the same as previously (2 to 5 days, 6 to 12 attendees). In the domain of object-oriented modeling we oﬀer an Introduction to object-oriented and UML (a sort of summary of basic concepts in 2 days) and UML for Product Definition (3 days). The UML for Product Definition is the most interesting to discuss. It targets people working in marketing departments. They have to interact with the customers and to express customer needs in a way that developers should understand. The course covers essentially use case and scenario modeling, with some insights in class modeling, sequence and activity diagrams, still remaining at “business level”. More speciﬁcally, the course describes use case and scenario models using hierarchical use case diagrams, text scenarios in Cockburn’s forms [2], and very basic activity diagrams. Then it skims over class diagrams, essentially using them for elaborating “conceptual models”. The training relies on a case study, processed individually or by groups of 2, and which accounts for half of the time. However, we usually do not use a UML modeling tool for this exercise, since teaching how to use the tool risks to take too much time and thus to mask the real problems. The audience is, here again, rather heterogeneous with respect to age, experience, nationality and education. Some people have a pure marketing background, others may be former developers. They all know their application up to a very detailed level. But they usually lack abstraction, scientiﬁc and computer culture. They are used to functional-like speciﬁcations and seldom accept the switch of perspective implied by use case modeling. They are suspicious of any change. For the other members who were formerly software developers, they form a delicate population because of their noxious desire to go into details of implementation! Finally, the motivations are variable, as for the course dedicated to developers.

3

What Usage of UML to Teach?

Martin Fowler distinguishes three diﬀerent modes of using UML [3]. In UML as sketch, UML is a communication tool among regular programmers and designers, used to describe and discuss on the ﬂy about some delicate parts of the system to implement. The sessions are short and require lightweight tool support, possibly

44

S. Moisan and J.-P. Rigault

just a white board or a sheet of paper. The UML subset is often restricted to a few representations (use case, class, sequence, possible state diagrams), one at a time, and in their simplest form. According to Fowler, this mode is the most frequent, and is indeed the major choice in agile software development processes. In UML as blueprint, the whole system (or a signiﬁcant part of it) is thoroughly described. Completeness is the key issue, and precise documents are expected. In this mode, extensive tool support is required and modelers must be experienced designers since they do not model for themselves but for programmers to code up. Also a wider palette of UML representations has to be used, each corresponding to a particular point of view on the system, and these representations should be consistent. In the third mode, UML as programming language, the idea is to build UML models precise enough to generate directly executable code. Thus the UML model becomes the source. Although many UML tools claim to be able to generate code, the result is still rather poor except for very restricted and stereotyped kinds of applications. The advent of Model Driven Architecture (MDA [4]) and its generalization, Model Driven Engineering (MDE [9]), raises legitimate hope. However, presently, UML as programming language is still a research topic, by many aspects. UML has not yet the syntax and, most importantly, the precise semantics to replace a modern object-oriented programming language. Which of these modes should we teach? UML as programming language seems somewhat untimely, for corporate training. It is acceptable for Master students, combined with MDA/MDE in an elective course introducing them to research issues, at the end of their curriculum. For corporate training, the choice between the two other modes ideally depends on the company methodology and on the origin, background, and role of the attendees. Unfortunately we have to handle heterogeneous groups, which implies some trade-oﬀ. Teaching sketch mode is not so rewarding and attendees usually expect more from UML than sketches and drafts. Also, as it is normal for computer people, they expect to use tools. Unfortunately, most present tools are not very good at sketching! (See 5.2.) So we usually adopt a “lightweight blueprint” approach, trying to achieve completeness1 , modeling with multiple views, and insisting on internal consistency of these views. If this approach is correctly assimilated, it is reasonable to think that students and professionals will certainly and naturally use the UML notation in sketch mode when communicating. This is conﬁrmed by the global acceptance of the UML notation in sketch mode.

4

Acceptance of UML

Acceptance of UML varies with the origin of the attendees. It is usually better for students than for professionals. Students do not have yet any habits in software development, the topic is new, the graphical nature of the models is rather appealing. The beginnings are sometimes diﬃcult, though. The students are eager to code and modeling may initially appear as a waste of time. However, 1

At least within the time scale of a few days training session.

Teaching Object-Oriented Modeling and UML to Various Audiences

45

at the end of the semester and of their practical project, when they are asked about the usefulness of modeling, a vast majority answers that it was indeed useful and that this was a good way to clarify ideas before coding. The situation is not as clear with professionals. For the most experienced, they are used to a way of doing things, which has often proved successful enough. Bringing UML into their practice shakes up their way of thinking, introduces an extra complexity without their anticipating any obvious beneﬁt. Other professionals place too much hope in UML. They become disappointed when they realize that they got yet another language but not a panacea. In the following, we examine some elements, either pedagogical or technical, that may impact acceptance or rejection, according to our experience. 4.1

The Importance of Case Studies

Everybody agrees on the importance of introducing a signiﬁcant case study into UML teaching. Indeed, one does not teach UML as a programming language; in this matter the concepts are more important than the notation itself. To assimilate those concepts one must tackle case studies of signiﬁcant size. In addition, some attendees also appreciate small exercises focused on particular tricky points of the course. Choosing the topic of the case study is not obvious. Of course one should stick to “real life” problems and avoid too academic ones. For instance, we tried the following in our teaching: modeling a highway toll station, a city parking, a gas station, a command language for a (simulated) robot. These topics are rather data oriented (since most of our attendees are in this area) but we make sure that they contain signiﬁcant state behavior. Moreover, for corporate training, it is our experience that the topic of the case study should be outside the professional concerns of the attendees, otherwise it is likely that the attendees know more about the topic than the teacher, drifting into endless debates and deep details, thus hiding conceptual matters. It is an interesting question to know how to present the problem statement of the case study. If it is slightly incomplete or even mildly inconsistent, professionals won’t care because they are used to it! On the contrary, students will complain because they usually expect precise and complete assignment descriptions. We have to convince them that having a critical eye on problem statements and being ready to ﬁx them is an integral part of the modeling job. A last remark concerns team work. While we have ways to force students to constitute groups, it is much more delicate in corporate trainings. We have noticed that, especially in big companies, people are reluctant to work together when they do not know each other and it is delicate to force them to group. 4.2

Well Accepted Modeling Concepts

Class and object diagrams: They are very natural for programmers and also for marketing people used to model data bases. The role of these diagrams as description and communication tools is easily understood. However, identifying

46

S. Moisan and J.-P. Rigault

objects and classes at the correct abstract level remains a diﬃcult issue, even for people used to data base modeling. Indeed, if there can be “tricks”, there are no absolute “recipes” to do it. Some advocate a sort of “linguistic approach”, reading an informal speciﬁcation or design document (depending on which phase you are in) and selecting nouns as candidates for classes and verbs as candidates for functions or methods. In our experience this does not work so well and nothing replaces a good understanding of the problem or its solution. For this, we simply promote group work, discussing and brainstorming in common. Use cases and scenarios: They are considered as useful, yet bizarre, but tedious to elaborate. They induce two risks, though. The ﬁrst is to restrict scenarios to diagrammatic representation, forgetting that scenarios are story telling [2]. Some people have problems in writing. Other are (too) proﬁcient in this domain and can hardly respect the restricted style required by scenarios. The second risk with use cases is to go too far in the functional decomposition, entering into low level system details, forgetting about the external actors, and missing the point of object-orientation. Activity diagrams: We use only the simplest form of activity diagrams to represent several scenarios, possibly a full use case. The similarity with traditional ﬂow charts makes this representation easily understood. However, it presents a serious danger, identical to one of the previously mentioned use case risks: some attendees may continue the decomposition up to very ﬁne grained activities, ending up with a functional approach and thus, here again, missing the point of object-oriented modeling. 4.3

Not So Well Accepted Modeling Concepts

State models: Apart from embedded system developers, most attendees have no conscience of the importance of state modeling and no practice thereof. State modeling, especially with state hierarchy, is hard. It relies on a rigorous mathematical theory and it may well be the part of UML with the most precise semantics. Moreover, many general tools are not very eﬀective with these models, they do not generate code from them, nor allow simulation, creating frustration when trying to debug or validate the state models. Sequence and collaboration diagrams: Universally recognized as precious in sketch mode but tedious and painful to do when it comes to blueprint! For traditional sequence diagrams, they are simple to use but their power of expression is limited, especially to express complex control ﬂows. Thus many diagrams are needed to express the scenarios and their variants, often with common and thus repeated parts. The situation improves with UML 2 sequence diagrams, which are a more compact and modular representation owing to the notion of fragments. However, the syntax becomes complex and may require programming experience. It is sometimes so complex that a programming language (or pseudocode) representation may be clearer and more natural. Moreover, many tools do not handle nicely fragment edition or update. Another problem about sequence

Teaching Object-Oriented Modeling and UML to Various Audiences

47

diagrams is that some attendees wonder why using these diagrams since few tools generate code, simulation, or test from them. Component and deployment diagrams: The component model in UML 1 is far from being clear and precise, and the gain of using diagrams for representing C/C++ .h or .c(pp) ﬁles is not obvious. In fact, here again, things are improving with UML 2 and the notion of composite diagrams, but at the cost of extra complexity. For deployment digrams, they convey poor information. An interesting usage could be the mapping of component diagrams onto deployment ones, but this mapping is not supported by some tools (e.g., Rational Rose). For those who really need this sort of diagrams (e.g., to represent distributed systems), alternative models and tools are available, but they are not yet incorporated into UML. Diagrams do not tell the whole story: Companion text, constraints (free text or OCL), textual scenarios are at least as important, especially in requirement modeling. But elaborating diagrams is so time consuming and, on the other hand, illusorily seems to be such a rigorous activity that many forget this issue. Moreover, it is diﬃcult to require a complete well written document within the short time scale of corporate trainings. It is much simpler with students.

5

Major Problems

Teaching software engineering is itself delicate. It is diﬃcult to inculcate the importance of the diﬀerent development phases as well as the culture of software product into the students. Compared with other engineering domains, software development has not yet reached a satisfying maturity. In the sequel, we list a number of problems that all UML instructors have to face. We have no clear or universal solution for them and the debate is largely open. We have classiﬁed these problems in three categories: audience background and expectations, course organization, and impact of company organization (this latter only applies to corporate trainings). 5.1

Audience Characteristics

Missing Background: Most attendees in our corporate sessions do not have a wide culture in computer science. Either they were initially trained in an other (hopefully scientiﬁc) discipline or their computer training took place a long time ago. There are several concepts of software that they do not master, in particular the notion of a type which plays a central role in the object-oriented approach, the diﬀerence between instantiation and specialization, between specialization and aggregation, or between a static mechanism and a dynamic one. However, these attendees have a good experience in software development for their domain. In the academic world this latter experience is missing, but the theoretical concepts are usually more or less assimilated and the knowledge of programming paradigms is more recent—it is disappointing, though, to realize how quickly these concepts vanish as soon as the students start working in the industry!

48

S. Moisan and J.-P. Rigault

Object-Oriented Languages as a Prerequisite? Coding is just one aspect of software development, and not the one which requires the largest eﬀort. However, is it possible to compose a novel without knowing the language in which it will be written? And, is it not true that the language itself has some inﬂuence on the design of the work? After all, object-oriented methods and UML itself are born from object-oriented languages, not the contrary. Of course, some aspects of UML do not require prior expertise in objectoriented programming to be understood and used: use case diagrams and simple sequence diagrams are of this kind. Beside, the knowledge of an object-oriented language does not help much in elaborating state diagrams, setting up eﬃcient architectures, or even identifying objects and classes. However, learning an object-oriented language is certainly the best way to assimilate precisely the main concepts of class, method, generalization, polymorphism, software architecture, etc. A programming language is precise, rigorous, veriﬁable through a compiler, and liable to experiments. On the other hand, too much emphasis on a particular object-oriented language leads to lower the abstraction level, to forget the targeted product, to ignore the semantic gap between speciﬁcation and implementation. A solution, rather easy for academic students but problematic for corporate people, is to teach several languages of diﬀerent kinds. In our now long experience of corporate training, it has always been more rewarding and more eﬀective to teach UML to attendees with a prior experience of (object-oriented) programming than to ones without programming knowledge. Over-expectations: There is a widely spread misunderstanding about the real role of UML and modeling in the software development process. Students as well as professionals often expect UML to dramatically facilitate requirements and design. They also hope that documents will become clearer, shorter, and easier to produce. This is true only up to some degree. As already pointed out (see 4) some developers (and even students) may have the feeling to do the same job twice when they realize that producing code from models is not a fully automated process. The frustration is great when one realizes that the eﬀort to make diagrams generate correct code is at least as important as writing the code itself. This may dash their initial expectations, possibly leading to rejection. Despite hopes and a lot of work, “executable UML” is not ready, yet. 5.2

Course Contents

What to Teach in UML? UML is a big language, even bigger with UML 2. Moreover, the problem is not the language itself, but the concepts of modeling. The arcane notations of UML 2 are not suitable for non-developers and for this population we usually restrict to classical (UML 1) class, sequence, and activity diagrams. Some UML 2 features can be useful for professional developers, provided they are supported by tools. Of course, academic teaching uses UML 2 notation, but only presenting major topics. The Object Constraint Language (OCL) is not formally part of UML but related to it. It is neither simple not natural. More and more tools support it now

Teaching Object-Oriented Modeling and UML to Various Audiences

49

and even are capable of generating code from the constraints. Introducing it to non software developers is almost impossible and the professional programmers usually do not like it: it looks like a programming language, but it is not; it has ﬁrst order logic semantics, but it does not look like it. For our part, we do not include OCL in corporate trainings but we teach it in the academic curricula. However, we always insist on the need for constraints, if only in textual form. It is important to know how to generate code from UML models. But it is even more important to have the student realize that (at this time at least) the process cannot be made entirely automatic. Many design or implementation decisions have to be taken that are not always represented in the UML model: for instance, attributes versus functions, template usage, refactoring for optimization, concurrency issues. Last but not least, one should not forget that software modeling is not only elaborating models but also being able to read and use them. Thus, it is important to teach people to be also model readers. The obvious way is to show complete examples of models. A better way, in our opinion, is to have attendees complete unﬁnished models. A practical way that we apply in case studies is exchanging models among groups to criticize the others modeling choices. Problems with Tools: Computer science uses computer tools! It is even one of its main distinguishing characteristics among engineering disciplines. People like and request tools. However, present UML modeling tools are not satisfactory by many aspects, although the situation slowly improves with time. Most general UML tools are not so easy to master, even for doing simple diagrams. They are immature and late with respect to the standards, or even worse, they have their own interpretation of the standards. Their ergonomics may be dubious. The model veriﬁcation facilities are often poor, internal consistency of models is neglected, few simulation/execution tools are available, quality assessment means and metrics are lacking. Many tools are still closed. They ignore external languages (like OCL). The exchange of models through XMI is at best an adventure, at worst a joke. Some tools try to support “intelligent” guidance. The result may be more irritating than useful. A particularly annoying issue is that of model consistency. UML proposes a wealth of diﬀerent views on the system, at diﬀerent levels of abstraction, corresponding to diﬀerent phases of development. This is good! But these views are not independent, they have strong and consistent relationships. Most of these relations are ignored by tools and cannot be introduced by the modeler. As a matter of example, virtually all tools handle correctly a relation between sequence diagrams and class deﬁnitions. When drawing a message in the sequence diagram, one can conjure up a menu with the list of all operations of the receiving object. But when drawing a state machine representing the “protocol” of a particular class, where most of the transitions are labeled with one of the class operations, most tools, if any, do not show the same magic menu. More generally, one of the major criticisms that many tools incur is that they are blueprint oriented and not easily usable for exploratory modeling and sketching. When you have already a good idea of the various aspects of your

50

S. Moisan and J.-P. Rigault

UML model, possibly because you have drafted it on paper or white board, the tools help you to enter it eﬃciently. But they make it diﬃcult to modify, refactor, or even update it afterward, especially when the changes impact inter-relations between views. Try to simply permute two objects in a sequence diagram with fragments. Try to add an operation in a class and introduce this operation as target in some of your sequence diagrams. And how many times did you have to reorganize your diagram layouts after a slight modiﬁcation? An other signiﬁcant example is the support of best practices such as Design Patterns. Several tools allow you to set up a particular pattern by selecting classes and operations in you model and assigning them a role in the pattern. This is really nice. But what happens if, afterwords you change your mind and wish to modify, even cosmetically, the pattern? Many tools advertise generating source code (usually from class diagrams only), which is often out of place. It is an illusion to believe that drawing simple diagrams will be enough and that code will automatically follow. Relation with Methodology: Indeed UML is independent of methodologies. However, can UML be taught independently of any methodology? A well deﬁned software development process should specify the elements of UML (views and diagrams) to be used, the order of their elaboration, and most of the needed relationships between them. These questions are absolutely recurrent among the training attendees, especially—but not only—among the students, although this issue depends on the attendee origins. For academic training it is diﬃcult to chose one speciﬁc methodology: there is no consensual choice; the diﬀerences between methodologies, even superﬁcial, may disturb students; it would be somewhat diﬃcult for the teaching staﬀ to come to an agreement on a given methodology. Moreover, in the industry, most methodologies are deﬁned in-house and are likely to be much diﬀerent from the one used for teaching. Finally, on a pedagogic point of view, it might not be a good idea to impose too strict a methodology on students. The risk is that they apply it blindly, without getting a chance to discover by themselves the ins and outs of methodological issues. To be honest, students usually do not appreciate this idea! A possibility would be to teach a general methodological framework such as the Rational Uniﬁed Process (RUP [6]) but it requires customization to be used, which raises the aforementioned problems. In our case, we decided to use a ultra-lightweight methodology for student assignments. We deﬁne a simple ﬂow which describes a partial order for elaborating views and diagrams, insisting on consistency relations among views. On the other hand, professionals already follow a more or less deﬁned process. They are often aﬀective about it: they like it or they hate it. Those who like it wish to know how a UML approach would integrate smoothly into their present way of working and what will have to change (something they are highly reluctant to do). The others expect to discover how UML (considered not only as a notation but, wrongly, as a full process) could be a replacement for their dreaded in-house process. Answering these questions requires a good knowledge of the company culture, habits, and processes, which the trainers seldom have.

Teaching Object-Oriented Modeling and UML to Various Audiences

51

Evaluation of the quality of models: “How do I know that my model is good?” is a recurrent question, from all attendees, students or not. It is also an embarrassing question. Setting up formal measurements and metrics on models is yet a research issue. Of course, common sense and style considerations can play a role. The models should have a clear organization, they should go directly to the point, they should not introduce unnecessary artifacts, inter-relations between views should be kept to what is needed, no more. Should we teach modeling like some artistic disciplines are taught (writing classes, master classes, architecture)? Indeed there are demands for elegance and even beauty in software architecture that software developers and students are usually not conscious of. Unfortunately, these criteria are not objective and their appreciation requires a good experience in modeling. For our part, we insist on the robustness of models. We play a “what if” game with the attendees to evaluate the impact of changes or evolutions on their models. More perniciously, we also change the problem speciﬁcation near the end of the case study time (we do this only with students!). 5.3

Impact of Company Organization

The organization and management of a company, the way its development process is deﬁned and enforced, the individual implication of its employees have an impact on the introduction of object-oriented modeling. Of course this impact is only relevant for corporate training. Notion of a “seamless process”: Although promoted by several authors, seamlessness is unrealistic for most companies that we know, especially the biggest ones, where there are multiple jobs, several skills, diﬀerent guilds. Beyond technical skills there are also political and organizational reasons that make it impossible to have the same people in charge from speciﬁcation to ﬁnal tests and maintenance. This separation of roles is in contradiction to the “seamless process” proposed by UML. Indeed, this seamlessness often blurs the limits of abstraction levels and allows people to mind about topics which are none of their business. For instance, we already mentioned the tendency of some former developers to tweak requirement models toward implementation. Only a clear and enforced methodology could prevent such drift. Problems with management: In companies, it is not suﬃcient to train base developers if the middle and higher management do not commit to the objectoriented modeling approach. Thus the managers should be trained too! This is the reason why we propose a one day session of UML for Executives. Unfortunately, few managers have time or desire for such a training, which is a pity because they are the ones who decide about integrating object-oriented modeling into corporate methodology. In-house methodology: It is diﬃcult to run corporate trainings without knowing the context, the habits, the methods used in the organization. Not all companies are willing to expose their development process because of corporate secrets

52

S. Moisan and J.-P. Rigault

or just technical modesty. Besides, it is often the case that the same methodology is not used in the diﬀerent departments or teams of a training session attendees. On the other hand, external trainers cannot master a company methodology and it is not even desirable. When hiring an external training provider, most companies, and the attendees themselves, expect some view from the outside, not yet another in-house vision. The trade-oﬀ is not easy to ﬁnd. In our case, we try to remain neutral and to stick to our lightweight process (see 5.2). Another diﬃculty is when (object-oriented) modeling is not part of the enterprise culture and when a smooth integration of UML into the development process has not been anticipated. In this case, UML is perceived as yet an other tool, just like C++ or J2EE, complex to grasp, and problematic to integrate into everyday practice. The lack of integration not only risks to lead to a wobbly process, but it can be detrimental for UML acceptance among the staﬀ.

6

Proposals

In this section, we summarize some suggestions, stemming from our experience, to conduct trainings in academic or industrial context. All these suggestions have been discussed in the previous sections. All trainings: The following advices apply to all sorts of UML trainings, independently of the population and the duration. – Do not try to teach all UML( 2). Select concepts and views relevant to the target population. – Try to remain methodology neutral whenever possible. Just provide general guidelines to schedule modeling activities: order of diagram elaboration, inter-diagram consistency rules, outline for textual information and constraints, etc. – Run a case study in sync with formal lectures. The topic should be realistic and ﬁt within the time frame (something rather delicate for short corporate trainings). – Use any reasonable (free) computer tool or the corporate choice, but do not expect too much. – Teach to read models, not only to write them; for instance exchange models among the case study groups. – Improve model quality by asking “what if?”, even by simulating speciﬁcation changes; this helps appreciate model robustness and versatility. – Insist on a model not being just a set of diagrams. Diagrams alone cannot be a complete solution, constraints and textual information are mandatory. We expect that, at the end of the training, through both lecture and practice, the attendees have grasped a clear understanding of the right role of modeling. Modeling is a step in problem solving and a way to clarify informal speciﬁcations and formalize design. The trainers should carefully navigate between to equally dreadful reefs: over-expectation and rejection.

Teaching Object-Oriented Modeling and UML to Various Audiences

53

Academic training: As faculty members, we (sort of) master the contents of our courses and curricula and, hence, we know the background of our students. – Make sure that technical prerequisites are met: practice of at least one objectoriented language, familiarity with computer science concepts such as types, state-machines, inheritance, aggregation, polymorphism. – Emphasize the links between modeling concepts and these theoretical aspects whenever possible. – Force students to work in team (a group of 4 seems a good choice) for the case study. – Do not spoon-feed students by providing a clear-cut problem statement for the case study. – Give students free hand on methodology as long as they seem to follow one. – Do not compromise on deadlines, quality of documents and presentations. Corporate training: Here we are just service providers. We do not decide how corporations behave and we cannot master their culture, their mentality, their background, or even their choice of tools and methodology. Even if we deﬁne prerequisites for our training sessions, they may not be fully respected. – Try to understand why the company asks for UML training: What are the kind(s) of methodology used within the company? How is UML integrated or integrable into these methodologies? How does management feel about object-oriented modeling? – Do not try to stick to the company methodology, if you do not master it. – Remember that the case study lasts only for a few days. – Choose a case study topic in the attendees’ general area of interest but not in a domain where they are specialists.

7

Conclusion

Due to the practical and operational nature of software engineering it is worthwhile to run training both in the academic world and in the industrial one. This allows us to build bridges between the day to day practice of industry and the current state of academic research and to prepare the present and future actors to the forthcoming evolutions. This paper analyzes some problems that we met in running courses in both context and lessons that we have drawn. It also proposes some simple advices. We believe that more formal studies are needed, although it might be problematic in corporate trainings. In the academic context, things are rather simple. We master students background, we can relate empirical modeling and theory, we have time, we control the ﬂow of the case study. This is not true in short term corporate sessions. For these latter, the key to the success lies in understanding the motivation for organizing UML courses. Discussing with head executives in charge of software development may be beneﬁcial. Not all companies are aware that it is useless

54

S. Moisan and J.-P. Rigault

to introduce software engineering methods and tools into an organization which has not reached the proper maturity level, as pointed out by the CMMI [1]. When a company fails to integrate UML in its software methodology—and we have already mentioned several reasons for which it may occur—one may hear that “UML is the problem, not the solution”. There are no silver bullet. Our job as trainers is to ease the integration of object-oriented modeling, to avoid UML being a problem, but also to have people realize that UML by itself cannot be the solution.

References 1. Carnegie Mellon Software Engineering Institute: Capability maturity model integration (2006), http://www.sei.cmu.edu/cmmi/ 2. Cockburn, A.: Writing Eﬀective Use Case. Addison Wesley, Reading (2001) 3. Fowler, M.: UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd edn. Addison Wesley, Reading (2003) 4. Frankel, D.S.: Model Driven Architecture. OMG Press, Wiley (2003) 5. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, Reading (1995) 6. Kruchten, P.: The Rational Uniﬁed Process: An Introduction, 2nd edn. Addison Wesley, Reading (2000) 7. Larman, C.: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd edn. Prentice Hall PTR, Englewood Cliﬀs (2004) 8. Rumbaugh, J., Jacobson, I., Booch, G.: The Uniﬁed Modeling Language Reference Manual, 2nd edn. Addison Wesley, Reading (2004) 9. Stahl, T., V¨ olter, M.: Model-Driven Software Development. Wiley, Chichester (2005)

Teaching Modeling: Why, When, What? Jean Bezivin1 , Robert France2 , Martin Gogolla3 , Oystein Haugen4 , Gabriele Taentzer5 , and Daniel Varro6 1

University of Nantes, France Colorado State University, USA 3 University of Bremen, Germany 4 University of Oslo, Norway 5 University of Marburg, Germany Technical University of Budapest, Hungary 2

6

Abstract. This paper reports on a panel discussion held during the Educators’ Symposium at MODELS’2009. It shortly explains the context provided for the discussion and outlines the statements made by the panelists. The panelists were asked to make their statements along a number of topics relevant to teaching modeling like: Notation, Semantics, Programming, Tooling, Suitability, Metamodeling.

1

Context

In order to set the context for the panel discussion on teaching modeling, we should be aware of the fact that, in the software development process, models can serve diﬀerent purposes and that models can be used on a number of diﬀerent levels. The UML (Uniﬁed Modeling Language) Reference Manual nicely explains this by stating the following classiﬁcations. Purposes of models – To capture and precisely state requirements and domain knowledge so that all stakeholders may understand and agree on them, – To think about the design of a system, – To capture design decisions in a mutable form separate from the requirements, – To generate usable work products, – To organize, ﬁnd, ﬁlter, retrieve, examine, and edit information about large systems, – To explore multiple solutions economically, and – To master complex systems. Levels of models – Guides to the thought process, – Abstract speciﬁcations of the essential structure of a system, – Full speciﬁcations of a ﬁnal system, S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 55–62, 2010. c Springer-Verlag Berlin Heidelberg 2010

56

J. Bezivin et al.

– Exemplars of typical or possible systems, and – Complete or partial descriptions of systems. Having this in mind, the question comes up when and where (in which institution) to teach modeling. There are various possible answers. – At (high-)school, – During university studies (before learning programming, after learning programming, parallel to learning programming), – After obtaining a ﬁrst degree in programming, and – During an advanced training for IT professionals. Teaching modeling also opens up a bunch of questions with respect to the taught contents. When asking “What” is taught at least the following dimensions, which could be considered, come up. – Graphical versus textual modeling languages, – “Modern” UML-like formalisms versus “historical” formalisms (like EntityRelationship schemata, automata, statecharts or petri nets), – Modeling versus programming, – Tooling versus modeling with paper and pencil or on the blackboard, – Modeling as a stand-alone ﬁeld versus modeling in computer science subﬁelds (like class diagrams in database systems, sequence diagrams in networking, statecharts in embedded systems), – Modeling versus speciﬁcation, – Universal modeling versus domain speciﬁc modeling, – Syntax versus semantics (with diﬀerent approaches to semantics like textual, informal, formal, programming language-based, graph-based semantics), and – Models versus metamodels. The panelists were asked to prepare their statements in light of this context.

2

We Need an Army of Engineers to Implement the MDE Vision (Jean Bezivin)

Towards implementing a vision: Modern software modeling techniques have rapidly evolved since the MDA proposal by the OMG in November 2000. We now understand much more clearly the foundations. Corresponding tools are becoming available, most notably from the open source community. Industrial applications in various ﬁelds have demonstrated the practical potential of the approach. It is interesting to notice that this has been an industry-driven evolution, because the original problem was mainly stated by OMG (an industrial oriented consortium) and that research labs and academic conferences came in only in a second phase in order, to propose a more regular conceptual framework and to link this pragmatic quest for more abstraction in software development to general theories of software engineering. The initial problem

Teaching Modeling: Why, When, What?

57

was put forward by practitioners and progressively reshaped by researchers. Now we are missing the last phase of the process, the education part. We have a reasonable consistent theory; we have the basic tooling support for this theory; we have empirical evidence that the industrial deployment of modern software modeling may bring a signiﬁcant return on investment for many projects; what we need now is the army of engineers to implement that vision in various branches of industry. Research? Deployment? Teaching! Unfortunately the engineers in Model Driven Engineering (MDE) are not so numerous. They are few PhD students that can lead innovative projects, but today, the vast majority of professional programmers, educated in the last decade, is excellent at developing objectoriented programming projects in Java, EJB or C#, but much less convinced when it comes to using MDE techniques. We are facing an important paradigm shift, probably more important than the migration from procedural technology to object technology that happened in the eighties. We have not only to educate new students in modeling, but also to re-educate former students in the advantages of transformative domain modeling over practices of direct application coding in high-level general purpose languages. MDE is now accepted in many places. As Tony Hoare stated at ICSE 1996, “Teaching reduces the gap [between theory and practice] and research increases it again”. In the never-ending Research-Deployment-Teaching cycles, MDE is now in a position where the teaching question is probably the more acute. UML versus DSL: So we need to address seriously the teaching of modern software modeling techniques without too much delay. Such a teaching should be modest since we have learned to be cautious in the short history of MDE. For example, we learned in the past that MDE should not be confused with UML, with general purpose languages, with visual languages, etc. There are plenty of advanced and successful deployments of MDE projects that do not use at all UML, or any visual language. On the contrary, there are currently a number of modeling projects using some form of Domain Speciﬁc Languages (DSLs) up to a point that it is hard to distinguish between teaching MDE and teaching DSLs. But this situation, as of today, may still evolve in the future. Metamodeling and model transformation: The ﬁrst part of a teaching curriculum in software modeling should present the core technology and we see two essential dimensions here: metamodeling and model transformation. This should be presented in such a generic way that it may encompass the most important instantiations of these ideas (e.g., MOF, KM3, ECore; but also Oslo, XML schema, Protege, OWL; QVT, ATL, GReAT, AGG, TGG; XSLT, XQuery). Applications of MDE: The second part of a teaching curriculum in software modeling should present a broad view of current known applications of MDE in ﬁelds like embedded systems, information systems, web engineering, software modernization, etc. There is such a broad range of domains (health care, transportation, business modeling, software processes, banking and insurance industry, human resource management, avionics, automotive industry,

58

J. Bezivin et al.

etc.) from where we can now draw concrete success stories, that this is becoming an easily documented exercise. Within this large spectrum of case studies, it is quite easy to distinguish the three successive generations of MDE applications: code generation from abstract models (like Java generation from UML), model discovery from unknown systems (like extracting business rules from COBOL legacy code) and the last more general application of model driven interoperability (like connecting diﬀerent tools by transformation after extraction of their related metamodels). In the last generation transformations are executed at run time while in the ﬁrst two ones, transformation are executed during the software production and maintenance phases. Convincing stakeholders about MDE value: But probably the most important sequence in a MDE curriculum is more human and social than technological: how to manage the changes in the enterprise, how to convince all the actors that they are going to be more productive by raising the abstraction working level from base programming code to domain modeling, from direct coding in general purpose programming languages to transformation from standard or custom made DSLs. The non-technical issues are probably the hardest ones to teach. Building specialized high-level curricula: Nearly ten years after the initial OMG proposal, software modeling seems now quite well accepted. The main challenge we face now is to succeed in building specialized high-level curricula so that engineers will be able to rapidly deploy MDE solutions in industry.

3

Expert Modelers Are Good Programmers (Robert France)

Expert modelers are good programmers: There is a misguided notion among some students and practitioners that you can succeed in a software modeling course if your programming skills are weak (“You don’t have to program; you just draw pictures!”). By “programming skills” I do not mean working knowledge of programming language syntax; the skill I am referring to is the skill of developing a solution expressed in a programming language using the abstractions provided by the language. The students that hold this notion view modeling as an opportunity for informally thinking about a solution. These notions are often quickly dispelled in a modeling course that emphasizes rigorous modeling of problems and solutions. In such courses students quickly ﬁnd out that identifying the “right” abstractions requires that they have a good programming background. This should not come as a surprise. How can we develop good abstractions if we do not understand the artifacts (programs) we are abstracting over? I put forward the following hypothesis: An expert modeler is a good programmer. The converse is not necessarily true. A good programmer is not necessarily a good modeler. The ability to abstract over concrete programming concepts is not something that all good programmers can do. It is an additional skill

Teaching Modeling: Why, When, What?

59

that makes a good programmer also a good modeler. In fact, I’ll go further and hypothesize that programmers with good modeling skills produce better quality programs than those with weaker abstraction skills. I would be very interested in hearing about empirical studies that explore (or explode) these hypotheses. Modeling should be developed alongside programming: If you subscribe to the above hypotheses, what is the implication for educators? It requires that modeling skills be developed alongside programming skills. As students are taught programming concepts, the means to describe abstractions over the programming concepts should also be introduced. Students should learn how to identify and describe abstractions that help them better organize their programs as they are developing their programming skills. This should lead to a greater appreciation of model-driven software development technologies that encode some knowledge about transforming abstractions to their realizations in a program. Layer of general-purpose abstractions: Some have pointed out that my hypotheses seem to suggest that a good Java programmer must also be a good assembly language programmer (or, a good machine coder!); after all the Java language provides abstractions over these lower level language concepts. The reason why a good Java programmer does not need to have any knowledge of lower level languages is that we have been able to build a complete layer of abstractions above these lower levels with accompanying tools for automatically translating Java program abstractions to lower level abstractions (and vice versa). We do not have such a complete layer of general-purpose abstractions above the level of current high-level programming languages as yet. Such complete layers may appear in the near future in speciﬁc domains, thus allowing modelers to become programmers in those domains. In the meantime, modeling and programming skills should be taught hand-inhand.

4

Models May or May Not Be: Executable, Formal, Complete (Oystein Haugen)

Modeling brings abstraction: We teach modeling because this makes the students better software engineers. We teach modeling to make them understand the value of abstraction. I would like to focus on three dichotomies that explain what modeling is and that should be focused in teaching modeling. Distinction between model and program: First, we elaborate on the distinction between model and program. Is there a diﬀerence, and is that difference important? Models and programs are not very diﬀerent, but how diﬀerent they are depends on the kind of model. Programs are always executable. When models are executable some people claim they are programs. When models are not executable they are not programs. Not only executable models are useful, but executable models are particularly useful. Sequence diagrams represent models that are not directly executable, but they are

60

J. Bezivin et al.

deﬁnitely useful. Still the power of execution makes it much easier to understand the model. The model can be explored by those that cannot read its deﬁnition. The proof of the pudding is in the eating, and execution is the eating of the model. Execution concepts versus application domain concepts: Is an executable model equivalent to a program that performs the same execution? That is a matter of deﬁnition, but our position is that there is a signiﬁcant diﬀerence, and the diﬀerence lies in abstraction. Typically programming languages have general concepts that describe the execution on a computer while modeling languages have concepts closer to some application domain, but they may still be quite general. An example to illustrate the diﬀerence is that we ﬁnd no programming languages with dedicated concepts to describe ﬁnite state machines, but you ﬁnd those in many modeling languages. This does not mean you cannot implement state machines in a programming language, but you have no concepts with which to think in terms of state machines and your programming is more error prone. Formal and informal models: Second, we consider the distinction between formal and informal models. Again both kinds of models are useful, but formal models have potentials to be more useful. An informal method cannot be executable, but are all executable models formal? Our position is that the execution is the semantics, and the compiler the formal deﬁnition of the language. Not all agree to this, and obviously there is much to gain from a more manageable deﬁnition of semantics than a compiler. Mathematics and logic are often used for the purpose of deﬁning semantics, but many students of informatics ﬁnd a mathematical deﬁnition more diﬃcult to read than the source of a compiler. Formal deﬁnitions can be applied to make executable code, or they can be used as base for analysis such as modelchecking or quality metrics. Formal deﬁnitions can be transformed into test cases or even user interfaces. Partial and complete models: Third, we explore the distinction between partial and complete models. An informal model is often partial, but there are partial models that are perfectly formal. Sequence diagrams have a formal semantics, but sequence diagrams can normally not provide a complete model. In fact it would normally be impractical or stupid to provide a complete model through sequence diagram. They are intended to give important, but partial knowledge. Complete models are typically needed to have an executable model, but it is possible to make execution engines that choose randomly between the valid choices. Modeling brings forth the important aspects: Make no mistake, our categories of models do not cover sloppy and bad models. It is quite possible that an informal and partial model is very useful and fairly precise and even quite unambiguous. On the other hand a formal and complete model may be impossible to understand and extremely diﬃcult to maintain. We should use modeling in informatics for the same reason as they use modeling in every other engineering discipline To abstract away the details to bring forth the

Teaching Modeling: Why, When, What?

61

important aspects. Therefore modeling should be taught on all levels for all students with formal as well as informal means and using advanced tools or using only pencil and paper.

5

Modeling Is Diﬀerent from Model Engineering (Gabriele Taentzer)

Learn modeling with a standard language such as the UML: Modeling is the process to think abstractly about systems. In software development, requirement elicitation and software design are central modeling tasks. Students should get modeling skills as early as possible. They do not need to learn programming beforehand. Usually, students start to learn programming based on a well-known language such as Java. Similarly, they should also start learning modeling based on a standard modeling language such as the UML. The usage of modeling tools is not important in the beginning, but later on when modeling tasks may become larger appropriate tool support should be used. Model engineering: Once students know how to model software systems, the study of model engineering concepts and techniques should start. Model engineering comprises the deﬁnition of modeling languages including syntactical and semantical aspects as well as supporting tools such as editors, interpreters, debuggers, analyzers, and code generators. Essential concepts for model engineering are metamodeling and model transformations. Model engineering can be compared to the deﬁnition of programming languages and compiler construction. However, the concepts used in model engineering are completely diﬀerent to those used for deﬁning programming languages and their supporting tools. The main reason for this diﬀerence might be the visual nature of most models compared to textual programs. While the abstract syntax of programs is usually considered to be tree-like, the underlying structure of a visual model does not necessarily have a distinct tree structure but is considered as graph in general. Model engineering leads to research topics: Model engineering is a developing discipline with a lot of open issues. They range from layout algorithms for visual models to comprehensive code generation ensuring high code quality standards. Therefore, model engineering is well suited to lead advanced students to current research topics.

6

Improve Use of Language, Not Only Vocabulary (Daniel Varro)

Motivation for extra modeling investment: My main involvement in teaching models is giving a Master level course where mostly UML is used as a modeling language, while models are introduced in the context of popular web technologies especially (like J2EE or Eclipse RAP). At this stage, most of the students can be quite advanced in one or more web technologies, thus they need some extra motivation why they should invest in models.

62

J. Bezivin et al.

Improve use of language, not only vocabulary: While most students also learned about UML as a language in their previous studies, they still have diﬃculties in using UML for their projects. In this respect, a main goal of the course is to improve the use of language, and not only UML vocabulary. For instance, linguistic diﬀerences like aggregation and composition are quite irrelevant for them compared to even very simple rules of thumb giving guidance in arranging models in diagrams, like “Large class diagrams do not demonstrate that you worked very hard. They only demonstrate that your are using the language improperly.” As a summary, it is very important to give some guidelines to students why certain models are good or bad. Carefully selected model fragments play a crucial role in this. Models serve as primary means of collaboration: As their homework assignment needs to be carried out in teams, they use models are primary means of collaboration. Instead of arbitrary sketches, models are used within teams to drive database design along the object-relational mapping, stateful behavior of business entities, etc. Moreover, models are also very useful in ﬁxing the interfaces between modules developed by diﬀerent teams (which will then be realized, e.g., by web services technology). Many experts say that frequently, modeling pays oﬀ only from the second project when the team members are already advanced users of the modeling language. The use of models as collaboration means gives students the impression that they are already working on something realistic where it is worth investing in the use of models. Use modeling tools, not only paper: While models are frequently used as pure sketches, I strongly recommend the use of modeling tools as part of a modeling course. In our case, IBM Rational Software Architect/Modeler provides support for eﬀective groupwork by dividing models into smaller parts where each team member may be responsible for easily identiﬁable bits of the model. Furthermore, from a didactic point of view, modeling tools help enforce certain well-formedness rules of the UML language. It is extremely important to maintain some consistency criteria along diﬀerent diagrams, which students frequently ﬁnd diﬃcult to grasp.

Model Based Architecting and Construction of Embedded Systems (ACES-MB 2009) Stefan Van Baelen1 , Thomas Weigert2 , Ileana Ober3 , Huascar Espinoza4 , and Iulian Ober3 1

2

K.U.Leuven - DistriNet, Belgium [email protected] Missouri University of Science and Technology, USA [email protected] 3 University of Toulouse - IRIT, France {Ileana.Ober,Iulian.Ober}@irit.fr 4 CEA - LIST, France [email protected]

Abstract. The second ACES-MB workshop brought together researchers and practitioners interested in model-based software engineering for real-time embedded systems, with a particular focus on the use of models for architecture description and domain-speciﬁc design, and for capturing non-functional constraints. Eleven presenters proposed contributions on domain-speciﬁc languages for embedded systems, the Architecture Analysis and Design Language (AADL), analysis and formalization, semantics preservation issues, and variability and reconﬁguration. In addition, a lively group discussion tackled the issue of combining models from diﬀerent Domain Speciﬁc Modeling Languages (DSMLs). This report presents an overview of the presentations and fruitful discussions that took place during the ACES-MB 2009 workshop.

1

Introduction

The development of embedded systems with real-time and other critical constraints raises distinctive problems. In particular, development teams have to make very speciﬁc architectural choices and handle key non-functional constraints related to, for example, real-time deadlines and to platform parameters like energy consumption or memory footprint. The last few years have seen an increased interest in using model-based engineering (MBE) techniques to capture dedicated architectural and non-functional information in precise (and even formal) domain-speciﬁc models in a layered construction of systems. The Second Workshop on Model Based Architecting and Construction of Embedded Systems (ACES-MB 2009) brought together researchers and practitioners interested in all aspects of model-based software engineering for real-time embedded systems. The participants discussed this subject at diﬀerent levels, from model speciﬁcation languages and analysis techniques to model-based implementation, deployment and reconﬁguration. The workshop was attended by 47 registered participants coming from 19 diﬀerent countries. S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 63–67, 2010. c Springer-Verlag Berlin Heidelberg 2010

64

2

S. Van Baelen et al.

Workshop Contributions

The keynote [2] was given by Prof. Marco Di Natale from the Scuola Superiore Sant’Anna in Pisa, Italy, who discussed semantics preservation issues in the design and optimization of software architectures for automotive systems. Architecture selection and design optimization are critical stages of the Electronics/Controls/Software (ECS)-based vehicle design ﬂow. In automotive systems design, complex functions are deployed onto the physical hardware and implemented in a software architecture consisting of a set of tasks and messages. Several optimizations of the software architecture design were presented, including the deﬁnition of the task periods, the task placement and the signal-tomessage mapping. In addition, the assignment of priorities to tasks and messages were automated in order to meet end-to-end deadlines and to minimize latencies. Architecture selection can be accomplished by leveraging worst case response time analysis within an optimization framework. Suggestions on how to use stochastic or statistical analysis to improve the approach were provided. Semantics preservation issues impose additional constraints on the optimization problem, but also reveal very interesting tradeoﬀs between memory and time/ performance. The need to deal with heterogeneous models and standards, such as AUTOSAR (AUTomotive Open System ARchitecture) in the automotive industry, further complicates the scenario. 7 full papers and 3 short papers had been accepted for the workshop, see [1]. A synopsis of each presentation is given below. Extended versions of articles [11] and [12] are included in this workshop reader. [3] presents SOPHIA, a modelling language that formalizes safety-related concepts (e.g., accident models), and explores strategies to implement SOPHIA as a complementary modelling language to SysML. [4] describes a prototype modeling language for the design of networked control systems using passivity to decouple the control design from network uncertainties. The resulting designs are by construction more robust with respect to platform eﬀects and implementation uncertainties. [5] presents a formal speciﬁcation of the design models used in COMDES-II, a component-based framework for distributed control systems, featuring an open architecture and predictable operation under hard real-time constraints. [6] proposes a systematic method for Worst-Case Execution-time (WCET) analysis that make Simulink/Stateﬂow model information (e.g., infeasible executions) available to static timing analysis tools. [7] presents a methodology and tool for building and translating AADL systems into a distributed application. This allows runtime analysis to fully assess system viability, and to reﬁne and correct the behavior of the system using BIP. [8] investigates the iterative model-driven design process for complex embedded systems, which suﬀers from a delay between applying changes to the model and obtaining information about the resulting properties of the system, and identiﬁes opportunities for a novel, integrating research domain on AADL. [9] presents a methodology for the speciﬁcation and analysis of critical embedded systems, based on an architectural design language that enables modeling

Model Based Architecting and Construction

65

of both software and hardware components, timed and hybrid behavior, faulty behavior and degraded modes of operation, error propagation, and recovery. [10] focuses on ﬁnding performance problems when use cases are added to (a family of) products, and proposes an automated algorithm that generates performance models by combining use case models, and an approach for performance optimization by adding ﬂow control elements into the system design. [11] integrate variability approaches from Software Product Lines (SPL) into Domain-Speciﬁc Languages (DSLs) like Matlab / Simulink, in order to specify variability, conﬁgure products and to resolve element dependencies. High-Order Transformations derive the variability mechanisms (as a generated model transformation) from the meta-model of the DSL. [12] supports the combination of robustness and ﬂexibility in automotive systems through the integration of reconﬁguration capabilities into AUTOSAR, supporting the management of complex system at the architectural level.

3

Summary of the Workshop Discussions

The workshop was divided into 4 sessions: domain-speciﬁc languages for embedded systems, the Architecture Analysis and Design Language (AADL), analysis and formalization, and variability and reconﬁguration. After each session, a group discussion was held on topics and issues raised during the session presentations. The following integrates and summarizes the conclusions of the discussions. AUTOSAR The automotive industry is challenged to distribute an increasing number of functions, which are enabled through an increasing number of smart sensors and actuators, onto a descreasing number of Electronic Control Units (ECUs). The AUTOSAR architecture is a key element for the automotive industry to decouple the software functions from the ECUs. The main challenges for the automotive embedded system industry are (1) how to perform the mapping of functions onto ECUs, and (2) how to preserve the semantics of these functions. The focus here is on the timing analysis to obtain an adequate mapping of the tasks to the resources. Currently no structured hierarchical methodology is used, but the allocation is performed using a bottom-up approach through a number of iterations. Regarding communication between ECUs, the CAN (Controller Area Network) bus is rather easy to deal with, while the FlexRay protocol is more complex. In most cases no formalized architectural frameworks are used on top of AUTOSAR. The trickiest part for the timing analysis is to get the correct Worst Case Execution Time (WCET) bound for safe and precise resource optimization, hereby avoiding overestimations due to infeasible paths. Further research on obtaining accurate WCET information is therefore necessary. Combining models from diﬀerent DSMLs There is a need for using diﬀerent DSMLs during the development of embedded systems. The main challenges hereby are (1) to combine such models and

66

S. Van Baelen et al.

map identical representations onto a single concept, (2) to obtain semantic compatibility, and (3) to guarantee and preserve consistency between these models. The UML-MARTE proﬁle seems to be too complex for ordinary developers and end users for expressing non-functional system properties; they require a simple language that is easily understandable. In addition, there can be a need to use several DSMLs, and the results expressed in these domainspeciﬁc models must be compatible and consistent. Three approaches for connecting domain-speciﬁc models were discussed. First, explicit semantic interfaces can be deﬁned to connect heterogeneous models. The link between AUTOSAR, Simulink, and Modelica is an example. Second, an underlying semantic framework can be used to map the domain-speciﬁc models onto a universal model. Such approach also has to deal with concepts present in the DSML that cannot easily be mapped onto the underlying framework. UMLMARTE could be a suitable candidate as an underlying supporting semantic framework for building domain-speciﬁc models that could be mapped and integrated on top of UML-MARTE. Finally, a third approach is to restrict a general model to a speciﬁc subset, for instance by deﬁning a restrictive UML proﬁle. SysML can be seen as an example of deﬁning a restrictive DSML on top of UML. In practice, we will have to combine all three approaches during embedded systems development. There is a need to utilise heterogenerous models that either are subsets of UML-MARTE, will be mapped onto it, or will be interfaced with it. The correctness by construction approach is very powerful, but very difﬁcult to realise when using heterogeneous models. If one can deﬁne the right abstractions and reﬁne them, then one no longer needs to reopen the component box when connecting to them. This works ﬁne for some combinations (e.g., from a synchronous reactive system description to a time-triggered architecture), but not for all combinations (e.g., to an event-driven architecture). One solution is to use only time-triggered architectures, and take the potential ineﬃciency as a fact, since reliability and composability might be more important than eﬃciency. This may be a good approach at least in some domains, such as aerospace and automotive, but may not apply in other domains, such as consumer electronics. This approach is best suited for a one-pass development process, while in practice incremental development is often used. The developer models part of the functionality, deﬁnes an architecture based on estimates, analyses and simulates the application, and then tries to obtain more concrete and precise estimates during later stages of the development. Iteratively, the developer can go back to change the behavior and functional and/or physical architecture at higher levels based on this reﬁned information. As such, one starts with a simpliﬁed version of the system that gradually is adjusted and reshaped until a suitable system description is obtained. Reconﬁguration Reconﬁguration is often a key element even in safety-critical embedded systems. It is used to obtain a graceful degradation in an FDIR (Fault Detection,

Model Based Architecting and Construction

67

Isolation and Recovery/Reconﬁguration) approach, enabling continuous operation under degraded conditions. Often the failing system cannot be shut down but must reach a stable state as soon as possible. It is not clear if such safe state can always be reached, and if so in which timeframe. Therefore the aerospace industry heavily relies on redundancy in order to avoid system failures. Similarly, the introduction of steer-by-wire in the automotive industry is not a matter of computational power or price but rather of reliability and culture, since there is not yet the same level of culture about safety and reliability as in the aerospace industry.

Acknowledgements We thank all workshop participants for the lively discussions. We especially thank our keynote speaker, Prof. Marco Di Natale, for his inspiring presentation. We also thank the workshop steering committee and program committee members for their support. This workshop was supported by the ARTIST2 Network of Excellence on Embedded Systems Design (http://www.artist-embedded.org) and by the EUREKA-ITEA project SPICES (http://www.spices-itea.org).

References 1. Van Baelen, S., Weigert, T., Ober, I., Espinoza, H. (eds.): Second International Workshop on Model Based Architecting and Construction of Embedded Systems. CEUR Workshop Proceedings, Aachen, Germany. CEUR, vol. 507 (2009) 2. Di Natale, M.: Semantics preservation issues in the design and optimization of SW architectures for automotive systems. In: [1], p. 9 3. Cancila, D., Terrier, F., Belmonte, F., Dubois, H., Espinoza, H., G´erard, S., Cuccuru, A.: SOPHIA: a modeling language for model-based safety engineering. In: [1], pp. 11–25 4. Eyisi, E., Porter, J., Hall, J., Kottenstette, N., Koutsoukos, X., Sztipanovits, J.: PaNeCS: A modeling language for passivity-based design of networked control systems. In: [1], pp. 27–41 5. Angelov, C., Sierszecki, K., Guo, Y.: Formal design models for distributed embedded control systems. In: [1], pp. 43–57 6. Tan, L., Wachter, B., Lucas, P., Wilhelm, R.: Improving timing analysis for Matlab Simulink/Stateﬂow. In: [1], pp. 59–63 7. Chkouri, M.Y., Bozga, M.: Prototyping of distributed embedded systems using AADL. In: [1], pp. 65–79 8. Langsweirdt, D., Vandewoude, Y., Berbers, Y.: Towards intelligent tool-support for AADL based modeling of embedded systems. In: [1], pp. 81–85 9. Bozzano, M., Cimatti, A., Katoen, J.P., Nguyen, V.Y., Noll, T., Roveri, M.: Modelbased codesign of critical embedded systems. In: [1], pp. 87–91 10. Ersfolk, J., Lilius, J., Muurinen, J., Salom¨ aki, A., Fors, N., Nylund, J.: Design complexity management in embedded system design. In: [1], pp. 93–106 11. Botterweck, G., Polzer, A., Kowalewski, S.: Using higher-order transformations to derive variability mechanisms for embedded systems. In: [1], pp. 107–121 12. Becker, B., Giese, H., Neumann, S., Schenck, M., Treﬀer, A.: Model-based extension of AUTOSAR for architectural online reconﬁguration. In: [1], pp. 123–137

Using Higher-Order Transformations to Derive Variability Mechanism for Embedded Systems Goetz Botterweck1 , Andreas Polzer2 , and Stefan Kowalewski2 1

Lero, University of Limerick Limerick, Ireland [email protected] 2 Embedded Software Laboratory RWTH Aachen University Aachen, Germany {polzer,kowalewski}@embedded.rwth-aachen.de

Abstract. The complexity of embedded systems can partly be handled by models and domain-specific languages (DSLs) like Matlab / Simulink. If we want to apply such techniques to families of similar systems, we have to describe their variability, i.e., commonalities and differences between the similar systems. Here, approaches from Software Product Lines (SPL) and variability modeling can be helpful. In this paper, we discuss three challenges which arise in this context: (1) We have to integrate mechanisms for describing variability into the DSL. (2) To efficiently derive products, we require techniques and tool-support that allow us to configure a particular product and resolve variability in the DSL. (3) When resolving variability, we have to take into account dependencies between elements, e.g., when removing Simulink blocks we have to remove the signals between these blocks as well. The approach presented here uses higher-order transformations (HOT), which derive the variability mechanisms (as a generated model transformation) from the meta-model of a DSL.

1 Introduction Embedded systems are present in our everyday life, for instance in washing machines (to save energy and water), in mobile devices (to simplify our lives) and in cars (to guarantee our safety). In many cases, the engineering of embedded systems has to fulfill conflicting goals, such as reliability and safety on the one hand, and economic efficiency on the other hand. Moreover, the complexity of such systems is increasing due to the extension of functionality and increased communication with other systems. One possibility to deal with the complexity, requirements and the cost pressure is to use model-based development techniques like Matlab / Simulink. The advantages of such an approach are that connections between system components are expressed in an intuitive way on a higher abstraction level, which hides implementation details. Other benefits are support for simulation and increased reuse due to the component-oriented approach. In the context of this paper, we regard a “system” as a Matlab / Simulink model that contains components (represented as blocks) and provides a certain functionality. S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 68–82, 2010. c Springer-Verlag Berlin Heidelberg 2010

Using Higher-Order Transformations to Derive Variability Mechanism

69

Nowadays, such systems are reused with small, but significant changes between different applications. Such variability causes additional complexity, which has to be handled. Some well-known techniques for this are suggested by Software Product Lines (SPL) [1,2]. In the research presented here, we discuss how SPL techniques can be applied and adapted for the domain of model-based development of embedded systems. The main contributions of this paper are (1) an analysis of Matlab / Simulink mechanism for variability, (2) concepts for realizing this variability with model transformations, (3) a mapping mechanism that adjusts the model according to configuration decisions (extension of [3]), and (4) concepts for “pruning”, i.e., the cleanup of components that are indirectly influenced by configuration decisions. First, we will give an overview of our approach (in Section 2). After this, we will explain methods of modeling and managing variability with Matlab / Simulink (Section 3). Subsequently, we explain the additional pruning methods (Section 4) and the implementation with model transformations (Section 5).

2 Overview of the Approach We address the challenges described in the introduction with a model-driven approach that relies on higher-order transformations. Before we go into more details, we will give a first overview of our approach (see Figure 1). The approach is structured into two levels (1) Domain Engineering and Application Engineering, similar to other SPL frameworks [1,2]. Please note that we mark processes with numbers ( to ) and artefacts with uppercase letters ( and ; will be used in later figures). In addition, we use indexes (e.g., d and a ) to distinguish artefacts on Domain Engineering and Application Engineering level. 2.1 Domain Engineering Domain Engineering starts with the consideration of the context and requirements of a product line. This Feature Analysis leads to the creation of a Domain Feature Model d , which defines the scope and available configuration options. Subsequently, in Feature Implementation a corresponding implementation is created. Initially, this implementation is given in the native Simulink format (*.mdl files). To access this native implementation in our model-based approach, we have to convert it into a model. To this purpose this we use techniques based on Xtext [4]. (see [5,6] for more details). As a result we get the corresponding Domain Implementation Model Cd . To prepare the derivation of products, a higher-order transformation (HOT) is executed, which reads the DSL meta-model and generates the derivation transformation . The generated transformation will later be used during Application Engineering. 2.2 Application Engineering The first step in Application Engineering is Product Configuration , where, based on the constraints given by the Domain Feature Model d , configuration decisions are made, which defines the particular product in terms of selected or eliminated features.

70

G. Botterweck, A. Polzer, and S. Kowalewski

Language Eng.

Requirements

Features

Implementation

Meta-model Requirements Metamodel

Feature Metamodel

Implementation DSL Metamodel

Model Process

1

Domain Engineering

Legend

2

Feature Analysis

Feature Implementation

Domain Feature Model

Domain Implementation Model

Product Line Requirements

Generated Process

Cd

Ad 3 Generate Derivation

generates

4

5

6

Configuration Processing

Derivation

Application Engineering

Product Configuration

7 Additional Pruning Operations

Application Feature Model

Product Requirements

Aa

Application Implementation Model

Ca

Fig. 1. Overview of the approach

This results in a product-specific configuration which is saved in the Application Feature Model a . After some further processing , this configuration is used in the Product Derivation transformation generated earlier by the HOT. This derivation reads the Domain Implementation Model Cd and – based on the product-specific configuration – derives a product-specific implementation. After additional pruning operations , the result is saved as the Application Implementation Model Ca , which can be used in further processing steps (e.g., Simulink code generation) to create the final executable product.

Using Higher-Order Transformations to Derive Variability Mechanism

71

Fig. 2. Feature Model for the variant Matlab / Simulink model shown in Figure 3

In the following sections, we will describe this in more detail. We start with a discussion of variability mechanisms during Feature Implementation and Derivation Section 3. Subsequently, the Pruning Operations are introduced in Section 4.

3 Managing Variability with Matlab / Simulink In this section, we introduce the variability mechanisms which we used in Simulink models and how they are influenced by configuring a corresponding feature model. As an example see the feature model shown in Figure 2, which contains typical notational elements of feature models. This feature model has an optional Feature A, XOR-grouped Feature B and Feature C, and OR-grouped Feature D and Feature E. Additionally the requires relation indicates that Feature B needs Feature A, i.e., whenever B is selected A has to be selected as well. This model defines a set of legal configurations. Each of these configurations contains a list of selected features and represents a product of the product line. Matlab / Simulink is a modeling and simulation tool provided by The Mathworks. The tool provides Blocks which can be represented graphically and Lines which indicate communication signals. Blocks can contain other blocks, which allows to abstract functionality in special blocks called Subsystems. A similar technique is used by summarizing multiple communication signals into buses. In many cases, a feature can be implemented in Matlab / Simulink by one cohesive subsystem containing the feature’s functionality. All necessary communication signals consumed by the subsystem have to be provided by an interface, represented by Input ports. These input ports are normally connected to buses. The information provided by a component are made available via Output ports, which are again organized as buses. We identified different possibilities to introduce variability in Matlab / Simulink for the required Feature Implementation . Predominantly, we use the technique called negative variability. When applying this technique a model is created, which contains

72

G. Botterweck, A. Polzer, and S. Kowalewski

Fig. 3. Implementing Variability within a Matlab / Simulink model

the union of all features across all possible configurations. When deriving a productspecific model this “union” model is modified such that features that were selected are activated and features that were not selected are deactivated or deleted. To realize such a model in Simulink we can use two different approaches: (1) embedding the variability mechanisms internally (i.e., within the Simulink model) or (2) manipulating the model, based on variability information described externally (i.e., outside of the model). We will describe these two different techniques by explaining how common structures of feature models (Optional feature, Or Group, Alternative Group) can be implemented. For more information see [7,8]. An overview of feature diagrams and their formal semantics can be found in [9]. 3.1 Variability Mechanisms within the Simulink Model It is possible to realize variability by inserting artificial elements into the Simulink model. These elements do not implement functionality of a feature, but the variability mechanism described before. See the example model in Figure 3 where the blocks that

Using Higher-Order Transformations to Derive Variability Mechanism

73

implement features (Feature A, Feature B, Feature C, . . . ) have been augmented with additional elements for variability (Feature A active, Integration, Variant, VP). Mandatory features are – by definition – present in all variants. Hence, there is nothing to do for the implementation of mandatory features when deriving a product. Please notice that there is no mandatory feature in the example. Optional features can be realized in Matlab / Simulink models as a triggered subsystem, which is a special block that can be activated using a boolean signal (see Feature A in Figure 3). By using these mechanisms we are able to activate or deactivate a feature implementation. When modeling Alternative (XOR) group and Or group we can use similar variability mechanisms. However, in addition we have to take care of the resulting signals and how they are fed into subsequent blocks. For alternative features we apply a Switch block (see the block VP in Figure 3) to choose the right output signal. For OR-related features the integration of the results cannot be described in general, but has to be implemented depending on the particular case. In particular, we have to take into the account the case when more than one feature of the group is selected and present in the implementation. We can implement an integration block for such cases in different ways. One example, is the case where a limit is calculated for a certain dimension. Then the integration can be done by using a minimum (or maximum) function. In doing so, the lowest (highest) value is used by the system. As an example for this see Feature D and Feature E which are combined using an Integration block. The Feature Model can contain additional constraints, e.g., the Requires line in Figure 2. These relations are sometimes introduced because of strategic or economical reasons, sometimes caused by technical dependencies in the implementation model. 3.2 Variability Mechanisms Outside of the Simulink Model A second possibility, besides variability within the model, is the direct manipulation of the model with an external tool. To this end, during product derivation it is necessary to analyze the structure of a model file and delete the blocks representing deactivated features in such a way that a desired configuration is obtained. When creating the union model (covering all potential products) it might be necessary to create a model, which could not be executed within Simulink since the execution semantics of the created structure is undefined. This is caused by variability decisions, which are still to be made and cause conflicting elements to remain. Only when we further remove elements, then we get an executable model. As an example consider the case when we want to combine signals of two alternative features in an XOR group. In the union model, we might create the blocks for these two features side-by-side and feed their results into the same inport of the next block. As long as we configure this model (i.e., when the variability is applied), some parts will be removed, such that we get a valid and executable Simulink model. However, if we leave the union model (i.e., no variability applied) we do not realize the exclusion of the two features (“the X in XOR”). This leads to two signals feeding into one input port, which is an invalid Simulink model with undefined execution semantics. In the example in figure Figure 3 this would correspond to connecting the F B Bus output port of block Feature B directly to the port F bus of the bus Output Signals,

74

G. Botterweck, A. Polzer, and S. Kowalewski

while at the same time connecting the F C Bus output port of Block Feature C directly to the same port F bus. If we would try to execute such a model, Simulink would respond with an error message. The advantage of this kind of external method is that we do not have to pollute the domain model with artificial variability mechanisms. Analyzing both possibilities, we came to the conclusion that a combination of both is an appropriate way of introducing variability. There are two major requirements which have to be fulfilled introducing variability methods. On the one hand, we have to keep the characteristics of model based development (e.g., easy testing and simulation, capturing of dependencies possible), on the other hand the derived product should no longer contain any variability mechanisms. The mechanisms, which we introduced to realize this are explained in the next section. 3.3 Managing Variability The mechanism that implements the variability of a feature tree has to fulfill certain requirements. In particular, it is important to keep the ability of simulating and testing the model. Therefore, it is necessary to build a model which has correct syntax, even after the internal variability mechanisms have been introduced. Additionally, the developer must have the possibility to introduce new features directly in the model. Due to the fact that there are space and performance requirements the mechanisms have to be removed if a product-specific model is derived form a configuration. To this end, in general we used the approach of modeling variability within Simulink but with blocks which are specially marked as variability blocks. These special blocks are adopted afterwards according to the desired configuration. This means for obtaining a configuration, features that are not necessary will be deleted. Additionally signals between blocks are rerouted to be able to eliminate the variability blocks, which are not necessary in the derived product. The exact methods for a Switch-block, Triggered subsystem and, integration mechanism is given in the following paragraphs. The Switch-block (see Figure 3 VP) is used to express the relation between alternative grouped features. Therefore only one of them will give their contribution to the system. Using this, the developer of the Simulink model is able to execute all features simply by choosing a configuration of the switch, which selects the corresponding feature implementation block. When deriving the final executable product, it is necessary to delete those features that are not selected in the feature configuration. The output ports of each selected feature has to be connected with the port the switch block points to. All other corresponding signals have to be removed. In the end, no variability mechanism should be left in the model. The situation is a bit simpler for triggered subsystems (see Figure 3 Feature A), which implement optional features. During simulation these blocks can be selected easily using trigger-signals. If the corresponding feature is selected then the triggerport has to be activated. When deriving a product-specific model a subsystem has to be deleted if the corresponding feature is deactivated. If a feature is activated nothing has to be done.

Using Higher-Order Transformations to Derive Variability Mechanism

75

A general mechanism to join the signals of features is not so easy to adopt. When simulating the system the developer has to activate the desired features. This can be done either by using triggered subsystems to implement the features or just by disconnecting their signals with the block which joins the signals. In case of deriving a real product two cases have to be distinguished. If only one feature is selected the subsystems realizes other feature and the variability block (see Figure 3 Integration) joining the signals can be deleted. If more than one feature is selected the subsystems implementing the features which are not selected can be deleted. But in this case the integration mechanism is still necessary for the remaining subsystems.

4 Pruning After handling feature implementation and applying the basic variability decisions there are more adaptations that have to be done. In particular, we have to configure components that are indirectly influenced by the variability decisions. One example for such adaptation are interfaces for input/output signals. As soon as features (i.e., the block implementing that feature) are removed from the model during product derivation some signals are no longer required. Hence, the interfaces have to be updated accordingly to (1) heal inconsistencies and/or (2) optimize the implementation. Such adaptation have to be done recursively on all levels of the hierarchy of subsystems. Figure 4 shows an example with the two subsequent model transformations for product derivation (negative variability) and pruning. First, during Product Derivation some block are removed as a direct consequence of configuration decisions. Then, during Pruning dependent elements, which are indirectly influenced by the operation before, are cleaned up.

5 Implementation The implementation discussed here (see Figure 5) is a technical realization of the approach shown earlier (see Figure 1). The technical implementation follows the same structure, with Domain Engineering (Processes to ) and Application Engineering (processes to ). 5.1 Generating the Derivation Transformation The higher-order transformation (HOT) is the only transformation which is generated completely manual. It is realised by Metamodel2Derivation.atl , and reads the meta-model of the DSL and generates the model transformation , which is able to copy instances of this DSL. Some excerpts of Metamodel2Derivation.atl are shown in Listing 1. The transformation is generated as an ATL query which concatenates the output as one large string. The helper function generateCopyRules() (see Listing 1, lines 4– 8) generates copy rules for all classes in the meta-model. Details of each copy rule are generated by the function Class.toRuleString() (see Listing 1, lines 10– 21). The resulting strings form the transformation file for the model transformation , which realizes the “negative variability”. It is explained in the next section.

76

G. Botterweck, A. Polzer, and S. Kowalewski

6

7

Fig. 4. Example of pruning

5.2 The Derivation Transformation The generated derivation transformation DeriveImplementation.atl realizes a principle called “negative variability” [10] (also known as a “150% model”), where the Domain Implementation Model Cd contains the union of all product-specific models. Hence, the derivation transformation has to selectively copy only those elements, which

Using Higher-Order Transformations to Derive Variability Mechanism

77

L egend

1

2

3

4

5

6

7

Fig. 5. Technical model workflow

will become part of the product-specific model, here the Application Implementation Model Ca . This is realized using the following mechanisms: – For each meta-class in the DSL there is one copy rule. For instance, for the class Block a rule is created which copy instances of the class Block. – Each copy rule contains a condition that refers to an .isVisible() helper function, which controls whether an element is “visible” for the particular product and, hence, is copied or not. – Moreover, to avoid inconsistencies, whenever references are processed, it is checked if the referenced elements are visible, as well.

78 1 2

G. Botterweck, A. Polzer, and S. Kowalewski query Metamodel2Derivation = [..]

3 4 5 6 7 8

helper def : generateCopyRules ( ) : String = ECORE ! EClass −>allInstancesFrom ( ’IN’ ) −>sortedBy ( o | o . cname ( ) ) −>iterate ( e ; acc : String = ’’ | acc + e . toRuleString ( ) ) ;

9 10 11 12 13 14 15 16 17 18 19 20 21 22

helper context ECORE ! EClass def : toRuleString ( ) : String = if not self . ” abstract ” and self−>inclusionCondition ( ) then ’rule ’ + self−>cname ( ) + ’ {\n’ + ’ from s : SOURCEMETA!’ + self−>cname ( ) + self−>inputConstraint ( ) + ’\n’ + ’ to t : TARGETMETA!’ + self−>cname ( ) + ’ mapsTo s (’ + self−>contentsToString ( ) + ’)\n’ + ’}\n\n’ else ’’ endif ; [..]

Listing 1. Metamodel2Derivation.atl, transformation (3), excerpt

– The decision whether instances of a certain meta-class will be copied are implemented in the visibility functions. For instance, Block.isVisible() calculates this for all instances of Block. In the initial version of DeriveImplementation.atl, which is automatically generated from the meta-model, all visibility functions are set to true by default. – In a second transformation, DeriveImplementationVisibility.atl Listing 2 these visibility functions are manually redefined and overloaded. These functions access the product configuration and determine, which elements go into the product and which do not. Later on, these will be overloaded over the default visibility functions, by using ATL’s superimpose mechanisms. During the executing of the product derivation transformations the visibility functions read the Application Feature Model a and decide how this influences the filtering of elements in the Domain Implementation Model. To come to this decision, it is necessary to know how the various features in the feature model ( d and a ) are related to the corresponding elements in the Matlab / Simulink implementation model. This is defined by the Mappings d between the Domain Feature Model d and the Domain Implementation Model Cd . With that mechanism we are able to link features (given in the configuration model) to the corresponding blocks (given in the implementation model). To implement pruning operations we are currently experimenting with new userdefined methods. These methods adapt the copy rules such that the pruning methods briefly introduced in Section 4 are realized. These pruning operations are influenced by

Using Higher-Order Transformations to Derive Variability Mechanism 1

79

module DeriveArchitectureDetermineVisibility ;

2 3

create TARGET : TARGETMETA from SOURCE : SOURCEMETA , CONFIG : CONFIGMETA ;

4 5 6 7

−− t r u e

i f B l o c k i s r e f e r e n c e d by a s e l e c t e d f e a t u r e helper context SOURCEMETA ! Block def : isSelected ( ) : Boolean = [..]

8 9 10 11

−− t r u e

i f B l o c k i s r e f e r e n c e d by an e l i m i n a t e d f e a t u r e helper context SOURCEMETA ! Block def : isDeselected ( ) : Boolean = [..]

12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

helper context SOURCEMETA ! Block def : isVisible ( ) : Boolean = if self . isSelected ( ) then if self . isDeselected ( ) then true . debug ( ’feature conflict for block’ + self . name ) else true endif else if self . isDeselected ( ) then false else true −− d e f a u l t t o v i s i b l e endif endif ; [..]

Listing 2. DeriveImplementationVisibility.atl, transformation (5), excerpt

the configuration and the mapping of features. However, they affect model components which are only indirectly referenced by the mapping.

6 Related Work Several projects deal with Product Derivation. The ConIPF project provides a methodology for product derivation [11]. ConIPF concentrates on the formalization of derivation knowledge into a configuration model. Deelstra et al. provide a conceptual framework for product derivation [12]. When dealing with variability in domain-specific languages a typical challenge is the mapping of features to their implementations. Here, Czarnecki and Antkiewicz [13] used a template-based approach where visibility conditions for model elements are described in OCL. In earlier work [14,15], we used mapping models and model transformations in ATL [16] to implement similar mappings. Heidenreich et al. [17] present FeatureMapper, a tool-supported approach which can map features to arbitrary EMFbased models [18].

80

G. Botterweck, A. Polzer, and S. Kowalewski

Voelter and Groher [10] used aspect-oriented and model-driven techniques to implement product lines. Their approach is based on variability mechanisms in openArchitectureWare [19] (e.g., XVar and XWeave) and demonstrated with a sample SPL of home automation applications. In earlier work [20,5], the authors have experimented with other mechanisms for negative variability (pure::variants Simulink connector [21] and openArchitectureWare’s XVar mechanism [19]) to realize variability in Embedded Systems. The mechanisms were applied to microcontroller-based control systems and evaluated with a product line based on the Vemac Rapid Control Prototyping (RCP) system. The approach presented here can be seen as an integration and extension of work from Weiland [22] and Kubica [23]. Both presented mechanisms to adopt Matlab / Simulink-models based on feature trees. Weiland implemented a tool which influences certain variability points in a Simulink model. However, variability mechanisms are not removed during variability resolution. The approach given by Kubica constructs a new Simulink model for a derived product. Tisi et al. provide an literature review on higher-order transformations [24] including a classification of different types of HOT. Oldevik and Haugen [25] use higherorder transformations to implement variability in product lines. Wagelaar [26] reports on composition techniques for model transformations.

7 Conclusion In this paper we presented an approach to introduce and adopt variability in a modelbased domain specific language (Matlab / Simulink) for developing embedded systems. All model transformations were implemented in the ATLAS Transformation Language (ATL) [16]. The original version was developed with ATL 2.0. We are currently experimenting with ATL 3.0 and its improved support for higher-order transformations. With our approach we are able to simulate and test variable Simulink-models by introducing mechanisms to manage variability and additionally derive models which contain only the product specific components. This provides us with (models of) systems that are more efficient, e.g., with respect to memory and computation time.

Acknowledgements This work was supported, in part, by Science Foundation Ireland grant 03/CE2/I303 1 to Lero – the Irish Software Engineering Research Centre, http://www.lero.ie/. The higher-order transformation was inspired by a case study by Dennis Wagelaar.

References 1. Clements, P., Northrop, L.M.: Software Product Lines: Practices and Patterns. The SEI series in software engineering. Addison-Wesley, Boston (2002) 2. Pohl, K., Boeckle, G., van der Linden, F.: Software Product Line Engineering: Foundations, Principles, and Techniques. Springer, New York (2005)

Using Higher-Order Transformations to Derive Variability Mechanism

81

3. Beuche, D., Weiland, J.: Managing flexibility: Modeling binding-times in Simulink. In: [27], pp. 289–300 4. Eclipse-Foundation: Xtext, http://www.eclipse.org/Xtext/ 5. Polzer, A., Botterweck, G., Wangerin, I., Kowalewski, S.: Variabilitaet im modellbasierten Engineering von eingebetteten Systemen. In: 7th Workshop Automotive Software Engineering, collocated with Informatik 2009, Luebeck, Germany (September 2009) 6. Botterweck, G., Polzer, A., Kowalewski, S.: Interactive configuration of embedded systems product lines. In: International Workshop on Model-driven Approaches in Product Line Engineering (MAPLE 2009), colocated with the 12th International Software Product Line Conference, SPLC 2008 (2009) 7. Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, S.: Feature oriented domain analysis (FODA) feasibility study. SEI Technical Report CMU/SEI-90-TR-21, ADA 235785, Software Engineering Institute (1990) 8. Czarnecki, K., Eisenecker, U.W.: Generative Programming. Addison Wesley, Reading (2000) 9. Schobbens, P.Y., Heymans, P., Trigaux, J.C.: Feature diagrams: A survey and a formal semantics. In: 14th IEEE International on Requirements Engineering Conference. RE 2006, pp. 136–145 (2006) 10. Voelter, M., Groher, I.: Product line implementation using aspect-oriented and model-driven software development. In: 11th International Software Product Line Conference (SPLC 2007), Kyoto, Japan (September 2007) 11. Hotz, L., Wolter, K., Krebs, T., Nijhuis, J., Deelstra, S., Sinnema, M., MacGregor, J.: Configuration in Industrial Product Families - The ConIPF Methodology. IOS Press, Amsterdam (2006) 12. Deelstra, S., Sinnema, M., Bosch, J.: Product derivation in software product families: a case study. The Journal of Systems and Software 74, 173–194 (2005) 13. Czarnecki, K., Antkiewicz, M.: Mapping features to models: A template approach based on superimposed variants. In: Gl¨uck, R., Lowry, M. (eds.) GPCE 2005. LNCS, vol. 3676, pp. 422–437. Springer, Heidelberg (2005) 14. Botterweck, G., Lee, K., Thiel, S.: Automating product derivation in software product line engineering. In: Proceedings of Software Engineering 2009 (SE 2009), Kaiserslautern, Germany (March 2009) 15. Botterweck, G., O’Brien, L., Thiel, S.: Model-driven derivation of product architectures. In: Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering (ASE 2007), Atlanta, GA, USA, pp. 469–472 (2007) 16. Eclipse-Foundation: ATL (ATLAS Transformation Language), http://www.eclipse.org/m2m/atl/ 17. Heidenreich, F., Kopcsek, J., Wende, C.: Featuremapper: Mapping features to models. In: ICSE Companion 2008: Companion of the 13th international conference on Software engineering, pp. 943–944. ACM, New York (2008) 18. Eclipse-Foundation: EMF - Eclipse Modelling Framework, http://www.eclipse.org/modeling/emf/ 19. openarchitectureware.org: Official open architecture ware homepage, http://www.openarchitectureware.org/ 20. Polzer, A., Kowalewski, S., Botterweck, G.: Applying software product line techniques in model-based embedded systems engineering. In: 6th International Workshop on Modelbased Methodologies for Pervasive and Embedded Software (MOMPES 2009), Workshop at the 31st International Conference on Software Engineering (ICSE 2009), Vancouver, Canada (May 2009)

82

G. Botterweck, A. Polzer, and S. Kowalewski

21. Pure::systems: pure::variants Connector for Simulink 22. Weiland, J., Richter, E.: Konfigurationsmanagement variantenreicher simulink-modelle. In: Informatik 2005 - Informatik LIVE!, Band 2. Koellen Druck+Verlag GmbH, Bonn (September 2005) 23. Kubica, S.: Variantenmanagement modellbasierter Funktionssoftware mit SoftwareProduktlinien. PhD thesis, Univ. Erlangen-N¨urnberg, Arbeitsberichte des Instituts f¨ur Informatik, Friedrich-Alexander-Universit¨at Erlangen N¨urnberg (2007) 24. Tisi, M., Jouault, F., Fraternali, P., Ceri, S., B´ezivin, J.: On the use of higher-order model transformations. In: [27], pp. 18–33 25. Oldevik, J., Haugen, O.: Higher-order transformations for product lines. In: 11th International Software Product Line Conference (SPLC 2007), Washington, DC, USA, pp. 243–254. IEEE Computer Society, Los Alamitos (2007) 26. Wagelaar, D.: Composition techniques for rule-based model transformation languages. In: Vallecillo, A., Gray, J., Pierantonio, A. (eds.) ICMT 2008. LNCS, vol. 5063, pp. 152–167. Springer, Heidelberg (2008) 27. Paige, R.F., Hartman, A., Rensink, A. (eds.): ECMDA-FA 2009. LNCS, vol. 5562. Springer, Heidelberg (2009)

Model-Based Extension of AUTOSAR for Architectural Online Reconfiguration Basil Becker1 , Holger Giese1 , Stefan Neumann1 , Martin Schenck2 , and Arian Treﬀer2 Hasso Plattner Institute at the University of Potsdam Prof.-Dr.-Helmert-Str. 2-3 14482 Potsdam, Germany 1 [email protected], 2 [email protected]

Abstract. In the last few years innovations in the automotive domain have been realized by software, leading to a dramatically increased complexity of such systems. Additionally, automotive systems have to be ﬂexible and robust, e.g., to be able to deal with failures of sensors, actuators or other constituents of an automotive system. One possibility to achieve robustness and ﬂexibility in automotive systems is the usage of reconﬁguration capabilities. However, adding such capabilities introduces an even higher degree of complexity. To avoid this drawback we propose to integrate reconﬁguration capabilities into AUTOSAR, an existing framework supporting the management of such a complex system at the architectural level. Elaborated and expensive tools and toolchains assist during the development of automotive systems. Hence, we present how our reconﬁguration solution has been seamlessly integrated into such a toolchain.

1

Introduction

Today most innovations in the automotive domain are realized by software. This results in a dramatically increasing complexity of the developed software systems.1 The objective of the AUTOSAR framework is to deal with this complexity at the architectural level. Additionally, these systems need to deal with many situations concerning the context in which the software is operating. Such systems and especially the software, which is realizing essential functionalities of the overall system, need to be ﬂexible to react to changes of its context. Regardless of whether such a system needs to react to failures or to other contextual situations2 , ﬂexibility and robustness plays an important role in today’s automotive applications. 1 2

The complexity concerning the size of the developed software, the functionality realized by the software system and so on. An example of such a situation is in the case the car is connected to diagnostic devices.

S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 83–97, 2010. c Springer-Verlag Berlin Heidelberg 2010

84

B. Becker et al.

Reconﬁguration is one possibility to facilitate the ﬂexibility and robustness of such systems. Diﬀerent possibilities exist to realize reconﬁguration within automotive software. One is to realize reconﬁguration mechanisms at the functional level. Because the AUTOSAR framework primarily provides mechanisms to deal with the complexity at the architectural level, also the reconﬁguration aspects should be available at the same level. Deriving architectural information from the functional level could be diﬃcult or even impossible and hence we propose to specify reconﬁguration aspects at the architectural level and to automatically derive the needed reconﬁguration functionality based on the architectural information. Further, in a typical development scenario one has to deal with a black-box view of components provided by third parties for which elaborated information about the included functionality is not available, what also hampers the management of reconﬁguration aspects at the functional level. Another possible solution is to introduce a new approach inherently facilitating reconﬁguration aspects in the context of automotive systems. Today, standard methods and tools already exist for supporting the development process of AUTOSAR. Because adapting existing tools or developing new ones is very costly, the propagation of such a new approach would hardly be suitable in practice. Summarizing, we have identiﬁed the need for a development approach that is able to provide reconﬁguration capabilities at the architectural level, which can be seamlessly integrated into an existing development solution and that can also include third party components in the reconﬁgurable architecture. In this work3 we show how reconﬁguration capabilities, which are currently not included in the existing AUTOSAR approach can be supported at the architectural level without degrading existing development solutions, tools or the standard itself. We further show how the needed functionality for realizing the reconﬁguration logic can be automatically generated based on the architectural information describing the reconﬁguration. The used application example for our evaluation is related to the ﬁeld of faulttolerant systems since from our perspective such systems are one possible ﬁeld to which reconﬁguration as discussed in the remainder of this work can be applied. The paper is organized as follows. In Section 2 we discuss existing approaches supporting reconﬁguration relevant for automotive systems and especially those approaches providing reconﬁguration capabilities at the architectural level. In Section 3 we brieﬂy introduce the existing toolchain, which builds the technological foundation for our investigation concerning the developed extension for on-line reconﬁguration within the AUTOSAR framework. Subsequently, in Section 4 we show how such a system is usually modeled with the given tools and how the additional reconﬁguration aspects could be formulated based on the input/output of the existing toolchain. In Section 5 we show how these created additional reconﬁguration aspects are automatically merged back into the original architecture and how the merged result ﬁts into the existing tools without discarding or degrading parts of the original toolchain. Finally we give a short discussion concerning the current results of our work in Section 6. 3

The work presented in this paper is an extension of [2].

Model-Based Extension of AUTOSAR

2

85

Related Work

In several diﬀerent areas of computer science ideas have been presented that are related to the approach we are going to present in this paper. In the ﬁeld of software product lines and especially dynamic software product lines the topic of variable software has been addressed. The software architecture community has presented some work on the reconﬁgurability of robotic systems. Work tailored to the automotive domain has been carried out in the DySCAS project. We did some research on self-optimizing mechatronic systems. In previous work we have presented a modeling technique called Mechatronic UML (mUML) that is suitable for the modeling of reconﬁgurable and self-optimizing mechatronic systems [1,3]. However, the mUML approach diﬀers from the one that will be presented in this paper, in the fact that mUML uses an own code generation mechanism and thus can hardly be integrated into existing development tool chains. In the DySCAS4 project dynamically self-conﬁguring automotive systems have been studied [4,5]. DySCAS does not provide a model based development approach tailored to the speciﬁcation of reconﬁguration. Reconﬁguration is speciﬁed with policy scripts, which are then evaluated by an engine at runtime [6]. Software Product Line Engineering (SPLE) [7] aims at bringing the assembly line paradigm to software engineering. Typically a software product line is used to develop multiple variants of the same product. However, as the classical SPLE approach targets the design-time variability of software it is not comparable to the approach we are going to present in this paper. Recently a new research branch has emerged from SPLE called Dynamic Software Product Line Engineering [8]. In Dynamic Software Product Lines the decision of which variant to run has moved from design time to run time. Such an approach is presented in [10], where the authors describe a dynamic software product line, which is suitable for the reconﬁguration of embedded systems. In contrast to our approach. this one is restricted to the reconﬁguration of pipe-and-ﬁlter architectures and the reconﬁguration has to be given in a textual form. In [11] a framework for the development of a reconﬁgurable robotic system has been presented. However, the presented approach – in contrast to ours – does not support the model-driven development of reconﬁguration. A policy-based reconﬁguration mechanism is described in [13]. The authors present a powerful and expressive modeling notation for the speciﬁcation of self-adaptive (i.e. reconﬁgurable) systems, but their approach requires too much computational power and is thus only remotely applicable to embedded systems. In [14] an approach based on mode automata has been presented. However, mode automata only support switching between diﬀerent behaviors internal to a component and do not cover architectural reconﬁguration.

3

Existing Development Approach

For the development of embedded systems – especially in the automotive domain – several tools exist that provide capabilities for model-based development of 4

http://www.dyscas.org

86

B. Becker et al.

such systems. Tools used by companies are typically mature, provide reliable and optimized code generation mechanisms and are as expensive as complex. Hence, any technique that claims to be usable in the domain of embedded / automotive systems must be integrated into the existing toolchain. We will use this section to exemplary describe a toolchain, which might be used in the context of the AUTOSAR domain speciﬁc language. 3.1

AUTOSAR

The AUtomotive Open System ARchitecture (AUTOSAR) is a framework for the development of complex electronic automotive systems. AUTOSAR provides a layered software architecture consisting of the Application layer, the Runtime Environment and the Basic Software layer. Figure 1 shows the diﬀerent layers of the architecture. The Basic Software layer provides services concerning HW access, communication and Operating System (OS) functionality [15]. The Basic Software provides several interfaces in a standardized form to allow the interaction between the Basic Software layer and the application layer routed through the Runtime Environment. The Runtime Environment handles the communication between diﬀerent constituents of the application layer and between the application layer and the Basic Software layer (e.g., for accessing Hardware via the Basic Software [16]). The Application layer consists of Software Components, which can be hierarchically structured and composed into so-called Compositions. Software Components and Compositions can have ports and these ports can be connected via Connectors (see [17] for more details). The real communication is realized through the Runtime Environment in cases of local communication between Software Components (Compositions) on the same node (Electronic Control Unit) or through the Runtime Environment in combination with the Basic Software in cases of communication between diﬀerent nodes. The main focus of AUTOSAR is the modeling of architectural aspects and of structural aspects. The behavior modeling (e.g., needed control functionality for reading sensor values and setting actuators) is not the main focus of the AUTOSAR framework. For modeling such behaviour, existing approaches and tools can be integrated into the development process of AUTOSAR. One commonly used tool for the model based development of behavior is MATLAB/Simulink (as described in Section 3.2). For executing such functionality AUTOSAR provides the concept of Runnables, which are added as a part of the internal behavior of a Software Component. Developed functionality could be mapped to Runnables and these Runnables are mapped to OS tasks. Additionally, events can be used to decide inside an OS task whether speciﬁc runnables are executed at runtime (e.g., runnables could be triggered by events if new data has been received via a port of the surrounding Software Component). See [18] for more details about the OS provided by the AUTOSAR framework. Once the modeling and conﬁguration hass been done, in the current release 3.1 of AUTOSAR changes at runtime concerning the structure of the application layer (e.g., restructuring connectors) are not facilitated by the framework.

Model-Based Extension of AUTOSAR

87

Fig. 1. The AUTOSAR layered architecture5

3.2

Existing Toolchain

The scheme in Figure 2(a) shows one possible toolchain for the development of AUTOSAR systems. Rectangles with rounded corners represent programs; rectangles with cogwheels stand for processes. The arrows indicate exchange of documents; the type of the document (i.e. models, C code or parameters) is annotated to the arrows. The system’s architecture (i.e. components, ports and connectors) is modeled in SystemDesk.6 Together with the architecture SystemDesk also supports the modeling of the system’s deployment to several ECUs. The components behavior is speciﬁed using MATLAB with the extension Simulink. For MATLAB/Simulink (ML/SL) special AUTOSAR block sets exist, which allow the import of AUTOSAR components speciﬁed in SystemDesk into MATLAB. Within MATLAB the functionality (e.g., control functionality) of the internal behavior of the AUTOSAR components then can then be realized. Further SystemDesk supports the generation of optimized C code, which conforms to the AUTOSAR standard concerning the Runtime Environment (see Section 3.1). Together with the C implementation of the software components modeled in SystemDesk, the generated output also contains a conﬁguration for the basic software layer. This layer is generated from specialized tools (e.g., Tresos by ElectroBit, abbreviated as BSW-C/G in Figure 2) and is speciﬁc to the system modeled in SystemDesk and the available hardware. At the integration step a build environment compiles the generated C code and builds the software running on each ECU. 5 6

Picture taken from http://www.autosar.org/gfx/media pictures/AUTOSAR-components-and-inte.jpg. http://www.dspace.de

88

B. Becker et al.

(a) Exemplary toolchain for development (b) Tool chain for modeling reconﬁgurable with AUTOSAR AUTOSAR architectures Fig. 2. The current and the extended toolchain for the development with AUTOSAR

3.3

Evaluation Example

The used application example for showing the reconﬁguration capabilities that are supplemented to the existing AUTOSAR framework in our approach is the reconﬁguration of a set of adjacent-aligned distance sensors. The discussed evaluation example allows sensor failures to be reacted to in the manner that the failure of individual sensor instances is compensated.7 Such adjacent-aligned sensors are commonly used in a modern car, e.g., in the case of a parking distance control. Such a parking distance control uses sensors (e.g., ultrasonic sensors) embedded in the front or rear bumper for measuring the distance to nearby obstacles. Additionally in Section 5.3 we discuss the evaluation results of experiments we have made on an evaluation platform using the techniques described in Section 4.

4

Modeling Reconfiguration

In order to make an AUTOSAR system architecture reconﬁgurable, some additional concepts are needed. The toolchain needs to be extended in a certain way that extensions do not invalidate the existing toolchain. From our perspective the best way is to integrate an optional tool that can be plugged into the existing toolchain. 4.1

Extended Toolchain

Our modeling approach is currently restricted to the modeling of AUTOSAR software architectures. The toolchain in Figure 2(b) shows our approach of extending the existing toolchain by another tool without degrading existing ones. By using this proposal the developer is free to choose whether he wants to use our given enhancement or not. He can either model an architecture that does not provide any reconﬁguration or he can use our tool in addition and empower 7

For our application example we assume that a sensor failure can be observed at the level of Software Components.

Model-Based Extension of AUTOSAR

89

Fig. 3. SystemDesk screenshot of the evaluation example conﬁguration

himself to specify and realize reconﬁguration aspects. The advantages are obvious: better control and overview due to the diagrammatic depiction. A detailed description of the extended toolchain can be found in [2]. Figure 3 shows the relevant part of the software architecture concerning our application example modeled in SystemDesk. Like depicted on the right side of Figure 3 the composition consists of four Software Components representing the distance sensors8 connected to another composition SensorLogic evaluating the sensor values to a single value provided by the port ShowDistanceOut.9 The above mentioned elements (Software Components, ports and connectors) are used to describe the software when no reconﬁguration is intended. Some additional elements shown in Figure 3 are described in more detail in the following section. These elements (Interpolation, Reconfiguration and the unused ports of the sensors) are used later to realize the reconﬁguration functionality. 4.2

dTool

The usual modeling procedure is not altered until the modeling in SystemDesk10 is initially done as described above. After the model from SystemDesk is exported in form of an XML ﬁle11 and loaded into the dTool the constituents concerning the reconﬁguration can be speciﬁed. Using the dTool we are now able to 8 9 10 11

The ports accessing the HW via the Runtime Environment and Basic Software are not shown here because they are not object of reconﬁguration. To allow a better understanding SensorLogic calculates a single output value based on the diﬀerent input values. Potentially also several output values can be computed. http://www.dspace.de/ww/en/ltd/home/products/sw/ system architecture software/systemdesk.cfm The AUTOSAR framework speciﬁes XML-Schemes for exchanging AUTOSAR models in a standardized form.

90

B. Becker et al.

(a) Conﬁguration in case Sensor 2 is bro- (b) Conﬁguration in case Sensor 3 is broken ken Fig. 4. Two conﬁgurations of the architecture for two diﬀerent scenarios

model two diﬀerent aspects relevant for the reconﬁguration. On the one hand, our tool allows new conﬁgurations to be created that diﬀer from the initial one. Such diﬀerences are alternative connections (in the form of connectors) between components and/or compositions. Which parts of the architecture are relevant concerning reconﬁguration is indicated by the Software Component Reconfiguration included in the original SystemDesk model. Alternatively, the dTool allows relevant parts of the imported architecture to be chosen manually. On the other hand, our dTool allows an automaton to be modeled, which speciﬁes how to switch between the modeled conﬁgurations. Figure 4(a) depicts the conﬁguration (modeled in the dTool) associated with the state that sensor two is broken. In the shown conﬁguration the value of the port DistanceOut from the broken sensor Sensor 2 is not available. Consequently the value sent to the port Distance 2 In of the composition SensorLogic is interpolated from the two sensor values of the ﬁrst and the third sensor via the additional composition Interpolation. Figure 4(b) shows the conﬁguration associated with the state that sensor three is broken and the value sent to the port Distance 3 In of the composition SensorLogic is interpolated based on the sensor values of the second and the fourth sensor. The composition Interpolation used here provides some functionality for interpolating two diﬀerent sensor values. This functionality has been added specifically for our application example.12 This interpolation functionality is used to approximate the value of a broken sensor based on the values of two adjacent sensors. It is potentially possible to integrate this functionality into an existing Software Component, but for a better understanding we decided to introduce a new Software Component for this purpose. 12

In our application example this functionality has been realized using MATLAB/Simulink to provide more vaguely pesimistic distance values.

Model-Based Extension of AUTOSAR

91

Fig. 5. Reconﬁguration automaton in the dTool

The second relevant part for the reconﬁguration that can be modeled in the dTool, is the automaton shown in Figure 5 specifying how to switch between diﬀerent conﬁgurations. The automaton consists of the initial state initial where all four sensors work correctly, the state sensor2broke where the second sensor is broken, the state sensor3broke where the third sensor is broken, and the state allfail where the ﬁrst or the fourth sensor or more than one sensor is broken. Transitions between these states specify which reconﬁguration is applied at runtime. The transitions are further augmented with guards. These guards are expressions over the values provided by components within the reconﬁgurable composition, which provide information relevant for the reconﬁguration (in our case this information is provided via the Status-ports of the four Sensor-Software Components). An example of such a guard is shown at the transition from state initial to state sensor2broke requiring that the status port of the Software Component Sensor 2 provides the value 0 (indicating a broken sensor). For the application example we assume that such status ports of the Software Components representing the sensors exist as we otherwise were not able to observe each sensor’s status.13 AUTOSAR allows a hierarchy of compositions to be modeled. Our approach supports this AUTOSAR feature seamlessly. In the dTool a hierarchy of compositions is represented as two or more nested reconﬁguration compositions. It is possible that one reconﬁgurable composition contains more than one inner reconﬁgurable composition. In Figure 6 an example for a nested composition is shown. The example is a combination of two adjacent-aligned distance sensor arrays (represented through SensorCompositionFront and SensorCompositionRear ) like shown in Figure 3. The composition on the left represents the parking sensors of the front bumper, and the composition on the right the sensors of the rear bumper. Depending on the current conﬁguration of the used compositions 13

Alternatively an observer could be realized in the form of an additional Software Component evaluating the sensor values over time and providing the status ports. If the measured values of consecutive points in time repeatedly have improper values (too big diﬀerences) a malfunction can be deduced.

92

B. Becker et al.

Fig. 6. An example for a hierarchy of compositions

(SensorCompositionFront and SensorCompositionRear ) the StateManager in Figure 6 decides which conﬁguration to choose resulting in diﬀerent functional behavior realized by ParkDistanceLogic.14

5

Merge

In its current version the AUTOSAR standard does not support reconﬁguration as a ﬁrst-class modeling element. While reconﬁguration can be realized at the functional level when using the AUTOSAR framework, this won’t be visible at the modeling elements provided by the framework. Thus, SystemDesk also does not support modeling of diagrams that represent diﬀerent variations of one composition. Hence the direct import of the reconﬁguration, which we have modeled in the dTool, is impossible. Nevertheless we want to make use of SystemDesk’s elaborated and AUTOSAR standard conform code generation capabilities. We had to ﬁnd a way to translate the reconﬁguration behavior into a SystemDesk/AUTOSAR model. This is done by merging all conﬁgurations into one ﬁnal model. In the ﬁnal model, the reconﬁguration logic will be encapsulated by two components, the RoutingComponent and the StateManager. 5.1

Merging Configurations

Our modeling approach only allows the reconﬁguration of connections between components, and is not suitable for the addition and removal of components at runtime.15 Hence, a merged conﬁguration consists of all components that have been modeled in SystemDesk at the early stages. Connections that do not exist in all conﬁgurations are redirected via a special component, called RoutingComponent. Therefore, the ﬁrst step is to build the intersection of all 14

15

Although in the shown example no architectural reconﬁguration is realized, our approach supports such reconﬁguration for hierarchies in the same way as shown above for the non-hierarchical case. Please note that the dTool allows to modeling conﬁgurations, that do not contain all components. The semantics is that the components are hidden. A dynamic loading of components is not supported by AUTOSAR.

Model-Based Extension of AUTOSAR

93

conﬁgurations. Connections found here are directly inserted into the merged model. Next the RoutingComponent is added. Generating the RoutingComponent: The RoutingComponent intersects every connection that is not invariant to the reconﬁgurable composition. Therefore, the RoutingComponent has to know at each point in time which conﬁguration is currently the active one. Which conﬁguration is active, is determined by the evaluation of the current conﬁguration and the valuation of the variables used in the guards of the reconﬁguration automaton (cf. Figure 5). Because evaluating at each point in time the actual value of the automaton and repeatedly sending this value to the RoutingComponent is much too expensive, we have implemented a diﬀerent strategy. The conﬁgurations modeled in the dTool each get a unique number. The RoutingComponent receives the number of the currently active conﬁguration via a special input port. Using this information the RoutingComponent can be implemented as a sequence of switch statements. The computation of the current active conﬁguration is done in a second component – the StateManager. The dTool automatically generates a runnable for the RoutingComponent containing the described behavior. StateManager: The StateManager – as brieﬂy mentioned above – is responsible for the computation of the currently active conﬁguration. Therefore, it has to be connected with all ports that provide values, which are used in the guards of reconﬁguration automaton. Each time the StateManager receives an update on its ports, it has to evaluate the automaton again and change the value of the currently active conﬁguration accordingly. Updates to the StateManager’s ports are signaled by events, which then trigger the StateManager’s evaluation function.16 The StateManager is the component in the merged project that has to deal with the hierarchy of compositions. The nested reconﬁgurable composition’s StateManager therefore provides a port that publishes its current conﬁguration. This port’s value is then used by the StateManager of the surrounding reconﬁgurable composition. Please note that compositions in AUTOSAR can be used at multiple places. Hence in one situation a composition can be used in a nested way and once at the topmost level. Therefore, using the conﬁguration of the surrounding reconﬁgurable composition’s StateManager is not allowed. Referring to Figure 6 the StateManagers included in the compositions SensorCompositionFront and SensorCompositionRear cannot use the status of the StateManager of the surrounding composition, but the StateManager of the surrounding composition can use the StateManagers included in the sub-compositions. 5.2

Final SystemDesk Project

Figure 7 shows the Sensor composition after exporting the merged model to SystemDesk again. The components for the distance sensors are all connected to the 16

Event mechanisms in form of AUTOSAR Runtime Environment events (for more information see [16]) have been used to trigger the runnable realizing the functionality of the StateManager.

94

B. Becker et al.

Fig. 7. Resulting merged software architecture in SystemDesk

RoutingComponent, which is named Reconf in this diagram. The system modeled in our application example does not allow an interpolation for the sensor components one and four. Subsequently, these components are always directly connected with the SensorLogic component and are not handled by the RoutingComponent. Nevertheless, they also have to be connected to the RoutingComponent as the sensor values are used to interpolate the second, respectively third sensor in the case of a failure. The StateManager is depicted below the RoutingComponent and is connected to the RoutingComponent through the Conf ports, which provide information about the currently active conﬁguration. As deﬁned in the reconﬁguration automaton (cf. Figure 5), the decision of which conﬁguration to use depends on the values of the sensor components’ status ports. Therefore the StateManager is connected to those ports. As the reconﬁguration automaton does not rely on any values provided by the Interpolation or SensorLogic component, the StateManager is not connected with them. 5.3

Evaluation Results

The above described approach for the modeling and realization of reconﬁguration aspects has been evaluated within a project arranged at the Hasso Plattner Institute in collaboration with dSPACE GmbH. As an evaluation platform for the shown approach the Robotino robot17 has been used, which provides an open platform for running C/C++ programs (among others) on a Real-Time Operating System (RTOS). The RTOS is 17

http://www.robotino.com

Model-Based Extension of AUTOSAR

95

provided in form of RTAI18 , which is a real-time extension for the Linux operating system. To be able to evaluate the developed concepts on this platform an execution environment has been realized based on the existing RTAI Linux, which allows the outcome of the above described extended toolchain, including the resulting parts of the reconﬁguration functionality, to be compiled and executed. The robot provides nine distance sensors uniformly distributed around its chassis. In the context of our evaluation experiments we modeled the reconﬁguration of distance sensors accordingly to the above used evaluation example using nine instead of four sensors.19 The generated source code of the diﬀerent tools has been compiled and executed on the platform to show the applicability of our approach. In addition, we analyzed the overhead resulting from the reconﬁguration functionality added by our approach in comparison to the original functionality without any reconﬁguration capabilities. For this purpose we measured the execution time of the generated reconﬁguration automaton included in the added StateManager in combination with the parts resulting from the routing functionality realized in the additional RoutingComponent (both components are shown in Figure 7). In the case of the nine sensors provided by the robot we measured execution times of the relevant parts concerning the reconﬁguration functionality between 20 and 100 microseconds depending on the type of reconﬁguration (react to the defect of one or several sensors at the same point in time). The tests have been realized on the equivalent execution platform on which the real functionality has been executed when running the application example on the robot.20 While the robot provides a more powerful processor like is the case for the most Electronic Control Units (ECUs) used within a modern car, even by using a platform or processor that has only a tenth of the computation power we will not reach an overhead concerning the reconﬁguration leading to an execution time much greater than one millisecond.

6

Conclusion and Discussion

In this paper we have presented an approach to extend AUTOSAR architectures with reconﬁguration capabilities. Like discussed in [12] there exist two diﬀerent strategies for how and when to identify the appropriate conﬁguration. First, identiﬁcation of possible system conﬁgurations is completely done at runtime or second, the identiﬁcation is speciﬁed by the developer at design time. Our approach has to ﬁt into the existing AUTOSAR framework and has to meet certain performance requirements. Therefore, the second strategy has been chosen. Thus, the possible conﬁgurations as well as the decisions for when to switch between them are speciﬁed at design time. In such a way a set of possible variants 18 19 20

For more details see https://www.rtai.org. For a better understanding we decided to only show four sensors in the previous sections. The robot is equipped with 300 MHz processor.

96

B. Becker et al.

in the form of conﬁgurations is deﬁned before runtime and one of these is selected at runtime accordingly. In doing so the overhead added to the resulting reconﬁgurable architecture has been shown to be negligible, but the developer rewards an easier development of reconﬁguration logic, which otherwise has to be done manually at the functional / implementation level. We have successfully shown that it is possible to use high-level architectural modeling techniques without generating massive runtime overhead. As a result of the chosen application domain, the used AUTOSAR framework and the usage of a highly optimized code generator, modeling artifacts (like components, ports and connectors) are no longer visible at runtime. To be able to apply the ﬁrst type of strategy described in [12] and reason at runtime about possible conﬁgurations as well as the decision when to switch between them our approach needs to be extended. The architectural information and the current state concerning the chosen conﬁguration need to be available at runtime, as well as some mechanism realizing the decision regarding in which situation to switch between them. The tradeoﬀ between diﬀerent aspects like ﬂexibility, eﬃciency and safety when applying the diﬀerent strategies needs to be seriously considered, especially for safety-critical systems like automotive systems. Although our approach has only been evaluated in the context of AUTOSAR it should be applicable to almost any component-based development approach, e.g., for AADL [9]. For the future we plan to also support the reconﬁguration of distributed compositions. From an architectural point of view a distributed composition does not diﬀer from a local one, as AUTOSAR completely hides the communication details in the Runtime Environment layer from perspective of the application layer. Anyway, a distributed scenario contains enough challenges such as timing delays, Basic Software conﬁguration, deployment decisions concerning RoutingComponents, just to name a few. Further the high-level architectural modeling we have introduced in this paper also allows the veriﬁcation of the modeled systems. First attempts in these directions have been very promising and we are looking forward to looking into the details. Acknowledgment. We would like to thank dSPACE GmbH and especially Dirk Stichling and Petra Nawratil for their support in setting up the project. We also whish to thank: Christian L¨ uck, Johannnes Dyck, Matthias Richly, Nico Rehwaldt, Thomas Beyhl, Thomas Schulz and Robert Gurol.

References 1. Burmester, S., Giese, H., M¨ unch, E., Oberschelp, O., Klein, F., Scheideler, P.: Tool Support for the Design of Self-Optimizing Mechatronic Multi-Agent Systems. Intl. Journal on Software Tools for Technology Transfer 10(3), 207–222 (2008) 2. Becker, B., Giese, H., Neumann, S., Treﬀer, A., Schenck, M.: Model-Based Extension of AUTOSAR for Architectural Online Reconﬁguration. In: Proc. of the 2nd International Workshop on Model Based Architecting and Construction of Embedded Systems (ACES-MB 2009), pp. 105–112 (2009)

Model-Based Extension of AUTOSAR

97

3. Giese, H., Burmester, S., Sch¨ afer, W., Oberschelp, O.: Modular design and veriﬁcation of component-based mechatronic systems with online-reconﬁguration. In: Proc. SIGSOFT 2004/FSE-12, pp. 179–188. ACM Press, New York (2004) 4. Feng, L., Chen, D., T¨ orngren, M.: Self conﬁguration of dependent tasks for dynamically reconﬁgurable automotive embedded systems. In: Proc. of 47th IEEE Conference on Decision and Control, pp. 3737–3742 (2008) 5. Anthony, R., Ekeling, C.: Policy-driven self-management for an automotive middleware. In: HotAC II: Hot Topics in Autonomic Computing on Hot Topics in Autonomic Computing, Berkeley, CA, USA. USENIX Association (2007) 6. DySCAS Project: Guidelines and Examples on Algorithm and Policy Design in the DySCAS Middleware System, Deliverable D2.3 Part III. (February 2009), http://www.dyscas.org/doc/DySCAS_D2.3_part_III.pdf 7. Pohl, K., B¨ ockl, G., van der Linden, F.: Software Product Line Engineering. In: Foundations, Principles, and Techniques. Springer, Heidelberg (2005) 8. Hallsteinsen, S., Hinchey, M., Park, S., Schmid, K.: Dynamic Software Product Lines. Computer 41(4), 93–95 (2008) 9. Feiler, P.H., Gluch, D.P., Hudak, J.J.: The Architecture Analysis & Design Language (AADL): An Introduction. Techreport no. CMU/SEI-2006-TN-011 - Software Engineering Institute, Carnegie Mellon University (2006) 10. Kim, M., Jeong, J., Park, S.: From product lines to self-managed systems: an architecture-based runtime reconﬁguration framework. In: Proc. of Workshop on Design and Evolution of Autonomic Application Software, pp. 1–7. ACM, New York (2005) 11. Kim, D., Park, S., Jin, Y., Chang, H., Park, Y.S., Ko, I.Y., Lee, K., Lee, J., Park, Y.C., Lee, S.: SHAGE: a Framework for Self-managed Robot Software. In: Proc. SEAMS 2006, Shanghai, China, pp. 79–85. ACM, New York (2006) 12. Trapp, M., Adler, R., F¨ orster, M., Junger, J.: Runtime adaptation in safety-critical automotive systems. In: SE 2007: Proc. of the 25th conference on IASTED (2007) 13. Georgas, J.C., Taylor, R.N.: Policy-based Self-adaptive Architectures: A Feasibility Study in the Robotics Domain. In: Proc. SEAMS 2008, pp. 105–112. ACM, New York (2008) 14. Talpin, J.P., Brunette, C., Gautier, T., Gamati´e, A.: Polychronous Mode Automata. In: EMSOFT 2006: Proc. of the 6th ACM & IEEE International Conference on Embedded software, pp. 83–92. ACM, New York (2006) 15. AUTOSAR GbR: List of Basic Software Modules. Version 1.3.0 16. AUTOSAR GbR: Speciﬁcation of RTE. Version 2.1.0 17. AUTOSAR GbR: Speciﬁcation of the Virtual Functional Bus, Version 1.0.2 (2008) 18. AUTOSAR GbR: Speciﬁcation of Operating System, Version 3.1.1 (2009)

Report of the 14th International Workshop on Aspect-Oriented Modeling Jörg Kienzle1 , Jeﬀ Gray2 , Dominik Stein3 , Thomas Cottenier4 , Walter Cazzola5, and Omar Aldawud6 1

McGill University, Montreal, Canada University of Alabama, Tuscaloosa, USA 3 University of Duisburg-Essen, Essen, Germany 4 UniqueSoft, Palatine, USA 5 University of Milan, Italy 6 Illinois Institute Of Technology, Chicago, USA [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] 2

Abstract. This report summarizes the outcome of the 14th Workshop on Aspect-Oriented Modeling (AOM), as part of the 12th International Conference on Model Driven Engineering Languages and Systems – MoDELS 2009 – in Denver, Colorado, USA, on the 4th of October 2009. The workshop brought together researchers and practitioners from two communities: aspect-oriented software development (AOSD) and software model engineering. This paper gives an overview of the accepted submissions, and summarizes the results of the discussion.

1

Introduction

This paper summarizes the outcome of the 14th edition of the successful AspectOriented Modeling Workshop series. An overview of what happened at previous editions of the workshop can be found at http://dawis2.icb.uni-due.de/aom/. The workshop took place at the Hyatt Tech Center Hotel in Denver, Colorado, USA, on Sunday, October 4th 2009, as part of the 12th International Conference on Model Driven Engineering Languages and Systems – MoDELS 2009. Participation to the workshop was open to anyone attending the conference, and as a result there were approximately 30 participants. A total of 5 position papers were submitted and reviewed by the program committee, all of which were accepted to the workshop. The rest of this report is structured as follows: Section 2 gives an overview of the presentations of the accepted papers that took place in the morning sessions. Section 3 summarizes the presentations on the crisis management system case study of the ﬁrst afternoon session. Section 4 gives an overview of the questions and comments that were voiced in the second afternoon session. Section 5 concludes the report. S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 98–103, 2010. c Springer-Verlag Berlin Heidelberg 2010

Report of the 14th International Workshop on Aspect-Oriented Modeling

2

99

Overview of Presentations

Gefei Zhang from the Ludwig-Maximilians-Universität München in Germany presented the paper “HiLA: High-Level Aspects for UML State Machines”. State machines are popular, simple and intuitive for modeling the behavior of reactive systems. However, Gefei pointed out that state machines face important modularity problems when used to model behavior at a high level of abstraction. To address this problem, he proposed HiLA. The language provides three diﬀerent kind of aspect models that allow a modeler to separate behavior pertaining to a diﬀerent concern: synchronization aspects, history-based aspects, and low-level transformation aspects. To illustrate the approach, Gefei presented a simple state machine describing the behavior of a guard in a game environment that is composed of 3 rooms. He then showed how to extend the model to add more detailed behavior to the guard (e.g., to prevent the guard from moving from one room to the other in certain conditions, or to inhibit the guard from ﬁghting in a speciﬁc room). This additional behavior was modeled in separate HiLA aspect models, and did not require the base model to be modiﬁed. HiLA also provides features that allow aspects to model behavior that is triggered by speciﬁc state transition sequences in the base, support for interference detection, and are model-checkable. Wisam Al Abed from McGill University in Montreal, Canada, presented how the Reusable Aspect Models approach, previously published in [1,2] can be extended to support information hiding principles. In object-orientation, the class construct allows a modeler to encapsulates state and behavior. An interface allows a modeler to expose some of the encapsulated state and behavior to the outside world; everything else remains hidden within the class. Wisam argued that aspect-orientation adds a new dimension to encapsulation, allowing a modeler to group model elements related to the structure and/or behavior of a given concern together, even if the concern’s state and behavior crosscuts the class boundaries. As a result, information hiding becomes tricky. Wisam proposed that in addition to a public interface that exposes the state and behavior that the aspect is designed to provide to the outside world, model elements within an aspect need to deﬁne an intra-aspect interface that exposes state and behavior to the model elements within the same aspect. In addition, in order to support aspect hierarchies, an aspect weaver should automatically remove the public interface of an aspect during the weaving process by moving the operations from the public interface to the intra-aspect interface. As a result, aspects give the developer the power to hide design decisions eﬀectively, even those that require the interaction of instances of multiple classes. Jorge Barreiros from the Instituto Politécnico de Coimbra in Portugal presented “Integrating AORA to the Problem Frames Approach”. He highlighted the fact that problem frames do not systematically address the problem of separation of crosscutting concerns. He explained how it is possible to integrate the meta-model of the Problem Frames (PF) approach with the meta-model of the Aspect-Oriented Requirements Analysis (AORA) approach with the aim of making PF analysis models more modular. As a result, an AORA concern can

100

J. Kienzle et al.

detail the requirements which must be fulﬁlled by a PF machine’s for a speciﬁc problem. AORA responsibilities can then be mapped to interface speciﬁcations of problem frame machines. He suggested the following process: 1) design the context diagram to structure and delimit the problem (PF); 2) Identify the main concerns following AORA; 3) Generate AORA templates for each concern; 4) Design a problem diagram for each functional concern (PF); 5) Identify match points and crosscutting concerns; 6) Specify composition rules using AORA. Jorge illustrated the approach with the car parc case study. Valter Camargo from the Federal University of Sao Carlos in Brazil presented his paper entitled “A Preliminary Comparative Study Using UML-AOF – a UML Proﬁle for Aspect-Oriented Frameworks”. UML-AOF, which was proposed in a previous AOM workshop [3], is a UML proﬁle that provides stereotypes that allow a modeler to better document the instantiation of an aspect-oriented framework within a target model, as well as provide the developers of an aspectoriented framework features that facilitate the maintenance activity. Valter ﬁrst presented a review of the UML-AOF stereotypes, and then continued on to describe an empirical study that was conducted in a university setting to compare ML-AOF with Evermann’s proﬁle [4], which is a UML proﬁle that was developed to describe aspect-oriented designs of programs implemented with AspectJ. In the empirical study, 8 graduate students divided into two groups were asked to look at code of two case study systems, a hotel reservation system and workshop management system. Two crosscutting concerns, persistence and security, were implemented in both systems using an aspect-oriented framework. The students were given a questionnaire, in which they had to answer questions about 1) the idioms and patterns used to link the AOF with the base application; 2) extension points of the AOF; 3) questions that asked them to determine if a certain class or interface belonged to the base application or the AOF; 4) aspect-oriented programming language speciﬁc questions. The last presentation entitled “Reusable Model Slices” was also given by Jorge Barreiros from the Instituto Politécnico de Coimbra in Portugal. Reusable model slices provide features that allow the modeler to express method signature manipulations that are to occur when a reusable model slice is woven into a base model. The presented approach also allows one aspect model to specialize another aspect model. Two kinds of specialization are supported: incremental and partial. Incremental specialization adds new template parameters to a model, while partial specialization ﬁxes one of the template parameters. When specifying element creation within an aspect, the approach oﬀers scoping features to specify if the created model element is to be universal to the target model (i.e. a single instance of the element is created), global (i.e. one instance of the element is created for each package), or local (i.e. one instance is created for each parameter binding).

3

Crisis Management System Case Study Session

The afternoon session from 2:00 - 3:30 was devoted to a discussion on the crisis management system (CMS) case study. The CMS case study was proposed in [5]

Report of the 14th International Workshop on Aspect-Oriented Modeling

101

as a common case study for the aspect-oriented modeling research community. A crisis management systems is a system that helps in identifying, assessing, and handling a crisis situation by orchestrating the communication between all parties involved in handling the crisis, by allocating and managing resources, and by providing access to relevant crisis-related information to authorized users. The case study description contains informal requirements of crisis management systems in general, a feature model for a CMS product line, use case models for a car crash CMS (CCCMS), a domain model for the CCCMS, an informal physical architecture description of the CCCMS, as well as some design models of a possible object-oriented implementation of parts of the CCCMS backend. AOM researchers that want to demonstrate the power of their AOM approach or technique can hence apply their approach to whatever part of the case study is the most appropriate to illustrate their ideas. An open call of the journal Transactions on Aspect-Oriented Software Development published by Springer Verlag sollicitating submissions presenting aspectoriented models of the CMS for a special issue of the journal was released in May 2009. Jörg Kienzle, the guest editor of this special issue and co-organizer of this workshop, received 11 paper submissions responding to the call in September 2009. Authors of 6 of the papers were actually attending the AOM workshop in Denver, and agreed to give a short presentation describing how their AOM approach was applied to the CMS. Gunter Mussbacher from the University of Ottawa, Canada, showed aspectoriented requirements models of the CMS expressed using the aspect-oriented user requirement notation (AoURN), which consists of aspect-oriented use case maps and the aspect-oriented goal-oriented requirements language. He identiﬁed aspects such as coordination, strategy recommendation, resource management and communication. Gefei Zhang from the Ludwig-Maximilians-Universität München in Germany presented how he modeled parts of the CMS using HiLA, the aspect-oriented modeling approach he had presented in the morning. In particular, he presented models of the login aspect, and explained how modelchecking can be applied to HiLA moels to verify desired system properties. Frans Sarnen from the Katholieke Universiteit Leuven, Belgium, pointed out the pointcut fragility problem, and subsequently described a software development process that leads a developer to identify crosscutting concerns at the requirements level within use cases. Then, stable domain abstractions are discovered, which can be used within architectural design, and as basic building blocks for constructing pointcut interfaces that are unlikely to change when the software evolves. Sebastien Mosser from the university of Nice, France, presented how ADORE, an aspect-oriented technique for composition of orchestrations for executable business processes, was used to design the workﬂows of the crisis management system. He presented a process in which a design model of service orchestrations is extracted from the use cases of the requirements document. Florian Heidenreich from Dresden University in Germany showed a comparison of two diﬀerent approaches, FeatureMapper and VML*, that allow a developer to map feature models to other models of a product

102

J. Kienzle et al.

line. To properly illustrate the product line development and to highlight the advantages and disadvantages of both approaches, he introduced an additional speciﬁc crisis management system product: a ﬂood crisis management system. Jörg Kienzle from McGill University in Canada showed how the Reusable Aspect Models (RAM) approach was applied to the design of the car crash crisis management system. He explained how the design of the CreateMission functionality was decomposed into a hierarchy of 23 interdependent aspect models.

4

Summary of the Discussion Groups

The second afternoon session provided an opportunity for open discussion among the participants. Those who wanted to voice a position or ask a question ﬁrst expressed their comments to the whole group. The set of questions and positions were collected and approximated clusters of topics were formed. The group as a whole then considered each cluster and discussed each topic. A summary of the list of topics and pertinent points stemming from the discussion follows. Verification of aspect correctness: A common theme among the concerns expressed by attendees related to the important issue of syntactic and semantic veriﬁcation of the composition of multiple aspects. The topic of aspect composition and the associated correctness is not a new concern, but attendees discussed how many of the proposed AOM approaches could be tested (e.g., case studies, metrics). Several attendees wanted to know about the potential for metrics that might help guide the reuse of aspects. A speciﬁc domain of interest that was brought up in the discussion was the interest in security aspects and the desire to have some conﬁdence in the correctness of their composition with a base application. AOM for managing complexity: The increased demands of software capabilities raised concerns over the management of aspect complexity, as well as base system complexity. AOM promises reduced complexity by more advanced separation of concerns. However, managing large sets of aspects, aspect dependencies and interactions, and correct weaving of complex models can be a challenge. Attendees questioned whether we have mature enough approaches and tools to leverage reduced complexity using AOM approaches. A discussion of aspect hierarchies then ensued with comments on how to compose new aspects from higher level aspects, and how to extend and specialize aspects. The reuse of aspects led to some comments about the desired level of granularity of the aspect and how to extract composition rules to help with variations in granularity. The evolution of aspects was also a focus of many workshop participants within the context of complexity concerns. The complexity of AOM and aspects in general were discussed in the context of aspect evolution (e.g., base model changes, aspect changes, sub-aspect changes amid those aspects that were composed from other higher level aspects). Application niche areas: A category of niche areas for AOM application was discussed. AOM@Runtime was a popular concept for dialogue among the

Report of the 14th International Workshop on Aspect-Oriented Modeling

103

participants. Many attendees wanted to know how to use AOM techniques for implementing dynamic variability. Within this context, there were several concerns about the performance of AOM weavers and the need for eﬃciency in the model weaving. Given the strong focus on UML in the AOM area, there were questions about the use of aspects in the growing area of domain-speciﬁc modeling languages. The overall state of maturity amid AOM tools was mentioned; the lack of downloadable tools amid a plethora of “paper-based” concept ideas highlighted the need for more implementation focus for AOM.

5

Concluding Remarks

The organizers for this edition of the workshop were Omar Aldawud, Walter Cazzola, Thomas Cottenier, Jeﬀ Gray, Jörg Kienzle, and Dominik Stein. An expert program committee provided assistance in reviewing the submitted papers. The members of the program committee were Mehmet Aksit, Aswin Van den Berg, Frank Fleurey, Sudipto Ghosh, Stefan Hanenberg, Phillipe Lahire, Funter Mussbacher, Alfonso Pierantonio, Ella Roubtsova, Pablo Sánchez, Beﬁr Tekinerdogan, Julie Vachon, Markus Völter, Jon Whittle, and Steﬀen Zschaler. Last but not least, we’d like to thank all submitters and participants of the workshop who contributed with their papers and positions.

References 1. Klein, J., Kienzle, J.: Reusable Aspect Models. In: 11th Aspect-Oriented Modeling Workshop, Nashville, TN, USA, September 30 (2007) 2. Kienzle, J., Abed, W.A., Klein, J.: Aspect-Oriented Multi-View Modeling. In: Proceedings of the 8th International Conference on Aspect-Oriented Software Development - AOSD 2009, March 1-6, pp. 87–98. ACM Press, New York (2009) 3. Júnior, J.U., Camargo, V.V., Chavez, C.V.F.: UML-AOF: a profile for modeling aspect-oriented frameworks. In: AOM 2009: Proceedings of the 13th workshop on Aspect-Oriented Modeling, pp. 1–6. ACM, New York (2009) 4. Evermann, J.: A meta-level specification and profile for aspectj in UML. In: AOM 2007: Proceedings of the 10th international workshop on Aspect-oriented Modeling, pp. 21–27. ACM, New York (2007) 5. Kienzle, J., Guelfi, N., Mustafiz, S.: Crisis Management Systems – A Case Study for Aspect-Oriented Modeling. Technical Report SOCS-TR-2009.3, McGill University, Montreal, Canada (2009)

HiLA: High-Level Aspects for UML State Machines Gefei Zhang and Matthias H¨olzl Ludwig-Maximilians-Universit¨at M¨unchen {gefei.zhang,matthias.hoelzl}@pst.ifi.lmu.de

Abstract. UML state machines are widely used for modeling software behavior. However, state-crosscutting behaviors, such as execution history dependence or synchronization (either within a single state machine or between different concurrently active state machines) are hard to model as their realizations are dispersed throughout the state machine or even several state machines. We present High-Level Aspects (HiLA) for UML state machines to address this problem. The HiLA language facilitates modeling cross-cutting behaviors in one single place and separately from the base machines, and thus improves the modularity of the software design. It provides facilities for specifying multiple history-dependent and concurrent aspects that extend the behavior of base machines in a straightforward, mostly declarative style; it therefore allows the designer to build models at a high level of abstraction. Furthermore, HiLA provides aspects that constrain or modify the interactions between multiple independent state machines.

1 Introduction UML state machines are a popular language for modeling software behavior, for example for reactive systems [7]. In many cases, the behavior of classes or interactions is described by individual state machines, with the overall behavior of the system resulting from their parallel or sequential execution. However, state machines are a low-level modeling construct with poor modularity: even many simple features, such as synchronization of parallel regions and behaviors based on the execution history, cannot be modeled in a localized way. Instead implementation details are scattered over large parts of the state machine, resulting in a model that is hard to read, hard to maintain and prone to errors. This problem has been addressed by several aspect-oriented approaches, see Sect. 4. Most approaches (see [3,11]) view aspects as model transformations and allow the modeler to define, in separate aspects, transformations of the base machine by introducing new model elements or removing existing ones. However, model transformations are themselves low-level instruments. While some features lend themselves to a concise description as graph transformations, other aspects for seemingly simple features require complex transformations, since the modeler has to specify in detail how to achieve a task instead of simply defining what to do. For example, one possible way to implement an aspect modeling mutual exclusion of states in orthogonal regions is to introduce a global variable as semaphore, select all involved

This work has been partially sponsored by the DFG project M AEWA EU project S ENSORIA (IST-2 005-016004).

S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 104–118, 2010. c Springer-Verlag Berlin Heidelberg 2010

II

(WI 841/7–2) and the

HiLA: High-Level Aspects for UML State Machines

105

states, extend their entry actions by decreasing the value of the semaphore, extend their exit actions by increasing it, and then select all transitions entering these states and extend their guards to block a transition if necessary. Other implementation strategies for this basic feature are similarly complicated, e.g. guarding transitions with inState predicates is simpler for achieving mutual exclusion between two states, but this strategy leads to complex Boolean combinations of inState expressions once mutual exclusion between more than two states is to be achieved. Understanding these aspects amounts to understanding the result of the weaving process. Moreover, handling interference between aspects is still insufficiently supported. It has been proposed (see [11]) to formulate aspects as graph transformations and to perform syntactical conflict detection by confluence checking of the graph grammar. However, syntactical conflicts are not expressive enough for many real-world applications: two aspects that modify the same model elements do not necessarily interfere from a semantic point of view. To give a simple example, if one aspect logs firing of transitions, and another aspect counts how often each transition was taken, these aspects are syntactically in conflict, even though applying them both poses no semantical problems. Mechanisms for resolving syntactical conflicts have been proposed, e.g., by layering aspects (see [3]), but these methods rely on manual resolution by the modeler. Except for very simple examples or some specialized embedded systems the behavior of a system is rarely specified by a single state machine; rather it consists of interactions between state machines describing the behavior of individual objects. This structure is a natural outcome of many object-oriented analysis and modeling approaches, and it is necessary for systems that allocate a potentially unbounded number of objects or threads. State machines, and most aspect systems for state machines, provide only limited support for managing the interactions between multiple state machines, although this is one major difficulty in building real-world systems. We present High-Level Aspects (HiLA) for UML state machines. The current paper is an extended version of [24] and introduces for the first time the language features of HiLA for handling interactions between different state machines. HiLA allows the mostly declarative specification of concerns such as history-based behaviors or synchronization of either orthogonal regions or concurrently executing state machines. We minimize aspect interference by weaving them into orthogonal regions and give a conservative criterion for determining semantical interference of aspects. The semantics of aspects in HiLA is defined independently of any concrete base machine; the connection between aspects and base machine is provided by a separate binding. The rest of the paper is organized as follows: in the following Sect. 2 we give an overview of the syntax and informal semantics of UML state machines, and show some of their modularity problems. In Sect. 3 we present our aspect language, HiLA. Related work is discussed in Sect. 4. Finally, we conclude and outline some future work.

2 UML State Machines UML state machines provide a behavioral view of software systems. In the following we use sentinels in a computer game as a running example. In the game the computer

106

G. Zhang and M. H¨olzl Running Room1 finished / defer entry / cp++ exit / cp−− finished [(inState(Patrolling) || inState(Fighting)) && ms(2) >= ms(3)]

finished [(inState(Patrolling) || inState(Fighting)) && ms(3) >= ms(2)]

Room2 finished / defer entry / cr = 2

finished [inState(Patrolling) || inState(Fighting)]

finished [(inState(Patrolling) || inState(Fighting)) && !inState(Fighting) && cp < maxP]

Room3 finished / defer entry / cr = 3

Init Idle do / while (p < 100) p++;

go

Patrolling attack / defer

attack [!inState(Room1)]

Fighting entry / oldp = p;

[p <= 0]

Dying

[p > 0] / if (p > oldp) cs(cr)++; if (ms(cr) < cs(cr)) ms(cr)=cs(cr); if (p < oldp) cs(cr)=0;

Fig. 1. UML state machine can get rather complex even when modeling simple features

controls several sentinels that guard three connected rooms; sentinels can die if they are defeated in combat and the user may train new sentinels. Therefore a variable, potentially unlimited number of sentinels may appear in the game. Their aggregate behavior cannot be described by a single state machine, instead the sentinels are represented by instances of a class Sentinel and the behavior of each sentinel is described by the state machine shown in Fig. 1. The sentinel may be idle, patrolling through the three rooms, fighting, or, if its power (p) is not greater than 0, dying. Power is changed by fights (this is not explicitly modeled in the state machine), where an increase of p indicates a win and a decrease of p indicates a defeat. The sentinel can also gain power when it is Idle. 2.1 Syntax and Semantics We briefly review the syntax and semantics of UML state machines according to the UML specification [17] by means of Fig. 1. A UML state machine consists of regions which contain vertices and transitions between vertices. A vertex is either a state, which may hierarchically contain other regions; or a pseudo state used for building compound transitions. Transitions are triggered by events and describe, by leaving and entering states, the possible state changes of the state machine. The events are drawn from an event pool associated with the state machine. A state is simple, if it contains no regions (such as Init, Idle, etc. in Fig. 1); it is composite, if it contains at least one region; a composite state is said to be orthogonal if it contains several regions, visually separated by dashed lines (Running). A state may show an entry behavior (like in Fighting) and an exit behavior (not shown in Fig. 1), which are executed on activating and deactivating the state, respectively; a state may also show a do activity (Idle) which is executed while the state machine sojourns in this state. Transitions are triggered by events (finished, go, etc.), may show guards (p > 0, etc.), and specify actions to be executed when a transition is fired (if (p > oldp) cs(cr)++;). Completion transitions (such as the ones leaving Fighting) are

HiLA: High-Level Aspects for UML State Machines

107

triggered by an implicit completion event emitted when a state completes all its internal activities. Events may be deferred (like in Patrolling, Room1), that is, put back into the event pool, if they are not handled by an enabled transition. We write the deferring of completion events as * / defer. By executing a transition, its source state is left and its target state entered. An initial pseudo state, depicted as a filled circle, represents the starting point for the execution of a region. A final state, depicted as a circle with a filled circle inside, represents the completion of its containing region. For simplicity, we omit the other pseudo state kinds (fork, join, entry and exit points, shallow and deep history, junction, and choice). During runtime, a state gets active when entered and inactive when exited as a result of a transition. The set of currently active states is called the active state configuration. When a state is active, so is its containing state. The active state configuration is thus a set of trees starting from the states in the top-level regions down to the innermost active substates. The execution of a state machine consists in changing its active state configuration in dependence of the current active states and a current event dispatched from the event pool. We call the change from one state configuration to another an execution step: A maximally consistent enabled compound transition is chosen; the main source state of this transition is deactivated, the transition’s actions are executed, and its target states are activated. To simplify the state machines presented in this paper we assume that transitions where both the guard and the effect access global state are executed atomically, i.e., while checking the guard and executing the effect no other part of the system accesses the same global state. A simple implementation of this restriction consists in the runtime system performing a P operation on a global semaphore with unit value whenever an event that might trigger one of the relevant transitions is dispatched, and by performing a V operation when the effect of the chosen transition has completed. This implementation restricts the parallelism of state machines more than necessary, so more fine-grained locking strategies might be used in practice. Note that we include this restriction mostly to simplify the presentation of non-aspect-oriented state machines: the non-aspect-oriented state machines presented in this paper can be modified to ensure correct behavior without additional restrictions on the execution model; the weaving process of HiLA can be changed to output these more complex state machines without changes to the HiLA model.

2.2 Modularity Problems of State Machines Separation of Concerns in UML state machines is not an easy task. Ideally, information is “localized”, i.e., all information needed to determine whether a transition is enabled is defined in the transition itself or in its source state, the behavior of a single region is defined in this region, and a state or a region does not interfere with the behavior defined in other states or regions. In practice, however, many features cannot be modeled in this way. Instead, they require interactions between several states and transitions, which may be located all over the state machine. Meanwhile, different features often interact with each other, hence a single model element (a state or a transition) is often involved in several features

108

G. Zhang and M. H¨olzl

of the system. For example, consider how the following simple features are modeled in Fig. 1: 1. The sentinel is allowed to change its room only while it is Patrolling or Fighting. Obviously, every transition in the upper region must be guarded by the OCL-constraint inState(Patrolling) inState(Fighting) (in guards consisting of several propositions, this is the first proposition; the other ones are used for other features of the sentinel). While in a region containing only four transitions the effort may seem acceptable, it is cumbersome to modify all the transitions in a more complex state machine. Moreover, the meaning of the state machine can only be understood by carefully analyzing interactions between guards and state transitions in different regions. 2. Additionally, the sentinel is required not to fight in Room1. To model this mutual exclusion, the guard of the transition from Room3 to Room1 is extended by a proposition !inState(Fighting), the guard of the transition entering Fighting by !inState(Room1). Moreover, the attack event has to be deferred in state Patrolling, since otherwise this event would be removed from the event pool when the sentinel is in Room1, and the sentinel would “forget” to attack even after leaving Room1. 3. When leaving Room1, the sentinel is required to enter the room with the longest winning sequence so far.1 To express this history-dependent feature, we need to introduce quite a few model elements: a map cs stores the length of the current winning sequence of Room2 and Room3; another map ms is introduced to store the length of the maximal winning sequence; a variable cr is used to store the current room and is set by the entry actions of Room2 and Room3; state Fighting needs a variable oldp to store the value of the sentinel’s power at the start of the fight (entry). We also need to extend the effect of the transition from Fighting to Idle to increase the value of cs(cr) if the fight was won (p > oldp), to update ms(cr) if necessary, and to reset cs(cr) to zero as soon as a fight was lost (p < oldp). Additionally, we need to extend the guards of the transitions from Room1 to Room2 and Room3 by a constraint to ensure that the maximal winning sequence of the target room is actually longer than that of the other room. 4. At most maxP sentinels may reside in Room1 at the same time; in other words, the state machines of at most maxP instances of Sentinel may simultaneously be in state Room1. This is modeled by adding a variable cp to the global environment (not shown in Fig. 1), by extending the guard on the transition leading from Room3 to Room1 (which is the only transition entering Room1) with cp < maxP, and by adding the entry action cp++ and the exit action cp–– to state Room1. The above examples exhibit three inherent weaknesses of UML state machines: 1) individual features can not be modeled separately, but are entangled with each other, 2) the level of abstraction at which features are modeled is too low, and 3) features which concern the interaction between different state machines are modeled by showing their local effect on a single state machine only. 1

This behavior is overly simplified since the sentinel will always choose the room in which it won the first fight. We have refrained from modeling more realistic strategies, e.g., adjusting the probability in which a room is entered according to the longest winning sequence, since they would not offer additional insights into HiLA.

HiLA: High-Level Aspects for UML State Machines Par1 Par2

«aspect» Name «pointcut»

selector State*

109

selector : Class

ST*

State* [Mult] {Constraint} «advice»

AdvBody

Label 1 Label 2 Label 3

(a) Class aspects

Par1 «history» Par2 Name «history» hs1 = op1 Pattern1 hs2 = op2 Pattern2

(b) History properties

Fig. 2. Concrete syntax of HiLA aspects

3 HiLA The language High-Level Aspects (HiLA), an aspect-oriented extension of UML state machines, is defined to address these weaknesses. Previous publications on HiLA are [24,25]. An aspect is a graphical specification of an additional or alternative behavior of a UML state machine (called the base machine), to be executed at certain “interesting” points of time in the base machine’s execution. These points of time are when a transition is being fired with the state machine in certain configurations (of states and/or environment), or if firing the transition would lead to certain state configurations. The transitions are specified by the pointcut of the aspect, the behavior to execute by its advice. We say the aspect advises the transitions selected by the pointcut. The concrete syntax of high-level aspects is shown in Fig. 2a, the identifiers in oblique type being place holders. State* is a set of states. The selector may be either before or after. For the first alternative shown in Fig. 2a, a pointcut labeled with after selects all transitions leaving any state in State* while the state machine is in a state configuration containing all states in State*. Similarly, a pointcut labeled with before selects each transition T entering any state contained in State*, but only in active state configurations where after taking T all states in State* will become active. For the second alternative, the selector is empty and a set of states and transitions ST* is specified. In this case the pointcut matches all transitions in ST* in active state configurations in which all states in ST* are active. The pointcut may contain a constraint. In this case, the advice is only executed when the constraint is satisfied. The third case shown in Fig. 2a takes into account the active state configurations of all state machines belonging to one of the specified Class es; Mult, selector and State are functions of Class. If Mult is not specified, then Mult := ∗. If the selector is before, the pointcut selects a transition in the currently active state machine if that transition would cause Mult instances of each specified Class to be in active state configuration State* with satisfied Constraint. If a single Class is specified without additional constraint, there are three possibilities when the advice applies: 1. between min(Mult) − 1 and max(Mult) − 1 instances of Class are already in a state configuration matching State* and the currently selected compound transition would cause the currently active instance to enter an active state configuration matching State* as well,

110

G. Zhang and M. H¨olzl

2. between min(Mult) and max(Mult) instances of Class are already in a state configuration matching State* and the currently selected compound transition does not change whether the state configuration of the current instance matches State*, and 3. between min(Mult) + 1 and max(Mult) + 1 instances of Class are already in a state configuration matching State* and the currently selected compound transition would cause the currently active instance to no longer match active state configuration State*. The cases for multiple classes, selector after and non-void constraints are similar. The advice of an aspect is also a state machine, where the final states may be labeled. When a transition advised by an aspect is taken, the advice of that aspect is executed; when the advice state machine finishes, execution of the base machine is resumed with a transition from the advice to the target state of the advised transition. The labels specify additional constraints on this transition: if the final state is labeled 1 this transition is enabled only if after its execution the active state configuration matches the pointcut of the aspect; if the final state is labeled 0 the transition is enabled only if after its execution the active state configuration does not match the pointcut. In both cases the completion event is deferred. In Fig. 2 three resumption strategies are defined. Depending on the execution of AdvBody, one of them will be used at run time. To increase reusability, aspects are usually defined as UML templates with parameters, which are then bound by the designer of concrete aspects. Fig. 2a shows two parameters: Par1 and Par2. In HiLA, properties of the execution history are specified by history properties. The basic idea behind history properties is that they provide a declarative way to specify the value of a variable that depends on the execution history of the state machine; other aspects can then use that value in their pointcut or advice to enable history-sensitive behavior. History properties are defined in history aspects, which are identified by the label history, as shown in Fig. 2b. A history property contains a name, followed by an operator and a pattern consisting of active state configurations and guards. The pattern matches contiguous subsequences of the execution history. The value of the history property is the result of applying the function defined by the operator to the subsequences selected by the pattern. In particular, operator # (“number of”) returns the number of matches of the pattern by the base machine’s execution history where the guards evaluate to true. Another operator, maxLength, returns the maximal length of all matched subsequences. In addition, HiLA also allows the use of low-level aspects, i.e., transformational aspects. In HiLA, a low-level aspect contains a transformation pointcut and a transformation advice. The transformation pointcut contains a pattern that can match a sub-structure of the base machine. The meaning of the aspect is that the parts of the base machine that match the pattern should be replaced by the advice. 3.1 HiLA Aspects for Single State Machines In the following, we use the previously described sentinel as to explain the syntax and informal semantics of HiLA in more detail. For a formal semantics, see [10]. Fig. 3 shows the base machine for an aspect-oriented model of the sentinel. Note that this state machine is “unfinished”: it only models the very basic behavior of the sentinel, leaving

HiLA: High-Level Aspects for UML State Machines

111

Running Room1 finished Room2

finished

finished

finished Room3

Init Idle

go

Patrolling

attack

Fighting

[p <= 0]

Dying

[p > 0]

Fig. 3. Sentinel: base machine

out many important details (like event deferring); on the other hand it describes these fundamentals much more concisely than Fig. 1 where the basic behavior is intertwined with several extensions. Using HiLA we can model additional behaviors as individual aspects; in many cases this can even be done for properties that are specified by a multitude of elements (vertices and transitions) spread throughout the state machine. This way, the modeling of each behavior is kept in a single, dedicated place, without entangling different properties in the same base machine elements. The overall effect is that a simple and comprehensible base machine can be refined and extended with additional behaviors, where each behavior can be developed and understood (mostly) independently from the concrete base machine to which it is applied. To make full use of this approach it is necessary to apply multiple aspects simultaneously to a single state machine, to detect errors arising from interactions between aspects, and to provide the modeler with possibilities to address these errors. We will address this topic in the next section and concentrate on individual aspects for the remainder of this section. Aspect MutexTrans in Fig. 4 is a simple yet powerful soluA: State tion for modeling the first feature described in Sect. 2.2, not B: State «aspect» C: State MutexTrans changing rooms while in state Idle. MutexTrans is a general so«pointcut» lution that can be instantiated with any transition and any state A B to prevent execution of the transition while the state is active. The aspect has three formal parameters: A and B specify the C transition, C the state. All parameters are used in the pointcut which selects the tran- «advice» 0 sitions between A and B while the lower region is in state C. The advice disallows the selected transition (while in state C) Fig. 4. Aspect for muby transitioning to a final state labeled 0. A label 0 on a final tual exclusion between state blocks the transition selected by the pointcut and defers transition and state the event until the pointcut no longer matches. It is very simple to exclude certain transitions from modification by the aspect: according to the informal specification of the example the aspect should not block selftransitions from a room to itself. To achieve this, we bind A and B with all pairs of different rooms (i.e., all combinations of states in the upper region of the base machine with A = B) and C with Idle; this binding of the aspect tells the sentinel to block any transition between different rooms while it is in state Idle, i.e., room change is only enabled when the sentinel if Patrolling or Fighting.

112

G. Zhang and M. H¨olzl

To model the second feature in Sect. 2.2, that the sentinel does not fight in Room1, we need a slight variation of the MutexTrans aspect. Instead of excluding a specific transition while a particular state is active in an orthogonal region we want mutual exclusion between two states in orthogonal regions. Again we define a more general aspect that can describe mutual exclusion between any two states in orthogonal regions, see Fig. 5. The pointcut of this aspect matches all transitions that would lead to states A and B becoming active at the same time, i.e., all transitions into state A when state B is active, all transitions into B when state A is active, and all compound transition causing A and B to become active simultaneously. The advice is again a simple transition into a final state labeled A: State «aspect» B: State MutexState 0, which inhibits the selected transition. By instantiating A with Room1 and B with Fighting we achieve the desired behavior: the «pointcut» «before» sentinel may not start a fight (transition into state Fighting) while it A is in Room1 and it may not enter Room1 while engaged in a fight. B In the last aspect we address the third requirement, always going to the room with the longest winning sequence. This feature «advice» 0 obviously depends on the execution history of the state machine; we use a history property to model it. In this case, the history prop- Fig. 5. Aspect for erty tracks, for each state, the longest subsequence of fights that mutual exclusion the guard won and that was not interrupted by a lost fight. While between two states the high-level aspects could approximate this behavior, it is, in this case, more elegant to modify the guards of the base state machine with low-level aspects. The history aspect MaxLength in Fig. 6a takes two parameters (N, the name of a history property, and C, a constraint). It defines N as a function from states to natural numbers which returns for each state S the maximal length of the subsequence in the trace, that contains (1) at least one occurrence of state S where C was valid and (2) no occurrence of S where C was invalid. The pointcut of the template IntroduceGuard (Fig. 6b) selects all transitions from S to T and stores the trigger, guard and action of the selected transition in internal variables ?E, ?G and ?A, respectively. Its advice expands the guard by conjoining another constraint C to the existing constraints; unguarded transitions are treated as guarded by [true]. With these aspect templates, the feature “choose the room with the longest winning sequence so far” can be modeled by the instantiations shown in Fig. 7. Instantiating N: String «history» C: Constraint MaxLength N(S) = maxLength S {C}

[1..*]

S [0] {not C}

(a) History aspect

«aspect» IntroduceGuard «transformation pointcut» ?E[?G] / ?A S T «transformation advice» ?E[?G && C] / ?A S

S: State T: State C: Constraint

T

(b) Transformation aspect

Fig. 6. Aspects for introducing history-dependent behavior

HiLA: High-Level Aspects for UML State Machines

113

Template

Binding C →p@post > p@pre N →win IntroduceGuard S →Room1 T →r ∈ {Room2, Room3} G →max(win[Succ(Room1)]) == win(r) MaxLength

Fig. 7. Aspect instances modeling the feature that the sentinel always chooses the room with the longest winning sequence

aspect template MaxLength from Fig. 6a by binding N with win and C with the constraint p@post > p@pre yields a history property named win which stores for each state the maximal length of p being increased without being decremented, i.e., the maximial length of the winning sequence. The history property win is then used to introduce new guards: Fig. 7 instantiates template IntroduceGuard twice by binding S with Room1, binding T with Room2 (resp. Room3) and binding C with max(win[Succ(Room1)]) == win(Room2) (resp. max(win[Succ(Room1)]) == win(Room3)). These bindings ensure that each transition from Room1 to either Room2 or Room3 is only enabled when the constraint is satisfied. max(win[Succ(Room1)]) yields the maximul value of win for all successor states of Room1. The transition is thus only enabled when there is no other target room in which the sentinel has lost fewer fights. The state machine in Fig. 1 implements the history property by means of the variable cr which keeps track of the current room and two functions: cs counts the number of wins in the current run, ms tracks the highest number of wins in the execution history. We have simplified the guards from max(ms[{2, 3}]) == win(i) to ms(i) >= ms(j ). Note that, even though the transformation itself is described by a low-level aspect, the lucidity of this aspect depends to a large degree on the history property which is a declarative high-level construct. 3.2 HiLA Aspects for Coordinating Multiple State Machines A: State The fourth feature in Sect. 2.2 (at most maxP sentinels in Room1 C: Class «aspect» M: Integer at the same time) is fundamentally different from the previous MutexObj three features in that it constrains the behavior of a state ma- «pointcut» «before» chine depending on the overall state of the system or, more pre:C cisely, depending on the active state configurations of other state A [M..*] machines. In Fig. 1 this is modeled by introducing a global variable, guards that query this variable, and actions to adjust the «advice» 0 variable’s value. While this solves the problem of coordinating different, concurrently active state machines, it does so in Fig. 8. HiLA aspect for a manner that is difficult to understand and relies on the mod- coordinating multiple eler explicitly maintaining global state. state machines Fig. 8 shows how HiLA aspects can be used to model this requirement more perspicuously: The pointcut specifies a situation in which, after executing the current transition, at least M instances of class C would be in active state

114

G. Zhang and M. H¨olzl

configuration A. In this case the advice prevents the current object from executing the transition and defers the event that triggered the transition. When instantiating M with maxP + 1, C with Sentinel and A with Room1 this aspect prevents more than maxP guards from being in Room1 at the same time. In contrast to the previous solution it does so in a manner that makes it obvious that its purpose is to coordinate the interaction between different objects, and it frees the modeler from manually maintaining the required global state. 3.3 Aspect Templates Before The examples above already hint at one of the powerful feaIf Do tures of HiLA: many aspects can be defined as generally useful «aspect» Goto BeforeIfDoGoto templates and bound multiple times. Some of the most common «pointcut» «before» aspects can be captured by templates adhering to the following 2 Before form: Before a certain state becomes active , If a certain condition holds, Do a specified action and then Goto a specified {If} state. HiLA therefore offers a number of predefined templates «advice» / Do goto Goto adhering to this regular naming scheme, e.g., BeforeIfDoGoto (see Fig. 9), or BeforeIfGoto (if no action is performed), or Fig. 9. HiLA standard BeforeDoGoto (if no guard is required), or BeforeGoto (if nei- template ther guard nor action are required), which makes the templates easy to remember and to use. In practical applications of HiLA we have found that most aspect uses are expressed as instantiations of these predefined templates which means that only tables with bindings, similar to Fig. 7, have to be specified. Since the templates are frequently used and usually well understood by modelers this allows them to rapidly specify and understand commonly occurring patterns.

3.4 Applying Multiple Aspects As mentioned before, for any state-machine aspect language to be useful it is necessary that multiple, independently developed aspects can be applied to a single base machine and that errors arising from the interaction of the aspects can be detected. The possible interactions between aspects have been classified in various ways; here we use a slightly shortened and adapted version of the one presented in [1]: 1. Applying one aspect can change the places where another aspect is applicable. 2. The result of applying two aspects can be dependent on the order in which the aspects are applied. 3. At run-time, one aspect can modify state affecting the behavior of another aspect; 4. At run-time, one aspect can change the control-flow of the system, causing another aspect to never be applied. When discussing these effects in HiLA we have to distinguish between low-level and high-level aspects. Low-level aspects define model transformations on the base state 2

Or After a certain state was active, or (not described in this paper) Whilst a state is active On occurrence of a particular event.

HiLA: High-Level Aspects for UML State Machines

115

machine and, like aspects defined by other approaches based on model-transformation, can change the base state machine in arbitrary ways. Therefore they can produce all four kinds of interference. The first two kinds can be eliminated by insisting that the graph transformation system defined by all aspects be confluent, but, as we have argued in the introduction, this condition is often too restrictive. Individual high-level aspects, on the other hand, have a well-defined meaning: whenever a transition is taken that matches the pointcut of the aspect, the advice of the aspect is executed. We use the inherent parallelism of state machines and extend this semantics to the application of multiple aspects: whenever a transition of the base state machine is taken, the advices of all aspects with matching pointcuts are executed in parallel. Therefore, the first two kinds of aspect interference cannot happen for high-level aspects. The modification of shared state is difficult to detect in the general case; in particular, since the event pool is a global resource even performing a transition without side effects may consume an event that would otherwise have been deferred and hence interfere with another aspect. However, it is often possible to eliminate these interferences by defining advice that modifies no globally visible state and where all transitions are triggered either by completion events or by events with private names. A variant of the last kind of interference can appear if one concurrently executing aspect finishes in a final state labeled 0 and another finishes in a final state labeled 1 as then the resulting transition back to the base state machine is never activated. Similar interferences are also possible with final states labeled goto which are not discussed in this paper. Unfortunately, this condition is statically undecidable since choices may make use of arbitrary functions and are therefore Turing complete. But a simple conservative approximation works well in many practical cases: two aspects are potentially in conflict for a base state machine M if the pointcuts of both match some transition T of M and if one aspect contains a final state labeled 0 and the other one a final state labeled 1.

4 Related Work Our idea of high-level aspects of state machines was inspired by dynamic aspectoriented programming languages such as JAsCo [21] and Object Teams [9]. Our history properties are reminiscent to the trace aspects of Arachne [6]. In the realm of modeling languages and state machines in particular, Altisen et al. [2] propose aspects for Mealy automata. In comparison, the weaving algorithm of our approach is much more elaborate, mainly due to the richer language constructs of the UML. Because of the wider acceptance of the UML, our approach is thus more tightly connected to common practice. State-based aspects in reactive systems are also supported by JPDD [19] and WEAVR UML [4], both of which facilitate specification of high-level pointcuts in flat state machines. In comparison, HiLA was designed to be applicable to parallel and hierarchical UML state machines, where in general concurrency increase the difficulty of correct and modular modeling. We believe HiLA provides valuable help to address these problems. It is worth noting that transition pointcuts are supported by WEAVR UML, although not yet implemented by its modelnig tool Telelogic TAU [26].

116

G. Zhang and M. H¨olzl

Addressing the complete UML, Theme/UML [3] models different features in different models (called themes) and uses UML templates to define common behavior of several themes. General composers like GeKo [15] and MATA [22] can be used for weaving. The aspects of these approaches are low-level, which means modeling nontrivial features often necessitates rather complex aspects, and comprehension of the aspects amounts to understanding the weaving result. Aspect interference is an intrinsic problem of aspect-oriented techniques. It has been addressed in a large amount of publications, for an overview, see [1,13]. Notations of precedence declaration are proposed in, e.g., [12,16,18,26]. Techniques to detect interference proposed so far include detecting shared fields addressed by read and write operations [20], a formal foundation of AOP languages using Conditional Program Transformations [13], and graph transformations [1,23]. These approaches focus on sequential programming languages. In comparison, HiLA exploits the concurrency of state machines and weaves aspects into parallel regions to solve the problem of join points being changed or the result of weaving depending on the weaving order. Weaving into parallel constructs is also proposed in [5], where an approach to concurrent event-based AOP (CEAOP) is defined. Concurrent aspects can be translated into Finite Sequential Processes and checked with the LTSA model-checker. Many similarities exist between CEAOP and the work presented in this paper; however the two approaches take complementary viewpoints in the sense that our work is primarily concerned with a state-based view of AOP that allows, e.g., the definition of mutual exclusion in state machines, whereas the CEAOP is mostly concerned with aspects over event sequences. CEAOP provides operators to combine aspects, e.g., by executing different aspects in sequence or in parallel; our approach is more restricted since our aspects are always executed in parallel. Furthermore, pointcuts in CEAOP are actually similar to sequences of pointcuts according to the usual definition, and pieces of advice are executed at different points of this sequence. This makes it easy to define stateful aspects. While our history mechanism can also be used to define these kinds of aspects, the definition has to be given in several parts and is more cumbersome than in CEAOP. On the other hand, the history mechanism in our approach can take into account values of context variables which significantly increases the expressive power; it seems that this possibility does currently not exist in CEAOP.

5 Conclusions and Future Work We have presented HiLA, an aspect-oriented approach to modeling with state machines. Our aspects can considerably enhance the modularity, and thus the comprehensibility and maintainability, of UML state machines. Compared to other aspect-oriented state machine approaches, HiLA is higher level in that it allows the pointcut to utilize information of the execution history, as well as address the active state configuration as a whole. History-dependent features and synchronization of orthogonal regions can therefore be modeled in HiLA in a highly modular manner. Furthermore, HiLA provides convenient features to model the interaction between multiple concurrently active state machines and therefore directly supports modeling approaches that use state machines to model the behavior of individual objects.

HiLA: High-Level Aspects for UML State Machines

117

On the flip side, the modeler has to learn a relatively rich set of language primitives and understand how the different types of aspects work before being able to successfully use them in the modeling process. Furthermore, the declarative character of high-level aspects leads to a certain loss of control over the detailed behavior. One example is that HiLA currently defers events if a transition is blocked by an aspect and provides no mechanism to “lose” events when using high-level aspects. It would be possible to allow the modeler to specify whether or not events should be deferred, but this would in turn lead to a further increase of the language size and complexity. In spite of these drawbacks, we believe that HiLA greatly enhances the expressive power and clarity of state-machine based approaches to modeling when compared to pure state machines, and that the availability of high-level aspects also offers a number of advantages over purely graph-transformation based approaches. It is, of course, possible to specify graph transformations that correspond to all HiLA aspects; similarly our low-level aspects can describe arbitrary graph transformations so that the approaches can, in theory, simulate each other. But this argument is, in our opinion, somewhat missing the point; more important questions are how clearly and concisely a modeling language can express the important features of systems, how easy it is to add new features or to modify existing behavior, and whether the language helps with testing and validation. To us, the “mostly declarative” approach of HiLA seems to compare well to other aspect-oriented modeling approaches on all these topics. Future work includes a graphical modeling tool, combining HiLA with other aspectoriented UML diagrams and generation of aspect-oriented programs out of HiLA.

References 1. Aksit, M., Rensink, A., Staijen, T.: A Graph-Transformation-Based Simulation Approach for Analysing Aspect Interference on Shared Join Points. In: Proc. 8th Int. Conf. AspectOriented Software Development (AOSD 2009), pp. 39–50 (2009) 2. Altisen, K., Maraninchi, F., Stauch, D.: Aspect-Oriented Programming for Reactive Systems: Larissa, a Proposal in the Synchronous Framework. Sci. Comp. Prog. 63(3), 297–320 (2006) 3. Clarke, S., Baniassad, E.: Aspect-Oriented Analysis and Design. Addison-Wesley, Reading (2005) 4. Cottenier, T., van den Berg, A., Elrad, T.: Joinpoint Inference from Behavioral Specification to Implementation. In: Ernst, E. (ed.) ECOOP 2007. LNCS, vol. 4609, pp. 476–500. Springer, Heidelberg (2007) 5. Douence, R., Botlan, D.L., Noy´e, J., S¨udholt, M.: Concurrent Aspects. In: Proc. 5th Int. Conf. Generative Programming and Component Engineering (GPCE 2006), pp. 79–88. ACM, New York (2006) 6. Douence, R., Fritz, T., Loriant, N., Menaud, J.-M., S´egura-Devillechaise, M., S¨udholt, M.: An Expressive Aspect Language for System Applications with Arachne. In: Mezini, M., Tarr, P.L. (eds.) [14], pp. 27–38 7. Drusinsky, D.: Modeling and Verification Using UML Statecharts. Elsevier, Amsterdam (2006) 8. Engels, G., Opdyke, B., Schmidt, D.C., Weil, F. (eds.): MODELS 2007. LNCS, vol. 4735. Springer, Heidelberg (2007) 9. Herrmann, S.: Object Teams: Improving Modularity for Crosscutting Collaborations. In: Aksit, M., Mezini, M., Unland, R. (eds.) NODe 2002. LNCS, vol. 2591, pp. 248–264. Springer, Heidelberg (2003)

118

G. Zhang and M. H¨olzl

10. H¨olzl, M., Knapp, A., Zhang, G.: Semantics of HiLA. Technical Report LMU-IFI-PST 0901, Ludwig-Maximilians-Universit¨at M¨unchen (2009) 11. Jayaraman, P.K., Whittle, J., Elkhodary, A.M., Gomaa, H.: Model Composition in Product Lines and Feature Interaction Detection Using Critical Pair Analysis. In: Engels, G., et al (eds.) [8], pp. 151–165 12. Kienzle, J., G´elineau, S.: AO Challenge — Implementing the ACID Properties for Transactional Objects. In: Filman, R.E. (ed.) Proc. 5th Int. Conf. Aspect-Oriented Software Development (AOSD 2006), pp. 202–213. ACM, New York (2006) 13. Kniesel, G.: Detection and Resolution of Weaving Interactions. In: Rashid, A., Ossher, H. (eds.) Transactions on Aspect-Oriented Software Development V. LNCS, vol. 5490, pp. 135– 186. Springer, Heidelberg (2009) 14. Mezini, M., Tarr, P.L. (eds.): Proc. 4th Int. Conf. Aspect-Oriented Software Development (AOSD 2005). ACM, New York (2005) 15. Morin, B., Klein, J., Barais, O., J´ez´equel, J.-M.: A Generic Weaver for Supporting Product Lines. In: Proc. 13th Int. Wsh. Software Architectures and Mobility (EA 2008), pp. 11–18. ACM, New York (2008) 16. Nagy, I., Bergmans, L., Aksit, M.: Composing Aspects at Shared Join Points. In: Hirschfeld, R., Kowalczyk, R., Polze, A., Weske, M. (eds.) Proc. Net.ObjectDays (NODe 2005). Lect. Notes Informatics, vol. P-69, pp. 19–38. Gesellschaft f¨ur Informatik (2005) 17. Object Management Group. OMG Unified Modeling Language (OMG UML), Superstructure, Version 2.2. OMG Available Specification, OMG (2009), http://www.omg.org/spec/UML/2.2/Superstructure 18. Reddy, Y.R., Ghosh, S., France, R.B., Straw, G., Bieman, J.M., McEachen, N., Song, E., Georg, G.: Directives for Composing Aspect-Oriented Design Class Models. In: Rashid, A., Aksit, M. (eds.) Transactions on Aspect-Oriented Software Development I. LNCS, vol. 3880, pp. 75–105. Springer, Heidelberg (2006) 19. S´anchez, P., Fuentes, L., Stein, D., Hanenberg, S., Unland, R.: Aspect-Oriented Model Weaving Beyond Model Composition and Model Transformation. In: Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., V¨olter, M. (eds.) MODELS 2008. LNCS, vol. 5301, pp. 766–781. Springer, Heidelberg (2008) 20. St¨orzer, M., Forster, F., Sterr, R.: Detecting Precedence-Related Advice Interference. In: Proc. 21st IEEE/ACM Int. Conf. Automated Software Engineering (ASE 2006), pp. 317– 322. IEEE, Los Alamitos (2006) 21. Vanderperren, W., Suv´ee, D., Verheecke, B., Cibr´an, M.A., Jonckers, V.: Adaptive Programming in JAsCo. In: Mezini, M., Tarr, P.L. (eds.) [14], pp. 75–86 22. Whittle, J., Jayaraman, P.K.: MATA: A Tool for Aspect-Oriented Modeling based on Graph Transformation. In: Proc. 11th Int. Wsh. Aspect-Oriented Modeling, AOM@MoDELS 2007 (2007) 23. Whittle, J., Moreira, A., Ara´ujo, J., Jayaraman, P.K., Elkhodary, A.M., Rabbi, R.: An Expressive Aspect Composition Language for UML State Diagrams. In: Engels, G., et al (eds.) [8], pp. 514–528 24. Zhang, G., H¨olzl, M.: HiLA: High-Level Aspects for UML State Machines. In: 14th Wsh. Aspect-Oriented Modeling (AOM@MoDELS 2009), Denver (2009) 25. Zhang, G., H¨olzl, M., Knapp, A.: Enhancing UML State Machines with Aspects. In: Engels, G., et al (eds.) [8], pp. 529–543 26. Zhang, J., Cottenier, T., van den Berg, A., Gray, J.: Aspect Composition in the Motorola Aspect-Oriented Modeling Weaver. Journal of Object Technology 6(7), 89–108 (2007)

4th International Workshop on [email protected] Nelly Bencomo1, Gordon Blair1, Robert France2, Freddy Muñoz3, and Cédric Jeanneret4 1

Computing Department, Lancaster University, UK {nelly,gordon}comp.lancs.ac.uk 2 Computer Science Department, Colorado State University, USA [email protected] 3 IRISA, INRIA, Equipe Triskell,Rennes, France [email protected] 4 Department of Informatics, University of Zurich, Switzerland [email protected]

Abstract. The 4th edition of the workshop [email protected] was held at the 12th International Conference on Model Driven Engineering Languages and Systems (MODELS). The workshop took place in the city of Denver, Colorado, USA, on the 5th of October 2009. The workshop was organised by Nelly Bencomo, Robert France, Gordon Blair, Freddy Muñoz, and Cédric Jeanneret. It was attended by at least 45 people from more than 10 countries. In this summary we present a synopsis of the presentations and discussions that took place during the 4th International Workshop on [email protected]. Keywords: runtime adaptation, MDE, reflection, abstraction.

1 Introduction The [email protected] workshop series provides a forum for exchange of ideas on use of models to support software runtime adaptation. The workshops target researchers from different communities, including researchers working on model-driven software engineering, software architectures, computational reflection, adaptive systems, autonomic and self-healing systems, and requirements engineering. This edition of the workshop successfully brought together researchers from different communities: At least forty-five (45) people from nineteen (19) countries attended the workshop. In this workshop we took advantage of the experience gained in previous editions and focused the discussions on the topic: “Raising the abstraction level". In response to the call for papers, sixteen (16) papers were submitted, of which four (4) papers and two (2) tool demonstrations were accepted. Additionally, six (6) papers were invited for poster presentations. Each submitted paper was reviewed by at least 3 program committee members. The papers presented during the workshop are published in a workshop proceedings [1]. Two papers were selected as the best papers. Extended and improved versions of these two papers are published in this post workshop proceedings. S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 119–123, 2010. © Springer-Verlag Berlin Heidelberg 2010

120

N. Bencomo et al.

2 Workshop Format and Session Summaries The workshop activities were structured into presentations, poster, and discussion sessions. In the opening presentation, Robert France set the context of the workshop by summarizing the major results from past workshop editions, presenting the theme of the fourth edition of the workshop “Raising the abstraction level", outlining the path to follow during the workshop, and announcing the publication of the special issue on the topic published by IEEE Computer in October 2009 [2]. The opening presentation was followed by the papers and posters sessions. In the paper sessions four (4) papers and two (2) demonstrations were presented. Authors presented their papers in a 20 minutes time slot, which included five minutes for questions and discussion. Geri George and Franck Fleurey chaired these presentations. In the poster session, six authors presented their work to the workshop attendees. All presentations were done during the morning to allow enough time for discussion. In the afternoon, the workshop participants formed three groups, where each group was charged with discussing a particularly relevant topic. At the end of the workshop, each group selected a representative who presented the questions raised in the group, and the conclusions reached by the group. More details about the discussion session can be found in section 3. The four (4) paper presentations and the two (2) demos were divided into the following two paper sessions: Session 1: The use of Computational Reflection - Incremental Model Synchronization for Efficient Run-time Monitoring", Thomas Vogel, Stefan Neumann, Stephan Hildebrandt, Holger Giese, and Basil Becker. - Generating Synchronization Engines between Running Systems and Their ModelBased Views, Hui Song, Yingfei Xiong, Franck Chauvel, Gang Huang, Zhenjiang Hu, and Hong Mei. - Demo: Leveraging Models From Design-time to Runtime. A Live Demo, Brice Morin, Olivier Barais, Jean-Marc Jézéquel and Grégory Nain. Session 2: Configuration Management - Evolving Models at Run Time to Address Functional and Non-Functional Adaptation Requirements, Andres J. Ramirez and Betty H.C. Cheng. - On the Role of Features in Analyzing the Architecture of Self-Adaptive Software Systems, Ahmed Elkhodary, Sam Malek and Naeem Esfahani. - Demo: Models at Runtime: Service for Device Composition and Adaptation, Nicolas Ferry, Vincent Hourdin, Stephane Lavirotte, Gaetan Rey, Jean-Yves Tigli, and Michel Riveill. The following posters were displayed and presented to the workshop attendees. - Using Specification Models for RunTime Adaptations, Sébastien Saudrais, Athanasios Staikopoulos and Siobhan Clarke. - A Model-Driven Configuration Management Systems for Advanced IT Service Management, Holger Giese, Andreas Seibel and Thomas Vogel.

4th International Workshop on [email protected]

121

- Modeling Context and Dynamic Adaptations with Feature Models, Mathieu Acher, Philippe Collet, Franck Fleurey, Philippe Lahire, Sabine Moisan and Jean-Paul Rigault. - Design for an Adaptive Object-Model Framework: An Overview, Hugo Ferreira, Filipe Correia and Ademar Aguiar. - Management of Runtime Models and Meta-Models in Meta-ORB Reflective Middleware Architecture, Lucas L. Provensi, Fábio M. Costa and Vagner Sacramento. - Statechart Interpretation on Resource Constrained Platforms: a Performance Analysis, Edzard Hoefig, Peter H. Deussen and Hakan Coskun. During the afternoon, three discussions groups were established. Each group was charged with discussing a topic based on the questions raised during the presentations and the theme of the workshop – “Raising the level of abstraction”: -

The types of models that arise at runtime. Reasoning and decision making at runtime. Causal connection between models at runtime and the running system.

3 Discussions After the presentations of the morning, the participants were organized into three groups (one group per topic as presented in the previous section). After spending 2 hours discussing the presentations and shared research interests, the groups came back to the meeting room to present a summary of their discussions and conclusions. Thomas Vogel was the representative for the group that discussed the “different types of models at runtime” topic. Thomas presented several categories of models at runtime: (1) abstract and fine-grained models, (2) structural and behavioural models, and (3) dynamic and static models. He emphasized that there are several dependencies among these categories such as critical and non-critical, explicit and implicit, overlapped dependencies (i.e. information replicated among models), and semantic and transitive dependencies. These dependencies raise the following research questions: How can we identify these dependencies? Are there dependency patterns that appear again and again? The identification of appropriate dependencies may help determine the impact that a change on one model can have on another. Identifying and managing dependencies will help developers produce the support needed to adapt software based on considerations such as cost and performance trade-off , criticality of functionality, and change rollbacks. Additionally, the support for managing the dependencies and transitive relationships among different categories of models can improve the propagation of correctness, compliance, and consistency criteria from one category to another. Finally, Thomas closed the presentation by reminding the audience that the [email protected] community can learn from system management work such as the work carried out by the companies IBM, CA, SAP. Frank Chauvel was the representative of the group that discussed “reasoning at runtime”. He started by stating that reasoning is a part of the analysis and planning phases of the control loop typically associated with autonomic systems. Franck then presented four questions that the group identified as main concerns:

122

N. Bencomo et al.

(1) What application domain does the reasoning target? As reasoning depends on the domain knowledge, it is important to identify in advance the application domain and its constraints. For example, some application domains may require reasoning responses by milliseconds whereas others do it by microseconds. Other constraints may deal with the reasoning’s accuracy, the type of reasoning that is required at runtime, or with what can be reasoned beforehand at design time. (2) What do we want to achieve with reasoning? Identifying the goals we seek to reason about and their impact on the actual running system is crucial. It determines the choice of the reasoning strategy to use. For example, reasoning can be performed to maintain over time self-* properties, such as self-adaptation, self-healing, selfconfiguration, (3) How to achieve it?, What techniques are suitable? According to the goal and the application domain, a variety of techniques may (or not) be suited to perform the needed reasoning. Some techniques are well suited to pre-process and analyze data, to plan and define action sequences, and to deduce and decide (e.g., rule-based systems, goal-based systems, neural networks). When selecting a reasoning technique, it is also useful to ask What inputs are required by the reasoning engine and how are they provided? Sometimes domain information may need to be pre-processed and filtered (via model transformation) before reasoning (or before making decision based on that information). (4) Which abstraction level should be used? Recalling the previous presentation, it was shown that different categories of models in different application domains may require different processing and representations. The focus and scope of the reasoning may suggest the abstraction level needed for the different artefacts and decisions. For instance, making decision on varying requirement requires a representation at that abstraction level (functionalities, qualities, etc), whereas making decisions on component swapping and state conservation requires a lower lever representation of components and connectors. Finally, Frank reminded the audience of the need to set clear goals. These goals should ensure the consistency between the answers to the previous questions and clearly states the relation between the application domains, the results of reasoning, and the reasoning techniques that are best suited to accomplish the reasoning task. Hugo Ferreira was the representative of the group that discussed the causal link between models at runtime and systems. Hugo started by defining a causal connection as a mapping between a model and its base system. The evolution of the model or the system implies that the other should change accordingly. Therefore, causality should be present whenever the system or the model evolves (or many systems and many models). More important, the causal connection should ensure synchronization and consistency at every moment – models and systems are up-to-date and should not cause conflicts. Hugo highlighted some challenges the group identified: (1) As the system evolves, how does the runtime model reflect the system changes? How do we make that possible? Different levels of abstraction help the causal connection to achieve a better granularity level according to the causal goals. For instance, aspects can be helpful for handling crosscutting concerns in causal change (security, authorization, etc). The synchronization rate between models and systems may depend of the goals that causality pursuit. For instance, in some cases

4th International Workshop on [email protected]

123

an event-based synchronization may be useful, whereas in other cases, a time frame-based synchronization may be a better choice. (2) Who changes the model? Why does it change? The model can be changed either manually or automatically. These changes may vary on nature according to the goal of the model(s). For instance, some models may change only to reflect the system changes (and perform verification tasks), whereas other may change to adapt the system and change its configuration. (3) How do we detect an inconsistency? According to which parameters (efficiency, relevance, degree of inconsistency)? Inconsistencies may arise when the system and the model change at the same time. It is necessary to define and evaluate means to detect inconsistencies and resolve them. (4) In case of inconsistency, which is more valid, the correctness of the model (if any) that controls the system, or the state of the system that should be reflected by the model? The issue is being able to recognize when to rollback changes in models, and when to rollback changes in the system. There is no real answer to this question, but a case-by-case analysis. Sometimes, we want the system to be “correct” and we may sacrifice the system evolution to maintain correctness. Sometimes, we want the model to be synchronized, and to reflect the system as is, then we may sacrifice the model correctness for fast synchronization. Final Remarks: A general wrap-up discussion was held at the very end of the workshop. The workshop was closed with a warm “thank you” from the organizers to all participants for another successful workshop. After the workshop, the organizers used the feedback from attendees and program committee members to select the best 2 papers. After discussion, the following papers were selected as the best 2 papers: - Generating Synchronization Engines between Running Systems and Their ModelBased Views. - Incremental Model Synchronization for Efficient Run-time Monitoring Acknowledgments. No workshop is successful by the efforts of only a few people. We would also like to thank the members of the program committee who acted as anonymous reviewers and provided valuable feedback to the authors: Danilo Ardagna, Fabio M. Costa, Franck Chauvel, Betty Cheng, Peter J. Clark, Frank Fleurey, John Georgas, Jeff Gray, Oystein Haugen, Jozef Hooman, Gang Huang, Paola Inverardi, Jean-Marc Jezequel, Stephane Menoret, Brice Morin, Flavio Oquendo, Daniel Schneider, Rui Silva Moreira, Arnor Solberg, Thais Vasconcelos Batista. Last but not least, the authors for their interesting submissions are thanked for helping us making this workshop possible.

References [1] Bencomo, N., Blair, G.S., France, R.B., Muñoz, F., Jeanneret, C.: Proceedings of the 4th Workshop on [email protected], held at the 12th International Conference on Model Driven Engineering Languages and Systems (MODELS 2009). CEUR Workshop Proceedings. CEUR, vol. 509 (2009) [2] Blair, G., Bencomo, N., France, R.B.: Models@ run.time. Computer 42(10), 22–27 (2009)

Incremental Model Synchronization for Eﬃcient Run-Time Monitoring Thomas Vogel, Stefan Neumann, Stephan Hildebrandt, Holger Giese, and Basil Becker Hasso Plattner Institute at the University of Potsdam Prof.-Dr.-Helmert-Str. 2-3, 14482 Potsdam, Germany [email protected]

Abstract. The model-driven engineering community has developed expressive model transformation techniques based on metamodels, which ease the speciﬁcation of translations between diﬀerent model types. Thus, it is attractive to also apply these techniques for autonomic and selfadaptive systems at run-time to enable a comprehensive monitoring of their architectures while reducing development eﬀorts. This requires special solutions for model transformation techniques as they are applied at run-time instead of their traditional usage at development time. In this paper we present an approach to ease the development of architectural monitoring based on incremental model synchronization with triple graph grammars. We show that the provided incremental synchronization between a running system and models for diﬀerent self-management capabilities provides a signiﬁcantly better compromise between performance and development costs than manually developed solutions.

1

Introduction

The complexity of today’s software systems impedes the administration of these systems by humans. The vision of self-adaptive software [1] and Autonomic Computing [2] addresses this problem by considering systems that manage themselves given high-level goals from humans. The typical self-management capabilities self-configuration, self-healing, self-optimization or self-protection [2] can greatly beneﬁt when in addition to some conﬁguration parameters also the architecture of a managed software system can be observed [3]. Each of these capabilities requires its own abstract view on a managed software system that reﬂects the run-time state of the system regarding its architecture and parameters in the context of the concern being addressed by the corresponding capability, e.g. performance in the case of self-optimization. Monitoring an architecture of a running system in addition to its parameters requires an eﬃcient run-time solution to be applicable online and it results in a considerable increase in complexity. The complexity further increases, as a view has to be usually decoupled from a running system for system analysis. Otherwise, changes that occurred during an analysis might invalidate the analysis results, as the analysis was not performed on a consistent view. Due to the complexity, S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 124–139, 2010. c Springer-Verlag Berlin Heidelberg 2010

Incremental Model Synchronization for Eﬃcient Run-Time Monitoring

125

the eﬀorts for developing monitoring approaches should be reduced. Moreover, diﬀerent views on a running system have to be provided eﬃciently at run-time. In this context, Model-Driven Engineering (MDE) techniques can in principle help. MDE provides expressive model transformation techniques based on metamodels which ease the speciﬁcation of translations between diﬀerent model types. As argued in [4], these techniques could be used for run-time models and thus also ease the development of architectural monitoring. Applying such techniques at run-time is promising for monitoring activities, as run-time models can provide appropriate abstractions of a running system from diﬀerent problem space perspectives [5]. Thus, a run-time model can target a certain self-management capability and the corresponding concerns. In this paper we propose a model-driven approach that enables a comprehensive monitoring of a running system by using metamodels and model transformation techniques as sketched in [6], where there was no room for a detailed discussion of the approach. Diﬀerent views on a system regarding diﬀerent selfmanagement capabilities are provided through run-time models that are derived and maintained by our model transformation engine automatically. These models can be independent from the platform of a monitored system, which supports the reusability of analysis algorithms working on these models. The engine employs our optimized model transformation technique [7,8] that permits incremental processing and therefore can operate eﬃciently and online. Furthermore, the approach eases the development eﬀorts for monitoring. For evaluation, the implementation of our approach considers performance monitoring, checking architectural constraints and failure monitoring that are relevant for self-optimization, self-conﬁguration, and self-healing capabilities, respectively. The paper is structured as follows: The proposed approach is presented in Section 2 and its application in Section 3. The beneﬁts of the approach are evaluated with respect to development costs and performance in Section 4. After discussing related work in Section 5, the paper concludes with a discussion on research challenges and future work.

2

Approach

To monitor the architecture and parameters of a running software system, our approach employs Model-Driven Engineering (MDE) techniques, which handle the monitoring and analysis of a system at the higher level of models rather than at the level of Application Programming Interfaces (APIs). Using MDE techniques, diﬀerent models describing certain concerns or certain views on a running system required for diﬀerent self-management capabilities are derived and maintained at run-time. Thus, models of a managed system and of its architecture essentially build the interface for monitoring the system. In the following, we present the generic architecture and the implementation of our approach. 2.1

Generic Architecture

The generic architecture of our monitoring approach is derived from [6] and depicted in Figure 1. A Managed System provides Sensors that are used to observe

126

T. Vogel et al.

Managing System

architectural element model defined by monitoring uses

Target Model

Metamodel

Model Transformation Engine

TGG Rules

Source Model

Metamodel

Sensors Managed System

Fig. 1. Generic Architecture (cf. [6])

the system, but that are usually at the abstraction level of APIs. These sensors can be used by any kind of Managing Systems for monitoring activities. Managing systems can be administration tools used by humans or even autonomic managers in case of a control loop architecture as proposed, among others, in [2]. Since it is diﬃcult to obtain an architectural view on a managed system by using sensors at such a low level of abstraction, our approach provides a run-time model of the system in the form of a Source Model. This model enables a modelbased access to sensors and it is maintained and updated at run-time if changes occur in the managed system. Though having a model-based view on a managed system, a source model represents all functionalities of the sensors and, therefore, it is usually related to the solution space of a managed system. Consequently, a source model might be quite complex and speciﬁc to the platform of a managed system, which makes it laborious to use it as a basis for monitoring and analysis activities by managing systems. As the source model is deﬁned by a Metamodel, it can be accessed by model transformation techniques. Using such techniques, we propose to derive several Target Models from the source model at run-time. Each target model raises the level of abstraction with respect to the source model and it provides a speciﬁc view on a managed system required for a certain self-management capability and the corresponding concern. Thus, in contrast to a source model that usually relates to the solution space of a managed system, target models tend to provide views related to problem spaces of diﬀerent self-management capabilities and to abstract from the underlying platform of a managed system. This supports the reusability of managing systems that focus on problem spaces shared by diﬀerent managed systems. For example, a target model might represent the security conditions or the resource utilization and performance state of a managed system to address self-protection or self-optimization, respectively. Moreover, a managing system being concerned with self-optimization will use only those target models that are relevant for optimizing a managed system, but does not have to consider

Incremental Model Synchronization for Eﬃcient Run-Time Monitoring

127

concerns or views that are covered by other capabilities such as self-protection. This also reduces the complexity for managing systems in coping with run-time models, though diﬀerent target models may provide overlapping views. Consequently, several managing systems work concurrently on possibly diﬀerent target models, as depicted in Figure 1. The diﬀerent target models are maintained by our Model Transformation Engine, which is based on Triple Graph Grammars (TGGs) [7,8]. TGG Rules specify declaratively at the level of metamodels how two models, a source and a target model of the corresponding metamodels, can be transformed and synchronized with each other. Thus, source and target models have to conform to userdeﬁned metamodels (cf. Figure 1). A TGG combines three conventional graph grammars: one grammar describes a source model, the second one describes a target model and a third grammar describes a correspondence model. A correspondence model explicitly stores the correspondence relationships between corresponding source and target model elements. Concrete examples of TGG rules are presented in Section 3 together with the application of our approach. To detect model modiﬁcations eﬃciently, the transformation engine relies on a notiﬁcation mechanism that reports when a source model element has been changed. To synchronize the changes of a source model to a target model, the engine ﬁrst checks if the model elements are still consistent by navigating eﬃciently between both models using the correspondence model. If this is not the case, the engine reestablishes consistency by synchronizing attribute values and adjusting links. If this fails, the inconsistent target model elements are deleted and replaced by new ones that are consistent to the source model. Thus, our model transformation technique synchronizes a source and a target model incrementally and therefore eﬃciently with respect to execution time as it avoids any recurring transformations from scratch. This enables the application of our technique at run-time. Therefore, for each target metamodel, TGG rules have to be deﬁned that specify the synchronization between the source model and the corresponding target model. Based on declarative TGG rules, operational rules in the form of source code are generated automatically, which actually perform the synchronization. Thus, our transformation engine reﬂects changes of the source model in the target models, which supports the monitoring of a managed system. Therefore, relevant information is collected from sensors to enable an analysis of the structure and the behavior of a managed system. As sensors might work in a pull or push-oriented manner, updates for a source model are triggered periodically or by events emitted by sensors, respectively. In both cases it is advantageous if the propagation of changes to target models could be restricted to a minimum. Therefore, our model transformation engine only reacts to change notiﬁcations dispatched by a source model and it does not process unchanged model elements. The notiﬁcations contain all relevant information to identify and locate the changes in the source model and to adjust the target models appropriately. Though the model transformation engine is notiﬁed immediately about modiﬁcations in the source model, there is no need for the engine to react right away

128

T. Vogel et al.

by synchronizing the source model with the target models. The engine has the capability to buﬀer notiﬁcations until synchronization is triggered externally. Hence, the engine is able to synchronize two models that diﬀer in more than one change and it facilitates a decoupling of target models from the source model, which enables the analysis of a consistent view based on target models. Finally, our model-driven approach can be easily extended with additional target models. As target models can be platform-independent, the kinds of target models that are used in our approach are rather deﬁned by managing systems than by our transformation engine or the underlying infrastructure. For example, to integrate an existing managing system or an analysis algorithm that uses a certain target model, only the corresponding target metamodel and TGG rules, which specify the synchronization of the source model with the corresponding target model, have to be provided. Thus, our approach fosters the reusability of managing systems or of analysis algorithms instead of having to re-engineer them to ﬁt into our approach. 2.2

Implementation

The implementation is based on the autonomic computing infrastructure mKernel [9], which enables the management of software systems being realized with Enterprise Java Beans 3.0 (EJB) [10] technology for the GlassFish v2 1 application server. For run-time management, mKernel provides sensors and effectors as an API. However, this API is not compliant to the Eclipse Modeling Framework (EMF)2 , which is the basis for our model transformation techniques. Therefore, we developed an EMF compliant metamodel for the EJB domain that captures the capabilities of the API. This metamodel deﬁnes the source model in our example. A simpliﬁed version of it is depicted in Figure 2 and it is described in detail in the following section. Though our techniques are based on EMF, the whole infrastructure can run decoupled from the Eclipse workbench. To synchronize a running managed system with our source model, an eventdriven EMF Adapter has been realized. It modiﬁes the source model incrementally by processing events being emitted by sensors if parameters or the structure of a system have changed. Additionally, the adapter covers on demand the monitoring of frequently occurring behavioral aspects, like concrete interactions within a managed system, by using pull-oriented sensors that avoid the profusion of events.

3

Application

This section describes the application of our model-driven monitoring approach. The metamodel for the EJB domain that speciﬁes the source model is depicted in a simpliﬁed version in Figure 2. The metamodel is conceptually divided into three levels. The top level considers the types of constituting elements of EJB-based systems, which are the 1 2

https://glassﬁsh.dev.java.net/ (Nov 4, 2009) http://www.eclipse.org/modeling/emf/ (Nov 4, 2009)

Incremental Model Synchronization for Eﬃcient Run-Time Monitoring

129

Fig. 2. Simpliﬁed Source Metamodel

results of system development. The middle level covers concrete conﬁgurations of EJB-based systems being deployed in a server. Finally, the lower level addresses concrete instances of enterprise beans and interactions by means of calls among them. The metamodel depicted in Figure 2 is simpliﬁed as it does not show, among others, attributes, enumerations, and several associations to navigate between the levels. For brevity, we refer to [9,10] to get details on the EJB component model and on the three levels. Based on this metamodel, a source model provides a comprehensive view on EJB-based systems, which however might be too complex for performing analyses regarding architectural constraints, performance and failure states of managed systems. Therefore, for each of these concerns, we developed a metamodel specifying a corresponding target model and the TGG rules deﬁning the synchronization of the source model with the target model. Thus, our model transformation engine synchronizes the source model with three target models at higher level of abstractions aiming at run-time monitoring and analysis of architectural constraints, performance and failure states. 3.1

Architectural Constraints

Analyzing architectural constraints requires the monitoring of the architecture of a running system. Therefore, we developed a metamodel that is depicted in

130

T. Vogel et al.

Figure 3 and whose instances reﬂect simpliﬁed run-time architectures of EJBbased systems. It abstracts from the source metamodel by providing a black box view on EJB modules through hiding enterprise beans being contained in modules, since modules and not single enterprise beans are the unit of deployment. Moreover, it abstracts from concrete bean instances and calls among them. To analyze architectural constraints, the Object Constraint Language (OCL) and checkers like EMF OCL3 are used to deﬁne and check constraints that are attached to metamodel elements, as illustrated in Figure 3. The constraint states that at most one instance SimEjbModule of a particular SimEjbModuleType with a certain value for attribute name exists. In other words, at most one module of the module type named Foo can be deployed.

Fig. 3. Simpliﬁed Architectural Metamodel

3.2

Fig. 4. Performance Metamodel

Performance Monitoring

Like the architectural target metamodel, the metamodel for target models being used to monitor the performance state of EJB-based systems also abstracts from the source metamodel. Moreover, it is independent from the EJB platform as it provides a view based on generic components and connectors. Figure 4 shows the corresponding metamodel. The metamodel represents session beans as Components and connections among beans as Connectors among components. For both entities, information about the instance situation is derived from the source model and stored in their attributes. For each component, the number of currently running instances, the maximum number of instances that have run concurrently, or the number of instances that have been created entirely are represented by the attributes runningInstances, runningInstancesMax and instanceCount, respectively. For each connector, the number of invocations, the maximum and minimum execution time of all invocations and the sum of execution time of all invocations along the 3

http://www.eclipse.org/modeling/mdt/?project=ocl (Nov 4, 2009)

Incremental Model Synchronization for Eﬃcient Run-Time Monitoring

131

connector are reﬂected by the attributes invocationCount, maxTime, minTime and totalTime, respectively. The average execution time of an invocation along a connector can be obtained by dividing totalTime with invocationCount. Finally, a component provides operations to retrieve aggregated performance information about all connectors provided by the component (inConnectors), and a Server provides aggregated information about its hosted components. Overall, a modelbased view is provided on the performance states of enterprise beans, which is comparable to parts of the Performance Data Framework deﬁned by the Java 2 Platform, Enterprise Edition Management Specification [11]. Based on the structure and attributes of the performance target model, an analysis might detect which components are bottlenecks and which are only blocked by others. Such information might be used to decide about relocating components, whose instances cause heavy loads, to other servers or improving the resource conﬁguration. The four TGG rules that are required to synchronize the source model with the performance target model are depicted in a simpliﬁed version in Figure 5. For all of them, nodes on the left refer to the source model, nodes on the right to the

Fig. 5. Simpliﬁed TGG rules for performance target model

132

T. Vogel et al.

target model, and nodes in the middle constitute the correspondence model. The elements that are drawn black describe the application context of the rule, i.e., these elements must already exist in the models before the rule can be applied. The elements that are not drawn black and marked with ++ are created by applying the rule. The ﬁrst rule in Figure 5 is the axiom that creates the ﬁrst target model element Server for a Container in the source model. The correspondence between both is maintained by a CorrContainer that is created and that is part of the correspondence model. Based on the second rule, for each SessionBean of an EjbModule associated to a Container that is created in the source model, a Component is created in the target model and associated to the corresponding Server. Likewise to a CorrContainer, the CorrComponent maintains the mapping between the SessionBean and the Component. As an example, this rule shows how element attributes are synchronized. The value for the attribute uid of a Component is derived directly from the attribute uid of a SessionBean, while instanceCount is the number of SessionBeanInstance elements the SessionBean is connected to via the instances link (cf. Figure 2). Moreover, for more complex cases, helper methods operating on the source model can be used to derive values for attributes of target model elements. The third rule is similar to the second one. It maps an EjbInterface provided by a SessionBean to a Connector for the corresponding Component. The CorrConnector maintains the relation between the EjbInterface and the Connector. The last rule creates a link between a Component and a Connector if an EjbReference of the corresponding SessionBean is associated to the EjbInterface that corresponds to the Connector. Comparable rules have been created for all target models, which are not described here for brevity. 3.3

Failure Monitoring

The last target model is intended for monitoring failures within managed systems. The corresponding metamodel is shown in a simpliﬁed version in Figure 6.

Fig. 6. Simpliﬁed Failure Metamodel

It deﬁnes a platform-independent architectural view on a managed system that is enriched with information about occurred failures. Components representing session beans are running in a Container. They can be conﬁgured through

Incremental Model Synchronization for Eﬃcient Run-Time Monitoring

133

Properties that correspond to simple environment entries, which are conﬁguration parameters for enterprise beans. A component provides Interfaces and potential requirements of functionality from other components are represented by Receptacles. Receptacles can be connected to interfaces via Connectors. An interface speciﬁes at least one Method whose usage at run-time might result in occurrences of exceptions (ExceptionInstance). Finally, each exception instance usually contains a stack trace (StackTraceElem). Thus, the failure model provides a basic view on the architecture and conﬁguration of an EJB-based system that can be related to exceptions that have occurred. If a certain method of an interface throws many exceptions, it can be analyzed whether the conﬁguration of the component providing the corresponding interface is faulty because some property values of the component are not set appropriately, the implementation of the component is faulty, or other components using the corresponding interface are not using the interface appropriately.

4

Evaluation

In this section we evaluate our approach in comparison with two other feasible solutions that might provide multiple target models for monitoring. 1. Model-Driven Approach: The approach presented in this paper. 2. Non-Incremental Adapter (NIA): For each target model, this approach retrieves the current run-time state of a managed system, i.e. a system snapshot, by extracting required structural and behavioral information directly from sensors in a pull-oriented manner. Then, the diﬀerent target models are created from scratch. 3. Incremental Adapter (IA): In contrast to the Non-Incremental Adapter, for each target model, this approach uses event-based sensors, which inform a managing system about changes in a managed system in a push-oriented manner. These events are processed and reﬂected incrementally in diﬀerent target models. In the following, our approach is evaluated, discussed and compared to these alternative approaches by means of development costs and performance. 4.1

Development Costs

Having implemented our approach and the NIA, we are able to give concrete values indicating development costs, which are depicted in Table 1. Using our Table 1. TGG Rules and Lines of Code (LOC) Model-Driven Approach Target Model Rules Nodes/Rules LOC Simpl. Architectural Model 9 7,44 15259 Performance Model 4 6,25 5979 Failure Model 7 7,14 12133 Sum 20 33371

NIA LOC 357 253 292 902

134

T. Vogel et al. Table 2. Performance measurement [ms] Size 5 10 15 20 25

NIA Model-Driven Approach S B n=0 n=1 n=2 n=3 n=4 n=5 B 8037 20967 0 163 361 523 749 891 10733 9663 43054 0 152 272 457 585 790 23270 10811 72984 0 157 308 472 643 848 36488 12257 105671 0 170 325 481 623 820 55491 15311 142778 0 178 339 523 708 850 72531

approach, we had to specify 20 TGG rules to deﬁne the transformation and synchronization between the source and all three target models described in Section 3. On average, each rule has about six to seven nodes, which constitutes quite small diagrams for each rule. However, based on all rules, an additional 33371 lines of code including code documentation have been generated automatically. Manually written code in the size of 2685 lines was only required for the EMF Adapter (cf. Section 2.2), that however does not depend on any target metamodel and therefore is generic and reusable. Consequently, specifying an acceptable number of TGG rules declaratively seems to be less expensive and less error-prone than writing an imperative program that realizes an incremental model synchronization mechanism (cf. about 30k lines of code the IA might potentially require). In contrast, the NIA required only 902 lines of code, which seems to be of the same complexity as the 20 TGG rules regarding the eﬀort for development. Moreover, our approach using model transformation techniques is easier to extend or to adapt for the case that new target models have to be integrated or metamodels of already used target models have changed, respectively. It requires only the provision of the new or changed metamodels and the creation or update of appropriate TGG rules, which is done in a declarative manner. Afterwards, code corresponding to the rules is generated automatically. In contrast and under the assumption that the other two approaches do not apply MDE techniques, especially code generation, these approaches require codebased re-engineering, i.e., usually altering imperative code. This can be expected to be more time consuming and error-prone than our approach, when having the diﬀerent characteristics of the approaches regarding development costs in mind and when comparing declarative and imperative approaches. 4.2

Performance

Finally, the approaches are discussed with respect to run-time performance. The results of some execution time measurements4 are shown in Table 2. The ﬁrst column Size corresponds to the number of beans that are deployed in a server to obtain diﬀerent sizes for source and target models. Approximately in the same ratio as the number of deployed beans increases, the number of events emitted by mKernel sensors due to structural changes, the number of bean instances, 4

Conﬁguration: Intel Core 2 Duo 3GHz, 3GB RAM, Linux Kernel 2.6.27.11.

Incremental Model Synchronization for Eﬃcient Run-Time Monitoring

135

and the calls among bean instances increase. mKernel sensors allow to monitor structural (S ) and behavioral (B ) aspects. Behavioral aspects, i.e., concrete calls, can only be monitored in a pull-oriented manner, while structural aspects can additionally be obtained through a push-oriented event mechanism. Changes can range from the modiﬁcation of a single attribute value to several model elements if an EJB module together with the included beans, interfaces, references and simple environment entries is added or removed from the system. The NIA uses only pull-oriented sensors to retrieve all required information to create the three target models separately, from scratch and periodically. For this approach, the second and third columns show the consumed time in milliseconds (ms) to retrieve a system snapshot from sensors and to create the three target models. For example, having deployed ten beans, it took 9663 ms to obtain and reﬂect the structural aspects in the target models, while the behavioral aspects required 43054 ms. Overall, the sum of both (52717 ms) has been consumed. For our Model-Driven Approach, structural aspects are obtained through events and behavioral aspects through pull-oriented sensors. For the structural monitoring, the fourth to ninth columns show the composite average times of two subsequent activities: 1. Event Processing: n events, that are emitted by sensors to notify about n structural changes of the managed system, are processed by reﬂecting these changes in the source model. Regarding structural aspects, this activity keeps the source model up-to-date and it is performed by the EMF Adapter (cf. Section 2.2). 2. Model Synchronization: This activity synchronizes changes of the source model, which are the result of processing n events, to the three target models incrementally by invoking once the model transformation engine. For example, for n = 2 and having deployed ten beans, 272 ms are consumed on average for processing two events, which includes updates of the source model depending on these two events, and for synchronizing at once the corresponding changes in the source model to the three target models on average. Additionally, we decomposed the average times to ﬁnd out the ratio of event processing times and model synchronization times. On average over all model sizes, 7.2%, 5.9%, 4.4%, 4.8% and 3.7% of the average times are used for model synchronization for the cases of n from one to ﬁve, respectively. Consequently, most of the time is spent on event processing, while our model transformation engine performs very eﬃciently. The last column of Table 2 shows the average times for retrieving one system snapshot of behavioral aspects, i.e., observed interactions among bean instances, through pull-oriented sensors, for reﬂecting this snapshot in the source model, and ﬁnally for synchronizing the updated source model to the three target models by invoking once the transformation engine. The third and last columns of Table 2 indicate that for both approaches the behavioral monitoring is expensive. This is a general problem, when complete system behavior should be observed. However, comparing both approaches regarding behavioral monitoring, our approach outperforms the NIA. Using our approach, the sensors are only accessed

136

T. Vogel et al.

once to obtain the required interaction information, which are then reﬂected in the source model. In contrast, the NIA accesses sensors twice to get interaction information, namely to create the failure target model and the performance target model. Both target models require interaction information, to obtain thrown exceptions or execution times of calls among bean instances, respectively. Regarding structural monitoring, our approach clearly outperforms the NIA as it works incrementally, while the NIA does not. Moreover, a manual IA would not be able to outperform our approach, because, as described above, event processing activities are much more expensive than model synchronization activities and a manual IA would have three event listeners, one for each target model, in contrast to the one listener our approach requires for the source model. To conclude, our approach outperforms the considered alternative approaches when development costs and performance are taken into account.

5

Related Work

The need to interpret monitored data in terms of the system’s architecture to enable a high-level understanding of the system was recognized by [12], who use a system representation based on an architecture description language, but no advanced model-driven techniques like model synchronization. Model-driven approaches considering run-time models, in contrast to ours, do not work incrementally to maintain those models or they provide only one view on a managed system. In [13] a model is created from scratch out of a system snapshot and it is only used to check constraints expressed in OCL. The run-time model in [14] is updated incrementally. However, it is based on XML descriptors and it provides a view focused on the conﬁguration and deployment of a system, but no other information, e.g., regarding performance. The same holds for [15] whose run-time model is updated incrementally, but reﬂects also only a structural view. However, they use model weaving techniques to transform models speciﬁed by the same metamodel to obtain new structures for a managed system [16]. All these approaches do not apply advanced MDE techniques like model transformation [13,14] or they do not consider the transformation of models speciﬁed by diﬀerent metamodels [15,16]. In this context, initial preliminary ideas exist, like [17], who apply a QVT-based [18] approach to transform models at run-time. They use MediniQVT 5 as a partial implementation of QVT, which performs only oﬄine synchronizations, i.e., models have to be read from ﬁles, and therefore leads to a performance loss. Moreover, it seems that their source model is not maintained at run-time, but always created on demand from scratch, which would involve non-incremental model transformations. Regarding the performance of diﬀerent model transformation techniques, we have shown that our TGG-based transformation engine is competitive to ATL[19] or QVT-based ones when transforming class and block diagrams. Moreover, for the case of synchronization, our engine outperforms the other engines [20]. 5

http://www.ikv.de/ (Nov 4, 2009)

Incremental Model Synchronization for Eﬃcient Run-Time Monitoring

137

Though the approach presented here uses diﬀerent models, metamodels and therefore diﬀerent transformation rules, similar results can be expected for the case study used in this paper.

6

Conclusion, Discussion and Future Work

This paper presented our approach for the model-driven monitoring of software systems. It enables the eﬃcient monitoring by using models based on metamodels and model synchronization techniques at run-time. The incremental synchronization between a run-time system and problem space oriented models for diﬀerent concerns can be triggered when needed and multiple managing systems can operate concurrently. As target models can be platform-independent, our approach leverages the reusability of managing systems across diﬀerent managed systems. The presented solution using TGGs outperforms feasible alternatives considering development costs and performance. Since TGGs have the capability of bidirectional model synchronization, basically and as sketched in [6], this technique can also be used for adapting a managed system. Instead of performing architectural adaptations directly by changing the source model, we propose that changes are applied to target models and synchronized to the source model. However, several research challenges emerge in this context, which are discussed in the following. Adapting the architecture of a managed system is complex, as a set of atomic changes might have to be performed. The order of changes performed on a target model might diﬀer from the order of performing corresponding changes to the source model and therefore to the managed system. Not suitable orders might aﬀect the consistency of a system. Moreover, in some cases the abstraction step between a source and a target model is too large. As a consequence, the relation between source and target models is only partial and need not to be injective. Therefore synchronizing target model changes to the source model requires additional information such as default values that depend on the concrete application. The same problem is discussed for round-trip engineering in [21] that emphasizes the diﬃculties of bidirectional model synchronization. Even worse, when using multiple target models representing diﬀerent concerns of a managed system, adaptations are more challenging, since changes can be applied concurrently to diﬀerent target models. Conﬂicting changes can lead to an inconsistent source model and managed system. Consequently, coordination among managing systems is required, which can be done by restricting adaptations to one target model and controlling access to this model. However, we believe that adaptations can be speciﬁc for a certain concern and therefore for a certain target model. Thus, restricting adaptation to exactly one target model would not be appropriate, and a more generic solution addressing relationships, like dependencies, interactions, or trade-oﬀs between diﬀerent target models, respectively their concerns, would be required. Such relationships could be used, among others, to coordinate changes and to validate changes of one target model by analyzing the impact of this change to other target models.

138

T. Vogel et al.

As future work, we are currently investigating the usage of model synchronization techniques for architectural adaptations using one target model and then, to enable adaptations using multiple target models. Moreover, extending our approach to a distributed setting is considered.

References 1. Cheng, B., de Lemos, R., Giese, H., Inverardi, P., Magee, J., et al.: Software Engineering for Self-Adaptive Systems: A Research Road Map. Number 08031 in Dagstuhl Seminar Proceedings (2008) 2. Kephart, J.O., Chess, D.M.: The Vision of Autonomic Computing. IEEE Computer 36(1), 41–50 (2003) 3. Kramer, J., Magee, J.: Self-Managed Systems: an Architectural Challenge. In: Proc. of the Workshop on Future of Software Engineering, pp. 259–268. IEEE, Los Alamitos (2007) 4. France, R., Rumpe, B.: Model-driven Development of Complex Software: A Research Roadmap. In: Proc. of the Workshop on Future of Software Engineering, pp. 37–54. IEEE, Los Alamitos (2007) 5. Blair, G., Bencomo, N., France, R.B.: [email protected]. Computer 42(10), 22–27 (2009) 6. Vogel, T., Neumann, S., Hildebrandt, S., Giese, H., Becker, B.: Model-Driven Architectural Monitoring and Adaptation for Autonomic Systems. In: Proc. of the 6th Intl. Conference on Autonomic Computing and Communications, pp. 67–68. ACM, New York (2009) 7. Giese, H., Wagner, R.: From Model Transformation to Incremental Bidirectional Model Synchronization. Software and Systems Modeling 8(1) (2009) 8. Giese, H., Hildebrandt, S.: Incremental Model Synchronization for Multiple Updates. In: Proc. of the 3rd Intl. Workshop on Graph and Model Transformation. ACM, New York (2008) 9. Bruhn, J., Niklaus, C., Vogel, T., Wirtz, G.: Comprehensive support for management of Enterprise Applications. In: Proc. of the 6th ACS/IEEE Intl. Conference on Computer Systems and Applications, pp. 755–762. IEEE, Los Alamitos (2008) 10. DeMichiel, L., Keith, M.: JSR 220: Enterprise JavaBeans, Version 3.0: EJB Core Contracts and Requirements (2006) 11. Hrasna, H.: JSR 77: Java 2 Platform, Enterprise Edition Management Speciﬁcation (2006) 12. Garlan, D., Schmerl, B., Chang, J.: Using Gauges for Architecture-Based Monitoring and Adaptation. In: Proc. of the Working Conference on Complex and Dynamic Systems Architecture (2001) 13. Hein, C., Ritter, T., Wagner, M.: System Monitoring using Constraint Checking as part of Model Based System Management. In: Proc. of the 2nd Intl. Workshop on [email protected] (2007) 14. Dubus, J., Merle, P.: Applying OMG D&C Speciﬁcation and ECA Rules for Autonomous Distributed Component-based Systems. In: Proc. of the 1st Intl. Workshop on [email protected] (2006) 15. Morin, B., Barais, O., J´ez´equel, J.M.: K@RT: An Aspect-Oriented and ModelOriented Framework for Dynamic Software Product Lines. In: Proc. of the 3rd Intl. Workshop on [email protected], pp. 127–136 (2008)

Incremental Model Synchronization for Eﬃcient Run-Time Monitoring

139

16. Morin, B., Barais, O., J´ez´equel, J.M., Fleurey, F., Solberg, A.: [email protected] to Support Dynamic Adaptation. Computer 42(10), 44–51 (2009) 17. Song, H., Xiong, Y., Hu, Z., Huang, G., Mei, H.: A Model-Driven Framework for Constructing Runtime Architecture Infrastructures. Technical Report GRACETR-2008-05, GRACE Center, National Institute of Informatics, Japan (2008) 18. OMG: MOF QVT Final Adopted Speciﬁcation, OMG Document ptc/05-11-01 19. Jouault, F., Allilaire, F., B´ezivin, J., Kurtev, I.: ATL: A Model Transformation Tool. Science of Computer Programming 72(1-2), 31–39 (2008) 20. Giese, H., Hildebrandt, S.: Eﬃcient Model Synchronization of Large-Scale Models. Technical report, No. 28, Hasso Plattner Institute, University of Potsdam (2009) 21. Hettel, T., Lawley, M.J., Raymond, K.: Model Synchronisation: Deﬁnitions for Round-Trip Engineering. In: Vallecillo, A., Gray, J., Pierantonio, A. (eds.) ICMT 2008. LNCS, vol. 5063, pp. 31–45. Springer, Heidelberg (2008)

Generating Synchronization Engines between Running Systems and Their Model-Based Views Hui Song1 , Yingfei Xiong1,2 , Franck Chauvel1 , Gang Huang1, , Zhenjiang Hu3 , and Hong Mei1 1

Key Laboratory of High Confidence Software Technologies (Ministry of Education) Peking University, Beijing, China {songhui06,franck.chauvel,huanggang,meih}@sei.pku.edu.cn 2 Department of Mathematical Informatics, University of Tokyo, Tokyo, Japan [email protected] 3 GRACE Center, National Institute of Informatics, Tokyo, Japan [email protected]

Abstract. The key point to leverage model-based techniques on runtime system management is to ensure the correct synchronization between the running system and its model-based view. In this paper, we present a generative approach, and the supporting tool, to make systematic the development of synchronization engines between running systems and models. We require developers to specify “what kinds of elements to manage” as a MOF meta-model and “how to manipulate those elements using the system’s management API” as a so-called access model. From these two specifications, our SM@RT tool automatically generates the synchronization engine to reflect the running system as a MOF-compliant model. We have applied this approach on several practical systems, including the JOnAS JEE server.

1

Introduction

The increasing need of continuously available systems (IT systems, e-business, or critical systems) requires to perform management activities such as conﬁguration, evolution or corrective maintenance at runtime. Management activities (automated or not) are build on a loop [1]: monitoring the running system, analyzing the collected data, planning the needed reconﬁgurations, and executing those reconﬁgurations. For monitoring and execution, existing platforms such as JEE [2], Fractal [3], and Android [4] provide adequate facilities through devoted APIs, such as the JMX API [5] for JEE systems. For analysis and planning, researchers proposed many generic approaches, utilizing model-based techniques like architecture styles [6, 7], model checking [1], modelbased self-repair [8], or model-based artiﬁcial intelligence [9], etc. The key-point to leverage model-based analysis and planning at runtime is to obtain a model-based view of a running system and to ensure the proper synchronization between the system and its model-based view.

Corresponding author.

S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 140–154, 2010. c Springer-Verlag Berlin Heidelberg 2010

Generating Synchronization Engines

141

However, despite their importance, such synchronization engines are still hand-crafted in a tedious and error-prone manner. Existing approaches [7,10,8,11] include hand-written synchronization engines. To do so, developers have to care about how to maintain a model, how to manipulate the system through the management API, and how to propagate the changes between model and system to ensure their consistency. All these functionalities have to be considered simultaneously. The contribution of this paper is to make systematic the development of such synchronization engines between models and running systems. Our approach reﬂects a simple model-driven process: For a speciﬁc system, we require the developers to specify what elements can be managed, and how to manipulate them through the management API. From these two speciﬁcations, our approach automatically generates a synchronization engine that maintains a dynamic MOF-compliant model for the running system. This enables the standard model-based techniques (like OCL and QVT) to be used for runtime management. We implement this approach as a tool named SM@RT 1 , and apply it on several practical systems. The rest of this paper is organized as follows. Section 2 illustrates the diﬃculty for developing a synchronization engine by hand whereas Section 3 presents an overview of our generation process. Section 4 and Section 5 explain how developers specify the system and how to generate the synchronization engine. Section 6 describes and discusses our case studies. Finally, Section 7 presents some related approaches and Section 8 concludes the paper.

2

Motivating Example

This section illustrates the complexity of developing a synchronization engine (SE) between a running systems and its model view. We choose the JOnAS [12] JEE application server as a running example. A JOnAS server contains a lot of manageable elements such as EJBs, data sources (proxies to databases), etc. Each data source maintains a pool of connections to the underlying database. If the number of cached connections tends to reach the capacity of the connection pool, the database access may be delayed and the pool capacity must be enlarged. In the same manner, if the number of cached connections is always zero, the data source can be removed to release resources. JOnAS provides an interface (the JMX [5] management API) for the monitor and execution of manageable elements. But complex analysis and planning must still be performed by hand or by using external tools. Model-driven techniques and tools can help such analysis and control tasks. Take the above management scenario as an example, the administrators could use a model visualization tool (like GMF [13]) to help better understand the system, or use OCL constraints to automatically verify the server reconﬁguration. Like other model-based technologies, GMF and OCL can only be applied on MOF-compliant models (as shown in Figure 1), which are constituted by 1

“SM@RT” for Supporting Models at Run-Time: http://code.google.com/p/smatrt

142

H. Song et al.

standard model elements. But the JMX API represents the running system as a speciﬁc kind of Java objects, the Managed Beans (MBeans). The integration of model-based techniques thus requires an SE which reﬂects the running system into a MOF-compliant model, and ensures a bidirectional consistency between the system and the model. For instance, in our JEE scenario, the SE must build a model element for each data source on the JEE AS. When the management agent deletes a model element, the SE must detect this change, identify which data source this removed element represents, and ﬁnally invoke the JMX API to remove this data source. MOF-Compliant Model jps: EntityBean

Running System

:JOnAS Modify jdbc DataSource

dataSource hsql : JDBCSource

mysql : JDBCSource

current = 45 capacity = 50

current = 0 capacity = 50

Monitor

Synchronization Engine Monitor

Java Pet Store Application

HSQL

JOnAS Server MySQL

Modify Business Logics

Storage

Fig. 1. A common structure of the synchronization engines

However, such an SE employs a complex mechanism and its development is therefore time consuming and error-prone. For the above scenario, the SE has to perform many functionalities: reading and writing models, monitoring and executing system changes, maintaining the mapping between model elements and system elements, handling conﬂicts between changes, and planning the proper subsequent changes to keep the model and system consistent. In addition, SEs share many commonalities, and developing the SE from scratch is a waste of time and labor. Actually, except for monitoring and executing system changes, all the other functionalities are independent to any speciﬁc systems, and thus it is possible to achieve common solutions for them.

3

Approach Overview

We provide a generative approach to assist the development of synchronization engines. As shown in Figure 2, the inputs of our approach include a system metamodel specifying what kinds of elements can be managed and an Access Model specifying how to use the API to monitor and modify those manageable elements. Our SM@RT tool generates a SE which reﬂects automatically the running system into a MOF-compliant model that conforms to the system meta-model. Our approach is applicable under the following conditions. First, we require the target system to provide a management API: our tool does not instrument non-manageable systems, nor extends inadequate APIs. Second, we reﬂect a direct model for the system (that means the model is homogeneous with the

Generating Synchronization Engines

SM@RT GENERATOR generate Synchronization Engine

Management API

Integration With

conforms to

Running System (JEE, Fractal, Android)

Existing Model-based Techniques (Analysis, Tranforfmation, etc)

Access Model (How to manage it?)

MOF-based Model (of the Running System)

System Meta-model (What to manage?)

143

Scope of the article

Fig. 2. Generation of Synchronization Engine: Approach Overview

system structure: each model element stands for one system element). If an abstract model is needed, a model transformation could be used to transform the abstract model to a direct model. Synchronisation with abstract models are considered beyond the scope of this paper.

4

Modeling Management APIs

In order to generate an SE for a speciﬁc system, we need to know what can be managed in this system, and how to manage it. In this section, we present how to specify these two kinds of information as models. 4.1

Modeling “What Can Be Managed”

According to Sicard et al. [8], a manageable running system is constituted of managed elements (like the JEE server and data sources). Managed elements have local states (like the pool sizes of data sources). They could be composed by other managed elements (a root JEE server contains several EJBs), and they could have connections between each other (an EJB requires data from a data source). These concepts can be described using the concepts of eMOF metamodels, as shown in Table 1. Following the above guidance, developers can specify the types of managed elements as an eMOF meta-model, and we refer to it as a “system meta-model”. For Table 1. Concept mapping concepts of system structure Element type Local state Composition Connection

concepts of MOF Model Class Attribute Aggregation Association

144

H. Song et al.

Fig. 3. The system meta-model of the JEE example

example, Figure 3 is an excerpt of the system meta-model we deﬁned for JOnAS. The three classes specify the three types of managed elements. JDBCDataSource has two attributes representing the currently opened connections and the maximal pool sizes. JOnASServer have aggregations with the other classes. EntityBean have association with JDBCDataSource. Note that we only showed the necessary part for explaining our sample scenario, and the actual meta-model contains many other classes and properties, as shown in Section 6. 4.2

Modeling “How to Manage the Systems”

The manageable elements can be manipulated through the management API. For example, we can use the getAttribute method of JMX to fetch the current opened connections of a data source. For a system, we require developers to specify how to invoke its management API to manipulate each type of elements, and we name this as an “access model”. More formally, the access model is a partial function: access : M etaElement × M anipulation −→ Code where M etaElement is the set of all the elements in the system meta-model (classes, attributes, etc.), M anipulation is the set of all types of manipulations, which are summarized in Table 2, and Code is a piece of Java code. Figure 4 shows two sample items in the access model for JOnAS. The ﬁrst item deﬁnes the common code for getting the values of int-typed attributes. We obtain an instance of an MEJB remote element (Line 4), and the logic is deﬁned as an Auxiliary operation. Then we invoke the getAttribute method. The ﬁrst parameter is the reference to the current management element. The second parameter is the property name. The second sample is used to add a new data source into a server, or “loading a data source according to a speciﬁc name” in the JEE language. We ﬁrst ﬁnd the model element added by management agents, and get the data source name (Line 11) from this element. Finally we use this name to invoke the loadDataSource operation (Lines 12-15). When deﬁning how to manipulate the systems, developers may need the following kinds of information: They need system information like “what is the current system element” (Line 5); They need system type information, like the property name, (Line 5). They also need the information inputted by the external management agent, like the appointed name for the to-be-created data source (Line 11), and such information is preserved in the corresponding model

Generating Synchronization Engines

145

Table 2. All kinds of manipulations. For each kind of operation, we list its name, the types of meta elements it could be applied, the parameters it requires for execution, and a brief description. In the table, Property standards for attribute, aggregation and association. The “1” or “*” marks following them means single-valued or multi-valued properties, respectively. The Auxiliarys are common operations defined by users, and can be used during the definition of code, as shown in the example. name Get Set List Add Remove Lookfor Identify Auxiliary

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

meta element Property (1) Property (1) Property (*) Property (*) Property (*) Class Class Package

parameter newValue toAdd toRemove condition other -

description get the value of the property set the property as newValue get a list of values of this property add toAdd into the value list of this property remove toRemove from the list of this property find an element according to condition check if this element equals to other user-defined auxiliary operations

// Sample 1 , get the value for any kind of attributes MetaElement= AnyClass :: AnyIntTypedSingleValuedAttribute , Manipulation = Get , Code=BEGIN Management mgmt = $sys :: auxiliary . getMainEntry (); Integer res =( Integer ) mgmt . getAttribute ( $sys :: t h i s , $meta :: prpt_name ); $sys :: result = rest . intValue (); END // Sample 2 , add a new data source MetaElement= JOnASServer :: jdbcDataSource , Manipulation = Add Code: BEGIN String dbName = $model :: newAdded . name ; Object [] para = { dbName , Boolean . TRUE }; String [] sig = { " java . lang . String " ," java . lang . Boolean " }; Management mgmt = $model :: auxiliary . getMainEntry (); $sys :: newAdded =( ObjectName ) mgmt . invoke ( dbserver , " loadDataSource " , para , sig ); END

Fig. 4. Invoking JMX interface

element. We deﬁned three kinds of specification variables, the system, meta and model variables, to stand for the above three kinds of information, in order to keep developers from the details about the generation and the SE.

5

Generating the Synchronization Engine

This section presents the SEs we generated to maintain the causal links between model and system. We ﬁrst explain how the generated SEs work, and then introduce how we generate the engines.

146

5.1

H. Song et al.

The Synchronization Engine

The ﬁrst question for a synchronization mechanism is “when and where to synchronize”. Since the model is the interaction point between the system and the management agent (MA), the synchronization should be triggered before MA read the model and after they write the model. In addition, for each reading or writing, the MA only cares about parts of the model. And thus, we only synchronize the involved part of the model with the running system. Figure 5 shows the structure of our SE, implementing the on-demand synchronization approach we discussed before. The model we provide is in an in-memory form conforming with Ecore [13]. Each model element is represented by a Java object in the type of EObject. External management agents read or write this model by invoking the standard get or set methods on these model elements. The Model Listener listens to these model operations. For a reading operation, the listener interrupts the operation, asks the planner to perform the synchronization, and ﬁnally resumes the original operation with the refreshed model. For a writing operation, it waits until the operation is ﬁnished, and asks the planner to synchronize this modiﬁed model with the system. The Mapping pool maintains a one-to-one mapping between the model elements and the system elements, as a reference for the synchronization. This mapping is implemented as a hash map between model elements and the references to the system elements, and is dynamically maintained as the model and system evolves. The Model and System proxies are used to read the current model and system, and write the required changes (i.e. the synchronization result) back. The model proxy is implemented by invoking the standard get or set methods on the model elements, while the system proxy is implemented by the API invocations speciﬁed in the access model. The Exception Catcher implements a simple conﬂict handling strategy, i.e. when a conﬂict causes failures during the model or system manipulation, it catches the thrown exceptions and warns the management agent. Developers could implement more sophisticated strategies by deﬁning complex code in the access model, but currently we do not provide special support on that. Based on these auxiliary parts, the central Planner execute a set of synchronization strategies: SynchStrategy : M odOp × M OF Elem → (M odOp SysOp M apOp)∗ Each strategy deﬁnes that when a speciﬁc kind of model operations (get, set, etc.) happened on a speciﬁc part of the model (model elements, single-valued attributes, etc.), the engine will execute a sequence of operations. These operations manipulate the model, the system, and the mapping pool, in order to make them consistent.

4

Planner

3

3

147

Running Systtem

6

Mgmt API

2

Exception catcher System prox S xy

Mo odel liste ener

Mapping pool

1 Mo odel pro oxy

In-m memory mo odel

Generating Synchronization Engines

Fig. 5. Structure of the generated SE

ModOp : Get MOFElem: Aggregation(upper-bond>1) Parameter: mself : the current model element pname: the name of the aggregation sself ← ImagePool.getSys(mself ) schildren ← sList (sself , pname) foreach schild ∈ schildren do if ImagePool.getModel(schild) = Null then mclass ← GetClass (mself .class,pname,self ) mchild ← mCreate (mclass, mself , child) ImagePool.put(mchild, schild) end else mchild ← ImagePool.getModel(schild) end mAdd (mself , pname, mchild) end

Algorithm 1. Sync strategy for getting multi-valued aggregations Algorithm 1 illustrates one of the synchronization strategies2 we have deﬁned and hard-coded inside the planner. This strategy is corresponding to the “Get” operations on the multi-valued aggregations in the model. The variable starting with “m” are elements from the model while the ones starting with “s” are elements in the system. Similarly, the functions starting with “m” (like mCreate) are standard model manipulations executed through the model proxy, while the ones with “s” are the manipulations on systems executed throught the system proxy, which are exactly the ones deﬁned in the access model (see Table 2). When informed by the model listener that someone wants to get the children of a model element mself , the planner ﬁrst gets the corresponding system elements sself , and then gets the children of this sself . For each of the obtained children 2

Strictly speaking, such strategies are not “algorithms”, because they do not have inputs and outputs: They just tell the planner what to do on a model operation.

148

H. Song et al.

Mgmt Agent

Model Listener

Model Proxy

Planner

Image Pool

System Proxy

get() sync() lookup() get_data() get_data() set_data() set_data() refresh() end_sync get_data return_get

Fig. 6. The collaboration inside an generation engine

schildren, it creates a new model element as its image, and refresh the model with these images as the original mself ’s children. Figure 6 illustrates how the parts inside an SE work together. We do not show the “Exception Catcher” here because it only appears when this sequence fails. For the JOnAS sample, in the beginning, the model contains only one element standing for the JOnAS server. The management agent invokes get method on this root element to see its data sources. The model listener interrupts this get operation, and informs the planner. Follow the synchronization strategy for get operations on multi-valued aggregations, the planner performs the following operations: It ﬁrst checks the mapping pool to see that root stands for the JOnAS server, and then invokes list on this server (See Table 2), which returns a set of ObjectNames pointing to the current data sources. The planner then invokes the create operation on the model proxy to create a new model element for each of these data sources, and refreshes the mapping pool for these new model elements. Finally, the original get operation continues, and returns a set of newly created model elements. 5.2

The Generation Tool for the Synchronization Engines

Our SM@RT tool automatically generates the above SEs. The tool has two parts, a common library and a code generation engine. The common library implements the mapping pool, the exception catcher, and the planner, with the synchronization strategies hard-coded inside. The code generation engine is an extension of the Eclipse Modeling Framework (EMF), and it generates the model listener, model proxy, and system proxy speciﬁc to the target system. Speciﬁcally,

Generating Synchronization Engines

149

it generates a Java class for each of the MOF classes in the system meta-model, implementing the EObject interface deﬁned by Ecore. Then it overrides the model processing methods in EObject, inserting the logic for listening operations and launching the synchronization planner. Finally, it wraps the pieces of API invocation code in the access model into a set of system manipulation methods, which constitutes the system proxy.

6

Case Studies

We applied our SM@RT tool to generate SEs for several practical systems, and performed several runtime management scenarios on these models, utilizing existing MOF-based model-driven techniques. 6.1

Reflecting JOnAS JEE Systems

Our ﬁrst case study is the full version of the running example we used before. We reﬂect all the 21 kinds of JEE manageable elements (including applications, EJBs, data sources, transaction services, etc.) as a MOF-compliant model, and visualize it to provide a graphical management tool for JOnAS administrators. We ﬁrst deﬁne the system meta-model and the access model for JOnAS as explained in the previous sections. The resulting system meta-model contains 26 classes, 249 attributes, 21 aggregations and 9 associations. The resulting access model deﬁnes 28 pieces of code like the sample in Figure 4. From the system meta-model and the access model, the SM@RT tool automatically generates the SE for JOnAS as a Java library. We connected this library with GMF to visualize the reﬂected model (just in the same way as visualizing any common Ecore models), as shown in Figure 7. In this snapshot, the rectangles stand for the JOnAS manageable elements and the lines stand for the association between these elements. From this diagram, we see that there are two applications running on the pku server, which runs on one JVM, and contains several resources, including a data source named HSQL1. We select the data source, and the property view on the right side shows its attribute values. All the elements, associations and attributes depict the current system state. That means if we select this model element again (that causes GMF to refresh the attributes), some attribute values may change, and if we select the canvas (that causes GMF to refresh the root element), some elements may disappear and new elements may appear. We can also directly use this diagram to change the system. For example, if we increase the JDBCMaxConnPool from 100 to 200, the underlying pool will be enlarged consequently. If we create a new model element in the type of J2EE Application, and set its fileName attribute as the address of an EAR ﬁle, the synchronization engine deploys this EAR ﬁle into the system, and some new model elements will appear in the diagram, standing for the modules and EJBs inside this newly-added application. We use the following two experiments to demonstrate that the generated SE reﬂects a valid and useful runtime model for the JEE system.

150

H. Song et al.

Fig. 7. A snapshot of the visualized model of JOnAS

The ﬁrst experiment is about monitoring and altering attribute values of system elements. We wrote an automated script to continuously request the SignOn component. When executing this script, we noticed that the currentOpened connections of HSQL1 was also growing, until it reaches 50, the value of the jdbcMaxConn. That means the data source’s connection pool is full. Then we change the jdbcMaxConn to 100, and the currentOpened began to grow immediately. That means the database’s maximal pool size has been successfully enlarged. After that we set Max Pool to 20000, but after synchronization, this value becomes 9999 (the upper limit of connection pool supported by this version of HSQL), and we receive a warning. Our second experiment is about changing the structure of system elements. We choose a typical scenario to add RSS (Really Simple Syndication) capability into JPS at runtime to support subscription of pet information. We added a StatelessSessionBean into the diagram, which organizes the pet information as products (a product represents a pet breed [14]). We also add a WebModule for formatting the data as an RSS seed. We implemented the EJB and the web module, packaged them as Jar and War ﬁles, and set the paths of these ﬁle as the fileName attributes of the new added model elements. Then we connected them with the pku J2EE server, and connect these components together. After that, we got the RSS seed using a browser with item information. That means the components have been deployed into the server by our SE. 6.2

Other Case Studies

Table 3 summarizes all the case studies we have undertaken. For each case, we give the target system and its management API, the number of elements in the system meta-model, the items in the access model and the total lines of code in these items. After that, we list the sizes of the generated synchronization engines.

Generating Synchronization Engines

151

Table 3. Summary of experiments target system JOnAS Java classes Eclipse GUI Android

API

m-model access model generated contrast techs (elements) (items) (LOC) (LOC) (LOC) JMX 305 28 310 18263 5294 GMF BCEL 29 13 124 10518 3108 UML2 SWT 43 23 178 11290 EMF Android 29 9 67 8732 OCL

For the ﬁrst two cases, we also list the size of the hand-written synchronization engines for comparison. Finally, we list the model-driven techniques we applied upon the generated SEs. The second case is a reproduction of the Jar2UML tool3 , which reﬂects the class structure in a Jar ﬁle as a UML model. We utilized the UML meta-model (deﬁned by Eclipse UML24 ) as our system meta-model, and deﬁned an access model, wrapping the invocation to BCEL library5 for analyzing Java binary code. We used Eclipse UML2 tools to visualize the reﬂected UML model as a class diagram. The third case is an illustrative example. We wrapped the management functions of SWT (the GUI system of Eclipse), and used the tree-based model editor to achieve dynamic conﬁguration of an Eclipse window, like changing a button’s caption or a label’s background color. A step-by-step presentation of this case study can be found in a tutorial on our project web-site. Our fourth case is to reﬂect the packages in an Android6 system as a model. We wrote a simple extended OCL rule (we extend OCL to support value assignment, as presented in our previous work [15]) stating that when there is no Wi-Fi service, the Wi-Fi based packages should be stopped. We successfully deployed the generated adapter into an HTC G2 mobile phone, along with the extended OCL interpreter. The rule works well: When the phone is out of the Wi-Fi range, the packages are stopped. 6.3

Discussion

Feasibility: The case studies above illustrate the feasibility of our approach: it generates SEs for a wide range of systems, and the generated SEs enable existing model-driven techniques for runtime management. Generation Benefits: Our generation approach improves the development eﬃciency of SEs. Among the complex functionalities of SEs (see Section 2), we only require developers to care about the monitoring and controlling of the system. Speciﬁcally, we reduce 94.1% hand-written code for the JOnAS case (310 vs. 5294 LOC), and 98% for the Java case (62 vs. 3108 LOC). 3 4 5 6

http://ssel.vub.ac.be/ssel/research/mdd/jar2uml, a use case of MoDisco [11] http://www.eclipse.org/uml2 Byte Code Engineering Library, http://jakarta.apache.org/bcel/ http://www.android.com

152

H. Song et al.

Synchronization Performance: The performance of the generated SE is acceptable for human-based management. For the JOnAS case, we deploy the JOnAS server and the synchronization engine on a personal computer with 3.0GHz CPU and 2.0GB memory. We spend 3.17 seconds in average to show the diagram shown in Figure 7, with 98 manageable elements in total, and we spend less than one second to refresh an element or change an attribute. The performance is similar to the default web-based management tool, the JOnAS Admin. For the Android case, we spend 1.7 seconds to perform the OCL adaptation rule.

7

Related Work

Many researchers are interested on model-based runtime management. The representative approaches include “runtime software architecture” [6, 16], “models at runtime” [17], etc. Currently, these approaches focus on the problems and ideas of model-based management, and implement their ideas on speciﬁc systems and models. By contrast, we focus on the reﬂection of models for diﬀerent systems, and provide automated support. Some researchers also focus on reﬂecting diﬀerent systems into standard models. Sicard et al. [8] employ “wrappers” to reﬂect systems states into Fractal models. Researchers of MoDisco Project [11] focus on developing “discoverers” to discover MOF-compliant models from systems. The “wrappers” and “discoverers” are similar to our SEs, but our work supports developers in constructing SEs from a higher level, not by directly writing code in ordinary programming language. Another major diﬀerence between our work and MoDisco is that our SEs support writing the model changes back to the system. Currently, many approaches employ many diﬀerent mechanisms to maintain the causal connections between models and running systems. First, some early approaches require the target systems to be developed under some speciﬁc techniques which has built-in RSA support. For example, Oreizy et al. [6] require their target systems to developed under the Java-C2 class framework, and to use Fractal architecture at runtime [18], the system classes must implement some interfaces deﬁned by Fractal. This requirement limits their applicability in practice. Second, some approaches allow the target systems to be developed under industrial standards, but enhance their runtime platforms (middlewares) with RSA mechanisms. These approaches are also known as “reﬂective middleware”, and covers many mainstream component models, like OpenORB [19] for CORBA, and PKUAS [16] for JEE. The problem of these approaches is that their middlewares are still not widely adopted in practice. Third, some researchers try to inject probes and eﬀectors into existing systems to collect runtime data, organize them as model, and perform model modiﬁcations [7]. But since most existing systems are not designed for code-level evolution, injecting code into them, if possible, is usually tedious and unsafe. Our approach is close to the third type in that we also seek to provide a generic mechanism for existing systems, but we choose a more safe way, utilizing the low-level management APIs provided by the existing systems.

Generating Synchronization Engines

153

Our language for modeling management APIs shares the similar idea as the approaches towards feature-based code composition [20]. They allow developers to model code slices as features, and to compose or customize features at a highlevel. From the feature composition, their generator composes the code slices behind the features into an initial version of the program. Our synchronization mechanism is related to the approaches on model synchronization [21,22]. The diﬀerence is that these approaches use the same model processing interface to manipulate the two participants of synchronization, but we try to integrate ad hoc management APIs into the synchronization process.

8

Conclusion

To eﬃciently leverage the use of model-based techniques at runtime, it is necessary to have a model-based view of the running system. In this paper, we report our initial attempt towards the automated generation of synchronization engines that reﬂect running systems into model-based views. We require developer to specify “what to manage on the system” as a MOF meta-model, and speciﬁc “how to use the related API to do so” as an access model. From these speciﬁcations, we automatically generate the synchronization engine that reﬂects the system as a direct MOF compliant model. We have successfully applied our approach on several practical systems, and enabled several typical model-based techniques at runtime. As future work, we plan to give more support for developers to specify the running systems and their APIs. We also plan to perform further analysis such as model checking to ensure a deeper correctness and completeness of the generated causal link.

Acknowledgment This work is sponsored by the National Key Basic Research and Development Program of China (973) under Grant No. 2009CB320703; the National Natural Science Foundation of China under Grant No. 60821003, 60873060; the National S&T Major Project under Grant No. 2009ZX01043-002-002; and the EU FP7 under Grant No. 231167.

References 1. Kramer, J., Magee, J.: Self-Managed Systems: an Architectural Challenge. In: Future of Software Engineering (FOSE) in International Conference on Software Engineering, pp. 259–268 (2007) 2. Shannon, B.: Java Platform, Enterprise Edition 5, Specifications (April 2006) 3. Bruneton, E., Coupaye, T., Leclercq, M., Quema, V., Stefani, J.: The Fractal Component Model and its Support in Java. Software Practice and Experience 36(11-12), 1257–1284 (2006) 4. DiMarzio, J.: Android: A Programmers Guide. McGraw-Hill Osborne Media (2008) 5. Hanson, J.: Pro JMX: Java Management Extensions (2004)

154

H. Song et al.

6. Oreizy, P., Medvidovic, N., Taylor, R.N.: Architecture-based runtime software evolution. In: ICSE, pp. 177–186 (1998) 7. Garlan, D., Cheng, S., Huang, A., Schmerl, B.R., Steenkiste, P.: Rainbow: Architecture-based self-adaptation with reusable infrastructure. Computer 37(10), 46–54 (2004) 8. Sicard, S., Boyer, F., De Palma, N.: Using components for architecture-based management: the self-repair case. In: ICSE, pp. 101–110 (2008) 9. Chauvel, F., Barais, O., Borne, I., J´ez´equel, J.M.: Composition of qualitative adaptation policies. In: Automated Software Engineering Conference (ASE 2008), pp. 455–458 (2008) (Short paper) 10. Batista, T.V., Joolia, A., Coulson, G.: Managing dynamic reconfiguration in component-based systems. In: Morrison, R., Oquendo, F. (eds.) EWSA 2005. LNCS, vol. 3527, pp. 1–17. Springer, Heidelberg (2005) 11. MoDisco Project, http://www.eclipse.org/gmt/modisco/ 12. OW2 Consortium: JOnAS Project. Java Open Application Server (2008), http://jonas.objectweb.org 13. Budinsky, F., Brodsky, S., Merks, E.: Eclipse Modeling Framework. Pearson Education, project address (2003), http://www.eclipse.org/modeling/emf 14. Sun: Java PetStore (2002), http://java.sun.com/developer/releases/petstore/ 15. Song, H., Sun, Y., Zhou, L., Huang, G.: Towards instant automatic model refinement based on OCL. In: APSEC, pp. 167–174 (2007) 16. Huang, G., Mei, H., Yang, F.: Runtime recovery and manipulation of software architecture of component-based systems. Autom. Softw. Eng. 13(2), 257–281 (2006) 17. France, R., Rumpe, B.: Model-driven development of complex software: A research roadmap. In: Future of Software Engineering (FOSE) in ICSE 2007, pp. 37–54 (2007) 18. Bruneton, E., Coupaye, T., Leclercq, M., Quema, V., Stefani, J., Rhone-Alpes, I.: An Open Component Model and Its Support in Java. In: CBSE, pp. 7–22 (2004) 19. Blair, G., Coulson, G., Blair, L., Duran-Limon, H., Grace, P., Moreira, R., Parlavantzas, N.: Reflection, self-awareness and self-healing in OpenORB. In: Proceedings of the first workshop on Self-healing systems, pp. 9–14 (2002) 20. Antkiewicz, M., Czarnecki, K.: Framework-specific modeling languages with roundtrip engineering. In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 692–706. Springer, Heidelberg (2006) 21. Giese, H., Wagner, R.: Incremental model synchronization with triple graph grammars. In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 543–557. Springer, Heidelberg (2006) 22. Xiong, Y., Liu, D., Hu, Z., Zhao, H., Takeichi, M., Mei, H.: Towards automatic model synchronization from model transformations. In: ASE, pp. 164–173 (2007)

MoDeVVa Workshop Summary Levi L´ ucio1 and Stephan Weißleder2 1

Universidade Nova de Lisboa, Portugal [email protected] 2 Fraunhofer FIRST / HU Berlin, Germany [email protected]

The MoDeVVa workshop series is focused on model-driven engineering, veriﬁcation, and validation. Models are purposeful abstractions. They are used as a means to abstract unnecessary artifacts and to make complex systems easy to understand. Beyond their use as documentations, models can also be used for transformation or code generation. A formal foundation of models with ﬁxed semantics is necessary for the automatic processing of models. One application is the automatic generation of large parts of systems. This automation can result in a decrease of system engineering costs. Thus, the usage of models, model transformations, and code generation is becoming more and more important for industrial applications. As one of the most important representatives for the application of models, Model-Driven Engineering (MDE) is a development methodology that is based on models, meta models, and model transformations. There is already a lot of tool support for models, (domain-speciﬁc) modeling languages, model transformations, and code generation. The constant pace at which scientiﬁc and industrial development of MDE-related techniques moves forward shows that MDE is quickly changing and that new approaches and corresponding issues arise frequently. Most important, there is crucial need for veriﬁcation and validation (V&V) techniques in the context of MDE. Likewise, V&V is very important in many domains (e.g. automotive or avionics) and the use of MDE techniques in the context of V&V is an interesting topic. One prominent representative of this approach is model-based testing. The objective of the workshop on model-driven engineering, veriﬁcation and validation (MoDeVVa) in 2009 was to oﬀer a forum for researchers and practitioners who are working on V&V and MDE. The main goals of the workshop were to identify the mutual impact of MDE and V&V: How can MDE improve V&V and how can V&V leverage the techniques around MDE? Thus, we asked for submissions that target the areas – V&V techniques for MDE activities, e.g. V&V for model2model or model2text transformations – V&V at the level of the models: techniques for validating a model or generating test cases from models, including simulation, model-checking, modelbased testing, etc. – V&V at the level of metamodels: techniques for validating meta-models (languages) or for using meta-models to validate other artifacts S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 155–157, 2010. c Springer-Verlag Berlin Heidelberg 2010

156

L. L´ ucio and S. Weißleder

– The application of MDE to validation, testing and veriﬁcation – Impact analysis of (meta-)model changes on validation. What is the result of a change in a (meta-)model on the previous results of validation? – V&V techniques supporting reﬁnement, abstraction and structuring – Tools and automation – Case studies and experience reports In 2009, there were 21 submissions to MoDeVVa from 12 countries. In the review process, we chose 9 papers on mainly two topics: automatic transformations and veriﬁcation. In most cases, both techniques were in combination. For instance, UML diagrams or domain-speciﬁc modeling languages were transformed in to Alloy for model checking, model transformations were used to inﬂuence the coverage of test suites, or automatic test generation has been done solely based on the UML Testing Proﬁle and transformations expressed in QVT. More information about the program can be found at http://www.model-basedtesting.de/modevva09/program.html . We have realized that transformations are currently a very quickly developing topic. They are very often used for attributing semantics to a model for simulation, testing, execution or model checking. The veriﬁcation of the transformations themselves is a promising topic whose foundations are currently under development. Since both topics of MoDeVVa are interesting and actual topics, we also plan to organize the seventh edition of MoDeVVa in 2010. After the paper presentations, we also included a discussion session. Several questions were raised during this session that may point new directions for the future of necessary research. From those questions we retain the following: 1) What does it mean to generate a set of test cases from a model? 2) How can we be sure that a model has suﬃcient information to produce test cases? 3) How can we measure the interest or relevance of certain approaches to validating or verifying meta models, models, or code? The ﬁrst question poses a fundamental problem in terms of what it means to cover a test model. Can this be done in absolute terms, i.e. can we devise a universal informal or formal fashion of measuring coverage for any model? Can this be done for any speciﬁcation language or should we restrict ourselves to particular coverage criteria for particular speciﬁcation languages? The second question relates not only to the level of abstraction that we are considering, but also to information related to the adaptor / test driver between the test cases and the SUT. The third question is related to the previous, but in a more generic fashion. How can we measure the interest or relevance of certain approaches to validating or verifying meta models, models, or code? Many approaches, languages, tools and methodologies have been proposed, but the trend seems to be on keeping on proposing rather than evaluating. A possible answer to this question would be to apply in larger scale at the industrial level or let the questions from industry permeate into research in a more open fashion, i.e. to rethink the research questions in terms of what is demanded from industry. This may also mean that

MoDeVVa Workshop Summary

157

a step up from current research is needed in order to ﬁnd meta tools that will allow this research to take place. There were several practical lessons we have learned from the experience of organizing this workshop. Firstly we realized that our model for discussions at the end of the workshop was not optimal. We have suggested that the audience proposes topics and have then let the discussion on those topics be free, with minor moderation. This has resulted in a somewhat heterogeneous set of solutions, which was not simple to organize as a conclusion. A possibly more eﬃcient fashion of organizing these discussions is to moderate the discussion on order to reach a certain goal. We may let the participants deﬁne the questions, but these will have to be in the sense of that deﬁned goal. Also, we have burned CDs with the conference proceedings in order to distribute them to the participants in the workshop. Although this was appreciated, we had some remarks on publishing the proceedings directly online so discussions among participants could be prepared beforehand. We would like to thank all the authors for their contributions and high quality presentations. A big thank you also to the Program Committee for their help and advice while selecting the best contributions: Vasco Amaral, Paul Ammann, Benoit Baudry, Fabrice Bouquet, Ruth Breu, Didier Buchs, Gregor Engels, Alain Faivre, Sudipto Ghosh, Martin Gogolla, Mark Harman, Rob Hierons, Jochen Kuester, Bruno Legeard , Jeﬀ Oﬀutt, Alexander Pretschner, Markus Roggenbach, Ina Schieferdecker, Holger Schlingloﬀ, Germ´ an Vega and Elisangela Vieira. Finally we would like to especially thank Sudipto Ghosh for having helped us kicking oﬀ MoDeVVa with his keynote speech and Robert Binder for bringing in many interesting questions to the discussion session.

From UML to Alloy and Back Again Seyyed M.A. Shah, Kyriakos Anastasakis, and Behzad Bordbar School of Computer Science, The University of Birmingham, Edgbaston, B15 2TT, United Kingdom {szs,kxa,bxb}@cs.bham.ac.uk

Abstract. Model transformations can be used to bridge the gap between design and analysis technical spaces by creating tools that allow a model produced by a designer to be transformed to a model suitable for conducting automated analysis. Such model transformations aim at allowing the designer to benefit from the capabilities provided by analysis tools and languages. If the designer who is not a formal method expert is to benefit from such tools, the outcome of the analysis should also be transformed to the language used in the design domain. This paper presents a study involving UML2Alloy, a tool for transforming UML models in form of UML Class Diagrams which are augmented with OCL constraints, to Alloy. The conversion allows analysis of UML models via Alloy, to identify consistencies in those UML models. We present a method of automatically creating a model transformation based on the original UML2Alloy transformation. The new transformation converts Alloy instances into the UML equivalent Object Diagram. The current technique is presented with the help of an example, along with a prototype implementation using the QVT standard.

1

Introduction

Model Driven Architecture (MDA) [20] aims to promote the role of models and their manipulation via automated software engineering techniques. A notable feature of modelling in the MDA is the automated transformation of models via software tools, commonly known as model transformation [2, 17]. A typical model transformation consists of transformation rules which map the modelelements of the source language to the destination language. Modelling languages are represented as meta models and for a given model complying to the meta model of the source, the tool can execute the transformation rules resulting an equivalent model in the the destination language. Model transformation allows bridging the gap between technical spaces and domains [23, 13]. For example, MDD has been extensively used to allow analysis

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 158–171, 2010. c Springer-Verlag Berlin Heidelberg 2010

From UML to Alloy and Back Again

159

Fig. 1. Model Driven Development, conversion of UML2Alloy

of UML models by transferring UML models to formal languages, which in turn can be used for conducting various types of analysis [7, 19, 12, 4]. One of the motivations behind such approaches is to assist the designer who works with UML to beneﬁt from the advantages of other languages. For example, UML2Alloy [4] transforms models involving UML Class Diagram and OCL to the Alloy language. An outline of the Model Driven Architecture transformation UML2Alloy is given in Figure 1. Once a UML model is converted, Alloy [9] is used to analyse the model for identifying inconsistencies in the design. For example, in case that there is an inconsistency between various parts of the design, Alloy can produce a counterexample helping to reveal the source of inconsistency. Identifying such inconsistencies allows improving the design to produce better software at earlier stages of software development. UML2Alloy has been successfully applied to various domains including Agile Manufacturing [5], Security [8], and Access control [4]. To fulﬁl the vision of bridging the gap between design and analysis technical spaces, there is a clear need to transfer the outcome of the analysis back into the design space. In other words, a design model must be transformed to a language suitable for analysis, and after conducting analysis the result must be transformed back to the design space. Therefore the designer can both produce a model in the design space and receive the feedback of analysis in the design space. In case of UML2Alloy if a counter-example is found in analysis, it must be transferred to a UML Object Diagram. That Object Diagram is an instance of the Class Diagram in the design space and represents a violation of a property of the system. Otherwise, the developer must be an expert in two languages, in this case Alloy and UML. UML2Alloy has been shown to be a complex model transformation [4]. Deﬁning a transformation from Alloy to UML to carry the outcome of analysis conducted by Alloy to an Object Diagram has proved to be challenging too. Firstly, the transformations from UML to Alloy and from Alloy to UML are not independent. The transformation from instances of the Alloy models to UML must result in an instance of the original UML model, i.e. the created Object Diagram must comply to the Class Diagram. Secondly, the reader may think that a bi-directional [21] model transformation would solve the problem. This is not the case, as the second transformation is between the instances of the models

160

S.M.A. Shah, K. Anastasakis, and B. Bordbar

that are transformed by the original transformation from UML to Alloy. In other words, the ﬁrst transformation is carried out at the M2 layer of MOF [15] hierarchy while the second transformation is carried out at the M1 layer. In this paper we shall present a method for automatically generating the second transformation from the ﬁrst transformation, i.e. the second transformation which converts the Alloy instance models (analysis) to the original UML form is created automatically from the transformation that maps UML to Alloy models in the ﬁrst place. We use an oﬀ-the-shelf implementation of the Queries Views Transformations (QVT) [16] standard to implement the transformation generator, as well as for the generated transformation. This enables UML developers to harness the power of UML as well as the analytical support of Alloy, hence truly bridging the gap between the two domains. This paper is structured as follows, in the next section, relevant background information is given. Following this, we present the motivation for this work in Section 3. An outline of our solution with the help of an example and a prototype implementation are presented in Section 4. In Section 5, we present a case study where the the method is applied to a particular erroneous UML model. The paper concludes with a discussion of the solution and related work.

2 2.1

Background Alloy for the Analysis of UML Models

The Uniﬁed Modelling Language (UML) is widely accepted by the software engineering community as the de facto standard for the design, implementation and documentation of systems in industry. However, the UML is not intended to support analysis and reasoning of the models created using it. Analysing a model can be essential in identifying the design ﬂaws and removing them at earlier stages of the development process. For this purpose, a number of proposals have been developed that advocate the transformation of UML models to wellestablished formalisms for the purpose of analysis. In particular, Evans et al. [7] propose the use of Z [28] as the underlying semantics for UML. Snook and Butler [19] suggest the use of B [1], while Kim [12] transforms UML models to Object-Z, by deﬁning a mapping from a subset of the UML meta model to the Object-Z meta model. In [4], we advocate the formalisation of a subset of the UML, with the help of the Alloy language [9]. Alloy is an increasingly popular declarative textual modelling language based on ﬁrst-order relational logic. The Alloy language is supported by a tool, the Alloy Analyzer, which provides support for fully automated analysis of Alloy models, with the help of SAT solvers. Alloy has been used for analysing a wide number of protocols and systems [10, 11, 6]. Speciﬁcally, Jackson and Sullivan [10] have analysed COM architecture and Khurshid and Jackson [11] have analysed consistency of the International Naming Scheme (INS). Dennis et al. [6] have used Alloy to analyse a radiation therapy machine, exposing ﬂaws in the original design of the system.

From UML to Alloy and Back Again

161

The Alloy Analyzer tool provides the capability to simulate, check assertions and to debug a model. In simulation, the tool produces an instance of the model that conforms to the constraints of the system. To check if an assertion (i.e. a statement expressed in ﬁrst-order logic that captures a requirement) holds according to the speciﬁcation, the tool attempts to generate an instance that invalidates the assertion. To debug over-constrained models, the tool can identify which elements of the model speciﬁcation are hindering the generation of instances [18]. In order to automate the transformation from UML to Alloy, tool called UML2Alloy [4], has been developed which transforms a subset1 of UML Class Diagrams and OCL constraints into the Alloy language. UML2Alloy employs the SiTra Model Transformation framework to carry out the transformation. The tool works by transforming a UML Class Diagram with OCL constraints into the Alloy language and interfaces with the Alloy Analyzer, using the Alloy Analyzer API to automatically produce an instance, which conforms to the model. The method presented in this paper can be applied to produce UML Object Diagrams from the Alloy instances, such as counterexamples produced by the Alloy Analyzer. 2.2

UML Object Diagram Standard

Modelling standards (or speciﬁcations) such as MOF, EMOF [15], EDOC [14] are deﬁned for the creation of software as models. Models in such languages are expressed at diﬀerent layers, and layers are normally described by another layer. For example, in the MOF hierarchy there are four layers. At the highest layer (M3), MOF is deﬁned. One layer below M3 is UML language speciﬁcation; M2 is the UML meta-model. UML Models are created at the M1 layer to represent a system under development. In the UML standard, the M0 layer is used for run-time instantiations of a modelled system. In this paper, we use the M0 layer to represent instances of a M1 model. This is so we can create a model transformation at that level. A similar discussion on extending the layers relationship in UML is made in [26].

3

Description of the Problem

UML2Alloy is a tool to automatically analyse UML Class Diagrams with OCL constraints. This is achieved by deﬁning a mapping between the UML meta model and the Alloy meta model (w in Figure 2). The tool works by converting the UML model to an equivalent model in the Alloy language (x in Figure 2) and using the Alloy Analyzer API it carries out the analysis. Some analysis is produced in the form of Alloy instances, a form the user is not familiar with. Standards based tools support the UML language exclusively and are oftentimes used as an Integrated Development Environment. UML tools usually do 1

Details of the subset of UML employed can be found in [3], with details of the application to UML Class Diagrams and OCL.

162

S.M.A. Shah, K. Anastasakis, and B. Bordbar

w

x

y

z

Fig. 2. Multiple layers in UML2Alloy. Horizontal arrows represent transformation, vertical arrows show instance-of relationship.

not support analysis natively but could be used to view and modify analysis produced externally, where it is in standard UML form. Using UML2Alloy and a conversion of Alloy instances, the analysis could then be used as part of the normal development process. The key diﬃculty in converting Alloy instances, back to UML instances (z in Figure 2) is the inherent semantic diﬀerences between UML and Alloy. Instances in Alloy are not naturally instances of the originating UML model- some information is “lost in transformation”. An example of this semantic diﬀerence between UML and Alloy is where the attributes and associations of a UML model are converted to Alloy ﬁelds. Therefore, converting an Alloy instance back to an instance of the originating UML model would require knowledge of precisely how attributes and associations were converted to ﬁelds. Although it may be possible for hand conversion of instances to infer the mappings manually (via inspection) the process would be time consuming, tedious and error prone. The instances produced by Alloy could be both large and numerous, so not suitable to manual conversion. As a result there is a need to automate the conversion of Alloy instances into UML instances, we propose a model transformation be used for the conversion, z in Figure 2. As the meta models (UML Class Model and Alloy Model in Figure 2) can change, the model transformation between them should ideally be generated automatically, based on the UML2Alloy transformation. Another problem with manual conversion or even manually created model transformation is the accuracy of the conversion. In hand-converted models, misinterpretation of the original transformation may mean instances are converted incorrectly. Similarly, a manually created model transformation is prone to developer error, resulting in many wrongly converted instances of analysis. Our solution creates the analyses (instance) transformation automatically, based on the execution trace of the original UML2Alloy model transformation. This leads to a higher degree of conﬁdence that there is consistency between the two

From UML to Alloy and Back Again

163

Automated

1

UML Model

UML2Alloy 3

instance of

4

UML Instance

2

Alloy Model

Execution Trace

Analysis

Alloy Instance Converter

Alloy Instance

Fig. 3. Outline of the approach

transformations. A result of using model transformation throughout allows for an implementation in an MDA-compliant tool.

4

Outline of the Solution

Figure 3 depicts the enumerated steps of our solution to convert Alloy instances to UML instances. Figure 2 is related as follows, w is “UML2Alloy” and z is the instance converter “Alloy instance converter” of Figure 3. Our solution centres on an initial transformation in UML2Alloy, where given a UML model an Alloy model will be produced (Step 1 in Figure 3). The resulting Alloy model can be automatically analysed, with some of the analysis produced as Alloy instances (Step 2 in Figure 3). Using the trace of the ﬁrst UML2Alloy transformation, we create another model transformation (Step 3 in Figure 3). This second transformation is used on Alloy instances, to convert them to UML instances (Step 4 in Figure 3). Step 1: The ﬁrst transformation, UML2Alloy is executed on a UML model, to produce an Alloy Model and a transformation trace. The OCL constraints of the original model are converted to facts in Alloy logic, that act to constrain the resulting Alloy model. Step 2: In this step, UML2Alloy uses the Alloy Analyzer API to automatically analyse the Alloy model. Two general kinds of analysis can be performed to produce instances: simulation and assertion checking. Simulation produces an arbitrary instance, that conforms to the model constraints. Assertion checking will allow the user to verify a property of the model holds, with an instance produced (counter example) if the property does not hold. In either case the produces instances will be constrained by the facts of the Alloy model, which are based on the OCL constraints of the originating UML model.

164

S.M.A. Shah, K. Anastasakis, and B. Bordbar

(a) UML model

! ! " #$% & #

''!()

(b) Output of UML2Alloy, using (a)

(c) Alloy instance of (b) Fig. 4. Example UML model to Alloy, with instance

Step 3: The next stage is to create the Alloy to UML instance converter. We propose that such a conversion can be achieved using MDA techniques: by creating a transformation. We use the trace of the original UML to Alloy model transformation to create the second instance transformation. In eﬀect, the trace of the ﬁrst transformation (executed in Step 1) is used as the speciﬁcation of the second transformation (used in Step 4). Each trace instance, that has recorded a conversion in the ﬁrst transformation is converted to a rule of the second transformation. Further details of can be found in Section 4.2. Step 4: The second transformation (Step 4 in Figure 3) can be executed, converting Alloy instances to UML instances. The resulting instance can then be used in standard UML tool support. 4.1

Example

In this section we introduce an example UML model to illustrate the solution and use later to explain the implementation. Consider the UML Class Diagram with OCL constraints shown in Figure 4a. Using the model transformation UML2Alloy on this UML model, an Alloy model is produced shown in Figure 4b. For example, the UML Class “Person” is converted to the Alloy signature “Person” (line 1, Figure 4b). Class Attributes become Fields of the Signature, for example the “age” attribute of “Person” in UML becomes the “age” ﬁeld of the “Person” signature (line 2, Figure 4b). The navigable UML association between “Person” and “BankAccount” becomes the ﬁelds and facts on lines 3, 6, 8-11 in the Alloy model. The conversion of associations and attributes to ﬁelds highlights a major semantic diﬀerence between the formalisms, see section 3 for

From UML to Alloy and Back Again

165

further discussion. Finally the OCL constraint of the UML model is converted to the fact in the Alloy model (line 13-15). The Alloy model can be simulated using the Alloy Analyzer to produce one (often many more and larger) Alloy instances such Figure 4c. The UML2Alloy transformation produces a trace. So in the above example, a trace is created when Class “Person” is converted to sig “Person”. The trace of class to sig also refers to another trace, attribute “age” to ﬁeld “age”. Using this information, the transformation Trace2MT will create the instance transformation (Step 3 in Figure 3). Based on the trace, the ﬁrst rule created is PersonSig2PersonClass, which takes an instance of the “Person” signature in Alloy and converts it to an instance of the UML “Person” Class. PersonSig2PersonClass will be created to invoke another rule AgeField2AgeAttribute, which converts instances of the Alloy “age” ﬁeld to instances of the UML “age” attribute. The rest of the model transformation (Step 4 in Figure 3) is created by repeating the process for every trace (produced in Step 1, Figure 3). Once the transformation has been created, Alloy instances can be automatically converted to UML instances. 4.2

Implementation

In this section we present an MDA centric implementation of our solution (Step 3 in Figure 3), by creating a prototype model transformation. The main artefact of the implementation is created using the QVT [16] standard, created using SmartQVT [22]. Trace2MT (Step 3 in Figure 3) converts the trace of a ﬁrst transformation in UML2Alloy (Step 1 in Figure 3) into a second transformation that converts a given Alloy instance into a UML Object Diagram (Step 4 in Figure 3). In the implementation, the second generated transformation is also in the form of a QVT model transformation. The rules of Trace2MT are deﬁned between the trace meta model and the QVT Operational [16] meta model. The trace meta model is instrumental to this implementation, as it is the basis for the generated model transformation. We have deﬁned a trace meta model based on the need to generate transformation rules. The pertinent features of our trace meta model for this purpose are preservation of order of rule invocation as well as the hierarchy of rule invocation. Figure 5 depicts the trace meta model utilised in the implementation. The ITrace class of the meta model is instantiated once in an execution of the UML2Alloy transformation. The TraceInstance class is instantiated at rule

Fig. 5. Trace meta model

166

S.M.A. Shah, K. Anastasakis, and B. Bordbar

execution, whenever a UML element is converted to an Alloy element. The trace model records all transformation execution, including transformation of primitive types. The TraceInstance class records the source and destination value of a mapping. Where one rule invoked another rule, a link is also created between the two traces in TraceInstance. The information from the trace model is used to build the “Alloy instance converter” from Figure 3. The rules of the Trace2MT model transformation are: – itrace2operational: Top level rule, takes an ITrace model and creates an empty QVT operational transformation. – first2entryoperation: Creates the entry point of the resulting model transformation form the ﬁrst trace element. – traceinst2rule: Subsequent trace elements are converted to into QVT rules The rule “itrace2operational” invokes “ﬁrst2entryoperation” once and “traceinst2rule”. The rule “ﬁrst2entryoperation” converts the ﬁrst of the TraceInstance into the main entry point (EntryOperation from [16]) of the generated model transformation. The rule “traceinst2rule” is key to the transformation- it converts a given TraceInstace to a rule, a MappingOperation from the QVT meta model [16], in the generated transformation. The rules is invoked repeatedly, to convert each trace element to a rule of the generated model transformation. To create rules “traceinst2rule” takes a trace element and converts the source and destination of the trace to the source and destination types of the generated rule. The body of all the generated rule creates an instance of the destination type and copies the value of the source to that instance. Therefore, the models of the UML2Alloy transformation act as the meta-models of the generated transformation (shown in 2). And the instances of those models can be automatically converted by a transformation generated from the trace of the original UML2Alloy transformation.

5

Case Study

This presents a case study, using models in the previously presented example, depicted in Figure 4. In the example model, the OCL constraints is modiﬁed to create a bug in the deﬁnition. Furthermore another OCL constraint is added to model to be used in as an assertion in Alloy to check the model for errors. The assertion will be simulated by Alloy, and a counter example generated in Alloy if the model is incorrect. Using the technique presented in this paper, a model transformation is generated to automatically convert Alloy counter examples into UML form. The aim of this case study is to show how UML models can be automatically simulated using UML2Alloy and the Alloy Analyzer. Furthermore, the instances created by Alloy can be used by UML developers to uncover problems in the original model, using the presented technique. Although the inconsistency added here is synthetic such inconsistency problems can be introduced in normal the

From UML to Alloy and Back Again

(a) UML model

167

! ! " #$% & #

''!()

'*(+

(b) Output of UML2Alloy, using (a) Fig. 6. Case Study: Buggy UML model with equivalent Alloy model

16 : age

bankaccount : BankAccount 16 : age

person : Person

(a)

(b)

(c) Object Diagram of (a)

person1 : Person

bankaccount1 : BankAccount

16 : age

bankaccount0 : BankAccount

person0 : Person

(d) Object Diagram of (b)

Fig. 7. Case Study: Alloy instances produced automatically as counter examples to assertion in Alloy model from Figure 6b. Equivalent Object Diagrams produced automatically using trace of the original UML2Alloy transformation.

course of model development, through developer error. Bugs in software models are diﬃcult to detect by inspection alone, hence an automated method to uncovering model inconsistency is presented. Figure 6 shows the UML model with inconsistency, and the equivalent Alloy model. Note that the OCL constraint “ageAssertion” in the UML model is used in the Alloy model as an assertion. In Alloy assertions are properties of the model that should hold, but are not explicitly enforced when checking the assertion, thus allowing the validation of a models properties. In this example, the constraint OCL “customerAge” incorrectly constraints the model, as opposed to the OCL constraint “ageAssertion”. The Alloy model is created automatically by the UML2Alloy model transformation with the assertion selected in the tool. Alloy will show the assertion to be incorrect by means of instances. To check a given assertion holds, the Alloy Analyzer will search for counter examples. If no counter examples is found, the model is consistent otherwise the existence of a counter examples shows the assertion does not hold. In this example, several counter example instances are generated when checking the assertion. Two of these is shown in Figure 7, although many more could be created if required. Using the technique presented in this paper, a model transformation is generated to convert these counter example instances back to UML form, using the trace of the original UML2Alloy transformation in Figure 6. Figure 7 shows the counter examples in Alloy form and the equivalent UML form, produced using the automatically generated instance transformation. Notice that the semantic diﬀerence between the languages has been taken account of

168

S.M.A. Shah, K. Anastasakis, and B. Bordbar

automatically; the instance transformation is based on the original UML2Alloy transformation. For example, in Alloy a navigable Association must be represented by two ﬁelds, as seen in Figure 7a and 7b between BankAccount and Person instances. Using the trace of UML to Alloy model transformation, the instance transformation converts the two ﬁelds to the correct single Association in the equivalent Object Diagrams, shown in Figure 7a and 7b. Consequently the UML developer can from inspection of the UML instances recognise that the UML model is incorrect with respect to the assertion that no Person in this system should have an age of 16. In this case study, an error in a UML model was uncovered using UML2Alloy, Alloy and conversion of Alloy instances to UML instances. The UML instances showing inconsistency in the UML model can be inspected by a UML developer, without requiring training or experience in the Alloy formalism. Furthermore, such a technique encourages the use of OCL not only for the speciﬁcation of constraints but also for analysis, by speciﬁcation of assertions. Using the technique exempliﬁed in this case study, UML models can be simulated automatically using another language (Alloy), with the results presented in the original UML form.

6

Discussion and Related Work

In this paper we have presented a method to automatically generate the transformation rules to convert Alloy instances to UML Object Diagrams. This allows instances generated in analysis using Alloy to be transferred back to the UML domain. The presented method uses the trace of the UML2Alloy transformation to create rules for the transformation of instances. In our method, the outcome of analysis is presented is standard UML form, so it can be used in existing tool support. The trace is used to create the model transformation and this allows us to avoid the inherent diﬀerences between UML and Alloy and thus convert Alloy instance back to UML automatically. Using trace data to generate the transformation allows for a high degree of conﬁdence in the consistency of the converter. The generated transformation could be used to convert many, large complex Alloy instances back to UML form automatically. If the original UML model changes, UML2Alloy can be used to automatically create an equivalent Alloy model. Any previously created transformation of instances would no longer be valid, using the presented solution the transformation can be re-created automatically. We have presented an example of how this solution could be implemented in a MDA-compliant tool and using only model transformation. The main advantage of the presented technique is that UML models can be analysed using the Alloy language but without exposing the Alloy language because the results of analysis (as instances) are converted to UML automatically. In this paper we have presented a method to automatically convert instances from Alloy back to the original form in UML. We have considered this type of transformation form an MDA perspective, with aim of validating UML models.

From UML to Alloy and Back Again

169

It may be applicable outside the MDA sphere but this requires further investigation. Furthermore, there are shortcomings of this approach in the current form, there need for a hierarchy of abstraction levels in the both source and destination language. Also, the model transformation generated must be in a lower level than an original transformation. As well as this, we make use of a custom tracing meta-model, which must be used to preserve requisite details of the transformation. We have presented our solution in terms of UML2Alloy, further research is required to understand where the reverse transformation is appropriate for any given transformation. For example how and when to apply the technique in the validation of other UML diagrams. Within the MDA sphere, it is possible to speculate how the method could be applied to other model transformations. Consider the example transformation of a UML Class Diagram to a relational database schema (UML2RDB). In this transformations, rules are written at the UML meta model level, that deﬁne the mapping of classes, attributes and associations to tables, ﬁelds and foreign keys or link tables in the schema meta model. When the rules of UML2RDB are applied to a particular UML model, the transformation will produce an equivalent SQL schema. Using the presented technique, data stored in a database that implements the generated schema could be automatically converted back into UML. The data would be converted back to UML as Object Diagrams that are instances of the original UML Class Diagram. Such a transformation is untested in practice. The work presented in this paper can be related to several diﬀerent areas within model driven development, but only a few of those are particularly relevant to instance conversion for analysis. In [27, 24], discussion is on inferring model transformation rules using a manually created mapping between particular models i.e. model transformation rules from an example. The current approach diﬀers in that rules are created top-down from a higher to a lower level of abstraction and in using the trace of an existing model transformation. Also relevant to the work presented here is [25], who introduce the concept of metatransformation. We utilise meta-transformation where input or output of model transformation is model transformation in converting traces to model transformation. The work in [25] focuses on architectural, practical and conceptual issues of creating such transformations.

References [1] Abrial, J.-R.: The B-book: assigning programs to meanings. Cambridge University Press, New York (1996) [2] Akehurst, D., Bordbar, B., Evans, M.J., Howells, W.G.J., McDonald-Maier, K.D.: SiTra: Simple transformations in Java. In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 351–364. Springer, Heidelberg (2006), http://dblp.uni-trier.de/db/conf/models/ models2006.html#AkehurstBEHM06

170

S.M.A. Shah, K. Anastasakis, and B. Bordbar

[3] Anastasakis, K.: A Model Driven Approach for the Automated Analysis of UML Class Diagrams. PhD thesis, School of Computer Science, University of Birmingham UK (2009) [4] Anastasakis, K., Bordbar, B., Georg, G., Ray, I.: On Challenges of Model Transformation from UML to Alloy. In: Software and Systems Modeling, Special Issue on MoDELS 2007 (2009) (Accepted for publication subject to minor revisions) [5] Bordbar, B., Anastasakis, K.: UML2Alloy: A tool for lightweight modelling of Discrete Event Systems. In: Guimar˜ aes, N., Isa´ıas, P. (eds.) IADIS International Conference in Applied Computing 2005, Algarve, Portugal, February 2005, vol. 1, pp. 209–216. IADIS Press (2005) ISBN 972-99353-6-X [6] Dennis, G., Seater, R., Rayside, D., Jackson, D.: Automating commutativity analysis at the design level. In: ISSTA 2004: Proceedings of the 2004 ACM SIGSOFT international symposium on Software testing and analysis, pp. 165–174. ACM Press, New York (2004) [7] Evans, A., France, R., Grant, E.: Towards Formal Reasoning with UML Models. In: Proceedings of the OOPSLA 1999 Workshop on Behavioral Semantics (1999) [8] Georg, G., Ray, I., Anastasakis, K., Bordbar, B., Toahchoodee, M., Houmb, S.H.: An Aspect-Oriented Methodology for Developing Secure Applications. Information and Software Technology, Special Issue on Model Based Development for Secure Information Systems (Accepted for publication) [9] Jackson, D.: Software Abstractions: Logic, Language, and Analysis. The MIT Press, London (2006) [10] Jackson, D., Sullivan, K.: COM revisited:tool-assisted modelling of an architectural framework. In: 8th ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE), San Diego, CA (2000) [11] Khurshid, S., Jackson, D.: Exploring the design of an intentional naming scheme with an automatic constraint analyzer. In: ASE 2000: Proceedings of the 15th IEEE international conference on Automated software engineering, Washington, DC, USA, p. 13. IEEE Computer Society, Los Alamitos (2000) [12] Kim, S.-K.: A Metamodel-based Approach to Integrate Object-Oriented Graphical and Formal Specification Techniques. PhD thesis, University of Queensland, Brisbane, Australia (2002) [13] Kurtev, I., B´ezivin, J., Aksit, M.: Technological Spaces: an Initial Appraisal. In: CoopIS, DOA (2002) [14] OMG. enterprise distributed object computing (edoc), http://www.omg.org/technology/documents/formal/edoc.htm [15] OMG. Meta Object Facility (MOF) 2.0 Core Specification. OMG (2004), www.omg.org [16] OMG. MOF QVT Final Adopted Specification. Object Modeling Group (2007) [17] Rose, L.M., Paige, R.F., Kolovos, D.S., Polack, F.: The epsilon generation language. In: Schieferdecker, I., Hartman, A. (eds.) ECMDA-FA 2008. LNCS, vol. 5095, pp. 1–16. Springer, Heidelberg (2008) [18] Shlyakhter, I., Seater, R., Jackson, D., Sridharan, M., Taghdiri, M.: Debugging overconstrained declarative models using unsatisfiable cores. In: Proceedings of the 18th IEEE International Conference on Automated Software Engineering, Montreal, Canada, pp. 94–105. IEEE Computer Society, Los Alamitos (2003) [19] Snook, C., Butler, M.: Uml-b: Formal modelling and design aided by UML. ACM Transactions on Software Engineering and Methodology 15(1), 92–122 (2006) [20] Stahl, T., Voelter, M., Czarnecki, K.: Model-Driven Software Development: Technology, Engineering, Management. John Wiley & Sons, Chichester (2006)

From UML to Alloy and Back Again

171

[21] Stevens, P.: Bidirectional model transformations in QVT: Semantic issues and open questions. In: Engels, G., Opdyke, B., Schmidt, D.C., Weil, F. (eds.) MODELS 2007. LNCS, vol. 4735, pp. 1–15. Springer, Heidelberg (2007) [22] France Telecom. Smartqvt: An open source model transformation tool implementing the mof 2.0 qvt-operational language, http://smartqvt.elibel.tm.fr/ [23] OMG UML. 2.0 superstructure final adopted specification. OMG Document reference ptc/03-08, 2 (2003) [24] Varr´ o, D.: Model transformation by example. In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 410–424. Springer, Heidelberg (2006) [25] Varr´ o, D., Pataricza, A.: Generic and meta-transformations for model transformation engineering. In: Baar, T., Strohmeier, A., Moreira, A., Mellor, S.J. (eds.) UML 2004. LNCS, vol. 3273, pp. 290–304. Springer, Heidelberg (2004) [26] Varr´ o, D., Pataricza, A.: VPM: A visual, precise and multilevel metamodeling framework for describing mathematical domains and UML. Software and Systems Modeling 2(3), 187–210 (2003) [27] Wimmer, M., Strommer, M., Kargl, H., Kramler, G.: Towards model transformation generation by-example. In: HICSS 2007: Proceedings of the 40th Annual Hawaii International Conference on System Sciences, Washington, DC, USA, IEEE Computer Society, Los Alamitos (2007) [28] Woodcock, J., Davies, J.: Using Z: Specification, Refinement, and Proof. Prentice Hall, Upper Saddle River (1996)

Generating Class Contracts from Deterministic UML Protocol Statemachines Ivan Porres and Irum Rauf ˚ Abo Akademi University, Dept. of Information Technologies, Turku, Finland {iporres,irauf}@abo.fi

Abstract. We present an approach to generate behavioral class interfaces in the form of class contracts from UML 2.0 protocol state machines. A generated class contract deﬁnes a pre- and post-condition for each operation that triggers a transition in the state machine. We consider the following protocol SM elements: state and state invariants, simple transitions, compound transitions, high-level transitions, complete transitions, self transitions also deal with the case of ﬁring priorities. The generated contracts can be used as a behavioral interface, for documentation, run-time checking and test case generation.

1

Introduction

The Uniﬁed Modeling Language(UML) has become an industrial standard language to design and document software-intensive systems. The UML standard provides many diﬀerent types of diagrams that can be used to document such a system. However, the UML standard often lacks a precise description on the semantic interpretation of these diagrams and how they can be implemented into the executable code [1]. State charts are one of the UML behavioral diagrams. They can represent the behavior of model elements as ﬁnite state transition systems. There are two types of UML state machine: behavioral state machines and protocol state machines (SM) [2]. Behavioral state machines specify how an object reacts to a sequence of events. The eﬀect of a transition is speciﬁed in an action, usually deﬁned as an executable statement in a programming language [2]. On the other hand, a protocol SM describes (part of) an interface speciﬁcation. In protocol SM transitions are triggered by a call event (invoking an operation), and the behavior is speciﬁed by using transition pre- and post-conditions. We consider that behavioral state machines are more suitable to describe reactive behavior while protocol state machines are more suitable to describe data-intensive classes. It is possible to generate executable code from behavioral state machines, since the transitions include executable actions. The implementation of state machines has been discussed often in the literature [22,24] and there are commercial tools that provide automatic code generation from behavioral state machines such as Telelogic Rhapsody [6]. S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 172–185, 2010. c Springer-Verlag Berlin Heidelberg 2010

Generating Class Contracts from Deterministic UML Protocol Statemachines

173

In contrast, protocol state machine do not include executable actions, but only a speciﬁcation of these actions in the form of preconditions and postconditions. This approach is useful to describe the interface and intended behavior of a class, while omitting its implementation details. In this case, the protocol SM serves as a visual representation of behavioral interface of a class. A programmer that plans to use a class can inspect its protocol SM to know what methods are available, when these methods can be invoked and what are the expected results. Since a protocol SM does not include executable actions, the actual implementation of a protocol SM into a class in a programming language such as Java has to be performed manually. This raises the question on how to ensure that a class implementing a protocol SM behaves as described in its interface. The approach that we suggest in this article is to generate a class contract from a protocol state machine. The use of a class contract to specify the behavior of a software class has been advocated by Meyer [18] and implemented ﬁrst in the Eiﬀel programming language. More recently, the Java Modeling Language (JML) [23] provides a contract language to annotate Java classes. A class contract can be used to generate run-time assertions that reveal if a particular execution of the system breaks the pre- or post-condition of a method and to generate test cases to exercise the method’s assertions [18,5,15]. This task can be automated with existing tools [3,4]. By using UML protocol SM to deﬁne behavioral interfaces and the approach described in this article to generate class contracts, we can beneﬁt from previous and future eﬀorts in test case generation from behavioral contracts while using a familiar and standardized visual notation. Models are easy to communicate with the intended users of the system. In addition, they also serve as a part of the speciﬁcation document[7]. The use of UML protocol SM in our work facilitates the software development process as it serves as a documentation for a class to the developer and also a basis for testing such a class. We proceed as follows. Section 2 provides an overview of the approach. Section 3 presents the structure of the protocol state machine and its semantics. In Section 4, we discuss how to generate a contract for a class while validation of classes is brieﬂy discussed in Section 5. Related work and conclusions are presented in Sections 6 and 7, respectively.

2

Overview

We aim to test the implementation of a class by employing the eﬀorts already done to validate a class using class contracts. Figure 1 shows the overview of our approach. We require two UML diagrams: a class diagram and a UML protocol state machine. The UML class diagram provides a syntactic interface of a class by naming the public methods of class and the type of their input and output parameters. We generate a Java class from a UML class diagram using a code generator and modify it by providing manual implementations. The protocol state machine describes the behavioral interface of the class. We extract class

174

I. Porres and I. Rauf

Fig. 1. Overview of the approach

contracts from UML protocol state machine by the approach described in this article. These contracts are asserted using JML contract language [23] into a Java class interface. The asserted contracts monitor the behavior of the implemented class and ensure that it does not violate the contracts of the class interface. The generated Java class and JML contracts are used with JML testing tools, i.e., JML-JUnit, ESC/Java and JET, to validate the implementation of the class. The protocol SM should deﬁne a state invariant for each simple and composite state. A state invariant is a boolean expression that is true when the given state is active. This expression should be pure or free of side eﬀects. For this reason, we diﬀerentiate between query methods, that retrieve the state of an object but do not modify it, and operations that can have side eﬀects. State invariants link the current state of an object, deﬁned using object attributes and the current state of its protocol, deﬁned using a protocol state machine. As an example Figure 2 shows a syntactic interface for a stack class and Figure 3 shows a simple protocol SM with three simple states(Empty, notEmpty, F ull), four query methods (isEmpty, isF ull, getM ax, size) and two operations (push and pop). Our objective is to extract a class contract for the class Stack so that it can be expressed in a contract language such as JML. This contract should follow the protocol deﬁned in the state machine. That is, the observable behavior of a class that implements the protocol state machine and a class that implements the contract should be equivalent. We should note that while there are three diﬀerent transitions triggered by the push method, the actual implementation should combine the behavior of the three transitions into one single method. Therefore, in order to generate the class contract we need to combine the information stated in all the transitions triggered by the method into a pre- and post-condition for that method. We describe this task in the following sections.

Generating Class Contracts from Deterministic UML Protocol Statemachines

175

Fig. 2. Stack Class

Fig. 3. Protocol Statemachine for Stack class

3

The Structure and Semantics of Protocol State Machines

A protocol state machine deﬁnes how a classiﬁer instance progresses from one state to another and under what conditions. It also identiﬁes the lifecycle of a classiﬁer instance [2]. A state of statemachine in UML 2.0 is distinguished into three kinds of states i.e., simple, composite and submachine state [2] . We do not deﬁne a submachine state since they are considered semantically equivalent to a composite state [2]. Deﬁnition 1. A protocol SM is deﬁned as a set { SF , ι, Ss , Sc , T, source, target, trigger, issubstate, g, inv, post}, where SF is a set of ﬁnal states, ι is the initial state, Ss is a set of simple states, Sc is a set of composite states and T is a set of transitions. The following functions describe the relations between the elements of the state machine: – issubstate(s1, s2 ) is true if state s1 is a substate of s2 . – trigger(t) provides the operation that triggers the transition t.

176

I. Porres and I. Rauf

– source(t) is the set of source states for a transition t. This is the set of all states that should be active in order to trigger transition t. If a transition starts from a substate, then this set will also include all the containing states. If a transition is a join transition, then this set will include all the states participating in the join (and their containers). We call the direct source of a transition to the set of source states without their containers: dsource(t) = {s ∈ source(t) : ¬∃s ∈ source(t) : issubstate(s, s)}. – target(t) provides the set of all the target states for a transition t. – post(t, σ) evaluates the postcondition of the operation associated to a transition t in an object in state σ. – g(t, σ) evaluates the guard associated with the transition t in an object in state σ. – inv(s, σ) evaluates the invariant of the state s in an object in state σ The set of states in a protocol SM is the union of the diﬀerent types of states S = ι ∪ SF ∪ Ss ∪ Sc . The sets Ss and Sc are mutually disjoint. Sigma state(σ) is the active state of the object in a protocol state machine. It is the semantic state of a protocol state machine and is distinguished from its syntactic state(s). If no guard is given for a transition, then we assume it is true. Similarly, if the postcondition of the transition is not given, it is assumed to be true. Elements in the set of ﬁnal states can never be the source of a transition, i.e. SF = {s : ∀t ∈ T, s ∈ / source(t)}. An initial state cannot belong to the set of ﬁnal states and is not the target state of any transition, i.e. ι = ι ∈ S ∧ ι ∈ SF ∧ ∀t ∈ T : ι ∈ target(t). The UML standard provides many well-formed rules or constraints over the structure of protocol state machine. We formalize here only the aspects of a protocol state machine that are most relevant for this article. We require that the graph created with the set of states S and the binary relation issubstate is connected and acyclic. The description of structure of protocol SM provides a concrete basis to present the semantics of protocol SM as a state transition system. The behavior of invoking a method will be equivalent to triggering one or more transitions that have that method as a trigger. To deﬁne the semantics of a protocol SM we need to deﬁne what transitions are enabled and what is the eﬀect of triggering each transition. 3.1

Enabled Transitions and Steps

In order to trigger a transition it should be enabled. A transition is enabled if its trigger method is invoked, its guard evaluates to true and all its source states are active. Deﬁnition 2. A transition t is enabled if enabled(t, m, σ) = g(t, σ)∧(trigger(t) = m) ∧ ∀s ∈ source(t) : inv(s, σ)

Generating Class Contracts from Deterministic UML Protocol Statemachines

177

It is possible that invoking a method triggers more than one enabled transition. In some cases we can only trigger one of the enabled transitions. This is the case when the enabled transitions have common source states. This situation results in a conﬂict between these transitions. Deﬁnition 3. Two transitions t1 and t2 are in conﬂict when: conf lict(t1 , t2 ) = (trigger(t1 ) = trigger(t2 )) ∧ enabled(t1 , trigger(t1 ), σ) ∧ enabled(t2, trigger(t2 ), σ) ∧ (source(t1 ) ∩ source(t2 ) = ∅) When two transitions are in conﬂict we need to choose one transition to ﬁre. The UML standard deﬁnes a priority scheme based on the state hierarchy. Transitions originating from deeper sub-states have priority over transitions originating from a composite state. Deﬁnition 4. Transition t1 has priority over transition t2 when priority(t1 , t2 ) = conf lict(t1 , t2 ) ∧ ∃s1 ∈ dsource(t1 ), s2 ∈ dsource(t2 ) : issubstate(s1, s2 ) In some cases, two transitions may be in conﬂict but none of them may have priority. This is the case of two transitions triggered by the same method call and originating from the same source state. In this case, the behavior of the protocol SM is non-deterministic. The UML standard speciﬁes that in the case of non-determinism between two or more transitions, any of the transitions can be triggered. In the rest of this text, we assume that all conﬂicts can be resolved and that the behavior of the protocol SM is thus deterministic. The set of transitions triggered simultaneously is called a step. We can now deﬁne what is a step in a protocol SM. Deﬁnition 5. Given protocol SM, an object in state σ and a method m, we deﬁne a step as the set of all enabled prioritized transitions: step(m, σ) = {t ∈ T : enabled(t, m, σ)∧ (¬∃t ∈ T : enabled(t , m, σ) ∧ priority(t , t))} When a method is invoked in an object whose behavior is represented as a protocol SM, the behavior of the method should be equivalent to triggering all the transitions in a step of the protocol SM. 3.2

The Eﬀect of Triggering a Transition

The eﬀect of ﬁring a transition is such that invariant of all the target states should be true and the transition postcondition should be also true. Deﬁnition 6. The eﬀect of triggering a transition t is deﬁned as: ef f ect(t, σ ) = post(t, σ ) ∧ ∀t ∈ target(t) : inv(t, σ ) This caters to the case of a fork transition by making sure that the invariants of all target states are true.

178

4

I. Porres and I. Rauf

Generation of Class Contracts

A class contract generated from a protocol SM contains a precondition and postcondition of each method that may trigger a transition in the protocol SM. The precondition of a method states under which conditions we can invoke a method. We allow a method to be invoked in an object in a state σ when it can trigger at least one transition in the equivalent protocol state machine. This is the case when at least there is a transition enabled. Deﬁnition 7. The precondition for a method m is deﬁned as: precondition(m, σ) = ∃t ∈ T : enabled(t, m, σ) Since the structure of a protocol SM is ﬁnite (there is a ﬁnite number of states, transitions, triggers) and static (it does not change at runtime), we can replace the existential quantiﬁcation in the previous deﬁnition with a disjunction. In our example of stack, we can calculate the precondition for the operation push(): precondition(push, σ) = enabled(t1, push, σ) ∨ enabled(t3, push, σ) ∨ enabled(t5, push, σ) By replacing the deﬁnition of enabled for each transition we obtain the following precondition for push(): precondition(push, σ) = (true ∧ isEmpty(σ)) ∨ (size(σ) < getM ax(σ) − 1 ∧ ¬isEmpty(σ) ∧ ¬isF ull(σ)) ∨ (size(σ) = getM ax(σ) − 1 ∧ ¬isEmpty(σ) ∧ ¬isF ull(σ)) We should note that this expanded precondition does not refer anymore to the structure of the protocol state machines. It uses transition guards and state invariants, but as we stated in Section 2, we require that guards and invariants are deﬁned in terms of the public features of the class. Thus, we have extracted a method precondition using information from the protocol state machine that can be represented in existing class contract languages such as Eiﬀel or JML, or even assertions in languages such as Java or C++. In a language such as JML the previous precondition can be represented as follows: /*@ requires (isEmpty()) || @ (!isEmpty() && !isFull() && size()
The postcondition of a method states the outcome of invoking the method. In our case, all the transitions of the step set are triggered and the eﬀect of each triggered transition should be observable after executing the method. We represent as σ the state of an object before executing the method and as σ the state of the object after executing the method.

Generating Class Contracts from Deterministic UML Protocol Statemachines

179

Deﬁnition 8. The postcondition for a method m is deﬁned as: postcondition(m, σ, σ ) = ∀t ∈ step(m, σ) : ef f ect(t, σ ) Again, it is possible to expand and unroll the previous deﬁnition for a speciﬁc method so that it only uses features present in the class interfaces. As the structure of a protocol state machine is ﬁnite and static, so in our example, the universal quantiﬁcation over the step set can be replaced by the conjunction of three implications: postcondition(push, σ, σ ) = (enabled(t1, push, σ) =⇒ ef f ect(t1, σ )) ∧ (enabled(t3, push, σ) =⇒ ef f ect(t3 , σ )) ∧ (enabled(t5, push, σ) =⇒ ef f ect(t5 , σ )) When we replace the deﬁnition of enabled and ef f ect, we obtain the following: postcondition(push, σ, σ ) = (true∧isEmpty(σ) =⇒ ¬isEmpty(σ )∧¬isF ull(σ ))∧(size(σ) < getM ax(σ)− 1 ∧ ¬isEmpty(σ) ∧ ¬isF ull(σ) =⇒ ¬isEmpty(σ ) ∧ ¬isF ull(σ )) ∧ (size(σ) = getM ax(σ) − 1 ∧ ¬isEmpty(σ) ∧ ¬isF ull(σ) =⇒ isF ull(σ )) In the JML contract language the previous value of an expression (before a method is executed) can be obtained by using the \old clause. As an example, this is the postcondition of the push operation: /*@ requires (isEmpty()) || @ (!isEmpty() && !isFull() && size() !isEmpty() ) && @ (\old(!isEmpty() && !isFull() && size() !isEmpty() && !isFull()) && @ (\old(!isEmpty() && !isFull() && size()=getMax()-1) ==> isFull()) */ void push(Object o) { ...

The generation of the precondition and postcondition of the pop operation follows a similar pattern. Usually the main drawback of using post-conditions in testing and runtime checking is that it needs to refer to the previous state of the object before executing the method. This can be achieved at runtime by storing a snapshot of the object, but this step can be computationally expensive and it is only partially supported in contract languages such as Eiﬀel and JML. However, a closer inspection of the deﬁnition of enabled reveals that we do not need to store the complete state of an object but only the guards and invariants that are enabled. Usually, that only requires few bits of storage per method.

180

5

I. Porres and I. Rauf

Validation of Classes Using Contracts

The testing of a program consists of three major steps i.e., selecting test data, executing tests and determining the test results [3]. In order to facilitate the testing process, eﬀorts have been done to automate these steps and determine their eﬀectiveness. We are interested in employing these eﬀorts done on automating the testing process with our approach that generates interface speciﬁcations directly from UML protocol state machines. The validity of a class can be determined by observing whether its implementation conforms to its interface behavioral speciﬁcations. We use this behaviour of validating a class using class contract with our approach. JML is a speciﬁcation language used for deﬁning the behavioral speciﬁcations of Java classes. The class contracts generated from UML protocol state machine, as described in Section 4, can be used with JML-based veriﬁcation and validation tools to ensure that a Java class implements the protocol described in the UML protocol state machine. Examples of such tools are the JML-JUnit [4] tool, JET [3] and ESC/Java2 [26]. Extended Static Checking for Java (ESC/Java2) [26] provides static checking by employing veriﬁcation condition checkers and automatic theorem proving techniques to ﬁnd common programming errors. Static checking evaluates the source code and ﬁnds inconsistencies between design decisions and the implementation without actually running it [27]. This helps in improving software productivity since the error can be detected earlier before executing the program [26]. When a program is run with ESC/Java2 it simply asks for a source ﬁle to check and as a result it displays the output in a message window. JML JUnit [4] automates the process of generating test oracles for classes by monitoring the speciﬁed behavior of the method being tested. The behavior of methods is speciﬁed using JML speciﬁcation language and is monitored using runtime assertion checker. The formal interface speciﬁcations are speciﬁed as pre-conditions, post-conditions and class invariants and are assumed to be fairly complete descriptions of the desired behavior. The test oracle is generated from these formal speciﬁcations and can be combined with hand-written test inputs. Although, the test cases are populated with test data manually by the user but JUnit eases the generation of test classes [4]. Thus, our approach can be used with JUnit in four steps, i.e., generating speciﬁcations, generating the JMLJunit skeleton, ﬁlling in the test class with test data and running the test. The statement coverage for JML-Junit can be provided using JVMDI coverage code analyser. JET [3] is an automated unit testing tool that automates each step of the testing process. It tests Java classes annotated with JML speciﬁcations and performs test data selection, test execution and test result determination. It uses JML speciﬁcations as test oracles and performs fully automatic unit testing of Java classes. The JML assertions help in monitoring the violations in the behavior of the class. If the precondition is violated, it means that the test case is not appropriate and if the postcondition is violated then this means that the implementation does not fulﬁll the contract behavior [3].

Generating Class Contracts from Deterministic UML Protocol Statemachines

181

We are currently developing a proof-of-concept tool to automatically extract class contracts from UML protocol SM. The tool accepts as input a UML 2.0 model serialized as XMI and a Java ﬁle containing an interface or a class. Then it automatically updates the Java ﬁle by inserting a contract derived from the UML protocol state machine as described in this article. Currently, the invariants, guards and post-conditions are written in the target programming language. Alternatively, a more sophisticated constraint language such as OCL could be use. However this requires translating the OCL expressions into the contract language such as JML.

6

Related Work

The use of UML with formal speciﬁcations such as B method has been studied in [9]. In this work [9], Snook and Butler combine the object oriented behavioral UML with formal precise semantics of B-Method to provide UML-B. They used B as an action and constraint language for UML to create speciﬁcations that can be validated and veriﬁed at an early stage. In [16], Sekerinski presents a scheme to translate statecharts into Abstract Machine Notation (AMN) that can be analyzed and reﬁned into executable code. Sekerinski and Zurob present iState Tool in [11] that translates statecharts into programming languages like Pascal, Java or AMN. This work is extended in [17] as he normalizes statecharts and veriﬁes the speciﬁcations by checking the consistencies of invariants with the transitions. Many other authors have also applied model checking and formal veriﬁcation techniques for state charts [12,13,14]. However, these techniques verify the speciﬁcations and do not address the issue of how an implementation created manually conforms to its speciﬁcations. Contracts have been used in many testing techniques. In [18], Meyer establishes the use of contracts to build reliable software components by the method of assertions. The preconditions, postconditions and the class invariants are used as assertions that can be monitored at runtime. In [15], Binder et al. discuss and investigate the role of asserted contracts to isolate the fault when failure is detected. Ciupa and Leitner [8] have made use of Design by Contract assertions for providing full automation of testing process for classes with contracts. They discuss various issues in automation of a testing process and present AutoTest tool as a solution to those issues. In [5], Leitner et al. introduce Contract Driven Development (CDD) as a new development method for testing. Contracts present in the code are used as test oracles and test cases are extracted from failure traces of program and failure runs. The approach is implemented as a Cdd tool. In terms of model based testing, state charts have been used to study, verify and test the dynamic behavior of a system [6,10,11,12,17,19]. Ali et. al [19] use state charts along with collaboration diagrams to test interaction among classes. Their work combines UML collaboration diagrams and statecharts to get an intermediate test model SCOTEM (State COllaboration TEst Model) that is

182

I. Porres and I. Rauf

used to generate valid test paths. In [20], Kansomkeat and Rivepibon transform UML statecharts into a Testing Flow Graph (TFG). Test cases are generated from TFG using testing criteria that provides coverage for state and transition of diagrams. These works, however, focus on the behavioral state charts and do not employ the information provided by the protocol state machine on interface speciﬁcations. Straeten [21] has studied the formalization of protocol state machine in order to identify the inconsistencies between models, but her work does not facilitate the testing process and is based of formal analysis. Kim et. al [10] have used UML state diagrams with EFSM(Extended Finite Statemachines) for generating test cases. Their work is based on behavioral state charts and studies the control and data ﬂow aspects of the program. The use of design by contract with UML has also been explored by Lohmann et. al [28] in their work. Their work provides visual notation to represent contracts that are easy to understand in contrast to textual Object Constraint Language(OCL). They specify the pre- and post-conditions of an operation visually by a pair of object diagrams. This visual representation of contracts is termed as a visual contract. Visual contracts are mapped to behavioral interface speciﬁcations in a Java class. It speciﬁes pre-conditions and post-conditions in terms of required and expected objects. However, for complex systems, with lots of classes and each with many operations, this approach can get complicated.

7

Conclusion and Future Work

UML protocol state machines provide behavioral interface of a class. A programmer writing a class can inspect its protocol state machine to see what methods can be invoked in a class. Class contracts deﬁne the conditions under which a method can be invoked and what are the expected results of invoking an operation of the class. Several eﬀorts have been done to validate classes using the information asserted as contracts in a class and we can ﬁnd the automation of many of these approaches to validate a contract-equipped class. These approaches target to automate various phases of a testing process to ease the testing task. Our work takes a step forward by providing a mechanism to generate class contracts from a model that is developed during the design phase. We have used UML protocol state machine along with UML class diagram to generate class contracts. These models serve as a part of the speciﬁcation document and do not require an extra eﬀort at the tester’s end. We assume that design models are detailed and correct. In this article, we present the process of generating class contracts from a UML protocol state machine. The process of generating class contract involves formal deﬁnitions to provide unambiguous semantics. The formalization of a protocol state machine and of the steps to generate class contracts are presented in detail and demonstrated with the help of a simple stack example. The generated class contracts are mapped to a speciﬁcation language and asserted into the class code. The Java class can be automatically generated from UML class

Generating Class Contracts from Deterministic UML Protocol Statemachines

183

diagram and reﬁned via manual implementation. The generated ﬁle annotated with JML speciﬁcations can then be used with diﬀerent testing tools to validate the behavior of the class. We have provided a detailed discussion on how the class can be validated using diﬀerent testing tools. These testing tools include JML testing tools like JML-JUnit, JET and ESC/Java2 that are used with JMLasserted classes. JML-JUnit simpliﬁes the development of white-box unit tests, JET is an automatic random test generator for JML and ESC/Java2 is a static analysis tool. Our work is unlike most of the previous works on state machines that employ behavioral state machines for code generation, veriﬁcation or validation. The process of generating class contracts from UML protocol state machines can be automated. Thus, the practitioners do not need to understand the underlying formal complexity for the translation of a protocol state machine to class contracts in order to beneﬁt from the approach. To our knowledge, our work of formalizing and extracting contracts from a protocol state machine to create and validate behavioral interfaces has not been addressed in the literature before. Currently we are working on extending the scope of our work to cover the non-deterministic behavior of a UML protocol state machine. The work on applying the approach on a comprehensive case study that exercises all the scenarios of a UML protocol state machine is underway. We are also working on a complete tool support that takes as input two UML diagrams i.e. a class diagram and a protocol state machine, and generates class contracts asserted into Java code. We plan to integrate all the testing tools along with our tool behind a single user interface. The tool can help UML practitioners to quickly generate class contracts that can be processed with existing validation and testing tools.

References 1. Evans, A., France, R., Lano, K., Rumpe, B.: Developing the UML as a formal modelling notation. In: B´ezivin, J., Muller, P.-A. (eds.) UML 1998. LNCS, vol. 1618, pp. 9–20. Springer, Heidelberg (1999) 2. UML Revision Task Force. OMG UML Speciﬁcation 2.2 (2009), http://www.omg.org/spec/UML/2.2/ 3. Cheon, Y.: Automated Random Testing to Detect Speciﬁcation-Code Inconsistencies. In: Proceedings of the International Conference on Software Engineering Theory and Practice, Orlando, Florida, U.S.A, July 9-12 (2007) 4. Cheon, Y., Leavens, G.T.: The JML and JUnit Way of Unit Testing and its Implementation. Technical Report 04-02, Department of Computer Science, Iowa State University, Ames, IA (February 2004) 5. Leitner, A., Ciupa, I., Manuel, O., Meyer, B., Fiva, A.: Contract driven development = test driven development-writing test cases. In: ESEC-FSE 2007: Proceedings of the ACM Symposium on The Foundations of Software Engineering, New York, NY, USA, pp. 425–434 (2007) 6. Gery, E., Harel, D., Palachi, E.: Rhapsody: A Complete Lifecycle Model-Based Development System. In: Butler, M., Petre, L., Sere, K. (eds.) IFM 2002. LNCS, vol. 2335, pp. 1–10. Springer, Heidelberg (2002)

184

I. Porres and I. Rauf

7. Mens, T., Gorp, P.V.: A Taxonomy of Model Transformation. In: Proceedings of the International Workshop on Graph and Model Transformation (2005) 8. Ciupa, I., Leitner, A.: Automatic testing based on Design by Contract. In: Proceedings of Net. ObjectDays 2005, 6th Annual International Conference on ObjectOriented and Internet-based Technologies, Concepts and Applications for a Networked World, pp. 545–557 (2005) 9. Snook, C., Butler, M.: UML-B: Formal modelling and design aided by UML. ACM Transactions on Software Engineering and Methodology 15(1), 92–122 (2006) 10. Kim, Y., Honh, H., Cho, S., Bae, D., Cha, S.: Test Cases Generation from UML State Diagrams. IEE Proceedings Software 146, 187–192 (1999) 11. Sekerinski, E., Zurob, R.: iState: A statechart translator. In: Gogolla, M., Kobryn, C. (eds.) UML 2001. LNCS, vol. 2185, pp. 376–390. Springer, Heidelberg (2001) 12. Latella, D., Majzik, I., Massink, M.: Automatic Veriﬁcation of a Behavioural Subset of UML Statechart Diagrams Using the SPIN Model-Checker. Formal Aspects of Computing 11, 637–664 (1999) 13. Lilius, J., Porres, I.: Formalising UML State Machines for Model Checking. In: France, R.B., Rumpe, B. (eds.) UML 1999. LNCS, vol. 1723, pp. 430–444. Springer, Heidelberg (1999) 14. Knapp, A., Merz, S., Rauh, C.: Model Checking Timed UML State Machines and Collaborations. In: Damm, W., Olderog, E.-R. (eds.) FTRTFT 2002. LNCS, vol. 2469, pp. 395–414. Springer, Heidelberg (2002) 15. Briand, L.C., Labiche, Y., Sun, H.: Investigating the Use of Analysis Contracts to Support Fault Isolation in Object Oriented Code. In: ISSTA 2002: Proceedings of the 2002 ACM SIGSOFT International Symposium on Software testing and analysis, pp. 70–80 (2002) 16. Sekerinski, E.: Graphical design of reactive systems. In: Bert, D. (ed.) B 1998. LNCS, vol. 1393, p. 182. Springer, Heidelberg (1998) 17. Sekerinski, E.: Verifying Statecharts with State Invariants. In: The Proceedings of the 13th IEEE International Conference on Engineering of Complex Computer Systems, pp. 7–14 (2008) 18. Meyer, B.: Applying Design by Contract, Computer. IEEE Computer 25, 40–51 (1992) 19. Ali, S., Briand, L.C., Jaﬀar-ur Rehman, M., Asghar, H., Iqbal, M.Z., Nadeem, A.: A State-based Approach to Integration Testing for Object-Oriented Programs. Information and Software Technology 49(11-12), 1087–1106 (2007) 20. Kansomkeat, S., Rivepiboon, W.: Automated-Generating Test Case Using Statechart Diagrams. In: Proceedings of the 2003 annual research conference of the South African institute of computer scientists and information technologists on Enablement through technology, vol. 47, pp. 296–300 (2003) 21. Van Der Straeten, R.: Inconsistency Management in Model-driven Engineering- An Approach using Description Logics. PhD thesis, Department of Computer Science, Vrije Universiteit Brussel, Belgium (2005) 22. Benowitz, E., Clark, K., Watney, G.: Auto-coding UML statecharts for ﬂight software. In: SMC-IT 2006: Proceedings of the 2nd IEEE International Conference on Space Mission Challenges for Information Technology, pp. 413–417 (2006) 23. Leavens, G.T., Baker, A.L., Ruby, C.: JML: a Java modeling language. In: Formal Underpinnings of Java Workshop at OOPSLA 1998 (October 1998) 24. Niaz, I.A., Tanaka, J.: Mapping Uml Statecharts To Java Code. In: Proceedings of IASTED International Conference on Software Engineering (2004)

Generating Class Contracts from Deterministic UML Protocol Statemachines

185

25. Lampinen, J.: Interface speciﬁcation methods for software components, Publications in the Laboratory for Theoretical Computer Science, Helsinki University of Technology, Department of Information and Computer Science (June 2008) 26. Flanagan, C., Leino, K.R.M., Lillibridge, M., Nelson, G., Saxe, J.B., Stata, R.: Extended static checking for Java. In: ACM SIGPLAN 2002: Proceedings of the Conference on Programming language design and implementation, Berlin, Germany, June 17-19 (2002) 27. Abdurazik, A., Oﬀutt, J.: Using UML collaboration diagrams for static checking and test generation. In: Evans, A., Kent, S., Selic, B. (eds.) UML 2000. LNCS, vol. 1939, pp. 383–395. Springer, Heidelberg (2000) 28. Lohmann, M., Sauer, S., Engels, G.: Executable Visual Contracts. In: VLHCC 2005: Proceedings of the IEEE Symposium on Visual Languages and HumanCentric Computing, pp. 63–70 (2005)

“Models and Evolution” Joint MoDSE-MCCM 2009 Workshop on Model-Driven Software Evolution (MoDSE) Model Co-Evolution and Consistency Management (MCCM) Dalila Tamzalit1, Dirk Deridder2, and Bernhard Schätz3 1

LINA, University of Nantes, France [email protected] 2 System and Software Engineering Lab, Vrije Universiteit Brussel, Belgium [email protected] 3 Fortiss GmbH, Germany [email protected]

1 Models and Evolution Software Evolution is a complex and prominent key research domain in software engineering. It has been the topic of numerous international conferences, workshops, books and scientific publications. On the other hand, it represents an omnipresent recurring problem for companies and needs practical and scalable solutions to ensure software confidence, quality and reliability. This becomes even more crucial and critical in application domains where software is geographically distributed and involves multiple stakeholders (e.g., managers, designers, developers, clients) and where resources and requirements must be reconciled. Model-driven engineering (MDE) is a software engineering methodology that focuses on models as primary software artifacts. It helps to reduce complexity and increase productivity and reuse by raising the level of abstraction. With the advent and widespread use of MDE in academia and industry, the research topic of model-driven software evolution and co-evolution becomes more and more important. Because of this increasing importance, a successful series of annual international workshops has been set up since 2007 for the MoDSE workshop and from 2008 for the MCCM workshop, with the main objectives of model-driven software evolution (MoDSE) and model co-evolution and consistency management (MCCM). The MoDSE workshops of 2007 and 2008 investigated how model-driven evolution can enforce and reduce critical risks and important costs involved in software evolution, by employing high-level abstractions. Furthermore, the potential of modeldriven engineering (MDE) to enforce and enhance software evolution was explored, weighing pros and cons of the use of MDE to manage and direct software evolution through innovative proposals. S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 186–189, 2010. © Springer-Verlag Berlin Heidelberg 2010

“Models and Evolution”

187

Complementary, the MCCM workshop focused on the manipulation and transformation of models as a core task of MDE, with model co-evolution and consistency management as crucial activities to cope with the natural changes of any software system; it promoted more disciplined techniques and engineering tools to support a wide range of model evolution activities, including model differencing, model comparison, model refactoring, model inconsistency management, model versioning and merging, and co-evolution of models. To explore and strengthen the interaction and synergy between the active research domains of Software Evolution, Co-Evolution, Consistency Management and MDE, these two workshops joined their forces in a common workshop on “Models and Evolution”.

2 Workshop Themes The objective of the workshop was to provide insight and advance the state of the art concerning how models can help and guide software evolution and how to enforce and reduce critical risks and important resources (e.g., costs, personnel, time) involved in software evolution, by employing high-level abstractions. In addition to the objective to propose a presentation and discussion space and gather the MDE and software evolution communities (as well academic as industry), the joint workshop also specifically encouraged young researchers participation and attendance. This full-day workshop included technical presentation sessions, tool demonstrations, moderated debate sessions with open discussions. The technical presentations were organized in four sessions: • Co-evolution, Co-adaptation and Synchronization: The first session specifically dealt with fundamental issues of change affecting the construction of models. Contributions provided an analysis of different approaches to model migration (by Louis Rose, Richard Paige, Dimitrios Kolovos and Fiona Polack), dealt with re-synchronization of models after source-code changes (by Rafael Meneses and Rubby Casallas), and treated the analysis of inconsistency during evolution of domain-specific models (by Christian Bartelt). • Tooling and Industrial feedback: The second session was focused on the application side of models and evolution, discussing possible ways of tool support and experiences with the problems and approaches of model evolution in practical settings. On the tooling side, contributions to this session presented a case study on different ways of model refactoring in Eclipse by different frameworks (by Thorsten Arendt, Florian Mantz, Lars Schneider and Gabriele Taentzer), discussed the provision of inconsistency management framework for Model Transformation Tools (by Olaf Muliawan and Dirk Janssens), and llustrated possible comprehensive support for evolving software cases (by Michal Smialek). On the experience side, contributions presented a practical case study of MDD infusion in a SME (by Regis Vogel) and discussed experiences why model versioning research is still needed (by Kerstin Altmanninger, Petra Brosch, Gerti Kappel, Philip Langer, Martina Seidl, Konrad Wieland and Manuel Wimmer).

188

D. Tamzalit, D. Deridder, and B. Schätz

• Modelling Evolution: The third session presented constructive approaches to handle evolution issues in a model-based development process. Contributions analyzed the limitations of automating model migration in response to meta-model adaptations (by Markus Herrmannsdoerfer and Daniel Ratiu), showed the possibilities of using model patches in Model-Driven Engineering, (by Antonio Cicchetti, Davide Di Ruscio and Alfonso Pierantonio), and illustrated how to provide change impact analysis of Model-Driven Development Systems using evolution scenario templates, (by Bedir Tekinerdogan and Ersin Er). • Evolution Techniques: The fourth session dealt with specific evolution techniques. Contributions illustrated the construction of Service Oriented Architecture definitions by using composition of evolutions, (by Sebastien Mosser, Mireille Blay-Fornarino and Michel Riveill), compared experiences with state-based vs. operation-based change tracking during model evolution (by Maximilian Koegel, Markus Herrmannsdoerfer, Jonas Helming and Yang Li), and investigated the use of change intentions to guide evolution and versioning in Model Driven Development (by Rafael Leaño, Rubby Casallas and Nicolás López).

3 Open Research Questions With the objective of the workshop to provide insight and advance the state of the art, the technical presentations were complemented by a discussion session on open issues concerning models and evolution. The session was organized around some debate questions asked by authors and by the program chairs, addressed in open discussion. During the discussion, five core questions emerged from a larger set of more detailed questions: 1. Is code just another model and a model just another form of code with respect to evolution? Here, methodical aspects of this question were raised, e.g., whether code should also be treated as a model in terms of versioning in the future, leading to nontextual versioning of source code. Furthermore, principal question were discussed whether eliminating this dichotomy could eliminate issues like round-trip problems, requiring to deal with the problem of preserving handwritten code in the generated implementation during revisions. 2. How do views affect model evolution? This field of questions included issues whether the separation of concern could simplify evolution, by asking for drawbacks and advantages of a single meta model supporting multiple views as separation of concerns compared to a proper separation of concerns built on top of different languages interconnected explicitly. Furthermore, since an integrate meta model would require it: is the issue of (horizontal/vertical) view consistency sufficiently solved to support such an approach? 3. Will improved tool support change the way (meta) models evolve? This question subsumed methodical issues concerning the role of models and meta models during evolution, e.g., whether the assumption that meta modelers have all

“Models and Evolution”

189

the existing models under their control is a common or a rare case. It also raised questions concerning how to assess effective improvements, e.g., to make research results more comparable by using one technological base (such as EMF). 4. How relevant is the management of (meta) model evolution? Here, questions were addressed arguing whether enterprises really evolve their modeling languages or whether they typically rely on well established languages and long running projects which require only limited changes, before developing a new meta model and corresponding instance from scratch. This question also raised the issue whether the (argued) advent of domain-specific abstractions will change how evolution will take place? 5. How can we ensure that a model evolution preserves the semantics? This question lead to a plethora of further, very fundamental questions, especially how to (effectively) describe the semantics of a (meta) model at all, how provide (effective) notions of evolution of (meta) models concerning their semantics, and how to implement analysis tools given those notions of evolution.

4 Summary and Outlook The joint workshop demonstrated its relevance with attracting more than 50 participants, providing the intended discussion amoung and cross-fertilization between the both domains of model-driven software evolution (MoDSE) and model co-evolution and consistency management (MCCM). Full versions of all presented contributions have been made available online (see www.modse.fr). The technical presentations, ranging from more fundamental questions via tooling and experience results to specific evolution approaches, and especially the questions posed during the discussion session clearly indicate that “Models and Evolution” is indeed a topic relevant for both research and application. Far from being sufficiently covered by the current state of the art, the topic therefore demands further attention to be addressed in future “Models and Evolution” workshops.

Model Patches in Model-Driven Engineering Antonio Cicchetti1 , Davide Di Ruscio2 , and Alfonso Pierantonio2 1

School of Innovation, Design and Engineering M¨alardalen University, SE-721 23, V¨aster˚as, Sweden [email protected] 2 Dipartimento di Informatica Universit`a degli Studi dell’Aquila Via Vetoio, Coppito I-67010, L’Aquila, Italy {diruscio,alfonso}@di.univaq.it

Abstract. Increasingly, recording the various kinds of design-level structural evolution that a system undergoes throughout its entire life-cycle is gaining relevance in software modeling and development. In this respect, an interesting and useful operation between subsequent system versions is model difference consisting in calculation, representation, and visualization. This work shows how to generalize the application of differences, represented as first-class artefacts, in order to abstract from persistent identifiers and enable more flexibility. Then, modifications can be applied as model patches to arbitrary models according to weaving specifications.

1 Introduction Model Driven Engineering (MDE) [1] emerged to increase productivity and reduce time-to-market by enabling development using concepts closer to the problem domain, rather than those offered by programming languages. Moreover, it is aimed at making the software assets more resilient to changes caused by the emerging technologies and makes the role of modeling and models in the current software development much more important. Similarly to what happened for source code, versioning techniques are increasingly needed for supporting the evolution of model-based artefacts. In this respect, the detection of differences between models is essential to model development and management practices [2,3]. The problem of model differences is intrinsically complex and requires specialized algorithms and notations [4,5]. It can be decomposed into three main aspects: calculation, representation, and visualization [5]. In particular, the information resulting from the calculation must be represented in a suitable form to be available for subsequent analyses and manipulations. From such a representation depends the capability of deriving further artefacts or drawing conclusions on the rationale behind the modifications the model underwent during its lifetime. Whereas, the visualization of differences is

Partially supported by the European Community’s 7th Framework Programme (FP7/20072013), grant agreement n◦ 214898.

S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 190–204, 2010. c Springer-Verlag Berlin Heidelberg 2010

Model Patches in Model-Driven Engineering

191

Fig. 1. Manual intervention

realized by giving a concrete syntax which pretty-prints the abstract syntax (representation) and may vary from intuitive diagrammatic notations to textual catalogs as, for instance, spreadsheet data. Encoding the relevant information about modifications as models allows the designer to derive from model differences powerful and interesting artefacts which enable a wide range of possibilities, such as reconstructing the final model starting from an initial one, performing subsequent analysis, or detecting and manipulating conflicts [3,6]. Recently, in [7,8] two similar techniques have been introduced to represent differences as models, hereafter called difference models; interestingly, in these proposals difference models are declarative and enable the reconstruction of the final model by means of automated transformations which are inherently defined in the approaches 1 . In this paper, we enhance the work in [7] in order to support the application of model differences as model patches, that is to apply the modifications described in a difference model to an arbitrary model. For instance, in Fig. 1 the difference model Δ detected between M1 and M2 is applied to reproduce the changes over M1 to obtain M2 with M1 obtained from M1 by means of some manual intervention. This is usually difficult because of persistent identifiers which refer to specific model elements limiting the application of the differences to the original models only, and sometime even to the same modeling environment [9]. The proposed approach considers differences as model patches analogously to Larry Wall’s work on Unix patch 2 . Specific techniques based on the concept of weaving models [2] are used to abstract from persistent identifiers and to explicitly identify those model elements over which modifications must be applied. The paper is structured as follows: Sect. 2 outlines the problem of model difference management, whereas Sect. 3 proposes the approach to apply model differences as patches. Section 4 compares this paper with others. Finally, conclusions and perspective works are drawn.

2 Background The overall structure of the technique in [7] is depicted in Fig. 2: given two base models M1 and M2 which conform to an arbitrary base metamodel MM, their difference conforms to a difference metamodel MMD derived from the former by means of an automated transformation MM2MMD. The approach does not impose any restriction over 1 2

For a better comparison between the existing techniques, please refer to Sect. 4. Gnu patch: http://www.gnu.org/software/hello/manual/diff/index.html

192

A. Cicchetti, D. Di Ruscio, and A. Pierantonio

Fig. 2. Overall structure of the model difference representation approach

Circles

Position

*

+pos : Position

*

+pos : Position

Figure

Canvas *

*

+draw()

Canvas

+x : int +y : int Polygons

(a) Model M1

Circles +draw()

Polygons +draw()

Group +draw()

(b) Model M2

Fig. 3. Two versions of the same model

the metamodel MM, i.e. it is metamodel-independent and can be applied to any arbitrary modeling language. In particular, the metamodel extension implemented in the MM2MMD transformation consists of adding new constructs able to represent the possible modifications that can occur on models and which can be grouped as follows: – additions: new elements are added in the initial model like the abstract class Figure in the sample model M2 depicted in Fig. 3.b not present in the initial version of the specification (see the model M1 in Fig. 3.a); – deletions: some of the existing elements are deleted as a whole like in M1 , where the class Position is not present in M2 anymore; – changes: a new version of the model being considered can consist of updates of already existing elements. For instance, the structural features (associations and operations) of the Circles and Polygons classes in Fig. 3.a have been modified giving place to the new version M2 . As mentioned, in order to represent the differences between M2 and M1 , their base metamodel has to be extended by applying the MM2MMD transformation. Essentially, for each metaclass MC of the source metamodel, the additional metaclasses AddedMC, DeletedMC, and ChangedMC are generated. For instance, an hypothetical simplified

Model Patches in Model-Driven Engineering +type

193

+returnType

Classifie r

+type

+name() : Strin g

AddedAttribut e +source

Attribute

Associatino

+parent

Class

+target

+isComposition : boolean = false +isAggregation : boolean +isDependency : boolean

+isAbstract : boolean

DeletedAttribute

ChangedAttribute updatedElement

updatedElement

AddedAssociation

+name : String +attributes +visibility : VisibilityKind * updatedElement

AddedClass

ChangedAssociation

ChangedClass

DeletedClass

DeletedAssociation

+operations

Operation +name : String +visibility : VisibilityKind

{ordered}

updatedElement

* +parameters

Parameter

AddedOperation

DeletedOperation

ChangedOperation

+name : String updatedElement

AddedParameter

DeletedParameter

ChangedParameter

Fig. 4. A simplified UML metamodel extended to the corresponding difference language

UML metamodel would be extended as shown in Fig. 4: the metaclass Class of the UML metamodel induces the generation of the metaclasses AddedClass, DeletedClass, and ChangedClass. In the same way, the metaclass Operation entails the addition of the new specializations that are AddedOperation, DeletedOperation, and ChangedOperation, whereas the Association metaclass induces the corresponding AddedAssociation, DeletedAssociation, and ChangedAssociation. The generated difference metamodel is able to represent all the differences amongst models which conform to the base metamodel, that is the simplified UML metamodel in this case. For instance, the difference model in Fig. 5 (that will be called Δ1,2 hereafter) represents the differences between the models M1 and M2 in Fig. 3. The differences depicted in such a model can be summarized as follows: 1. the addition of the new class Figure in M2 is represented by means of the AddedClass instance c1 which is associated with the instance op1 of the metaclass AddedOperation; 2. the addition of the new class Group is represented through the instance c2 of the AddedClass metaclass. The method draw is represented like that of the new Figure class. Moreover, the composition between the Group and Figure classes is represented through assoc1 which is an instance of the AddedAssociation metaclass; 3. in the new version of the model, the Circles and Polygons classes are specializations of the class Figure. These modifications are represented by means of the instances c3 and c5, respectively, of the ChangedClass metaclass. Each of them refer to the corresponding updatedElement which represents the new version of the element. For instance, the instance c4 of the metaclass Class has the new parent association with the class Figure and does not have the attribute pos which has been deleted in the new version of the class Circles;

194

A. Cicchetti, D. Di Ruscio, and A. Pierantonio

Fig. 5. Sample difference model (Δ1,2 )

4. the deletion of the class Position has been represented by means of the instance c7 of the DeletedClass metaclass. Moreover, the attributes x and y of the same class are represented through the datt1 and datt2 instances, respectively, of the metaclass DeletedAttribute. The proposed difference representation meets a number of requirements which are given in [7]; in particular, in this work we exploit the self-containedness property to extend the application of manipulations to arbitrary models conforming to the base metamodel MM. 2.1 Difference Application According to Fig. 2 the model transformation MMD MM2MM is generated to apply the differences stored in a difference model Δ to an initial model M1 in order to obtain a final M2 . MMD MM2MM is automatically derived by means of the higher-order transformation MMD2ATL in Fig. 2, i.e. a transformation which produces another transformation [2]. In particular, MMD MM2MM consists of rules which apply over a model M1 the additions, deletions and changes specified in Δ.

Model Patches in Model-Driven Engineering

195

The application of the transformation MMD MM2MM to the models M1 and Δ1,2 reconstructs the final model M2 in Fig. 3.b. Nevertheless, it may be very convenient to be able to apply a difference to any model conforming to the base metamodel. In other words, we want to use difference models as model patches analogously to Larry Wall’s Unix patch. To the best of our knowledge, in current model-based approaches (e.g. [10,11,12,8]) difference application is either not supported at all or limited to those models which have been used for the difference calculation. In this respect, the approach illustrated so far in Fig. 2 is no exception. In fact, the generated MMD MM2MM transformation is exact, i.e. does not comprise any adjustability of its application. This problem, that will be tackled in the next section, is mainly due to the persistent identifiers, that is identifiers which are assigned to model elements by the modeling tools. They compromise interoperability and lock the models within a specific platform since identifiers are not universally computable. For instance, Δ1,2 embeds the references to the model elements of M1 and M2 involved in the calculation of the differences. Hence, the application of Δ1,2 to a model different than M1 (like the scenario shown in Fig. 1), probably will result either in an idempotent application or in an erroneous model since the involved persistent identifiers could be no longer valid. The next section generalizes the application of model difference to arbitrary models by introducing weaving models [2], which can be considered morphisms between models, to support the realization of model differences as model patches. This will enable, for instance, the application of Δ1,2 as is also to a model M1 obtained from M1 , thus requiring that the refactoring originally operated from M1 to M2 has to involve also new elements while leaving all the other modifications still valid.

3 Modeling Difference Application In this section, the metamodel independent approach outlined above is extended in order to model the application of differences to arbitrary models. For instance, starting from the manipulation of M1 as shown in Fig. 6.a, it shall be possible to apply the differences stored in Δ1,2 in order to obtain a M2 as depicted in Fig. 6.b. Going deeper, the difference application should also take into account the new class Line by reproducing the same effects induced by Δ1,2 on the original Circle and Polygon. In order to let the approach be general, this operation requires the definition of correspondences which identify the model elements upon which the modifications must be operated. Such correspondences are based on the concept of model weaving which has been successfully applied for metadata integration and evolution [13]. The specific definition of model weaving which is used here refers to the work in [2], where the authors proposed a model-based framework to establish model element correspondences in a generic way. In particular, it consists of the production of a weaving model WM representing the mapping between the metamodels LeftMM and RightMM; like other models, this should conform to a specific weaving metamodel WMM. Weaving links may be specified to relate also models instead of metamodels and this is the case of what is proposed in this paper in which weaving models are produced in order to relate input models with existing difference representations. Such correspondences are specified with respect to the difference application metamodel in Fig. 7. In

196

A. Cicchetti, D. Di Ruscio, and A. Pierantonio

Circle +pos : Position

Figure

Canvas Position

Canvas

+x : int +y : int

* Line

*

+draw()

+pos : Position

Polygon

Line

Circle

+draw()

+draw()

Polygon +draw()

Group +draw()

+pos : Position

(a) Model M1

(b) Model M2 Fig. 6. Modified models

particular, a difference application model (DAModel) consists of elements (WElement) related through weaving links (WLink). According to the different kind of elements involved in weaving operations, InputWElement and DeltaWElement specialize the WElement concept. Moreover, ApplicationWLink is a specialization of WLink and relates elements of the input model (see the left role) with one of the difference representation (see the right role).

Fig. 7. The Difference Application metamodel

A sample difference application model is depicted in Fig. 8.c. The model is presented by using the tree-based editor of EMF 3 which is the framework that underpins the AMMA platform [14] used to implement the overall approach, as clarified in the following. Moreover, for the sake of illustration, the identifiers denoting the element correspondences have been replaced by dashed lines. The model in Fig. 8.c is only a fragment of the weaving specification that solves the problems stated above. In fact, the proposed application model discloses the possibility to apply the existing difference model Δ1,2 in Fig. 5 to any model that conforms to the base metamodel MM. In the 3

Eclipse Modeling Framework (EMF): http://www.eclipse.org/emf

Model Patches in Model-Driven Engineering

197

Fig. 8. Fragment of a sample difference application model

example, the model M1 of Fig. 6.a is taken into account in order to reuse and apply Δ1,2 to produce the model M2 of Fig. 6.b. In more detail, by means of the application model the modifications in Δ1,2 are related to elements of M1 . For instance, the deletion of the Position class is specified by relating it (and the contained attributes) to the instances c7, datt1, and datt2 in Δ1,2 through the application links w1, w2, w3, respectively. Moreover, the links w6, and w7 denote the deletion of the pos attribute of the class Polygon and the introduction of the specialization with the new class Figure. The reader should note that the modification can be applied even though the class Polygon has a name different than the initial class Polygons in Fig. 3.a. This is feasible since the change expressed in Δ1,2 by means of the instances c3, att1, and c4 does not express any modification of the attribute name, hence the updatedElement class will have the same name of the changed one. Interestingly, the new added class Line is also considered in the difference application. In fact, since the modifications that should be employed on it are the same as those for the class Polygon, the links w4 and w5 can be specified in order to use them for the class Line.

198

A. Cicchetti, D. Di Ruscio, and A. Pierantonio

Fig. 9. The enhanced difference application scenario

In general, the definition of difference application models can be supported by heuristics raising its automation level [15] like structural similarity which has proved to be an efficient element matching mechanism [10,11]. For instance, in [11] the calculation starts by evaluating signature similarity, that is by comparing the combinations of type, kind and name of the given entities. Relations can be matched as well by means of their signatures plus those of linked source and target elements. If multiple valid candidates exist, the mapping is refined through structural similarity computations. In our scenario, each time a mapping is discovered, it can be stored in the difference application model being specified. Then the automated weaving mechanism can be fine-tuned through manual intervention which could be required both to correct erroneous matchings and to establish custom mappings. 3.1 Technical Details In order to apply differences with respect to the correspondences specified in weaving models, a new enhanced model transformation has to be generated by MMD2ATL. In particular, the new MMD MM2MM can be applied to a source model M1 in order to obtain a target model M2 with respect to the differences specified in a model Δ and the correspondences given in the difference application model DAM . In other words, the enhanced difference application engine has to embed the knowledge of the weaving model driving the application as pointing out the elements which are subject of the corresponding manipulations defined in the Δ document, as clarified in Fig. 9. The transformation implements the rules to apply on a model M1 the addition, deletions and changes specified in the Δ with respect to the application links specified in DAM . In general, for each metaclass MC in the metamodel M M , the transformation contains the following rules: – AddedMC2MC: for each element in Δ that conforms to the AddedMC metaclass the rule creates in M2 a new instance of MC setting the structural features according to the specification of the AddedMC element; – ChangedMC2MC: for each element in Δ that conforms to the ChangedMC metaclass the rule reads the links in DAM and verifies whether the change is applied to M1 or not. In positive cases the rule updates the changed elements in M1 according to the modifications specified in Δ;

Model Patches in Model-Driven Engineering

199

– UnchangedMC2MC: the rule copies the instances of MC which have to be the same both in M1 and M2 . In particular, given an instance of MC in M1 the rule verifies whether there are application links in DAM which specify the deletion or the changing of the element. Only in negative cases the element is copied to M2 ; As previously stated, the MMD MM2MM transformation can be generated by means of the MMD2ATL higher-order transformation which takes as input the metamodel M M the

models M1 and M2 conform to. In order to clarify what the higher-order transformation has to generate, fragment of the UMLD UML2UML transformation is provided in Listing 1.1 4 . It has been generated by applying such transformation to a sample UML metamodel like the one discussed in the previous section. The transformation is in ATL [17], a hybrid language part of the AMMA platform which contains a mixture of declarative and imperative constructs. Transformation definitions consist of modules each containing a header section (lines 1-2 in the listing), an import section, transformation rules (lines 4-38) and a number of helpers which are used to navigate models and to specify complex calculations on them (lines 40-74). The Listing 1.1 contains a fragment of the helpers and rules generated from the metaclass Class of the sample UML metamodel. In particular, the UnchangedClass2Class rule (lines 4-20) copies the classes of the source UML model to the final one that, according to the OCL guard at line 8, are neither changed nor deleted. The guard exploits the isChanged and isDeleted generated helpers whose bodies are shown at lines 40-52. According to them a source class (referred by self in the code) is changed/deleted if in the difference model there is a ChangedClass/DeletedClass instance e, respectively, related with self by means of an application link l. The management of the changed classes is more complex and it is performed by the ChangedClass2Class rule at lines 22-38. In particular, for each element of the difference model which is an instance of the ChangedClass metaclass, the rule checks whether the modification is applied to some element of the source model. The verification is performed by means of the isApplied helper (whose body is reported at lines 54-59) which navigates the source UML model and checks the existence of a class e which is related to the considered difference by means of a link l specified in the difference application model. In positive cases, a new class is generated in the target UML model and its properties are calculated by exploiting generated helpers like getChangedClassname and getAppliedClass. The latter, whose code is reported at lines 61-74, according to the difference application model gives the reference of the UML class on which the source difference is applied. 1 module UMLDiff2UML; 2 create OUT : UML from IN1 : UML, IN2 : UMLDiff, IN3 : DA; 3 4 rule UnchangedClass2Class { 5 from 6 s : UML!Class 7 ( 8 s.oclIsTypeOf(UML!Class) and not s.isChanged and not s.isDeleted 9 ) 10 to 4

Due to space limitation, the complete transformation is not provided here but it can be downloaded from [16].

200 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

A. Cicchetti, D. Di Ruscio, and A. Pierantonio t : UML!Class ( isAbstract <- s.isAbstract, model <- s.model, parent <- s.parent, attributes <- s.attributes, operations <- s.operations, name <- s.name, id <- s.id )

} ... rule ChangedClass2Class { from s : UMLDiff!ChangedClass ( s.oclIsTypeOf(UMLDiff!ChangedClass) and s.isApplied ) to t : UML!Class ( isAbstract <- s.getChangedClassisAbstract, name <- s.getChangedClassname, id <- s.getChangedClassid, model <- s.getChangedClassmodel, parent <- s.getChangedClassparent, attributes <- Sequence {s.getAppliedClass.attributes, s.attributes}, operations <- Sequence {s.getAppliedClass.operations, s.operations} ) } ... helper context UML!Class def: isChanged : Boolean = UMLDiff!ChangedClass.allInstancesFrom(’IN2’)->exists(e | DA!ApplicationWLink.allInstancesFrom(’IN3’)->exists(l | e.id = l.right.ref and self.id = l.left.ref ) ); helper context UML!Class def: isDeleted : Boolean = UMLDiff!DeletedClass.allInstancesFrom(’IN2’)->exists(e | DA!ApplicationWLink.allInstancesFrom(’IN3’)->exists(l | self.id = l.left.ref and e.id = l.right.ref ) ); ... helper context UMLDiff!ChangedClass def: isApplied : Boolean = UML!Class.allInstancesFrom(’IN1’)->exists(e | DA!ApplicationWLink.allInstancesFrom(’IN3’)->exists(l | self.id = l.right.ref and e.id = l.left.ref ) ); helper context UMLDiff!ChangedClass def: getAppliedClass : UML!Class = if UML!Class.allInstancesFrom(’IN1’)->exists(e | DA!ApplicationWLink.allInstancesFrom(’IN3’)->exists(l | e.id = l.left.ref and self.id = l.right.ref ) ) then UML!Class.allInstancesFrom(’IN1’)->select(e | DA!ApplicationWLink.allInstancesFrom(’IN3’)->exists(l | e.id = l.left.ref and self.id = l.right.ref ) ).first() else OclUndefined endif;

Listing 1.1. Fragment of the generated UMLD UML2UML transformation

Model Patches in Model-Driven Engineering

201

4 Related Work Over the last years a number of approaches to model-based differencing of models have been proposed, e.g. [7,10,11,12,8] to mention a few. All of them can be considered symmetric deltas, according to the classification in [3]. The works in [7] and [8] differ from the others since they represent differences in a self-contained way, i.e. they do not refer to any elements belonging to the base models. On the contrary, other works are relational in the sense that they are based on weaving models [2] (or similar techniques) which contain correspondences between elements in the base models and thus cannot abstract from them. The main difference between these mechanisms is that the self-contained representations contain only information about added, deleted and changed elements disregarding those elements which are left unchanged. This can have an impact on the size of the difference models as witnessed by the coloring techniques (see [12] for a discussion on how to reduce difference model population). All the mentioned approaches may give place to difference application, but as a matter of facts only [7] and [8] provide support to it. This paper aims at applying model differences as model patches. Thus, it generalizes the self-contained approach in [7] and, under limited assumptions, the one in [8] in order to apply differences also to models which are different from the base ones. In this respect, since the other approaches ([10,11,12]) are relational and not independent of the base models, they cannot be used as model patches. It is worth noting that there exist several alternatives for merging models, like for instance ReuseWare 5 and EML [20]. However, those approaches would require a new specification of difference application semantics for each metamodel taken into account. In fact, the difference application proposed in this work extends the already existing technique on model differencing presented in [7]; the previous difference application engine has been improved by adding the supporting knowledge coming from the weaving model to perform the desired manipulations on arbitrary input models. In this respect, the higher-order transformation exploits the basic difference metaelements semantics to derive the corresponding application engine tailored to the given metamodel. A detailed comparison among the techniques given in [11,12] and the various differencing algorithms can be found in [7], the discussion about calculation methods is beyond the scope of this paper which mainly focuses on representation. However, it is worth mentioning that EMF Compare [10] is a component of the Eclipse Modeling Framework Technology (EMFT) which provides models with generic compare and merge operations. Apart from offering a metamodel independent implementation of model comparison and composition, it represents differences as something very similar to weaving models, thus falls in the category of the generic relational representations (see table in Fig. 10 for a brief comparison of the representations provided by the several approaches). Introducing new metaclasses to denote added, deleted, and changed elements for each metaclass in the base metamodel is not the only way of modelling modifications. In fact, in [8] the authors propose a unique difference metamodel consisting of three fundamental metaclasses, namely AddedElement, DeletedElement, and ModifiedElement. 5

ReuseWare Website: http://www.reuseware.org

202

A. Cicchetti, D. Di Ruscio, and A. Pierantonio Approach

Generic Meta Representation

Cicchetti et al [7] Toulm´e [10] Lin et al [11] Ohst et al [12] Rivera et al [8]

x x x x x

self-contained relational relational relational self-contained

Fig. 10. Summary

Those entities are linked to the model elements which have been subject to the corresponding kind of manipulation. Compared to our work, the technique presents the advantage of not requiring the creation of the metamodel specific difference representations and applications because it is generic. However, preferring generic methods over techniques which are defined at a meta level does not always imply an immediate advantage (see [18]). For instance, in this case the representation results coarser, in the sense that the difference models do not hold the information about the classes the modified elements are instance of. This may be problematic since it prevents the abstract syntax of the difference models to be directly mapped to an arbitrary concrete syntax by means of standard frameworks such as GMF [19]: in fact, it is possible to map the concrete syntax only to the fundamental (generic) metaclasses and the problem can be solved only with ad-hoc implementations. Patches have been introduced by Larry Wall in 1985 as a Unix utility. It updates text files according to instructions contained in a separate difference file with the possibility to relax context constraints by means of a fuzz factor. In our work the application of manipulations can be given a certain degree of fuzziness, the context of a difference is implicitly provided by its structure and the fuzz factor conveys the degree of structural similarity required for a modification to be operated. Other interesting proposals are Darcs [25] and Unison [26], text-based version management systems similar to CVS 6 . One of the main distinctive features of Darcs is an underlying theory of patches, on which it is coherently based. The representation of a patch is defined as the manipulations induced by that patch if applied in a certain context. In this paper the representation of a delta is the set of changes caused by that document according to the input model and its matchings with difference elements. Concerning Unison, it is a file synchronizer whose job is to maintain consistency between replicated directory structures. Unison is endowed with different approaches for identifying filesystem differences. Unfortunately, these approaches are less appropriate for calculating the differences of models since they mainly rely on the Unix diff tool. Finally, from a different perspective, it may make sense to mention the FAMOOS project [21]. It is an interesting proposal whose goal is to build a framework to support the evolution and re-engineering of object–oriented software systems. In particular, the language-independent FAMIX meta-model [22] is often used for modelling snapshots in approaches which handle the history as a first class entity, as for instance in [23] where the Hismo metamodel is introduced. A similar mechanism is also provided by the OMG MOF Versioning and Development Lifecycle Specification [24]. With respect 6

CVS Project Web site: http://www.nongnu.org/cvs

Model Patches in Model-Driven Engineering

203

to those approaches, here subsequent versions are represented by models which are possibly related via difference models. In contrast with Hismo, we do not explicitly model history and versions. Thus, the approaches are somewhat orthogonal since we are able to specify arbitrary snapshots which are linked by automated transformations induced by the modifications.

5 Conclusions and Future Work Difference models can record the modifications a model undergoes during its life-cycle, as shown in [7]. By means of higher-order transformations it is possible to reproduce the modifications encoded in a difference model in order to reconstruct the newer version of a model starting from the old one. This paper presented an approach to generalize such construction and consider model differences as model patches, i.e. modifications which are formally described by a model and can be reproduced in any model conforming to the base metamodel. Such application is realized by coupling a difference model with a weaving model, that is a morphism between models, able to link the intended modifications to the model elements to be modified. Such morphism is called difference application model and can be defined i) by means of structual analysis, ii) in an implicit way, e.g. it can be derived directly from the persistent identifiers of the elements which are considered during the comparison, or iii) explicitly by the designer who intends to arbitrarily reproduce the modifications. In any case, at distinguished difference application models correspond different reproductions of the same modifications. Efficient and reliable extraction of differences among two models opens up many possibilities for future work. Especially we are interested in an industrial validation of the presented approach, but in order to pursue this objective a preliminary analysis of the available model differencing tools is necessary.

References 1. Schmidt, D.C.: Guest Editor’s Introduction: Model-Driven Engineering. Computer 39(2), 25–31 (2006) 2. B´ezivin, J.: On the Unification Power of Models. Jour. on Software and Systems Modeling (SoSyM) 4(2), 171–188 (2005) 3. Mens, T.: A State-of-the-Art Survey on Software Merging. IEEE Trans. Softw. Eng. 28(5), 449–462 (2002) 4. Lin, Y., Zhang, J., Gray, J.: Model Comparison: A Key Challenge for Transformation Testing and Version Control in Model Driven Software Development. In: OOPSLA Work. MDSD (2004) 5. Brun, C., Pierantonio, A.: Model Differences in the Eclipse Modeling Framework. UPGRADE, The European Journal for the Informatics Professional (April -May 2008) (to appear) 6. Cicchetti, A.: Difference Representation and Conflict Management in Model-Driven Engineering. PhD thesis, University of L’Aquila, Computer Science Dept. (2008) 7. Cicchetti, A., Di Ruscio, D., Pierantonio, A.: A Metamodel Independent Approach to Difference Representation. Journal of Object Technology 6(9), 165–185 (2007) 8. Rivera, J., Vallecillo, A.: Representing and Operating with Model Differences. In: Procs of the 46th Int. Conf. TOOLS EUROPE 2008 (2008) (to appear)

204

A. Cicchetti, D. Di Ruscio, and A. Pierantonio

9. Alanen, M., Porres, I.: Difference and Union of Models. In: Stevens, P., Whittle, J., Booch, G. (eds.) UML 2003. LNCS, vol. 2863, pp. 2–17. Springer, Heidelberg (2003) 10. Toulm´e, A.: The EMF Compare Utility, http://www.eclipse.org/modeling/emft/ 11. Lin, Y., Gray, J., Jouault, F.: DSMDiff: A Differentiation Tool for Domain-Specific Models. European Journal of Information Systems 16(4), 349–361 (2007); Special Issue on ModelDriven Systems Development 12. Ohst, D., Welle, M., Kelter, U.: Differences between versions of UML diagrams. In: ESEC/FSE-11: Proc. ESEC/FSE, pp. 227–236. ACM Press, New York (2003) 13. Melnik, S., Rahm, E., Bernstein, P.: Rondo: a programming platform for generic model management. In: Procs. Int. Conf. on Management of Data, pp. 193–204. ACM Press, New York (2003) 14. B´ezivin, J., Jouault, F., Rosenthal, P., Valduriez, P.: Modeling in the Large and Modeling in the Small. In: Aßmann, U., Aksit, M., Rensink, A. (eds.) MDAFA 2003. LNCS, vol. 3599, pp. 33–46. Springer, Heidelberg (2005) 15. Del Fabro, M.D., Valduriez, P.: Semi-automatic Model Integration using Matching Transformations and Weaving Models. In: The 22th ACM SAC - MT Track, pp. 963–970. ACM, New York (2007) 16. Cicchetti, A., Di Ruscio, D., Pierantonio, A.: ATL Use Case - A Metamodel Independent Approach to Difference Representation (February 2008), http://www.eclipse.org/m2m/atl/usecases/ MMIndApproachtoDiffRep/ 17. Jouault, F., Kurtev, I.: Transforming Models with ATL. In: Bruel, J.-M. (ed.) MoDELS 2005. LNCS, vol. 3844, pp. 128–138. Springer, Heidelberg (2006) 18. Varr´o, D., Pataricza, A.: Generic and Meta-Transformations for Model Transformation Engineering. In: International Conference on the Unified Modeling Language, pp. 290–304 (2004) 19. Eclipse project: GMF - Graphical Modeling Framework, http://www.eclipse.org/gmf/ 20. Kolovos, D.S., Paige, R.F., Polack, F.: Merging Models with the Epsilon Merging Language (EML). In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 215–229. Springer, Heidelberg (2006) 21. Baer, H., et al.: The FAMOOS Object-Oriented Reengineering Handbook (1999), http://www.iam.unibe.ch/˜famoos/handbook/4handbook.pdf 22. Tichelaar, S., Ducasse, S., Demeyer, S.: FAMIX and XMI. In: Proceedings WCRE 2000 Workshop on Exchange Formats, pp. 296–299 (2000) 23. Girba, T., Ducasse, S.: Modeling History to Analyze Software Evolution. J. Softw. Maint. Evol.: Res, Pract. 18, 207–236 (2006) 24. Object Management Group (OMG): MOF Versioning and Development Lifecycle Specification, v2.0, OMG Document: formal/07-05-01 (May 2007) 25. Roundy, D.: Darcs 1.1.0pre1 (June 30 2007), http://darcs.net/manual/darcs.html 26. Pierce, B.C., Vouillon, J.: What’s in Unison? A formal specification and reference implementation of a file synchronizer (2004)

Limitations of Automating Model Migration in Response to Metamodel Adaptation Markus Herrmannsdoerfer and Daniel Ratiu Institut f¨ ur Informatik Technische Universit¨ at M¨ unchen Boltzmannstr. 3, 85748 Garching b. M¨ unchen, Germany {herrmama,ratiu}@in.tum.de

Abstract. In consequence of changing requirements and technological progress, modeling languages are subject to change. When their metamodels are adapted to reﬂect those changes, existing models might become invalid. Manually migrating the models to the adapted metamodel is tedious. To substantially reduce eﬀort, a number of approaches have been proposed to fully automate model migration. However, the evolution of modeling languages occasionally leads to metamodel changes for which the migration of models inherently cannot be fully automated. In these cases, the migration of models requires information which is not available in the model. If such changes are ignored or circumvented, they may lead to language erosion. In this paper, we formally characterize metamodel adaptations in terms of the eﬀort needed for model migration. We focus on the problem of metamodel changes that prevent the automatic migration of models. We outline diﬀerent possibilities to systematically cope with these kinds of metamodel changes.

1

Introduction

Even though often neglected, a modeling language is subject to change like any other software artifact [1]. This holds for both general-purpose and domainspeciﬁc modeling languages. For instance, UML—a general purpose modeling language—already has a rich evolution history, although it is relatively young. Domain-speciﬁc modeling languages—like e. g. AUTOSAR for the speciﬁcation of automotive software architectures—are even more prone to change, as they have to be adapted whenever their domain changes due to technological progress or evolving requirements. A modeling language is evolved by adapting its metamodel to satisfy new requirements. Due to metamodel adaptation, existing models may no longer conform to the adapted metamodel. These models have to be migrated so that they can be used with the new version of the modeling language. Throughout the paper, the combination of metamodel adaptation and reconciling model migration is referred to as coupled evolution. Manually migrating existing models to the adapted metamodel is tedious and error-prone. Adequate tool support is thus required to reduce the eﬀort for model migration. S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 205–219, 2010. c Springer-Verlag Berlin Heidelberg 2010

206

M. Herrmannsdoerfer and D. Ratiu

To determine requirements for adequate tool support, we reverse engineered the coupled evolution of a number of real-world modeling languages [2,3]. More speciﬁcally, we classiﬁed the performed metamodel changes according to the automatability of the associated model migration. Metamodel-only changes do not require the migration of models, whereas coupled changes do. Metamodelindependent coupled changes do not depend on a speciﬁc metamodel. Metamodelspeciﬁc coupled changes are so speciﬁc to a certain metamodel that the migration cannot be reused across metamodels. Model-speciﬁc coupled changes require information from the modeler during migration, and thus the migration cannot be speciﬁed in a model-independent way. As no changes were classiﬁed as modelspeciﬁc, we decided to ignore them for the ﬁrst version of our tool called COPE. With adequate tool support at our hands, we started using COPE to forward engineer the coupled evolution of a number of modeling languages. From our experience with adapting several metamodels, we learned that sometimes changes requested by the users of the modeling language require a metamodel adaptation that prevents the automation of the model migration. Using our terminology presented above, we would say that these cases require a model-speciﬁc coupled evolution. Implementing such a change would invalidate the existing models, which have to be migrated manually. However, manually migrating a potentially unknown number of models imposes a heavy burden on the language users. Consequently, the language developers are tempted to avoid model-speciﬁc coupled evolution by adapting the metamodel in a way that the model migration does not require information from the users. However, not being able to implement such changes limits modeling language evolution, and threatens the simplicity and quality of the metamodel. In this paper, we provide a formal framework to characterize metamodel adaptations in terms of the eﬀorts needed for model migration. We focus on the problem of metamodel changes that prevent the automatic migration of models. We outline diﬀerent possibilities to systematically cope with these kinds of metamodel changes. Outline. In Sec. 2, we provide a number of examples to distinguish modelspeciﬁc coupled changes from other kinds of changes. In Sec. 3, we try to specify these coupled changes using our current tool COPE. Subsequently, we present the formal framework to generally characterize model-speciﬁc coupled evolution: we show how to formalize the syntax and semantics of a modeling language in Sec. 4; we formally characterize the evolution of a modeling language in Sec. 5; and ﬁnally, we formally deﬁne model-speciﬁc migration in Sec. 6. In Sec. 7, we outline a number of possible solutions to cope with model-speciﬁc coupled evolution. In Sec. 8, we analyze related work with respect to the support for model-speciﬁc coupled evolution, and we conclude our paper in Sec. 9.

2

Motivating Example

We choose a simple modeling language to specify I/O automata as our running example. To show diﬀerent levels of automating a model migration, we present a

Limitations of Automating Model Migration in Response $XWRPDWRQ

$XWRPDWRQ

VWDWH

VWDWH

RXWJRLQJ WDUJHW

6WDWH QDPH6WULQJ HIIHFW$FWLRQ

7UDQVLWLRQ WULJJHU(YHQW

(a) Original Metamodel $XWRPDWRQ

VWDWH 6WDWH QDPH6WULQJ HIIHFW$FWLRQ

RXWJRLQJ WDUJHW

6WDWH QDPH6WULQJ HIIHFW$FWLRQ

207

7UDQVLWLRQ WULJJHU(YHQW

(b) Introducing Hierarchical States $XWRPDWRQ

LQLWLDO

RXWJRLQJ WDUJHW

VWDWH 7UDQVLWLRQ WULJJHU(YHQW

(c) Introducing Initial States

LQLWLDO

6WDWH QDPH6WULQJ

RXWJRLQJ WDUJHW

7UDQVLWLRQ WULJJHU(YHQW HIIHFW$FWLRQ

(d) Moore to Mealy Automata

Fig. 1. Metamodel Adaptation

number of adaptations to the language’s metamodel. We ﬁrst present the diﬀerent metamodel adaptation steps, and then discuss reconciling model migrations. Metamodel Adaptation. Fig. 2 depicts the diﬀerent versions of the metamodel as UML class diagrams. For better overview, metamodel adaptations are highlighted by dashed boxes. Original Metamodel. Fig. 1(a) depicts the original version of the metamodel. An Automaton deﬁnes a number of named states. A State has a number of outgoing transitions each of which is activated by a trigger Event. When a Transition is activated, the control transitions to a target state. When the target state is entered, a sequence of Actions is performed as eﬀect. Introducing Hierarchical States. As is depicted in Fig. 1(b), we introduce hierarchical states to our modeling language to be able to structure complex automata. In the metamodel, we thus make Automaton a subclass of State. Now, a State can also be an Automaton which can again be decomposed into a number of states, and so on. Introducing Initial States. As is depicted in Fig. 1(c), we introduce initial states to reﬁne the modeling language. In the metamodel, the mandatory reference initial is introduced to denote the initial state within an automaton. Moore to Mealy Automata. As is depicted in Fig. 1(d), we change the modeling language from a Moore to a Mealy automaton to ease the speciﬁcation

208

M. Herrmannsdoerfer and D. Ratiu

of eﬀects. In Moore machines, the eﬀect of the automaton only depends on the current state. In contrast, the eﬀect of the automaton depends also on the trigger in Mealy machines. In the metamodel, we thus move the attribute eﬀect from State to Transition. Model Migration. We discuss the model migration for each metamodel adaptation step presented above in the order of decreasing automatibility. Note that this order is slightly diﬀerent from the temporal order in which the metamodel adaptations were performed. Introducing Hierarchical States. Existing models without hierarchy are not aﬀected by this metamodel adaptation, as they are still valid and have the same meaning. As a consequence, they do not have to be migrated, and the adaptation basically is a conservative extension. Moore to Mealy Automata. As eﬀects are no longer allowed for states, models no longer conform to the adapted metamodel. To migrate these models, the eﬀect of each transition has to be determined based on the states it enters. Note that this model migration can be fully automated by the well-known algorithm to transform Moore to Mealy automata. Introducing Initial States. As the introduced reference initial is mandatory, the model needs to be migrated to add the missing information. However, the initial states cannot be unambiguously inferred from the information already available in the model, and default values cannot be provided either. As a consequence, this model migration cannot be automated, as information is required from the developer of the model during migration. One solution would be to avoid the model-speciﬁc change. For example, we could make the new reference initial optional instead of mandatory in order not to invalidate existing models. However, our metamodel would not be as robust as we want it to be, and our tools would have to cope with missing initial states in an ad-hoc manner (each tool can interpret the initial states diﬀerently) and this would lead to ambiguities. As a result, this reduces the overall quality and simplicity of the modeling language and makes models fragile. To prevent such language erosion, we need to be able to support model-speciﬁc coupled evolution.

3

COPE – Coupled Evolution of Metamodels and Models

COPE is a tool to reduce the eﬀort associated with model migration by incrementally composing the coupled evolution of metamodels and models. COPE is implemented based on the Eclipse Modeling Framework (EMF). Overview of COPE. As is depicted in Figure 2, COPE allows the language developer to record the history of a metamodel. The history basically is a sequence of operations which adapt the metamodel. These operations can be enriched with instructions on how to migrate models in response to metamodel adaptation. As they thus couple metamodel adaptation with model migration, these operations are termed coupled operations. COPE provides two kinds of coupled operations: reusable and custom coupled operations.

Limitations of Automating Model Migration in Response

209

5HQDPH

6SHFLDOL]H6XSHU7\SH

1HZ5HIHUHQFH

([WUDFW&ODVV

,QVWDQWLDWLRQRI5HXVDEOH&RXSOHG2SHUDWLRQV

0HWDPRGHO OHYHO

0HWDPRGHO+LVWRU\

5HOHDVH

5HOHDVH

6SHFLDOL]H6XSHU7\SH

1HZ5HIHUH

&XVWRP&RXSOHG 2SHUDWLRQ

,QWURGXFLQJ+LH UDUFKLFDO6WDWHV

,QWURGXFLQJ ,QLWLDO6WDWHV

0RRUH7R0HDO\

0HWDPRGHO $GDSWDWLRQ

0RGHO 0LJUDWLRQ 2OG 0HWD PRGHO

&23(

0HWDPHWDPRGHO OHYHO

/LEUDU\RI5HXVDEOH&RXSOHG2SHUDWLRQV

1HZ 0HWD PRGHO

*HQHUDWLRQ

0RGHO OHYHO

FRQIRUPV7R

2OG 0RGHO

FRQIRUPV7R

,QSXW

0LJUDWRU

2XWSXW

1HZ 0RGHO

Fig. 2. Overview of COPE

Metamodel-only and metamodel-independent coupled changes can be reused across metamodels—reducing the eﬀort associated with model migration. Therefore, COPE provides reusable coupled operations which encapsulate metamodel adaptation and model migration in a metamodel-independent way. Reusable coupled operations are organized in a library which can be extended by declarations of new operations. The declaration is made independent of a speciﬁc metamodel through parameters, and may provide constraints to restrict the applicability of the operation. The operation SpecializeSuperType—which replaces a super type by one of its subclasses—e. g. can be used to introduce hierarchical states. Metamodel-speciﬁc coupled changes are so speciﬁc to a certain metamodel that reuse makes no sense. To be able to cover these model migrations, a custom coupled operation can be manually deﬁned by the language developer. In order to do so, the developer has to manually implement a model migration for a recorded metamodel adaptation. The model migration is implemented in a language provided by COPE which is expressive enough to cater for complex model migrations [4]. A custom coupled operation is e. g. necessary to transition from Moore to Mealy automata. Model-speciﬁc coupled changes are currently not supported, and hence we use the operation NewReference to introduce the reference initial as a placeholder.

M. Herrmannsdoerfer and D. Ratiu

&XVWRP&RXSOHG2SHUDWLRQ

RSHUDWLRQEURZVHU

5HXVDEOH&RXSOHG2SHUDWLRQV

PLJUDWLRQHGLWRU

KLVWRU\

PHWDPRGHOHGLWRU

210

Fig. 3. User Interface of COPE

A migrator can be generated from the history that allows for the batch migration of models. The migrator simply packages the sequence of coupled operations which can be invoked to automatically migrate existing models. User Interface of COPE. Fig. 3 shows COPE’s user interface which has been integrated into the existing structural metamodel editor provided by EMF. This metamodel editor has been extended so that it also provides access to the metamodel history. All reusable coupled operations in the library are made available to the language developer through a special view called operation browser. A migration editor with syntax highlighting is provided for the speciﬁcation of custom coupled operations. The developer can adapt the metamodel by invoking reusable coupled operations through the operation browser. The operation browser allows to set the parameters of a reusable coupled operation based on their type and gives feedback on its applicability based on the constraints. When a reusable coupled operation is executed, its invocation is automatically recorded in the metamodel history. Fig. 3 shows the SpecializeSuperType operation being available in the browser and some reusable coupled operations stored in the history.

Limitations of Automating Model Migration in Response

211

In case no reusable coupled operation is available for the change at hand, the language developer can perform a custom coupled operation. First, the metamodel is directly adapted in the metamodel editor, in response to which the changes are automatically recorded in the history. A migration can later be attached to the sequence of metamodel changes. Fig. 3 shows the model migration—implemented in COPE’s language—for the transition from Moore to Mealy automata in the migration editor. The operation browser provides a release button to create a major version of the metamodel. After release, the language developer can initiate the automatic generation of a migrator.

4

Defining Modeling Languages

Before we can characterize language evolution, we have to formally deﬁne our understanding of a modeling language. According to [5], a modeling language is speciﬁed through its abstract syntax and semantics. Definition 1 (Modeling language). A modeling language L = (M, SD, S) is a triple of abstract syntax M, semantic domain SD and semantic mapping S. The abstract syntax deﬁnes the (possibly inﬁnite) set of all models M = {m1 , m2 , . . .} that are syntactically correct. The semantic domain SD speciﬁes the concepts that exist in the universe of discourse, and the semantic mapping S : M → SD interprets a model from M w.r.t. to the semantic domain SD. A model is syntactically valid if it is built from the constructs and fulﬁlls the constraints deﬁned by the metamodel. For the sake of simplicity, we omit the formalization of the relationship between model and metamodel here. Two models m1 , m2 ∈ M are syntactically equivalent if and only if m1 = m2 . Note that, in practice, usually only a small subset Mbuilt ⊂ M of the possible models are actually built. Since the semantics S is a total function, each well-formed model has associated a semantics. Furthermore, we require the notions of semantic equivalence ≡ and reﬁnement on the semantic domain. Two models m1 , m2 ∈ M are semantically equivalent, if the interpretation returns equivalent objects from the semantic domain, i. e. S(m1 ) ≡ S(m2 ). A model m1 ∈ M is a reﬁnement of m2 ∈ M, if the interpretation of model m1 reﬁnes the interpretation of model m2 , i. e. S(m1 ) S(m2 ). Example. The abstract syntax of the example modeling language presented in Sec. 2 deﬁnes a dialect of I/O automata. The instances of a class in the metamodel can be accessed through a set with its name: e. g. Automaton to access all instances {a1 , a2 , . . .} of the class Automaton. The associations in the metamodel can be followed by functions applied to instances: e. g. state : Automaton → P(State) to access the states of an automaton. Notationally, a.state is the same as state(a).

212

M. Herrmannsdoerfer and D. Ratiu

As semantic domain, we choose the behavior of automata. One possibility to deﬁne the behavior of I/O automata is through a function that maps a stream of events onto a stream of actions [6], i. e. SD : Event∗ → P(Action∗ ). Note that this semantic domain allows to specify non-deterministic behavior, as an event stream can lead to a set of action streams. The semantic mapping S : Automaton → SD maps an automaton a ∈ Automaton to its behavior S(a) ∈ SD. We use S(a, es) as a notation for (S(a))(es). Two automata a1 , a2 ∈ Automaton are semantically equivalent if S(a1 , es) = S(a2 , es)—meaning that for all possible event streams es ∈ Event∗ we have the same actions. A possible deﬁnition of reﬁnement is the subset relationship on sets of streams: An automaton a1 ∈ Automaton reﬁnes another automaton a2 ∈ Automaton if S(a1 , es) ⊆ S(a2 , es) for all possible event streams es ∈ Event∗ —i.e. exhibits less non-determinism. In the following, we use the version number as index to distinguish the classes from diﬀerent language versions, i. e. Automaton1 to denote the automata conforming to language version 1. Original Metamodel. The behavior of an automaton a ∈ Automaton1 for an event stream es = e1 , e2 , . . . ∈ Event∗ is deﬁned as the union of the behavior of its states: S1 (a, es) = s.eﬀect ◦ S1 (s, es) (1) s∈a.state

The operator ◦ concatenates streams and is automatically lifted to sets of streams. The behavior of a state s ∈ State1 is deﬁned as the union of the behavior of the states to which the control can transition: S1 (s, e ◦ es) = t.target.eﬀect ◦ S1 (t.target, es) (2) t∈activated1 (s,e)

in case there is at least one transition activated by event e ∈ Event, i. e. activated1 (s, e)

= ∅. Otherwise—in case there is no transition activated—the automaton remains in the same state: S1 (s, e ◦ es) = S1 (s, es) When there are no more events left to be processed, then of course S1 (s, ) = {}. The set of transitions activated by an event e ∈ Event in a state s ∈ State is the set of outgoing transitions having the event as trigger: activated1 (s, e) = {t ∈ s.outgoing | t.trigger = e}

(3)

Introducing Hierarchical States. To introduce hierarchical states, we have to adapt formula (3) to also take into account the transitions inherited from parent states: activated2 (s, e) = activated1 (p, e) p∈s.parent∗

Limitations of Automating Model Migration in Response

213

where parent : State2 → Automaton2 is the opposite of the association state, and ∗ is the transitive closure. The other formulas do not need to be adapted and thus stay the same. Note that the formulas are polymorphic, i. e. S2 (s, es) in formula (2) is automatically redirected to formula (1), in case s ∈ Automaton2 . Introducing Initial States. To introduce initial states, we only have to adapt formula (1) to take the initial state of an automaton into account: S3 (a, es) = a.initial.eﬀect ◦ S3 (a.initial, es) In this change, we have reﬁned the behavior of an automaton by removing possible executions. In other words, we removed non-determinism generated by the choice between more initial states. The developer of the model has to decide which executions to remove by choosing an initial state for each automaton. Moore to Mealy Automata. To transition from Moore to Mealy automata, we only have to adapt formulas (1) and (2) to consider the eﬀect of the transition instead of the eﬀect of its target state: S4 (a, es) = S4 (a.initial, es) S4 (s, e ◦ es) = t.eﬀect ◦ S4 (t.target, es) t∈activated4 (s,e)

5

Characterizing Language Evolution

A language evolution is usually reﬂected by the adaptation of the metamodel and/or by the adaptation of the semantics. In the following, we talk about two language versions L1 = (M1 , SD 1 , S1 ) and L2 = (M2 , SD2 , S2 ), where L1 evolved to L2 . For simplicity’s sake, we assume that the semantic domain remains the same during language evolution, i. e. SD 1 = SD 2 . Consequently, only the abstract syntax and the semantic mapping change from one language version L1 = (M1 , SD, S1 ) to the next language version L2 = (M2 , SD, S2 ). Definition 2 (Conservative extension). L2 is a conservative extension of L1 if and only if M1 ⊂ M2 and S1 (m) ≡ S2 (m) for all m ∈ M1 . A conservative extension thus does not syntactically invalidate existing models and preserves their meaning. An extension can occur when new constructs are added to the metamodel, when existing constructs are extended, or when constraints are removed or weakened. Definition 3 (Restriction). L2 is a restriction of L1 if and only if M2 ⊂ M1 . A restriction syntactically invalidates a number of models, namely M1 \M2 , which have to be migrated. A restriction can occur when constructs are removed from the metamodel, when existing constructs are restricted, or when constraints are added or strengthened. In general, a new version of the language exhibits both restrictions and extensions which we call variations.

214

M. Herrmannsdoerfer and D. Ratiu

Definition 4 (Variation). L2 is a variation of L1 if and if only M2 \ M1

= ∅ ∧ M1 \ M2

= ∅. A variation invalidates outdated models, namely Mo = M1 \ M2 , which have to be migrated. In practice, only those outdated models need to be migrated that are actually built, i. e. Mbuilt ∩ Mo . Example. Introducing Hierarchical States. The introduction of hierarchical states to the modeling language as depicted in Fig. 1(b) is an example of a conservative extension. Existing ﬂat automata are still valid with respect to the adapted metamodel and have the same meaning. The meaning of all models is preserved, since for ﬂat automata, the adapted semantics does not change the transitions activated in a state. The inverse evolution—from Fig. 1(b) back to Fig. 1(a)—is a restriction, as automata with hierarchy are no longer valid and thus have to be ﬂattened. Moore to Mealy Automata. The transition from Moore to Mealy automata is a variation. All models that deﬁne eﬀects for their states are no longer valid, but we now allow new models that deﬁne eﬀects for their transitions. We have to ﬁnd a mapping that migrates the outdated models to the new language version and preserves the semantics of the models. Introducing Initial States. The introduction of initial states is a variation, since it allows to build new automata with initial states and at the same time requires old automata to deﬁne initial states.

6

Characterizing Model-Specific Migration

As we have seen before, models may have to be migrated to preserve their meaning in response to language evolution. A model migration is deﬁned by a migration function which maps the models from the old language L1 to models of the new language L2 . Definition 5 (Migration function). A migration function is a function µ : M1 → M2 which maps each model m ∈ M1 to a model µ(m) ∈ M2 . Typically, we require that the migration function preserves the semantics of all models. Otherwise, information is lost during migration which needs to be avoided. Definition 6 (Language refactoring). A language refactoring is a change to the language which allows to build a migration function µ that preserves the semantics of the models, i. e. S2 (µ(m)) ≡ S1 (m) for all m ∈ M1 . However, there are cases in which the language is changed in a way that we cannot build a semantics-preserving migration. Definition 7 (Language refinement). A language reﬁnement is a change to the language which allows to build a migration function µ that reﬁnes the semantics of the models, i. e. S2 (µ(m)) S1 (m) for all m ∈ M1 .

Limitations of Automating Model Migration in Response

215

When a language is reﬁned, often the migration cannot be performed without information which is not available in the original model as shown below. Definition 8 (Model-specific migration). Let E : M1 → P(M2 ) with E(m1 ) = {m2 ∈ M2 | S2 (m2 ) S1 (m1 )} be the models from M2 that reﬁne a model from M1 after language reﬁnement. A migration µ is model-speciﬁc if and only if a model m1 ∈ M1 exists for which |E(m1 )| > 1. A migration has to be model-speciﬁc, if several models in M2 exist which semantically reﬁne a model in M1 . In this case, additional information is necessary during migration to choose one of these semantically equivalent models. The set for which the migration has to be model-speciﬁc is Mms = {m1 ∈ M1 | |E(m1 )| > 1}. Again, only those models are problematic which are built and require model-speciﬁc migration, i. e. Mbuilt ∩ Mms . A migration is thus modelindependent if |E(m1 )| = 1 for all m1 ∈ M1 . Example. Moore to Mealy Automata. The transition from Moore to Mealy automata as depicted in Fig. 1(d) is a language refactoring. The transition requires a migration function that maps all models with eﬀects in states to models with eﬀects in transitions. To preserve the meaning of all models, the migration function has to determine the eﬀect of a transition based on the state it enters. For a transition t ∈ T ransition3 which is mapped to t ∈ T ransition4 by the function µ34 to migrate models from language version 3 to 4 (i.e. t = µ34 (t)), t .eﬀect = eﬀect(t.target) is fulﬁlled with: s.eﬀect ◦ eﬀect(s.initial), if s ∈ Automaton3 eﬀect(s) = s.eﬀect, if s ∈ State3 Again, the indices denote the language version of the class. When a transition enters an automaton, we do not only have to take its eﬀect into account but also the eﬀect of its initial state. Note that this may have to be applied recursively, as the initial state may again be an automaton, and so on. Using the deﬁnition of the semantics, we can easily prove that this migration function preserves the meaning of all models. No additional information is required during migration, and we can thus specify an algorithm that automatically performs the migration. The implemented algorithm is displayed in the migration editor in Fig. 3. Introducing Initial States. The introduction of mandatory initial states as is depicted in Fig. 1(c) is a language reﬁnement. A model migration µ23 from language version 2 to 3 cannot always preserve the semantics, but has to reﬁne it (a = µ23 (a)): S3 (a , es) = S3 (a .initial, es) ⊆ S2 (s, es) = S2 (a, es) s∈a.state

As a consequence, a number of models with diﬀerent choices for initial states are possible reﬁnements for each model without initial states. Model-speciﬁc information is required to choose the one that is intended by the developer of the model.

216

7

M. Herrmannsdoerfer and D. Ratiu

Coping with Model-Specific Migration

We outline a number of possible solutions to cope with model-speciﬁc coupled evolution. The solutions take advantage of particular situations which are however encountered very often in practice. Eﬀort analysis. In practice, only a small subset of all possible models M are actually built. Only the existing models need to be migrated. In many practical situations (e. g. for languages developed only for use inside an organization), the language developers and users are quite close to each other. In these situations, it is often the case that the entire set of the existing models is known to the language developers. For instance, whenever the language is used only in-house, all models are contained in a central repository. In case when all models are known, language developers can make informed language improvements also with respect to the eﬀort needed for model migration. Based on the existing models, they can assess the manual migration eﬀort required after metamodel adaptation. For instance, the eﬀort needed to introduce initial states is proportional to the number of automata in the existing models, as an initial state has to be chosen for each automaton. They can decide whether a language improvement is worth making given the amount of manual work necessary to migrate the existent models. However, in a lot of cases, language developers and users are decoupled which makes this approach infeasible. Interactive migration. One possibility to support model-speciﬁc coupled evolution is to provide user interaction during migration. The migration algorithm automatically migrates the model as far as possible, and whenever it needs supplementary information, it asks the language user to provide the missing information. It can also suggest a number of alternatives from which the language user has to choose. We have extended COPE’s language to implement a model migration with a primitive to trigger such an interaction during migration. The following snippet shows the use of this primitive in an interactive coupled operation that introduces initial states in the language: // metamodel adaptation newReference(Automaton, "initial", State, 1, 1, !CONTAINMENT) // model migration for(a in Automaton.allInstances) { a.initial = choose(a, a.state, "Choose initial state") }

The metamodel adaptation creates the new reference initial which is mandatory (lower bound 1), single-valued (upper bound 1) and not a composition (not containment). During model migration, the developer of the model has to choose an initial state for each automaton. The primitive choose takes three parameters as input—namely the context element, the values to choose from and a message, and returns the chosen value. Figure 4 shows the dialog that is opened during model migration to let the language user make a choice. The dialog shows the current state of the model

Limitations of Automating Model Migration in Response

217

Fig. 4. COPE’s User interface for interactive coupled operations

(selecting the context element), the list of values to choose from, as well as the message. The developer of the model is required to choose a value from the list to determine the initial state within an automaton. Implicit information. Many times, the language users employ diﬀerent conventions (e. g. naming conventions) to capture more information than is made explicit through the metamodel. In these cases, the language user can incorporate implicit information to help automate the migration. For example, language users might have already named all initial states with a preﬁx ”I”, before the initial states were explicitly introduced in the metamodel. They can then reﬁne the migration in a way that for each automaton, it automatically chooses the marked sub state. We thus plan to introduce a means to allow the language user to upfront establish certain choices introduced by the language developer.

8

Related Work

Current approaches to reduce the eﬀort for model migration focus on fully automating the model migration. They thus do not address model-speciﬁc coupled evolution which can inherently not be fully automated. We believe that the current language evolution approaches do not support model-speciﬁc migration, because the problem is not completely understood yet. With this paper, we thus aimed to characterize the problem and outlined possible solutions. Related work on model migration can be subdivided into two kinds of approaches: diﬀerencebased and operation-based. Diﬀerence-based approaches allow language developers to synthesize a model migration based on the diﬀerence between two metamodel versions. Sprinkle et al.

218

M. Herrmannsdoerfer and D. Ratiu

introduce a visual graph-transformation-based language which requires to specify the model migration only for the metamodel diﬀerence [7]. However, this language does not provide constructs to cater for model-speciﬁc migrations. The following approaches further automate model migration by automatically deriving it from the diﬀerence between two metamodel versions. Gruschko et al. classify primitive metamodel changes into non-breaking, breaking resolvable and unresolvable changes [8,9]. Based on this classiﬁcation, they propose to automatically derive a migration for non-breaking and resolvable changes. Cichetti et al. go even one step further and try to detect composite changes like e. g. extract class in the diﬀerence between metamodel versions [10,11]. Garces et al. reﬁne this approach, present a prototype and demonstrate its applicability in two case studies [12]. However, the derivation approaches currently are not able to detect model-speciﬁc migrations in the metamodel diﬀerence. Operation-based approaches allow language developers to incrementally transform the metamodel by means of coupled operations which also encapsulate the corresponding model migration. Although they are not as automated as diﬀerence-based approaches, they allow to capture the intended model migration already when adapting the metamodel. H¨oßler and Soden present a number of reusable coupled operations which automate metamodel adaptation as well as model migration [13]. Wachsmuth adopts ideas from grammar adaptation and proposes a classiﬁcation of metamodel changes based on instance preservation properties [14]. Based on these preservation properties, the author deﬁnes a library of reusable coupled operations. In [3,4] we generalize these approaches by a language which allows to specify arbitrary new reusable coupled operations. Moreover, this language can be used to attach a custom migration to a metamodel adaptation, which cannot be covered by reusable coupled operations. We demonstrate the usefulness of this approach by presenting the coupled evolution of two real-life metamodels. However, all of these approaches do not provide coupled operations which support model-speciﬁc migrations. In this paper, we thus extended our language for expressing coupled operations with a choice construct that allows the user to guide the migration.

9

Conclusion

Modeling languages evolve over time, and thereby their metamodels need to be adapted. To reduce the eﬀort for language evolution, the resulting migration of models needs to be automated. However, some metamodel changes require information during migration which is not available in the model. Consequently, these metamodel changes inherently prevent the automatic migration of models. In this paper, we presented an example of such model-speciﬁc changes and formally characterized them. Moreover, we presented a number of techniques to cope with model-speciﬁc migrations. With these techniques, language developers can make informed decisions about the eﬀort needed for manual migration, and partially automate the manual migration by means of adequate tool support. As

Limitations of Automating Model Migration in Response

219

a consequence, language erosion can be prevented which can result from avoiding model-speciﬁc changes. It remains to be investigated how much a language suﬀers from systematically avoiding model-speciﬁc changes. Moreover, we are interested in how often model-speciﬁc changes are actually required in practice. Acknowledgments. This work was partially funded by the German Federal Ministry of Education and Research (BMBF), grant “SPES2020, 01IS08045A”.

References 1. Favre, J.M.: Languages evolve too! changing the software time scale. In: 8th International Workshop on Principles of Software Evolution (IWPSE), pp. 33–44. IEEE Computer Society, Los Alamitos (2005) 2. Herrmannsdoerfer, M., Benz, S., Juergens, E.: Automatability of Coupled Evolution of Metamodels and Models in Practice. In: Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., V¨ olter, M. (eds.) MODELS 2008. LNCS, vol. 5301, pp. 645–659. Springer, Heidelberg (2008) 3. Herrmannsdoerfer, M., Benz, S., Juergens, E.: COPE - Automating Coupled Evolution of Metamodels and Models. In: Drossopoulou, S. (ed.) ECOOP 2009. LNCS, vol. 5653, pp. 52–76. Springer, Heidelberg (2009) 4. Herrmannsdoerfer, M., Benz, S., Juergens, E.: COPE: A Language for the Coupled Evolution of Metamodels and Models. In: 1st International Workshop on Model Co-Evolution and Consistency Management, MCCM (2008) 5. Harel, D., Rumpe, B.: Meaningful modeling: what’s the semantics of ”semantics”? Computer 37(10), 64–72 (2004) 6. Rumpe, B.: A note on semantics (with an emphasis on UML). In: 2nd ECOOP Workshop on Precise Behavioral Semantics (1998) 7. Sprinkle, J., Karsai, G.: A domain-speciﬁc visual language for domain model evolution. Journal of Visual Languages and Computing 15, 291–307 (2004) 8. Becker, S., Gruschko, B., Goldschmidt, T., Koziolek, H.: A Process Model and Classiﬁcation Scheme for Semi-Automatic Meta-Model Evolution. In: 1st Workshop MDD, SOA und IT-Management (MSI), GI, pp. 35–46. GiTO-Verlag (2007) 9. Gruschko, B., Kolovos, D., Paige, R.: Towards synchronizing models with evolving metamodels. In: International Workshop on Model-Driven Software Evolution, MoDSE (2007) 10. Cicchetti, A., Ruscio, D.D., Eramo, R., Pierantonio, A.: Automating co-evolution in model-driven engineering. In: Ceballos, S. (ed.) 12th International Enterprise Distributed Object Computing Conference (EDOC). IEEE Computer Society, Los Alamitos (2008) 11. Cicchetti, A., Ruscio, D.D., Pierantonio, A.: Managing dependent changes in coupled evolution. In: Paige, R.F. (ed.) ICMT 2009. LNCS, vol. 5563, pp. 35–51. Springer, Heidelberg (2009) 12. Garc´es, K., Jouault, F., Cointe, P., B´ezivin, J.: Managing model adaptation by precise detection of metamodel changes. In: Paige, R.F., Hartman, A., Rensink, A. (eds.) ECMDA-FA 2009. LNCS, vol. 5562, pp. 34–49. Springer, Heidelberg (2009) 13. H¨ oßler, J., Soden, M., Eichler, H.: Coevolution of Models, Metamodels and Transformations. In: Models and Human Reasoning, pp. 129–154. Wissenschaft und Technik Verlag, Berlin (2005) 14. Wachsmuth, G.: Metamodel adaptation and model co-adaptation. In: Ernst, E. (ed.) ECOOP 2007. LNCS, vol. 4609, pp. 600–624. Springer, Heidelberg (2007)

Recent Advances in Multi-paradigm Modeling Vasco Amaral1 , C´ecile Hardebolle2 , Gabor Karsai3, L´ aszl´o Lengyel4 , and Tiham´er Levendovszky3 1

Universidade Nova de Lisboa [email protected] 2 Sup´elec - Computer Science Department, France [email protected] 3 Vanderbilt University {gabor,tihamer}@isis.vanderbilt.edu 4 Budapest University of Technology and Economics [email protected]

Abstract. Model-Based Design of complex software systems is an activity that requires the use of diﬀerent modeling formalisms, with diﬀerent perspectives of the system, to cover all relevant aspects of the system, to avoid over-design, to employ manageable models and to support system integration. The comprehensive use of models in design has created a set of challenges beyond those of supporting one isolated design task. In particular, the need to combine, couple, and integrate models at diﬀerent levels of abstraction and in diﬀerent formalisms is posing a set of speciﬁc problems that must be tackled. Multi-Paradigm Modeling is precisely the research ﬁeld to focus on developing an appropriate set of concepts and tools to address the challenge of integrating models of diﬀerent aspects of a software system speciﬁed using diﬀerent formalisms and eventually at diﬀerent levels of abstraction. This paper summarizes the results of the 3rd Workshop on Multi-Paradigm Modeling: Concepts and Tools.

1

Introduction

Computational modeling has become the norm in the industry to remain competitive and be successful. As such, Model-Based Design of embedded software has enterprise-wise implications and modeling is not limited to isolated uses by a single engineer or team. Instead, it has reached a proliferation much akin to large software design, with requirements for infrastructure support such as version control, conﬁguration management, and automated processing. The comprehensive use of models in design has created a set of challenges beyond that of supporting one isolated design task. In particular, the need to combine, couple, and integrate models at diﬀerent levels of abstraction and in diﬀerent formalisms is posing a set of speciﬁc problems that the ﬁeld of Computer Automated Multiparadigm Modeling (CAMPaM) is aiming to address. The essential element of multiparadigm modeling is the use of explicit models throughout the engineering process. This leads to a framework with models to S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 220–224, 2010. c Springer-Verlag Berlin Heidelberg 2010

Recent Advances in Multi-paradigm Modeling

221

represent the syntax of formalisms used for modeling, models of the transformations that represent the operational semantics, as well as model-to-model transformations for inter-formalism transformation. These models are then used to facilitate generative tasks in language engineering, such as evolving a domainspeciﬁc modeling formalism as its requirements change, as well as in the tool engineering space, such as the automatic generation of integrated development environments. Moreover, given an explicit model of model transformations allows analysis such as termination characteristics, consistency, and determinism. In the rest of this paper, we summarize the results of the third Workshop on Multi-Paradigm Modeling: Concepts and Tools. We report the diﬀerent contributions in Section 2 and we elaborate on future research directions of CAMPaM that will be discussed in the next edition of this workshop in Section 3.

2 2.1

Current Trends in Multi-paradigm Modeling MPM Applications

Because it is focused on the problems raised by the necessary use of multiple modeling formalisms and paradigms, Multi-Paradigm Modeling is inherently a multidisciplinary ﬁeld. Several contributions to the workshop illustrated well that, as such, the MPM ﬁeld has multiple applications in various domains such as optical networks, cyber-physical systems, robotics and control software systems. Gheorghe et al. [1] presented an approach for the global validation of the behavior of a passive integrated photonic routing structure. This approach uses models which are based on timed automata. The authors showed how their approach applies to modeling, simulation and formal veriﬁcation and they presented an illustrative case study. In the domain of cyber-physical systems, one major diﬃculty is the heterogeneity of their components (such as sensors, actuators, signal processing units), which makes modeling and automated model processing diﬃcult. Rajhans et al. [2] illustrated well this problem and proposed an extension of an architectural approach with a graphical notation in order to model and analyze the behavior of cyber-physical systems. In this approach, the components of a cyber-physical system are described as ﬁnite state processes and linear hybrid automata which are combined with the architectural model of the system. Schuster et al. [3] introduced an approach dedicated to the building of component based robotics applications. The goal of their approach is the synthesis of combinations of reusable components for experimental simulations of robotics software. To this end, they designed a domain speciﬁc modeling language which helps integrating heterogeneous components. They illustrated their approach with an autonomous ground vehicle example. Control software systems have various uses. The work by Schiﬀelers et al. [4] and by Groothuis et al. [5] regard respectively supervisory controllers for plants and embedded control software for mechatronic systems. Schiﬀelers et al. integrated supervisory control theory and model based engineering to build a framework which is based on the Compositional Interchange Format for hybrid systems

222

V. Amaral et al.

(CIF). The goal of their framework is the synthesis of the supervisory controller of a plant and the joint simulation of the model of the plant and of the model of its controller. Groothuis et al. proposed a tool-independent methodology for the concurrent design of the components of a mechatronic system. They illustrated the advantages of their methodology on a production cell case study. All of these contributions clearly demonstrate the variety of the applications of the MPM domain. 2.2 MPM Concepts for Composition and Integration Current work in Multi-Paradigm modeling involves the deﬁnition of new concepts for composing or integrating heterogeneous models. This topic is, together with model transformations, one of the most important challenges for the MPM research ﬁeld. Three contributions regarding this topic have been presented during the workshop. Jiang et al. [6] proposed an approach to model dependencies between elements of diﬀerent models. Based on UML collaboration diagrams with a providerconsumer pattern, this approach allows the management of model references. Yie et al. [7] suggested a method for composing heterogeneous models that represent diﬀerent views of a system by transforming them to a low-level homogeneous platform. The composition at the low level is driven by correspondence relations which are expressed at the model level. While in the two previous approaches the composition operation is made at the model level, the work by Barroca et al. [8] regards the composition at the meta-model level, which implies the composition of languages. They presented an approach for DSL composition that aims at making test generation easier. Based on SATEL, a model based testing language, and on Prolog, they deﬁne a methodology and they implemented a framework for composing SATEL with any DSL in order to allow test generation. Discussions during the workshop showed that this topic on model composition is of very high interest but one that also raises a number of very diﬃcult issues. Existing approaches address mostly the composition at the syntactic level. The composition at the semantic level is still a quite open issue. 2.3 MPM Concepts for Model Transformation Other contributions to the workshop emphasized the importance of the second main challenge in the MPM ﬁeld: model transformation. Work on this topic seem to be more mature than work on model and language composition. K¨ uhne et. al [9] presented their work on the explicit modeling of model transformations. They provide tools to generate model transformation languages semiautomatically. As a result, model transformation languages can be tailored to the source and target languages of transformations, in the same way as Domain Speciﬁc Languages (DSLs) are tailored to domain models. Their goal is to allow for easier modiﬁcation of the control ﬂow of transformations and for easier mapping and pattern matching at both syntax and semantics levels, thus facilitating transformation evolution. They demonstrated how their approach applies successfully to Higher Order Transformation (HOT).

Recent Advances in Multi-paradigm Modeling

223

In [10], Meszaros et al. chose to apply model transformation techniques to model animation. Their approach is composed of a visual method to describe the dynamic behavior of visual languages coupled to a model transformation method to obtain models in an executable form which can be animated by their VMTS Animation Framework. Finally, Mark Asztalos et. al [11] presented their work on the veriﬁcation of model transformation. Using a reasoning system, they are able to automatically generate the proof of some properties on a model transformation. They illustrated their approach on a model transformation which refactors business process models.

3

Conclusion

A signiﬁcant part of the workshop was devoted to discussions with the objective of exchanging ideas on directions, open problems, and current ”hot topics” of the MPM domain. Diﬀerent topics were proposed, among which the most characteristic were semantic issues in model composition and meta-model composition, traceability issues in heterogeneous models, evolution issues for heterogeneous models and meta-models, concrete syntax and visualization issues in heterogeneous languages, and higher-order transformations. The participants agreed upon the following three most important challenge problems: (i) concrete syntax and visualization problems, (ii) semantics and composition of semantics, and (iii) higher order transformations. Finally, we would like to thank the reviewers who helped us make this workshop successful. In particular, we are indebted to Frederic Boulanger (Supelec), Peter Bunus (Linkoping University), Holger Giese (Hasso Plattner Institute), Reiko Heckel (University of Leicester), Thomas Kuehne (Victoria University of Wellington), Juan de Lara (Universidad Autonoma de Madrid), Edward A. Lee (UC Berkeley), Florence Maraninchi (Verimag), Pieter J. Mosterman (The MathWorks Inc.), Jose Risco-Martin (Universidad Complutense de Madrid), Hessam S. Sarjoughian (Arizona State University), Jonathan Sprinkle (University of Arizona), Mamadou K. Traore (Blaise Pascal University), Jeroen Voeten (Eindhoven University of Technology) and Hans Vangheluwe (McGill University).

References 1. Gheorghe, L., Nicolescu, G., O’Connor, I.: Modeling and formal veriﬁcation of a passive optical network on chip behavior. In: Proceedings of the 3rd International Workshop on Multi-Paradigm Modeling: Concepts and Tools, colocated with the ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems, Denver, Colorado, USA, October 6 (2009) 2. Rajhans, A., wen Cheng, S., Schmerl, B., Garlan, D., Krogh, B.H., Agbi, C., Bhave, A.: An architectural approach to the design and analysis of cyber-physical systems. In: Proceedings of the 3rd International Workshop on Multi-Paradigm Modeling: Concepts and Tools, colocated with the ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems, Denver, Colorado, USA, October 6 (2009)

224

V. Amaral et al.

3. Schuster, A., Sprinkle, J.: Synthesizing executable simulations from structural models of component-based systems. In: Proceedings of the 3rd International Workshop on Multi-Paradigm Modeling: Concepts and Tools, Denver, Colorado, USA, October 6 (2009) 4. Schiﬀelers, R., Theunissen, R., van Beek, D., Rooda, J.: Model-based engineering of supervisory controllers using CIF. In: Proceedings of the 3rd International Workshop on Multi-Paradigm Modeling: Concepts and Tools, colocated with the ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems, Denver, Colorado, USA, October 6 (2009) 5. Groothuis, M., Frijns, R., Voeten, J., Broenink, J.: Concurrent design of embedded control software. In: Proceedings of the 3rd International Workshop on MultiParadigm Modeling: Concepts and Tools, colocated with the ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems, Denver, Colorado, USA, October 6 (2009) 6. Jiang, J., Systa, T.: A pattern-based approach to manage model references. In: Proceedings of the 3rd International Workshop on Multi-Paradigm Modeling: Concepts and Tools, colocated with the ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems, Denver, Colorado, USA, October 6 (2009) 7. Yie, A., Casallas, R., Deridder, D., Wagelaar, D.: A practical approach to multimodeling views composition. In: Proceedings of the 3rd International Workshop on Multi-Paradigm Modeling: Concepts and Tools, colocated with the ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems, Denver, Colorado, USA, October 6 (2009) 8. Barroca, B., L´ ucio, L., Buchs, D., Amaral, V., Pedro, L.: Dsl composition for modelbased test generation. In: Proceedings of the 3rd International Workshop on MultiParadigm Modeling: Concepts and Tools, colocated with the ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems, Denver, Colorado, USA, October 6 (2009) 9. K¨ uhne, T., Mezei, G., Syriani, E., Vangheluwe, H., Wimmer, M.: Explicit transformation modeling. In: Proceedings of the 3rd International Workshop on MultiParadigm Modeling: Concepts and Tools, colocated with the ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems, Denver, Colorado, USA, October 6 (2009) 10. Meszaros, T., Levendovszky, T., Mezei, G.: Code generation with the model transformation of visual behavior models. In: Proceedings of the 3rd International Workshop on Multi-Paradigm Modeling: Concepts and Tools, colocated with the ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems, Denver, Colorado, USA, October 6 (2009) 11. Asztalos, M., Lengyel, L., Levendovszky, T.: Toward automated veriﬁcation of model transformations: A case study of analysis of refactoring business process models. In: Proceedings of the 3rd International Workshop on Multi-Paradigm Modeling: Concepts and Tools, colocated with the ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems, Denver, Colorado, USA, October 6 (2009)

Deriving Correspondence Relationships to Guide a Multi-view Heterogeneous Composition Andrés Yie1,2 , Rubby Casallas1, Dirk Deridder2 , and Dennis Wagelaar2 1

Grupo de Construcción de Software, Universidad de los Andes, Colombia {a-yie,rcasalla}@uniandes.edu.co 2 Software Languages Lab, Vrije Universiteit Brussel, Belgium {ayiegarz,dennis.wagelaar,dirk.deridder}@vub.ac.be

Abstract. The use of several view models is a common practice to specify diverse concerns of a complex system. It is advantageous to use appropriate Domain-Specific Modeling Languages, at high-level of abstraction, to specify each concern. To actually produce the running application, it is necessary not only to transform the view-models into code, but also to compose them. We can establish at the high-level correspondence relationships between the concepts in the different concerns, but it is a complex task to compose the models at this level because we face a heterogeneous composition problem. Therefore, our strategy is to independently transform each view model into a common low-level language to perform a homogeneous composition. We create a mechanism to automatically derive correspondence relationships between the generated low-level models. These new correspondences contain the information to guide a homogeneous composition. Keywords: Model Driven Engineering, Model transformation, Model composition, Multi-paradigm modeling.

1

Introduction

The use of several models to specify a complex system is a common practice in software engineering. The main objective is to provide the most appropriate abstractions to specify the diverse concerns involved (e.g., UML Class diagrams to specify structure, UML State charts to specify behavior); each of these models is called a view model. Some approaches use Domain-Specific Modeling Languages (DSMLs) trying to reduce the gap between the problem and the solution domains. The use of several DSMLs helps experts to express the system specifications. Having the correct DSML for each concern reduces the accidental complexities introduced while specifying it using a unsuitable language. When several view models are used to specify a system, it is necessary to compose them to generate the application. When the models are expressed in different DSMLs a problem arises

This research was performed in the context of the Caramelos project (VLIR), the VariBru project (ISRIB), and the MoVES project (IAP, Belgian Science Policy).

S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 225--239, 2010. c Springer-Verlag Berlin Heidelberg 2010

226

A. Yie et al.

because a heterogeneous composition is required (e.g., composition of a business entity from a business DSML and a secured resource from the security DSML). This means that it is necessary to have different composition mechanism for every pair of DSMLs. A possible approach to avoid a heterogeneous composition is to transform the diverse models into low-level models using a common low-level modeling language [1]. Moreover, this common low-level modeling language can be a GeneralPurpose Language (GPL) to implement the application. Therefore, when all view models are transformed into low-level models specified with a common language, it is possible to apply a homogeneous composition (e.g., composition of two Classes). Additionally, in order to compose two models it is necessary to identify what elements will be composed. Sometimes, it is enough to use naming conventions to identify corresponding elements, but when it is required more robustness, it is necessary to establish correspondence relationships between the elements to compose [2]. These relationships can be defined in a Correspondence Model (CM) that contains the links between elements to compose. However, when the different high-level models are transformed into a common low-level language it is necessary to derive the correspondence relationships between the generated low-level models. These correspondence relationships identify the elements that actually will be composed in the low-level models. This paper is an extended and revised version of [3]. In this paper we present an approach to avoid a heterogeneous composition of view-models. This approach uses Model Transformation Chains (MTCs) 1 to transform each view model into a common low-level language where it is possible to perform an homogeneous composition. Our approach offers an automatic mechanism to derive low-level correspondence relationships between the generated low-level models. These correspondences identify the elements to compose and guide the integration of the low-level models. The structure of the paper is as follows: the next section presents an example that is used to illustrate the proposed solution. Section 3 describes the problem that we tackle. In Section 4 an overview of our solution is presented. Section 5 presents a detailed explanation of how we derive a low-level CM and the elements involved in the derivation. Section 6 briefly presents how we perform the actual homogeneous composition. Finally, the related works are presented in Section 7, and Section 8 presents the conclusions of our work.

2

Illustrative Example

We use a simplification of an MDE implementation as case study, where web applications based on components and their security are modeled using two 1

A Model Transformation Chain (MTC) is a sequence of transformation steps that converts the high-level model, which is rooted in the problem domain, into a low-level model, which is rooted in the solution domain.

Deriving Correspondence Relationships

227

independent view models. These two high-level models are specified using two different DSML. The main objective of the first DSML is to specify the core functionality of the application using business concepts. The objective of the second DSML is to specify the authorization policies of the application. In this section both DSMLs are presented. 2.1

Business Modeling Language

As it was stated before, the first language is used to specify the main functionality of an application using concepts such as Entity, Attributes and Services. Figure 1(a) presents an extract of the metamodel of the Business modeling language. The main concept of this metamodel is Entity, which represents business entities of the application, such as "Project" or "Item". An Entity has Attributes, Relationships and Services. Figure 1(b) presents an extract of the business model2 . Business name target entities

0..1

Association name roleDestination roleSource

0..*

associations 0..*

Entity name

services 0..*

Service name

items: Association

rolSource

Project: Entity

rolDestination 0..1

attributes source

0..*

Attribute name

(a)

Item: Entity

attribute

attribute

attribute name: Attribute

name: Attribute

dueDate: Attribute

(b)

Fig. 1. Business Metamodel (M Mbus ) and Model (Mbus )

2.2

Security Modeling Language

We define a Security language using the SecureUML metamodel defined by Lodderstedt et al. in [4]. In the metamodel there is a Role that can perform a set of Actions on a Resource and it can be assigned to Users or Groups. The Actions are grouped as a Permission. Resource and Action are abstract concepts and it is necessary to extend them to include the resources and the actions to be protected. In our case study, we extend the concept Resource with EntityResource, AttributeResource and ServiceResource. Additionally, the concept Action is extended to define every action that can be protected in the extended resources. For instance, the security model (Msec ) has a Role "User" that has a permission with an Action "Read" on the EntityResource "Project". This means that a "User" can read the information about a "Project", but he cannot change it. 2

We use the UML Object diagram concrete syntax as a common representation for the presented models.

228

3

A. Yie et al.

Problem: Composing Multi-modeling Views

When a complex system is specified using several view models, it is necessary to compose them to obtain the required application. Nevertheless, before performing the composition it is necessary to identify the elements that will be composed. In order to identify those elements we use a CM. As defined in [2] a CM is a model that explicitly describes the relationships between elements of different models. Furthermore, the CM is the definition of what to compose, which elements, described in the models, will be composed. At the high-level of abstraction, it is possible to define the CM model using two strategies: intensional, extensional, or the combination of both. The first strategy is based on the intensional specification of the correspondence relationships. Using intensional formulas it is possible to infer which are the corresponding elements in both models. For instance, an intensional formula could state that if an element that conforms to the metaclass Entity and an element that conforms to the metaclass Resource have the same name, a correspondence relationship between them should be created. The second strategy is based on the extensional specification of the correspondence relationships. This means that every pair of corresponding elements is explicitly specified by the modeler. The extensional strategy tackles the problem of matching corresponding elements that requires human interaction to identify them. In our case study, we use an extensional strategy to define the CM because it is a more general case to test our approach. 3.1

High-Level Correspondence Model (CMHigh−Level )

We align the two high-level models using a CM which relates the elements to be composed. For example, in Figure 2 the business model (Mbus ) contains the Entity "Project" and the security model (Msec ) contains the Resource "Project" that needs to be protected. A correspondence relationship between the Entity and the Resource specifies that both elements are correspondent. The CM between both models CMhigh−level represented in the figure as black lines with circles in their ends. Additionally, the Attribute "dueDate" is related in the CM to the AttributeResource "date". The modeler creates these correspondence links because he knows the meaning of the relationships between elements. SECURITY MODEL (Msec)

BUSINESS MODEL (Mbus)

Read: Action action Project: Entity

equivalent

user: Role

Project: EntityResource ProjectUser: Permission

attribute dueDate: Attribute

permission

action

action

equivalent

date: AttributeResource

action

Read: Action

Fig. 2. High-level View Models

Deriving Correspondence Relationships

3.2

229

Heterogeneous Composition

A heterogeneous composition is the integration of two models expressed in two different languages. This means that is necessary to define the compositional semantic for every pair of concepts in both languages. For instance, if we have the concept Entity that belongs to a Business modeling language, and the concept Resource that belongs to a Security modeling language, it is necessary to define what is the meaning of composing them, e.g., if every Service and Attribute of the Entity will be protected too. Similarly, if a third language is added, it will be necessary to define a composition semantic for each pair of languages, increasing the complexity of implementing a multi-view solution. Our strategy is to avoid the heterogeneous composition transforming each view model into a low-level model defined using a common modeling language. After the composition we perform a composition between homogeneous concepts, for instance, to compose two Classes. Therefore, if the complete set of view-models is transformed into a common low-level language, a homogeneous composition can be applied. However, a new problem appears: how to identify the element to compose in the low-level models, in other words, how to derive the CM between the low-level models.

4

Approach Overview

The overall approach is to transform both high-level models into low-level models that conform to the same existing metamodel (e,g,. Java metamodel), or conform to an extension of it. We align both high-level models by using a CM, which needs to be propagated through the complete transformation chains. The main challenge is to define a mechanism to automatically derive the new correspondence relationships, having in mind that the MTC increments the complexity of the models by adding elements at each step. To derive a low-level CM, it is necessary to trace back the elements of the low-level models and to check if they come from pairs of related elements in the high-level. With a Trace Model (T M ) [5] we determine the elements in both lowlevel models that come from a couple of related elements in the high-level. For instance, an Attribute in the business view model is transformed in the low-level model into: an Attribute, a GetterMethod and a SetterMethod. In the security model a ResourceAttribute with a ReadPermission is transformed in the lowlevel security model into: a private Attribute and an annotated ReadMethod. Therefore, we have to trace back all these low-level elements and verify that the high-level source element (e.g., Attribute) from which they originate, is related with a correspondence relationship to the high-level concern-specific element (e.g., ResourceAttribute). Once, we establish which elements in the low-level models came from a pair of corresponding elements in the high-level models, we have to relate them by identifying the correct match for each one. For instance, a GetterMethod (in the low-level application model) can be related to a ReadMethod (in the low-level security model) but not to a WriteMethod. The modeler has to specify constraints,

230

A. Yie et al.

to avoid erroneous correspondences. A constraint is a relationship between two metaclasses that defines if the correspondence link between concepts that conform to them can be established or not. In our solution this set of constraints is specified in a Derivation Model (DM ). This approach is presented too in the context of transformation chain evolution [6]. Figure 3 presents the general schema of our approach. In the left, the business view model is transformed into a Java model (M Mbus , Mbus , M Mjava , Mjava , T1 )3 . In the right the security view model is transformed into a Java model too (M Msec , Msec , M Msec−java , Msec−java , T2 ). CMhigh−level is the high-level correspondence model that aligns the two high-level models. T MA and T MS are the trace models that relate the high-level models with the low-level models. The DM relates the low-level metamodels with constrains between their metaclasses. The DM is used to generate the transformation T3 , that uses the trace models and the CMhigh−level to generate the CMlow−level . MMbus

MMsec

CMhigh-level*

Mbus*

Msec* DM

T1

TMA

T2

Mjava

Msec-java

CMlow-level composition

(*) Manually defined by the application modelers

Metamodel

TMB

MMsec-java

MMjava

Model

T3

Mfull

G1

Application code

Fig. 3. General Schema

Finally, the low-level models are composed and transformed into code by a model-to-text transformation (G1 ).

5

Deriving Correspondence Relationships

Our approach proposes an automatic low-level correspondence relationship derivation mechanism. The goal of this mechanism is to automatically generate the transformation (T3 in fig. 3), that produces the low-level CM. 5.1

Derivation Process

Two elements a and b , from Mjava and Msec−java models respectively, will have a correspondence relationship if: 1) There is a CM relationship at the higher level between a and b, from Mbus and Msec models respectively, where a was produced from a by T1 , and b was produced from b by T2 . 2) The metaclasses ma and mb where a conforms to ma and b conforms to mb , allow for correspondence relationship between their instances. Intuitively, the first condition establishes 3

MM = Metamodel, M = Model, T = Transformation Chain.

Deriving Correspondence Relationships

231

that elements a and b trace back to a pair of elements that have a high-level correspondence relationship between them. The second condition means that the metaclasses ma and mb are the same metaclass or extensions of the same one. Therefore, it is permitted to define correspondence links between their instances and finally to compose them. If both conditions are satisfied for an element a and b , T3 will produce a correspondence link between a and b . In Figure 4, a correspondence link is created between the GetterMethod "getDueDate" in Mjava and the annotated ReadMethod "readDate" in Msec−java because they satisfy both conditions. First, "getDueDate" traces back to the Attribute "dueDate" in Mbus when T1 , transformed it and "readDate" trace back to the AttributeResource "date" in Msec when T2 transformed it. Additionally, the Attribute "dueDate" and the AttributeResource "date" were related by the high-level CM (CMhigh−level ). Second, the GetterMethod and ReadMethod metaclasses are allowed to be related by the DM. However, it is not possible to create a correspondence link between the SetterMethod "setDueDate" and the annotated ReadMethod "readDate" because there is not a constraint relating the metaclasses. Project: Entity

ProjectManager: Permission

user: Role

permission

attribute dueDate: Attribute

T1

equivalent

action

date: AttributeResource action

Project: Class

Read: Action T1 attribute method

T2

T2

T1 dueDate: Attribute

equivalent

method getDueDate: GetterMethod

equivalent

date: Attribute visibility = "private"

T2

readDate: ReadMethod T2 action

setDueDate: SetterMethod

T1 @RolesAllowed: RolesAllowedAnnotation value = "user"

Fig. 4. Detailed schema

5.2

Generating Tracing Information

When T1 is applied to the Attribute "dueDate", it is transformed into the Attribute "dueDate", the GetterMethod "getDueDate" and the SetterMethod "setDueDate". In order to make this information available to T3 , we generate trace links between output elements and input elements. The same happens in the T2 side, T3 needs to know if the ReadMethod traces back to a related AttributeResource. Once T1 and T2 are executed, two tracing models are generated (T MA and T MS ). With these two tracing links, T3 can find the elements in both lowerlevel models that trace back to the pair of related elements in both higher-level models. We generate a trace model when each transformation (i.e., T1 and T2 )

232

A. Yie et al.

is executed. This model conforms to a Traceability Metamodel and it has links between every source element and its target elements. In our implementation we extend the ATL virtual machine [7] implementation to automatically generate trace models every time that an ATL transformation is executed. This extension is presented in [8]. 5.3

Derivation Model

The Derivation Model is a key element in the generation of the low-level correspondence model. Using this model, we define relationships that intentionally define how the correspondence relationship should be propagated through the whole MTC. The Derivation Model explicitly defines if two metaclasses, in two different metamodels, are compatible. Compatibility here means that the two metaclasses are abstractions of the same concept in two different models. The modeler of the domains has to decide if two metaclasses are compatible or not. In the same way, the modeler has to decide about the propagation of the compatibility relationships. If two metaclasses are compatible, are their submetaclasses compatible too? Are the composites compatibles too? Whether or not correspondence links are allowed between certain model elements is defined using compatibility relationships. Developers have to define a Derivation Model (DM ) to make explicit if instances of two metaclasses are allowed or not to be related by a correspondence relationship. Figure 5 shows a sample of the Derivation Model specified between the Java Model (Mjava ) and the Java Security Model (Msec−java ). For instance, in the figure a CompatibleConstraint is defined between the metaclass GetterMethod and the metaclass ReadMethod, this means that it is possible to generate a correspondence relationship between the classes conform to them. Method

MMjava

Method

DM Getter

compatible

ReadMethod

Setter

compatible

WriteMethod

EJBMethod

UpdateMethod

MMsec-java

compatible

Fig. 5. Mjava - Msec−java Derivation Model

Furthermore, the developer has to decide about the propagation of the compatibility relationships. It is possible to say that in the Derivation Model the developer specifies intensional formulas to derive the low-level correspondence model. How a correspondence relationship is propagated is specified by different types of constraints, that are defined in the Derivation Metamodel.

Deriving Correspondence Relationships

5.4

233

Derivation Metamodel

Compatibility relationships represent constraints that allow or deny the creation of a correspondence relationship between target models. We have defined different types of compatibility relationships in the Derivation Metamodel, to offer to the developer the possibility of specifying how a low-level correspondence relationship between two elements in the target models are propagated, if they come from two elements related by a high-level correspondence relationship. Figure 6 presents the Derivation Metamodel. The base concept of the metamodel is the DerivationConstraint that relates two Metaclasses. The DerivationConstraint has several specializations that represent the types of constraints: Compatible Constraint, Final Constraint, Incompatible Constraint, and Composition Constraint. These constraints are illustrated in the Figure 7. DerivationModel leftMetaclass

links DerivationConstraint

Metaclass

ref

EObject

rightMetaclass

CompatibleConstraint

IncompatibleConstraint

FinalConstraint

CompositionConstraint

Fig. 6. Derivation Metamodel

Fig. 7. Derivation Model Constraint

Compatible Constraint: The Compatible Constraint (Figure 7(a)) relates two metaclasses ma and ms , each one in a different metamodel. If T3 finds an element a that conforms to ma or to its subclasses, and an element s that conforms to ms or to its subclasses. And their sources a and s in the higherlevel models were connected by the CM, then the T3 creates a new link between a and s in the new CM. For instance, the metaclass Attribute in M MA and the metaclass Attribute in M MS will be related with an Compatible Constraint, because we want to protect every attribute in the application. Therefore, an instance of Attribute or and instance of one of its submetaclasses will be private.

234

A. Yie et al.

Final Constraint: The Final Constraint (Figure 7(b)) relates two metaclasses ma and ms , each one in a different metamodel. If T3 finds an element a that conforms only to ma , but not to its subclasses, and an element s that conforms only to ms , but not to its subclasses. And their sources a and s in the higherlevel models were connected by the CM, then the T3 creates a new link between a and s in the new CM. For instance, the metaclass Method in M MA and the metaclass Method in M MS will be related with a Final Constraint, because we want to protect only the method types. If we use an Compatible Constraint for these metaclasses every couple of methods will be connected, i.e., SetterMethod and WriteMethod. Incompatible Constraint: The Incompatible Constraint (Figure 7(c)) relates two metaclasses ma’ and ms’, each one in a different metamodel. If T3 finds an element a’ that conforms to ma’, and an element s’ that conforms to ms’. And their sources a and s in the higher-level models were connected by the CM, then the T3 will not create a new link between a’ and s’ in the new CM, neither if the elements supermetaclasses are related with a Compatible Constraint nor a Composite Constraint. For instance, it is possible to explicitly express with an Incompatible Constraint that a GetterMethod and WriteMethod are incompatible concepts. Composition Constraint: The Composition Constraint (Figure 7(d)) relates two composition associations ra and rs , each one in a different metamodel and relating two different metaclasses in each metamodel. If T3 finds a element a2 that conforms to ma2 and contained by an element a1 that conforms to ma1 , and T3 finds an element s2 conforms to ms2 and contained by an element s1 that conforms to ms1 , and the sources of a1 and s1 are a and s, and they are related in the higher-level CM, then the T3 will create a new link between a2 and s2 in the new CM. For instance, with a Composition Constraint between the containment Class/Attribute relationships is possible to explicitly express if a Class is protected, every contained Attribute is protected too. 5.5

Generating the CM Transformation

Once the Derivation Model is defined by the developer, it needs to be processed to be used by T3 . The DM is defined at metamodel level and T3 needs information at model level. Therefore, it is necessary to express the constraints as part of the transformation rules. For this reason, we use a High-Order Transformation (HOT) that receives the DM as input and produces T3 . A HOT is a transformation rule that produces another transformation rule as output. The HOT that we implemented uses the DM as input and adds a new rule to T3 for each constraint in the DM. The added rules are in charge of selecting and connecting the elements depending on the constraint in the DM. For instance, a Compatible constraint is defined between the metaclass GetterMethod in M Mjava and the metaclass ReadMethod in the M Msec−java . The semantic of this constraint allows relating elements conform to the related metaclasses or their submetaclasses. Listing 1 presents part of the High Order Transformation rule.

Deriving Correspondence Relationships

235

1 rule C o m p a t i b l e L i n k 2 R u l e { 2 from 3 inlink : DerivationMM ! Comp atibl eCons traint 4 to 5 outrule : ATL ! MatchedRule ( 6 name <- ’ CompatibleConstraint ’ + inlink . left . name + inlink . right . name , 7 inPattern <- inPattern , 8 outPattern <- outPattern 9 ), 10 inPattern : ATL ! InPattern ( 11 elements <- Sequence { leftInElement , rightInElement , link } , 12 filter <- d e r i v a t i o n C o n s t r a i n t 13 ), 14 d e r i v a t i o n C o n s t r a i n t : ATL ! O p e r a t i o n C a l l E x p ( ... ) , 15 ... 16 outPattern : ATL ! OutPattern ( 17 elements <- Sequence { outLink } 18 ... 19 ), 20 outLink : ATL ! S i m p l e O u t P a t t e r n E l e m e n t ( 21 varName <- ’ outlink ’ , 22 bindings <- Sequence { linkName , linkModel , leftElement , righElement } 23 ... 24 ), 25 ... 26 }

Listing 1. High Order Transformation

The main goal of the presented HOT is to produce an ATL MatchedRule for each Derivation Constraint specified in the DM. For instance, the rule takes the CompatibleConstraint as input (line 3) and produces a new MatchedRule (line 5-9). An inPattern and an outPattern are defined for the new MatchedRule. The inPattern (lines 10-13) specifies the type of the elements that are going to be matched by the rule, such as GetterMethod and ReadMethod. Additionally, the inPattern has a filter where the derivation constraint is defined. In the derivationConstraint (line 14) an intensional formula is specified based on the type of constraint. These formulas are expressed as OCL constraints that are applied as a filter to the matched elements. The outPattern (lines 16-19) specifies the output elements that will be generated. In this case a new correspondence link between the matched elements. 5.6

The Correspondence Model Transformation T3

When HOT transformation processes the DM a transformation rule is generated. This transformation rule T3 will be responsible of generating the low-level correspondence model. For instance, one of the rules generated from the DM presented in Figure 5 is presented in Listing 2. This transformation rule takes three elements as input: 1) an element of type GetterMethod (line 3), 2) an element of type ReadMethod (line 4), and 3) a correspondence link which related elements are the sources for (1) and (2) (lines 5-10). This rule has three outputs: 4) a correspondence link (lines 12-16), 5) a reference to the left element that is the left input element (1) (line 17) and 6) a reference to the right element that is the right input element (2) (line 18).

236

A. Yie et al.

1 rule C o m p a t i b l e C o n s t r a i n t _ G e t t e r _ R e a d M e t h o d { 2 from 3 leftElement : LEFTOUT ! GetterMethod , 4 rightElement : RIGHTOUT ! ReadMethod , 5 inlink : CORRESPONDENCE ! EquivalentLink ( 6 ( inlink . left . getTargets ( ’ leftTrace ’) - > flatten () - > select ( e | 7 e = leftElement ) - > notEmpty ()) and 8 ( inlink . right . getTargets ( ’ rightTrace ’) - > flatten () - > select ( e | 9 e = rightElement ) - > notEmpty ()) 10 ) 11 to 12 outlink : CORRESPONDENCE ! EquivalentLink ( 13 model <- thisModule . matchModel , 14 left <- leftEnd , 15 right <- rightEnd 16 ), 17 leftEnd : MATCH ! LeftElemen t ( ref <- leftElement ) , 18 rightEnd : MATCH ! RightElement ( ref <- rightElement ) 19 } 20 }

Listing 2. Transformation Rule (T3 )

From Listing 2, T3 is specified for both low-level metamodels (lines 3-4), and the types of the metaclasses are hard-coded in the inputs of the rule; it comes from the constraints because we automatically generate T3 using the presented HOT. In our case study, the GetterMethod "getDueDate" in the application side can be connected to the ReadMethod "readDueDate", because the metaclasses GetterMethod and ReadMethod are compatible. As it was presented before, it exists a constraint that allows these two elements to be connected. The case of GetterMethod and WriteMethod is clear that they are incompatible metaclasses and a correspondence link can not be defined between their instances. In this way it is possible to relate only the compatible pairs of elements and not every generated element in each side.

6

Composition

The final step is to compose both low-level models to obtain a complete low-level model of the application. In this composition, the generated CM (CMlow−level ) is an essential input. This model has the information of what will be composed. In our example, the Classes in the application low-level model (Mjava ) will be composed with the annotated Classes in the security low-level model (Msec−java ), the Attributes in (Mjava ) with the private Attributes in (Msec−java ), and the Methods in (Mjava ) with the annotated Methods in (Msec−java ). By using the correspondence links it is possible to identify every pair of elements to be composed. To do the actual composition we use a mechanism based on the UML Package Merge [9]. After the composition a single model is obtained. This model has the elements of Mjava enhanced with the elements of the Msec−java . For instance, the final Method getDueDate is annotated with @RolesAllowed that comes from the Msec−java annotated Method.

Deriving Correspondence Relationships

7

237

Related Work

In our approach we integrate several of the ideas of other works; these ideas helped us to model the application and its concerns in independent models and to delay the composition to the lower-level of abstraction where a homogeneous composition is performed. In [1], Vangheluwe presents a Formalism Transformation Graph (FTG). In the FTG diverse formalisms are mapped using transformations that allow to transform a model expressed in one formalism into other formalism. The traversal of this graph allows to represent how coupled models specified using different formalisms can be transformed into a common formalism. Once the models are mapped into a common formalism, closure under coupling of that formalism makes the meaning of the coupled model explicit. The coupling can be analyzed or composed into an atomic model. Additionally, in this research DEVS is presented as common denominator for the representation of discrete events models. In our work we use a GPL based language as common denominator to compose diverse models expressed using different DSML. We make explicit the coupling of the different models by using correspondence relationships between them. Moreover the coupling is propagated through the MTCs and used to derive correspondences between the models expressed in the common language. Bezivin et al. presents in their paper [2] a canonical scheme for model composition. This canonical scheme is extracted of analyzing several composition frameworks. From the analysis results they derive a core set of common definitions that are used to define key requirement for model composition tools. We use from this paper the notion of correspondence model and we propagate it through the MTCs. Following the multi-modeling principle, Cicchetti and Di Ruscio present in [10] a proposal for modeling a web application using three independent models: a data model, a composition model, and a navigation model. A correspondence model is defined between each pair of models. These three models are composed using the CMs into a high-level model. This high-level model conforms to a platform independent web metamodel, such as WebML or Webile. These web modeling languages try to integrate all the required concepts for web application modeling in a common metamodel. This approach requires to transform and to compose the heterogeneous source models in the same transformation, increasing the complexity and reducing the scalability to add new view models. In [11], Cibran et al. present an approach to define for an application business rules as aspects. The business rules are modeled using a DSML and the relationships between the business rules and the application are defined using a connection DSML. This DSML abstracts patterns of how the business rules are connected with the application code. This connection language can be seen as a CM that relates two different models of the application. Both models are transformed into low-level models and the connections are also transformed and aspect code is generated from them. In our approach, using the DM and the HOT we automate the generation of the transformation that creates the relationships between the low-level models.

238

A. Yie et al.

In [12], Ruiz-Gonzalez et al. present a mechanism to synchronize viewpoint models in a model driven web specification. This mechanism is based on the use of correspondence relationships to specify synchronization correspondences between the models. This means that if one of the viewpoint models is modified, their proposed mechanism will suggest a solution for synchronize the corresponding elements in the related viewpoint models. In our research the correspondences are managed and maintained through the complete MTCs. This allow us to use them to perform an homogeneous composition. The work by Vanhooff et al. in [13] present a Global Traceability Graph (GTG) which is used as mechanism to navigate several models involved in a transformation chain. These models represent different aspects of a system. The GTG is automatically generated by the transformation chain and it can be used as input of a transformation step. For instance, to know the name of a Table in a generated relational model, and use this name to generate the code that access the Table. With the GTC is possible to navigate every single model produced by the transformation chain. In our approach we use traceability links and Correspondence Models as mechanisms to relate a pair of MTC.

8

Conclusions

Our approach facilitates the modeling of different concerns using separated view models each one close to the problem domain. The view models are aligned using correspondence relationships between their elements. These correspondence relationships explicitly capture overlapping and dependencies among their elements. Additionally, our approach offers an automatic derivation mechanism to identify the elements to compose in the low-level models based on the correspondence relationships defined between the high-level models. With this mechanism, it is possible to maintain both models aligned from the high-level until the lowestlevel through the transformation chain. This is the main difference of our work with other approaches where these relationships are only defined as an input, but not maintained during the transformation chain. As a result of delaying the actual composition to the lowest-level where all the models conform to the same metamodel or to an extension of it, it is possible to perform a homogeneous composition using a single composition mechanism. Our approach helps to separate the model transformation from the model composition. Using our approach it is possible to express diverse view models using different DSLS and to transform independently each one into a common language. Then, a homogeneous composition step can be applied. This improves the maintainability of the MDE implementation by decoupling the composition from the translation into a different metamodel. The strategy of transforming diverse models to a common language or formalism was used by [1]. He obtained sound results using this strategy with behavioral models specified in non-UML based modeling languages. In our work we focus in to propose a mechanism to propagate correspondence relationships through a transformation chain. However, we only tested our approach in structural models.

Deriving Correspondence Relationships

239

We implemented the derivation mechanism and the composition mechanism using the Atlas Modeling Language (ATL) and in our current work we are exploring the modeling of an application in three or more models and bringing these models to the lower level, where they will be composed. This is a complex problem, because of the interactions among the different modeled concerns can generate several inconsistencies.

References 1. Vangheluwe, H.: DEVS as a common denominator for multi-formalism hybrid systems modelling. In: CACSD 2000: IEEE International Symposium on ComputerAided Control System Design, pp. 129--134 (2000) 2. Bézivin, J., Bouzitouna, S., Del Fabro, M., Gervais, M.P., Jouault, F., Kolovos, D., Kurtev, I., Paige, R.F.: A canonical scheme for model composition. In: Rensink, A., Warmer, J. (eds.) ECMDA-FA 2006. LNCS, vol. 4066, pp. 346--360. Springer, Heidelberg (2006) 3. Yie, A., Casallas, R., Deridder, D., Wagelaar, D.: A practical approach to multimodeling views composition. Electronic Communications of the EASST 21 (2009) 4. Lodderstedt, T., Basin, D., Doser, J.: SecureUML: A UML-based modeling language for model-driven security. In: Jézéquel, J.-M., Hussmann, H., Cook, S. (eds.) UML 2002. LNCS, vol. 2460, pp. 426--441. Springer, Heidelberg (2002) 5. Aizenbud-Reshef, N., Nolan, B.T., Rubin, J., Shaham-Gafni, Y.: Model traceability. IBM Systems Journal 45(3), 515--526 (2006) 6. Yie, A., Casallas, R., Wagelaar, D., Deridder, D.: An approach for evolving transformation chains. In: Schürr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 551--555. Springer, Heidelberg (2009) 7. Jouault, F., Kurtev, I.: On the architectural alignment of atl and qvt. In: SAC 2006: Proceedings of the, ACM symposium on Applied computing, pp. 1188--1195 (2006) 8. Yie, A., Wagelaar, D.: Advanced traceability for ATL. In: 1st International Workshop on Model Transformation with ATL, pp. 78--87 (2009) 9. Dingel, J., Diskin, Z., Zito, A.: Understanding and improving UML package merge. Software and Systems Modeling 7(4), 443--467 (2008) 10. Cicchetti, A., Di Ruscio, D.: Decoupling web application concerns through weaving operations. Science of Computer Programming 70(1), 62--86 (2008) 11. Cibran, M., D’Hondt, M.: A slice of MDE with AOP: transforming high-level business rules to aspects. In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 170--184. Springer, Heidelberg (2006) 12. Ruiz-Gonzalez, D., Koch, N., Kroiss, C., Romero, J., Vallecillo, A.: Viewpoint synchronization of uwe models. In: MDWE 2009: Proceedings of the 5th International Workshop on Model-Driven Web Engineering, pp. 46--60 (2009) 13. Vanhooff, B., Baelen, S.V., Joosen, W., Berbers, Y.: Traceability as input for model transformations. In: Third ECMDA traceability workshop (2007)

Explicit Transformation Modeling Thomas K¨ uhne1 , Gergely Mezei2 , Eugene Syriani3 , Hans Vangheluwe3,4 , and Manuel Wimmer5 1

2

Victoria University of Wellington [email protected] Budapest University of Technology and Economics [email protected] 3 McGill University {esyria,hv}@cs.mcgill.ca 4 University of Antwerp [email protected] 5 Vienna University of Technology [email protected]

Abstract. Despite the pivotal signiﬁcance of transformations for modeldriven approaches, there have not been any attempts to explicitly model transformation languages yet. This paper presents a novel approach for the speciﬁcation of transformations by modeling model transformation languages as domain-speciﬁc languages. For each pair of domain, the metamodel of the rules are (quasi-)automatically generated to create a language tailored to the transformation. Moreover, this method is very eﬃcient when the transformation domains are the transformation rules themselves, which facilitates the design of higher-order transformations.

1

Introduction

Model-driven approaches are gaining popularity both in the form of being based on standard modeling languages, such as the UML, as well as domain-speciﬁc modeling languages. In both instances, the aim is to increase developer productivity, in the case of the former by raising the level of abstraction at which systems can be speciﬁed and in the case of the latter by lowering the impedance mismatch between a modeling language and its application domain [1]. There are still many open problems with respect to the economic development of domain-speciﬁc modeling languages, but their deﬁnition is well understood. This shifts the focus on transformations which have a number of applications among which are: (1) establishing transformation chains from high-level to lowlevel speciﬁcations, (2) providing semantics for a source language by mapping it to a target language, and (3) creating a consistent mapping between two or more models. A number of transformation paradigms exists, e.g., template-based, rulebased, triple graph grammars, with or without explicit control ﬂow [2]. They are supported by various implementations such as Atl [3], AToM3 [4], GReAT [5], Moflon [6], Qvt [7], Vmts [8]. They provide tremendous value for developers, but in each implementation the transformation paradigm is hard-coded to be S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 240–255, 2010. c Springer-Verlag Berlin Heidelberg 2010

Explicit Transformation Modeling

241

used as is. The implementations do not provide a way to interrogate or modify transformation deﬁnitions as ﬁrst-class transformation models [9]. This is surprising as there are a number of beneﬁts to be gained when treating transformations as ﬁrst-class citizens [10,11] which are explicitly modeled and amenable to introspection and modiﬁcation. In the following, we ﬁrst introduce our running example which we use as the basis of our subsequent discussions. In Sect. 3, we investigate the automated construction of customized pattern speciﬁcation languages, using the components relaxation, augmentation, and modiﬁcation, exploring and discussing alternative solutions. This provides a systematic procedure for explicitly modeling transformation languages. As a consequence, this enables to “cleanly” design higherorder transformations. In Sect. 4, we present two higher-order transformations – for automatically enhancing transformations with correspondence links and adding source-level animation for simulations respectively – which exhibit two diﬀerent forms of separation of transformation concerns. Before we conclude, we compare our transformation deﬁnitions with those required in an Atl conFig. 1. (a) FSA & (b) Petri Net Metamodels text and discuss further related work in Sect. 5.

2

Running Example

The example that we will use in the remainder of the paper to illustrate our arguments is a typical case of a domain-speciﬁc language being assigned a semantics by translating it into a target formalism with known semantics. In order to deﬁne the semantics of statecharts and/or perform reachability analyses on them, one can translate them to Petri nets [4]. Another reason for considering this particular translation is that one can use Petri nets as a common semantic

Fig. 2. (a) FSA to (a) Petri Net Mapping

242

T. K¨ uhne et al.

domain for statecharts, sequence diagrams, and activity diagrams. For the purposes of this paper, however, we restrict ourselves to translating ﬁnite state automata, rather than statecharts, into Petri nets. The resulting transformation deﬁnitions of this translation are much simpler but still rich enough to illustrate our arguments. Figure 1 shows both metamodels. 2.1

Finite State Automata as Language Recognizers

More speciﬁcally, we interpret our state automata to be language recognizers, i.e., they either accept input sequences as belonging to respective regular languages or not. The top part of Fig. 2 shows a sample input sequence (“yees”) and a ﬁnite state automaton accepting the language y(e)∗ s. In our example, we want to simulate the execution of the ﬁnite state automaton in the context of receiving the events from the input sequence in order to ascertain whether the input sequence is a sentence of the language. To this end, we translate such scenarios into corresponding Petri nets (see bottom part of Fig. 2). 2.2

Translating Finite State Automata to Petri Nets

Figure 3 shows an excerpt of the transformation rules that are required to translate a ﬁnite state automaton plus an input sequence into a Petri net that can be used to simulate the automaton execution. In particular, Figure 3 shows a subset of the rules that translate ﬁnite automaton states into Petri net places. The rest of the rules dealing with the translation are similar to those shown and are not of further signiﬁcance for the purposes of this paper. Note that we are using AToM3 [4] and MoTif [12] and thus use concrete syntax for describing single push-out graph transformation rules, employing numerical labels to indicate identity of elements. We are well aware of the tension between the “must transition” and “may ﬁre” semantics of ﬁnite state automata and Petri nets, reFig. 3. Translating States to Places spectively. In timed Petri nets, this diﬀerence may lead to a situation where a ﬁnite state automaton does not change states anymore even though it should, just because the Petri net used for simulating it does not ﬁre transitions anymore, even though it could. However, the

Explicit Transformation Modeling

243

place/transition nets we assume do not create this mismatch and a simulator for them will ﬁre enabled transitions. 2.3

Petri Net Semantics

We simulate Petri net execution by using a small set of transformation rules, from Petri nets to Petri nets, which realize an operational semantics of Petri nets (see Fig. 4). We are able to express the operational semantics in just four simple rules because we use MoTif (Modular Timed graph transformation language) control structures, which are based on discrete event-based control structures [12]. The respective control structure is shown in Fig. 5. The control structure shown in Fig. 5 makes it particularly easy to ﬁnd an enabled Petri net transition, i.e., one which can ﬁre. Such a transition needs sufﬁciently many tokens Fig. 4. Operational Semantics for Petri Nets at each of its incoming transitions. One naive solution for ﬁnding enabled transitions is to just specify all possible patterns to be found as subgraph isomorphisms. Alternatively, this can be solved provided that the pattern speciﬁcation language uses intentional speciﬁcations to allow referring to subgraphs of arbitrary size. However, the most elegant solution is to iterate through all transitions until one has been found that does not satisfy the pattern of a non-ﬁring transition. The backward channel in Fig. 5 from the success port (depicted by a check mark) of NonFiringTransition to the next port (depicted by two ﬁlled triangles) of FindTransition ensures the iteration through all transitions, skipping those which cannot ﬁre. Hence the forward channel from the fail port (depicted by a cross) of NonFiringTransition to the graph port (depicted by a triangle) of the FireTransition block. The latter’s content are the two rightmost rules of Fig. 4. They are applied to all matching patterns within the subgraph that has been passed to FireTransition. Circles around output ports indicate that a pivot model (matched model element) is passed to the next port (i.e., next and fail ports). Therefore, FireTransition will ﬁre exactly the transition which has been ﬁrst found by FindTransition and subsequently has not been rejected by NonFiringTransition. In Sect. 4, we will use a higher-order transformation to extend the control structure shown in Fig. 5 to include an animation component. First, however, we will describe and discuss the explicit modeling of transformation deﬁnitions Semantics as an enabler of customized transformation development Fig. 5. Control Structure environments and higher-order transformations.

244

3

T. K¨ uhne et al.

Explicit Transformation Modeling

Metamodeling1 , i.e., the explicit speciﬁcation of a language’s well-formedness constraints, has become popular because of a number of associated advantages: (1) the speciﬁcation is not hidden in the code of a tool, making it easier to understand and correct, (2) the speciﬁcation can be altered by users of the tool instead of requiring a new tool release, and (3) one can reason about the speciﬁcation and the models it describes. The same advantages apply if metamodeling is not only applied to modeling language deﬁnitions, but also to transformation deﬁnitions. While there is a considerable initial investment to be made in explicitly modeling a transformation language including its semantics, the prospect to more easily experiment with language features, customize them for certain purposes, and allow transformations to be reasoned about and/or modiﬁed makes that investment worthwhile. Clearly, in order to enable the last aspect mentioned above, the transformation language’s mapping approach, e.g., rule-based graph transformation, needs to be explicitly modeled. Section 4 elaborates on this and additionally motivates why a transformation language’s control part should also be explicitly modeled. Unlike the mapping and control aspects of a transformation language, its pattern speciﬁcation sublanguage depends on other languages. The input and output languages of a transformation determine which pattern speciﬁcations for left-hand side (LHS) and right-hand side (RHS) can be considered well-formed. The underlying assumption here is that the pattern speciﬁcation language should not be generic to ﬁt all possible input and output languages, but speciﬁcally tailored to the input and output languages involved. 3.1

Generic versus Customized Pattern Specification Languages

The most economic approach to providing a pattern speciﬁcation language is to oﬀer a generic one. Most tools do not use concrete syntax for specifying transformation patterns and thus are able to use the same generic (often UML objectdiagram-inspired) pattern speciﬁcation syntax for all possible input/output languages. They often also have an underlying generic (often MOF-like) representation format which can be used to represent elements from any input/output language. There are good reasons, however, to consider using a pattern speciﬁcation language which is customized to the input/output languages involved: – One may use pattern speciﬁcation visualizations which are adapted to the languages involved. Even if no concrete syntax is used, one may still want to customize the syntax, e.g., to adequately visualize connector elements. – A customized syntax allows excluding patterns from being speciﬁed that do not have a chance of matching subgraphs in the host graphs. For instance, in the context of Petri nets, a pattern consisting of an arc linking two places will never be matched on any valid Petri net instance (i.e., conforming to the meta-model in Figure 1). 1

Linguistic metamodeling [1], to be precise.

Explicit Transformation Modeling

245

A generic pattern speciﬁcation language will allow any pattern to be expressed whether or not it will be able to match subgraphs from the input language(s) or generate subgraphs conforming to the metamodel(s) of the output language(s). Just as a plain domain-speciﬁc modeling tool has advantages for its users, guiding them to produce meaningful models, a customized transformation pattern speciﬁcation tool also aids in avoiding meaningless pattern speciﬁcations. Whether this customization is achieved by changing the representation format for each generated transformation deﬁnition environment or by just exchanging a language deﬁnition against which generic pattern speciﬁcations are checked is immaterial to the user, but a tool builder decision. In the following, we assume that, in one way or another, pattern speciﬁcations can be checked for conformance to a pattern speciﬁcation language deﬁnition. As a result, a method needs to be identiﬁed that enables these conformance checks in an economic manner, while oﬀering the transformation language user maximum beneﬁts. 3.2

Metamodels versus Conformance Checks

Unfortunately, providing a customized pattern speciﬁcation language is not as easy as simply reusing the corresponding input/output metamodels. First, demanding a full adherence of pattern speciﬁcations to original language deﬁnitions is not practical. If all minimal multiplicity requirements of language deﬁnitions were enforced, one could not specify useful patterns such as findTransition of Fig. 4, which refer to model fragments, ignoring minimal multiplicity requirements. Second, one may want to provide several levels of rigor with respect to checking the well-formedness of pattern speciﬁcations. While the transformation designer edits a pattern speciﬁcation, one most certainly does not want to enforce all well-formedness constraints. It also should be possible to save ill-formed sketches to be worked on later. This does not mean, however, that the complete absence of all potential well-formedness checks is always the best choice in such cases. Table 1 lists potentially useful levels of conformance checking rigorousness. There are two ways to enable the use of such levels of conformance: 1. either one creates modiﬁed language deﬁnitions and performs a normal conformance check against them, or 2. one uses original language deﬁnitions, but accordingly modiﬁed conformance checks. Table 1. Levels of Conformance Level of rigor Free form Valid elements Valid multiplicities Valid constraints

Description no constraints at all elements are typed by the metamodel (relaxed) multiplicity constraints are enforced (a subset of) metamodel constraints are enforced

246

T. K¨ uhne et al.

The second option has a number of advantages: – one can simply use the original language deﬁnitions; there is no need to create multiple variants of them. – switching between conformance levels does not require the switch of a metamodel; the latter is quite feasible though with an appropriate architecture. – the alternative (1. above) cannot use a standard conformance check anyhow (see Sect. 3.3 and Sect. 5). However, there are also a number of disadvantages: – some generic way to extend languages deﬁned by metamodels is required; pattern speciﬁcation languages require additional features beyond the original input/output languages (see Sect. 3.3). Customized metamodels can easily incorporate these. – custom conformance checks are harder to reason about than custom metamodels; in the absence of a fully modeled action language, conformance checks will be implemented in some programming language making it harder to see and analyze what relation they actually implement. – conformance checks are harder to customize by users; transformation designers can be expected to alter the transformations that yield tailored metamodels but may not be able to re-program conformance checks. – swapping conformance checks means that the transformation development will remain the same; swapping metamodels opens up the possibility to use them for the automated generation of dedicated development environments with diﬀering sets of control elements. Finally, there is another motivation for supporting more than one mode of wellformedness checking which can only be enabled by using multiple metamodel versions: Typically, transformation deﬁnitions comprise layers of rules in the sense that one will expect all rules from one layer to have matched, and then match no more, before the next layer of rules will be used. This layering often exists independently of whether or not it is dealt with explicitly. In particular with in-place transformations, the input and output languages change from layer to layer. The ﬁrst layer’s input language is the source language while its output, the input to the next layer, will typically contain generic links which are not part of the source language (see Sect. 3.3). The last layer’s output language is the target language, whereas all preceding layers will produce either augmented versions of it or mixtures between the source and target languages. The availability of a series of adapted metamodels may aid the transformation developer to understand what the layers involved are and assign rules to them accordingly. We have not yet pursued the idea of using a series of transformation layer interface language deﬁnitions and it would be challenging to automate the generation of these intermediate language deﬁnitions. Luckily, however, automating the creation of customized pattern speciﬁcation languages from original input/output language deﬁnitions can be automated very well.

Explicit Transformation Modeling

3.3

247

Semi-automated Metamodeling

The previous section motivated the use of variants of original metamodels for deﬁning the well-formedness of pattern speciﬁcations. In this section, we discuss how one can create such variants systematically and thus automate the process. Figure 6 depicts how rules refer to precondition and postcondition patterns and the pattern element they Fig. 6. Rule Metamodel contain. When adapting transformation languages to speciﬁc input and output languages, one needs to tailor these precondition and postcondition patterns so that they are ﬁt to be used for the respective input and output languages. We obtain the required tailored pattern speciﬁcation metamodels by starting with the original language metamodels and then subjecting them to a number of changes. The required metamodel metamorphosis has three distinct components: relaxation, augmentation, and modiﬁcation. Figure 7 shows an excerpt of the result of applying these steps to the ﬁnite state machine metamodel of Fig. 1. Relaxation Original language deﬁnitions cannot be used as is for deﬁning the well-formedness of pattern speciﬁcations. First, often transformation designers aim to match for any one-of-many element types, e.g. one-of-many “connection” kinds. Such generalizations are typically present in original language deﬁnitions but as abstract concepts which cannot be instantiated. One relaxation step therefore is to turn such abstract concepts into concrete ones.

Fig. 7. Generated Pattern Speciﬁcation Metamodel

248

T. K¨ uhne et al.

Second, as mentioned before, enforcing minimal multiplicity constraints would be completely impractical. A further relaxation step is, therefore, to reduce all minimal multiplicities to zero (see Fig. 7 for the relaxation of State multiplicities and Sect. 5 for a more elaborate discussion). Third, only a subset of explicitly formulated original constraints (e.g., using Ocl) can be active for the purpose of checking pattern speciﬁcation well-formedness. All constraints concerned with ensuring completeness of models are potentially unsuitable for the inherent fragment-like nature of speciﬁcation patterns. The relaxation process could automatically ﬁlter out constraints with the help of a corresponding naming scheme for constraints or manually provided augmentations, but we currently believe any further automation will be diﬃcult to achieve. This is why we refer to the metamodel generation as semi-automated. A potential further relaxation is to raise all maximum multiplicities to “unbounded” in order to allow intermediate results that can be helpful to drive the transformation process, despite the fact that they would be ill-formed as end results. However, we argue that purposefully violating well-formedness requirements in this way amounts to “hacking” and should be avoided. We recommend using so-called generic links for these purposes instead. Augmentation To be ﬁt as pattern speciﬁcation metamodels, input/output metamodels also need to be augmented with features required for transformation purposes. In Fig. 7, all types are made descendants of MT Element so that they inherit features that all elements that may appear in a pattern speciﬁcation must have, e.g., a way to label them for identity matching. The generated metamodels also feature additional generic nodes and links which are often necessary to drive the transformation (e.g., see the generic connectors between states and places in Fig. 3). Elements which are used in negative application conditions (NACs) or the LHS of rules (subtypes of MTpre element ) also need a ﬂag feature that tells the pattern matcher whether to look for exact types or allow subtype matching as well. The remaining diﬀerences between the original and generated metamodel elements are all modiﬁcations of existing features. Modification The modiﬁcations that need to be applied to original metamodel elements depend on whether we want to obtain precondition (i.e., NAC and LHS) or postcondition (i.e., RHS) pattern speciﬁcations. For precondition pattern speciﬁcations we need to replace the respective types of attributes to the type “constraint”. This allows the transformation designer to specify constraints for element features, such as MTpre name=”NEXT” (see Fig. 3). For postcondition pattern speciﬁcation we need to allow actions rather than constraints, so that the transformation designer can set values of attributes, among other potential actions. In rule NextPlace of Fig. 3, the “=” in the RHS part of the rule is an assignment action rather than an equality check. Note that the same naming and modiﬁcation scheme is applied to classes, associations, and role names.

Explicit Transformation Modeling

249

Finally, we sometimes need to modify the concrete syntax of language elements whose size or natural layout is not conducive for specifying patterns. Also, elements which are normally not rendered at all, such as instances of formerly abstract classes or association ends, need to be assigned some concrete syntax so that they may be referred to in a visual manner. We have implemented a prototype of this procedure. A new metamodel is created as partly shown in Figure 7. In the relaxation step, we did not consider the (OCL) constraints of the respective metamodels yet and they thus have been maintained. In the augmentation step, the ﬁrst two levels of the inheritance hierarchy of Figure 7 correspond to concepts from the meta-metamodel of AToM3 /MoTif. Finally in the modiﬁcation step, our prototype did not take into account issues related to layout in the concrete syntax of the pattern elements. Summarizing, this section has discussed various alternatives for enabling transformation designers to make use of customized pattern speciﬁcation languages and environments. We proposed the semi-automated generation of customized metamodels based on the components of relaxation, augmentation, and modiﬁcation. Figure 8 depicts how a transformation from model M 1 to model M 2 is deﬁned with this approach. Following the Finite State Automata to Petri Nets example, we call TF SA−P N the (transformation) model mapping MF SA to MP N , respectively the models depicted by Fig. 2 (a) and (b). The two models conform to their metamodels M MF SA and M MP N , respectively. Applying the technique Fig. 8. Schema of domaindescribed in this section, domain-specific pattern speciﬁc transformation lanlanguages are generated from these metamodels, guages namely P LF SA and P LP N respectively. The metamodels of the patterns (speciﬁc to this transformation) combined with the metamodel of the transformation control logic language, in our example MoTif, form the transformation language T LF SA−P N . The transformation TF SA−P N is thus a model conforming to its metamodel T LF SA−P N . One of the big advantages of such explicit transformation language modeling is the possibility to easily deﬁne higher-order transformations.

4

Higher-Order Transformations

There is ample motivation for transforming transformations by means of higherorder transformations. Promising application areas include: Language evolution: Whenever the deﬁnition of a language evolves, any associated transformations have to be adapted. This adaptation process may sometimes be semi-automated by using a higher-order transformation generated from the modiﬁcations made to the language. Transformation optimization: Optimizing transformations could modify transformations so that they and/or their results are more eﬃcient.

250

T. K¨ uhne et al.

Transformation definition: In some cases, one can obtain a translational semantics from an operational semantics by use of a higher-order transformation, so that one has ease of deﬁnition plus advanced analysis opportunities [13]. One may also deﬁne the meaning of transformations using high-level constructs by mapping them onto standard transformations [14]. Separation of transformation concerns: Instead of putting all functionality into one transformation, one can split concerns over many transformations and integrate them by sequentially adding them with higher-order transformations to a base transformation. Often one may use multi-stage transformations for the same eﬀect, but sometimes this is not a viable option (see Sect. 4.2). Separating transformation concerns from each other does not only reduce the complexity of an otherwise monolithic transformation but also opens up the opportunity to reuse (higher-order) transformations. 4.1

Source-Level Animation

In conjunction, the “Finite State Automaton to Petri Net” and operational Petri net semantics transformations presented in Sect. 2 simulate a language recognizer but without visualizing the execution at the source level of state automata. In order to add source-level animation, we need to add update rules (see Fig. 9) to the operational Petri net semantics. AToM3 then automatically takes care of updating the respective concrete syntax.

Fig. 9. Animation Rules

Having explicitly modeled all artifacts, we are now in a position to deﬁne a higher-order transformation which automatically adds the update rules to the operational semantics transformation. Block “1” at the bottom of the LHS pattern in Fig. 10 is a parameter to the higher-order transformation AddAnimation and contains all the update rules of Fig. 9. We perform the parameter passing by using the block as a pivot model. The RHS of higher-order transformation AddAnimation simply links the update block into the main loop of the original semantics control structure (see Fig. 5), making sure this happens only once at the top level (hence the NAC).

Explicit Transformation Modeling

251

Figure 11 shows the result of applying higher-order transformation AddAnimation to the original control ﬂow shown in Fig. 5. Note that being able to modify an explicit representation of a transformation’s control structure allowed us to design AddAnimation in a way that makes it reusable. As long as one designs other operational semantics deﬁnitions Fig. 10. H-O Transformation: Animation with a similar overall main loop and provides corresponding update rules as a parameter to AddAnimation, the latter can be reused as is. Had we designed the operational semantics transformation to perform a single step only, it would have been possible to add animation using a multi-stage transformation approach as well (i.e., sequential execution of transformations). The transformation we discuss next, however, cannot be easily expressed by a multi-stage approach. 4.2

Correspondence Links

Animation update rules make use of correspondence links between ﬁnite state automata and Petri net models (see element “4” of Fig. 9). These correspondence links sometimes coincide with the intermediate generic links used in the “Finite State Automaton to Petri net” transformation, but the latter are not a reliable source for establishing correspondence. Furthermore, they are typically removed as part of the transforma- Fig. 11. Final Petri Net tion in order not to waste memory space. Control Flow We can, however, automate the insertion of relevant correspondence links by adding correspondence associations between certain language elements at the metamodel level, i.e., by creating a “meta-triple” [15] (see Fig. 12). With this additional information, a higher-order transformation that extends the “Finite State Automaton to Petri net” transformation with the feature of establishing correspondence links, can be deﬁned with a simple, single rule (see Fig. 13). This rule transforms translation rules such that they automatically insert corresponding links between respective input-output language element pairs. Note that Petri net places are linked to both state automaton states and events. It is therefore crucial to have the context of the original translation rule that creates an output language element based on the presence of an input language element. The rule in Fig. 13 speciﬁcally matches such creation

252

T. K¨ uhne et al.

patterns. Establishing the correct links between corresponding input-output elements without this contextual knowledge would, in general, be impossible. This demonstrates that higher-order transformations cannot be subsumed by multistage transformations. Our correspondence higherorder transformation is not directly reusable because MoTif does not support parameterization of rules yet. Because of this limitation we could not formulate a generic version of the transformation that can be tailored to a particular application by passing in the names of metamodel elements of input/output language types. Fig. 12. Correspondence Meta Triple However, the transformation is reusable with respect to its structure. Another application can simply be obtained by a manual renaming of the input/output language types.

Fig. 13. H-O Transformation: Correspondence Links

5

Related Work

The need to relax conformance rules occurs in other areas as well. Levendovszky et al. capture domain-speciﬁc design patterns which also inherently are fragments of proper models [16]. Instead of creating a relaxed version of the metamodel, they use relaxed conformance, i.e., “relaxed instantiation”. This allows them to use one original language deﬁnition to check both proper models and design patterns. Since they only need to support this one variant of conformance checking, this is a viable approach. In general, however, the explicit modeling of transformations may require a multitude of conformance levels, making the

Explicit Transformation Modeling

253

relaxation of metamodels a more attractive option (see Sect. 3.2). Levendovsky et al., furthermore, observe that simply setting all minimal multiplicities to zero will allow the formulation of fragments which cannot be completed to proper models. They suggest detecting such fragments by using constraint solving. This approach is applicable in our context as well and could be realized by adding corresponding constraints to the relaxed metamodels. Varr´o and Pataricza seem to have been the ﬁrst to suggest higher-order transformations for improving the performance and maintainability of ﬁrst-order transformations [17] (see Sect. 4). Sch¨ urr’s triple graph grammars are designed to support correspondence links between models from declarative rules [18]. In contrast to our respective higherorder transformation, a Tgg transformation designer is more ﬂexible in deﬁning diﬀerent correspondence links per rule. However, this also bears the risk that some correspondence links are forgotten or incorrectly established. A higherorder transformation like ours automates the process of establishing the required links and will be comparatively simple to correctly deﬁne, even for more advanced cases. Moreover, we may generate correspondence links with arbitrary amounts of additional information in contrast to the ﬁxed format links of Tggs. Jouault used Atl to deﬁne a higher-order transformation for automatically generating traceability links [19]. Unlike our correspondence link higher-order transformation, however, Jouault’s TraceAdder transformation adds traceability links between all elements rather then correspondence links. Traceability links can sometimes be used for tracking correspondences as well but not in general. Furthermore, while traceability links come for free as they do not need pattern speciﬁcations that only match relevant correspondences, they may use up a lot of memory albeit the majority of them is not being used in correspondence mapping applications. The main problem with using Atl for specifying higher-order transformations is that a higher-order Atl transformation has access to the transformation deﬁnition (e.g., to the FSA-to-PN transformation), but not to the latter’s respective input and output languages (the FSA and PN metamodels). All matching patterns and output patterns for the input/output languages of the transformation are therefore unchecked as they occur on a purely textual basis only. This results in even mundane syntactic errors going unnoticed. This problem is aggravated by the fact that the result of the higherorder transformation must be tested dynamically in order to detect the errors. Sometimes the only means to detect errors is to examine the ﬁrst-order transformation’s output. Having detected errors in the output, one then has to trace back the errors to the ﬁrst-order transformation and from there back to the higher-order transformation. While there will always be a class of errors that will require this extended backward reasoning, our approach can avoid this complicated procedure for purely syntactical errors.

6

Conclusion

Although we discussed our work and developed our artifacts in the context of AToM3 /MoTif, our ideas and results are by no means conﬁned to the speciﬁcs

254

T. K¨ uhne et al.

of this combination. Our proposal to explicitly model transformation deﬁnitions is applicable to a wide range of transformation approaches. While it is not necessary to explicitly model all aspects of transformation deﬁnitions, we have illustrated that there are beneﬁts associated with each such step. First, the explicit modeling of pattern speciﬁcations allowed the semi-automatic generation of customized pattern speciﬁcation language deﬁnitions based on the components of relaxation, augmentation, and modiﬁcation. It thus provided a cost-eﬀective way to obtain customized transformation development environments. Second, the explicit modeling of transformation control structures allowed the modular addition of new behavior, such as source-level animation. Third, the explicit modeling of transformation rules allowed the automated enhancement of transformation rules, e.g., the insertion of correspondence links. With the latter application of a higher-order transformation we have demonstrated that such higher-order transformations cannot be replaced by a multi-stage approach using ﬁrst-order transformations only. This paper builds on our previous work [20] by demonstrating how our approach can facilitate higher-order transformations. The higher-order transformations we presented not only help to reduce the complexity of the basetransformations they are applied to, but are also reusable. The transformations we presented are furthermore applicable in a wide range of similar contexts. This and their reusability is a direct result of explicitly modeling all aspects of transformations including their control ﬂow aspects. In contrast to Atl higher-order transformations, ours can be fully checked for well-formedness violations. Summarizing, we provided further motivation for the utility of higher-order transformations, demonstrated the beneﬁts of explicitly modeling transformations and proposed ways to economically enable their deﬁnition.

References 1. Atkinson, C., K¨ uhne, T.: A tour of language customization concepts. Advances in Computers 70(3), 105–161 (2007) 2. Czarnecki, K., Helsen, S.: Feature-based survey of model transformation approaches. IBM Systems Journal, special issue on Model-Driven Software Development 45(3), 621–645 (2006) 3. Jouault, F., Kurtev, I.: Transforming models with ATL. In: Bruel, J.-M. (ed.) MoDELS 2005. LNCS, vol. 3844, pp. 128–138. Springer, Heidelberg (2006) 4. de Lara, J., Vangheluwe, H.: AToM3 : A tool for multi-formalism and metamodelling. In: Kutsche, R.-D., Weber, H. (eds.) FASE 2002. LNCS, vol. 2306, pp. 174–188. Springer, Heidelberg (2002) 5. Agrawal, A., Karsai, G., Kalmar, Z., Neema, S., Shi, F., Vizhanyo, A.: The design of a language for model transformations. SoSym 5(3), 261–288 (2006) 6. 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) 7. Object Management Group: Meta Object Facility 2.0 Query/View/Transformation Speciﬁcation (April 2008)

Explicit Transformation Modeling

255

8. Lengyel, L., Levendovszky, T., Mezei, G., Charaf, H.: Control ﬂow support in metamodel-based model transformation frameworks. In: EUROCON 2005, Belgradem, Serbia, pp. 595–598. IEEE, Los Alamitos (2005) 9. B´ezivin, J., B¨ uttner, F., Gogolla, M., Jouault, F., Kurtev, I., Lindow, A.: Model transformations? transformation models! In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 440–453. Springer, Heidelberg (2006) 10. B´ezivin, J., Farcet, N., J´ez´equel, J.M., Langlois, B., Pollet, D.: Reﬂective model driven engineering. In: Stevens, P., Whittle, J., Booch, G. (eds.) UML 2003. LNCS, vol. 2863, pp. 175–189. Springer, Heidelberg (2003) 11. Tisi, M., Jouault, F., Fraternali, P., Ceri, S., B´ezivin, J.: On the use of higher-order model transformations. In: Paige, R.F., Hartman, A., Rensink, A. (eds.) ECMDAFA 2009. LNCS, vol. 5562, pp. 18–33. Springer, Heidelberg (2009) 12. Syriani, E., Vangheluwe, H.: Programmed graph rewriting with DEVS. In: Sch¨ urr, A., Nagl, M., Z¨ undorf, A. (eds.) AGTIVE 2007. LNCS, vol. 5088, pp. 136–151. Springer, Heidelberg (2008) 13. de Lara, J., Vangheluwe, H.: Automating the transformation-based analysis of visual languages. In: Formal Aspects of Computing, Special section on FASE (2008) (to appear) 14. Gorp, P.V., Keller, A., Janssens, D.: Transformation language integration based on proﬁles and higher-order transformations. In: Gaˇsevi´c, D., L¨ ammel, R., Van Wyk, E. (eds.) SLE 2008. LNCS, vol. 5452, pp. 208–226. Springer, Heidelberg (2009) 15. Guerra, E., de Lara, J.: Event-driven grammars: Relating abstract and concrete levels of visual languages. SoSym 6(6), 317–347 (2007) 16. Levendovszky, T., Lengyel, L., M´esz´ aros, T.: Supporting domain-speciﬁc model patterns with metamodeling. Software and Systems Modeling, Theme Issue on Metamodeling (2009) (to appear) 17. Varr´ o, D., Pataricza, A.: Generic and meta-transformations for model transformation engineering. In: Baar, T., Strohmeier, A., Moreira, A., Mellor, S.J. (eds.) UML 2004. LNCS, vol. 3273, pp. 290–304. Springer, Heidelberg (2004) 18. Sch¨ urr, A.: Speciﬁcation 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. Jouault, F.: Loosely coupled traceability for atl. In: ECMDA Workshop on Traceability (2005) 20. K¨ uhne, T., Mezei, G., Syriani, E., Vangheluwe, H., Wimmer, M.: Systematic transformation development. ECEASST 21 (October 2009)

Ninth International Workshop on the Pragmatics of OCL and Other Textual Specification Languages Jordi Cabot1 , Joanna Chimiak–Opoka2 , Martin Gogolla4, Fr´ed´eric Jouault3 , and Alexander Knapp5 1

4

Open University of Catalonia, Spain [email protected] 2 University of Innsbruck, Austria [email protected] 3 University of Bremen, Germany [email protected] ´ INRIA-Ecole des Mines de Nantes, France [email protected] 5 University of Augsburg, Germany [email protected]

Abstract. This paper reports on the 9th OCL workshop held at the MODELS conference in 2009. The workshop focused on the challeges of using OCL in a variety of new scenarios (e.g., model verification and validation, code generation, test-driven development, transformations) and application domains (e.g., domain-specific languages, web semantics) in which OCL is now being used due to the increasing popularity of model-driven development processes and the important role OCL play in them. The workshop included sessions with paper presentations and a final round discussion.

1

Introduction

In recent years, model-driven methodologies, approaches and languages (like QVT) emphasized the role that OCL has to play in all kinds of model-based software development. Now, OCL is being used for quite diﬀerent purposes (e.g., model veriﬁcation and validation, code generation, test–driven development, transformations) and application domains (domain–speciﬁc languages, web semantics). Successfully adapting OCL to all these diﬀerent scenarios requires strong research on alternative notations/representations for OCL that simplify its application, improvements and clariﬁcations on its semantics, modular language extensions, new evaluation techniques, mappings from OCL to other languages and formalisms and of course, the tools that will make all of this possible among many other relevant aspects. The papers presented in the workshop covered many of these interesting topics. All submitted papers were reviewed by three industrial or academic members from the Program Committee: S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 256–260, 2010. c Springer-Verlag Berlin Heidelberg 2010

Ninth International Workshop on the Pragmatics of OCL

– – – – – – – – – – – – – – – – –

2

257

Thomas Baar, Tech@Spree, Germany Achim Brucker, SAP, Germany Manuel Clavel, IMDEA Software Institute, Spain Dan Chiorean, University of Cluj, Romania Tony Clark, Thames Valley University, UK Birgit Demuth, Technical University of Dresden, Germany Remco Dijkman, Eindhoven University of Technology, The Netherlands Robert France, University of Fort Collins, USA Heinrich Hußmann, University of Munich, Germany Tihamer Levendovszky, Vanderbilt University, USA Richard Mitchell, Inferdata, UK Richard Paige, University of York, UK Mark Richters, Astrium Space Transportation, Germany Shane Sendall, IBM, Switzerland Pieter Van Gorp, University of Eindhoven Burkhart Wolﬀ, LRI, University Paris–Sud, France Steﬀen Zschaler, Lancaster University, UK

Workshop Papers

Ten papers were accepted for presentation in the workshop. In the following, we list all papers and give a short overview of each paper from the abstracts provided by the authors (except for the two papers selected as best workshop papers, already included in this same volume in full length). Polished versions of the workshop papers will appear in an EASST special issue. 2.1

Extending OCL with Null–References: Towards a Formal Semantics for OCL 2.1 by Achim D. Brucker, Matthias P. Krieger and Burkhart Wolﬀ

Full paper is published in this volume. 2.2

On Better Understanding OCL Collections -or- An OCL Ordered Set Is Not an OCL Set by Fabian Buettner, Martin Gogolla, Lars Hamann and Mirco Kuhlmann

Full paper is published in this volume. 2.3

Checking Unsatisﬁability for OCL constraints by Manuel ˜ ˜ de Dios Clavel, Marina Egea and Miguel Angel GarcAa

In this paper we propose a mapping from a subset of OCL into ﬁrst–order logic (FOL) and use this mapping for checking the unsatisﬁability of sets of OCL constraints. Although still preliminary work, we argue in this paper that our mapping is both simple, since the resulting FOL sentences closely mirror the original OCL constraints, and practical, since we can use automated reasoning tools, such as automated theorem provers and SMT solvers to automatically check the unsatisﬁability of non–trivial sets of OCL constraints.

258

2.4

J. Cabot et al.

A Metamodel Based Approach for Inconsistency Detection by Mohammad Ariyan, Jafar Habibi and Ali Kamandi

One of the important issues in software modeling languages is consistency management inside models. Although UML as a standard for software modeling has been very successful compared to its predecessors, inconsistency is one of its unresolved problems. In recent years, much work has been done to detect inconsistencies in models of a language (e.g. UML), but limited research has been done to detect inconsistencies in the metamodel level. This paper presents a method for discovering possible inconsistencies at the modeling language design level. The precise semantics of the metamodel along with a target (possibly inconsistent) model are the inputs to this method. We deﬁne a translation of the input into ﬁrst order predicate logic and logical reasoning is used to detect possible inconsistencies. The method will help modelers prevent modeling inconsistencies. 2.5

OCL Contracts for the Veriﬁcation of Model Transformations by Eric Cariou, Belloir Nicolas, Franck Barbier and Nidal Djemam

A model–driven engineering process relies on a set of transformations which are usually sequentially executed, starting from an abstract level to produce code or a detailed implementation speciﬁcation. These transformations may be entirely automated or may require manual intervention by designers. In this paper, we propose a method to verify that a transformation result is correct with respect to the transformation speciﬁcation. This method both includes automated transformations and manual interventions. For that, we focus on transformation contracts written in OCL. This leads to making the proposed method independent of modeling and transformation tools. These contracts are partially or fully generated through a dedicated tool. 2.6

Requirements Analysis for an Integrated OCL Development Environment by Joanna Chimiak–Opoka, Birgit Demuth, Darius Silingas and Nicolas F. Rouquette

An Integrated OCL Development Environment (IDE4OCL) can signiﬁcantly improve the pragmatics and praxis of OCL. We present the domain concepts, tool level interactions with OCL and the use cases we identiﬁed in a systematic analysis of requirements for an IDE4OCL. The domain concepts is an important contribution of our work as it attempts to clarify inconsistencies in the relevant speciﬁcations. Because OCL is not a standalone language, the OCL landscape includes several interacting tools including an IDE4OCL. The use cases describe our vision of the desired functionality unique to an IDE4OCL. The results of our analysis and the long term vision of our work should be relevant to developers of OCL tools as well as to the OMG Request for Information regarding the UML Futures5. Our work is relevant to the UML Futures Roadmap because providing OCL for the constraints in the UML speciﬁcation has been a longstanding problem at the OMG.

Ninth International Workshop on the Pragmatics of OCL

2.7

259

Generation of Formal Model Metrics for MOF based Domain Speciﬁc Languages by Christian Hein, Marcus Engelhardt, Tom Ritter and Michael Wagner

The assessment of quality in a software development process is vital for the quality of the ﬁnal system. A number of approaches exist, which can be used to determine such quality properties. In a model–driven development process models are the primary artifacts. Novel technologies are needed in order to assess the quality of those artifacts. Often, the Object Constraint Language (OCL) is used to formulate model metrics and to compute them automatically afterwards. This paper describes an approach for the generation of model metrics expressed as OCL statements based on a set of generic rules. These rules can be applied on any domain speciﬁc modeling languages for creating a basic set of metrics which can be tailored for the speciﬁc needs of a development process. The paper also brieﬂy describes a prototype of a tool for the generation, computation, and management of these model metrics by using the Software Metrics Meta–model — SMM. 2.8

A MOP Based DSL for Testing Java Programs Using OCL by Tony Clark

OCL is used to specify systems by deﬁning pre and postconditions for class operations. Typically, the conditions refer to properties and operations that are deﬁned in a model. When the model is implemented, various implementation decisions are made regarding properties and operations that cause the OCL conditions to be inconsistent with the implementation. This paper deﬁnes a domain speciﬁc language (DSL) for testing and shows how a meta–object–protocol for OCL can be used to dynamically run tests written in the DSL against diﬀerent Java implementations of the same model. 2.9

Declarative Models for Business Processes and UI Generation Using OCL by Jens Br¨ uning and Andreas Wolﬀ

This paper presents an approach to model business processes and associated user interfaces in a declarative way, relying on constraints. An UML–based meta–model to deﬁne processes, activities and user–interface objects is proposed. Connecting activities and user interface objects in an integrated model allows expressing interdependencies and mutual eﬀects. Flexible execution logic for workﬂows and UI control ﬂows are speciﬁed by OCL invariants. The model is constructed for the UML tool USE. Using object snapshots, USE can animate and validate business scenarios. Snapshots represent states of a process and a UI at speciﬁc times. Such animation enables business process and UI designers to discuss sensible scenarios on basis of the ﬂexible declarative models. The intention is to create validated concrete process models in connection with UI elements that will provide a basis for the system implementation.

260

J. Cabot et al.

2.10

Specifying OCL Constraints on Process Instantiations by Peter Killisperger, Markus Stumptner, Georg Peters and Thomas Stueckl

Due to the variety of concerns aﬀecting software development in large organisations, processes have to be adapted to project speciﬁc needs to be eﬀectively applicable in individual projects. We describe a project aiming to provide tool support for this individualised instantiation of reference processes, based on an OCL–based speciﬁcation of instantiation operations. The aim is not only to execute instantiation decisions made by humans but to automatically ensure correctness of the resulting process, potentially resulting in followup actions being executed or suggested.

3

Lessons Learned

During the workshop a broad spectrum of topics was discussed: syntax, semantics and pragmatics of the language, using formal or lightweight approaches, discussing core OCL aspects or its application in diﬀerent domains and presented by a mixture of academic and industrial participants. Several papers pointed out semantic inconsistencies with the current standard speciﬁcation of the language and presented concrete solutions to those problems (papers 2.1, 2.2 and 2.6). This triggered a very interesting discussion on the OCL standardization process and on how the OCL workshop community could have a more tight cooperation with the standardization committee to increase the desired community– driven character of the OCL language and thus improve quality of the OCL speciﬁcation by opening a communication channel to easily report on the issues and improvements discussed during the workshop. A second set of papers showed once again the broad application scenarios of OCL (this was also observed in other workshops and the main conference). Papers in the workshop presented the use of OCL as constraint or query language (papers 2.3 and 2.4 ) at the user model or metamodel levels (either in the context of MOF, paper 2.7, or as part of domain speciﬁc languages) and its usefulness as part of testing activities (paper 2.8), model transformations (paper 2.5) and business process modelling (papers 2.9 and 2.10). This lead to a long discussion regarding tool support for OCL, a key aspect in all application scenarios. In this context, an initiative for a community–driven speciﬁcation and development of a new user–friendly OCL tool was presented (paper 2.6). As part of discussion, attendees were asked to ﬁll in questionnaires regarding the most important features a user–friendly OCL tool should have. Everybody agreed on the importance of such initiative and was eager to propose new features for the tool to-do list (or better said wish list). Architectural aspects and possible strategies for a collaborative-building eﬀort of such a tool were also discussed.

Extending OCL with Null-References Towards a Formal Semantics for OCL 2.1 Achim D. Brucker1, Matthias P. Krieger2, and Burkhart Wolﬀ2 1

2

SAP

Research, Vincenz-Priessnitz-Str. 1, 76131 Karlsruhe, Germany [email protected] Université Paris-Sud, Parc Club Orsay Université, 91893 Orsay Cedex, France {krieger, wolff}@lri.fr

Abstract. From its beginnings, OCL is based on a strict semantics for undeﬁnedness, with the exception of the logical connectives of type Boolean that constitute a three-valued propositional logic. Recent versions of the OCL standard added a second exception element, which, similar to the null references in object-oriented programming languages, is given a non-strict semantics. Unfortunately, this extension has been done in an ad hoc manner, which results in several inconsistencies and contradictions. In this paper, we present a consistent formal semantics (based on our HOL-OCL approach) that includes such a non-strict exception element. We discuss the possible consequences concerning class diagram semantics as well as deduction rules. The beneﬁts of our approach for the speciﬁcation-pragmatics of design level operation contracts are demonstrated with a small case-study. Keywords: HOL-OCL, UML, OCL, null reference, formal semantics.

1

Introduction

The Object Constraint Language (OCL) is used for specifying constraints such as well-formedness rules and for deﬁning object-oriented designs through operation contracts and class invariants. The expressions of OCL constitute the core of the language. In essence, OCL allows for evaluating queries over UML models. From its beginnings, OCL has been equipped with the notion of an undeﬁned value (called invalid in [17]) to deal with exceptions occurring during expression evaluation. A classical example of such an exception is a division by zero. In OCL such an erroneous division is speciﬁed to yield an undeﬁned value. Other reasons for exceptions include attempting to retrieve elements from empty collections, illegal type conversions and evaluating attributes on objects that do not exist. Most operations in OCL are deﬁned to be strict, i. e., they evaluate to invalid if they are called with an undeﬁned argument. This ensures that errors are propagated during expression evaluation so they are visible and can be handled

This work was partially supported by the Digiteo Foundation.

S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 261–275, 2010. c Springer-Verlag Berlin Heidelberg 2010

262

A.D. Brucker, M.P. Krieger, and B. Wolﬀ

later on. Naturally, OCL collections are not allowed to have undeﬁned elements, since errors are more easily signaled by marking the collection value as undeﬁned. During the development of OCL, the potential beneﬁts of a second exception element in addition to invalid became clear. This second exception element, called null, is intended to represent the absence of value. The need to express the absence of value arises naturally when dealing with object attributes with a multiplicity lower bound of zero. These attributes, that occur frequently in models, are not required to yield a value when evaluated. Representing this absence of value with the original undeﬁned value invalid would be inconvenient. To prevent a propagation of undeﬁned values, it would be necessary to handle all cases of value absence immediately. In particular, it would not be possible to pass potentially null values to strict operations. Since nearly all operations of OCL are strict, even the most basic operations such as equality testing would need to check for null. These diﬃculties can be avoided by introducing the second exception element null as a valid operation argument and collection element. The latest OCL 2.0 standard [17] introduces null for representing the absence of a value. This extension has been done in an ad hoc manner, which results in several inconsistencies and contradictions. For example, both invalid and null are deﬁned to conform to all classiﬁers, in particular null conforms to invalid and vice versa. Since the conforms relationship is antisymmetric, this implies that invalid and null are indistinguishable. The standard does not state clearly when object attributes can evaluate to null and how this depends on its multiplicity. The standard does also not clarify whether objects that do not exist (“dangling references”) are treated the same way as null or not. Our contribution is a proposal for a formal semantics that overcomes these problems in the current version of the OCL standard. From this semantics, we derive formally and informally numerous rules, which could be included in the mandatory part of a standardization document, while our semantics could serve as foundation of a future “Annex A.” We proceed as follows: In Section 3, we provide a summary of the essentials of the HOL-OCL semantics as it could be found in semantics textbooks (rather than a technical presentation motivated by machine readable documents). Nevertheless, our semantics is a strong formal, i. e., machine-checked semantics largely following [16, Annex A]. In Section 4, we present as an increment our proposal for OCL 2.1, focusing on the key issue of null-elements and null-types. In Section 5, we will discuss the consequences for an omnipresent feature of UML, namely multiplicities, and its pragmatics. Finally, in Section 6 we will show how the extended language can be used to describe pretty standard contracts at design-level for object-oriented programs.

2 2.1

Formal and Technical Background Higher-Order Logic

Higher-order Logic (HOL) [8,1] is a classical logic with equality enriched by total parametrically polymorphic higher-order functions. It is more expressive than ﬁrst-order logic, e. g., induction schemes can be expressed inside the logic.

Extending OCL with Null-References

263

HOL is based on the typed λ-calculus, i. e., the terms of HOL are λ-expressions. Types of terms may be built from type variables (like α, β, . . . , optionally annotated by Haskell-like type classes as in α :: order or α :: bot) or type constructors. Type constructors may have arguments (as in α list or α set). The type constructor for the function space ⇒ is written inﬁx: α ⇒ β; multiple applications like τ1 ⇒ (. . . ⇒ (τn ⇒ τn+1 ) . . .) have the alternative syntax [τ1 , . . . , τn ] ⇒ τn+1 . HOL is centered around the extensional logical equality _ = _ with type [α, α] ⇒ bool, where bool is the fundamental logical type. We use inﬁx notation: instead of (_ = _) E1 E2 we write E1 = E2 . The logical connectives _ ∧_, _∨_, _ ⇒ _ of HOL have type [bool, bool] ⇒ bool, ¬_ has type bool ⇒ bool. The quantiﬁers ∀ _._ and ∃ _._ have type [α ⇒ bool] ⇒ bool. The quantiﬁers may range over types of higher order, i. e., functions or sets. The deﬁnition of the element-hood _ ∈ _, the set comprehension {_._}, as well as _ ∪ _ and _ ∩ _ are standard. The Isabelle/HOL library [15] contains formal deﬁnitions and theorems for practically all mathematical concepts used in computer science, including typed set theory, well-founded recursion theory, number theory and theories for datastructures like Cartesian products α × β and disjoint type sums α + β. The library also includes the type constructor τ⊥ := ⊥ | _ : α that assigns to each type τ a type τ⊥ disjointly extended by the exceptional element ⊥. The function _ : α⊥ ⇒ α is the inverse of _ (unspeciﬁed for ⊥). Partial functions α β are deﬁned as functions α ⇒ β⊥ supporting the usual concepts of domain (dom _) and range (ran _). The library is built entirely by logically safe, conservative deﬁnitions and derived rules. This methodology is also applied to HOL-OCL.

2.2

A Brief Introduction to the HOL-OCL System

HOL-OCL [6,4] is integrated into a framework [3] supporting a formal, modeldriven software engineering process. Technically, HOL-OCL is based on a repository for UML/OCL models and on Isabelle/HOL. HOL-OCL also reuses and ex-

tends the existing Isabelle front-end called Proof General as well as the Isabelle documentation generator.

3

An Overview over OCL Semantics

In this section, we will brieﬂy introduce OCL semantics from the HOL-OCL perspective. The main diﬀerences between the OCL 2.0 formal semantics description [16, Annex A] and HOL-OCL is that the latter is a machine-checked, “strong” formal semantics which is itself based on a typed meta-language (i. e., HOL) instead of an untyped one (i. e., naïve set theory), and various technical simpliﬁcations: instead of three diﬀerent semantic interpretation functions I(x), Ieτ , IAtt eτ , we use only one. The ﬁrst diﬀerence enables us to give a semantic consistency guarantee: Since all deﬁnitions of our formal semantics are logically safe extensions, i. e., conservative [12] and since all rules are derived, the consistency of HOL-OCL is reduced to the consistency of HOL, i. e., a widely accepted small

264

A.D. Brucker, M.P. Krieger, and B. Wolﬀ

system of seven axioms. The second diﬀerence dramatically reduces the number of rules necessary for formal reasoning. In this presentation we will avoid to show the key-deﬁnitions used inside HOL-OCL; rather, for the sake of making this work amenable to a wider audience, we will use a “textbook-style” presentation of the semantics which is formally shown to be equivalent (for details, see [6]). 3.1

Validity and Evaluations

The topmost goal of the formal semantics is to deﬁne the validity statement: (σ, σ ) P , where σ is the pre-state and σ the post-state of the underlying system and P is a Boolean expression (a formula). The assertion language of P is composed of 1) operators on built-in data structures such as Boolean or set, 2) operators of the user-deﬁned data-model such as accessors, type-casts and tests, and 3) userdeﬁned, side-eﬀect-free methods. Informally, a formula P is valid if and only if its evaluation in the context (σ, σ ) yields true. As all types in HOL-OCL are extended by the special element ⊥ denoting undeﬁnedness, we deﬁne formally: (σ, σ ) P ≡ P (σ, σ ) = true . Since all operators of the assertion language depend on the context (σ, σ ) and result in values that can be ⊥, all expressions can be viewed as evaluations from (σ, σ ) to a type τ⊥ . All types of expressions are of a form captured by V(α) := state × state ⇒ α⊥ , where state stands for the system state and state × state describes the pair of pre-state and post-state and _ := _ denotes the type abbreviation. The OCL semantics [16, Annex A] uses diﬀerent interpretation functions for invariants and pre-conditions; we achieve their semantic eﬀect by a syntactic transformation _pre which replaces all accessor functions _. a by their counterparts _. a @pre. For example, (self . a > 5)pre is just (self . a @pre > 5). 3.2

Strict Operations

An operation is called strict if it returns ⊥ if one of its arguments is ⊥. Most OCL operations are strict, e. g., the Boolean negation is formally presented as:

Inot Xτ ≡

¬IXτ if IXτ = ⊥, ⊥ otherwise .

where τ = (σ, σ ) and I_ is a notation marking the HOL-OCL constructs to be deﬁned. This notation is motivated by the deﬁnitions in the OCL standard [16]. In our case, I_ is just the identity, i. e., IX ≡ X. These constructs, i. e., not _ are HOL functions (in this case of HOL type V(bool) ⇒ V(bool)) that can be viewed as transformers on evaluations.

Extending OCL with Null-References

265

The binary case of the integer addition is analogous: IX τ + IY τ if IX τ = ⊥ and IY τ = ⊥, IX + Y τ ≡ ⊥ otherwise . Here, the operator _ + _ on the right refers to the integer HOL operation with type [int, int] ⇒ int. The type of the corresponding strict HOL-OCL operator _ + _ is [V(int), V(int)] ⇒ V(int). A slight variation of this deﬁnition scheme is used for the operators on collection types such as HOL-OCL sets or sequences: S IXτ ∪ IY τ if IXτ = ⊥ and IY τ = ⊥, IX->union(Y )τ ≡ ⊥ otherwise. Here, S (“smash”) is a function that maps a lifted set X to ⊥ if and only if ⊥ ∈ X and to the identity otherwise. Smashedness of collection types is the natural extension of the strictness principle for data structures. Intuitively, the type expression V(τ ) is a representation of the type that corresponds to the HOL-OCL type τ . We introduce the following type abbreviations: Boolean := V(bool) , Integer := V(int) , and

Set(α) := V(α set) , Sequence(α) := V(α list) .

The mapping of an expression E of HOL-OCL type T to a HOL expression E of HOL type T is injective and preserves well-typedness. 3.3

Boolean Operators

There is a small number of explicitly stated exceptions from the general rule that HOL-OCL operators are strict: the strong equality, the deﬁnedness operator and the logical connectives. As a prerequisite, we deﬁne the logical constants for truth, absurdity and undeﬁnedness. We write these deﬁnitions as follows: Itrueτ ≡ true ,

Ifalseτ ≡ false , and Iinvalidτ ≡ ⊥ . . HOL-OCL has a strict equality _ = _. On the primitive types, it is deﬁned similarly to the integer addition; the case for objects is discussed later. For logical purposes, we introduce also a strong equality _ _ which is deﬁned as follows: IX Y τ ≡ (IX τ = IY τ ) , where the _ = _ operator on the right denotes the logical equality of HOL. The undeﬁnedness test is deﬁned by X .oclIsInvalid() ≡ (X invalid). The . strong equality can be used to state reduction rules like: τ (invalid = X) invalid. The OCL standard requires a Strong Kleene Logic. In particular: ⎧ ⎪ ⎨x ∧ y if x = ⊥ and y = ⊥, IX and Y τ ≡ false if x = false or y = false, ⎪ ⎩ ⊥ otherwise . where x = IXτ and y = IY τ . The other Boolean connectives were just shortcuts: X or Y ≡ not (not X and not Y ) and X implies Y ≡ not X or Y .

266

3.4

A.D. Brucker, M.P. Krieger, and B. Wolﬀ

Object-Oriented Data Structures

Now we turn to several families of operations that the user implicitly deﬁnes when stating a class model as logical context of a speciﬁcation. This is the part of the language where object-oriented features such as type casts, accessor functions, and tests for dynamic types come into play. Syntactically, a class model provides a collection of classes C, an inheritance relation _ < _ on classes and a collection of attributes A associated to classes. Semantically, a class model means a collection of accessor functions (denoted _.a :: A → B and _. a @pre :: A → B for a ∈ A and A, B ∈ C), type casts that can change the static type of an object of a class (denoted _.oclAsType(C) of type A → C) and dynamic type tests (denoted _.oclIsTypeOf(C)). A precise formal deﬁnition can be found in [6]. Class models: A simplified semantics. In this section, we will have to clarify the notions of object identifiers, object representations, class types and state. We will give a formal model for this, that will satisfy all properties discussed in the subsequent section except one (see [5] for the complete model). First, object identiﬁers are captured by an abstract type oid comprising countably many elements and a special element nullid. Second, object representations model “a piece of typed memory,” i. e., a kind of record comprising administration information and the information for all attributes of an object; here, the primitive types as well as collections over them are stored directly in the object representations, class types and collections over them are represented by oid’s (respectively lifted collections over them). Third, the class type C will be the type of such an object representation: C := (oid × Ct × A1 × · · · × Ak ) where a unique tag-type Ct (ensuring type-safety) is created for each class type, where the types A1 , . . . , Ak are the attribute types (including inherited attributes) with class types substituted by oid. The function OidOf projects the ﬁrst component, the oid, out of an object representation. Fourth, for a class model M with the classes C1 , . . . , Cn , we deﬁne states as partial functions from oid’s to object representations satisfying a state invariant invσ : state := {f :: oid (C1 + . . . + Cn ) | invσ (f )} where invσ (f ) states two conditions: 1) there is no object representation for nullid: nullid ∈ / (dom f ). 2) there is a“one-to-one” correspondence between object representations and oid’s: ∀oid ∈ dom f. oid = OidOf f (oid). The latter condition is also mentioned in [16, Annex A] and goes back to Mark Richters [19]. 3.5

The Accessors

On states built over object universes, we can now deﬁne accessors, casts, and type tests of an object model. We consider the case of an attribute a of class C which has the simple class type D (not a primitive type, not a collection): ⎧ ⎪ if O = ⊥ ∨ OidOf O ∈ / dom σ ⎨⊥ Iself . a(σ, σ ) ≡ getD u if σ (getC σ (OidOf O). a(0) ) = u, ⎪ ⎩ ⊥ otherwise.

Extending OCL with Null-References

⎧ ⎪ ⎨⊥ Iself . a@pre(σ, σ ) ≡ getD u ⎪ ⎩ ⊥

267

if O = ⊥ ∨ OidOf O ∈ / dom σ if σ(getC σ(OidOf O). a) = u, otherwise.

where O = Iself (σ, σ ). Here, getD is the projection function from the object universe to D⊥ , and x. a is the projection of the attribute from the class type (the Cartesian product). For simple class types, we have to evaluate expression self , get an object representation (or undeﬁned), project the attribute, de-reference it in the pre or post state and project the class object from the object universe (getD may yield ⊥ if the element in the universe does not correspond to a D object representation.) In the case for a primitive type attribute, the de-referentiation step is left out, and in the case of a collection over class types, the elements of the collection have to be point-wise de-referenced and smashed. In our model accessors always yield (type-safe) object representations; not oid’s. Thus, a dangling reference, i. e., one that is not in dom σ, results in invalid (this is a subtle diﬀerence to [16, Annex A] where the undeﬁnedness is detected . one de-referentiation step later). The strict equality _ = _ must be deﬁned via . OidOf when applied to objects. It satisﬁes (invalid = X) invalid. The deﬁnitions of casts and type tests can be found in [5], together with other details of the construction above and its automation in HOL-OCL.

4

A Proposal for an OCL 2.1 Semantics

In this section, we describe our OCL 2.1 semantics proposal as an increment to the OCL 2.0 semantics (underlying HOL-OCL and essentially formalizing [16, Annex A]). In later versions of the standard [17] the formal semantics appendix reappears although being incompatible with the normative parts of the standard. Not all rules shown here are formally proven; technically, these are informal proofs “with a glance” on the formal proofs shown in the previous section. 4.1

Revised Operations on Primitive Types

In UML, and since [17] in OCL, all primitive types comprise the null-element, modeling the possibility to be non-existent. From a functional language perspective, this corresponds to the view that each basic value is a type like int option as in SML. Technically, this results in lifting any primitive type twice: Integer := V(int⊥ ) , etc. and basic operations have to take the null elements into account. The distinguishable undeﬁned and null-elements were deﬁned as follows: Iinvalidτ ≡ ⊥ and InullInteger τ ≡ ⊥ . An interpretation (consistent with [17]) is that nullInteger + 3 = invalid, and due to commutativity, we postulate 3 + nullInteger = invalid, too. The necessary modiﬁcation of the semantic interpretation looks as follows:

268

A.D. Brucker, M.P. Krieger, and B. Wolﬀ

IX + Y τ ≡

x + y ⊥

if x = ⊥, y = ⊥, x = ⊥ and y = ⊥ otherwise .

where x = IXτ and y = IY τ . The resulting principle here is that operations on the primitive types Boolean, Integer, Real, and String treat null as invalid . (except _ = _, _ .oclIsInvalid(), _ .oclIsUndefined(), casts between the diﬀerent representations of null, and type-tests). This principle is motivated by our intuition that invalid represents known errors, and null-arguments of operations for Boolean, Integer, Real, and String belong to this class. Thus, we must also modify the logical operators such that nullBoolean and false false and nullBoolean and true ⊥. With respect to deﬁnedness reasoning, there is a price to pay. For most basic operations we have the rule: not (X + Y ) .oclIsInvalid() (not X .oclIsUndefined()) and (not Y .oclIsUndefined()) where the test x .oclIsUndefined() covers two cases: x .oclIsInvalid() and . x = null (i. e., x is invalid or null). As a consequence, for the inverse case (X +Y ) .oclIsInvalid()1 there are four possible cases for the failure instead of two in the semantics described in [16]: each expression can be an erroneous null, or report an error. However, since all built-in OCL operations yield non-null el. ements (e. g., we have the rule not (X + Y = nullInteger )), a pre-computation can drastically reduce the number of cases occurring in expressions except for the base case of variables (e. g., parameters of operations and self in invariants). For these cases, it is desirable that implicit pre-conditions were generated as default, ruling out the null case. A convenient place for this are the multiplicities, which can be set to 1 (i. e., 1..1) and will be interpreted as being non-null (see discussion in Section 5 for more details). Besides, the case for collection types is analogous: in addition to the invalid collection, there is a nullSet(T) collection as well as collections that contain null values (such as Set{nullT }) but never invalid. 4.2

Null in Class Types

It is a viable option to rule out undeﬁnedness in object-graphs as such. The essential source for such undeﬁnedness are oid’s which do not occur in the state, i. e., which represent “dangling references.” Ruling out undeﬁnedness as result of object accessors would correspond to a world where an accessor is always set explicitly to null or to a deﬁned object; in a programming language without explicit deletion and where constructors always initialize their arguments (e. g., Spec# [2]), this may suﬃce. Semantically, this can be modeled by strengthening the state invariant invσ by adding clauses that state that in each object representation all oid’s are either nullid or element of the domain of the state. 1

The same holds for (X + Y ) .oclIsUndefined().

Extending OCL with Null-References

269

We deliberately decided against this option for the following reasons: 1. methodologically we do not like to constrain the semantics of OCL without clear reason; in particular, “dangling references” exist in C and C++ programs and it might be necessary to write contracts for them, and 2. semantically, the condition “no dangling references” can only be formulated with the complete knowledge of all classes and their layout in form of object representations. This restricts the OCL semantics to a closed world model.2 We can model null-elements as object-representations with nullid as their oid: Definition 1 (Representation of null-Elements). Let Ci be a class type with the attributes A1 , . . . , An . Then we define its null object representation by: InullCi τ ≡ (nullid, arbt , a1 , . . . , an ) where the ai are ⊥ for primitive types and collection types, and nullid for simple class types. arbt is an arbitrary underspecified constant of the tag-type. Due to the outermost lifting, the null object representation is a deﬁned value, and due to its special reference nullid and the state invariant, it is a typed value not “living” in the state. The nullT -elements are not equal, but isomorphic: Each type, has its own unique nullT -element; they can be mapped, i. e., casted, isomorphic to each other. In HOL-OCL, we can overload constants by parametrized polymorphism which allows us to drop the index in this environment. . The referential strict equality allows us to write self = null in OCL. Recall . that _ = _ is based on the projection OidOf from object-representations. 4.3

Revised Accessors

The modiﬁcation of the accessor functions is now straight-forward: ⎧ ⊥ ⎪ ⎪ ⎪ ⎨null D Iobj. a(σ, σ ) ≡ ⎪ get u D ⎪ ⎪ ⎩ ⊥

if Iobj(σ, σ ) = ⊥∨OidOf Iobj(σ, σ ) ∈ / dom σ (0) if getC σ (OidOf Iobj(σ, σ )). a = nullid if σ (getC σ (OidOf Iobj(σ, σ )). a(0) ) = u, otherwise.

The deﬁnitions for type-cast and dynamic type test—which are not explicitly shown in this paper, see [5] for details—can be generalized accordingly. In the sequel, we will discuss the resulting properties of these modiﬁed accessors. 2

In our presentation, the deﬁnition of state in Section 3 assumes a closed world. This limitation can be easily overcome by leaving “polymorphic holes” in our object representation universe, i. e., by extending the type sum in the state deﬁnition to C1 + · · · + Cn + α. The details of the management of universe extensions are involved, but implemented in HOL-OCL (see [5] for details). However, these constructions exclude knowing the set of sub-oid’s in advance.

270

A.D. Brucker, M.P. Krieger, and B. Wolﬀ

All functions of the induced signature are strict. This means that this holds for accessors, casts and tests, too: invalid. a invalid

invalid.oclAsType(C) invalid invalid.oclIsTypeOf(C) invalid

Casts on null are always valid, since they have an individual dynamic type and can be casted to any other null-element due to their isomorphism. nullA . a invalid

nullA.oclAsType(B) nullB nullA.oclIsTypeOf(A) true

for all attributes a and classes A, B, C where C < B < A. These rules are further exceptions from the standard’s general rule that null may never be passed as ﬁrst (“self ”) argument. 4.4

Other Operations on States

Deﬁning _ ::allInstances() is straight-forward; the only diﬀerence is the property T ::allInstances()->excludes(null) which is a consequence of the fact that null’s are values and do not “live” in the state. In our semantics which admits states with “dangling references,” it is possible to deﬁne a counterpart to _.oclIsNew() called _.oclIsDeleted() which asks if an object id (represented by an object representation) is contained in the pre-state, but not the post-state. OCL does not guarantee that an operation only modiﬁes the path-expressions mentioned in the postcondition, i. e., it allows arbitrary relations from pre-states to post-states. This framing problem is well-known (one of the suggested solutions is [13]). We deﬁne ( S : Set ( OclAny )) - > modifiedOnly (): Boolean

where S is a set of object representations, encoding a set of oid’s. The semantics of this operator is deﬁned such that for any object whose oid is not represented in S and that is deﬁned in pre and post state, the corresponding object representation will not change in the state transition: ⊥ if X = ⊥ IX->modifiedOnly()(σ, σ ) ≡ ∀ i ∈ M. σ i = σ i otherwise . where X = IX(σ, σ ) and M = (dom σ ∩ dom σ ) − {OidOf x| x ∈ X }. Thus, if we require in a postcondition Set{}->modifiedOnly() and exclude via _.oclIsNew() and _.oclIsDeleted() the existence of new or deleted objects, the operation is a query in the sense of the OCL standard, i. e., the isQuery property is true. So, whenever we have τ X->modifiedOnly() and τ X->excludes(s.a), we can infer that τ s.a = s.a @pre (if they are valid).

Extending OCL with Null-References

5

271

Attribute Values

Depending on the speciﬁed multiplicity, the evaluation of an attribute can yield a value or a collection of values. A multiplicity deﬁnes a lower bound as well as a possibly inﬁnite upper bound on the cardinality of the attribute’s values. 5.1

Single-Valued Attributes

If the upper bound speciﬁed by the attribute’s multiplicity is one, then an evaluation of the attribute yields a single value. Thus, the evaluation result is not a collection. If the lower bound speciﬁed by the multiplicity is zero, the evaluation is not required to yield a non-null value. In this case an evaluation of the attribute can return null to indicate an absence of value. To facilitate accessing attributes with multiplicity 0..1, the OCL standard states that single values can be used as sets by calling collection operations on them. This implicit conversion of a value to a Set is not deﬁned by the standard. We argue that the resulting set cannot be constructed the same way as when evaluating a Set literal. Otherwise, null would be mapped to the singleton set containing null, but the standard demands that the resulting set is empty in this case. The conversion should instead be deﬁned as follows: context OclAny :: asSet (): T . . post : if self = null then result = Set {} . else result = Set { self } endif

5.2

Collection-Valued Attributes

If the upper bound speciﬁed by the attribute’s multiplicity is larger than one, then an evaluation of the attribute yields a collection of values. This raises the question whether null can belong to this collection. The OCL standard states that null can be owned by collections. However, if an attribute can evaluate to a collection containing null, it is not clear how multiplicity constraints should be interpreted for this attribute. The question arises whether the null element should be counted or not when determining the cardinality of the collection. Recall that null denotes the absence of value in the case of a cardinality upper bound of one, so we would assume that null is not counted. On the other hand, the operation size deﬁned for collections in OCL does count null. We propose to resolve this dilemma by regarding multiplicities as optional. This point of view complies with the UML standard, that does not require lower and upper bounds to be deﬁned for multiplicities.3 In case a multiplicity is speciﬁed for an attribute, i. e., a lower and an upper bound are provided, we require any collection the attribute evaluates to to not contain null. This allows for a straightforward interpretation of the multiplicity constraint. If bounds are not 3

We are however aware that a well-formedness rule of the UML standard does deﬁne a default bound of one in case a lower or upper bound is not speciﬁed.

272

A.D. Brucker, M.P. Krieger, and B. Wolﬀ

provided for an attribute, we consider the attribute values to not be restricted in any way. Because in particular the cardinality of the attribute’s values is not bounded, the result of an evaluation of the attribute is of collection type. As the range of values that the attribute can assume is not restricted, the attribute can evaluate to a collection containing null. The attribute can also evaluate to invalid. Allowing multiplicities to be optional in this way gives the modeler the freedom to deﬁne attributes that can assume the full ranges of values provided by their types. However, we do not permit the omission of multiplicities for association ends, since the values of association ends are not only restricted by multiplicities, but also by other constraints enforcing the semantics of associations. Hence, the values of association ends cannot be completely unrestricted. 5.3

The Precise Meaning of Multiplicity Constraints

We are now ready to deﬁne the meaning of multiplicity constraints by giving equivalent invariants written in OCL. Let a be an attribute of a class C with a multiplicity specifying a lower bound m and an upper bound n. Then we can deﬁne the multiplicity constraint on the values of attribute a to be equivalent to the following invariants written in OCL: context C inv lowerBound : a - > size () >= m inv upperBound : a - > size () <= n inv notNull : not a - > includes ( null )

If the upper bound n is inﬁnite, the second invariant is omitted. For the deﬁnition of these invariants we are making use of the conversion of single values to sets described in Section 5.1. If n ≤ 1, the attribute a evaluates to a single value, which is then converted to a Set on which the size operation is called. If a value of the attribute a includes a reference to a non-existent object, the attribute call evaluates to invalid. As a result, the entire expressions evaluate to invalid, and the invariants are not satisﬁed. Thus, references to non-existent objects are ruled out by these invariants. We believe that this result is appropriate, since we argue that the presence of such references in a system state is usually not intended and likely to be the result of an error. If the modeler wishes to allow references to non-existent objects, she can make use of the possibility described above to omit the multiplicity.

6

Example: Red-Black Trees

We give a small example to demonstrate how the semantics we presented for undeﬁned values facilitates speciﬁcation. Figure 1 and Listing 1.1 describe a class for representing red-black trees. A red-black tree is a binary tree that satisﬁes an additional balancing invariant to ensure fast lookups. Each node is associated with a color (i. e., red or black) to allow for balancing. Every instance of the tree class represents a red-black tree. The empty tree is represented by null. A tree object is connected to its left and right subtrees via associations. The data is stored in the attribute key and the node color in the attribute color.

Extending OCL with Null-References

273

inv wf : not left . o c l I s I n v a l i d() and not right . o c l I s I n v a l i d() . inv redinv : color implies (( left = null or not left . color ) . and ( right = null or not right . color )) . inv ordinv : ( left = null or left . max () < key ) and . ( right = null or right . min () > key ) . inv balinv : b l a c k _ d e p t h( left ) = b l a c k _ d e p t h( right ) context RBT :: min (): Integer . post : if left =null then key else left . max () endif context RBT :: max (): Integer . post : if right =null then key else right . max () endif context RBT :: b l a c k _ d e p t h( tree : RBT ): Integer . post : ( tree = null and result 0) or ( tree . left . color and result b l a c k _ d e p t h( tree . left )) or ( not tree . left . color and result b l a c k _ d e p t h( tree . left ) + 1) context RBT :: isMember ( tree : RBT , a : Integer ): Boolean . post : result ( tree <> null and ( a = tree . key or isMember ( tree . left , a ) or isMember ( tree . right , a ))) context RBT :: subtrees (): Set ( RBT ) post : result left - > collect ( subtrees ()) -> union ( right - > collect ( subtrees ())) - > asSet () context RBT :: insert ( k : Integer ): post : subtrees () - > m o d i f i e d O n l y() and . subtrees (). key - > asSet () = s u b t r e e s @ p r e (). key - > asSet () - > i n c l u d i n g( k )

Listing 1.1. OCL speciﬁcation of red-black trees

The availability of the null value for representing the empty tree clearly simpliﬁes the speciﬁcation. One 0..1 might object here that one left could alternatively introduce a subclass EmptyTree inFig. 1. A class representing red-black trees heriting from RBT; however, this implies that there are EmptyTree-objects which have to be allocated and deallocated resulting in a diﬀerent memory behavior. In contrast, representing empty trees by null allows for specifying tree operations as they are commonly realized in Java or C++, i. e. our extensions pave the way for design level contracts in OCL. The only remaining alternative would be to represent the empty tree by the other undeﬁned value invalid. However, it is easy to see that this choice would obscure the speciﬁcation substantially. Recall that every operation call with an invalid argument evaluates to invalid, so the tree operations could not be called for the empty tree. Instead, the case of an empty tree would always have to be considered additionally. In the postcondition of the operation isMember, for example, the two recursive calls to isMember would require two tests for the empty tree, which would increase the size of the postcondition considerably. 0..*

RBT key:Integer[1] 0..* color:Boolean[1] min():Integer[1] max():Integer[1] black_depth(tree:RBT[0..1]):Integer[1] isMember(tree:RBT[0..1], a:Integer[1]):Boolean[1] 0..1 right subtrees():Set(RBT) insert(k:Integer[1]):OclVoid[0..1]

274

A.D. Brucker, M.P. Krieger, and B. Wolﬀ

The postcondition of insert uses _->modifiedOnly() (see Section 4) for stating that the only objects the operation may modify are the subtrees of the tree that the operation is called for. Without this constraint it would not be guaranteed that the operation does not modify other unrelated trees or even other objects of a completely diﬀerent type. Thus, _->modifiedOnly() allows us to express properties that are essential for the completeness of the speciﬁcation. Another advantage of our semantics is that references to non-existent objects can easily be ruled out a priori by the invariant wf.4 Hence, it is guaranteed that every non-null tree object encountered during a search is a valid subtree and not a dangling reference. This property is essential for the speciﬁcation correctness.

7

Discussion

We have presented a formal semantics for OCL 2.1 as an increment to the machine-checked HOL-OCL semantics presented in textbook format. The achievement is a proposal how to handle null-elements in the speciﬁcation language which result from the current attempt to align the UML infrastructure [18] with the OCL standard; an attempt that has great impact on both the semantics of UML and, to an even larger extent, OCL. Inconsistencies on the current standardization documents as result of an ad-hoc integration have been identiﬁed as a major obstacle in OCL tool development. We discussed the consequences of the integrated semantics by presenting the derived rules, their implications for multiplicities, and their pragmatics in a non-trivial example, which shows how null elements can help to write concise, natural, design-level contracts for object-oriented code in a programming like style. Adding a basic mechanism to express framing conditions gives the resulting language a similar expressive power as, for example, JML or Spec#. 7.1

Related Work

While null elements are a common concept, e. g., in programming languages or database design, there are, to our knowledge, no proposals at all for a formal semantics of null elements in the context of OCL. Albeit, there are object-oriented speciﬁcation languages that support null elements, namely JML [14] or Spec# [2]. Notably, both languages limit null elements to class types and provide a type system supporting non-null types. In the case of JML, the non-null types are even chosen as the default types [7]. Supporting non-null types simpliﬁes the analysis of speciﬁcations drastically, as many cases resulting in potential invalid states (e. g., de-referencing a null) are already ruled out by the type system. Our concept for modeling frame properties is essentially identical (but simpler) to [13], where query-methods were required to produce no observable change of the state (i. e., internally, some objects may have been created, but must be inaccessible at the end; an idea motivated by the presence of a garbage collector). 4

In fact, the invariant wf is redundant since it is implied by the multiplicity constraints (see Section 5). The multiplicity constraints of the attributes key and color ensure that these attributes are neither null nor invalid.

Extending OCL with Null-References

7.2

275

Future Work

There are numerous other concepts in the current OCL deﬁnition that deserve formal analysis; for example, the precise notion of signals, method overriding, overload-resolution, recursive deﬁnitions, and the precise form of interaction between class models, state machines and sequence charts. However, from the narrower perspective of this work on integrating null elements, adding non-null types and a non-null type inference to OCL (similar to [9,10]) seems to be the most rewarding target.

References 1. Andrews, P.B.: Introduction to Mathematical Logic and Type Theory: To Truth through Proof, 2nd edn. Kluwer Academic Publishers, Dordrecht (2002) 2. Barnett, M., Leino, K.R.M., Schulte, W.: The Spec# programming system: An overview. In: Barthe, G., Burdy, L., Huisman, M., Lanet, J.-L., Muntean, T. (eds.) CASSIS 2004. LNCS, vol. 3362, pp. 49–69. Springer, Heidelberg (2005) 3. Brucker, A.D., Doser, J., Wolﬀ, B.: An MDA framework supporting OCL. Electronic Communications of the EASST 5 (2006) 4. Brucker, A.D., Wolﬀ, B.: The HOL-OCL book. Tech. Rep. 525, ETH Zurich (2006) 5. Brucker, A.D., Wolﬀ, B.: An extensible encoding of object-oriented data models in HOL. Journal of Automated Reasoning 41, 219–249 (2008) 6. Brucker, A.D., Wolﬀ, B.: Semantics, calculi, and analysis for object-oriented speciﬁcations. Acta Informatica 46(4), 255–284 (2009) 7. Chalin, P., Rioux, F.: Non-null references by default in the Java modeling language. In: SAVCBS 2005: Proceedings of the 2005 conference on Speciﬁcation and veriﬁcation of component-based systems, p. 9. ACM Press, New York (2005) 8. Church, A.: A formulation of the simple theory of types. Journal of Symbolic Logic 5(2), 56–68 (1940) 9. Ekman, T., Hedin, G.: Pluggable checking and inferencing of nonnull types for Java. Journal of Object Technology 6(9), 455–475 (2007) 10. Fähndrich, M., Leino, K.R.M.: Declaring and checking non-null types in an objectoriented language. In: OOPSLA, pp. 302–312. ACM Press, New York (2003) 11. Gogolla, M., Kuhlmann, M., Büttner, F.: A benchmark for OCL engine accuracy, determinateness, and eﬃciency. In: Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., Völter, M. (eds.) MODELS 2008. LNCS, vol. 5301, pp. 446–459. Springer, Heidelberg (2008) 12. Gordon, M.J.C., Melham, T.F.: Introduction to HOL: a theorem proving environment for higher order logic. Cambridge University Press, Cambridge (1993) 13. Kosiuczenko, P.: Speciﬁcation of invariability in OCL. In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 676–691. Springer, Heidelberg (2006) 14. Leavens, G.T., Poll, E., Clifton, C., Cheon, Y., Ruby, C., Cok, D.R., Müller, P., Kiniry, J., Chalin, P.: JML reference manual, revision 1.2 (2007) 15. Nipkow, T., Paulson, L.C., Wenzel, M.: Isabelle’s logic: HOL (2009) 16. UML 2.0 OCL speciﬁcation (2003). Available as OMG document ptc/03-10-14 17. UML 2.0 OCL speciﬁcation (2006). Available as OMG document formal/06-05-01 18. UML 2.2 infrastructure (2009). Available as OMG document formal/2009-02-04 19. Richters, M.: A precise approach to validating UML models and OCL constraints. Ph.D. thesis, Universität Bremen, Logos Verlag, BISS Monographs, No. 14 (2002)

On Better Understanding OCL Collections or An OCL Ordered Set Is Not an OCL Set Fabian B¨ uttner, Martin Gogolla, Lars Hamann, Mirco Kuhlmann, and Arne Lindow University of Bremen Computer Science Department Database Systems Group D-28334 Bremen, Germany

Abstract. Modeling languages like UML or EMF support textual constraints written in OCL. OCL allows the developer to use various collection kinds for objects and values. OCL 1.4 knows sequences, sets, and bags, while OCL 2.0 adds ordered sets. We argue that this addition in the OCL standard was not carried out in a careful way and worsened conceptional problems that were already present previously. We discuss a new way of establishing the connection between the various collection kinds on the basis of explicitly highlighting and characterizing fundamental collection properties.

1

Introduction

During the last years, the Object Constraint Language (OCL) [OMG06, WK03] became a central ingredient in modeling and transformation languages like UML [OMG04] or EMF [BSM+ 03]. Thus, approaches for model-driven engineering rely on it. OCL is supported by many commercial and open source tools from the OMG and Eclipse sphere. Thus an unambiguous and understandable deﬁnition of language concepts is indispensable. OCL has been developed over the years and is described in a handful of OMG standards with diﬀerent degrees of amount of care devoted to particular details. Furthermore, we would call the style of deﬁnitions used in the OCL standards mostly “operation oriented” with emphasis on pre- and postconditions which is in contrast to a style which could be coined as “property oriented” with emphasis on invariants. In particular, the OCL collections are nearly completely deﬁned in formal terms by characterizing the behavior of single operations. However, class-scope properties of collections relating diﬀerent operations are stated, if at all, only in an informal manner. This paper concentrates on formal class-scope properties of OCL collections and puts forward a new way of establishing the connection between the various collection kinds on the basis of explicitly highlighting and characterizing fundamental collection properties with invariants. These properties which are expressed as equations could be used, for example, S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 276–290, 2010. c Springer-Verlag Berlin Heidelberg 2010

On Better Understanding OCL Collections

277

in OCL tools for pointing the developer to semantically equivalent OCL expressions. Similar collection kinds as present in OCL have been studied in connection with complexity [TS91], functional [HB94] and logic programming [Won95] as well as in the context of conceptual database models [HL07]. The rest of the paper is structured as follows. Section 2 points to various deﬁciencies in the OCL standard collection deﬁnitions. Sections 3 analyses the properties of the four OCL collection kinds bag, set, sequence, and ordered set. Section 4 looks at OCL collections from the point of view of algebraic speciﬁcations. Section 5 discusses a new type hierarchy for collections including invariants which characterize central properties. The paper ends with concluding remarks.

2

Deficiencies in OCL Collection Definitions

Let us ﬁrst explain diﬃculties which arise with the latest OCL standard. Basic properties of ordered sets are unclear when one considers only the statements made in the OCL 2.0 standard [OMG06]. For example, the question how many ordered sets exist which contain three distinct elements (x
Fig. 1. Type Hierarchy and Incomplete Value Hierarchy for OCL 2.0 Collections

– The operations equality =, including, excluding, and the collection conversions asBag, asSet, and asSequence are not deﬁned on ordered sets. – Some operation deﬁnitions on ordered sets are incorrect. For example, the description of append with postconditions is erroneous, because it does

278

F. B¨ uttner et al.

not handle the most interesting case when the parameter object which is to be appended is already present in the collection. The description of OrderedSet::append is textually identical to (and probably has, without any modiﬁcation, been copied from) Sequence::append. – As shown in Fig. 1 which is condensed from [OMG06, pages 34 and 98], ordered sets are not considered in the collection value hierarchy, although are they present in the type hierarchy. – Ordered sets are not mentioned when collection operation like select, exists or collect are deﬁned on the basis of iterate. Thus these operations are formally not deﬁned on ordered sets. Furthermore, there were already some deﬁciencies in the deﬁnition of OCL 1.4 collections [OMG03]. – OCL 1.4 collections are not explicitly characterized by general properties, for example by invariants, but are deﬁned by the behavior of single operations like equality = or the constructor-like operations including. The interplay between the operations is not discussed. – A conceptual question which is not answered in the OCL 1.4 standard is the question why a set cannot be regarded automatically as a bag whose elements occur exactly once. A similar question comes up in connection with the relationship between ordered sets and sequences. – Furthermore the properties of conversion operations are only handled in a sketchy way: On the one hand there are explanations concerning the question which conversion operations are completely determinated by their arguments and which conversion operations are only incompletely determinated by their arguments and must therefore take implementation dependent choices; but on the other hand not all relevant important properties of these conversion operations are explicitly discussed in the OCL 1.4 standard.

3 3.1

Collection and Conversion Properties Collection Properties

As a basis for discussion, we propose in the following two fundamental properties which an OCL collection kind might satisfy or might not satisfy. Both properties are formulated in an OCL-like style as invariants. However, as will be explained further down, both formulations are not valid current OCL expressions. – Property insertionOrderIndependence: The insertion order of elements into the collection does not matter. context Collection(T) inv insertionOrderIndependence: T.allInstances()->forAll(x,y:T| self->including(x)->including(y) = self->including(y)->including(x))

On Better Understanding OCL Collections

279

– Property singleElementOccurrence: An element can occur at most once in the collection or, in other words, duplicates are not allowed. context Collection(T) inv singleElementOccurrence: self->forAll(x:T|self->count(x)=1)

In Fig. 2 we identify the four OCL collection kinds, the above two properties, and twelve arrows which represent the twelve collection conversions operations. For example, Bag(T)::asSequence():Sequence(T) is represented by the topmost dashed arrow. Each conversion operation is classiﬁed into one of three categories: (1) completely determinated and injective function, (2) incompletely determinated function, i.e., OCL engine implementation-dependent function, and (3) completely determinated and non-injective function.

Fig. 2. Classiﬁed Conversions between OCL Collections

Let us now discuss the relationship between the two properties and the OCL collections kinds. The two basic properties insertionOrderIndependence and singleElementOccurrence are chosen in such a way that they orthogonally partition the OCL collection kinds: insertionOrderIndependence is valid on bags and sets, whereas it is invalid on sequences and ordered sets; singleElementOccurrence is valid on sets and ordered sets, whereas it is invalid on bags and sequences. For sets both properties have to hold, for bags and ordered sets exactly one respective property is valid, and sequences do not have to obey any of these two properties.

280

F. B¨ uttner et al.

These two central properties may be regarded as the formalization of the informal description given in the OCL standard [OMG06, page 145]: Set: The Set is the mathematical set. It contains elements without duplicates ... OrderedSet: The OrderedSet is a Set, the elements of which are ordered. It contains no duplicates ... Bag: A bag is a collection with duplicates allowed. That is, one object can be an element of a bag many times. There is no ordering deﬁned on the elements in a bag ... Sequence: A sequence is a collection where the elements are ordered. An element may be part of a sequence more than once. Note that the wording used for the description of ordered sets “The OrderedSet is a Set” may suggest that ordered sets are subsets of sets. Our argumentation below does not follow this view. The above formulations are not valid current OCL expressions because (1) a type parameter T is used for the context class and (2) allInstances is applied to the type parameter T which is generally not allowed, if T is a basic data type or T is again a collection type. A forbidden example situation for the ﬁrst case is Collection(Integer), and a forbidden example for the second case is Collection(Sequence(Person)). Please note that Fig. 2 is incomplete because a conversion on each collection kind to itself is missing. According to the OCL standard, for example, asBag() can be applied on Bag(T). Analogously, the other three collection kinds additionally possess a loop arrow from the respective type to the type itself. We have not shown these conversions in order to keep the ﬁgure simple. Finally, we state some observations which apply only to ordered sets. – OrderedSet(T) is the only collection kind where all three conversions from the other collection kinds are implementation-dependent. Therefore, a conversion from any other collection to an ordered set must make an implementation-dependent choice. – An ordered set (in mathematics or theoretical computer science) is usually diﬀerent from the OCL ordered set. There, an ordered set denotes a set together with a partial order on the set, i.e., a reﬂexive, antisymmetric and transitive relationship. The OCL ordered sets do not rely on such a relationship. 3.2

Completely Determinated, Injective Conversions

In Fig. 2 we have shown the only two injective conversions with thick arrows: Set(T)::asBag():Bag(T) and OrderedSet(T)::asSequence():Sequence(T). The property of being injective comes from the fact that (1) a set can be interpreted in a unique way as a bag where each element occurs once and (2) an ordered set can be interpreted in a unique way as a sequence where the order of the elements in both collections coincides.

On Better Understanding OCL Collections

281

This view on OrderedSet(T)::asSequence():Sequence(T) contributes to the answer of the question raised earlier: How many ordered sets exist which exactly contain three diﬀerent elements, for example, the integers 7,8,9? All six permutations can be considered as ordered sets without problems. Thus OrderedSet{8,7,9} is a valid ordered set although it is not a sorted set. 3.3

Incompletely Determinated Conversions

In Fig. 3 the ﬁve incompletely determinated conversions are pictured with dashed arrows. By using the notion “incompletely determinated” we refer to the fact that these conversions are not determined in a canonical way and that in these conversions implementation-dependent choices have to be made. An example argument for this indeterminateness is shown in the ﬁgure for each conversion in grey boxes. For example, Bag(T)::asSequence():Sequence(T) is incompletely determinated, because the bag Bag{x,y} can be mapped to Sequence{x,y} or Sequence{y,x}; Sequence(T)::asOrderedSet():OrderedSet(T) is incompletely determinated, because the sequence Sequence{x,y,x} can be mapped to OrderedSet{x,y} or OrderedSet{y,x}. These conversions are not completely determinated, because one order has to be ﬁxed which is not uniquely present in the argument collection.

Fig. 3. Incompletely Determinated Conversions between OCL Collections

282

3.4

F. B¨ uttner et al.

Completely Determinated, Non-injective Conversions

In Fig. 4 the ﬁve completely determinated conversions which are not injective are pictured with solid arrows. One example argument for being not injective is indicated in the ﬁgure in grey boxes: For example, Bag(T)::asSet():Set(T) is not injective, because the bags Bag{x,x,y} and Bag{x,y,y} are both mapped to Set{x,y}, and the conversion is completely determinated because when going from the bag to the set one simple ignores the multiple occurrences of elements. Analogous arguments for being non-injective and for determinateness hold for the other conversions.

Fig. 4. Completely Determinated Conversions between OCL Collections

Please note that the incompletely determinated, dashed conversions in Fig. 3 basically go from the left to the right, and the completely determinated, solid conversions in Fig. 4 go from the right to the left. This is due to the fact that the left collection kinds Bag(T) and Set(T) obey the property insertionOrderIndependence while this property is in general not valid in the right collection kinds Sequence(T) and OrderedSet(T).

4

Excursus: Collections as Algebraic Specifications

We now discuss algebraic speciﬁcations [EM85, EGL89, Wir90] for OCL collections as shown in Fig. 5. Viewing these collections from a diﬀerent ﬁeld helps

On Better Understanding OCL Collections

283

in understanding them because the view on collections is diﬀerent in that it emphasizes diﬀerent aspects. In particular one can nicely express the interplay between operations. Equational algebraic speciﬁcations have the advantage of (1) showing central and characteristic properties and (2) being able to automatically construct an interpretation for the respective structure, namely the so-called quotient term algebra, which is an intial algebra. – There is a close relationship between our two central OCL requirements and the equations: The invariant insertionOrderIndependence corresponds to the equation commutativity, and the invariant singleElementOccurrence has the equations (deﬁned in Fig. 5) absorption and absorptionIfPresent as its counterparts. – One can view the speciﬁcations for sets, bags, and sequences as a hierarchy of requirements: There are two equations for sets, one of these equations is also used for bags, and there is no equation for sequences. Thus the set is more restricted than the bag which is more restricted than the sequence. Sequences are generated freely, i.e., they are described by a pure term algebra without any factorization on terms. – We have given speciﬁcations not for general collections with type parameters, but for more concrete collections which roughly correspond to (speaking in OCL notions) Sequence(Integer), Bag(Integer), Set(Integer) and OrderedSet(Integer), respectively. The general collections like Bag(T) could be deﬁned in an analogous way. In particular, because so-called parametrized algebraic speciﬁcations are a well-studied concept, and type parameters do not present diﬃculties (in contrast to current OCL). – The type orderedSet needs an auxiliary operation includes and conditional equations. Otherwise it would not be speciﬁable. Thus the type orderedSet belongs to a diﬀerent speciﬁcation class than the three other collections which are speciﬁable by pure equations and without auxiliary operations. The type orderedSet is also the only one which needs the equality on its elements whereas the other collections do not require this. – Interestingly, in both speciﬁcation formalisms, in OCL and with algebraic speciﬁcation, the ordered sets play a special role and special means must be taken to describe it. – Finally, when we want to play around with the algebraic speciﬁcations and study further structures, we discover that we could also build a collection kind which considers the equation from the bag speciﬁcation for the absorption property (including(including(S,N),N) = including(S,N)) as its single equation. This would construct a structure that could be called “repetition free sequences”, say RepFreeSequence. In that structure, for example, the statements RepFreeSequence{22, 11, 11, 22, 33, 33} = RepFreeSequence{22, 11, 22, 33} and RepFreeSequence{22, 11, 22, 33} <> RepFreeSequence{22, 11, 33} would be true. Such a collection kind is not (and from our point of view should not be) present in OCL.

284

F. B¨ uttner et al.

srts bool, nat --------------------------------------------------------opns false, true : -> bool or : bool bool -> bool zero : -> nat succ : nat -> nat eq : nat nat -> bool eqns or(B,true) = true or(B,false) = B eq(zero,zero) = true eq(zero,succ(N)) = false eq(succ(N),zero) = false eq(succ(N),succ(M)) = eq(N,M) srts sequence ---------------------------------------------------------opns emptySequence : -> sequence including : sequence nat -> sequence eqns -- no equations srts bag --------------------------------------------------------------opns emptyBag : -> bag including : bag nat -> bag eqns including(including(B,N),M) = including(including(B,M),N) -- commutativity srts set --------------------------------------------------------------opns emptySet : -> set including : set nat -> set eqns including(including(S,N),M) = including(including(S,M),N) -- commutativity including(including(S,N),N) = including(S,N) -- absorption srts orderedSet ------------------------------------------------------opns emptyOrderedSet : -> orderedSet including : orderedSet nat -> orderedSet includes : orderedSet nat -> bool eqns includes(emptyOrderedSet,N) = false includes(including(O,N),M) = or(eq(N,M),includes(O,M)) includes(O,N)=true => including(O,N) = O -- absorptionIfPresent Fig. 5. Algebraic Speciﬁcation of Collections of Natural Numbers

On Better Understanding OCL Collections

285

– For non-specialists in algebraic speciﬁcations we emphasize that we have used above equations and not rewrite rules: Equations are applicable in both directions (from left to right and from right to left) whereas rewrite rules usually are applied in one direction only. For example, the semantics of speciﬁcation remains the same if we write eq(N,M) = eq(succ(N),succ(M)) instead of the equation stated above.

5 5.1

Alternative Collection Type Hierarchy and Invariants Alternative Collection Type Hierarchy (Discussion Proposal)

Figure 6 shows our discussion proposal for a possible type hierarchy of OCL collections. Because there are already two conversion operations present in current OCL, which are also canonical, natural injections, it may seem natural to utilize the UML generalization concept in order to express this relationship. Thus Set(T) becomes a subtype of Bag(T) and OrderedSet(T) becomes a subtype of Sequence(T). Please note, although the wording might suggest something diﬀerent, OrderedSet(T) is not a subtype of Set(T).

Fig. 6. Alternative OCL Collection Type Hierarchy (Discussion Proposal)

Viewing at the proposal so far, we can observe that having “natural injections” sounds like a nice criterion, but this is not the only criterion for establishing a generalization hierarchy. Another important aspect is the inheritance of properties (e.g., invariants) from a supertype to a subtype. In our case, the upper collection kinds Bag(T) and Sequence(T) fullﬁll, for example, the property COLLECTION->including(x)->size() = COLLECTION->size()+1. But this property should not be valid in the lower collection kinds. Therefore it seems advisable for us, to keep the standard collection hierarchy where the specialized collection kinds Bag(T), Set(T), Sequence(T) and OrderedSet(T) are subtypes of Collection(T).

286

5.2

F. B¨ uttner et al.

Collection Invariants

In any case, we can extend the collection type hierarchy with class invariants characterizing the diﬀerent collections. We can connect our central requirements for collections with the respective collection kinds. context Bag(T) inv insertionOrderIndependence: T.allInstances()->forAll(x,y:T| self->including(x)->including(y)=self->including(y)->including(x)) context Set(T) inv insertionOrderIndependence: T.allInstances()->forAll(x,y:T| self->including(x)->including(y)=self->including(y)->including(x)) context Set(T) inv singleElementOccurrence: self->forAll(x:T|self->count(x)=1) context OrderedSet(T) inv singleElementOccurrence: self->forAll(x:T|self->count(x)=1)

After having ﬁxed the central properties of collections we can now explain our view on the diﬀerence between sets and ordered sets. Sets must obey the requirement insertionOrderIndependence, while ordered sets should not follow this constraint. The usual view on generalization is that any property of a more general class is inherited to a more special class. Thus if one would make OrderedSet(T) a subclass of Set(T), ordered sets have to be “insertion order independent” which would be a contradiction to their desired property of not obeying that constraint. In our view, a subclass should not take away a property which is present in a more general class. Furthermore, a subclass element should correspond in a unique way to a superclass element, which would not be the case here, because OrderedSet(T)::asSet():Set(T) is not injective. Our statement “An OCL Ordered Set is not an OCL Set” should be understood in this context. As an alternative to the notion “Ordered Set” the unhandy notion “Single Occurrence Sequence” (for which an abbreviation like “Sos” or “Soq” could be used) may be more appropriate. The handling of the type parameter T remains to be studied for future work. However, in order to avoid expressions like T.allInstances() one could (at least in the above example) use the context variable self. The invariant would then be read as indicated below. This opens the possibility of giving at least a preprocessor semantics (textual replacement semantics) to type parameters where each collection type occurrence must be accompanied by respective constraints where the type parameter is replaced by an actual value. context Bag(T) inv insertionOrderIndependence_allInstancesReplaced: self->forAll(x,y:T| self->including(x)->including(y)=self->including(y)->including(x))

On Better Understanding OCL Collections

287

Employing the deﬁned type hierarchy it is also possible to state basic invariants about fundamental collection operations like including, excluding, includes and excludes. In particular, such invariants can make statements about the relationship between these operations. context Collection(T) inv includingImpliesIncludes: T.allInstances()->forAll(x:T| self->including(x)->includes(x)) context Collection(T) inv excludingImpliesExcludes: T.allInstances()->forAll(x:T| self->excluding(x)->excludes(x)) context Collection(T) inv includesXorExcludes: T.allInstances()->forAll(x:T| self->includes(x) xor self->excludes(x))

Another interesting area is to focus only on the connection between including and excluding. Interestingly, an invariant which directly requires something like COLLECTION->including(x)->excluding(x) = COLLECTION does neither hold for bags, sets, sequences nor ordered sets. However, a variant realizing the underlying idea is valid in all respective collections. This invariant must take into account the particular behavior of the constructor including and the operation excluding which eliminates all occurrences of its argument provided as a parameter. context Collection(T) inv includingExcluding: T.allInstances()->forAll(x:T| self->including(x)->excluding(x)=self->excluding(x))

Furthermore determinateness properties of conversion operations can be expressed in this style with invariants as well. For example, the direct conversion from sequences to sets should be identical to a conversion where a conversion to bags is added or a conversion to ordered sets is added (or both, in any order). This is formally expressed in the invariants below and pictured in Fig. 7. We formulate these invariants for sequences, whereas analogous statements also hold for ordered sets. context Sequence(T) inv asBagDoesNotChangeAsSet: self->asSet() = self->asBag()->asSet() context Sequence(T) inv asOrderedSetDoesNotChangeAsSet: self->asSet() = self->asOrderedSet()->asSet() context Sequence(T) inv asBagAsOrderedSetDoesNotChangeAsSet: self->asSet() = self->asBag()->asOrderedSet()->asSet() context Sequence(T) inv asOrderedSetAsBagDoesNotChangeAsSet: self->asSet() = self->asOrderedSet()->asBag()->asSet()

288

F. B¨ uttner et al.

Fig. 7. Determinateness for Sequence(T)::asSet():Set(T)

A fundamental property of conversion operations is the requirement that the membership in the converted collection and the result collection coincides. We formulate this requirement for asBag. Analogous requirements must be made for asSet, asSequence and asOrderedSet. context Collection(T) inv asBagPreservesMembership: T.allInstances()->forAll(x:T| self->includes(x) = self->asBag()->includes(x) and self->excludes(x) = self->asBag()->excludes(x))

All in all, we believe that formulating constraints in a more property oriented style with invariants is an addition to the more operation oriented style with pre- and postconditions in the OCL standards. With such invariants one can directly express properties which have to be deduced from pre- and postconditions in the operation oriented style. At least such invariants can help to make the intention of the standard more explicit and can be employed for the description of properties within OCL libraries [BD07, Opo09] or as test cases in OCL benchmarks [GKB08].

6

Conclusion

This paper has presented a concept for dealing with OCL ordered sets which is implemented as proposed here in USE [GBR07]. For this implementation we

On Better Understanding OCL Collections

289

had to make several design decisions, for example, concerning the conversion operations or concerning the operation append on ordered sets which is in our implementation without eﬀect if the parameter element is already present. We have discussed an alternative type hierarchy for OCL collections and several invariants which determine the interplay between collection operations. Future research will cover a number of points to work on. An open question is how type parameters have to be dealt with. The preprocessor semantics mentioned above should be worked out in detail. Furthermore, additional details concerning the interplay between collection operations are probably missing. We understand our paper as a discussion oﬀer to the OCL community in order to make a better proposal for the standard OCL library.

Acknowledgements Thanks to the referees for the constructive comments and to the workshop participants, in particular Birgit Demuth and Markus Stumptner, for asking good questions.

References [BD07]

Br¨ auer, M., Demuth, B.: Model-Level Integration of the OCL Standard Library Using a Pivot Model with Generics Support. In: Giese, H. (ed.) MODELS 2008. LNCS, vol. 5002, pp. 182–193. Springer, Heidelberg (2008) [BSM+ 03] Budinsky, F., Steinberg, D., Merks, E., Ellersick, R., Grose, T.: Eclipse Modeling Framework. Addison Wesley Professional, Reading (2003) [EGL89] Ehrich, H.-D., Gogolla, M., Lipeck, U.W.: Algebraische Speziﬁkation Abstrakter Datentypen - Eine Einf¨ uhrung in die Theorie. Leitf¨ aden und Monographien der Informatik. Teubner, Stuttgart (1989) [EM85] Ehrig, H., Mahr, B.: Fundamentals of Algebraic Speciﬁcation. Springer, Berlin (1985) [GBR07] Gogolla, M., B¨ uttner, F., Richters, M.: USE: A UML-Based Speciﬁcation Environment for Validating UML and OCL. Science of Computer Programming 69, 27–34 (2007) [GKB08] Gogolla, M., Kuhlmann, M., B¨ uttner, F.: A Benchmark for OCL Engine Accuracy, Determinateness, and Eﬃciency. In: Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., V¨ olter, M. (eds.) MODELS 2008. LNCS, vol. 5301, pp. 446–459. Springer, Heidelberg (2008) [HB94] Hoogendijk, P.F., Backhouse, R.C.: Relational Programming Laws in the Tree, List, Bag, Set Hierarchy. Science of Computer Programming 22(1-2), 67–105 (1994) [HL07] Hartmann, S., Link, S.: Collection Type Constructors in EntityRelationship Modeling. In: Parent, C., Schewe, K.-D., Storey, V.C., Thalheim, B. (eds.) ER 2007. LNCS, vol. 4801, pp. 307–322. Springer, Heidelberg (2007) [OMG03] OMG (ed.): Object Constraint Language, Version 1.4. OMG, 2003. OMG Document, www.omg.org

290

F. B¨ uttner et al.

[OMG04] [OMG06] [Opo09]

[TS91]

[Wir90] [WK03] [Won95]

OMG (ed.): OMG Uniﬁed Modeling Language Speciﬁcation, Version 2.0. OMG. OMG Document (2004), www.omg.org OMG (ed.): Object Constraint Language, Version 2.0. OMG. OMG Document formal/06-05-01 (2006), www.omg.org Opoka, J.: OCLLib, OCLUnit, OCLDoc: Pragmatic Extensions of the Object Constraint Language. In: Sch¨ urr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 665–669. Springer, Heidelberg (2009) Tannen, V., Subrahmanyam, R.: Logical and Computational Aspects of Programming with Sets/Bags/Lists. In: Leach Albert, J., Monien, B., Rodr´ıguez-Artalejo, M. (eds.) ICALP 1991. LNCS, vol. 510, pp. 60–75. Springer, Heidelberg (1991) Wirsing, M.: Algebraic speciﬁcation. In: van Leeuwen, J. (ed.) Handbook of Theoretical Computer Science. North-Holland, Amsterdam (1990) Warmer, J., Kleppe, A.: The Object Constraint Language: Precise Modeling with UML, 2nd edn. Addison-Wesley, Reading (2003) Wong, L.: Polymorphic Queries Across Sets, Bags, and Lists. ACM SIGPLAN Notices 30(4), 39–44 (1995)

The 2nd International Workshop on Non-functional System Properties in Domain Specific Modeling Languages (NFPinDSML2009) Marko Bošković1, Dragan Gašević1, Claus Pahl2, and Bernhard Schätz3 1

School of Computing and Information Systems, Athabasca University, Canada [email protected], [email protected] 2 School of Computing, Dublin City University, Ireland [email protected] 3 Institut für Informatik, Technische Universität München, Germany [email protected]

Abstract. Domain Specific Modeling Languages (DSMLs) are becoming a common-place for engineering software systems of a particular domain. Currently, the study of DSMLs is mostly dedicated to engineering languages for specification of functional properties of systems. Until now, the study of engineering DSMLs has mostly been dedicated to specifying functional properties of domain specific systems. Besides functional properties, so called nonfunctional properties (NFP) such as safety, reliability, timeliness and so on, have been recognized as important as functional ones. This workshop discusses integration of NFP estimation and evaluation to Model Driven Engineering with DSMLs.

1 Introduction Meeting non-functional requirements (NFR) in software systems engineering has generally been recognized as important as meeting functional requirements. Not meeting NFRs can make the system unusable, despite the fact that it implements all required functionalities. Model Driven Engineering (MDE) advocates extensive usage of models in software engineering. It relies on principles of abstraction and automation. Abstraction introduces modeling constructs which facilitate solving problems of a particular problem domain. These abstractions form (Domain Specific) Modeling Languages. Automation facilitates automatic generation of implementation through transformation. Currently, the research on engineering of DSMLs and non-functional properties (NFP) estimation and evaluation is in its infant phase. On-going research activities of DSMLs are mostly dedicated to engineering DSMLs for the specification of functional requirements. The importance of NFP demands research in defining common principles of engineering DSMLs and NFP analysis. In order to create a forum where researchers can exchange their results and experiences in integrating NF aspects in engineering with DSMLs, and MDE in general, we have started the NFPinDSML workshop series. The first edition of this workshop has identified several important S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 291–295, 2010. © Springer-Verlag Berlin Heidelberg 2010

292

M. Bošković et al.

research questions. From those identified questions, we have created an agenda for the future issues of this workshop. The NFPinDSML2009 discussed one of those identified questions, namely, multi-dimensional NFP analysis.

2 The Workshop Program This year’s workshop program was divided into two parts, morning and afternoon. The morning part of the workshop was dedicated to paper presentations. The afternoon session was an interactive part of the workshop consisting of one interactive panel and a discussion session. 2.1 The Morning Workshop Part Papers presented in the morning part of the workshop can be divided in two major areas: monitoring of NFR satisfaction and parallel analysis of different NFPs. Monitoring of NFP satisfaction has been discussed by two presenters. The first presenter was Antonio Vallecillo, from the University of Malaga, Spain. He held a presentation entitled, “On the specification of non-functional properties of systems by observation”. In this presentation, he introduced an approach for measuring and monitoring NFPs by using domain specific observers. Observers are pieces of software which collect system execution data and compute the value of NFP. One more approach for NFP measuring and monitoring was introduced by Anton Yrjönen, from the VTT Technical Research Centre, Finland. In his presentation entitled “Extending the NFR framework with measurable Non-Functional Requirements”, he extends so called NFR framework, a goal based framework, to provide measurable NFR specification and evaluation. The approach facilitates measurement values of NFPs at the design level, and propagates those values to the requirements level for reasoning about the satisfaction of specified requirements. The second session consisted of three presentations demonstrating and evaluating different approaches for parallel analysis of NFPs. The first two presentations were given by Luca Berardinelli, from the University of dell’Aquila, Italy. In this first presentation, entitled “UML Profiles for non-functional properties at work: analyzing reliability, availability and performance”, he demonstrated a usage of UML profiles for annotation, and parallel transformations to different formalisms used for evaluation of different NFPs. In his second presentation, named “A unified approach to model non-functional properties of mobile context-aware software”, Luca Berardinelli presented a unifying conceptual framework for modeling mobility and context awareness aspects of mobile and adaptive software systems. This approach proposes a uniform representation of software component location and hardware platform awareness, expressed through a set of attributes associated to system elements. The time variability of these attributes is modeled with stochastic state charts. The final presentation was given by Elyes Rouis, from the Supelec School in France. In his presentation, with the title “Modeling heterogeneous points of view with ModHel’X”, he demonstrated how ModHel’X, can be used for a multi-view modeling of systems from both, functional and non-functional viewpoints. ModHel’X was originally a framework for modeling heterogeneous systems.

The 2nd International Workshop on Non-functional System Properties

293

2.2 The Afternoon Workshop Part The afternoon workshop part consisted of two sessions: 1) a panel where four of highly qualified researchers presented their experiences in integration of quality assurance and modeling, and 2) an interactive discussion session. The panel gathered the following four researchers: Anirüddhā Gokhālé (Vanderbilt University, USA), Richard Page (University of York, UK), Dorina Petriu (Carleton University, Ottawa) and Steffen Zschaler (Lancaster University, UK). During their presentations each panelist described projects and NFPs they have addressed, described NFP evaluation methods, introduce domain specific languages they have used, explained interrelations between different NFPs, elaborated on benefits and shortcomings of UML and profiles in the cases where they were used, and shared with the community on lessons learned. Anirüddhā Gokhālé’s domain of research is model driven engineering of large scale real-time distributed systems (e.g., avionic computing). Systems which are his topic of research are middleware-based systems that recently tend to move to service orientation and component based abstractions. Major NFPs that he addressed were security, reliability, timeliness, and resource consumption. In designing large scale real time distributed systems, designers need support for many decisions they have to make like specifying component interfaces, composition of components, efficient resource utilization, valid configuration of different middleware configurations, and validation of meeting the requirements. In order to provide the support, his group had developed several languages mostly based on component based abstraction. The languages they had developed provided the support for composition and deployment, for middleware configuration, for specification of QoS, for reliability and security. Furthermore, for all these languages they had developed a tool support for code generation and model checking. In their focus of research was also a support for continuous evaluation during whole lifecycle. This is due to the fact that not all components would be available at the same time during the design, and the problems that arise during the integration can significantly impact the final design. From his experience in development of previously mentioned languages and systems, Anirüddhā Gokhālé emphasized the importance of separating different concerns to different languages. If all concerns were placed in one language, and its models, the final model would be hard to comprehend. Furthermore, he also pointed out the need for systematic mappings of domain space, where the functional and NFRs had been collected, and the solution space, where different implementation choices had to be made. Richard Paige comes from the area of high integrity real time embedded systems like airspace, defense systems, and engine controllers. His overall concern was the delivering of systems that satisfy certifying authority. The major NFPs of his interest were security and safety. Particularly, in safety, he has addressed NFPs like liability, availability and schedulabillity. Evaluation methods, used in his approaches were formal modeling, simulation, and model checking supplemented with manual experts’ reasoning based safety analysis. Some of languages that he has used are UML, UML Profiles, Mathlab Simulink and Stateflow and families of different domain specific languages. Semantics of these languages have been defined: some mathematically, but mostly by tools, model transformations and code generation. During his use of

294

M. Bošković et al.

UML, and UML Profiles in real, industrial projects, he noticed that models with annotations or constraints grow very large. From his experience, Richard Paige drew attention to the need of conformant standards for certification. Current standards are very generic, and can be satisfied with different techniques. This can cause problems in certification because certifying authorities will hardly accept arguments provided by the developers if applied evaluation techniques are not the ones to which the certifying authority is used to. He also emphasized that most of tools and languages did not scale up in industrial context. Therefore, there is a need for infrastructure supporting industrial languages and models. Dorina Petriu’s background is performance driven software design. In her research, she had addressed problems of annotating design models with performance information and automatically deriving software performance models such as queuing networks. Besides performance driven software engineering, recently she started analyzing interrelations between software performance and security. Languages that she had used in her research are UML and Use Case Maps. For evaluation, her group has used Layered Queuing Networks, Stochastic Petri Nets and Process Algebras. One of the major challenges in parallel analysis of security and performance is formal representation of relations between these two NFPs. This can be helpful in optimization of the design and reasoning between different alternatives. The next major problem is finding the appropriate level of knowledge a software designer must know about the performance analysis and information the design model should contain. At one hand, a developer needs to know what information to put into the model, in order to provide sufficient information for performance analysis and to know how to interpret the results of the performance analysis. On the second hand, there is a need of sheltering the designer from the complexity of performance analysis. She also noticed that different NFPs might be addressed at different levels of abstraction. For example, security is addressed at the design level, and performance is concerned with deployment. This also implies that software design processes driven by different NFPs might significantly differ. In such context it is questionable which NFP should be the leading one and which the secondary. Steffen Zschaller’s, background are NFPs in business applications. In his work, he tried to find a generic formalism for NFPs. Currently, many formalisms for describing functional and NFPs exist. In order to make appropriate decision on which component to chose, a developer would have to know all these formalisms. Zschaller had developed such formalism, and effectively built it in UML and in some textual DSLs. However, this generic language was good for the communication, but it was not sufficiently good for analysis. As one of the major research questions for the future he pointed out was finding the appropriate balance between generality of the language for NFPs communication and good analysis capability. The discussion session started with a question on whether UML profiles are the right way to go. UML profiles add some information to the model, which is of interest to an e.g. performance analyst and not software developer. The offered alternative was to model a system with respect to use. That is, that a separate modeling language should be developed for performance analysts and software designers. The problem with this alternative is keeping synchronized performance analysis and design models. The solution for the problem of synchronization might be found in traceability tools.

The 2nd International Workshop on Non-functional System Properties

295

The second question was the problem of exchange of analysis results between people with different roles in software development process and with different knowledge. For example, safety engineers often model systems in a way understandable only to them, while software developers and certifying authorities are not able to interpret these results. In some industrial cases, UML and UML Profiles helped better to communicate the results of the safety analysis to the software team, and to bring together the communities. Also, a benefit of UML profiles in this sense is provided tool support. However, the problem with UML profiles is that everybody has to learn them. Certifying authorities often know only textual and tabular documents analysis, and are not willing to learn UML Profiles. Therefore, the promising alternative might be the development of DSMLs for different communities, with transformations between them. At the present moment the development of tools for DSMLs is not as expensive as in the past. During the discussion on the exchange of analysis results between different communities, not only means of communication were touched on, but also used terminologies, which could be another cause of problems. It is often questionable whether the people correctly interpret a terminology used in the model. For this purpose, there is a need for the consensus on the terminology used in different domains. The major research question here is to find appropriate ways to semantically define used terms. Finally, it was also noticed that languages should not solve everything. For example, modeling security is questionable. Possibilities of social engineering are hard to express in models. Therefore, there is a need to explore where limitations of languages are and how/whether those limitations can be overcome with better trained people and better design processes.

3 Final Remarks and Outlook NFPinDSML2009 was the second successful edition in the series of workshops dealing with problems of integration of NFP assurance and domain specific languages. It gathered researchers discussing measuring, monitoring and multi dimensional analysis of NFPs. All presentations have been published in the CEUR workshop proceedings (http://www.ceur-ws.org/Vol-553). The workshop has been well attended, having overall more than 40 participants. The attention the workshop attracted, clearly demonstrates its need and timeliness. Additionally, the number of research questions that arose during NFPinDSML2008 and NFPinDSML2009 provided us with a set of interesting topics for the future issues. For this reason, we intend to continue the organization of this workshop to explore possibilities and limits of integration of NFP evaluation in MDE in general.

On the Specification of Non-functional Properties of Systems by Observation Javier Troya, Jos´e E. Rivera, and Antonio Vallecillo GISUM/Atenea Research Group. Universidad de M´alaga, Spain {javiertc,rivera,av}@lcc.uma.es

Abstract. Domain specific languages play a cornerstone role in Model-Driven Engineering (MDE) for representing models and metamodels. So far, most of the MDE community efforts have focused on the specification of the functional properties of systems. However, the correct and complete specification of some of their non-functional properties is critical in many important distributed application domains, such as embedded systems, multimedia applications or e-commerce services. In this paper we present an approach to specify QoS requirements, based on the observation of the system actions and of the state of its objects. We show how this approach can be used to extend languages which specify behavior in terms of rules, and how QoS characteristics can be easily expressed and reused across models. We show as well how this approach enables the specification of other important properties of systems, such as automatic reconfiguration of the system when some of the QoS properties change.

1 Introduction Domain specific languages (DSLs) play a cornerstone role in Model-Driven Engineering (MDE) for representing models and metamodels. The Software Engineering community’s efforts have been progressively evolving from the specification of the structural aspects of a system to modeling its dynamics, a current hot topic in MDE. Thus, a whole set of proposals already exist for modeling the structure and behavior of a system. Their goal is not only to generate code, but also to conduct different kinds of analysis on the system being modeled including, e.g., simulation, animation or model checking. The correct and complete specification of a system also includes other aspects. In particular, the specification and analysis of its non-functional properties, such as QoS usage and management constraints (performance, reliability, etc.), is critical in many important distributed application domains, such as embedded systems, multimedia applications or e-commerce services and applications. In order to fill this gap, in the last few years the research has faced the challenge of defining quantitative models for non-functional specification and validation from software artifacts [2]. Several methodologies have been introduced, all sharing the idea of annotating software models with data related to non functional aspects, and then translating the annotated model into a model ready to be validated [3]. However, most

This is a revised version of the paper presented at the NFPinDSML09 workshop, and published in its on-line Proceedings [1].

S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 296–309, 2010. c Springer-Verlag Berlin Heidelberg 2010

On the Specification of Non-functional Properties of Systems by Observation

297

of these proposals specify QoS characteristics and constraints using a prescriptive approach, i.e., they annotate the models with a set of requirements on the behavior of the system (response time, throughput, etc). These requirements state how the system should behave. Examples of these approaches include the majority of the UML Profiles for annotating UML models with QoS information, e.g., [4,5,6]. In this paper we present an alternative approach to specify QoS requirements, based on the observation of the system actions and of the state of its constituent objects. We show how this approach can be used to extend DSLs which specify behavior in terms of rules (that describe the evolution of the modeled artifacts along some time model), and how QoS characteristics can be easily expressed and reused across models. In particular, we focus on performance and reliability characteristics. We show as well how this approach enables the specification of other important features of systems, such as the automatic reconfiguration of the system when the value of some of the QoS properties change. Finally, the approach has an additional benefit when it comes to generate the system code. The “observers” that monitor the system behavior and compute the QoS metrics can be used to generate the instrumentation code that monitors the actual behavior of the system, too. After this introduction, Section 2 briefly describes one proposal for modeling the functional aspects of systems, which also contemplates time-dependent behavior. It presents an example that will be used throughout the paper to illustrate our approach. Section 3 introduces the main concepts of our proposal, and how they can be used to specify QoS properties. In particular, we show how the throughput, jitter and mean-time between failures of the system are specified. Then, Section 4 shows how the specifications produced can be used to analyse the system, to specify self-adaptation mechanisms for alternative behaviors of the system, and to generate probes. Finally, Section 5 compares our work with other related proposals and Section 6 draws some conclusions.

2 Specifying Functional Properties One way of specifying the dynamic behavior of a DSL is by describing the evolution of the modeled artifacts along some time model. In MDE, this can be done using model transformations supporting in-place update [7]. The behavior of the DSL is then specified in terms of the permitted actions, which are in turn modeled by the transformation rules. There are several approaches that propose in-place model transformations to deal with the behavior of a DSL, from textual to graphical (see [8] for a brief survey). This approach provides a very intuitive way to specify behavioral semantics, close to the language of the domain expert and the right level of abstraction [9]. In-place transformations are composed of a set of rules, each of which represents a possible action of the system. These rules are of the form l : [NAC]∗ × LHS → RHS, where l is the rule’s label (its name); and LHS (left-hand side), RHS (right-hand side), and NAC (negative application conditions) are model patterns that represent certain (sub-)states of the system. The LHS and NAC patterns express the precondition for the rule to be applied, whereas the RHS one represents its postcondition, i.e., the effect of the corresponding

298

J. Troya, J.E. Rivera, and A. Vallecillo

Fig. 1. Sound System metamodel

action. Thus, a rule can be applied, i.e., triggered, if an occurrence (or match) of the LHS is found in the model and none of its NAC patterns occurs. Generally, if several matches are found, one of them is non-deterministically selected and applied, producing a new model where the match is substituted by the appropriate instantiation of its RHS pattern (the rule’s realization). The model transformation proceeds by applying the rules in a non-deterministic order, until none is applicable — although this behavior can be usually modified by some execution control mechanism [10]. In [11] we also showed how time-related attributes can be added to rules to represent features like duration, periodicity, etc. Moreover, we also included the explicit representation of action executions, which describe actions currently executing. We have two types of rules to specify time-dependent behavior, namely, atomic and ongoing rules. Atomic rules represent atomic actions, with a specific duration. They can be cancelled, but cannot be interrupted. Ongoing rules represent interruptible continuous actions. Atomic rules can be periodic, and atomic and ongoing rules can be scheduled, or be given an execution interval, by rules’ lower and upper bounds. A special kind of object, named Clock, represents the current global time elapse. This allows designers to use it in their timed rules. A running example Let us show a very simple example to illustrate how the behavior of a system can be modeled using our visual language. The system models the transmission of a sound via a media, the Internet for instance. It consists of a soundmaker (e.g., a person) who, periodically, transmits a sound to a microphone. This one is connected to a media (the Internet), which transports the sound to a speaker. Finally, when the sound reaches the

On the Specification of Non-functional Properties of Systems by Observation

299

Fig. 2. Initial model of the system

Fig. 3. GenSound rule

speaker, it is amplified. Fig. 1 shows the metamodel of the system. For the time being, Coder and Decoder metaclasses can be ignored; they will be mentioned in Sect. 4. The initial state of the system is shown in Fig. 2. The position of objects in the initial model has been omitted for simplicity reasons. In addition to the metamodel and the initial model of our system, we also need to describe the behavior of the system. This is done in terms of the possible actions, which in our proposal are represented by in-place transformation rules. The GenSound periodic rule (Fig. 3) makes the soundmaker emit a sound every 3 time units. This rule makes use of an action execution element. This way, we explicitly forbid the execution of the rule (see the NAC1 pattern) if the same soundmaker is emitting another sound. This action execution states that the element sm (the soundmaker) is participating in an execution of the rule GenSound, so the rule cannot be applied if there is a match of this NAC. In the RHS, we can see that the sound is now in the microphone, so it acquires its position. The sound has 20 decibels. The duration of the action modeled by this rule is one time unit. Fig. 4 shows the rule which makes the sound reach the speaker. As we can see in the LHS pattern, this rule is executed when the microphone has a sound. This microphone

300

J. Troya, J.E. Rivera, and A. Vallecillo

Fig. 4. SoundFlowSlow rule

Fig. 5. OverLoad rule

has to be connected to a media which should be, in turn, connected to a speaker. The number of sounds that the media is currently transporting has to be lower than its capacity. When the rule is realized, the sound reaches the speaker (RHS pattern). When this happens, the sound decibels are quadruplicated and the position of the sound is changed to be the same as the position of the speaker. The time the media consumes in transporting the sound (i.e., the time consumed by the rule) is given by the Manhattan distance between the microphone and the speaker. Fig. 5 shows the OverLoad rule. It is triggered when the soundmaker has produced a sound which is now at the microphone, and the media is already transporting more sounds than its capacity allows. Thus, the sound appearing in the LHS pattern cannot be transported and it is lost (i.e., it is not included in the RHS pattern). So far, these three rules are enough for modeling the behavior of this simple system. Let us see now how to add QoS information to these specifications about the performance and reliability properties of the system.

On the Specification of Non-functional Properties of Systems by Observation

301

3 Specifying QoS Properties by Observation The correct and complete specification of a system should include the specification and analysis of its non-functional properties. An approach to specify QoS requirements, based on the observation of the system actions and of the state of its constituent objects, is presented in this section. In particular, we introduce three QoS parameters which have to be updated with the passing of time. – Throughput (th): The amount of work that can be performed or the amount of output that can be produced by a system or component in a given period of time. Throughput is defined as th = n/t , where n is the amount of work the system has performed and t is the time the system has been working. The work the system performs depends on the kind of system we are dealing with. In our example, it is the number of successful packets transmitted. – Mean time between failures (MTBF): the arithmetic mean (average) time between failures of a system. MTBF = t /f , where t is the time the system has been working and f is the number of failures of the system. – Jitter (j ): in the context of voice over IP, it is defined as a statistical variance of the RTP data package inter-arrival time [12]. RTP (Real Transport Protocol) provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. To estimate the jitter after we receive an i-th packet, we calculate the change of inter-arrival time, divide it by 16 to reduce noise, and add it to the previous jitter value. The division by 16 helps to reduce the influence of large random changes. The formula used is: j (i) = j (i −1)+(| D (i −1, i) | −j (i −1))/16, where j (i) is the current jitter value and j (i − 1) is the previous jitter value. In this jitter estimator formula, the value D (i, j ) is the difference of relative transit times for the two packets. The difference is computed as D (i, j ) = (Rj −Ri )−(Sj −Si ), where Sj (Sendj ) is the time the package j appears in the system (that is, the time at which it is sent by the transmitter) and Rj (Receivej ) is the time the package j leaves the system because it has been processed (that is, the time at which it is received by the receiver). 3.1 Defining Observers To calculate the value of these QoS properties we propose the use of observers. An observer is an object whose objective is to monitor the value of one of these parameters. We identify two kinds of observers, depending on whether they monitor specific objects or the state and behavior system as a whole. In the first case, observers are created with the objects they monitor, and destroyed with them. In the second case, observers are present for the whole life of the system. As a first approach, we have created a metamodel of observers (Fig. 6) with four observers, which inherit from an Observer class. Each of them has a specific purpose: – ThroughPutOb. Calculates the current value of throughput in the system, which is stored in its variable tp. Attribute packages counts the number of successful packages, i.e., those that have reached their destinations.

302

J. Troya, J.E. Rivera, and A. Vallecillo

Fig. 6. Observers Metamodel

Fig. 7. Initial model of the system with observers

– MTBFOb. Calculates the MTBF of the system (mtbf attribute). Attribute fails stores the number of lost packages. – JitterOb. This is a general observer that is used to compute the jitter of the system. It has three attributes: prevJitter contains the latest jitter value, prevTS stores the time the latest package appeared in the system, and prevArrival stores the time the latest package left the system. – JitterIndOb. This observer has a reference to an EObject, which is at the top of the class hierarchy. In this way, it can be associated to any of the elements of the Sound System metamodel. In our example, this observer is associated to individual sounds. It computes the jitter when its associated sound reaches its destination. The idea for including observers in our system is to combine the two metamodels (Fig. 1 and 6) to be able to use the defined observers in our sound system language. In fact, since our modeling tool e-Motions [11] allows users to merge several metamodels in the definition of a DSVL behavior, we can define the Observers metamodel in a

On the Specification of Non-functional Properties of Systems by Observation

303

Fig. 8. GenSound with observers

non-intrusive way, i.e., we do not need to modify the system metamodel to add observers in their rules. Furthermore, this approach also enables the reuse of observers across different DSVLs. Thus, we have added to the initial model depicted in Fig. 2 a set of initial observers (see Fig. 7). They will be present throughout the execution of the system and their values will be changing depending on the state of the system. The other elements are the same as shown in Fig. 2. 3.2 Describing the Behavior of the Observers Once the observers have been added to a system, we can define their behavior using the rules described in Section 2. In this section we show how the throughput, jitter and mean time between failures can be updated by means of the rules that specify the behavior of the system. In Fig. 8, an observer has been added to action GenSound. Now, the rule associates a JitterIndOb observer to a newly generated sound. The time this sound appears in the system is stored in attribute timeStamp. In Fig. 9, the MTBFOb observer has been added to action OverLoad, to be able to update its attribute fails every time a sound disappears. Fig. 10 shows how the value of the jitter is calculated when a sound reaches its destination and how the number of successful packages is updated. As we can see, a JitterIndOb observer is associated to the sound. Observers ThroughPutOb and JitterOb appear in the LHS part of the rule. When the sound reaches the speaker (RHS part), the number of successful packages of the system is increased. The jitter attribute of the JitterIndOb associated to the sound is computed, using the value of its timeStamp attribute and the three attributes of the JitterOb observer.

304

J. Troya, J.E. Rivera, and A. Vallecillo

Fig. 9. OverLoad with observers

Fig. 10. SoundFlowSlow with observers

Fig. 11 shows an atomic rule which has been added to this new system with observers. It is triggered when a sound reaches the speaker, i.e., after the SoundFlowSlow rule has been executed. In the LHS part, the JitterIndOb associated with the sound contains the current jitter. This rule updates the values of the attributes of JitterOb in the RHS part and makes the sound disappear (because it has reached its destination). Fig. 12 shows an ongoing rule, required to calculate the throughput and MTBF of the global system. It is an ongoing rule and therefore it progresses with time. In this way both observers always store correct and up-to-date QoS values at any moment in time.

On the Specification of Non-functional Properties of Systems by Observation

305

Fig. 11. New rule: ConsumeSound

Fig. 12. New rule: UpdateObservers

4 Making Use of the Observers Apart from computing the QoS values for the system, observers can be very useful for defining alternative behaviors of the system, depending on the QoS levels. For instance, the system can self-adapt under certain conditions, since we are able to search for states of the system in which some attributes of the observers take certain values. Fig. 13 shows a rule where the media that transmits the sound changes when the throughput value is less than a threshold value (1.5 in this case). In particular, we add one coder and one decoder to the system. Thus, when there is a match of the LHS part, the system self-adapts to accomplish the requirements. Fig. 14 shows the behavior of the sound flow with the presence of coders and decoders. It is very similar to the SoundFlowSlow rule. The main difference is the time both rules consume. This new rule, with the coder and decoder added to the system, consumes half the time the other rule does. In this way, the throughput value increases notably, improving the system performance.

306

J. Troya, J.E. Rivera, and A. Vallecillo

Fig. 13. New rule: ChangeMedia

Fig. 14. SoundFlowFast with observers

Fig. 15. ChangeMedia2: Restoring the change made by ChangeMedia

Similarly, Fig. 15 shows a rule that specifies the opposite transformation. That is, when the throughput goes above 1.5, the system returns to its original configuration. In this way the configuration of the system can toggle between these two options, selfadapting according to the overall performance.

On the Specification of Non-functional Properties of Systems by Observation

307

5 Related Work Several approaches have proposed a procedure for monitoring and measuring nonfunctional properties of a system. Some of them are similar to the one presented here, although all of them have a different focus. For example, Liao and Cohen [13] introduced a high level program monitoring and measuring system which supported very high level languages. In [14] and [15] they propose two frameworks for performance measurement. In the first case, Mike et al. designed and implemented Pinpoint, a framework for problem determination in Internet service environments. It was implemented on top of the J2EE middleware platform, a network sniffer, and an analyzer based on standard data clustering techniques. In the second one, Matthias Rohr et al. present Kieker, which allows continuous monitoring, analysis, and visualization of Java applications. It supports to create Sequence Diagrams, Markov chains, Timing Diagrams, and Component Dependency Graphs from monitoring data. Our approach contains similar characteristics to these frameworks. On the one hand, it can be used to determine problems in systems by looking up the state of the observers. In our example, the sound system changed when the throughput was too low. On the other hand, our approach allows continuous monitoring of the system, as observers are constantly updated. Compilers supporting aspect-oriented programming (AOP), such as AspectJ [16] and AspectC++ [17], may be considered source-level instrumentation tools. In AOP, it concerns that cross-cut modules are factored out into modular aspects. AOP tools have been used to instrument programs with debugging and monitoring code [18], as well as to instrument programs with code to check temporal invariants [19]. As a shortcoming, AOP techniques can only be applied at well-defined join points and can be used for instrumentation only. With our approach, instead, non-functional parameters can be measured at any time and at any point in the system. In addition, our proposal remains at a very high level of abstraction, without being tied to any programming language or concrete technology platform. Observers are not a new concept. They have been defined in different proposals for monitoring the execution of systems and to reason about some of their properties. For example, the OMG defines different kinds of observers in the MARTE specification [6]. Among them, TimedObservers are conceptual entities that define requirements and predictions for measures defined on an interval between a pair of user-defined observed events. They must be extended to define the measure that they collect (e.g., latency or jitter), and aim at providing a powerful mechanism to annotate and compare timing constraints over UML models against timing predictions provided by analysis tools. In this sense they are similar to our observers. The advantage of incorporating them into DSLs using our approach is that we can also reason about their behavior, and not only use them to describe requirements and constraints on models. In addition, we can use our observers to dynamically change the system behavior, in contrast with the more “static” nature of MARTE observers. General frameworks for self-adaptive systems are presented in [20] and [21], featuring inter-related monitoring, analysis and adaptation tiers. Diaconescu et al. [22] add a transparent software layer between components and middleware. This framework aligns with [20] and [21], while specifically targeting enterprise applications based on contextual composition middleware. Our approach presents a way to make systems

308

J. Troya, J.E. Rivera, and A. Vallecillo

self-adaptive as well, although we deal with the monitoring of QoS parameters using observers at high level of abstraction, and again independently from the underlying platform or language. In both cases we see that our approach could be easily mapped to the ones mentioned here, hence provided platform-independent models that could be transformed into these platform-specific approaches, as we plan to do as part of our future work.

6 Conclusions and Future Work The correct and complete specification of the non-functional properties of a system is critical in many important distributed application domains. In this paper we have presented a platform independent approach to specify QoS properties and requirements, and shown its use to specify three of them: throughput, jitter and mean time between failures. In particular, we have shown that the use of observers that monitor the state and behavior of the system can be very useful to enrich some kinds of high-level behavioral specifications with QoS information. The QoS parameters calculated by observers can be used for many additional purposes. We have shown how our approach can also serve to easily specify self-adaptive behaviors depending on the values of the system QoS properties. Please also note that our proposal is built on top of the underlying language (e-Motions [11] in this case), hence allowing users to make use of all the analysis possibilities available for that environment [10] for free. Another advantage of our proposal is that it can serve to monitor not only the states of the objects of the system, but also their actions. The fact that action executions are first-class citizens of the e-Motions visual language enables their monitorization by our observers. As part of our future work we would like to define additional observers, with the advantage that once defined they can be re-used across models. For this purpose, we would like to create libraries into e-Motions with these observers. This way, designers could merge several metamodels: their original ones and the metamodels with observers provided by the libraries. This makes the designers tasks easier when including QoS properties to their systems. We would also like to study the connection of these specifications with other notations (e.g., SysML or MARTE) so that transformations can be defined between them. In addition, we would also like to explore the automatic instrumentation of the standard code generated by model-transformation approaches, with the aim of being able to generate monitors and probes associated to the code, too. Acknowledgements. The authors would like to thank the anonymous referees for their insightful comments and very constructive suggestions. This work has been supported by Spanish Research Projects TIN2008-031087 and P07-TIC-03184.

References 1. Troya, J., Rivera, J.E., Vallecillo, A.: On the specification of non-functional properties of systems by observation. In: Proc. of the 2nd International Workshop on Non-Functional Properties for DSMLs (NFPinDSML 2009), Denver, CO. CEUR Workshop Proceedings, vol. 553 (2009), http://CEUR-WS.org/Vol-553/paper1.pdf 2. Balsamo, S., Marco, A.D., Inverardi, P., Simeoni, M.: Model-based performance prediction in software development: A survey 30(5), 295–310 (2004)

On the Specification of Non-functional Properties of Systems by Observation

309

3. Cortellessa, V., Marco, A.D., Inverardi, P.: Integrating performance and reliability analysis in a non-functional MDA framework. In: Dwyer, M.B., Lopes, A. (eds.) FASE 2007. LNCS, vol. 4422, pp. 57–71. Springer, Heidelberg (2007) 4. OMG: UML Profile for Schedulability, Performance, and Time Specification. OMG, Needham (MA), USA (2005) 5. OMG: UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms. OMG, Needham (MA), USA, ptc/04-09-01 (2004) 6. OMG: A UML Profile for MARTE: Modeling and Analyzing Real-Time and Embedded Systems. OMG, Needham (MA), USA (2008) 7. Czarnecki, K., Helsen, S.: Classification of model transformation approaches. In: OOPSLA 2003 Workshop on Generative Techniques in the Context of MDA (2003) 8. Rivera, J.E., Guerra, E., de Lara, J., Vallecillo, A.: Analyzing rule-based behavioral semantics of visual modeling languages with Maude. In: Gaˇsevi´c, D., L¨ammel, R., Van Wyk, E. (eds.) SLE 2008. LNCS, vol. 5452, pp. 54–73. Springer, Heidelberg (2009) 9. de Lara, J., Vangheluwe, H.: Translating model simulators to analysis models. In: Fiadeiro, J.L., Inverardi, P. (eds.) FASE 2008. LNCS, vol. 4961, pp. 77–92. Springer, Heidelberg (2008) 10. Rivera, J.E., Vallecillo, A., Dur´an, F.: Formal specification and analysis of Domain Specific Languages using Maude. Simulation: Transactions of the Society for Modeling and Simulation International 85(11/12), 778–792 (2009) 11. Rivera, J.E., Dur´an, F., Vallecillo, A.: A graphical approach for modeling time-dependent behavior of DSLs. In: Proc. of the IEEE Symposium on Visual Languages and HumanCentric Computing (VL/HCC 2009), Corvallis, Oregon (US). IEEE Computer Society, Los Alamitos (2009) 12. Toncar, V.: VoIP Basics: About Jitter (2007), http://toncar.cz/Tutorials/VoIP/VoIP_Basics_Jitter.html 13. Liao, Y., Cohen, D.: A specification approach to high level program monitoring and measuring 18(11), 969–978 (1992) 14. Chen, M.Y., Kiciman, E., Fratkin, E., Fox, A., Brewer, E.: Pintpoint: Problem determination in large, dynamic internet services. In: Proceedings of the 2002 International Conference on Dependable Systems and Networks, pp. 595–604. IEEE Computer Society, Washington (2002) 15. Rohr, M., van Hoorn, A., Matevska, J., Sommer, N., Stoever, L., Giesecke, S., Hasselbring, W.: Kieker: Continuous monitoring and on demand visualization of Java software behavior. In: Proceedings of the IASTED International Conference on Software Engineering 2008, pp. 80–85. ACTA Press (2008) 16. Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W.: An overview of AspectJ. In: Knudsen, J.L. (ed.) ECOOP 2001. LNCS, vol. 2072, pp. 327–353. Springer, Heidelberg (2001) 17. Spinczyk, O., Gal, A., Schroder-Preikschat, W.: AspectC++: an aspect-oriented extension to the C++ programming language. In: Proc. of 40th International Conference on Tools Pacific, pp. 53–60 (2002) 18. Mahrenholz, D., Spinczyk, O., Schroeder-Preikschat, W.: Program instrumentation for debugging and monitoring with Aspectc++. In: Proc. of ISORC 2002, pp. 249–256 (2002) 19. Gibbs, T., Malloy, B.: Weaving aspects into C++ applications for validation of temporal invariants. In: Proc. of SMR 2003 (2003) 20. Garlan, D., Cheng, S., Schmerl, B.: Increasing system dependability through architecturebased self-repair. In: Architecting Dependable Systems. Springer, Heidelberg (2003) 21. Oreizy, P., Gorlick, M., Taylor, R., Heimbigner, D., Johnson, G., Medvidovic, N., Quilici, A., Rosenblum, D., Wolf, A.: An architecture-based approach to self-adaptive software. In: IEEE Intelligent Systems (1999) 22. Diaconescu, A., Mos, A., Murphey, J.: Automatic performance management in component based systems. In: Proc. of ICAC 2004, pp. 214–221 (2004)

Modeling Heterogeneous Points of View with ModHel’X Frédéric Boulanger, Christophe Jacquet, Cécile Hardebolle, and Elyes Rouis SUPELEC, 3 rue Joliot-Curie, 91192 Gif-sur-Yvette Cedex, France [email protected]

Abstract. Non-functional properties (NFPs) concern various characteristics of a system (cost, power, QoS). These characteristics belong to diﬀerent models of the system, built by diﬀerent design teams, using different formalisms. Therefore, the design of a system includes a number of domain-speciﬁc modeling languages, used to express various NFPs. This paper focuses on the heterogeneity of the points of view on the system. We show that “multi-view” approaches which do not rely on a unique underlying model appear better-suited to express NFPs than model weaving or annotations. However, existing approaches in this category do not yet support model execution. We introduce a multi-view extension to ModHel’X, a framework for executing heterogeneous models, and we show how it can be used for modeling non-functional characteristics of a system and expressing NFPs. A key point of this approach is that it relies only on the core concepts of ModHel’X, but uses them in new ways.

1

Introduction

The design of a system requires to take into account diﬀerent concerns besides the core function of the system. Such concerns comprise cost, reliability, performance, or power consumption. Concerns are generally classiﬁed as functional or non-functional. While functional concerns used to be the main matter in the development process, non-functional concerns are now taken into consideration earlier because they constrain the design of the functional part of the system. This is why, in the context of Model Driven Engineering, diﬀerent techniques have been developed to model non-functional characteristics of systems. One of the goals of these techniques is to allow the analysis of non-functional properties of a system together with its functional behavior during design. Obviously, diﬀerent concerns require diﬀerent types of models since they rely on diﬀerent domains (power, security, etc.), which therefore implies the use of suitable modeling languages or paradigms (diﬀerential equations, state machines, statistics). In consequence, several domain-speciﬁc modeling languages (DSMLs) are used when modeling a system with respect to diﬀerent concerns. We focus here on the problems caused by the heterogeneity of the modeling languages which are used to model functional and non-functional features [1]. In this paper, we present an approach in which the system is modeled from diﬀerent points of view which correspond to diﬀerent concerns. A view of the S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 310–324, 2010. c Springer-Verlag Berlin Heidelberg 2010

Modeling Heterogeneous Points of View with ModHel’X

311

system may regard either its functional or its non-functional characteristics. Each view is modeled using a modeling language which is suitable for the considered concern. Since diﬀerent views of the system may be interdependent (for instance, the power consumption of a system, which is studied in one view, may depend on the state of the system, which is studied in another view), we provide means to express dependencies among views in order to ensure the coherence of the diﬀerent models of the system. Our goal is to enable the simultaneous execution of diﬀerent models which represent the system under diﬀerent points of view. Our approach relies on an existing framework, called ModHel’X [2]. First, we present related work and motivate our approach in section 2. Then, in section 3, we introduce the approach we propose. We brieﬂy present ModHel’X, a framework built for assembling heterogenous models through hierarchical composition in 3.1. Then, starting from the basic concepts of ModHel’X, we propose an architecture for deﬁning the coherence of several views of a system in 3.2. This architecture introduces no new concepts in ModHel’X, but uses the composition mechanisms of ModHel’X in two ways: for aggregation (building more complex systems by assembling simple systems), and for superposition (adding layers for deﬁning diﬀerent aspects of a system). We detail the mechanisms that we propose to model interdependencies among views. In section 4, we illustrate the principles of our approach on an example. Finally, we discuss open issues in section 5, before concluding.

2

Related Work

Non-functional characteristics of a system may be expressed in a number of ways. First, crosscutting concerns (including non-functional features) may be modeled separately from the functional core of the system, and later be “woven” into it. This constitutes the aspect-oriented approach. Second, non-functional features may be expressed as annotations to the core model, as done in UML with the MARTE proﬁle. Third, the features of the system, both functional and nonfunctional, may be constructed in parallel, in relation to one another, through various “views” on the system, corresponding to various ﬁelds of concerns. Let us start with aspect-oriented approaches. 2.1

Aspects for Weaving Non-functional Features into Models

Object-oriented programming allows the structuration of an application into modular parts. However, non-functional, crosscutting concerns are interwoven in the object-oriented code. For instance, in an application that performs logging, virtually every class is “polluted” with logging-related code, which increases complexity. To allow for more modularity, aspect-oriented programming (AOP) was introduced. Crosscutting concerns such as logging are called aspects and are considered separately from the main code. An aspect is composed of an advice, a portion of code to add to the main program, and a pointcut, an expression which speciﬁes at which points in the main program the advice is to be added.

312

F. Boulanger et al.

The action of automatically combining a base program with aspects to get a new program is known as weaving. Well-known implementations of aspect-oriented programming include, for the Java language, AspectJ and Hyper/J. AOP enables one to weave non-functional behaviors into a core program. Likewise, one may wish to be able to weave non-functional aspects into a functional model. To this end aspect-oriented modeling (AOM) was introduced [3]. An aspect-oriented design model consists of a primary (functional) model and a set of aspect (non-functional) models. Each aspect model describes a feature that crosscuts elements in the primary model. The primary model and the aspect models can be woven automatically to obtain a global model which contains both functional and non-functional features [4]. Theme/UML [3] extends the UML standard to explicitly support modularization and the composition of concerns. The extensions include a new type of classiﬁer called theme and a new type of relationship called composition relationship. A theme contains two types of UML diagrams, class diagrams and sequence diagrams. Themes correspond to functional or non-functional concerns in the design of the system. When a theme corresponds to a crosscutting concern, it is called an aspect theme. Composition relationships deﬁne how themes are woven with each other: concepts and behaviors may be composed between themes [5]. RAM (Reusable Aspect Models) [6] follows the same philosophy as Theme/UML, but crosscutting concerns can be described using three types of UML diagrams: class diagrams, sequence diagrams and state diagrams. Similarly, Superimposition [7] allows one to weave the behavior of a component with additional behavior (functional or non-functional). Superimposition has mathematical grounds, and may be expressed using activity diagrams [8]. However, in this paper, we do not wish to weave functionalities into a component or system, but rather to describe a system from diﬀerent perspectives. The next two sections introduce annotations and multi-view approaches, that seem to be better suited to our objective. 2.2

Annotations for Expressing Non-functional Properties

Non-functional features are not necessarily intended to be woven into the system. Instead, one may wish to express properties to be veriﬁed on the system. Starting from a functional model of the system, which states what the system shall do, one can add annotations to state how the system shall do it. These annotations carry non-functional properties. For instance, when using UML to model a system, various proﬁles can be used to add domain-speciﬁc annotations [9]. Examples of such proﬁles are SPT (UML Proﬁle for Schedulability, Performance and Time Speciﬁcation) or more recently MARTE (Modeling and Analysis of Real-Time and Embedded systems) for real-time constraints, QoS&FT (UML Proﬁle for Modeling Quality of Service and Fault Tolerance) for QoS constraints. In this context, annotating a UML model amounts to attaching information to model elements, which can be done in two ways according to Espinoza et al. [9]. First, one can use tagged values, which are value slots associated to stereotype attributes. Hence a tagged value applies to one element only. Second, one can

Modeling Heterogeneous Points of View with ModHel’X

313

use OCL constraints, which are more ﬂexible, and apply to several elements. A syntax must be given for non-functional properties, in order to deﬁne types, values and the nature of the values (required, assumed, achieved value, etc.). The annotations may be used for two purposes: analyzing a model, and constraining the synthesis of the actual system from the model. For instance, MARTE annotations to a UML model may be used to check the model for schedulability (analysis), but also to choose a scheduler or allocate resources when generating an implementation (synthesis). 2.3

Multiple Views for Representing a System from Various Angles

Adding annotations to a core model may not be suﬃcient to describe complex non-functional points of view of the system. A designer or a team of designers may wish to be able to build full-ﬂedged models of a system from several points of view in parallel, while ensuring consistency among the points of view. This is called multi-view modeling, and it can be approached in two ways. The ﬁrst and most common one is to consider that views are projections of a hybrid reference model. In this approach, the reference model aggregates all the information about the system. Views are queries on the reference model; they perform projections hiding irrelevant information when studying a particular aspect of the system. The second approach uses views as partial deﬁnitions or expected observations of the system. Therefore, there is no explicit reference model of the system. However, information about the system can be obtained dynamically by combining information observed in diﬀerent views. The diﬀerent views must be linked so that global properties can be computed from properties which come from diﬀerent models. This approach is similar to the drawing of a front view, a top view and a side view for modeling a building: it provides global information about the building without requiring to build a 3D global model. The work of Attiogbé et al. [10] and View-based UML (VUML) [11] belong to the ﬁrst approach: they are centered around a reference model. In the framework of Attiogbé et al., there is a clear distinction between an abstract reference model, which concentrates all information available about the system, and specific models, which are built from the reference model. The speciﬁc models constitute various points of view on the system. Analysis can be performed on speciﬁc models. Modiﬁcations on one speciﬁc model are fed back into the reference model and then propagated to the other speciﬁc models. VUML is a UML proﬁle for multi-view modeling. It is based on the concept of multi-view class. A multi-view class consists of a default (common) view and a set of speciﬁc views related to the common view through extension relations. OCL constraints enforce consistency among views. As UML is the underlying framework, there is indeed a reference model, the UML model itself. Maintaining a reference model requires to update this model each time a view is changed, as well as to propagate the change to the other views. Moreover, the reference model must be an instance of a meta-model which encompasses the semantics of every possible view of the system. Deﬁning the semantics of such a union language is very diﬃcult, and reference models are therefore purely

314

F. Boulanger et al.

syntactic. This makes the veriﬁcation of the global coherence of a model a diﬃcult problem. That is why the second approach, in which there is no explicit reference model, seems promising. Let us now see two examples of this approach: the work of Benveniste et al. [12] and Rosetta [13,14]. Benveniste et al. introduce a framework for system design, inspired by the Tagged Signal Model [15], in which components are characterized by contracts. A contract comprises assumptions and guarantees, which are sets of acceptable behaviors, or “traces”. An implementation of a component conforms to a contract if the guarantees are satisﬁed whenever the assumptions are satisﬁed. Several contracts can be provided for a given component, which allows the designer to express both functional and non-functional properties. Rosetta is a system speciﬁcation language based on formal (coalgebra-based) semantics. Central in Rosetta is the notion of facet. A facet corresponds to an observable aspect of a component, either functional or non-functional. Facets which model diﬀerent components can interact with each other. Also, several facets of the same component may be combined with a product operator, meaning that all of them must be satisﬁed simultaneously, which ensures consistency among views. Rosetta can therefore be used to model the structure of systems, as well as diﬀerent points of view on system components. However, the framework of Benveniste et al. and Rosetta remain at the level of speciﬁcations, which means that models cannot be executed directly. Therefore a designer who uses one of these tools to specify a system will have to use another tool in order to get an executable implementation. In the remainder of this paper, we introduce a proposal which adds multi-view modeling capabilities to ModHel’X, an existing framework for heterogeneous modeling. Contrary to the aforementioned frameworks, ModHel’X is capable of executing a model: it can calculate its behavior. ModHel’X belongs to the second approach, since it considers views as layers that add information to each other in order to build an implicit global model of a system. The originality of the approach presented here is to specify the links between views using the same mechanisms that were designed for the hierarchical composition of heterogeneous models. It therefore provides a uniform framework for combining heterogeneous models both for hierarchical composition and for the superposition of views.

3 3.1

Multi-view Modeling with ModHel’X ModHel’X

We start here with a short introduction to the basic concepts of ModHel’X, so that we can show later how these concepts can be used for multi-view modeling. ModHel’X [2] is a framework for modeling heterogeneous systems. It is designed to build models by assembling model parts which are described using diﬀerent modeling languages. It relies on a generic metamodel for describing the structure of models, and on a generic execution engine for interpreting such structures. A comparison of ModHel’X with other related approaches in the Multi-Paradigm Modeling domain can be found in [16].

Modeling Heterogeneous Points of View with ModHel’X

315

In ModHel’X, the interpretation of a model by the generic execution engine is directed by a model of computation. A model of computation is a set of rules for combining the behaviors of a set of components into the behavior of a model. Well-known examples of models of computation include discrete events, synchronous data-ﬂows, ﬁnite state machines and continuous time [17]. In ModHel’X, a model of computation dictates the rules for scheduling the components of a model, for propagating values between components, and for determining when the computation of the state of a model is complete. The concept of model of computation is essential in ModHel’X because it allows ModHel’X to support the execution of models described using diﬀerent modeling languages as well as the execution of models composed of sub-models which are described using diﬀerent modeling languages (which are called “heterogeneous models”). In order for ModHel’X to support a given modeling language, an expert of this language must describe the corresponding model of computation. Once described in ModHel’X, this model of computation is used by the generic execution engine in order to interpret any model described using the chosen modeling language. This mechanism is further detailed in [2].

Pin Block

Pin

A

relation

B

Pin Fig. 1. A block

Fig. 2. A composite

The elementary unit of behavior in ModHel’X is the block, as shown on ﬁgure 1. A block is deﬁned (a) by its interface which is composed of pins, and (b) by an update operation which allows the observation of the behavior of the block through its interface. Pins are used to send and receive information and they deﬁne what is observable from a block. The behavior of a block is observed by requiring an update of its interface. The update operation requires that the block take its inputs into consideration and update its outputs according to the inputs and its current state. Blocks can be assembled by setting relations between their pins. A composite block, as shown on ﬁgure 2, is composed of a set of blocks with relations between their pins. Its interface is a subset of the union of the interfaces of its blocks (it can hide their pins or make them visible from the outside). On the ﬁgure, the pins exposed at the interface of the composite block are shown as dashed circles in order to emphasize that they are just pins of the internal blocks which are made visible through the interface of the composite block. A model of computation is used to deﬁne the semantics of the interconnected blocks. A composite associated to a model of computation forms a model, as shown on ﬁgure 3.

316

F. Boulanger et al.

MoC A

B

MoC A

B adaptin adaptOut

Fig. 3. Model

Fig. 4. Interface block

ModHel’X has support for hierarchical composition and heterogeneity thanks to interface blocks. An interface block is a kind of block whose behavior is deﬁned by a model (which is therefore “inside” the block). An example is shown on ﬁgure 4. The model which deﬁnes the behavior of an interface block may use a diﬀerent (internal) model of computation than the (external) one used for the model in which the interface block is used. Hierarchy through interface blocks is the mechanism used to combine heterogeneous models in ModHel’X. The semantic adaptation between the two models of computation is speciﬁed by deﬁning the adaptIn and adaptOut operations of the interface block. These operations are in charge of adapting the control (scheduling, synchronization) and the data between the internal model of computation and the external one. An interface block has its own pins, and the data available on those pins is processed by its adaptIn and adaptOut operations. Typically, adaptIn uses the valuation of the pins of the interface block to compute scheduling and status information as well as a valuation of the pins of the composite block. adaptOut uses status information and the valuation of the pins of the composite block to give a valuation of the pins of the interface block. 3.2

Multiple Views of a System in ModHel’X

A block in ModHel’X represents an observable behavior. When we consider a component that we want to model from diﬀerent points of view, each view can be considered as an observable behavior and represented as a block in ModHel’X. With this approach, a “real world” component may be modeled by a block Cϕ for its functional behavior, by a block CP for its power consumption, and by a block CT for its thermal behavior. By considering that a view of a component is a ModHel’X block, we can build composite views by assembling components and interpreting this composition according to a model of computation. This is composition by aggregation, the usual way of building models with block diagram tools, for which the metamodel of ModHel’X was built. Actually, there can be several of these views for a given system: in the same way we build a functional view of a system by assembling blocks which represent the functional behavior of the components of the system, we can also build a power consumption view of the system by assembling the blocks which represent the power consumption behavior of these components. Each of these two models computes one aspect of the behavior of the system, and they are interdependent.

Modeling Heterogeneous Points of View with ModHel’X

3.3

317

Multi-view Models and Coherence among Views

Indeed, the power consumption of a system may depend on its functional behavior, and this dependency should be stated in the model of the system. This leads us to consider that blocks may be combined in two ways: by aggregation, in order to build larger models (as seen in the previous section); and by superposition, in order to build multi-view models. Composition by superposition amounts to maintaining coherence between models which represent diﬀerent views of a system so that the behaviors observed in the diﬀerent views are coherent. The abstract syntax (block, pin, relation, MoC) of ModHel’X has been designed for composition by aggregation, but we will now show that it can also be used for composition by superposition. In a multi-view model, coherence between views can be denoted by relations between the ports of the views, just as the composition of the behaviors of several blocks is denoted by relations between their ports. Figure 5 shows two views of a component C, which are superposed so that observations on view CP are coherent with observations on view Cϕ . The relations between the pins of the two views represent the coherence relation between their behaviors, and the semantics of the interconnection of these views is deﬁned by a model of computation, as for any model in ModHel’X.

MoCϕ Bϕ

AP

BP

MoCs1

MoCs2

Aϕ Cϕ MoC

CP Fig. 5. Superposition of views

MoCP

Fig. 6. Superposition and aggregation

Figure 6 illustrates the general pattern for using both composition by aggregation and composition by superposition. Views Aϕ and Bϕ are composed by aggregation according to MoCϕ in order to build a functional view of a system. Views AP and BP are also composed by aggregation according to MoCP to build a power consumption view of the system. The coherence of these views is obtained by maintaining the coherence of Aϕ and AP, and of Bϕ and BP. This is achieved by composing these views according respectively to MoCs1 and MoCs2.

4

Illustrative Example

In order to illustrate our approach of multi-view modeling, we present on ﬁgure 7 a simple example in which a thermostat regulates the temperature in a room by

318

F. Boulanger et al.

T < 20◦ C T◦

On

Oﬀ

And

Heater

T > 20◦ C CT

SDF

DE

Power consumption view

Functional view

Superposition model

Main switch

if (state == On) { out = 10 W } else { out = 2 W

if (in > 0) { out = 2000 W } else { out = 0 W

}

}

CT +

Fig. 7. Example multi-view model

switching a heater on or oﬀ. For the sake of simplicity, the border and pins of the composite blocks are omitted on the ﬁgure, and the internal model of interface blocks is represented in a form (state machine, pseudo code) which is easier to understand than a strict ModHel’X model. In the functional view, a thermometer (denoted by T◦ ) provides the thermostat with the ambient temperature. The thermostat is modeled as a state machine which switches between the On and Oﬀ states when the temperature goes below or above 20◦ C. When the main switch is on, the output of the thermostat is used to drive a heater. A synchronous data ﬂow (SDF) model of computation is used for the model of the thermostat, and the continuous time (CT) model of computation is used to combine the behaviors of the thermometer, the thermostat and the heater. In the power consumption view, the left block models the power consumption of the thermostat: 10 W when in the On state and 2 W when in the Oﬀ state. The power consumption of the heater is modeled by the next block (2000 W when powered). The last block in the power consumption view is an adder which computes the power consumption of the system by adding the power consumption of the thermostat and of the heater. The continuous time (CT) model of computation is used for this view. Let us examine now the coherence of the views. The power consumption of the thermostat depends on its internal state, so this information must be provided

Modeling Heterogeneous Points of View with ModHel’X

319

by the functional view to the power consumption view. However, for the sake of modularity, the internal state of the thermostat is an implementation detail that should not be revealed to other blocks in an aggregation model. We can consider it as protected information that should be available only for blocks whose behavior is tightly coupled to the functional behavior of the thermostat. The model of the thermostat has therefore two interfaces, one for composition by aggregation, and one for composition by superposition. ModHel’X has support for this since a given model may be wrapped into several interface blocks. On ﬁgure 7, aggregation interfaces are shown using solid black rectangles and pins, and superposition interfaces are shown using thick gray rectangles and gray pins. In a similar way, the power consumption view of the heater needs to know if the heater is powered. This is determined by the output of the And block in the functional view, which is therefore published in the superposition interface of the thermostat. This shows that pins in the superposition interface of a model can provide information from either aggregation interfaces (the output of the And block) or superposition ones (the state output of the thermostat). In ModHel’X, the role of the interface blocks is not only to deﬁne diﬀerent interfaces for a given model, but also to adapt the behavior of this model to diﬀerent models of computation. Here, the coherence of the two views of the system is expressed using the discrete event (DE) model of computation. The superposition interfaces therefore perform the semantic adaptation of the model of computation used for these models with DE. The aggregation interfaces of the same models also perform a semantic adaptation, but with CT. Let us examine the semantic adaptation of the model of the thermostat, which uses SDF. Its aggregation interface adapts between SDF and CT by making the internal model react only to signiﬁcant changes in the continuous input signal, and by holding a constant continuous output when no data sample is produced by the model. Its superposition interface adapts between SDF and DE by producing events when the automaton changes its state or when the output of the And block changes.

5

Discussion

We have shown that the basic meta-model designed to represent the structure of hierarchical heterogeneous models in ModHel’X can also be used to represent the coherence relations between several views of a system. However, we did not give the precise semantics of this representation. The generic execution algorithm of ModHel’X was designed with the hypothesis that a given block belongs to only one model because only composition by aggregation was possible. Adding composition by superposition allows a block to belong to several models, behind diﬀerent interfaces. Since the observations that are made of this block through diﬀerent interfaces are interdependent, the result of the execution of a multi-view model may depend on the order in which the diﬀerent views are observed. In the simple example of the thermostat, the power consumption view depends on the functional view, and there is no other dependency, so we can merely compute the behavior of the functional model, then the behavior of the superposition model,

320

F. Boulanger et al.

and last, the behavior of the power consumption model. However, if there were cyclic dependencies between these diﬀerent views, deﬁning the semantics of the multi-view model would be more diﬃcult. Actually, the current version of the execution engine of ModHel’X does not support it. In the following, we illustrate the problem and present some possibilities to address it.

A

B

A’

B’ MoC2

superp b

MoCa

view 1 MoCb

superp a

MoC1

view 2

Fig. 8. Cyclic dependencies

First, to show what a multi-view model with cyclic dependencies looks like, let us consider the example of ﬁgure 8. view 1 and view 2 model the behavior of the system according to diﬀerent points of view. superp a and superp b are used to maintain the coherence between the views. One may consider that A and B are views of some components of the system according to the point of view of view 1, and that A’ and B’ are views of the same components according to the point of view of view 2. Arrows are used to show that the behavior of B depends on data produced by A, the behavior of B’ on data produced by B, the behavior of A’ on data produced by B’, and the behavior of A on data produced by A’. Such cyclic dependencies are common and appear naturally in models of systems. In the example of the thermostat and the heater, we could have modeled the fact that the heater makes the temperature increase when it is on. Such a model is shown on ﬁgure 9. It uses three views to model the functional behavior of the system, its power consumption behavior, and its thermic behavior. The functional and power consumption views are similar to the ones shown on ﬁgure 7, with simpliﬁed schematics for complex blocks. The thermic view models the production of heat by the heater, as well as the thermic behavior of the room. A second superposition model is used to maintain the coherence between the power consumption view and the thermic view. A third one is added to maintain the coherence between the thermic view and the functional view, because the temperature measured by the thermometer depends on the thermic behavior of the room. The relation between the output of the room thermic model and the input of the thermometer in the functional view closes a dependency loop:

Thermic view

T◦

321

Heater

Thermostat

DE

CT

CT Heater (power)

+

DE

Thermostat (power)

DE

Power consumption view

Functional view

Modeling Heterogeneous Points of View with ModHel’X

CT Room

Heater (thermic)

Fig. 9. Model of the thermostat with a dependency cycle

the temperature in the room depends on the output of the thermostat (because it drives the heater), which depends itself on the temperature. However, when the heater is switched on, the temperature does not rise instantaneously, so the dependency cycle is broken by a delay: the output of the thermometer depends on the current room temperature, but the heater acts on the future temperature. Introducing delays in communications between ports is a way of solving the issue of cyclic dependencies. However, we have seen that the semantics of the relations between blocks is determined by a model of computation. Therefore, in general, and for instance on ﬁgure 8, we cannot assume that the models of computation used in view 1, view 2, superp a and superp b all have “propagate with delay” semantics for relations. Another way of considering cyclic dependencies is to regard the cycle as an equation of the form x = f (x), with x the vector of values given to their pins, and to choose the value of the pins in order to solve this equation. The f function represents the behaviors of the blocks and the rules used by the model of computation to combine these behaviors. If the equation has no solution, the model has no behavior. If there are several solutions to the equation, we can either consider

322

F. Boulanger et al.

the model as ill-formed, or pick a random solution (this allows non-deterministic behaviors), or choose a solution according to some criterion (for instance, the smallest or the largest solution according to some order). Indeed, ModHel’X allows cyclic dependencies in models, provided that a solution can be computed by repeated observations of the blocks. With the equation above, this means that ModHel’X allows cyclic dependencies when ∃k0 ∈ N, ∀k ≥ k0 , f k (x0 ) = f k0 (x0 ). Starting from an initial guess x0 for the values of the pins, we repeatedly apply f , which represents the observation of the blocks and the propagation of the observed values according to the relations between pins. When two successive series of observations yield the same values for the pins, a ﬁxed point xf has been reached and gives the behavior of the model for this observation. The ﬁxed point which is reached depends on the individual behavior of the blocks, but also on the model of computation, which determines the order in which blocks are observed, and how the values associated to the pins are propagated according to the relations. When ModHel’X computes the behavior of a model, it relies on the MoC of the model to compute f (x). In our multi-view example, four models of computation are involved (one for each view, and one for each superposition model), so it is much more diﬃcult to determine f , and therefore to ﬁnd its ﬁxed-point, if it exists. We are studying a new version of the execution engine of ModHel’X which observes the structure of multi-view models in order to schedule the observations of their views and superposition models in order to compute the behavior of the whole model as a ﬁxed-point.

6

Comparison with Other Approaches

It has been suggested that consistency among views can be achieved by deﬁning model transformations [18,19]. Indeed, if a view v1 of a system is given in a domain D1 , and if another view v2 is given in another domain D2 , one can apply a transformation t to v1 , such that t(v1 ) is in domain D2 . In this way, one can check in D2 the consistency of {t(v1 ), v2 }. While the conceptual pattern used by these approaches looks like what we do, there is a fundamental diﬀerence. They transform views in order to compare them in a given domain, while our goal is to synchronize the behaviors of the views. Therefore, we do not need to transform the views themselves, we only need to transform the information that the views have to exchange. Transforming information preserves modularity since it requires access to the interface of a view only, not to its internal structure. Work has been done to allow the deﬁnition of correspondences between views. For instance, one can deﬁne correspondences as identity relationships between modeling elements such as UML classes or relations [20,21]. This is valuable when building a model, to enforce consistency at the structural level. However, we do not deal here with structural consistency, but rather with behavioral consistency. In our approach, superposition models enforce consistency of the behavior of views, in the same way as correspondences enforce consistency of the structure of views in the aforementioned frameworks. Behavioral consistency has been studied for ODP views expressed in LOTOS or Z [22], which allows one to express consistency in a formal way. These are

Modeling Heterogeneous Points of View with ModHel’X

323

concrete solutions for views and consistency expressed using speciﬁc models of computations, and they could ﬁt well in our proposal, although we have tried to introduce a more general (but also more abstract) framework.

7

Conclusion

Non-functional aspects of a system can be captured in models which focus on a speciﬁc point of view on the system. Such models often require diﬀerent modeling formalisms or DSMLs because they belong to diﬀerent domains. In consequence, diﬀerent models which represent views on diﬀerent aspects of a system are often heterogeneous. Since non-functional properties may be interdependent (e.g. temperature, dissipated power and clock frequency in a CPU), and may also depend on the functional behavior of the system, it is necessary to model these dependencies so as to ensure the coherence of the diﬀerent models of the system. The approach of multi-view modeling presented in this paper relies on ModHel’X, a framework for heterogeneous modeling and design, to model each view of a system. Each view combines the behavior of components according to the rules of a model of computation which is equivalent to the semantics of a DSML. Components are aggregated into models and a model can be wrapped in a component to give a hierarchical structure to a larger model. In the work presented in this paper, we introduce superposition, a new way of combining components to express the coherence between diﬀerent views of a system. In this approach, a multi-view model of a system consists of several views (which are models of the system built according to diﬀerent points of view), and of superposition models which propagate information between the views in order to ensure their coherence. This approach has the main advantage of reusing the basic mechanisms designed in ModHel’X for hierarchical heterogeneous modeling. It only assumes that a given model can be encapsulated in several interfaces for composition by aggregation and superposition. It therefore provides the base of a uniﬁed framework for building heterogeneous multi-view models in a modular way.

References 1. Boulanger, F., Jacquet, C., Rouis, E., Hardebolle, C.: Modeling Heterogeneous Points of View with ModHel’X. In: Proc. of NFPinDSML2009 (2nd Workshop on Non-functional System Properties in Domain Speciﬁc Modeling Languages at MODELS 2009). CEUR-WS, vol. 553, pp. 1–14 (2009) 2. Boulanger, F., Hardebolle, C.: Simulation of Multi-Formalism Models with ModHel’X. In: Proceedings of ICST 2008, pp. 318–327. IEEE Comp. Soc., Los Alamitos (2008) 3. Clarke, S., Baniassad, E.: Aspect-oriented analysis and design. Addison-Wesley Professional, Reading (2005) 4. Reddy, Y., Ghosh, S., France, R., Straw, G., Bieman, J., McEachen, N., Song, E., Georg, G.: Directives for composing aspect-oriented design class models. In: Rashid, A., Aksit, M. (eds.) Transactions on Aspect-Oriented Software Development I. LNCS, vol. 3880, pp. 75–105. Springer, Heidelberg (2006)

324

F. Boulanger et al.

5. Cahill, V., Clarke, S.: Separation of distributed real-time embedded concerns with theme/UML. In: Proc. of the MOMPES 2008 Conference, pp. 27–33. IEEE, Los Alamitos (2008) 6. Kienzle, J., Al Abed, W., Klein, J.: Aspect-oriented multi-view modeling. In: Proc. of AOSD 2009 (Aspect-oriented software development), pp. 87–98. ACM, New York (2009) 7. Bosch, J.: Superimposition: A component adaptation technique. Information and Software Technology 41(5), 257–273 (1999) 8. van Gurp, J., Smedinga, R., Bosch, J.: Architectural Design Support for Composition & Superimposition. In: Proceedings of The Annual Hawaii International Conference on System Sciences, pp. 287–287 (2002) 9. Espinoza, H., Dubois, H., Gérard, S., Medina, J., Petriu, D., Woodside, M.: Annotating UML models with non-functional properties for quantitative analysis. In: Bruel, J.-M. (ed.) MoDELS 2005. LNCS, vol. 3844, pp. 79–90. Springer, Heidelberg (2006) 10. Attiogbé, J.: Mastering Speciﬁcation Heterogeneity with Multifacet Analysis. In: Proceedings of ICSTW 2008, pp. 121–130. IEEE Comp. Soc., Los Alamitos (2008) 11. Nassar, M.: VUML: a Viewpoint oriented UML Extension. In: Proc of the 18th IEEE Int. Conference on Automated Software Engineering, pp. 373–376 (2003) 12. Benveniste, A., Caillaud, B., Ferrari, A., Mangeruca, L., Passerone, R., Sofronis, C.: Multiple Viewpoint Contract-Based Speciﬁcation and Design. In: de Boer, F.S., Bonsangue, M.M., Graf, S., de Roever, W.-P. (eds.) FMCO 2007. LNCS, vol. 5382, pp. 200–225. Springer, Heidelberg (2008) 13. Kong, C., Alexander, P.: The rosetta meta-model framework. In: Proc. of the IEEE Engineering of Computer-Based Systems Symp. and Workshop, pp. 133–141 (2003) 14. Streb, J., Alexander, P.: Using a lattice of coalgebras for heterogeneous model composition. In: Proc. of the Multi-Paradigm Modeling Workshop (2006) 15. Lee, E., Sangiovanni-Vincentelli, A.: A framework for comparing models of computation. IEEE Transactions on computer-aided design of integrated circuits and systems 17(12), 1217–1229 (1998) 16. Hardebolle, C., Boulanger, F.: Multi-paradigm modeling techniques. SIMULATION: Transactions of The Society for Modeling and Simulation International 85, 688–708 (2009) 17. Eker, J., Janneck, J., Lee, E., Liu, J., Liu, X., Ludvig, J., Neuendorﬀer, S., Sachs, S., Xiong, Y.: Taming heterogeneity – the Ptolemy approach. Proceedings of the IEEE 91(1), 127–144 (2003) 18. ISO/IEC: Reference Model for Open Distributed Processing, Part 3 – Architecture, Chapter 10 – Consistency Rules. In: RM-ODP. ISO/IEC 10746, ITU-T X.901X.904. ISO, Geneva, Switzerland (1997) 19. Boronat, A., Knapp, A., Meseguer, J., Wirsing, M.: What Is a Multi-modeling Language? In: Recent Trends in Algebraic Development Techniques. LNCS, vol. 5486, pp. 71–87. Springer, Heidelberg (2009) 20. Linington, P.: Black Cats and Coloured Birds-What do Viewpoint Correspondences Do? In: Proceedings of the 2007 Eleventh International IEEE EDOC Conference Workshop, pp. 239–246. IEEE Computer Society, Los Alamitos (2007) 21. Romero, J., Jaén, J., Vallecillo, A.: Realizing Correspondences in Multi-Viewpoint Speciﬁcations. In: Procs. of EDOC 2009. IEEE, Los Alamitos (2009) 22. Boiten, E., Bowman, H., Derrick, J., Linington, P., Steen, M.: Viewpoint consistency in ODP. Computer Networks 34(3), 503–537 (2000)

Second Workshop on Transforming and Weaving Ontologies in Model Driven Engineering (TWOMDE 2009) Fernando Silva Parreiras1, Jeﬀ Z. Pan2 , and Uwe Assmann3 1

WeST — Institute for Web Science Technologies, University of Koblenz-Landau Universitaetsstrasse 1, Koblenz 56070, Germany [email protected] 2 Department of Computing Science, The University of Aberdeen Aberdeen AB24 3UE [email protected] 3 Institute for Software- and Multimedia-Technology, TU Dresden D-01062 Dresden, Germany [email protected]

Abstract. The First International Workshop on Transforming and Weaving Ontologies in Model Driven Engineering (TWOMDE 2009), aﬃliated with the 12th International Conference on Model Driven Engineering Languages and Systems (MoDELS2009), brought together researchers and practitioners from the modeling community with experience or interest in MDE and in Knowledge Representation to discuss about how the scientiﬁc and technical results around ontologies, ontology languages and their corresponding reasoning technologies can be used fruitfully in MDE.

1

Introduction

The interest in integrating Ontologies and Software Engineering has gained more attention with commercial and scientiﬁc initiatives. The Semantic Web Best Practice and Deployment Working Group (SWBPD) in W3C included a Software Engineering Task Force (SETF) to explore how Semantic Web and Software Engineering can cooperate. The Object Management Group (OMG) has an Ontology Platform Special Interest Group (PSIG) aiming at formalizing the semantics in software by knowledge representation and related technologies. The concrete results of such initiatives are the speciﬁcation of the OMG Ontology Deﬁnition Metamodel, the OWL2 Metamodel, the introduction to Ontology Driven Architectures and a Semantic Web Primer for Object-Oriented Software Developers. Nevertheless, as MDE spreads, disciplines like model transformation, domain speciﬁc languages (DSLs) and traceability become essential in order to support diﬀerent kinds of models in a model driven environment. Understanding the role S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 325–328, 2010. c Springer-Verlag Berlin Heidelberg 2010

326

F.S. Parreiras, J.Z. Pan, and U. Assmann

of ontology technologies like knowledge representation, automated reasoning, dynamic classiﬁcation and consistence checking in these ﬁelds is crucial to leverage the development of such disciplines. The TWOMDE 2009, aﬃliated with the 12th International Conference on Model Driven Engineering Languages and Systems (MoDELS2009), brought together researchers and practitioners from the modeling community with experience or interest in MDE and in Knowledge Representation to discuss about: (1) how the scientiﬁc and technical results around ontologies, ontology languages and their corresponding reasoning technologies can be used fruitfully in MDE; (2) the role of ontologies in supporting model transformation; (3) and how ontologies can improve designing domain speciﬁc languages. The objective of the workshop was: (1) to present success cases of integrated approaches; (2) to present state-of-the-art researches covering ontologies in MDE; (3) and to encourage the modeling community to explore diﬀerent aspects of ontologies. This report covers an analysis of papers presented in the workshop. For more information, please refer to the Workshop Proceedings1.

2

Program

The workshop was divided in four parts. It started with the invited talk about “Ontologies and Software Modeling: Potentials, Experience and Challenges” following by research papers. Afterwards, the tool presentations took place, followed by a discussion about future applications. Dragan Gasevic gave a keynote talk starting from the main principles of MDE and ontologies, and discussing present achievements and experience gained in various projects and domains [1]. An important topic highlighted in this talk is the lack of tooling for ontology metamodels. Existing tools like Integrated Ontology Development Toolkit do not support completely model driven development of OWL ontologies. A response to that issue is the twouse toolkit, presented later in Sect. 2.2. The talk presented applications of ontologies as shared terminology with the objective of underlying business vocabularies. The main application areas in that matter are software product lines and software requirements. 2.1

Technical Papers

Tobias Walter presented an approach “Towards Semantic Modelling of Network Physical Devices” [2]. The paper analyzes the usage of ontologies in a transparent way by DSL users for consistency checking, and suggestions of suitable domain concepts. The authors claim that ontologies improve DSLs in the following sense: it deﬁnes the formal semantics of the DSL; it uses reasoning, query answering, semantic rules; and ﬁnally, it enriches DSLs by additional constraints. 1

http://ceur-ws.org/Vol-395/

Second Workshop on Transforming and Weaving Ontologies

327

Lothar Hotz applies reasoning technologies to classify software cases in the paper “Mapping MOF-based requirement representations to ontologies for software reuse” [3]. In the paper, the authors describe how to map requirement speciﬁcations into ontologies for identifying the reuse of similar software cases. The characteristics of OWL language allow revealing implicit relations contained in the requirement speciﬁcation. In the third talk, Tobias Walter presented the paper about “Combining ontology-enriched Domain- Speciﬁc Languages” [4]. In that paper, the integration of DSLs and ontology languages allows creating additional (local or global) annotations on DSL domain concepts. These annotations allow to deﬁne constraints and axioms to restrict the usage of concepts in the model and to allow reasoning. The approach presented allows combining modeling languages with existing models and constraints. This approach enables users to verify model correctness by using reasoning technology. Finally, Awny Alnusair presented their approach on “Towards a Model-driven Approach for Reverse Engineering Design Patterns” [5]. It is an ontology-based approach to provide formal, explicit, and semantic-based representation of software design pattern knowledge including an eﬀective model that promotes understanding. As scenario, the paper presents the need for facilitating software reuse by deﬁning skeletons of algorithms in methods. Thus, they use ontology technologies to automatically detect software design patterns. 2.2

Tool Presentation

Fernando Silva Parreiras conducted a presentation of the twouse toolkit. TwoUse Toolkit bridges the gap between Semantic Web and Model Driven Software Development. It is an implementation of current OMG and W3C standards for developing ontology-based software models and model-based OWL ontologies. Using the twouse toolkit, model driven software developers can: – – – – – –

Describe UML classes using OWL class descriptions. Semantically search for classes, properties and instances in UML models. Extent software design patterns with OWL class descriptions. Transform graphical models to OWL2 functional syntax. Make sense of the modeling using inference explanations Write queries using SAIQL, SPARQL, or the SPARQL-DL Functional Syntax using editors with syntax highlighting. – Graphically model OWL ontologies and OWL safe rules using OMG UML Proﬁle for OWL and UML Proﬁle for SWRL. – Graphically model OWL ontologies and OWL Safe Rules using the TwoUse Graphical Editor. The tool has been developed by the Institute for Web Science and Technologies2 and is available for download under the project website3 . 2 3

http://twouse.googlecode.com/ http://west.uni-koblenz.de/twouse

328

3

F.S. Parreiras, J.Z. Pan, and U. Assmann

Conclusion

Although we had papers covering diﬀerent aspects of MDE, the employment of automated reasoning services to make use of the formal description provided by ontology languages has practically not been explored. Moreover, prominent topics in MDE like model transformation and traceability were not pondered by the papers of the previous editions. For the next editions, we expect more use cases in a wider range of topics. We would like to see successful industry use cases and mechanisms to evaluate the role of ontologies.

References 1. Gasevic, D.: Ontologies and software modeling: Potentials, experience and challenges. In: Proceedings of the Second Workshop on Transforming and Weaving Ontologies in Model Driven Engineering (TWOMDE 2009) at MoDELS 2009, Denver, Colorado, USA, October 4. CEUR Workshop Proceedings, CEUR-WS.org, vol. 531 (2009) 2. Miksa, K., Kasztelnik, M., Sabina, P., Walter, T.: Towards semantic modelling of network physical devices. In: Proceedings of the Second Workshop on Transforming and Weaving Ontologies in Model Driven Engineering (TWOMDE 2009) at MoDELS 2009, Denver, Colorado, USA, October 4. CEUR Workshop Proceedings, CEUR-WS.org, vol. 531 (2009) 3. Wolter, K., Smialek, M., Hotz, L., Knab, S., Bojarski, J., Nowakowski, W.: Mapping mof-based requirements representations to ontologies for software reuse. In: Proceedings of the Second Workshop on Transforming and Weaving Ontologies in Model Driven Engineering (TWOMDE 2009) at MoDELS 2009, Denver, Colorado, USA, October 4. CEUR Workshop Proceedings, CEUR-WS.org, vol. 531 (2009) 4. Walter, T., Ebert, J.: Combining ontology-enriched domain-speciﬁc languages. In: Proceedings of the Second Workshop on Transforming and Weaving Ontologies in Model Driven Engineering (TWOMDE 2009) at MoDELS 2009, Denver, Colorado, USA, October 4. CEUR Workshop Proceedings, CEUR-WS.org, vol. 531 (2009) 5. Alnusair, A., Zhao, T.: Towards a model-driven approach for reverse engineering design patterns. In: Proceedings of the Second Workshop on Transforming and Weaving Ontologies in Model Driven Engineering (TWOMDE 2009) at MoDELS 2009, Denver, Colorado, USA, October 4. CEUR Workshop Proceedings, CEUR-WS.org, vol. 531 (2009)

Towards Semantic Modeling of Network Physical Devices Krzysztof Miksa1 , Marek Kasztelnik1 , Pawel Sabina1 , and Tobias Walter2 1

Comarch SA Al. Jana Pawla II 39A, Krakow, Poland {krzysztof.miksa,marek.kasztelnik,pawel.sabina}@comarch.com 2 ISWeb — Information Systems and Semantic Web, Institute for Computer Science, University of Koblenz-Landau Universit¨ atsstrasse 1, Koblenz 56070, Germany [email protected]

Abstract. One of the challenges faced by network management systems is the increasing need for consistent management of physical network equipment. We propose a solution where equipment is modelled using a dedicated Domain Speciﬁc Language (DSL) enriched with the power of logic-based reasoning services. This enables us to deﬁne a rich layer of semantics on top of the structural description of the devices. This way, the conﬁguration related constraints are expressed declaratively, in a platform independent manner, and are managed in an integrated way with the structural model. The information kept in the model can then be used on runtime to give guidance to the system user.

1

Introduction

One of the challenges faced by Next Generation Operation Support Systems (OSS) [1] is the increasing need for consistent management of physical network equipment. In large companies the time consumed by maintaining thousands of devices and ﬁnding solutions to possible problems is constantly on the rise. State-of-the-art technologies enable vendor independent equipment type identiﬁcation and access to the attributes of the component types. Furthermore, current solutions often provide the user with convenient graphical modelling of the physical elements structures, but are usually unable to provide consistent support to the user, by answering questions that involve sophisticated conﬁguration related constraints. In our approach, we propose a solution where equipment is modelled using a dedicated domain speciﬁc language enriched with the power of logic-based reasoning services. This enables us to deﬁne a rich layer of semantics on top of the structural description of the devices. This way, the conﬁguration related

This research has been co-funded by the European Commission and by the Swiss Federal Oﬃce for Education and Science within the 7th Framework Programme project MOST number 216691.

S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 329–343, 2010. c Springer-Verlag Berlin Heidelberg 2010

330

K. Miksa et al.

constraints are expressed declaratively, in a platform independent manner, and are managed in an integrated way with the structural model. The information kept in the model can then be used on runtime to give guidance to the system user.

2

Problem Description

Myriads of device types and their conﬁgurations can make user’s everyday work a nightmare. For example, each time a card in some device is broken, the system operator faces questions like, “what are the possible replacements for that card, are some options better then others?” On the other hand, a system analyst planning new services on a particular device wants to know what components he can use with that device, if possible, from those available in the company’s warehouse. Similar questions may also arise while integrating manually maintained repositories of physical network equipment. In such cases, automatic checking of device conﬁguration correctness or even ﬁnding the exact device type using only information about its conﬁguration, would surely improve the integrity and correctness of existing data. Let’s take an example of a usual situation in telecommunication companies when one of the physical device cards is broken or not supported any longer and requires replacement. Figure 1 presents an example conﬁguration of the Cisco 7603 chassis. It contains two cards. The card in slot 1 is a supervisor card, required by the device to work properly. In slot 2, a backup supervisor card is inserted.

Fig. 1. Example instance of Cisco 7603 conﬁguration in PDIDSL

Let’s suppose that the main supervisor card is broken and requires replacement. The person responsible for this device receives a notiﬁcation about the problem and begins to resolve it. Current solutions of OSS systems require deep knowledge about every sub-component of the physical device (what kind of cards can be used as a replacement for a broken card, what kind of constraints a particular card has, etc.).

Towards Semantic Modeling of Network Physical Devices

331

Fig. 2. Cisco 7603 conﬁguration in PDDSL

To limit the eﬀort required to solve such problems, we designed a DSL that describes the structure of the physical device and stores information about a possible connection between physical device elements. In our example of a simpliﬁed Cisco 7603 from Figure 2, we specify that it has three slots and that the ﬁrst slot is required (marked red in the diagram). The possible or required cards are indicated in blue rectangles next to the respective slots. The description can be enriched with the additional ontology axioms. One of the constraints that occur, is that the Hot Swappable OSM card require a speciﬁc supervisor engine, namely Supervisor engine 720 in the Cisco 7603 conﬁguration. As shown, there is clearly a need for tools providing advanced support helping users make correct decisions, tools based on knowledge and semantics, able to reason and bring meaningful answers for user questions. The problems to address are much more broad than simply suggesting the replacements of a broken card: 1. Network planning - what components can I use with a given conﬁguration of a device to build my service? 2. Consistency checks - is my conﬁguration valid? 3. Data quality - what is the exact type of device, given it’s conﬁguration? 4. Explanations and guidance: Why the conﬁguration is invalid? How can I ﬁx it? Such tools, guiding and supporting users through tedious tasks by answering the questions mentioned, would generate substantial proﬁt, and reduce the number of potential errors in device conﬁgurations. It would also improve productivity, and mitigate the time consumed studying the technical details of a device’s documentation.

3

Integrating Models and Ontologies

To achieve these goals, we follow an approach proposed by our partner in the MOST project, the University of Koblenz-Landau1, based on the idea of 1

http://isweb.uni-koblenz.de

332

K. Miksa et al.

integration of models and ontologies [2]. Modelling physical devices is a perfect candidate to evaluate this idea, and for a reason. Firstly, a network of physical devices can easily be described using a limited number of concepts that makes it a subject of Physical Device Domain Speciﬁc Language (cf. section 4). On the other hand, possible device conﬁgurations and connections build some kind of knowledge base, which would be hard to express using structural models, but are ideal for representing as an ontology. Existing works that compare the ontological and metamodelling technology spaces [3] reveal that hybrid approaches present signiﬁcant advantages over technologies stemming purely from metamodelling space, such as OCL. In the scope of Comarch2 case study in the MOST project3 , our work goes toward extending the expressiveness of the domain speciﬁc language for the description of the physical device structure. This is achieved through integration of Domain Speciﬁc Languages with ontologies, and thus opening new spaces for modelling structure and semantics together. The integrated models remain easy to edit, process, and reasoned about using existing tools and approaches, being a structural and semantic model at the same time.

4

Prototype Solution

A prototype implementation of a physical devices modelling tool was developed using Eclipse Modelling Framework4. The goal of the tool was to enable modelling physical devices in a DSL and, at the same time, take advantage of formal semantics and expressivity of OWL. In this early prototype, the integration of the domains of models and ontologies was achieved by model transformations speciﬁed in QVT Operational [4].

Fig. 3. Conceptual architecture of the prototype 2 3 4

http://www.comarch.com http://www.most-project.eu http://www.eclipse.org/modeling/emf/

Towards Semantic Modeling of Network Physical Devices

333

Fig. 4. PDDSL metamodel excerpt

As shown in Figure 3, the prototype consists of the following artefacts: PDDSL: The Physical Devices Domain Specific Language (PDDSL) enables speciﬁcation of possible conﬁgurations of device models. The language uses concepts related to the structure of devices: Configuration, Slot, Card. Figure 2 gives an example of a model expressed in PDDSL. An excerpt of the metamodel of PDDSL is given in Figure 4. The language has also a concrete textual syntax which, for brevity, is not described in this document. Also, for simplicity, we consider Configuration concept as the direct representation of a physical device type, while in real scenario a device could have multiple alternative conﬁgurations PDIDSL: The Physical Devices Instances Domain Specific Language (PDIDSL) enables deﬁnitions of concrete instances of devices that conform to the PDDSL speciﬁcations. An example of a PDIDSL model is given in Figure 1. As depicted in Figure 3 PDIDSL models conform to a metamodel which is speciﬁed with PDDSL. However, since PDDSL is not a metamodelling language we need an additional step, where some PDDSL model is mapped to an Ecore metamodel. This transformation is not given here for the sake of brievity. An excerpt of the metamodel of PDIDSL is given in Figure 5. OWL: We use OWL Manchester Syntax [5] to represent the OWL ontology. Manchester Syntax was chosen because there already exists an Ecore metamodel for it, and more importantly, generated OWL models can be serialized into valid Manchester Syntax ﬁles without the need for another transformation (as in case of Ontology Data Model) using EMFText tool5 . 5

http://www.emftext.org

334

K. Miksa et al.

Fig. 5. PDIDSL metamodel excerpt

OWL extensions: Additional knowledge related to physical devices is deﬁned in OWL Manchester Syntax. Section 4.4 describes an example of such an ontology. Reasoner: We use Pellet to perform reasoning in the prototype. Examples for reasoning are given in Section 4.5. PDDSL2OWL: A QVT operational transformation transforms PDDSL models into an OWL T-box. It is further described in Secion 4.1. PDIDSL2OWL: A QVT operational transformation transforms PDIDSL models into an OWL A-box. It is further described in Secion 4.2. In the modeling domain the languages conceptually form the following hierarchy: M3 level: Ecore metametamodel M2 level: PDDSL metamodel deﬁning the language needed to describe possible conﬁgurations of devices M1 level: PDDSL models describing the possible conﬁgurations of a device. PDIDSL metamodel deﬁning the language needed to describe concrete conﬁgurations of devices M0 level: PDIDSL model represents concrete conﬁgurations 4.1

Transforming Type Model

The goal of the PDDSL2OWL transformation is to extract the OWL T-box from the PDDSL models. The transformation maps the concepts of the PDDSL into OWL classes and properties and, equally important, speciﬁes formal semantics of the concepts from PDDSL (e.g. formalization of conﬁguration constraints). Figure 6 shows an excerpt of the transformation where an object property restriction is generated for the Configuration class. Each of the required slots

Towards Semantic Modeling of Network Physical Devices

-- configuration is mapped to subclass of Configuration -- with equivalency axiom mapping Configuration::toConfiguration() : OWL::Class { equivalentClassesDescriptions += object Conjunction { primaries += object ClassAtomic{clazz := ConfigurationClass}; -- condition on required cards primaries += self.slots [cardRequired = true] -> map toSlotRequiredRestriction(); -- Another restrictions (not listed here): ... } } -- required cards - configuration has _some_ of the cards -- specified in required slots mapping Slot::toSlotRequiredRestriction() : OWL::NestedDescription { description := object ObjectPropertySome { feature := hasSlotProperty; primary := object NestedDescription { description := object Conjunction { primaries += object ObjectPropertySome { feature := hasCardProperty; primary := object ClassAtomic{ clazz := self.cards -> first().map toCardCategory()} }; --slot number primaries += object ObjectPropertyValue { feature := idProperty; _literal := object IntegerLiteral { value := self.id.toInteger() } } } } } } Fig. 6. Excerpt of T-box generation in PDDSL2OWL transformation

335

336

K. Miksa et al.

in the Configuration is mapped to an ObjectPropertySome restriction on the hasSlot property. The property is restricted to a conjunction of restrictions on the hasCard property. Each of the restrictions in the conjunction speciﬁes the required card and value restriction on the id data property indicating the slot number. 4.2

Transforming Instance Model

The PDIDSL2OWL transformation takes as input a model containing the instances of physical devices expressed in PDIDSL and extracts the respective OWL A-box. The transforation updates the ontology T-box produced by the PDDSL2OWL transformation by adding individuals along with the respective facts assertions. Figure 7 shows an excerpt from the transformation where an instance of Configuration is transformed into an OWL individual. The type of the individual is set to the corresponding OWL class, representing the conﬁguration, and the respective slots are related by the hasSlot property. mapping Configuration::toConfigurationIndividual(): OWL::Individual { iri := self.name; types += object ClassAtomic { clazz := classes[iri = self.metaClassName()] -> asSequence() -> first(); }; self.hasSlot -> forEach (i) { facts += object ObjectPropertyFact{ objectProperty := hasSlotProperty; individual := i.map toSlotIndividual(); } }; } Fig. 7. Excerpt of A-box generation in PDIDSL2OWL transformation

4.3

Closing the World

The reasoning tasks performed on models, such as consistency checking, often require non-monotonic reasoning [6] (e.g. Close World Assumption). In contrast, OWL adopts Open World Assumption. Therefore it is necessary to be able to close the knowledge explicitly, e.g. by adding the respective axioms to the ontology. which is done in our prototype automatically by PDIDSL2OWL transformation. One of the means of closing knowledge is to state that a class is equivalent to an enumeration of all of its known individuals (domain closure). An update mapping that closes the world of any class with known individuals, is speciﬁed in Figure 8.

Towards Semantic Modeling of Network Physical Devices

337

mapping inout OWL::Class::updateClass() { self.equivalentClassesDescriptions += object IndividualsAtomic { individuals += PDmodel.objects() [metaClassName() = self.iri] .resolve().oclAsType(OWL::Individual); } } Fig. 8. Inout mapping closing an OWL class

4.4

Enriching with Additional Statements

The prototype allows for enriching the physical devices ontology with additional axioms, not to limit the whole solution to the expressiveness of the DSLs. Currently these axioms are speciﬁed in a separate OWL ﬁle that references the extracted ontology through a namespace declaration. As shown in Figure 3, to perform the reasoning tasks both OWL ﬁles automatically generated from models and manually written extension ﬁle are needed by the reasoner. The ﬁles are kept separate in order to prevent overwriting manual changes after rerunning the transformations. Figure 9 gives an example of an extension, by specifying that HotSwappable OSM cards in Cisco7603 are only allowed with Supervisor engine 720. Namespace: pd Ontology: Class: pd:Cisco7603Configuration SubClassOf: ((pd:containsCard some pd:Hot_Swappable_OSM) and (pd:containsCard some pd:Supervisor_engine_720)) or (pd:containsCard only (not (pd:Hot_Swappable_OSM))) Fig. 9. Additional axioms

4.5

Reasoning with the Resulting Ontology

The extracted ontology together with extensions are the artefacts that constitute the input to the reasoner. The prototype allows for various types of reasoning, e.g. classiﬁcation and consistency checking. We use classiﬁcation to detect the exact type of a conﬁguration individual, in order to support elaboration of partially incomplete models, which is the often case in physical devices management. Consistency checking was also successfully applied in order to detect and prevent errors in devices conﬁgurations. In the remainder of this section we provide an example of classiﬁcation and consistency check in the physical devices ontology. The examples diﬀer in A-box axioms but use the same T-box. In Figure 10 the basic concepts of the ontologies are deﬁned: Configuration, Slot, Card classes. A Configuration may contain multiple Slots (via the hasSlot property), while

338

K. Miksa et al.

a Slot may contain only one Card (via the hasSlot property). Additionally, the slots may be identiﬁed with an id property. Slot and Card classes are closed by enumerating all of their individuals.

Class: Configuration Class: Slot EquivalentTo: {cisco1_slot_3, cisco1_slot_2, cisco1_slot_1} Class: Card EquivalentTo: {supervisor_2_2, HS_OSM_1, supervisor_720_1, supervisor_720_3, H_OSM_2, supervisor_2_1, supervisor_2_3, spa_1} ObjectProperty: hasSlot Domain: Configuration Range: Slot Characteristics: InverseFunctional ObjectProperty: hasCard Domain: Slot Range: Card Characteristics: InverseFunctional , Functional DataProperty: id Domain: Slot Characteristics: Functional Fig. 10. Basic concepts in the generated ontology

Figure 11 shows another part of the T-box where speciﬁc types of Cards are deﬁned. Each of the speciﬁc Card classes is closed by enumerating all of its individuals. Additionally, the respective Card subclasses are declared disjoint (not depicted in ﬁgure 11). The class representing the allowed Cisco 7603 conﬁguration is speciﬁed in Figure 12. The class is generated as equivalent to an anonymous class that brings together all of the restrictions generated from PDDSL model, i.e.: 1. Cardinality restriction on hasSlot property - the conﬁguration has exactly the number of slots speciﬁed in PDDSL. 2. Restriction on the required cards - the conﬁguration has to contain cards speciﬁed in the slots marked as required in PDDSL. 3. Restriction on the optional cards - the conﬁguration cannot contain other cards than those speciﬁed in PDDSL. The mappings for the ﬁrst and third constraint are given in Figure 6. E.g. toSlotRequiredRestriction mapping generates restriction on the required cards.

Towards Semantic Modeling of Network Physical Devices

339

Class: Supervisors SubClassOf: Card Class: Hot_Swappable_OSM SubClassOf: Card EquivalentTo: { HS_OSM_1 , H_OSM_2 } Class: SPA_interface_processors SubClassOf: Card EquivalentTo: { spa_1 } Class: Supervisor_engine_2 SubClassOf: Supervisors EquivalentTo: {supervisor_2_1, supervisor_2_2, supervisor_2_3} Class: Supervisor_engine_720 SubClassOf: Supervisors EquivalentTo: {supervisor_720_1, supervisor_720_3}

Fig. 11. Card types in the generated ontology

Class: Cisco7603Configuration EquivalentTo: Configuration and # cardinality restriction on slots: hasSlot exactly 3 Slot and # required cards restriction: (hasSlot some (hasCard some Supervisors and id value 1)) and #optional card restriction: (hasSlot only (((hasCard some Supervisors and id value 1)) or ((hasCard some Supervisors and id value 2) or (hasCard some Hot_Swappable_OSM and id value 2)) or ((hasCard some Hot_Swappable_OSM and id value 3) or (hasCard some SPA_interface_processors and id value 3))))

Fig. 12. Allowed Cisco 7603 conﬁguration in the generated ontology

Let us now consider the example of a conﬁguration depicted in Figure 13. The model contains a conﬁguration with three slots. Each of the slots contains a card. The model does not specify the speciﬁc type of the conﬁguration (cisco1 is an instance of the generic class Configuration). As a consequence, it is not clear what is the speciﬁc type of the device. In the generated ontology A-box, this model is represented by the set of individuals, speciﬁed in Figure 14. The A-box excerpts in this section omit the

340

K. Miksa et al.

Fig. 13. Example instance of conﬁguration in PDIDSL

Individual: cisco1 Types: Configuration Facts: hasSlot slot_1, hasSlot cslot_2, hasSlot slot_3 Individual: slot_1 Types: Slot Facts: hasCard supervisor_2_1, id 1 Individual: slot_2 Types: Slot Facts: hasCard supervisor_2_3, id 2 Individual: slot_3 Types: Slot Facts: hasCard spa_1, id 3

Fig. 14. Individuals representing an instance of device conﬁguration

declarations of each card individuals for the sake of brevity, since all of them are listed in the EquivalentTo axioms of the respective classes in Figure 11. Using the deﬁnitions from the T-box the cisco1 individual can be classiﬁed as Cisco7603Configuration (see Figure 12 for the relevant constraints). Then, this inference could be used to provide guidance to the user of PDIDSL, i.e. suggest to change the type of cisco1 to Cisco7603Configuration. Let us now consider an example where we use consistency checking to prevent illegal conﬁgurations. Figure 15 depicts an example of Cisco7603Configuration. The conﬁguration is invalid since the required Supervisors card is missing in slot 1.

Towards Semantic Modeling of Network Physical Devices

341

Fig. 15. Example of inconsistent instance of conﬁguration in PDIDSL

The A-box axioms generated from this model are listed in Figure 16. Given the restrictions speciﬁed in Figure 12, the reasoner can detect the inconsistency (i.e the required card restriction does not hold). This fact then could be reported to the user by marking the inconsistent elements in the model and providing explanation of the reason of inconsistency. Moreover, employing more sophisticated reasoning services, the user could also get some guidance in form of suggestions what to change in the model in order to ﬁx it.

Individual: cisco1 Types: Cisco7603Configuration Facts: hasSlot slot_1, hasSlot slot_2, hasSlot slot_3 Individual: slot_1 Types: Slot Facts: hasCard HS_OSM_1, id 1 Individual: slot_2 Types: Slot Facts: hasCard supervisor_2_3, id 2 Individual: slot_3 Types: Slot Facts: hasCard spa_1, id 3

Fig. 16. Individuals representing an inconsistent instance of device conﬁguration

5

Related Work

In [7], a transformation from UML+OCL to Alloy is proposed. The approach shows how Alloy can be adopted for consistency checking of UML models.

342

K. Miksa et al.

F-Logic is a further prominent rule language that combines logical formulas with object oriented and frame-based description features. Diﬀerent works (e.g. [8,9]) have explored the usage of F-Logic to describe conﬁgurations of devices or the semantics of MOF models. In general, the above approaches only provide the expressiveness of MOF+OCL because its conforming models are directly transformed into a knowledge representation like Alloy or F-Logic. Our approach provides also a transformation from domain models to OWL ontologies but in addition allows enriching the OWL ontology by additional statements. Thus we can enhance the expressiveness of constraints to be checked. [10] and [11] present combined approaches. In [11] a methodology to combine DSLs and ontology languages using metamodel integration is presented. Result is an integrated metamodel which allows building domain models and simultaneously annotating model elements with OWL statements, which are directly embedded into the model. In [10] a technical space is presented which allows developing EMOF based metamodels with integrated constraints using the ontology language OWL2. [12] explains characteristics of conﬁgurations with description logics (DLs) that make DLs well suited for deﬁning conﬁgurations. Our approach and the prototype comply some of the deﬁned requirements of a conﬁguration application. For instance, we provide based on the exported ontology inferencing and knowledge completion, explanations, inconsistency detection, error handling and some more features. Furthermore we support object-oriented modeling and extensible schemas, which is possible by using and extending the PDDSL metamodels. In [12] the representation of rules is desired, which leads us to the idea to improve our approach and prototype (e.g. taking beneﬁts of SWRL).

6

Summary and Outlook

Even though ontologies in computer science have been used for a long time, integration with domain speciﬁc languages is a early innovation in the ﬁeld of data modelling. The problems described and appearing in everyday tasks are of an abstract nature and cannot easily be solved using existing tools and approaches. Introducing integrated models containing structure and semantic information will surely be a great advantage, and will lead to the improvement of existing systems, making them more user-friendly. The presented usage scenario serves as a proof of concept for ontology enriched prmodelling. Initial results have already proved its usefulness. However, the prototype implementation presented in this paper does not fully take advantage of the integrated approach. The ontology is fully extracted by the means of model transformation, and only then it can be extended with additional constraints. This means that models and additional axioms have to be managed separately. In our future work in the MOST project, we will investigate how we can use the language integration approach to mitigate this shortcoming. The idea is to take proﬁt from both approaches described in Section 5, and to allow an integrated modelling of additional OWL axioms within PDDSL models.

Towards Semantic Modeling of Network Physical Devices

343

This would not only solve the problem of eﬀective management of the models, but also improve the understanding of the relationship between the concepts from the two worlds. In general, it is assumed that large majority of models can be described using pure PDDSL constructs, while only limited number of uncommon cases require use of OWL extensions, thus OWL expertise would be required only for some of the users. When this extensions come into play in the integrated modelling could provide such users with understanding about the OWL meaning of PDDSL concepts without knowing the details of PDDSL2OWL transformations.

References 1. Fleck, J.: Overview of the Structure of the NGOSS Architecture (2003) 2. Silva Parreiras, F., Staab, S., Winter, A.: TwoUse: Integrating UML Models and OWL Ontologies. Technical Report 16/2007, Universit¨ at Koblenz-Landau, Fachbereich Informatik (2007) 3. Parreiras, F.S., Staab, S., Winter, A.: On marrying ontological and metamodeling technical spaces. In: ESEC-FSE 2007: Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering, pp. 439–448. ACM, New York (2007) 4. OMG: MOF QVT Final Adopted Speciﬁcation (2005), http://www.omg.org/docs/ptc/05-11-01.pdf 5. Horridge, M., Patel-Schneider, P.F.: OWL 2 Web Ontology Language Manchester Syntax. Technical report (2009), http://www.w3.org/TR/owl2-manchester-syntax/ 6. Dam´ asio, C.V., Analyti, A., Antoniou, G., Wagner, G.: Supporting Open and Closed World Reasoning on the Web. In: Alferes, J.J., Bailey, J., May, W., Schwertel, U. (eds.) PPSWR 2006. LNCS, vol. 4187, pp. 149–163. Springer, Heidelberg (2006) 7. Anastasakis, K., Bordbar, B., Georg, G., Ray, I.: UML2Alloy: A challenging model transformation. In: Engels, G., Opdyke, B., Schmidt, D.C., Weil, F. (eds.) MODELS 2007. LNCS, vol. 4735, pp. 436–450. Springer, Heidelberg (2007) 8. Sure, Y., Angele, J., Staab, S.: OntoEdit: Guiding ontology development by methodology and inferencing. LNCS, pp. 1205–1222. Springer, Heidelberg 9. Gerber, A., Lawley, M., Raymond, K., Steel, J., Wood, A.: Transformation: The Missing Link of MDA. In: Corradini, A., Ehrig, H., Kreowski, H.-J., Rozenberg, G. (eds.) ICGT 2002. LNCS, vol. 2505, pp. 90–105. Springer, Heidelberg (2002) 10. Walter, T., Silva Parreiras, F., Staab, S.: OntoDSL: An Ontology Based Developement Environment for Domain-Speciﬁc Languages. In: Sch¨ urr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 408–422. Springer, Heidelberg (2009) 11. Walter, T., Ebert, J.: Combining DSLs and Ontologies using Metamodel Integration. In: Taha, W.M. (ed.) Domain-Speciﬁc Languages. LNCS, vol. 5658, pp. 148–169. Springer, Heidelberg (2009) 12. Baader, F., Calvanese, D., McGuinness, D., Nardi, D., Patel-Schneider, P.: The description logic handbook: theory, implementation, and applications. Cambridge University Press, New York (2003)

Using Ontology Reasoning for Reverse Engineering Design Patterns Awny Alnusair and Tian Zhao Department of Electrical Engineering and Computer Science University of Wisconsin-Milwaukee, USA {alnusair,tzhao}@uwm.edu

Abstract. Capturing design knowledge in large software systems reduces the complexity of understanding and reusing these systems. Model Driven Engineering (MDE) is seen by many as the new trend to cope with software complexity. MDE promotes the notion of modeling and model transformations in model-driven development. In this paper, we propose an approach that utilizes ontological modeling and reasoning for recovering design pattern information from source code. We thus provide a formal representation of the conceptual knowledge found in source code and match it to similar representation of design patterns. This proper matching is the basis for applying semantic reasoning to infer design pattern instances. We have tested our approach on multiple open source application frameworks. The results we obtained are promising and show an improvement in terms of recall and precision. Keywords: Semantic Reasoning, Software Ontology, Design Patterns, Program Understanding, Knowledge Representation.

1

Introduction

In Software Engineering practices, software understanding deals with the process of studying software to mentally conceptualizing its behavior and inner working structure. Unfortunately, understanding voluminous and complex software is widely regarded as the most time consuming and resource intensive activity during both reverse and forward engineering practices. In order to cope with software complexity and consequently enable better understanding of software, Model Driven Engineering (MDE) has emerged as a software engineering discipline. MDE emphasizes the systematic use of models and modeling principles throughout the software development lifecycle. In fact, software design and design best practices (i.e., design patterns) are of particular relevance to MDE due to the heavy reliance on modeling techniques and principles. Design patterns describe reusable solutions to common recurrent objectoriented design problems. The classic book [1] of design patterns introduced many of these patterns. Ever since then, these patterns have been liberally used in building and documenting new object-oriented systems as well as reengineering legacy software. It is thus evident why one would be interested in reverse engineering approaches for design pattern instance recovery. S. Ghosh (Ed.): MODELS 2009 Workshops, LNCS 6002, pp. 344–358, 2010. c Springer-Verlag Berlin Heidelberg 2010

Using Ontology Reasoning for Reverse Engineering Design Patterns

345

Central to all reverse engineering activities is the accurate identiﬁcation of interrelationships among the components of a subject system as well as a true representation of the system at a higher level of abstraction [2]. As a typical reverse engineering activity, design pattern recovery is no exception. However, building an eﬀective model that promotes understanding and truly represents the internal working structure and organization of a software system is not a straight forward task; it requires a formal, explicit, and semantic-based representation of the conceptual knowledge of source code artifacts found in the subject system. The research presented in this paper explores this hypothesis by providing ontological representations of software assets. In our further exploration of this hypothesis, we take into account modeling principles and techniques from Model Driven Engineering. MDE promises full support for reverse engineering activities through modeling and model transformations at diﬀerent levels of abstractions. Due to the formal and built-in reasoning foundations of ontologies, our methodology is solely reliant on ontology-based modeling. Therefore, we provide an OWL1 ontology model that includes a software representation ontology; this ontology is automatically populated through text-to-model transformation with ontological instances representing various program elements of a subject system. Furthermore, each design pattern’s structure including its participants’ behaviors and collaborations are represented by a separate OWL ontology; this ontology also encodes the rules needed to detect this particular pattern. We organize the rest of the paper as follows. In Sect 2, we describe our approach for structuring and populating the knowledge base. We discuss the details of design pattern detection in Sect 3. Implementation and evaluation case studies are discussed in Sect 4. Finally, a discussion of the current state-of-the-art followed by future work directions are discussed in Sect 5 and Sect 6, respectively.

2

Ontology Model

Due to their ability to enable automatic knowledge sharing and understanding, ontologies are being used as the knowledge representation component of the Semantic Web vision [3]. To this end, many ontology modeling languages and Semantic Web technologies have emerged and been used in various domain areas. In our work, we utilize the Web Ontology Language (OWL), the Resource Description Framework (RDF)2 , the Semantic Web Rule Language (SWRL)3 , and SPARQL4 query language. OWL is used for capturing relationship semantics among domain concepts, OWL-DL is a subset of OWL based on Description Logic and has desirable computational properties for reasoning systems. OWL-DL’s reasoning support 1 2 3 4

http://www.w3.org/TR/owl-guide/ http://www.w3.org/TR/rdf-primer http://www.w3.org/Submission/SWRL http://www.w3.org/TR/rdf-sparql-query

346

A. Alnusair and T. Zhao

allows for inferring additional knowledge and computing the classiﬁcation hierarchy (subsumption reasoning). RDF is used as a ﬂexible data representation model. RDF is suitable for describing resources and provides a data model for representing machine-processable semantics of data. SWRL is used for writing rules that can be combined with OWL knowledge bases for reasoning and computing entailments. Finally, SPARQL is an RDF query language and protocol for ontological querying of RDF graphs. In what follows, we describe how Semantic Web languages contribute to our methodology; in particular, we show how OWL-DL and RDF are used to obtain a precise formal representation of source code knowledge and design patterns. We also show how SWRL rules can be used to further extend the OWL representation of design patterns to handle features that cannot be expressed using OWL alone. Collectively, these representations form the base for semantic reasoning and inference of additional facts that can be retrieved using SPARQL semantic queries. 2.1

Structuring the Knowledge Base

At the core of the ontology model is a Source Code Representation Ontology (referred to afterwards as SCRO). This ontology is created to provide an explicit representation of the conceptual knowledge structure found in source code. SCRO captures major concepts of object-oriented programs and helps understand the relationships and dependencies among source code artifacts. SCRO’s knowledge is represented using the OWL-DL ontology language and veriﬁed using the Pellet OWL-DL reasoner [4]. It was designed with ontology reuse in mind, such that its vocabulary can be used not only for design pattern detection but also in any application that requires semantic source code information. This ontology is a work in progress, currently focused on the Java programming language; however, extensions for other object-oriented languages can be easily obtained. A fragment of the ontology’s taxonomy using the Prot´eg´e [5] ontology editor is shown in Fig. 1 and the complete ontology can be found online [6]. Each of the concepts (classes) shown in Fig. 1 is interpreted as a set that deﬁnes a group of individuals (instances) sharing some properties. Disjoint subclasses are also modeled to deﬁne diﬀerent sets of individuals. For example, all individuals that are members of class InstanceMethod are necessarily members of class Method but none of them can simultaneously be a member of another subclass of Method. Currently SCRO deﬁnes 56 OWL classes and subclasses. Those classes map directly to source code elements and collectively represent the most important concepts found in object-oriented programs such as method, class, nested class, and ﬁeld. Various object properties, sub-properties, and ontological axioms are deﬁned within SCRO to represent relationships among concepts by linking individuals from diﬀerent OWL classes. For example, hasOutputType is a functional property deﬁned for the return type of a method and hasSuperType is a transitive object property deﬁned with two transitive sub-properties for inheritance

Using Ontology Reasoning for Reverse Engineering Design Patterns

347

Fig. 1. Excerpt of SCRO class hierarchy

and interface implementation. Inverse properties are also used to deﬁne the inverse relation. For example, isLocalVariableOf is the inverse property of hasLocalVariable. This is in particular useful in many situations such as traversing the resulted RDF graph in both directions and making the ontology useful for applications that do not depend on a reasoner system. Currently, SCRO deﬁnes 73 object properties, sub-properties and data properties. Some of these properties are further discussed in Sect 3. 2.2

Design Pattern Ontology Sub-model

In order to properly represent a design pattern, a proper identiﬁcation of its participating classes, their instances, roles, and collaborations is indeed essential. We thus reuse the vocabulary deﬁned in SCRO and build deﬁnitions for each design pattern. The result is a modular extensible structure of OWL ontologies linked together via regular OWL reuse mechanisms. This structure is depicted in Fig. 2. The design-pattern ontology represents knowledge common to all design patterns. An ontology is created for each design pattern describing its essential participants and their properties, collaborations, restrictions, and the corresponding

348

A. Alnusair and T. Zhao

SCRO Design-Pattern

Singleton

Observer

Composite

Visitor

.....Others

Fig. 2. Modular structure of design pattern ontologies linked via owl:imports

SWRL rules needed to detect this pattern. This modular structure promotes ontology reuse, thus allowing SCRO to be used with various maintenance related activities and certainly with reasoners that do not support SWRL rules. Having the ontology structure created, the next natural step is to populate the knowledge base with ontological instances of various concepts in the ontology. This process is described next. 2.3

Automatic Knowledge Population

Populating knowledge repositories requires binding concrete resource information with the ontology to create instances of ontological concepts. These instances are the building blocks of the knowledge base that can be used for browsing and querying. When dealing with large source code repositories, a large number of instances is usually created, this is why automatic text-to-model transformation and knowledge population is essential. Inspired by the Java RDFizer idea from the Simile5 project, we have built a subsystem that automatically extracts knowledge from Java binaries. The original RDFizer was able to distinguish only class types, super types, and basic use relations represented in a class ﬁle. Currently, our subsystem performs a comprehensive parsing of the class ﬁle format speciﬁed by the Java Virtual Machine. It captures every ontology concept that represents a source code element and eﬀectively generates instances of all ontological properties deﬁned in our ontologies for those program elements. Our knowledge generator subsystem distinguishes itself as not being relied on the existence of source code to extract knowledge. This is in particular helpful for binary reverse engineers who must understand a software system in which the source code is unavailable. The semantic instances generated by our subsystem are serialized using RDF triples; a separate RDF ontology in Notation36 syntax is generated for each application framework parsed, this amounts to instantiating an OWL knowledge base for that framework. This arrangement provides a clean separation of explicit OWL vocabulary deﬁnitions from the metadata represented by RDF. Since OWL 5 6

http://simile.mit.edu http://www.w3.org/DesignIssues/Notation3

Using Ontology Reasoning for Reverse Engineering Design Patterns

349

is a vocabulary extension of RDF, the encoded metadata represented in RDF can be naturally linked to the OWL design pattern ontologies via OWL reuse mechanisms. A sample output of our knowledge extractor subsystem for the JHotDraw7 application framework can be examined online [6].

3

Design Pattern Recovery Approach

Due to their abstract nature and the varying responsibilities and interactions of their participants, design patterns can generally be implemented in diﬀerent ways and using diﬀerent techniques or language-speciﬁc constructs. Examples of such implementation variations are plenty. Consider object composition for example, some systems do not use a built-in collections framework component for maintaining an aggregate collection of objects. Instead, they use a user-deﬁned data structure. Other systems favor some delegation techniques over the others when implementing design patterns such as Visitor, State, and Strategy. We thus believe that pattern detection tools should be ﬂexible and easily extensible to improve usability and eﬀectiveness, that is, the roles and interactions of participants should not be hard-coded. In fact, users of the detection tool often need to change those hard-coded role restrictions but ﬁnd it extremely diﬃcult because it requires code modiﬁcation and rebuilding the entire tool. In our approach, we aim at providing ﬂexibility and transparency such that design patterns are speciﬁed externally using ontology formalisms and participant’s responsibilities are depicted using ontology rules that can be easily understood and modiﬁed. We thus use the expressivity of OWL-DL and SWRL rules to formally represent each design pattern using a set of intent-preserving conditions. When these conditions are collectively met, an instance of the design pattern is detected. This approach relies solely on the deﬁnitions found in our ontologies and on an OWL-DL reasoner that is capable of computing inferences from the set of facts and SWRL rules deﬁned in the ontologies. To test the validity of our approach, we authored SWRL rules for ﬁve well-known design patterns, namely, Visitor, Observer, Composite, Template-Method, and Singleton. In the next subsections, we illustrate our detection mechanism for Visitor and Observer. Since SWRL rules are part of the OWL ontology representing a particular design pattern, the reader can examine the rules for the other three patterns by downloading the corresponding ontology [6] and view it in an ontology editor such as Prot´eg´e. Note that our approach is not limited to these ﬁve design patterns, others can be easily formalized and thus detected using the same procedure. 3.1

Detecting the Visitor Design Pattern

Visitor is a behavioral design pattern that facilitates ﬂexibility by allowing external operations to be performed on the elements of an object structure and hence not modifying the classes of the elements [1]. The idea is to keep the object 7

http://www.jhotdraw.org

350

A. Alnusair and T. Zhao

structure intact by deﬁning new structures of visitors representing the new behaviors of interest. This pattern deﬁnes two separate class hierarchies: Host and Visitor. The following are three sample conditions for detecting this pattern: 1. At the root of the Visitor hierarchy is a Visitor interface common to all concrete visitors; this interface declares the invariant abstract behaviors (visit methods) that should be implemented by each ConcreteVisitor, since each visit method is designed for a ConcreteHost, the concrete host must be present as an argument (input type) in the corresponding visit method. 2. A ConcreteVisitor is a concrete class type that implements the Visitor interface and overrides each visit method to implement visitor-speciﬁc behavior for the corresponding ConcreteHost. 3. A ConcreteHost must deﬁne the accept instance method that takes Visitor as an argument. This method implements the double dispatching technique by calling the matching visit method and passing the host object into the visitor. Intuitively, we should take advantage of OWL-DL expressivity to formalize the above restrictions. However, these restrictions require more expressive power than what Description Logic provides. OWL can only handle descriptions of inﬁnite number of unstructured objects connected in a tree-like manner [7]. We thus use SWRL to handle all non-tree-like situations and property chaining for design pattern restrictions. SWRL extends OWL-DL with First Order Horn-like rules; a rule in SWRL has two parts: the antecedent and the consequent, each of these parts contain only positive conjunctions of either unary or binary atoms. In its simple form, a unary atom represents an OWL class predicate of the form C(var1) and a binary atom represents an OWL property predicate of the form P(var1, var2), both var1 and var2 are variables over OWL individuals. The reasoner will carry out the actions speciﬁed in the consequent only if all the atoms in the antecedent are known to be true. Listing 1 shows a sample SWRL rule that depicts the above conditions for the visitor design pattern. Please refer to SCRO and the visitor ontology found online [6] for the deﬁnitions of OWL properties used in this rule. Every restriction was formalized using three diﬀerent atoms in the rule; the hasInputType OWL object property is deﬁned in SCRO to represent a method’s formal parameter and methodOverrides works for both method overriding and interface method implementation. Upon classifying the ontology, a reasoner with a rule engine such as Pellet would infer and thus create instances for the diﬀerent participants of this design pattern as described in the consequent part of the rule. scro : InterfaceType (? visitor ) ∧ scro : hasAbstract M et ho d (? visitor , ? visit ) ∧ scro : hasInputType (? visit , ? concrete - host ) ∧ scro : hasSuperType (? concrete - visitor , ? visitor ) ∧ scro : hasInstance M et ho d (? concrete - visitor , ?c - visit ) ∧ scro : methodOverri de s (? c - visit , ? visit ) ∧

Using Ontology Reasoning for Reverse Engineering Design Patterns

351

scro : hasInstance M et ho d (? concrete - host , ? accept ) ∧ scro : hasInputType (? accept , ? visitor ) ∧ scro : invokesMethod (? accept , ? visit ) =⇒ visitor : Visitor (? visitor ) ∧ visitor : hasConcret eV i si t or (? visitor , ? concrete - visitor ) ∧ visitor : hasConcreteH o st (? visitor , ? concrete - host ) ∧ visitor : hasVisitMeth od (? concrete - visitor , ?c - visit ) ∧ visitor : hasAcceptMet h od (? concrete - host , ? accept ) Listing 1. A sample SWRL rule for Visitor

Relaxing or adding more restrictions to the requirements is relatively simple. For the sake of argument, one might want to retrieve only pattern instances that declare a super type for all concrete hosts in the Host hierarchy. This can be accomplished by modifying the third condition and introducing a fourth condition as shown below. The result is a new rule depicted in Listing 2. 3. A ConcreteHost is a subtype of Host. It deﬁnes the accept instance method that overrides the hook method found in Host. This method implements double dispatching by calling the matching visit method and passes the host in to the visitor. 4. At the root of the Host hierarchy is an interface or abstract class type. It represents the super type of all concrete hosts. It declares the abstract hook method; this method takes Visitor as an argument. scro : InterfaceType (? visitor ) ∧ scro : hasAbstract M et ho d (? visitor , ? visit ) ∧ scro : hasInputType (? visit , ? concrete - host ) ∧ scro : hasSuperType (? concrete - visitor , ? visitor ) ∧ scro : hasInstance M et ho d (? concrete - visitor , ?c - visit ) ∧ scro : methodOverri de s (? c - visit , ? visit ) ∧ scro : hasSuperType (? concrete - host , ? host ) ∧ scro : hasAbstract M et ho d (? host , ? hook ) ∧ scro : hasInputType (? hook , ? visitor ) ∧ scro : hasInstance M et ho d (? concrete - host , ? accept ) ∧ scro : methodOverri de s (? accept , ? hook ) ∧ scro : invokesMethod (? accept , ? visit ) =⇒ visitor : Visitor (? visitor ) ∧ visitor : hasHost (? visitor , ? host ) .......... .. . . .. . .. . Listing 2. A modified SWRL rule for Visitor

352

3.2

A. Alnusair and T. Zhao

Detecting the Observer Design Pattern

Observer represents a one-to-many dependency between communicating objects such that when the subject object changes its state, it sends a notiﬁcation message to all its listeners to be updated accordingly. Unlike the Composite pattern, Observer is implemented in two separate hierarchies of participants. An interface for all listeners sits at the root of the listener’s hierarchy; it identiﬁes a common behavior for all listeners interested in observing a particular subject such that each concrete listener maintains a reference to that particular subject. On the other hand, the subject knows its listeners, it provides means to establishing the relationship with them, and it is responsible for communicating the behavior change to all those registered listeners. Listing 3 shows sample rule representations of this pattern. The ﬁrst rule identiﬁes candidates for potential listeners, their concrete listeners and the corresponding update methods. scro : hasSuperType (? c - listener , ? listener ) ∧ scro : hasMethod (? listener , ? update ) ∧ scro : methodOver ri d de n By (? update , ?c - update ) ∧ scro : isMethodOf (? c - update , ?c - listener ) =⇒ observer : hasCListe n er C an d i da t e (? listener , ?c - listener ) ∧ observer : hasCUpdate (? c - listener , ?c - update ) ∧ observer : hasUpdate (? listener , ? update ) ----------------------------------------------------------scro : hasField (? c - subject , ? container ) ∧ scro : hasStruct ur e dD a t aT y pe (? container , ? containerDT ) ∧ scro : hasMethod (? containerDT , ? insert ) ∧ scro : methodInvoke d By (? insert , ? add - listener ) ∧ scro : isMethodOf (? add - listener , ?c - subject ) =⇒ observer : hasAddListen er (? c - subject , ? add - listener ) ----------------------------------------------------------observer : hasCListe n er C an d i da t e (? listener , ?c - listener ) ∧ observer : hasUpdate (? listener , ? update ) ∧ observer : hasAddListen er (? c - subject , ? add - listener ) ∧ scro : hasInputType (? add - listener , ? listener ) ∧ scro : hasPart (? c - listener , ?c - subject ) ∧ scro : hasMethod (? c - subject , ? notify ) ∧ scro : invokesMethod (? notify , ? update ) =⇒ observer : hasConcre te L is t en e r (? listener , ?c - listener ) ∧ observer : listensTo (? c - listener , ?c - subject ) ∧ observer : Observer (? notify ) Listing 3. Sample SWRL rules for the Observer pattern

Using Ontology Reasoning for Reverse Engineering Design Patterns

353

The OWL object property hasSuperType is made transitive so that the reasoner can infer all direct or indirect super types of a given class. The update method speciﬁed in the listener interface should be implemented by all concrete listeners. Recall that the object property methodOverrides works for both classes and interfaces. The second rule eﬀectively identiﬁes potential candidates for concrete subjects and the method used for establishing the relationship between this subject and its listeners. The subject class maintains a collection of its listeners, typically stored in a ﬁeld that has a structured data type. In SCRO, StructuredDataType represent arrays or collections of elements; it is a sub-class of ComplexDataType which also includes UnstructuredDataType such as user-deﬁned data structures. Therefore, the rule in Listing 3 can be modiﬁed to detect containers of any kind. The third rule builds on the other two rules and eﬀectively ensures the conditions needed for detecting this pattern. The hasPart property ensures that a concrete listener must maintain a reference to the observable; the hasInputType property ensures that the candidate add-listener method accepts only listener objects, and ﬁnally the notiﬁcation behavior is speciﬁed using method invocation.

4

Implementation and Evaluation

We are currently developing a program understanding tool that utilizes reasoning services over the ontological representation of source code elements. This tool currently accepts the Java byte code and the ontologies (Sections 2.1 and 2.2) as input; the knowledge generator module parses the byte code and generates the RDF repository (Sect 2.3). This repository is stored and managed by Jena [8], an open source Java framework for building Semantic Web applications. Our tool currently supports SPARQL ontological queries against the knowledge base. These queries can be issued to retrieve particular program elements as well as explore various relationships among those elements. Consider a developer who is reusing the JHotDraw framework and wishes to ﬁnd all parameterless static methods that return an instance of the interface type FigureEnumeration. Listing 4 shows a sample SPARQL query that answers this question. Furthermore, several SPARQL queries are embedded within the tool for retrieving the supported design patterns and details about their participants. This process is simple and fully automated, no manual interaction is required by the user. PREFIX scro : < http :// www . cs . uwm . edu /~ alnusair / o n t o l o g i e s/ scro . owl # > PREFIX JHotDraw : < http :// www . cs . uwm . edu /~ alnusair / o n t o l o g i e s/ JHotDraw . n3 # > SELECT distinct ? sm WHERE { ? sm a scro : S t a t i c M e t h o d. ? sm scro : h a s O u t p u t T y p e JHotDraw : org . jhotdraw . f r a m e w o r k. F i g u r e E n u m e r a t i o n. OPTIONAL {? sm scro : h a s I n p u t T y p e ? it } FILTER (! bound (? it )) }

Listing 4. A sample SPARQL query

354

A. Alnusair and T. Zhao

4.1

Experimental Results

We have conducted a preliminary study on multiple open source frameworks including JUnit8 , JHotDraw, and Java AWT. The chosen frameworks vary in size, they represent diﬀerent domains, and most importantly, they were built with design patterns in mind; this makes them a good ﬁt for evaluating our approach. Instance detection is shown in Table 1.

Table 1. Inferred design pattern instances Visitor 1

2

T TP Pr

Observer Composite T-Method Singleton 3

T TP Pr T TP

Pr

T TP Pr T TP Pr Pr:all

JUnit 3.7

0 0

-

4

4 100% 1 1 100% 1

1 100% 0 0

-

100%

JUnit 4.7

0 0

-

0

0

5

-

86%

JHotDraw 6.0 1 1 100% 9 Java AWT 1.6 1 0 1 2 3

-

1 1 100% 6

9 100% 2 1

0% 13 8

61% 6 3

83% 0 0

50% 11 11 100% 1 0 50% 6

5

0% 91%

83% 9 7 77% 65%

Total number of instances Number of identified True Positives Precision value

The interpretation of a pattern instance can be readily obtained from the corresponding rule for that pattern. For example, a Composite instance represents the child element’s container, a Singleton instance represents the singleton class, and a Template Method instance represents the template method itself. In our manual evaluation of the obtained results, we adopted precision measures – The number of correctly inferred pattern instances (True Positives) over the total number of inferred instances. In order to accept an instance as truly positive, this instance needs to be explicitly stated in the framework’s documentation or there have to be strong indications found by inspecting source code and available comments. In all the tests performed, none of the inferred pattern instances violates any of the structural or behavioral restrictions put forward for that pattern in the axioms and rules; this means that the knowledge base accurately represents the source code and the reasoner acted accordingly. However, as noted in Table 1, there are a few cases in which precision suﬀers since the identiﬁed instances were considered by our standards as false positives – falsely inferred instances that were not designed as such. In all these cases, neither documentation nor source code and its internal documentation strongly certiﬁed those instances as true positives. 8

http://www.junit.org

Using Ontology Reasoning for Reverse Engineering Design Patterns

355

Recall statistics, however, are usually harder to come up with since they require the identiﬁcation of all false negatives – occurrences that were intended as actual pattern instances but were not inferred by the reasoner. Most framework documentations do not explicitly report on all actual number of pattern instances, thus manual identiﬁcation through source code inspection is subject to one’s interpretations of what constitutes an actual instance. Nevertheless, we found some evidence of false negatives. Some of the instances were missed due to our parser’s inability to capture the complete picture of the running code; others are due to the restrictions speciﬁed in OWL axioms and SWRL rules. For example, the current rule for Template Method requires the primitive operation that is called by the template method to be declared protected, however, this is not a requirement; we found evidence of that in both JHotDraw and JUnit. It is obvious that such relaxation of the Template Method rule allows the reasoner to detect the missed instances. Generally speaking, relaxation reduces false negatives; it does, however, increase the risk of false positives. It was evident in some cases that better capturing of behavior speciﬁed in method bodies through more eﬀective parsing is indeed helpful, an appropriate parsing provides more ﬂexibility when relaxing the requirements and certainly improves both precision and recall. Nevertheless, our approach to pattern detection distinguishes itself as being ﬂexible and usable such that users can relax or restrict pattern descriptions as they wish. In Singleton, for example, accounting for another form of lazy instantiation or perhaps disputing the way the static reference is being declared, can be readily obtained by slightly modifying the corresponding rule. A more comprehensive case study is currently being conducted. In this study we are investigating the eﬀect of rule relaxation, applying our approach to other frameworks, comparing our results to other non-ontology driven approaches, and ﬁnally attempting to come up with recall statistics for selective well documented frameworks. Preliminary results are extremely encouraging and show an improvement However, a systematic study can uncover the overlap between diﬀerent approaches and most fundamentally show the value of ontology-based modeling in software engineering. Table 2 shows statistics related to the software frameworks used in our study as well as running time analysis. It is evident that the time required for parsing the code, loading the ontologies, executing the queries, etc. is in most cases minimal when compared to the time required by the reasoner to classify the ontologies and execute SWRL rules. Furthermore, since rules allow for reasoning with all available individuals, rule execution time is susceptible to increase as the number of OWL individuals in the ABox (assertions that represent ground facts for individual descriptions) as well as the complexity of the rules increase. In fact, Pellet, our experimentation reasoner, does not claim optimal performance. However, it does have an integrated rule engine that provides a complete and sound support for SWRL; that deﬁnitely adds to the cost of memory consumption and computational speed.

356

A. Alnusair and T. Zhao Table 2. Framework statistics and time1 analysis JUnit JUnit JHotDraw Java AWT v. 3.7 v. 4.7 v. 6.0 v. 1.6

Statistics

No. of Classes

99

105

377

549

1368

6254

11853

3

3

6.5

13

Visitor

1.6

1.5

18

49.7

Observer

2.9

2.5

33.3

95.2

Composite

2.5

2.2

29.1

76

Template Method

1.6

1.6

14.7

46

Singleton

1.7

1.6

14

48

No. of OWL Individuals 1411 Processing Time Parsing + Processing

Reasoner Time

1

5

Time unit: Second

Related Work

On surveying the state of the art in design pattern recovery, we found numerous non-semantic based approaches. Most existing approaches diﬀer in the detection technique utilized as well as the mechanism used for obtaining source code knowledge and formalizing pattern descriptions. PINOT [9] for example, represents design patterns using control-ﬂow graphs which have some scalability issues. This tool relies on processing the Abstract Syntax Tree (AST) of method bodies to build a CFG for program elements. This CFG is then examined to verify the existence of restrictions related to a particular design pattern. Balanyi and Ferenc [10] proposed an approach for detecting design patterns from C++ source code. In this approach, patterns are described externally using an XMLbased pattern description language. Similar to our approach, users of the system are granted full control over customizing these descriptions. Their approach relies on analyzing the source code to obtain its Abstract Semantic Graph (ASG) representation; this graph representation is then matched with pattern descriptions to detect design pattern instances. Similarly, Niere et al. [11] proposed an approach that is based on formalizing structural pattern descriptions using transformation rules and an annotated ASG representation of source code. Tsantalis et al. [12] proposed an approach that relies on graph and matrix representation of both, the system under study and design patterns. The ASM framework is used to parse the Java bytecode and populate the matrices for a particular system; using a well known similarity score algorithm, system’s representation is matched with pattern descriptions that are hard-coded within their tool. Other approaches utilize information obtained through dynamic analysis of the running code [13]. In general, runtime analysis can be eﬀective in detecting behavioral patterns only when the software is backed by a suitable and

Using Ontology Reasoning for Reverse Engineering Design Patterns

357

complete test data. We believe that our precise semantic descriptions of that particular group of behavioral patterns can compensate for the lack of dynamic analysis. Furthermore, due to its ﬂexibility and usability, our approach can be easily combined with other dynamic approaches to improve results. Whether the representation mechanism used is CFG, ASG, matrices, or DFG, it is our belief, however, that using a semantic-based formalism ensures consistent and accurate functional representation of design patterns, their participants, and the system under study. Furthermore, semantic representation allow for computing inferences of knowledge that was not explicitly stated, yielding an inference-based detection of design pattern instances. Closer to our approach is the work of Kramer and Prechelt [14] and Wuyts [15] in which declarative meta-programming techniques were utilized. In particular, design patterns are described using variations of Prolog predicates and limited information about program elements and their roles are represented as Prolog facts. Most recently, the work presented in [16] and [17] explored the notion of utilizing OWL ontologies to structure the source code knowledge. However, these approaches provide template ontology descriptions or at best rudimentary ontologies that must be extended to become more expressive. The full potential of semantic-based modeling was yet to be explored. The primary focus of the work presented in [16] is basically to facilitate exchanging and sharing knowledge about patterns, anti-patterns, and refactoring. Our aim, however, is to provide a true semantic-based approach for design pattern detection and provide an aid for understanding, reasoning, and conceptualizing source code.

6

Conclusion and Future Work

In this paper, we proposed a semantic-based approach to software understanding. In particular, we illustrated our approach for recovering design patterns from source code. The proposed approach is fully automatic and distinguishes itself as being extensible and extremely usable. Moreover, the proposed approach is purely semantic-based that describes knowledge using a set of ontologies. SCRO, our main ontology, provides a consistent and complete functional description of program elements and allows for semantic inference of knowledge that was not explicitly stated. The tool described in Sect 4 is currently a work in progress. Our ultimate goal is to provide a more comprehensive program comprehension environment for conceptualizing, understanding, and recovering software knowledge to aid both reverse and forward engineering activities. Notably the generated knowledge by the bytecode parser may not provide the full picture of the running code; in particular, method bodies need to be eﬀectively parsed to capture more detailed behavioral aspects of programs. We are currently investigating the use of other means to augment the current knowledge, the more knowledge captured, the more ﬂexibility is given to the user in authoring the rules for detecting design patterns. We also investigating our approach on other design patterns found in literature and conducting more case studies as described in Sect 4.1.

358

A. Alnusair and T. Zhao

References 1. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading (1995) 2. Chikofsky, E.J., Cross, J.H.: Reverse engineering and design recovery: A taxonomy. IEEE Software 7(1), 13–17 (1990) 3. Berners-Lee, T., Hendler, J., Lassila, O.: The Semantic Web. Scientific American 284(5), 34–43 (2001) 4. Sirin, E., Parsia, B., Grau, B.C., Kalyanpur, A., Kartz, Y.: Pellet: A Practical OWL-DL Reasoner. Web Semantics: Science, Services and agents on the World Wide Web 5(2) (2007) 5. Knublauch, H., Fergerson, R.W., Noy, N.F., Musen, M.A.: The Prot´eg´e OWL Plugin: An Open Development Environment for Semantic Web Applications. In: McIlraith, S.A., Plexousakis, D., van Harmelen, F. (eds.) ISWC 2004. LNCS, vol. 3298, pp. 229–243. Springer, Heidelberg (2004) 6. Source Code Representation Ontology (SCRO); Design Pattern Ontolgies; and an automatically generated ontology from parsing the JHotDraw application framework, http://www.cs.uwm.edu/~ alnusair/ontologies 7. Motik, B., Grau, B.C., Sattler, U.: Structured Objects in OWL: Representation and Reasoning. In: 17th International Conference on World Wide Web, pp. 555– 564 (2008) 8. McBride, B.: Jena: A Semantic Web Toolkit. IEEE Internet Computing 6(6), 55–59 (2002) 9. Shi, N., Olsson, R.A.: Reverse engineering of design patterns from Java Source Code. In: 21st IEEE/ACM International Conference on Automated Software Engineering, pp. 123–132 (2006) 10. Balanyi, Z., Ferenc, R.: Mining design patterns from C++ source code. In: 19th IEEE International conference on Software Maintenance (ICSM 2003), pp. 305–314 (2003) 11. Niere, J., Sch¨ afer, W., Wadsack, J., Welsh, J.: Towards pattern-based design recovery. In: 24th International Conference on Software Engineering (ICSE), pp. 338–348 (2002) 12. Tsantalis, N., Chatzigeorgiou, A., Stephanides, G., Halkidis, S.: Design Pattern Detection Using Similarity Scoring. IEEE Transactions on Software Engineering 32(11), 896–909 (2006) 13. De Lucia, A., Deufemia, V., Gravino, C., Risi, M.: Behavioral Pattern Identification Through Visual Language Parsing and Code Instrumentation. In: European Conference on Software Maintenance and Reengineerig (CSMR 2009), pp. 99–108 (2009) 14. Kramer, C., Prechelt, L.: Design Recovery by Automated Search for Structural Design Patterns in Object Oriented Software. In: 21st IEEE/ACM International Conference on Automated Software Engineering, pp. 123–132 (2006) 15. Wuyts, R.: Declarative reasoning about the structure of object-oriented systems. In: Proceedings of TOOLS USA 1998, pp. 112–124 (1998) 16. Dietrich, J., Elgar, C.: A Formal Description of Design Patterns Using OWL. In: Proceedings of the 2005 Australian Software Engineering Conference, pp. 243–250 (2005) 17. Kirasi´c, D., Basch, D.: Ontology-Based Design Pattern Recognition. In: Lovrek, I., Howlett, R.J., Jain, L.C. (eds.) KES 2008, Part I. LNCS (LNAI), vol. 5177, pp. 384–393. Springer, Heidelberg (2008)

Author Index

Aldawud, Omar 98 Alnusair, Awny 344 Amaral, Vasco 220 Anastasakis, Kyriakos Assmann, Uwe 325

Huang, Gang Hu, Zhenjiang 158

Becker, Basil 83, 124 Bencomo, Nelly 119 Bezivin, Jean 55 Blair, Gordon 119 Bordbar, Behzad 158 Botterweck, Goetz 68 Boulanger, Fr´ed´eric 310 Boˇskovi´c, Marko 291 Brucker, Achim D. 261 B¨ uttner, Fabian 276 Cabot, Jordi 256 Casallas, Rubby 225 Cazzola, Walter 98 Chauvel, Franck 140 Chimiak–Opoka, Joanna Cicchetti, Antonio 190 Cottenier, Thomas 98

France, Robert

Jacquet, Christophe 310 Jeanneret, C´edric 119 Jouault, Fr´ed´eric 256 Kappel, Gerti 5 Karsai, Gabor 220 Kasztelnik, Marek 329 Kienzle, J¨ org 98 Knapp, Alexander 256 Kowalewski, Stefan 68 Krieger, Matthias P. 261 Kuhlmann, Mirco 276 K¨ uhne, Thomas 240 Kusel, Angelika 5 Lengyel, L´ aszl´ o 220 Levendovszky, Tiham´er Lindow, Arne 276 L´ ucio, Levi 155

220

256

Deridder, Dirk 186, 225 Dingel, Juergen 1 Di Ruscio, Davide 190 Espinoza, Huascar

140 140

63

36, 55, 119

Mei, Hong 140 Mezei, Gergely 240 Miksa, Krzysztof 329 Moisan, Sabine 40 Mu˜ noz, Freddy 119 Neumann, Stefan Ober, Ileana Ober, Iulian

83, 124

63 63

Gaˇsevi´c, Dragan 291 Giese, Holger 83, 124 Gogolla, Martin 36, 55, 256, 276 Gray, Jeﬀ 98 Gudenkauf, Stefan 21

Pahl, Claus 291 Pan, Jeﬀ Z. 325 Parreiras, Fernando Silva 325 Pierantonio, Alfonso 190 Polzer, Andreas 68 Porres, Ivan 172

Hamann, Lars 276 Hardebolle, C´ecile 220, 310 Haugen, Oystein 55 Herrmannsdoerfer, Markus 205 Hildebrandt, Stephan 124 H¨ olzl, Matthias 104

Ratiu, Daniel 205 Rauf, Irum 172 Retschitzegger, Werner 5 Rigault, Jean-Paul 40 Rivera, Jos´e E. 296 Rouis, Elyes 310

360

Author Index

Sabina, Pawel 329 Sch¨ atz, Bernhard 186, 291 Schenck, Martin 83 Schoenboeck, Johannes 5 Schwinger, Wieland 5 Shah, Seyyed M.A. 158 Song, Hui 140 Stein, Dominik 98 Syriani, Eugene 240 Taentzer, Gabriele 55 Tamzalit, Dalila 186 Treﬀer, Arian 83 Troya, Javier 296 Vallecillo, Antonio Van Baelen, Stefan

296 63

Vangheluwe, Hans 240 Varro, Daniel 55 Vogel, Thomas 124 Wagelaar, Dennis 225 Walter, Tobias 329 Weigert, Thomas 63 Weißleder, Stephan 155 Wimmer, Manuel 5, 240 Wolﬀ, Burkhart 261 Xiong, Yingfei Yie, Andr´es

140 225

Zhang, Gefei 104 Zhao, Tian 344

Software Language Engineering: Second International Conference, SLE 2009, Denver, CO, USA, October 5-6, 2009 Revised Selected Papers (Lecture Notes ... Programming and Software Engineering)

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

Models in software engineering: workshops and symposia at MODELS 2008, Toulouse, France, September 28 - October 3, 2008: reports and revised selected papers

Model Driven Engineering Languages and Systems: 12th International Conference, MODELS 2009, Denver, CO, USA, October 4-9, 2009, Proceedings (Lecture ... Programming and Software Engineering)

Fundamentals of Software Engineering: Third IPM International Conference, FSEN 2009, Kish Island, Iran, April 15-17, 2009, Revised Selected Papers ... Programming and Software Engineering)

Ontologies in Software Engineering and Software Technology

Generative and Transformational Techniques in Software Engineering III: International Summer School, GTTSE 2009, Braga, Portugal, July 6-11, 2009, Revised ... Programming and Software Engineering)

Task Models and Diagrams for User Interface Design: 8th International Workshop, TAMODIA 2009, Brussels, Belgium, September 23-25, 2009, Revised Selected ... Programming and Software Engineering)

Models in Software Engineering: Workshops and Symposia at MODELS 2009, Denver, CO, USA, October 4-9, 2009. Reports and Revised Selected Papers ... Programming and Software Engineering)

Software Language Engineering: Second International Conference, SLE 2009, Denver, CO, USA, October 5-6, 2009 Revised Selected Papers (Lecture Notes ... Programming and Software Engineering)

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

Models in software engineering: workshops and symposia at MODELS 2008, Toulouse, France, September 28 - October 3, 2008: reports and revised selected papers

Model Driven Engineering Languages and Systems: 12th International Conference, MODELS 2009, Denver, CO, USA, October 4-9, 2009, Proceedings (Lecture ... Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Models in Software Engineering - MoDELS 2010

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Fundamentals of Software Engineering: Third IPM International Conference, FSEN 2009, Kish Island, Iran, April 15-17, 2009, Revised Selected Papers ... Programming and Software Engineering)

Ontologies in Software Engineering and Software Technology

Generative and Transformational Techniques in Software Engineering III - GTTSE 2009

Software engineering and development

Generative and Transformational Techniques in Software Engineering III: International Summer School, GTTSE 2009, Braga, Portugal, July 6-11, 2009, Revised ... Programming and Software Engineering)

Task Models and Diagrams for User Interface Design: 8th International Workshop, TAMODIA 2009, Brussels, Belgium, September 23-25, 2009, Revised Selected ... Programming and Software Engineering)

Ontologies for Software Engineering and Software Technology

Models in Software Engineering: Workshops and Symposia at MODELS 2009, Denver, CO, USA, October 4-9, 2009. Reports and Revised Selected Papers ... Programming and Software Engineering)

Software Language Engineering: Second International Conference, SLE 2009, Denver, CO, USA, October 5-6, 2009 Revised Selected Papers (Lecture Notes ... Programming and Software Engineering)

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

Models in software engineering: workshops and symposia at MODELS 2008, Toulouse, France, September 28 - October 3, 2008: reports and revised selected papers

Model Driven Engineering Languages and Systems: 12th International Conference, MODELS 2009, Denver, CO, USA, October 4-9, 2009, Proceedings (Lecture ... Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Models in Software Engineering - MoDELS 2010

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Fundamentals of Software Engineering: Third IPM International Conference, FSEN 2009, Kish Island, Iran, April 15-17, 2009, Revised Selected Papers ... Programming and Software Engineering)

Ontologies in Software Engineering and Software Technology

Generative and Transformational Techniques in Software Engineering III - GTTSE 2009

Software engineering and development

Generative and Transformational Techniques in Software Engineering III: International Summer School, GTTSE 2009, Braga, Portugal, July 6-11, 2009, Revised ... Programming and Software Engineering)

Task Models and Diagrams for User Interface Design: 8th International Workshop, TAMODIA 2009, Brussels, Belgium, September 23-25, 2009, Revised Selected ... Programming and Software Engineering)

Ontologies for Software Engineering and Software Technology

Recommend Documents