Model Driven Engineering Languages and Systems: 13th International Conference, MODELS 2010, Oslo, Norway 3-8, 2010, Proceedings, Part II (Lecture ... Programming and Software Engineering)

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 for Informatics, Saarbruecken, Germany

6395

Dorina C. Petriu Nicolas Rouquette Øystein Haugen (Eds.)

Model Driven Engineering Languages and Systems 13th International Conference, MODELS 2010 Oslo, Norway, October 3-8, 2010 Proceedings, Part II

13

Volume Editors Dorina C. Petriu Carleton University, Department of Systems and Computer Engineering 1125 Colonel By Drive, Ottawa, Ontario, K1S 5BG, Canada E-mail: [email protected] Nicolas Rouquette Jet Propulsion Laboratory Flight Software Systems Engineering and Architecture Group 4800 Oak Grove Drive, Pasadena, CA 91109, USA E-mail: [email protected] Øystein Haugen SINTEF IKT Forskningsveien 1, 0373 Oslo, Norway E-mail: [email protected]

Library of Congress Control Number: 2010935022 CR Subject Classification (1998): D.2, D.3, K.6.3, D.2.9, F.3.3, D.1, D.2.2 LNCS Sublibrary: SL 2 – Programming and Software Engineering ISSN ISBN-10 ISBN-13

0302-9743 3-642-16128-6 Springer Berlin Heidelberg New York 978-3-642-16128-5 Springer Berlin Heidelberg New York

This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. springer.com © Springer-Verlag Berlin Heidelberg 2010 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific 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 focusing on a very important new technical discipline: model-driven software and systems engineering. The expansion of this discipline is a direct consequence of the increasing significance and success of model-based methods in practice. Numerous efforts resulted in the invention of concepts, languages and tools for the definition, analysis, transformation, and verification of domain-specific modeling languages and general-purpose modeling language standards, as well as their use for software and systems engineering. MODELS 2010, the 13th edition of the conference series, took place in Oslo, Norway, October 3-8, 2010, along with numerous satellite workshops, symposia and tutorials. The conference was fortunate to have three prominent keynote speakers: Ole Lehrmann Madsen (Aarhus University, Denmark), Edward A. Lee (UC Berkeley, USA) and Pamela Zave (AT&T Laboratories, USA). To provide a broader forum for reporting on scientific progress as well as on experience stemming from practical applications of model-based methods, the 2010 conference accepted submissions in two distinct tracks: Foundations and Applications. The primary objective of the first track is to present new research results dedicated to advancing the state-of-the-art of the discipline, whereas the second aims to provide a realistic and verifiable picture of the current state-ofthe-practice of model-based engineering, so that the broader community could be better informed of the capabilities and successes of this relatively young discipline. This volume contains the final version of the papers accepted for presentation at the conference from both tracks. We received a total of 252 submissions (207 in the Foundations and 45 in the Applications track) from 34 countries; 21% of the papers were co-authored by researchers from different countries, indicating a healthy trend toward international collaboration. The program committees selected a total of 54 papers for presentation at the conference (43 Foundations and 11 Applications) giving a total acceptance rate of 21.3%. We would like to thank everyone who submitted papers, as well as those who submitted proposals for workshops and tutorials. We would also like to express our gratitude to the large number of volunteers who contributed to the success of the conference. Special thanks are due to Richard van de Stadt for his prompt and unfailing support of CyberChairPRO, the conference management system used for MODELS 2010. Last but not least, we would like to thank our sponsors, ACM, IEEE, SINTEF, and the Department of Informatics at the University of Oslo. October 2010

Dorina C. Petriu Nicolas Rouquette Øystein Haugen

Organization

General Chair Øystein Haugen

SINTEF and University of Oslo, Norway

Program Chairs Dorina C. Petriu (Foundations Track) Nicolas Rouquette (Applications Track)

Carleton University, Canada NASA, Jet Propulsion Laboratory, USA

Local Chair Birger Møller-Pedersen

University of Oslo, Norway

Publicity and Sponsor Chair Arne J. Berre

SINTEF and University of Oslo, Norway

International Publicity Chair Franck Fleurey

SINTEF, Norway

Treasurer Parastoo Mohagheghi

SINTEF, Norway

Workshop Co-chairs Juergen Dingel Arnor Solberg

Queens University, Canada SINTEF, Norway

Tutorial Co-chairs Stein Krogdahl Stein-Erik Ellevseth

University of Oslo, Norway ABB, Norway

VIII

Organization

Educators’ Symposium Co-chairs Peter Clarke Martina Seidl

Florida International University, USA Vienna University of Technology, Austria

Doctoral Symposium Chair Bernhard Sch¨ atz Brian Elvesæter (Support)

Technical University Munich, Germany SINTEF and University of Oslo, Norway

Panel Chair Thomas K¨ uhne

Victoria University of Wellington, New Zealand

Exhibition and Demo Chair Arne Maus

University of Oslo, Norway

Web Chair Dag Langmyhr

University of Oslo, Norway

Local Room Facilities Roy Grønmo

SINTEF and University of Oslo, Norway

Student Volunteer Coordinator Jon Oldevik

SINTEF and University of Oslo, Norway

Program Committee: Foundations Track Daniel Amyot Krishnakumar Balasubramanian Don Batory Benoit Baudry Behzad Bordbar Ruth Breu Lionel Briand Jean-Michel Bruel Jordi Cabot

University of Ottawa, Canada The MathWorks Inc., USA University of Texas, USA INRIA, France University of Birmingham, UK University of Innsbruck, Austria Simula Research Lab and University of Oslo, Norway Universit´e de Toulouse, France INRIA- Ecole des Mines de Nantes, France

Organization

Michel Chaudron Tony Clark Vittorio Cortellessa Krzysztof Czarnecki Juan de Lara Jens Dietrich Juergen Dingel Stephane Ducasse Keith Duddy Gregor Engels Franck Fleurey Robert B. France David Frankel Lidia Fuentes Dragan Gasevic Geri Georg S´ebastien G´erard Sudipto Ghosh Holger Giese Tudor Gˆırba Martin Gogolla Susanne Graf Vincenzo Grassi Jeff Gray John Grundy Esther Guerra Jun Han Øystein Haugen Zhenjiang Hu Heinrich Hussmann Paola Inverardi Jan J¨ urjens Audris Kalnins Gerti Kappel Gabor Karsai J¨ org Kienzle Ingolf Kr¨ uger Thomas K¨ uhne Jochen K¨ uster Yvan Labiche Ralf Laemmel Micha¨el Lawley Timothy C. Lethbridge

Leiden University, The Netherlands Middlesex University, UK University of L’Aquila, Italy University of Waterloo, Canada Universidad Aut´ onoma de Madrid, Spain Massey University, New Zealand Queen’s University, Canada INRIA Lille, France Queensland University of Technology, Australia University of Paderborn, Germany SINTEF, Norway Colorado State University, USA SAP, USA University of Malaga, Spain Athabasca University, Canada Colorado State University, USA CEA LIST, France Colorado State University, USA Hasso Plattner Institute at the University of Potsdam, Germany University of Bern, Switzerland University of Bremen, Germany VERIMAG, France University of Rome “Tor Vergata”, Italy University of Alabama, USA Swinburne University of Technology, Australia Universidad Carlos III de Madrid, Spain Swinburne University of Technology, Australia SINTEF, Norway National Institute of Informatics, Japan Universit¨ at M¨ unchen, Germany University of L’Aquila, Italy TU Dortmund and Fraunhofer ISST, Germany University of Latvia, Latvia Vienna University of Technology, Austria Vanderbilt University, USA McGill University, Montreal, Canada UC San Diego, USA Victoria University of Wellington, New Zealand IBM Research - Z¨ urich, Switzerland Carleton University, Canada University of Koblenz-Landau, Germany CSIRO Australian e-Health Research Centre, Australia University of Ottawa, Canada

IX

X

Organization

Tom Maibaum Radu Marinescu Dragan Milicev Birger Møller-Pedersen Ana Moreira Pierre-Alain Muller Ileana Ober Iulian Ober Richard Paige Robert Pettit Alfonso Pierantonio Claudia Pons Ivan Porres Gianna Reggio Arend Rensink Ralf Reussner Bernhard Rumpe Bernhard Sch¨ atz Andy Sch¨ urr Bran Selic ´ Michal Smia lek Arnor Solberg Perdita Stevens Paul Strooper Tarja Syst¨ a Gabriele Taentzer Juha-Pekka Tolvanen Laurence Tratt Antonio Vallecillo D´ aniel Varr´ o Eelco Visser Andrzej Wasowski Jon Whittle Andreas Winter

McMaster University, Canada Universitatea Politehnica Timisoara, Romania University of Belgrade, Yugoslavia University of Oslo, Norway Universidade Nova de Lisboa, Portugal Universit´e de Haute-Alsace, France IRIT, France IRIT, France University of York, UK The Aerospace Corporation, USA Universit` a degli Studi dell’ Aquila, Italy University of La Plata, Argentina ˚ Abo Akademi University, Finland Universit` a di Genova, Italy University of Twente, The Netherlands Karlsruhe Institute of Technology, Germany RWTH Aachen University, Germany TU M¨ unchen, Germany Technische Universit¨at Darmstadt, Germany Malina Software, Canada Warsaw University of Technology, Poland SINTEF, Norway University of Edinburgh, UK The University of Queensland, Australia Tampere University of Technology, Finland Philipps-Universit¨ at Marburg, Germany MetaCase, Finland Bournemouth University, UK Universidad de M¨ alaga, Spain Budapest University of Technology and Economics, Hungary Technical University of Delft, The Netherlands IT University of Copenhagen, Denmark Lancaster University, UK Carl von Ossietzky University, Germany

Program Committee: Applications Track Patrick Albert Robert Baillargeon Edward Barkmeyer Mariano Belaunde Rao G. Bhaskar Behzad Bordbar Francis Bordeleau

IBM, France Panasonic Automotive Systems, USA National Institute of Standards & Technology, USA Orange Labs, France Motorola, India University of Birmingham, UK Zeligsoft, Canada

Organization

Tony Clark Diarmuid Corcoran Rik Eshuis

XI

Middlesex University, UK Ericsson AB, Sweden Eindhoven University of Technology, The Netherlands Huascar Espinoza European Software Institute, Spain Andy Evans Xactium, UK Geri Georg Colorado State University, USA Øystein Haugen SINTEF, Norway Steven Kelly MetaCase, Finland Jana Koehler IBM Zurich Research Laboratory, Switzerland Vinay Kulkarni Tata Consultancy Services, India Nikolai Mansourov KDM Analytics, Canada Stephen Mellor Project Technology, Inc., UK Dragan Milicev University of Belgrade, Serbia Hiroshi Miyazaki Fujitsu, Japan Juan Carlos Molina UdaetaCARE Technologies, S.A., Spain Pierre-Alain Muller Universit´e de Haute-Alsace, France Syed Salman Qadri The Mathworks, Inc., USA Ina Schieferdecker TU Berlin/Fraunhofer FOKUS, Germany Bran Selic Malina Software Corporation, Canada Richard Soley Object Management Group, USA Ingo St¨ urmer Model Engineering Solutions GmbH, Germany Jun Sun National University of Singapore, Singapore Fran¸cois Terrier CEA-LIST, France Laurence Tratt Bournemouth University, UK Markus Voelter itemis AG, Germany Michael von der Beeck BMW Group, Germany Thomas Weigert Missouri University of Science and Technology, USA Frank Weil Hengsoft, USA Jon Whittle Lancaster University, UK Ed Willink Thales Research and Technology Ltd., UK

Steering Committee Heinrich Hussmann (Chair) Geri Georg (Vice Chair) Thomas Baar Jean Bezivin Lionel Briand Jean-Michel Bruel Krzysztof Czarnecki Gregor Engels Øystein Haugen Rob Pettit Stuart Kent

Ana Moreira Pierre-Alain Muller Oscar Nierstrasz Dorina Petriu Gianna Reggio Matthew Dwyer Doug Schmidt Andy Sch¨ urr Perdita Stevens Jon Whittle

XII

Organization

Sponsors ACM (http://www.acm.org) IEEE (http://www.ieee.org) SINTEF (http://www.sintef.no/Home/) IFI, University of Oslo (http://www.ifi.uio.no/english/)

Additional Reviewers Saeed Ahmadi-Behnam Mauricio Alferez Shaukat Ali Hamoud Aljamaan Andrew Allen Carmen Alonso Michal Antkiewicz Thorsten Arendt Nesa Asoudeh Arun Bahulkar Kacper Bak Andr´ as Balogh Cecilia Bastarrica Basil Becker Kristian Beckers Axel Belinfante James M. Bieman Enrico Biermann D´enes Bisztray Marko Boˇskovi´c Noury Bouraqadi Jens Br¨ uning Petra Brosch Frank Br¨ useke Erik Burger Sergio Campos Maura Cerioli Dan Chiorean Hyun Cho Antonio Cicchetti Selim Ciraci Rober Claris´ o Peter J. Clarke Benoit Combemale Duc-Hanh Dang Sylvain Dehors Marcus Denker

Marcos Didonet Del Fabro Zinovy Diskin Frederic Doucet Mauro Luigi Drago Iulia Dragomir Zoya Durdik Maged Elaasar Romina Eramo Eban Escott Sami Evangelista Julie S. Fant Hanna Farah Claudiu Farcas Stephan Fassbender Ali Fatolahi Frederic Fondement Gregor Gabrysiak Nadia G´ amez Xiaocheng Ge Christian Gerth Sepideh Ghanavati Martin Giese Thomas Goldschmidt Cristina G´ omez L´aszl´o G¨onczy Hans Groenniger Baris G¨ uldali Tim G¨ ulke Arne Haber Lars Hamann Brahim Hamid Ali Hanzala Michael Hauck Regina Hebig Ramin Hedayati Werner Heijstek Michael Henderson

Organization

Frank Hernandez Markus Herrmannsdoerfer Stephan Hildebrandt Martin Hirsch Florian Hoelzl S¨ oren H¨ oglund ´ Akos Horv´ ath To-Ju Huang Jeronimo Irazabal Martin Johansen Stefan Jurack Lucia Kapova Soon-Kyeong Kim Felix Klar Dimitrios Kolovos Dagmar Koss Mirco Kuhlmann Thomas Kurpick Ivan Kurtev Angelika Kusel Martin K¨ uster Scott Uk-Jin Lee Leen Lambers Philip Langer Marius Lauder Herv´e Leblanc Arne Lindow Qichao Liu Alexander De Luca Markus Luckey Tomaz Lukman Carlos Luna Frederic Massicotte Max Maurer Dieter Mayrhofer Massimiliano Menarini Marjan Mernik Raffaela Mirandola Kim-Sun Mo Naouel Moha Maarten de Mol Ingo Mueller Gunter Mussbacher Benjamin Nagel Stefan Neumann

Ariadi Nugroho Martin Ochoa Jon Oldevik Sebastian Oster Lars Patzina Sven Patzina Ekaterina Pek Patrizio Pelliccione Gabriela Perez Christian Pfaller Gergely Pint´er Monica Pinto Alain Plantec Ernesto Posse Alireza Pourshahid Alek Radjenovic Istv´an R´ ath Daniel Ratiu Irum Rauf Indrakshi Ray Holger Rendel Lukas Renggli Taylor Riche Eduardo Rivera Louis Rose Sebastian Rose Judith E. Y. Rossebø Suman Roychoudhury Fran J. Ruiz-Bertol Davide Di Ruscio Mehrdad Sabetzadeh Karsten Saller Pablo S´ anchez Joao Santos Martin Schindler Holger Schmidt Andreas Seibel Martina Seidl Filippo Seracini Seyyed Shah Syed Mohammad Ali Shaw Carla Silva Karsten Sohr St´ephane S. Som´e Michael Spijkerman Jim Steel

XIII

XIV

Organization

Yu Sun Andreas Svendsen Nora Szasz J¨ orn Guy S¨ uß Tian Huat Tan Massimo Tisi Catia Trubiani Sara Tucci-Piergiovanni Steve Versteeg Thomas Vogel Steven V¨ olkel Sebastian Voss Ingo Weisemoeller Konrad Wieland

Manuel Wimmer Jevon Wright Yali Wu Andreas W¨ ubbeke Yingfei Xiong Lijun Yu Tao Yue Eduardo Zambon Vadim Zaytsev Xiaorui Zhang Manchun Zheng Celal Ziftci Karolina Zurowska

Table of Contents – Part II

Keynote 2 Modeling the Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pamela Zave

1

Session 4a: Distributed/Embedded Software Development Transformation-Based Parallelization of Request-Processing Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Taylor L. Rich´e, Harrick M. Vin, and Don Batory Model Driven Orchestration: Design for Service Compatibility . . . . . . . . . Georg Grossmann, Michael Schrefl, and Markus Stumptner Embedded Software Development with Projectional Language Workbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Markus Voelter

2 17

32

Session 4b: (De)Composition and Refactoring Concern-Based (de)composition of Model-Driven Software Development Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jendrik Johannes and Uwe Aßmann

47

Flexible Model Element Introduction Policies for Aspect-Oriented Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Brice Morin, Jacques Klein, J¨ org Kienzle, and Jean-Marc J´ez´equel

63

Role-Based Generic Model Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jan Reimann, Mirko Seifert, and Uwe Aßmann

78

Session 4c: Model Change Precise Detection of Conflicting Change Operations Using Process Model Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Christian Gerth, Jochen M. K¨ uster, Markus Luckey, and Gregor Engels Capturing the Intention of Model Changes . . . . . . . . . . . . . . . . . . . . . . . . . . Patrick K¨ onemann

93

108

XVI

Table of Contents – Part II

Selective and Consistent Undoing of Model Changes . . . . . . . . . . . . . . . . . . Iris Groher and Alexander Egyed

123

Session 5a: (Meta)Models at Runtime Modeling Features at Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Marcus Denker, Jorge Ressia, Orla Greevy, and Oscar Nierstrasz

138

Metamodel-Based Information Integration at Industrial Scale . . . . . . . . . . Stefan Berger, Georg Grossmann, Markus Stumptner, and Michael Schrefl

153

Inferring Meta-models for Runtime System Data from the Clients of Management APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hui Song, Gang Huang, Yingfei Xiong, Franck Chauvel, Yanchun Sun, and Hong Mei

168

Session 5b: Requirements Engineering A Meta Model for Artefact-Orientation: Fundamentals and Lessons Learned in Requirements Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Daniel M´endez Fern´ andez, Birgit Penzenstadler, Marco Kuhrmann, and Manfred Broy

183

A Common Framework for Synchronization in Requirements Modelling Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Shahram Esmaeilsabzali, Nancy A. Day, and Joanne M. Atlee

198

A Systematic Review of the Use of Requirements Engineering Techniques in Model-Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . . . Grzegorz Loniewski, Emilio Insfran, and Silvia Abrah˜ ao

213

Session 5c: Slicing and Model Transformations Slicing of UML Models Using Model Transformations . . . . . . . . . . . . . . . . . Kevin Lano and Shekoufeh Kolahdouz-Rahimi

228

An Adjustable Transformation from OWL to Ecore . . . . . . . . . . . . . . . . . . Tirdad Rahmani, Daniel Oberle, and Marco Dahms

243

Transforming Process Models: Executable Rewrite Rules versus a Formalized Java Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pieter Van Gorp and Rik Eshuis

258

Table of Contents – Part II

XVII

Keynote 3 Disciplined Heterogeneous Modeling (Invited Paper) . . . . . . . . . . . . . . . . . . Edward A. Lee

273

Session 6a: Incorporating Quality Concerns in MDD Design Guidelines for the Development of Quality-Driven Model Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Emilio Insfran, Javier Gonzalez-Huerta, and Silvia Abrah˜ ao

288

Early Deviation Detection in Modeling Activities of MDE Processes . . . . Marcos Aur´elio Almeida da Silva, Reda Bendraou, Xavier Blanc, and Marie-Pierre Gervais

303

Artifact or Process Guidance, an Empirical Study . . . . . . . . . . . . . . . . . . . . Marcos Aur´elio Almeida da Silva, Alix Mougenot, Reda Bendraou, Jacques Robin, and Xavier Blanc

318

Session 6b: Model-Driven Engineering in Practice Scaling Up Model Driven Engineering – Experience and Lessons Learnt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vinay Kulkarni, Sreedhar Reddy, and Asha Rajbhoj Mod4J: A Qualitative Case Study of Model-Driven Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vincent Lussenburg, Tijs van der Storm, Jurgen Vinju, and Jos Warmer Modeling Issues: A Survival Guide for a Non-expert Modeler . . . . . . . . . . Emilio Rodriguez-Priego, Francisco J. Garc´ıa-Izquierdo, and ´ Angel Luis Rubio

331

346

361

Session 6c: Modeling Architecture Monarch: Model-Based Development of Software Architectures . . . . . . . . Hamid Bagheri and Kevin Sullivan

376

Model-to-Metamodel Transformation for the Development of Component-Based Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gerd Kainz, Christian Buckl, Stephan Sommer, and Alois Knoll

391

Architectural Descriptions as Boundary Objects in System and Design Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lars Pareto, Peter Eriksson, and Staffan Ehnebom

406

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

421

Table of Contents – Part I

Keynote 1 A Unified Approach to Modeling and Programming . . . . . . . . . . . . . . . . . . Ole Lehrmann Madsen and Birger Møller-Pedersen

1

Session 1a: Genericity and Generalization Generic Meta-modelling with Concepts, Templates and Mixin Layers . . . Juan de Lara and Esther Guerra

16

An Observer-Based Notion of Model Inheritance . . . . . . . . . . . . . . . . . . . . . Thomas K¨ uhne

31

MDE-Based Approach for Generalizing Design Space Exploration . . . . . . Tripti Saxena and Gabor Karsai

46

Session 1b: Model Migration and Incremental Manipulation A Comparison of Model Migration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . Louis M. Rose, Markus Herrmannsdoerfer, James R. Williams, Dimitrios S. Kolovos, Kelly Garc´es, Richard F. Paige, and Fiona A.C. Polack

61

Incremental Evaluation of Model Queries over EMF Models . . . . . . . . . . . ´ G´ abor Bergmann, Akos Horv´ ath, Istv´ an R´ ath, D´ aniel Varr´ o, ¨ os Andr´ as Balogh, Zolt´ an Balogh, and Andr´ as Okr¨

76

Active Operations on Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Olivier Beaudoux, Arnaud Blouin, Olivier Barais, and Jean-Marc J´ez´equel

91

Session 1c: Modeling Model Transformations transML: A Family of Languages to Model Model Transformations . . . . . Esther Guerra, Juan de Lara, Dimitrios S. Kolovos, Richard F. Paige, and Osmar Marchi dos Santos Henshin: Advanced Concepts and Tools for In-Place EMF Model Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Thorsten Arendt, Enrico Biermann, Stefan Jurack, Christian Krause, and Gabriele Taentzer

106

121

XX

Table of Contents – Part I

A Technique for Automatic Validation of Model Transformations . . . . . . . Levi L´ ucio, Bruno Barroca, and Vasco Amaral

136

Session 2a: Verifying Consistency and Conformance Static- and Dynamic Consistency Analysis of UML State Chart Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Christian Schwarzl and Bernhard Peischl

151

Verifying Semantic Conformance of State Machine-to-Java Code Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lukman Ab Rahim and Jon Whittle

166

A Dynamic-Priority Based Approach to Fixing Inconsistent Feature Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bo Wang, Yingfei Xiong, Zhenjiang Hu, Haiyan Zhao, Wei Zhang, and Hong Mei

181

Session 2b: Taming Modeling Complexity Taming Graphical Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hauke Fuhrmann and Reinhard von Hanxleden

196

Taming EMF and GMF Using Model Transformation . . . . . . . . . . . . . . . . . Dimitrios S. Kolovos, Louis M. Rose, Saad Bin Abid, Richard F. Paige, Fiona A.C. Polack, and Goetz Botterweck

211

A Visual Traceability Modeling Language . . . . . . . . . . . . . . . . . . . . . . . . . . . Patrick M¨ ader and Jane Cleland-Huang

226

Session 2c: Modeling User-System Interaction Application Logic Patterns – Reusable Elements of User-System Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ Albert Ambroziewicz and Michal Smia lek

241

A Metamodel-Based Approach for Automatic User Interface Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ant´ onio Miguel Rosado da Cruz and Jo˜ ao Pascoal Faria

256

Rapid UI Development for Enterprise Applications: Combining Manual and Model-Driven Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arne Schramm, Andr´e Preußner, Matthias Heinrich, and Lars Vogel

271

Table of Contents – Part I

XXI

Session 3a: Model-Driven Quality Assurance Environment Modeling with UML/MARTE to Support Black-Box System Testing for Real-Time Embedded Systems: Methodology and Industrial Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Muhammad Zohaib Iqbal, Andrea Arcuri, and Lionel Briand Improving Test Models for Large Scale Industrial Systems: An Inquisitive Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Andrew Diniz da Costa, Viviane Torres da Silva, Alessandro Garcia, and Carlos Jos´e Pereira de Lucena Automatically Discovering Properties That Specify the Latent Behavior of UML Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heather J. Goldsby and Betty H.C. Cheng

286

301

316

Session 3b: Managing Variability Towards a Semantics of Activity Diagrams with Semantic Variation Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hans Gr¨ onniger, Dirk Reiß, and Bernhard Rumpe

331

An AADL-Based Approach to Variability Modeling of Automotive Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Shin’ichi Shiraishi

346

Extending Variability for OCL Interpretation . . . . . . . . . . . . . . . . . . . . . . . . Claas Wilke, Michael Thiele, and Christian Wende

361

Session 3c: Multi-Modeling Approaches Inter-Modelling: From Theory to Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . Esther Guerra, Juan de Lara, Dimitrios S. Kolovos, and Richard F. Paige

376

Consistent Modeling Using Multiple UML Profiles . . . . . . . . . . . . . . . . . . . Florian Noyrit, S´ebastien G´erard, Fran¸cois Terrier, and Bran Selic

392

A Systematic Review on the Definition of UML Profiles . . . . . . . . . . . . . . . Jes´ us Pardillo

407

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

423

Modeling the Internet Pamela Zave AT&T Laboratories—Research www2.research.att.com/~ pamela

Abstract. The Internet has changed the world. Its astounding success has led to explosive growth in users, traffic, and applications, which has made its original architecture and protocols obsolete. Currently the networking community is questioning all aspects of Internet technology, as researchers and stakeholders try to understand how to meet new requirements for functionality, quality of service, availability, and security. In this technological crisis, one of our most powerful technical tools, namely functional modeling (as opposed to performance modeling), is being completely ignored. In this talk I explain how modeling can be put to good use in the Internet context, how the culture of the Internet Engineering Task Force and the networking research community resist such efforts, and what might be done to bring about a cultural change. The talk will be illustrated with examples and results from several projects using different modeling languages and techniques. These include: – A project to understand, formalize, and partially verify SIP, the dominant protocol for IP-based multimedia applications. The official specification of SIP consists of many thousands of pages of English text. – A project revealing many unknown defects in the Chord routing protocol, which is the most-cited protocol for maintenance of peerto-peer networks. – A project to generate modular telecommunication services from models in a high-level, domain-specific language. This long-term project, based on the DFC architecture, has already produced two large-scale deployed systems. – A project to discover how to meet complex requirements for application sessions using software composition. The descriptions of these projects will emphasize topics such as the search for the right modeling language and the search for principles of networking.

D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, p. 1, 2010. c Springer-Verlag Berlin Heidelberg 2010 

Transformation-Based Parallelization of Request-Processing Applications Taylor L. Rich´e1 , Harrick M. Vin2 , and Don Batory1 1

Department of Computer Science, The University of Texas at Austin, Austin, TX, USA {riche,batory}@cs.utexas.edu 2 Tata Research and Development Center, Pune, India [email protected]

Abstract. Multicore, multithreaded processors are rapidly becoming the platform of choice for high-throughput request-processing applications (RPAs). We refer to this class of modern parallel platforms as multi- systems. In this paper, we describe the design and implementation of Lagniappe, a translator that simplifies RPA development by transforming portable models of RPAs to highthroughput multi- executables. We demonstrate Lagniappe’s effectiveness with a pair of stateful RPA case studies.

1 Introduction Moore’s law and the accompanying improvements in fabrication technologies (90nm to 65nm and beyond [5]) have significantly increased the number of transistors available to processor designers. Rather than use these transistors by further extending the depth of processor pipelines, designers are developing processors with multiple, multithreaded cores. This class of modern parallel platforms, called multi- systems, are the standard for constructing high-performance and high-throughput computing clusters. Sadly, the ubiquity of multi- systems has not led to breakthroughs in easing the core burdens of parallel programming: 1. It is the responsibility of programmers to map components of an application to available parallel resources manually, in order to maximize performance or efficiency. Further, the computational needs of an application may change during runtime, requiring mapping decisions to change dynamically based on both application and workload characteristics [15]. 2. Many applications have persistent, mutable state. Accessing state with multiple execution threads, if done na¨ıvely, can cause contention for locks and reduce performance [20]. As multi- systems grow larger, application mappings become more difficult as the cost of sharing state between processing elements grows. 3. Different systems utilize different types of parallel resources. Platform-specific code should never be embedded in an application because the application may run on different hardware configurations over time (portability for code reuse) and because multi- systems are often heterogeneous comprising different hardware types (portability for heterogeneity). D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 2–16, 2010. c Springer-Verlag Berlin Heidelberg 2010 

Transformation-Based Parallelization of Request-Processing Applications

3

Request-processing applications (RPAs) are an important class of applications on multi- systems given their traditionally high amounts of both task parallelism (i.e. different parts of the application can run in parallel [26]) and data parallelism (i.e. the same part of the application can process different requests at the same time [25]). An RPA is a directed graph of components called a streaming [24] or pipe-and-filter [22] architecture. Multi- concerns of these architectures (e.g. component coordination, access to persistent state, and mapping the application to multi- hardware) are non-trivial. Even worse, programmers implement RPAs using traditional, low-level methodologies that strain development, testing, component reuse, and maintenance. While tools [4,9,14,24] do allow programmers to create high-performance applications—even parallel ones— the programming task remains daunting and error-prone. Our research improves the state-of-the-art tools in RPA development for multi- systems by automating the difficult, tedious, and error-prone tasks that lie at the heart of parallel RPA programming. We built Lagniappe1, a tool that maps a model of an RPA to a C++ module; effectively it implements a sophisticated model-to-text (M2T) transformation. Lagniappe was our first step in understanding the domain of RPAs and its engineering requirements. It helped us to test the correctness of our RPA abstractions and demonstrated that we could derive efficient multi- implementations of RPAs from these abstractions. Lagniappe generalizes prior work by providing an abstraction and portability advantage to programmers over previous, one-of-a-kind tools that fixed one or more domain variabilities or that exposed very low-level details. We see Lagniappe as a precursor to a sophisticated model driven engineering (MDE) tool where a model of an RPA is progressively mapped to more complex models using model-to-model (M2M) transformations that expose task and data parallelism. The most-refined model is then translated to a C++ module via a simple M2T transformation. Presently, these parallelism mappings are hardcoded in the M2T implementation. In this paper, we present the design and implementation of Lagniappe from this more advanced MDE perspective. An RPA is specified by a graph of interacting components where each component is implemented in an imperative language (C++ in our case). The model captures application features that are relevant for execution on multi- systems. Lagniappe automatically transforms this model of an RPA—actually a single- description that can only execute on a single processing element (processor, core, thread, etc.2 )—into a model that is optimized for multi- execution. These transformations determine custom and optimized policies for run-time adaptation and load-distribution. Part of Lagniappe’s contribution is that these policy decisions are explicit and changeable—adding new policy implementations is effectively providing a different implementation of the transformations we identify. Lagniappe automatically creates an application that meets the four challenges of multi- programming: dynamic resource assignment, efficient state access, portability,

1 2

Lagniappe is a Cajun-French word meaning “a little something extra.” If programmers give us a small amount of extra information, we can give them much added benefit. When we refer to a processor we are referring to one chip. A processor may have several cores, a core being a fully functional processing element with its own low-level cache. Operating systems typically see all cores as separate “processors.”

4

T.L. Rich´e, H.M. Vin, and D. Batory

and parallelism. We demonstrate experimentally the effectiveness of Lagniappe’s mappings with two stateful RPA case studies. We begin with a review of the key traits of the RPA domain, followed by an MDEdescription of how Lagniappe parallelizes RPAs by transformations.

2 The Request-Processing Application Domain 2.1 General Structure An RPA is specified by a directed graph of A Operators (also known as components, filters, and stages [14,22]). Each A Operator may contain multiple inputs and outputs, and may generate zero, one, or multiple requests when processing an incoming request. Requests flow through A Connectors between A Operators. A Connectors are typed by the messages they carry and Ports are typed by the messages they send or receive. A request enters the application at the head of the graph and passes from one A Operator to the next until an A Operator either drops the request (i.e. the system reclaims the resources it assigned to request) or the request exits the graph. Figure 1 depicts a model of an RPA we call the AttackDetector that examClassifier Service ines incoming requests for patterns that Inspect SrcDst State FileN State would suggest a network attack.3 The AttackDetector has three A Operators: Classi f ier, Inspect, and Service. Fig. 1. The AttackDetector Application The behavior of AttackDetector is straightforward: requests enter Classi f ier and are marked as either good or bad. Bad requests are dropped immediately. Good requests move to Inspect where it performs a test to determine if the request is part of an attack. If the request is not an attack, Inspect forwards the request untouched to Service. If Inspect thinks the request may be part of an attack, the request is dropped and Classi f ier is notified to drop all future related requests. Requests that pass Inspect are processed by Service that represents any service, such as a webserver or database engine. AttackDetector processes two different types of requests: dotted lines represent notifications of suspicious activities and solid lines are normal paths of requests. 2.2 Request Flows and Flow Signatures The processing of a request may have no impact on processing other requests in a system. At other times, A Operators may process related requests. A flow is any sequence of requests (not necessarily adjacent in arrival time) that share some property, for example a source and destination network address pair. A flow signature is a function that maps a request to a flow identifier. All requests that map to the same flow identifier are said to be in the same flow. 3

By attack we could mean worm propagation, distributed denial of service, or simple “hacking.” The exact definition is not important for this example.

Transformation-Based Parallelization of Request-Processing Applications

5

An application may exploit several different flow signatures. In AttackDetector, there are two flow signatures: SrcDst and FileN. Classi f ier uses (source, destination) address pairs to identify flows while Service uses file names contained in the request. 2.3 Persistent A Operator State Unlike classic pipe-and-filter architectures where filters are stateless [22], many requestprocessing applications maintain persistent state—state that exists beyond the processing of any one request. Accesses to persistent state can dominate the time it takes an A Operator to process a request [17] and na¨ıve concurrent access can introduce contention for locks [20]. Persistent state is essential in many RPAs because the logic of an A Operator may depend on the requests it has previously processed. Persistent state falls into two classes. The first assumes no relationship between requests. The second uses flow identifiers as keys to data associated with a flow, which we refer to as flow state. In AttackDetector, Classi f ier maintains a mapping of flow identifiers to state representing the status (good/bad) of the flow. Service contains application state (such as webpages) and uses a different flow identifier. 2.4 Application Guarantees Application designers create RPAs to meet specific throughput or latency guarantees. Such guarantees are often defined by a business-driven service level agreement (SLA). Programmers may not care to maximize performance (e.g. maximize throughput or minimize latency) but rather to just meet the throughput or delay guarantees of an SLA. For example, a company may sell different levels of service. Different applications running “in the cloud” may receive different amounts of resources and achieve different levels of performance based on the fee paid by their customers.

3 Models and Transformations of RPAs Lagniappe identifies two types of parallelism in an application: task parallelism (breaking the application into pipeline stages) and data parallelism (replicating a stage during runtime to process different requests in parallel). Programmers specify an RPA as a single- model that conforms to the basic application structure presented in Section 2 with no knowledge of underlying multi- system. That is, the model in Figure 1 conforms to a domain defined by a metamodel A (“A” being short for Application). Two other models are used as input to Lagniappe: W is the metamodel of typical A Operator workloads, and M is the metamodel of multi- systems. The input to Lagniappe is a model from each of these three domains. The Lagniappe translator is depicted in Figure 2. Lagniappe is currently a pair of M2T transformations A2C : A,W, M → C, which maps a (A,W ,M) triple to a C++ module, and M2C : M → C, which maps M to another C++ module. In the next sections,

6

T.L. Rich´e, H.M. Vin, and D. Batory source modules

sequential

A

A2C

C++

Application Programmer

M2T

W

workload

M

System Programmer

PROF

E

PIPE

P

pipeline parallelism

profiling

R

REP

M2C

multi* platform

replicated parallelism

Lagniappe

Fig. 2. The Lagniappe Translator

we offer a more advanced description of Lagniappe by decomposing the A2C transformation into a series of M2M transformations (REP • PIPE • PROF)4 followed by a simple M2T transformation R2C. That is, A2C = R2C • REP • PIPE • PROF. We explain our work using metamodel instances. The details of our metamodels are given in an extended technical report [21], but none are complex (less than 10 entities each). These metamodels make explicit the concepts that are implicitly well-known in this domain—practitioners have described their applications in these terms for years [14]. 3.1 A: The Single- Application Model Figure 1 is a model of AttackDetector that conforms to A. Beyond what we presented earlier, Classi f ier is stateful and uses the Flow Signature SrcDest to map requests to flow identifiers. Service is also stateful and uses the Flow Signature FileN to map the names of files contained in the request payload to a flow identifier. The input/output ports of all A Operators have the data-request type except for the A Connector from Inspect to Classi f ier that reports attacking flows (the dashed arrow in Figure 1). A key property of an A model is that no two A Operators can access the same persistent state; doing so forces programmers to model task parallelism in the application as each A Operator can now run independently with no contention for shared state. 3.2 Performance Estimates (PROF Transformation) The PROF : A,W, M → E transformation uses the application, workload, and platform models to produce an annotated application model in domain E (for Estimate). Metamodel E is a minimal extension to A: E preserves all of the objects and relationships in A, and adds one attribute to each A Operator to provide elementary performance information. The programmer provides an average case workload (W ) for each A Operator and Lagniappe determines the A Operator’s average execution time on platform M through profiling. These estimates are added to the A model to produce an E model and are used in the transformations that we discuss next. 4

The order in which transformations are composed is well-understood in the domain—first identify stages of the application that are independent, and then determine how to replicate these stages.

Transformation-Based Parallelization of Request-Processing Applications

7

3.3 Task Parallelism (PIPE Transformation) Lagniappe parallelizes an application in two ways. The first identifies pipeline stages (i.e. task-parallel comPO1 putations). We call these stages P OperClassifier Service Inspect ators for pipelined A Operators. One or more A Operators are contained in a P Operator. Fig. 3. P Model of AttackDetector A Connectors are mapped to P Connectors, which are one of two types: Call or Queue. An A Connector is mapped to a Call if it is internal to a P Operator. A Call implements a P Connector by method calls. All other P Connectors are Queues. Queues provide an asynchronous FIFO abstraction between P Operators. P is the metamodel that defines the domain of pipelined applications using P Operators and P Connectors. Figure 3 shows the result of transforming the AttackDetector in Figure 1 to its P model counterpart (note that the performance information of E is not shown). We refer to this transformation as PIPE : E → P. Queue

Call

SrcDst State

FileN State

Policy Discussion. A first thought is simply to use A Operators as pipeline stages and not go through the trouble of forming P Operators. While pipelining has its benefits, it also comes with overhead. Every time a request moves from one processing element to another it has to be enqueued and dequeued. As queueing overheads can be significant, it is important to keep the number of pipeline stages to a minimum. Given an equal number of parallel processing elements, we would rather have fewer pipeline stages with more chances to replicate stages than to execute separate pipeline stages on their own. This minimizes the overhead per request and provides more replication opportunities. We show in Section 4.2 that these are both desirable properties. To maximize replication, we greedily form P Operators and minimize the number of P Operators. Situations exist where an application may have A Operators that cannot be replicated for correctness reasons (the FT application in Section 4.1 is one). Thus, we allow application programmers to mark A Operators with a “Do Not Replicate” flag in A models, information that is preserved in the PROF and PIPE transformations. If PIPE encounters an A Operator with this flag, it is put into its own P Operator. While we cannot take advantage of data parallelism by replicating such a P Operator, we can take advantage of task parallelism by running these “Do Not Replicate” P Operators on different processors at the same time. We show in Section 4.2 pipelining the application in this situation improves throughput. Flow-Based Composite Policy. The formation of P Operators proceeds as follows: 1. Starting with incoming request sources, absorb A Operators into a P Operator along the application graph until an A Operator with the “Do Not Replicate” flag is found or the only available output Port has a different data type than the input.5 5

A Port with a different data type implies a control-data path through the application, and one that will not be externally visible.

8

T.L. Rich´e, H.M. Vin, and D. Batory

2. Do not absorb A Operators that have already been included in a P Operator (i.e. check for cycles). 3. After a depth first search is finished, collect remaining A Operators into P Operators based on flow signatures. These are A Operators that process control data and are most likely off of the application fast-path. Combining them usually does not impact performance and saves system resources (i.e. a smaller number of overall pipeline stages equals a smaller number of processing resources initially needed). Applying the above heuristic to Figure 1 produces one P Operator, shown in Figure 3. That is, Classi f ier, Inspect, and Service are put into P Operator PO1. The incoming A Connector for the P Operator PO1 is now a Queue. All of the A Connectors internal to PO1 are Calls. We could have used other policies. For example, memory may be limited in embedded platforms. Any one P Operator may have an upper bound on its code size [2]. For the class of RPAs that motivated our work, code size was not an issue and flow state was prevalent. If we needed to support another pipelining policy i, we would implement a different transformation PIPEi : E → P. More on this later. 3.4 Data Parallelism (REP Transformation) Lagniappe’s second parallelizing transformation takes advantage of data parallelism in an application. Individual pipeline stages are transformed to support processing multiple requests at the same time. Let R be the metamodel that defines the domain of applications that support replication and let transformation REP : P → R map a P representation of an application to an R representation. The first step in REP is to transform each P Operator into an R Operator. An R Operator contains platform-independent implementations of two mechanisms. The first is the data structures that map R Operator replicas to individual processing elements. The second is an adaptation trigger that requests more processing resources from the system when an R Operator becomes overwhelmed by its current workload. The processing element mapping is, at this point, underspecified as we have not yet finished pairing the application with a specific multi- platform and we do not replicate any R Operators until the workload requires it at runtime. We use the execution time annotations in E (which have been copied into P) to create an adaptation trigger implementation; we discuss our specific policy later in this section. The next step in REP is to replace all Queues in the application with LD Queues (the “LD” stands for load distributing). LD Queues implement a queue abstraction that distributes incoming requests amongst the replicas of an R Operator according to a policy (we use a policy based on flows and discuss alternatives later in this section). The REP transformation is completed with the addition of a special R Operator (Monitor) to the application graph. Monitor tracks resource usage across the application and makes decisions to allocate more processing elements to R Operators that request more resources. The Monitor is also underspecified because the amount of available resources is not yet known.

Transformation-Based Parallelization of Request-Processing Applications

LD

LD_Queue

9

PO1 Service Classifier

LD

Monitor

FSig1 State

LD

Inspect

FSig2 State Replication and Trigger

Replication and Trigger

LD

Fig. 4. R Model of AttackDetector

Figure 4 shows the AttackDetector after REP is applied. REP maps PO1 to an R Operator. Queues are replaced by LD Queues and Rep adds the Monitor R Operator. Bidirectional communication is added between Monitor and PO1. Policy Discussion. LD Queues distribute load among replicas using a policy based on flow signatures of their respective R Operators. Specifically, we pin flows to replicas. When a request is enqueued, an LD Queue uses the flow signature to generate a flow identifier. The LD Queue sends all requests from a flow to the same replica. The value of flow pinning is performance: load distribution policies are based on flow signatures. Flow pinning guarantees that all lock acquisitions based on flow identifiers will never block, thereby increasing RPA performance.6 If an R Operator has no flow signature attached to it, then the LD Queue uses a simple round-robin scheme for load-distribution. If an R Operator comprises multiple P Operators then we choose the Flow Signature from the A Operator with the largest execution time. The reasoning here is that using that Flow Signature will reduce contention for shared state the most within the R Operator if the R Operator is replicated during runtime. REP also adds an adaptation trigger to R Operators. This trigger uses the policy of Kokku et al. [16]. The application has a maximum latency value that all requests must observe. This latency is specified by an SLA. We split that latency amongst the R Operators and determine the maximum amount of time a request can spend in an LD Queue and not violate the delay guarantee. We translate this slack value to queue depth using Kokku et al.’s methodology. If the queue depth violates this determined value, the R Operator requests more resources. An LD Queue repins flows when the number of processing elements assigned to a R Operator changes. Our case studies have long-lived flows, so repinning was beneficial. Other polices do exist for load distribution, and are dependent on workload [6,7] and system properties [20]. Lagniappe presently hard-wires the above policy to implement REP : P → R. A different policy j would be implemented by different transformation, REPj : P → R. Choosing the best REP transformation is discussed later.

6

When locks are acquired based on flow identifiers, and all requests from the same flow go to the same replica, then two requests from the same flow will never be processed simultaneously guaranteeing a replica will never block waiting to acquire a lock.

10

T.L. Rich´e, H.M. Vin, and D. Batory

3.5 Code Generation (R2C Transformation) Lastly, Lagniappe performs a simple M2T transformation to map an R model to a C++ module that is platform-independent. The binding of the application code to a particular multi- system implementation is done at runtime (which we discuss in Section 3.7). The Lagniappe library allows us to generate platform-independent code as it acts as an adaptor between the generated C++ module and the multi- system. 3.6 System Models M (for multi- system) denotes the domain/metamodel of system models that support fully parallel (pipelined and replicated) applications. An M model consists of four entities: Elements, Channels, Mutexes, and Groups. Elements, short for processing elements, represent an abstraction that can support independent computation. They can be software threads (such as classic UNIX pthreads) or actual hardware contexts (such as hardware threads of an embedded system). Channels allow data to flow between Elements. A Channel must support multiple queues per Element to allow load sharing between R Operators (and the separate incoming ports of R Operators) assigned to the Element. Mutexes provide a way to ensure consistency when multiple Elements execute a replicated R Operator at the same time. Finally, Groups signify relative data sharing costs amongst Elements (for example, the cores of one physical CPU are in a Group, but the cores of two separate physical CPUs are not). The Lagniappe translator maps an M model to a C++ module by the M2T transformation M2C : M → C. By separating the modeling of the multi- systems (M) from that of the RPAs (A), RPA models are portable because they do not have to be modified for different multi- systems. With changes to M models, we have run Lagniappe applications on Linux, Mac OS X, and OpenSolaris multi- systems. 3.7 Run-Time Binding of Applications to Platforms To recap, Lagniappe uses transformation A2C to map a model a of an RPA to a C++ module ma and transformation M2C to map model m of a multi- system to another C++ module mm . Once ma and mm are compiled, they are linked with a module mbind in the Lagniappe run-time library to produce a multi- executable of a. The library module mbind defines a generic way to map R Operators and LD Queues to multi- Elements and Channels at run-time. This mapping has two parts: 1. The Monitor R Operator now has a complete list of system resources and knows which Elements have been assigned to which R Operators and which Elements are free to assign during runtime when an R Operator requests more resources. 2. Locking calls in the R Operator modules are mapped to Mutex implementations.

4 Case Studies We use two different applications to show the versatility and performance of Lagniappe: 1) a concrete version of our running AttackDetector example and 2) a fault-tolerant replicated-state machine, called FT . AttactDector is now familiar; we next discuss FT .

Transformation-Based Parallelization of Request-Processing Applications

11

4.1 The FT Application FT is the part of a replicated-state machine that decides the order in which requests are processed by a server (such as our AttackDetector application). We reengineered a hand-coded state-of-the-art prototype of a replicated-state machine for faulttolerant servers [3]. Our motivation to do so was to show that Lagniappe is suitable for complex applications as well as simple ones. Figure 5 shows a model of the FT application. FT attaches to three separate networks: the clients submitting requests, Clients cleaner the servers that execute requests, and copies of FT on different machines logRequest orderProtocol Agreement Servers that together decide upon the order of requests. FT is part of a larger Fig. 5. The application model for the FT distributed-application running across application many machines that make up the abstraction of one always available and correct server. Clement, et al. give a full description of their version of the application [3]; we describe its key details below. Requests from clients arrive at the orderProtocol A Operator, where they are sent to the cleaner to have their digital signatures verified. If the signature is valid, the request is returned to orderProtocol.7 orderProtocol then initiates the actual agreement protocol with FT copies on other machines. The application copies run a three-phase protocol where the next message to be processed is proposed, accepted as a valid proposal, and then voted upon. If enough FT copies agree, the message is marked as the next message to be executed. orderProtocol then sends the request to logRequest where the request is logged to stable storage for purposes of failure recovery and asynchronous network support. After the write completes, logRequest sends the request onto the network to execution servers that process the request. The logRequest also alerts the orderProtocol that the logging has completed to disk. Both the orderProtocol and the logRequest A Operators have persistent state, and share a flow identifier that is the sequence number of the incoming requests. Different from AttackDetector, FT does not have multiple flows in flight at the same time. The entire purpose of the FT application is to serialize incoming requests from multiple clients. FT assigns each request a sequence number that denotes that request’s place in the order. The sequence number defines the only flow. The cleaner A Operator is stateless and could be replicated during runtime. Given the specific requirements of the FT application, each A Operator in Figure 5 is transformed into its own R Operator. seqNo State

7

seqNo State

While it may seem we could model the application as more of a pipeline, with the beforecleaner and after-cleaner portions of orderProtocol as their own A Operators, both of these A Operators would access the same state. As mentioned earlier, a key constraint of A models is that different A Operators are not allowed to share state.

12

T.L. Rich´e, H.M. Vin, and D. Batory

4.2 Experimental Results Attack Detector. Figure 6(a) shows the results of scaling the number of clients for AttackDetector using three different policies for forming P Operators and R Operators. The x-axis is the number of simultaneous clients and the y-axis is average throughput. The Service Operator performs work to simulate a significant real-world web service. Each client sends a request for a file and waits until it gets a response to send another request. AttackDetector was executed on a 16-core server running Linux 2.6.16. The clients were distributed over several 4-core servers running the same version of Linux. The results of three different policies are shown: (1) using the programmer-provided Operators as P Operators, (2) using the P Operator heuristic with the first Operator’s Flow Signature as the load-balancing policy, and (3) our P Operator heuristic with the most expensive Operator’s Flow Signature as the load-balancing policy. The pipelined version scales the worst as it introduces latency between the stages, unnecessarily increasing the amount of time each request takes to process. Heuristic (2) scales better, but as the client load increases the lock contention in the Service Operator takes its toll, limiting the throughput gains from replication. Finally, the heuristic using the Service Flow Signature (3) scales the best as it eliminates lock contention by using flow pinning, but still replicates the execution taking more advantage of the available parallelism. Figure 6(b) shows the benefit of pipelining an application when the Operators have the “Do Not Replicate” flag set in the application model. We change the AttackDetector application to have heavy-weight computation in both Classi f ier and Service as well to set the “Do Not Replicate” flag in both. As the number of clients on the x-axis increases, the pipeline version scales throughput better. This shows that when replication is not an option, pipelining can still be beneficial. Figure 6(c) shows how the properties of the underlying multi- system affect the choice of P Operators during the PIPE transformation. We strip the A Operators to their minimum functionality so that overhead of the Channel implementation is significantly more than any of the A Operators. In this case, pipelining introduces more latency than that of the A Operators, and thus a better solution is to combine all the A Operators into a single P Operator. Even in the situation where all A Operators are marked “Do Not Replicate,” keeping them together is the better option when the A Operator cost is small. FT. Figure 6(d) summarizes our experiments with the FT application. For these experiments we ran the application on an 8-core system running Linux 2.6.16. The clients and servers ran on 4-core systems running the same version of Linux. We ran three copies of the FT application, each on their own machine. The x-axis shows throughput in kreqs/s and the y-axis shows latency in ms. We scale the number of clients as we move along the line to push the systems to their maximum throughput. Lagniappe performs comparably (within 15%) to the hand-coded and highly-optimized Java version. We posit that this slowdown is acceptable. Our version is based on a C++ translation of the original highly-tuned Java application, and the system implementation (threads, queues, etc.) in the original were written specifically for the application. These custombuilt mechanisms take advantage of deep application information, overwhelming any performance advantage of switching from Java to C++. By separating the application

900

90

800

80

700 600 500 400 300 200

FS Heuristic Basic Heuristic Pipe

100 0 0

Throughput (reqs/sec)

Throughput (reqs/sec)

Transformation-Based Parallelization of Request-Processing Applications

13

70 60 50 40 30 20 Pipe No-Pipe

10 0 0

10 20 30 40 50 60 70 80 90 100 Clients

5

10 15 20 25 30 35 40 45 50 Clients

(a) Different policies for forming P Operators (b) Benefits of pipelining with the “Do Not Replicate” flag set. in AttackDetector 16

30 25 20 15 10 5

No-Pipe Pipe

0 0

50 100 150 200 250 300 350 400 450 500 Clients

(c) Pipelining for very small Operators.

Throughput (kreqs/sec)

Throughput (kreqs/sec)

35

14 12 10 8 6 4 Original Lagniappe

2 0 0

20

40

80 60 Clients

100

120

140

(d) Performance of Lagniappe FT and the original Java implementation.

Fig. 6. Experimental Results for AttackDetector and FT

from the system code (unlike the the Java version) it is now trivial to upgrade to more efficient queueing or processing mechanisms with the Lagniappe version. The results here point towards us developing a next-generation MDE tool that works with Java components. An extensible, Java-based tool would allow us to use the original, supported FT implementation that is continually being updated and extended. Furthermore, a Java-based tool would make supporting the application servers in this domain (i.e. web services such as Hadoop [12]) possible as well as the predominant language of these services is Java.

5 Extensibility of Lagniappe We initially developed Lagniappe using a single PIPE and REP transformation. Our case study experiences soon made it clear that alternatives were needed. Instead of generalizing our existing PIPE transformation, bundling the decision of which P → R mapping to use and applying that mapping, we chose to separate these concerns into two distinct mappings: ChoosePipe and PIPEi . ChoosePipe :

14

T.L. Rich´e, H.M. Vin, and D. Batory

(A,W, M) → (A → P) is a higher-order transformation that selects a particular PIPEi transformation given an application model (A), workload (W ), and a multi- system (M). If the execution time of the pipelining infrastructure (queues, load-distribution, etc.) is more than the overall execution time of the P Operators then it is not worth forming pipeline stages, and a trivial (A → P) map suffices. However, if a system were to offer a hardware queueing mechanism, pipeline stages would incur small overhead relative to even the fastest P Operators encouraging the use of yet another (A → P) mapping. Similar arguments apply to supporting multiple REPj transformations and the selection of an appropriate REPj by a ChooseRep : (A,W, M) → (P → R) transformation. For example, different workload, system, and application characteristics affect which loaddistribution policy is optimal [6,7,20]. We know that there can be many different PIPEi and REPj transformations, and factoring out the selection of which transformation to use makes it easier to extend Lagniappe in the future.

6 Related Work Dataflow programming can be recast in today’s MDE technology as mapping models of dataflow applications to executables. While we are aware of pioneering MDE work in signal processing that is similar to RPAs [23], the most well-known work on parallelizing dataflow applications is largely outside the MDE literature [13]. Lagniappe differs from these traditional coarse-grain dataflow models as its operators do not need to wait for all its incoming ports to have data to execute. Also, RPAs can be expressed by coordination languages [19], which also can be recast in an MDE setting. Labview [18] and Weaves [10] are among the earliest environments for programming RPAs on multi-threaded platforms (automatic pipelining and replication was not a focus of these systems). Click [14] is the most well-known packet-processing programming environment, allowing programmers to specify applications in terms of a connected graph of elements. Click supports task parallelism [1], but not data parallelism, and is written as a Linux module, tying it to a specific platform (while user-mode Click exists, programmers are forced to use the kernel for serious development). The SAI architectural style [8] provides an elegant metamodel for RPA construction. SAI supports both persistent and volatile state, but does not provide mechanisms for creating an executable. Further, the application is taken as is, and no transformations are applied to further extract parallelism out of the application. Stream environments (such as Streamit [24] and Streamware [11]) provide programmers with new languages that focus on stream processing. Stream programs are written in a fashion similar to standard programming, i.e., no separation between coordination and execution. Stream compilers determine how to separate the functionality of the program (usually with keyword help from the programmer) into tasks that are then scheduled on the multi- resources of the system. This is a more fine-grained approach to parallelism. Stream languages work well in signal-processing applications and lowlevel network programs that are more computationally bound and often side-effect free. Finally, the issue of extensibility is largely absent in all of the above works. Extensibility is, we believe, the key to highly-adaptable and general RPA programming tools.

Transformation-Based Parallelization of Request-Processing Applications

15

Lagniappe captures this extensibility in terms of higher-order transformations, selecting transformations to use based on input models.

7 Conclusions RPAs are an important class of applications in multi- systems. Existing tools do not adequately support the task and data parallelism that is inherent in RPAs. Further, some tools force programmers into the operating system kernel for serious development. The need for a better approach lead us to design and implement Lagniappe, a translator that transforms simple models of RPAs to high-throughput multi- executables. Lagniappe addresses the major challenges of RPA programming: portability (RPA models are portable in that they do not have to be modified for different multi- systems), efficient state access (load distribution policies are based on flow signatures, guaranteeing that all lock acquisitions based on flow identifiers will never block), dynamic resource assignment (accomplished by Lagniappe run-time libraries), and effective support for task and data parallelism. Although the current version of Lagniappe is a sophisticated model-to-C++-text translator, we found it invaluable to explain the mappings of Lagniappe in a more advanced MDE-style which uses multiple model-to-model transformations prior to a simple model-to-C++-text transformation. Further our experience with Lagniappe reveals the importance of transformation extensibility: effective policies that map higherlevel models to lower-level models may be influenced by platform, workload, and application-specific details. We have realized transformation extensibility through the use of higher-order transformations, which can select appropriate mappings to use. Two case studies were presented that show Lagniappe’s effectiveness. The first was a custom-built RPA that detects generic network attacks. It demonstrated the efficacy of our policy generation for parallelism. The second reengineered a hand-crafted state-of-the-art replicated state machine. It demonstrated Lagniappe’s ability to support complicated applications with minimal performance impact. Acknowledgments. We gratefully acknowledge the support of the National Science Foundation under Science of Design Grant #CCF-0724979.

References 1. Chen, B., Morris, R.: Flexible Control of Parallelism in a Multiprocessor PC Router. In: USENIX Annual Technical Conference, pp. 333–346. USENIX (2001) 2. Chen, M.K., Li, X.F., Lian, R., Lin, J.H., Liu, L., Liu, T., Ju, R.: Shangri-La: Achieving High Performance from Compiled Network Applications while Enabling Ease of Programming. In: ACM SIGPLAN Conference on Programming Language Design and Implementation, pp. 224–236. ACM, New York (2005) 3. Clement, A., Kapritsos, M., Lee, S., Wang, Y., Alvisi, L., Dahlin, M., Rich´e, T.L.: Upright Cluster Services. In: ACM SIGOPS Symposium on Operating Systems Principles, pp. 277– 290. ACM, New York (2009) 4. Microsoft directshow, http://msdn.microsoft.com/en-us/library/ms783323.aspx

16

T.L. Rich´e, H.M. Vin, and D. Batory

5. Emma, P.: The End of Scaling? Revolutions in Technology and Microarchitecture As We Pass the 90 Nanometer Node. SIGARCH Computer Architecture News 34(2), 128 (2006) 6. Estan, C., Varghese, G.: New Directions in Traffic Measurement and Accounting: Focusing on the Elephants, Ignoring the Mice. ACM Transactions on Computer Systems 21(3), 270– 313 (2003) 7. Estan, C., Varghese, G., Fisk, M.: Bitmap Algorithms for Counting Active Flows on HighSpeed Links. IEEE/ACM Transactions on Networking 14(5), 925–937 (2006) 8. Francois, A.R.J.: A Hybrid Architectural Style for Distributed Parallel Processing of Generic Data Streams. In: International Conference on Software Engineering, pp. 367–376. IEEE Computer Society, Los Alamitos (2004) 9. Gay, D., Levis, P., von Behren, R., Welsh, M., Brewer, E., Culler, D.: The nesC Language: A Holistic Approach to Networked Embedded Systems. In: ACM SIGPLAN Conference on Programming Language Design and Implementation, pp. 1–11. ACM, New York (2003) 10. Gorlick, M.M., Razouk, R.R.: Using Weaves for Software Construction and Analysis. In: International Conference on Software Engineering, pp. 23–34. IEEE Press, Los Alamitos (1991) 11. Gummaraju, J., Coburn, J., Turner, Y., Rosenblum, M.: Streamware: Programming GeneralPurpose Multicore Processors Using Streams. In: International Conference on Architectural Support for Programming Languages and Operating Systems, pp. 297–307. ACM, New York (2008) 12. Hadoop, http://hadoop.apache.org/core/ 13. Johnston, W.M., Hanna, J.R.P., Millar, R.J.: Advances in Dataflow Programming Languages. ACM Computing Surveys 36(1), 1–34 (2004) 14. Kohler, E., Morris, R., Chen, B., Jannotti, J., Kaashoek, M.F.: The Click Modular Router. ACM Transactions on Computer Systems 18(3), 263–297 (2000) 15. Kokku, R., Rich´e, T.L., Kunze, A., Mudigonda, J., Jason, J., Vin, H.M.: A Case for RunTime Adaptation in Packet Processing Systems. SIGCOMM Computer Communication Review 34(1), 107–112 (2004) 16. Kokku, R., Shevade, U., Shah, N., Mahimkar, A., Cho, T., Vin, H.: Processor Scheduler for Multi-Service Routers. In: IEEE International Real-Time Systems Symposium, pp. 225–235. IEEE Computer Society Press, Los Alamitos (2006) 17. Mudigonda, J.: Addressing the Memory Bottleneck in Packet Processing Systems. Ph.D. thesis, The University of Texas at Austin (2005) 18. National Instruments LabView, http://www.ni.com/labview/ 19. Papadopoulos, G.A., Arbab, F.: Coordination Models and Languages. In: Advances in Computers, pp. 329–400. Academic Press, London (1998) 20. Rich´e, T.L., Mudigonda, J., Vin, H.M.: Experimental Evaluation of Load Balancers in Packet Processing Systems. In: Workshop on Building Block Engine Architectures for Computers and Networks, Boston, MA (October 2004) 21. Rich´e, T.L., Vin, H.M., Batory, D.: Transformation-Based Parallelization of RequestProcessing Applications. Tech. Rep. TR-10-16, Department of Computer Science, The University of Texas at Austin (2010) 22. Shaw, M., Garlan, D.: Software Architecture: Perspectives on an Emerging Discipline. Prentice-Hall, Englewood Cliffs (1996) 23. Sztipanovits, J., Karsai, G., Bapty, T.: Self-Adaptive Software for Signal Processing. Communications of the ACM 41(5), 66–73 (1998) 24. Thies, W.: Lang. and Compiler Support for Stream Programs. Ph.D. thesis, MIT (February 2009) 25. Data parallelism, http://en.wikipedia.org/wiki/Data_parallelism 26. Task parallelism, http://en.wikipedia.org/wiki/Task_parallelism

Model Driven Orchestration: Design for Service Compatibility Georg Grossmann, Michael Schrefl, and Markus Stumptner University of South Australia, Advanced Computing Research Centre, Mawson Lakes, SA 5095, Adelaide, Australia [email protected]

Abstract. Service composition is a recent field that has seen a flurry of different approaches proposed towards the goal of flexible distributed heterogeneous interoperation of software systems, usually based on the expectation that such systems must be derived from higher level models rather than be coded at low level. In practice, achieving service interoperability nonetheless continues to require significant modelling approach at multiple levels, and existing formal approaches typically require the analysis of the global space of joint executions of interacting services. Based on our earlier work on providing locally checkable consistency rules for guaranteeing the behavioral consistency of inheritance hierarchies, we propose a model-driven approach for creating consistent service orchestrations. We represent service execution and interaction with a high-level model in terms of Petri-net based Behavior diagrams, provide formal criteria for service consistency that can be checked in terms of local model properties, and give a design methodology for developing services that are guaranteed to be interoperable.

1

Introduction

The dynamic interaction of systems using service-oriented architectures is one of the key challenges faced in the implementation of state-of-the-art business systems. Inevitably, separately developed systems rely on disparate models and no matter how flexible the infrastructure is, it requires major effort to establish interoperability via the mutual adaption of coexisting business processes. The paradigm that has emerged in recent years as the most widespread and practical view towards reaching this goal is that of service orchestration: the notion that the service processes engaged in an interaction (also referred to as partner processes) are centrally managed by a coordination process, the orchestrator. A key advantage of this approach over the more decentralised choreography approach is that services can be incorporated in an orchestration without being aware that they are taking part in a larger business process. The development of service-oriented applications thereby, in some degree, recapitulates the concerns 

This research was supported by the Australian Research Council (ARC) under grant DP0988961.

D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 17–31, 2010. c Springer-Verlag Berlin Heidelberg 2010 

18

G. Grossmann, M. Schrefl, and M. Stumptner

of moldularity as studied in classical software systems for a long time. However, classical solutions cannot be readily adapted due to the concurrent nature of the architecture and the new langagues developed for describing such processes, the foremost of which at this point is BPEL [12]. Our goal in this paper is to provide a formal basis for developing demonstrably correct orchestrations of service processes. We refer later to the process that will be designed as the orchestrator and the given processes which are orchestrated by the designed process as the partner processes. We consider the problem from a high-level, conceptual perspective, that abstracts from the details of the interaction paradigm. For example, we consider the distinction between synchronous and asychronous communication, frequently explicitly represented by communication primitives in SOA approaches, to be a lower level concern and encapsulate in the underlying middleware. We abstract from the XML syntax that is the natural choice for the actual exchange of information in service-oriented environments but results in many platform-specific concerns. Instead we use a simple, powerful formalism to model high-level behavior of service processes. This enables us to not only provide formal criteria for service compatibility, but a methodology for developing compatible sets of services at PIM level before they are transformed to PSM level, e.g., transformation from a high-level business process models to BPEL orchestration file. The underlying principle is that of achieving a discipline of Design for service compatibility. Instead of hoping that, after designing a set of services, compatibility can be determined, which, as practice shows is unlikely to be the case, and will require complex modifications except in the most simple cases, the goal should be different. Services should be designed from the outset with a clear indication of what types of interactions they support. This does not mean that the general power of what can be achieved with service processes should be restricted, but that the way in which it is expressed should be amenable to determining and improving compatibility. We take here as a guide comparable past drives such as “design for reuse” or “structured programming”, which aimed at avoiding problems before-hand by requiring the use of basic program patterns (such as loop constructors instead of general gotos in the structured programming case). These restrictions simplify design, ease re-use, and enable later adaption. In our case the basic principle we are following is the classic separation of concerns, which in the case of service processes follow the general distinction between communication and processing. For an orchestrator, the concerns are (1) service usage and (2) coordination, and for a service (partner) process, they are (1) external service provision and (2) internal processing1. The methodology engendered by the Design for Compatibility approach is a gradual, multi-step approach in orchestration design with intermediate, simple 1

Note that internal processing can be provided in two ways. It could occur as part of external service provision during an “activity state” in message communication (activity triggering: start activity, internal processing, complete activity, with the last sending a response message). It could also occur in parallel to external service provision.

Model Driven Orchestration: Design for Service Compatibility

19

checks for service compatibility. We guarantee a set of local consistency properties. Starting with well-formed orchestrator and partner services, we can bring them into a form where service mappings can be established between them. We then can establish compatibility between the services based on the service mapping in a sequence of four straightforward checks. The formalism is presented in the next section. We then discuss the formal requirements that permit us to guarantee service compatibility, and give an overview of a design method that will produce a set of compatible services.

2

Orchestration Modeling

2.1

Modeling Process Behavior

We use the notation of Behavior diagrams that were originally developed for the design of object-oriented databases [10] and were later extended for modeling workflows [3]. A behavior diagram of an object type represents the possible life cycles of its instances by activities, states, and arcs corresponding to transitions, places, and arcs of Petri nets, and is here used to represent the different states of a process. The approach combines the simple formal semantics and well-understood properties of Petri nets with the clarity and intuitive understanding of an object-centered representation. When mapped to program code, activities are mapped to operations, and states to the pre- and postconditions of these operations. We extend the notation to clearly indicate message exchanges between processes. A key aspect of the representation is the use of labels that express the existence of particular parallel control flows (or threads2 ) within service process execution. Each label represents a particular “communication link” between the orchestrator and a service process. To capture complex orchestration patterns, multiple links per service process are permitted. In particular, the orchestrator may consist of different control flows for each service the services offer, i.e., control flows are “designed” from a stand-alone-perspective. By establishing communication links, parallel flows are mapped to partner services or orchestrators, but they are not linked to specific control flows within those other processes. In comparison to standard UML diagram types such as Statecharts (which emphasize states over actions) or Activity Diagrams (which emphasize activities over states), behavior diagrams give equal weight to states and transitions. We have investigated certain drawbacks of languages which focus either on states or transitions and proposed an extension of UML Activity Diagrams to overcome the limitations [7]. In particular, the concept of an “activity state” which represents the fact that a transition may have implicit processing or communication 2

A thread can support synchronous, asynchronous communication or both, but different communications within a thread cannot be interleaved, i.e., in asynchronous communication each outgoing message (send) must be eventually followed by a corresponding reply message (which may be delayed due to asynchronous communication) before the thread continues. However, multithreadedness of processes permits the rest of the process to continue in the meantime.

20

G. Grossmann, M. Schrefl, and M. Stumptner

delays associated with it, allows for abstracting away from a communication paradigm (i.e., asynchronous or synchronous) when describing a system3 . Compared to earlier work, we extend Labeled Behavior diagrams by a number of features to capture the interaction between multiple independent processes. These include the possibility of alternative completions of an activity (to provide for BPEL language concepts such as pick), and multiple initial states for providing the possibility to join interacting processes into a common diagram to be checked for consistency. The idea of labeling states and activities in labeled behavior diagrams is inspired by the way in which, in business processes guided by paper work, various carbon copies of a form are given different colors. Each business activity handles one or several copies of a form, it may collect several copies of a form from different input boxes, and it may distribute several copies of a form to different output boxes. A label in a labeled behavior diagram corresponds in this analogy to the color given to some copy of a form, an object corresponds to one filled-in form representing a particular business case, and the labels given to an arc identify those copies of a form that are delivered by a business activity to an output box or are taken by a business activity from an input box. Labels thus serve to identify parallel flows of control within a process. Definition 1 ((Labeled) Behavior Diagram) A behavior diagram BO = (SO , TO , FO , LO , lo ) of a process O (the subscripts are omitted if O is understood) consists of a set of states S = ∅, a set of activities T = ∅, T ∩ S = ∅, and a set of arcs F ⊆ (S × T ) ∪ (T × S), such that ∀t ∈ T : (∃s ∈ S: (s, t) ∈ F ) ∧ (∃s ∈ S: (t, s) ∈ F ) and ∀s ∈ S: (∃t ∈ T : (s, t) ∈ F ) ∨ (∃t ∈ T : (t, s) ∈ F ). There is a non-empty set of distinguished states of S, the initial states A, where for no t ∈ T : (t, α) ∈ F ; and states in A are the only states with this property. There is a non-empty set of distinguished states of S, the final states Ω, where for no s ∈ Ω and no t ∈ T : (s, t) ∈ F and the states in Ω are the only states with this property. L is a set of labels and l a labeling function which assigns a non-empty set of labels to every arc in F , i.e., l : F → 2L \ {∅}. The outgoing arcs of the initial state α carry all labels, i.e., L = (α,t)∈F l(α, t). A behavior diagram type specifies all legal sequences of life cycle states. A life cycle state (LCS) α is a subset of S ∪ T and a particular sequence of life cycle states of a process is referred to as life cycle occurrence of that process. A labeled behavior diagram B observes the label preservation property if for every t ∈ T the incoming and the outgoing arcs carry the same set of labels. It further observes the common label distribution property if all incident arcs of a state carry the same label set (Formal definitions of these properties see [13]).

3

There is no explicit time representation; activity states merely express that while a particular control flow is engaged in an activity, other things may be happening in the process in parallel.

Model Driven Orchestration: Design for Service Compatibility

21

Definition 2 (Start and completion of an activity). An activity t ∈ T can be started on a life cycle state σ, if for each label x in l(t) 4 one prestate of t carrying this label is contained in σ.5 The start of activity t on LCS σ yields life cycle state σ  = σ \ {s ∈ S | (s, t) ∈ F } ∪ {t}. An activity t ∈ T can be completed on a life cycle state σ with post state assignment St , if St contains for each label x of t exactly one post state of t carrying this label. The completion of activity t on σ yields life cycle state σ  = σ \ {t} ∪ St . Definition 3 (Reachable life cycle states). The set of life cycle states reachable from LCS σ, written R(σ), contains every LCS σ  of O that can be reached from σ by starting or completing any sequence of activities in T . We restrict our discussion of inheritance of object behavior to a meaningful subclass of behavior diagrams, to activity-reduced (i.e., every activity is potentially applicable), safe, and deadlock-free behavior diagrams. Incorporating these three requirements, formally defined in [13], follows standard practice in the Petri net field. 2.2

Modelling Process Interaction

We now use behavior diagrams to describe the two types of process involved in orchestration. Definition 4 (Orchestrator (Process)). An orchestrator (process) O is described by a life cycle diagram BO in which activities are partitioned into coordination activities T c and service usage activities T p , and in which labels are classified into coordination labels Lc and partner (link) labels Lp . Each service usage activity and each partner label is associated to one service process of a set of (abstract) partner processes P . Service usage activities are partitioned into triggering activities T ↓ and triggered activities T ? . A triggering activity of an orchestrator invokes exactly one activity of a service process, a triggered activity may only be invoked by an activity of a service process. An orchestrator is well-formed if (1) each coordination activity carries no partner label and (2) each service usage activity carries one or more partner labels of exactly one service process (and possibly also some coordination label). A key concern of our approach is the notion of separation between internal and external concerns of a service process. The external concerns, basically describe the interface of the process, while the internal computations should be hidden from other processes interacting with the service process externally. This distinction reflects standard object-oriented modelling concepts. We express it through the notion of well-formedness. 4 5

The label of an activity is given by the labels of its incident arcs, see [13]. Label preservation and common label distribution ensure that, providing start and completion rules are properly applied, there will be exactly one such prestate.

22

G. Grossmann, M. Schrefl, and M. Stumptner deliver

a1 d




d

    

a

     

a0

    

order

b0 a

delivery

b1 a

order

a

status

b2 a

a

terminate

b3 a

a

delivery

a3

b

b,c,d

   

d

b4 a

b

a2 a4

b,d

c status

a5 c

reject a

d

terminate

a6 c

a7 c

c reject

a

c

c

Fig. 1. Well-formed orchestrator process Buyer on the left hand side and well-formed partner process Accounting & Logistics on the right hand side

Example 1. The example used throughout the article is a simple procurement business process adapted from [15]. It consists of an orchestrator process called Buyer and a service process called Accounting & Logistics. The orchestrator process is shown in Figure 1 and consists of elements of four different types, (1) states are visualised in circles, (2) arcs indicate control flows and hold labels, activities are shown as rectangles where (3) triggering service usage activities are shaped to indicate an outgoing trigger, and (4) triggered service usage activities indicate an incoming trigger. The orchestrator (Buyer ) starts by triggering an order activity in an external service process which sends an order. Then it waits in state b1 for its activity delivery to be triggered which indicates that processing the delivery for the order started. In state b2 a buyer can choose either to reject the ordering process or request the status of the delivery by executing activity status. After the status is received the ordering process enters state b3 and the process can be terminated through activity terminate. The orchestrator process in Fig. 1 is well-formed p = {order, delivery, reject, status, because all service usage activities TBuyer terminate} are holding a single label a which is a partner label. Definition 5 (Partner (Process)). A partner (process) P is described by a behavior diagram BP in which activities and labels are classified into internal and external activities (T i and T e ) and labels (Li and Le ). Internal activities may only be invoked by the service provider. They are not visible to the orchestrator and do not invoke activities of the orchestrator. External activities are further partitioned into triggered activities T ? and triggering activities T ↓ . A triggered activity can only be invoked by an orchestrator using the service process, and a triggering activity invokes an activity of the orchestrar process. A service is passive if all its externa activities are triggered activities. In the context of orchestration in a given orchestrator, a service process is also referred to as partner process of an orchestrator – a partner process is well-formed if each internal activity carries no external label. Example 2. The orchestrator process Buyer from the previous example communicates with a partner process called Accounting & Logistics shown in Fig. 1. The partner process consists of states, labeled arcs, external triggering and triggered activities, and internal activities. It starts with receiving an order in the

Model Driven Orchestration: Design for Service Compatibility

23

external triggered activity order. After the completion of order, the execution continues in three parallel control flows. The flow at the top triggers internal activity deliver which creates a new delivery for the order. In the flow leading to state a3 , a delivery message is sent to the orchestrator by triggering external activity delivery which can be triggered only after deliver was executed. In the flow shown at the bottom there are two choices: Either the partner process receives a request from Buyer for sending a status, or one to reject the order. In the former case a status for the delivery is requested, in the latter the order is cancelled. If a status was sent to the requestor then the process waits for the termination indicated by the external triggered activity terminate. Three labels are used in the process: Labels b and c are external labels and label d is an internal label that ensures that deliver is executed before delivery. The service process Accounting & Logistics shown in Fig. 1 is a well-formed i partner process because all internal activities TAccLog = {delivery} hold no external label. Definition 6 (Service mapping). A service mapping m between a partner process P and an orchestrator process O maps each external activity of P to at most one usage activity of O, such that (1) triggered activities are mapped to triggering activities and (2) triggering activities are mapped to triggered activities. We extend m to a total function for unmapped external activities of P in that m(t) =  if m is not defined for t. Example 3. All external activities of the Accounting & Logistics partner dee = {order, delivery, reject, status, terminate} scribed in Example 2 are TAccLog and all service usage activities in the Buyer process described in Example 1 p are TBuyer = {order, delivery, reject, status, terminate}. The mapping funcp e tion m(t) maps activities t ∈ TAccLog to activities m(t) ∈ TBuyer where t and m(t) have the same name. Label b and c of the Accounting & Logistics service process are mapped to label a of the Buyer process. Establishing a mapping between the services in an orchestration means that for analysis purposes we can then remove all states that do not contribute to the mapping. A state is isolated if it has no ingoing and no outgoing arc. Definition 7 (Interaction-reduced orchestrator (partner)). The behavior diagram O of an orchestrator (partner) process is interaction-reduced with respect to service mapping m, if unmapped triggered activities, isolated states, and activities that are not potentially applicable have been removed. Example 4. The interaction-reduced Buyer (Accounting & Logistics) process with respect to service mapping is identical to the initial Buyer (Accounting & Logistics) process shown in Fig. 1. All activities in Buyer are covered by the service mapping and internal activity deliver in Accounting & Logistics is potentially applicable. Definition 8 (Well-behaved service mapping). A service mapping is wellbehaved if the interaction-reduced orchestrator service O and the interactionreduced partner service P are correctly labeled behavior diagrams that contain

24

G. Grossmann, M. Schrefl, and M. Stumptner

no unmapped triggering activities and have the same final states as O and P , respectively. Example 5. The service mapping between Accounting & Logistics and Buyer is well-behaving because both interaction-reduced processes are identical to the initial processes which are correctly labeled behavior diagrams that contain no unmapped triggering activities and have the same final states. The formal definition now enables us to examine the conditions under which an orchestration mapping can be successfully constructed. This will provide us with a set of conditions to determine compatibility. The next definition describes the central property we are concerned with in this paper, namely the conditions which orchestrator and partner service must satisfy so they are guaranteed to execute jointly without a conflict.

3

Service Compatibility

As mentioned earlier, a particular sequence of life cycle states of a process is referred to as life cycle occurrence of that process. We now define life cycle occurrences, and give a dual representation of life cycle occurrences, that of activation sequences. Essentially these two views represent the sequence of observed states and the sequence of operations that can produce a state. Definition 9 (Life cycle occurrence). A life cycle occurrence (LCO) γ of process O is a sequence of life cycle states σ1 , . . . , σn , such that σ1 = A, and for i = 1, . . . , n − 1 either σi = σi+1 , or there exists an activity t ∈ T such that either t can be started on σi and the start of t yields σi+1 or σi contains t and the completion of t yields σi+1 . Any subsequence of γ is called partial LCO. A LCO γ is called complete, if σn ⊆ Ω. Definition 10 (Activation sequence). An activation sequence μ of process O is a sequence of statements τ1 , . . . , τn (n ≥ 0), where τi = start(t) or τi = completion(t) for some t ∈ T ; μ is valid on some LCS σ1 ∈ R(A) if there is some partial LCO γ = σ1 , . . . , σn+1 of O where for i ∈ {1, . . . , n} σi+1 results from performing τi on σi and we say μ yields the trace γ. If n = 0, the activation sequence is called empty. An empty activation sequence can be applied on every LCS σ and yields trace [σ]. 3.1

Behavior Comparison

We now have the instrumentarium needed to describe relationships between lifecycles of different processes. The simplest of these is the concept of restrictions, which examines a behavior diagram from the point of view of a different process – basically, only the operations known to the other process are considered.

Model Driven Orchestration: Design for Service Compatibility

25

Definition 11 (Restriction of a life cycle occurrence). The restriction of a life cycle state σ  of a process O to process O, written σ  /O , is defined as σ  /O = σ  ∩ (SO ∪ TO ). The restriction of a life cycle occurrence γ  = [σ1 , . . . , σn ] of process O to process O, written γ  /O , is defined as [σ1 , . . . , σn ], where for i = 1, . . . , n: σi = σi /O . We use the concept of restriction to define what it means to extend a process. As described in [13], there are two basic ways of consistently extending a behavior diagram: either in observation consistent fashion (which means that the passive observer only cares to check whether the parts of the lifecycle known to him are consistent with the original), or in invocation consistent fashion (which means that a sequence of operations invoked in the original lifecycle must also work on the extended lifecycle). Definition 12 (Observation consistent extension). We refer to a behavior diagram BO = B  = (S  , T  , F  ) as an observation consistent extension of a behavior diagram BO = B = (S, T, F ), iff for every life cycle occurrence γ  of process O , γ  /O is a life cycle occurrence of B. Definition 13 (Weak invocation consistent extension). A behavior diagram BO = B  = (S  , T  , F  ) is a weak invocation consistent extension of a behavior diagram BO = B = (S, T, F ) if every activation sequence μ valid on A in B is also valid on A in B  and for their respective traces γ and γ  , γ = γ  /O holds. Note: In [13] we distinguished between weak and strong invocation consistency and showed that strong invocation consistency holds between two diagrams B and B  iff weak invocation consistency and observation consistency hold. Since the way in which we will join the partner and orchestrator later will always guarantee observation consistency, the join result will always be strongly invocation consistent iff it is weak invocation consistent. Therefore, from here on, we will not make a distinction between the two and refer only to invocation consistency. Rules6 that provide a local decision procedure for checking invocation consistency are introduced and discussed in [13]. 3.2

Checking Service Compatiblity

For the subsequent definitions, let O be the interaction-reduced behavior diagram of a well-formed orchestrator, P be the interaction-reduced behavior diagram of a well-formed partner, and m a well-behaved service mapping of P to O. For simplicity we assume that mapped activities are identical in P and O. 6

These are for references purposes: E1. Partial inheritance: (1) A = A, (2) t ∈ T  ∧t ∈ T ∧ (s, t) ∈ F ⇒ (s, t) ∈ F  , and (3) t ∈ T  ∧ t ∈ T ∧ (t, s) ∈ F ⇒ (t, s) ∈ F  ; E2. Immediate definition of prestates and post-states: (1) (s, t) ∈ F  ∧ s ∈ S ∧ t ∈ T ⇒ (s, t) ∈ F and (2) (t, s) ∈ F  ∧ s ∈ S ∧ t ∈ T ⇒ (t, s) ∈ F ; E3. Parallel extension: (1) (s, t) ∈ F  ∧t ∈ T  ∧t ∈ T ⇒ s ∈ S and (2) (t, s) ∈ F  ∧t ∈ T  ∧t ∈ T ⇒ s ∈ S; E4. Full inheritance: T  ⊇ T ; E5. Alternative extension: (s, t) ∈ F  ∧ s ∈ S  ∧ s ∈ S ⇒ t ∈ T .

26

G. Grossmann, M. Schrefl, and M. Stumptner

Definition 14 (Global life cycle state). A global life cycle state (gLCS) of an orchestrator O interacting with a partner process P is a pair σ = (σO , σP ) of life cycles states of O and P , respectively. Definition 15 (Global start or completion of an activity). An activity t can be globally started (completed) on a global life cycle state σ = (σO , σP ) if  – t∈ / TOp : t can be started (completed) on σO in O yielding LCS σO and gLCS  (σO , σP ) – t ∈ TPi : t can be started (completed) on σP yielding LCS σP and gLCS (σO , σP ) – t ∈ TOp ∧ t ∈ TPe : t can be started (completed) on σO in O and on σP in P   yielding LCSs σO and σP , respectively, yielding to gLCS (σO , σP ).

The global activation sequence, global life cycle occurrence, and global reachable life cycle state are defined as for their non-global counterparts. Definition 16 (Life cycle state restricted to a set of labels). A life cycle state σ restricted to a set of labels L, written σ/L , is the subset of states in σ that contain some label of L. Definition 17 (Service compatibility). Partner P is service compatible to orchestrator O if in any reachable global life cycle state (σO , σP ) – if t ∈ TOp ↓ can be started on σO in O, then t can be started on σP in P – if t ∈ TPe ↓ can be started on σP in P , then t can be started on σO in O – t∈ / TOp is started (completed) on σO in O, then start (or completion) of t   in O such that σO /Lp = σO /Lp yields a LCS σO i – t ∈ TP can be started on σP in P , then start (or completion) of t yields a LCS σP in O such that σP /Le = σP /Le The first two conditions express the requirement of invocation consistency, the second two conditions express observation consistency. Next, we describe how to determine the subset of a process that directly interacts with another process, which will enable us to compose the joint execution of both processes. Definition 18 (Orchestrator confined to partner process). The behavior diagram O of an orchestrator process confined to a partner process P , written O[P ], consist of the activities, states and arcs that carry a partner label associated with P , and of the set of labels associated with these arcs. Example 6. The process Buyer[AccLog] which is the Buyer process confined to partner Accounting & Logistics is identical to the Buyer process shown in Fig. 1 because label a is mapped to the partner process and all elements of Buyer hold that label. Definition 19 (Partner process confined to orchestrator). The behavior diagram P of a partner process confined to orchestrator O, written P [O], consists of the activities, states and arcs that carry an external label.

Model Driven Orchestration: Design for Service Compatibility

27

Example 7. The process AccLog[Buyer] which is the Accounting & Logistics process confined to orchestrator Buyer is identical to the Accounting & Logistics process shown in Fig. 1 because external labels b and c are mapped to Buyer and all elements except internal activity deliver of Buyer hold that label. Activity deliver is included because it holds internal label d which is also held by some of the external activities. Definition 20 (Redundant state). A state s ∈ S is redundant in a behavior diagram B if for every activity t and every reachable life cycle state σ, t can be started on σ if and only if t can be started on σ \ {s} in the behavior diagram created from B by removal of s and its incident arcs. We now have all parts in place to combine the execution of two processes in an orchestration. Definition 21 (Interaction join of services). The interaction join of the behavior diagrams of an orchestrator O and a service P based on service mapping m, denoted by O  P , is the behavior diagram (SO ∪ SP , TO ∪ TP , FO ∪ FP , LO ∪ LP ), where mapped activities are considered identical and all other elements are considered different. The orchestrator-focused interaction join O[P ]∗  P is given by the interaction join O[P ]  P in which states of SP that are redundant but not final have been removed. The partner-focused interaction join P [O]∗  O is given by the interaction join P [O]  O in which states of SO that are redundant but not final have been removed. Example 8. Fig. 2 shows the interaction join AccLog[Buyer]  Buyer which represents the interaction join of partner process Accounting & Logistics confined to Buyer with the Buyer process. The mapped activities order, delivery, status, and terminate are considered as identical. In the figure, the type of each activity a1

deliver a2

a0 b0

order

a3

delivery

a4

b1 b2

a5

status

a6

terminate

b3

a7

b4 reject

Fig. 2. Interaction join AccLog[Buyer]  Buyer with redundant states in grey. The business process without redundant states represents the interaction join AccLog[Buyer]∗  Buyer. (Note that the arc labels were removed to simplify the notation. They are not required in the further analysis.).

28

G. Grossmann, M. Schrefl, and M. Stumptner

(triggered or triggering) is shown from the perspective of the AccLog process. All states S = {b1 , . . . , b4 } and arcs with label a from Buyer are inserted into the partner process. The interaction join AccLog[Buyer]∗  Buyer is AccLog[Buyer]  Buyer without redundant states b0 , b1 , and b3 , which are depicted in grey in Fig. 2. The interaction join Buyer[AccLog]∗  AccLog is identical to the interaction join AccLog[Buyer]∗  Buyer except that states a0 , a3 and a6 are replaced by b0 , b1 and b3 , respectively. Our goal from here on is to show how service compatibility can be derived via local checks based on the behavior diagrams of the two processes. Lemma 1. Given orchestrator O, partner service P , and global activation sequence τ : The global life cycle state (σO , σP ) that results from application of τ on the initial states of O and P is given by the restriction to O and P of the life cycle state σ that results from application of τ on the initial life cycle state of the interaction join of O  P , i.e., σO = σ/O and σP = σ/P . Proof: For all proofs see technical report [8] to this paper. Lemma 2. Let O be an orchestrator and P a service process. Then the orchestrator-focused interaction join O[P ]∗  P is an observation consistent extension of O[P ] and the service-focused interaction join P [O]∗  O is an observation consistent extension of P [O]. Lemma 3. Property service compatibility Def. 17 is satisfied for any orchestrator service O and partner service P . We now show the requirements for service compatibility between an orchestrator and a passive partner process (i.e., one that does not trigger activities in the orchestrator). Theorem 1. Given an orchestrator O and a passive service P . P is service compatible to O if and only if O[P ]∗  P is an invocation consistent consistent extension of O[P ]. Next, we extend our results to the more general case where the partner process may itself trigger activities in the orchestrator. Definition 22 (Activity-specific invocation consistent extension). A behavior diagram B  = (S  , T  , F  ) is an invocation consistent extension of a behavior diagram B = (S, T, F ) with respect to activity t ∈ T if in every reachable life cycle state σ of B on which t can be started (completed), t can be started (completed) in every reachable life cycle state σ  of B  such that σ  /B = σ and for the resulting life cycle states σ ˆ and σ ˆ , σ ˆ  /B = σ ˆ. Theorem 2. Given behavior diagram B  = (S  , T  , F  ) that is an observation consistent extension of behavior diagram B = (S, T, F ) with T ⊆ T  . B  is an invocation consistent extension of B if and only if B  is an invocation consistent extension of B with respect to every activity t ∈ T .

Model Driven Orchestration: Design for Service Compatibility

29

Theorem 3. Given an orchestrator O and a partner service P , P is service compatible to O if and only if O[P ]∗  P is an invocation consistent extension of O[P ] with respect to every triggering activity t of O and P [O]∗  O is an invocation consistent extension of P [O] with respect to every triggering activity t of P . Example 9. For checking service compatibility between AccLog and Buyer we first investigate if Buyer[AccLog]∗  AccLog is an invocation consistent extension of Buyer[AccLog] with respect to every triggering activity t of Buyer and then if AccLog[Buyer]∗  Buyer is an invocation consistent extension of AccLog[Buyer] with respect to every triggering activity t of AccLog: (1) The interaction-join Buyer[AccLog]∗  AccLog is described in Example 8, the partner-confined orchestrator process Buyer[AccLog] is identical to Buyer and shown in Fig. 1. Invocation consistency will be checked with respect to ↓ = {order, status, reject, terminate}. Checking rules triggering activities TBuyer E1-E5, see Section 3.2, indicates that they are satisfied and the invocation consistent extension property holds. (2) Now we check if AccLog[Buyer]∗  Buyer is an invocation consistent extension of AccLog[Buyer] with respect to every triggering activity t of AccLog. AccLog[Buyer]∗  Buyer is shown in Fig. 2 (process without grey shaped elements) and AccLog[Buyer] is identical to AccLog shown in Fig. 1. Invocation consistency will be checked with respect to triggering activity t = delivery which is the only triggering activity in AccLog[Buyer]. Checking rules E1-E5 indicates that they are satisfied and the invocation consistent extension property holds. Applying Theorem 3 to parnter process AccLog and orchestrator Buyer shows that both are service compatible. 3.3

Design for Service Compatibility

The approach for the design of service compatibility consists of five steps which can be performed locally on the orchestrator or partner side. They enable orchestrators to identify possible service candidates and partners to verify if they provide functionality which can be consumed by a client: (1) Build well-formed orchestrator and partner services according to definition: The de-facto standard for specifying Web services and orchestrators is BPEL. We cannot provide a mapping for BPEL to our notation in this paper but refer to related work which dealt with a mapping to a notation that is also based on Petri-net semantics [12]. Having such a mapping in place, it is possible to check BPEL documents for possible errors in their specification, e.g., deadlocks. (2) Build interaction-reduced orchestrator and partner services with respect to specified service mapping: The service mapping represents the integration of orchestrator and partner services. It identifies matching points of processes and is the underlying specification for the automated generation of interaction joins. Here, we assume that the mapping is performed manually by a domain expert but this approach could be supported by tools which check underlying constraints for possible matches, e.g., constraints on input and output types of activity parameters. (3) Check whether the service

30

G. Grossmann, M. Schrefl, and M. Stumptner

mapping is well-behaved: This task is automated and might identify non compatibility. By checking certain rules such as if the interaction-reduced orchestrator contains an unmapped triggering activity, it is possible to point out why a service is not compatible and give suggestion how to change the design in order to achieve compatibility. (4) Construct interaction joins between orchestrator and each partner service: This task is also automated and required for the last check of service compatibility. (5) Check for service compatibility between orchestrator and each partner service: In the last task, the generated interaction joins are checked for invocation consistency with respect to triggering activities of orchestrator and partner service. If the checks are positive then service compatibility is given. A powerful advantage of the approach is that changes made to a process can be checked immediately for service compatibility. This allows to permit only certain changes which ensure that service compatibility is guaranteed even after changes have been made.

4

Related Work and Conclusion

One of the first efforts which focused on the design of composition and interaction of services dealt with modelling structured workflows [11] and investigated the transformation of unstructured into structured models. A similar goal was followed by research in the structured composition of services [5]. Zaha et al. developed a service interaction modeling language for modeling the interaction of services from a global view [17]. An advantage of this approach is that the designer can focus on the interaction but on the other side local models need to be checked if they are compliant to the global view. In our approach, we do not provide a global view but allow to check compatibility locally by verifying simple rules which can be implemented straightforward in a business process editor. Extensive work can be found that deals with compatibility and the classification of service compatibility [4,2,14,1,9,6,18,16]. Instead of verifying simple service compatibility as in our case, they provide notions and classes of compatibility, e.g., partial and fully compatibility. However, these approaches are either based on low level Web service specifications or require the analysis of all possible execution traces. In this paper we presented a conceptual model for the design of service compatibility which is based on our previous work in behavior-consistent specialisation of business processes. The concept introduced certain design rules for processes in order to guaranty service compatibilty between an orchestrator and a partner process which can be checked locally on either side. Compared to other approaches where a complete tree of all possible execution traces of a process is computed, we provide simple rules which require less computation and therefore can be checked more efficiently. We have built an editor for the conceptual model in the open source DoME meta modelling tool called DoME and our next step will be the implementation of the transformation from Behavor Diagrams (as Platform Independent Model) to BPEL (as Platform Specific Model) to provide automated support for the generation of service compatible BPEL processes. We

Model Driven Orchestration: Design for Service Compatibility

31

discuss the results of our design approach with respect to common processing and interaction patterns in [8].

References 1. Becker, K., Lopes, A., Milojicic, D., Pruyne, J., Singhal, S.: Automatically Determining Compatibility of Evolving Services. In: ICWS, pp. 161–168 (2008) 2. Benatallah, B., Casati, F., Toumani, F.: Representing, analysing and managing Web service protocols. DKE 58(3), 327–357 (2006) ` Pastor, 3. Bichler, P., Preuner, G., Schrefl, M.: Workflow Transparency. In: Oliv´e, A., J.A. (eds.) CAiSE 1997. LNCS, vol. 1250, pp. 423–436. Springer, Heidelberg (1997) 4. Bordeaux, L., Sala¨ un, G., Berardi, D., Mecella, M.: When are two web services compatible? In: Shan, M.-C., Dayal, U., Hsu, M. (eds.) TES 2004. LNCS, vol. 3324, pp. 15–28. Springer, Heidelberg (2005) 5. Eshuis, R., Grefen, P.W.P.J., Till, S.: Structured Service Composition. In: Dustdar, S., Fiadeiro, J.L., Sheth, A.P. (eds.) BPM 2006. LNCS, vol. 4102, pp. 97–112. Springer, Heidelberg (2006) 6. Gong, X., Liu, J., Zhang, M., Hu, J.: Formal Analysis of Services Compatibility. In: COMPSAC, pp. 243–248 (2009) 7. Grossmann, G., Ren, Y., Schrefl, M., Stumptner, M.: Behavior Based Integration of Composite Business Processes. In: van der Aalst, W.M.P., Benatallah, B., Casati, F., Curbera, F. (eds.) BPM 2005. LNCS, vol. 3649, pp. 186–204. Springer, Heidelberg (2005) 8. Grossmann, G., Schrefl, M., Stumptner, M.: Orchestration Modeling: Design for Service Compatibility. Technical report, UniSA, ACRC (2010), http://www.mrgg.at/documents/TR-UNISA-CIS-KSE-2010-04.pdf 9. Guermouche, N., Perrin, O., Ringeissen, C.: Timed Specification For Web Services Compatibility Analysis. Electr. Notes Theor. Comput. Sci. 200(3), 155–170 (2008) 10. Kappel, G., Schrefl, M.: Object/Behavior Diagrams. In: Proceedings IEEE ICDE, pp. 530–539. IEEE Press, Los Alamitos (1991) 11. Kiepuszewski, B., ter Hofstede, A.H.M., Bussler, C.J.: On Structured Workflow Modelling. In: Wangler, B., Bergman, L.D. (eds.) CAiSE 2000. LNCS, vol. 1789, pp. 431–445. Springer, Heidelberg (2000) 12. Lohmann, N., Massuthe, P., Stahl, C., Weinberg, D.: Analyzing interacting WSBPEL processes using flexible model generation. DKE 64(1) (2008) 13. Schrefl, M., Stumptner, M.: Behavior-consistent Specialization of Object Life Cycles. ACM TOSEM 11(1), 92–148 (2002) 14. Tan, W., Rao, F., Fan, Y., Zhu, J.: Compatibility analysis and mediation-aided composition for bpel services. In: Kotagiri, R., Radha Krishna, P., Mohania, M., Nantajeewarawat, E. (eds.) DASFAA 2007. LNCS, vol. 4443, pp. 1062–1065. Springer, Heidelberg (2007) 15. Wombacher, A.: Decentralized Consistency Checking in Cross-organizational Workflows. In: Proc. CEC/EEE 2006, pp. 39–46 (2006) 16. Wu, Z., Deng, S., Li, Y., Wu, J.: Computing compatibility in dynamic service composition. Knowl. Inf. Syst. 19(1), 107–129 (2009) 17. Zaha, J.M., Dumas, M., ter Hofstede, A.H.M., Barros, A.P., Decker, G.: Bridging Global and Local Models of Service-Oriented Systems. IEEE Transactions on Systems, Man, and Cybernetics, Part C 38(3), 302–318 (2008) 18. Zhou, Z.B., Bhiri, S., Gaaloul, W., Shu, L., Hauswirth, M.: Behavioral Compatibility of Web Services. In: OTM Workshops, pp. 27–28 (2008)

Embedded Software Development with Projectional Language Workbenches Markus Voelter independent/itemis Oetztaler Strasse 38, 70327 Stuttgart, Germany [email protected] http://voelter.de

Abstract. This paper describes a novel approach to embedded software development. Instead of using a combination of C code and modeling tools, we propose an approach where modeling and programming is unified using projectional language workbenches. These allow the incremental, domain-specific extension of C and a seamless integration between the various concerns of an embedded system. The paper does not propose specific extensions to C in the hope that everybody will use them; rather, the paper illustrates the benefits of domain specific extension using projectional editors. In the paper we describe the problems with the traditional approach to embedded software development and how the proposed approach can solve them. The main part of the paper describes our modular embedded language, a proof-of-concept implementation of the approach based on JetBrains MPS. We implemented a set of language extensions for embedded programming, such as state machines, tasks, type system extensions as well as a domain specific language (DSL) for robot control. The language modules are seamlessly integrated, leading to a very efficient way for implementing embedded software. Keywords: embedded systems, language extension, domain-specific languages, code generation, projectional editing.

1 Problems and Challenges in Embedded Systems Development Embedded software is usually based on the C programming language. There are several reasons for that. There is significant experience with C because it has been used for a long time. New systems often reuse existing software written in C. The language is also relatively close to the hardware, resulting in efficient machine code. Finally, a large number of compilers exist for many different target platforms and (embedded) operating systems. These compilers usually produce decent quality code. However, this approach is not without problems. For example, C has a number of features that are considered unsafe. Examples include void pointers, unions and (certain) automatic type conversions. Coding conventions, such as the Misra-C standard [1], prohibit the use of these features. Compliance is checked with automated checkers. Of course, while editing the code, developers can use these prohibited features, but get an error message only later. Another problem with C is its limited support for meaningful abstraction. For example, there is no first class support for interfaces or D.C. Petriu, N. Rouquette, and Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 32–46, 2010. © Springer-Verlag Berlin Heidelberg 2010

Embedded Software Development with Projectional Language Workbenches

33

components, making modularization and replacement of functionality (similar to polymorphism) hard. This becomes a significant problem as systems become larger and more complex - modern cars, for example, have up to 70 computers and controllers, several different bus systems as well as several gigabytes of software and configuration data. It is also hard to implement good abstractions for physical quantities (speed, rpm, temperatures), so most systems represent all kinds of quantities as integers. The resolution of the integers is optimized based on the value range of the quantity (0 to 300 for a speed, for example). However, since the compiler does not know about these ranges, developers have to take care of this resolution mapping themselves: a very tedious and error prone approach. It also leads to code that is hard to read because of all the inline conversion code. Finally, the preprocessor can be used for any number of mischief, thwarting attempts to analyze source code in a meaningful way. To address these problems, modeling tools are used in the following two ways. One use case is the declarative specification of module and component structures for example by declaring interfaces, bus messages used by the module, or shared memory regions. A generator creates a header file based on which the developer then implements the actual functionality of the module. Examples for this approach include Autosar [5] or EAST-ADL [4] and many home-grown tools. The other use case for modeling tools is support for a specific behavioral paradigm: prominent examples include state-based behavior (as represented by (real time) UML tools) and abstractions from the control systems domain, often implemented using data flow block diagrams with tools such as Matlab/Simulink [20]. While these modeling tools are important and useful, they also create significant problems. No one tool addresses all aspects of an embedded system, and various tools used for describing a system don't integrate very well with each other. Symbols defined in one tool cannot easily be referenced from models created with another tool. A special case of this problem is that the integration of manually written C code and abstractions defined in the models is hard. Also, the tools are often proprietary and very hard to customize and adapt to the specific environment of the project, product, or organization. There is also a more fundamental problem with the approach of using models and generators to generate header files or skeletons and then filling in the application logic via manual C programming: because of C's limited ability to express abstractions, the high-level constructs described in the models cannot be directly used or type checked in manually written C code. To make this possible, the C compiler, as well as the IDE, would have to be extended. This is unrealistic with today’s tools. There are also significant challenges with process integration of the models and code including the ability to trace model and program elements back to requirements and the ability to express product line variability. Most tools do not provide first-class support for expressing variations in models or programs. If they do, then each tool has its own paradigm. In C, preprocessor #ifdef statements are often used. Since variability affects all artifacts in the software lifecycle, having a different way of specifying it in each tool without a way of pulling it all together is a serious problem. As the number of variants increases all the time, a scalable and well integrated facility for treating the variability is crucial. This is true in a similar way for requirements traceability. Finally, in large engineering environments, the integration build can take very long, up to several hours. If the concerns described above are only checked during the

34

M. Voelter

build, this can reduce productivity significantly. Checking these concerns earlier in a tool would improve the situation. Better modularity, analyzable dependency specification and better support for unit testing would further improve the situation.

2 Proposed Solution This paper proposes an approach for embedded development based on a modular, incremental extension of C. Projectional language workbenches (see next section; for now, consider them a tool for flexibly defining, mixing and extending languages) are the basis for this approach. Extensions can be on arbitrary abstraction levels, thereby integrating modeling and programming and avoiding tool integration issues. Code generation to C is used to integrate with existing compilers and platforms. Here are some examples of how C could be extended to be more suitable as an embedded programming language. These are examples only, since the paper proposes an approach where C in extended in ways that are specific to organizations, projects or platforms. A module system. Implementing modularized, reusable software requires a module system or component infrastructure. A module should declare everything it provides or expects from its environment in a way which is analyzable for tools. Interfaces could be functions that can be called by other modules, shared memory structures or published or consumed events. A module system would be directly integrated into the programming language, and abstractions defined in the module definitions are first class citizens in the program and can be referenced directly. Physical Quantities. The language would support the definition of quantities, a numeric type with a unit and a value range. Conversion rules for the value ranges and units are included in the type system. The IDE can check type compatibility, calculate resulting types/units and automatically insert value range conversions. State-based behavior. Behavior in embedded systems is often state-based [2]. An enhanced language for embedded system development should contain native abstractions for states, transitions, and events. A module that contains state-based behavior would declare published and consumed events as part of its interface. Dataflow. Many (especially control) systems use block diagrams [3]. In a new embedded programming language, these would be represented using dataflow ports on modules. They would serve as the basis for “wiring” the modules together, potentially using the well-known box-and-line notation. Mathematical notation and abstractions. To support the concise expression of mathematical concepts, support for mathematical abstractions and notations should be built into the language. Examples include vectors, matrices, the sum symbol, or subscript notation. Because of the complete integration into the type system, static analysis and compile-time optimizations become possible. Middleware Integration. In many embedded domains, standardized middleware frameworks are becoming de facto standards. Examples include EAST-ADL2 [4], AUTOSAR [5] or any number of frameworks for network/bus protocols. Developers are

Embedded Software Development with Projectional Language Workbenches

35

required to interface with these frameworks all the time. Language extensions specific to the target middleware would make a developer’s job significantly simpler. IDE-level checks of correct usage also make development more robust and less error prone. Variability. First-class support for expressing variability is crucial. At least, the markup of variable sections of models/code and their relationships to configuration features must be expressed. It must be possible to show programs with or without the variability markup as well as specific variants, i.e. the with all non-selected variable sections removed (as in [26]). Because the variability expression mechanism would be native to the language, it can be analyzed and checked in the IDE – it is not just implemented as a comment or a type-system-unaware preprocessor directive. Traceability. The language should provide a way to embed references to other artifacts using some kind of referencing scheme. At the very least, pointers to requirements in systems like DOORS or Requisite Pro are necessary.

3 Language Workbenches and JetBrains MPS To implement extensions such as those proposed in the previous section, it must be possible to modularize the overall language as otherwise it will become complex and bloated. It must also be extensible so that new language modules can be added and language concepts in existing modules can be adapted to project- or system specifics. Projectional language workbenches form the basis for such an approach. The term Language Workbench has been coined by Martin Fowler in 2005 [6]. In this article he characterizes it as a tool with the following properties: 1. 2. 3. 4. 5.

Users can freely define languages which are fully integrated with each other. The primary source of information is a persistent abstract representation. A DSL is defined in three main parts: schema, editor(s), and generator(s). Language users manipulate a DSL through a projectional editor. A language workbench can persist incomplete or contradictory information.

Projectional editing implies that all text, symbols, and graphics are projected, wellknown from graphical modeling tools (UML, ER, State Charts): the model is stored independent of its concrete syntax, only the model structure is persisted, often using XML or a database. For editing purposes this abstract syntax is projected using graphical shapes. Users perform mouse gestures and keyboard actions tailored to the graphical editing to modify the abstract model structure directly. While the concrete syntax of the model does not have to be stored because it is specified as part of language definition and hence known by the projection engine, graphical modeling tools usually also store information about the visual layout. Projectional editing can also be used for a syntax that is textual or semi-graphical (mathematical notations for example). However, since the projection looks like text, users expect interaction patterns and gestures known from "real text" to work (such as cursor movements, inserting/deleting characters, rearranging text, selection). A projectional editor has to "simulate" these interaction patterns to be usable.

36

M. Voelter

The following list shows the benefits of the approach: • In projectional editing, no grammar or parser is used. Editing directly changes the program structure (AST). Thus, projectional editors can handle unparseable code. Language composition is easily possible, because composed languages cannot result in ambiguous grammars, a significant issue in classical parser-based systems. • Notations are more flexible than ASCII/ANSI/Unicode. Graphical, semi-graphical and textual notations can be mixed and combined. For example, a graphical tool for editing state machines can embed a textual expression language for editing the guard conditions on transitions. • Because projectional languages by definition need an IDE for editing (it has to do the projection!), language definition and extension always implies IDE definition and extension. The IDE will provide code completion, error checking and syntax highlighting for all languages, even when they are combined. • Because the model is stored independent of its concrete notation, it is possible to represent the same model in different ways simply by providing several projections. Different viewpoints [7] of the overall program can be stored in one model; editing can be viewpoint or aspect specific. It is also possible to store out-of-band data, i.e. annotations on the core model/program. Examples of this include documentation, pointers to requirements (traceability) [8] or feature dependencies in the context of product lines [9]. As a side effect, language workbenches deliver on the promise of removing the distinction between what is traditionally called programming and what is traditionally called modeling. This distinction is arbitrary: developers want to express different concerns of software systems with abstractions and notations suitable to that particular concern, formally enough for automatic processing or translation, and with good IDE support. Projectional language workbenches deliver on this goal in an integrated, consistent and productive way. They do this by applying the technology known from modeling tools (projection) to editing any notation. JetBrains MPS JetBrains’ Meta Programming System is an open source projectional language workbench [10]. Defining a language starts by defining the abstract syntax, the editor for the language concepts is specified in a second step. Lastly the generator is defined. It outputs text (for a low-level language) or it transforms higher-level code into code expressed in lower level languages. The higher-level to lower-level generators are not text generators, they transform abstract syntax trees. Editing the tree as opposed to “real text” needs some accustomization. Without specific adaptations, every program element has to be selected from a drop-down list and "instantiated". However, MPS provides editor customizations to enable editing that resembles modern IDEs that use automatically expanding code templates. In some cases though, the tree shines through: Consider changing a statement like int i = j+k; to int i = (j+k)*2; you cannot simply move the cursor to the left of j and insert a left parenthesis. Rather, you have to select the + operator (the root node of the expression on the right) and use a Surround with Parens refactoring. Using ( as the hotkey for this refactoring creates an editing experience very similar to "real" text.

Embedded Software Development with Projectional Language Workbenches

37

Language Definition, Extension and Composition with MPS I have described language creation, extension and composition in MPS in a separate paper [15]. This section shows an example as a short summary. MPS, like other language workbenches, comes with a set of DSLs for language definition, a separate DSL for each language aspect. Language aspects include structure, editor, type system, generator as well as support for features such as quick fixes or refactorings. Defining a new language starts by defining the language structure (aka meta model). This is very much like object oriented programming as language elements are represented as concepts that have properties, children and references to other concepts. The second step is the editor for the language concepts. An editor defines how the syntax for the concepts should look like - it constitutes the projection rules. Figure 1 is an example.

Fig. 1. Defining an editor for a local variable declaration statement (as in int i = 2*2;)

Next is the definition of the type system. For example, the type property of a LocalVariableDeclaration must be compatible with the type of its init expression. At this point, the definition of the language and the basic editor, as well as the type system are finished. However, to use the new LocalVariableDeclaration statement, the user has to bring up the code completion menu in the editor, select the concept LocalVariableDeclaration and use tab or the mouse to fill in the various properties (type, name, init). A couple of editor customizations are necessary to make sure users can "just type" the declaration. I refer to [11] for details on how this works. I already alluded to the relationship between object oriented programming and language definition in MPS. This analogy also holds for language extension and specialization. Concepts can extend other concepts, and subconcepts can be used polymorphically. Languages can extend other languages, too, and the sublanguage can contain subconcepts of concepts in the base language or can override the translation rules (generators) of concepts defined in the base language. Concept interfaces are also available. Using the Adapter pattern [12], unrelated concepts can be made to fit together. To use a B in places where an A (or subtypes) is expected, an adapter BAdapter that extends A and contains or references a B is necessary. As shown in [11], this approach supports embedding of completely unrelated languages. Languages also define translation rules to lower-level languages or to text. MPS includes an incremental translation engine that reduces program code as long as translation rules are available for the program elements. At the end, text generators output regular program text that can be fed into a compiler. Finally, MPS also comes with an integration into common version control systems, allowing diff/merge on the level of the projected concrete syntax. The upcoming version 1.5 will also provide support for debugging.

38

M. Voelter

Why Language Extensions Compared to using libraries and frameworks, language extension has a couple of advantages. First of all, the syntax can be adapted. C does not have a very flexible syntax, so internal DSLs are not easily possible. Also, for all the language extensions created, MPS provides IDE support: syntax coloring, code completion as well as error reporting. Much more meaningful static checks and analyses can be implemented (in the IDE) based on the language because language modules can be limited in their expressive power, making semantic analyses feasible. Integration of language modules also includes the integration of the type systems, as well as of the semantics of the integrated languages. The latter is achieved by incremental transformation into less abstract languages. Finally, all kinds of optimizations can be performed during the incremental translation phase. In short, language extension provides all the benefits of (what's traditionally known as) modeling, but without all the integration and tooling headaches. The perceived disadvantage of language extension - mainly the effort of implementing the extensions - is addressed very effectively by MPS. As discussed in the Evaluation section, the effort for building language extensions is very reasonable.

4 Proof of Concept Bernhard Merkle and the author are working on a proof-of-concept, the modular embedded language (MEL). It contains several of the C extensions described above. The system is a Lego Mindstorms line follower. It uses a single light sensor to follow (one side of) a thick black line. It keeps track of the turning line by changing the speed of motors that drive the two main wheels. It is shown in Figure 2. The software is implemented in C based for the Fig. 2. The line follower robot OSEK operating system [14] for Lego Mindstorms [13]. Using Mindstorms makes the case study accessible and fun; OSEK makes it relevant to real-world software because it is used a lot in automotive systems. It is basically a set of C APIs together with a configuration file, called OIL file. In the proof-of-concept, all these artifacts are generated from the MEL programs. Note that none of the language extensions described below are specific to OSEK only the code generator is. By plugging in different code generators, different platforms can be targeted. For testing and debugging, a win32 target is available. Core Language. The core of the MEL is a relatively complete implementation of the C programming language in MPS. The core language supports variables, constants, enums, structs, functions, most of C's statements and expressions as well as the type system including pointers. No headers files are used (they are only generated during text generation at the end of the translation chain). Instead the language provides the concept of a module. Modules are like a namespace and contain variables,

Embedded Software Development with Projectional Language Workbenches

39

typedefs, structs and functions - all the elements that can be declared on top level in C programs. Module contents can be exported. Modules can declare dependencies to other modules which makes their exported contents visible to depending module. Note that the system does not include the preprocessor. Instead it provides first class concepts for many of the typical use cases for the preprocessor (such as constants or conditional code regions). Existing code can thus not be directly imported into the MEL. However, the system supports interfacing with code (as represented by header files) that resides outside of MEL/MPS. This is described below.

Fig. 3. Code for the simple line follower robot expressed with the MEL

Figure 3 shows a screenshot of the basic line follower program implemented with MEL. It contains a module main that uses three external API modules. The module contains constants as well as a statemachine which manages the two phases of the program: initialization and running. The module also contains an initialize block (called at program startup) which performs the initialization of the light sensor. The cyclic run task is responsible for reading the sensor and adjusting motor speeds. It is called every two system ticks. What the run task actually does is state-dependent by virtue of the stateswitch; if the linefollower state machine is in the running state it reads the light sensor and updates the motor settings. This state is entered by signalling linefollower:initialized at the end of the setup task. Finally, the module contains the updateMotorSettings function which actually drives the motors. Let us look at some of the features available in the MEL. Tasks. Tasks capture behaviour that should be executed at specific times, currently at startup and cyclic are supported. Tasks are like functions, but they have no arguments and no return type. In fact, use of the return keyword is prevented inside tasks. Translation is target platform specific and can be exchanged by using a different generator.

40

M. Voelter

For the OSEK target, tasks are mapped to a void function and a couple of entries in the OIL file: for a cyclic task, a counter, an alarm and a task have to be declared. In addition, a function that drives the counter based on an interrupt is required. All of this is transparent to the programmer. Statemachines. The MEL contains a module for state machines. It supports the declaration of state machines (with states, events, transitions, guard conditions as well as entry and exit actions), a statement to fire events into a statemachine as well as a stateswitch statement to create a switch-like construct for implementing statedependent behavior in tasks or functions. The statemachine language module extends the core language. Like functions or tasks, state machines implement the IModuleContent interface so they can be put into modules. The event… keyword and the stateswitch are subtypes of the core language's Statement concepts, making sure they can be used in statement context. Actions are statement lists, so every valid C statement can be used in them. The generator is implemented as a model-to-model transformation that maps these construct down to plain C (as defined in MPS). The state machine becomes a variable (to hold the current state) as well as a function containing a switch/case statement to "execute" the transitions. States and events result in constants. The event statement calls this function passing in a constant representing the actual event. The stateswitch results in a couple of if statements querying the current state variable.

Fig. 4. Editing the state machine as a table embedded in the program code

Notice how as a consequence of the projectional editing it is possible to edit state machines using several notations. In addition to the textual notation above, we also support a table notation as shown in figure 4. A graphical notation is planned future. Calling external APIs. OSEK provides a set of APIs. Since they are not implemented with the MEL in MPS, it must be possible to call low-level APIs. External modules contain the signature of the functions that need to be called from within MPS. An external module also associates a set of linked resources. The code generated from modules that use an external module will #include the header represented by the external module and the linked resources will be added to the generated makefile to make sure they are linked into the resulting image. A special kind of integer. Working with the sonar sensor to detect obstructions in the robot's path requires averaging over repeated measurements because the sensor is very sensitive. This is useful for many sensors, so an extension of the type system to provide averaging variables is included. Figure 5 A shows the declaration of a variable with an averaging type: the base type is int, the number of elements over which to

Embedded Software Development with Projectional Language Workbenches

41

average is 10 and the initialization value is 250. From this declaration the generator produces two more variables: a buffer that remembers the last 10 measurements and an index into that buffer to determine where the next value is stored. The =/ operator (see B) inserts a new measurement into to the buffer, calculating the new average and assigning it to the variable of the left of the operator. The variable can be read just like any other variable (see C).

Fig. 5. Averaging Variables

The system also supports physical quantities as explained in the introduction. Safety. One aspect of safety is making sure that values are not assigned to variables that cannot hold these values. For example, if a programmer assigns a value to an uint8, the value must not be larger than 255. To enforce this, coding guidelines of many organizations require the use of safe functions (such as mul32(…) ) instead of the built-in operators. The MEL supports such an approach transparently. A module can simply be marked as safe: all assignments and initializations are wrapped with a checkSizeNN(…) function call that logs an error if the value is outside the permitted range. An alternative implementation would transparently replace built-in operators with safe library functions such as mul32.

Fig. 6. An interface, a component and a component implementation

42

M. Voelter

Components. Component-based development is widespread in software engineering in general, and in embedded systems in particular. Components are the "smallest architecturally relevant building block". They encapsulate behaviour and expose all system-relevant characteristics declaratively. In the proof-of-concept, a language module is available to express interfaces, components and component implementations, as shown in Figure 6. The separation of interface, component and implementation also leads to a support for "compile-time polymorphism": since client code is written only against interfaces, the implementing component can be replaced. For example, this supports the encapsulation of platform-specific code and makes mocks for testing simple. A domain specific language. All the facilities described so far address embedded software development generally. There was nothing in the languages that is specific to mobile robots that can drive and turn.

Fig. 7. A robot routing script embedded in a module

Consider now the role of a robot vendor who sells Lego robots with two wheels that can drive a predefined route. Each customer wants a different predefined route. The vendor has to develop a different route-driving program for each customer. Of course this can be achieved with tasks, state machines, variables and functions. But it would be better if a domain specific language for defining routes was available. This is an example of cascading languages: on top of a (relatively) general purpose language (Embedded/C/OSEK/Mindstorms), a (relatively) domain specific language (robot routing) is cascaded. The domain specific constructs are translated down to the more general purpose constructs for execution. Figure 7 shows an example route expressed in the new TwoWheels DSL. This program uses native route definition constructs. Since the robot routing language extends the core language, and the robot script construct implements the IModuleContents interface, it can be embedded in a module - like the lower-level constructs. The robot script can even call functions. The robot routing language is executed by translation into the following lower level constructs: • a state machine that keeps track of the current command/step • module variables that remember the current speeds for the two motors

Embedded Software Development with Projectional Language Workbenches

43

• module variables that store the current deltas for the speeds of both motors to be able to "ramp up" the speeds in accelerate and decelerate commands • a cyclic tasks that updates motor speeds based on the currently selected deltas. Figure 8 shows a simple robot script (grey box) and its translation into states and tasks, which are in turn translated into "regular" C and the OIL file by the incremental, multi-stage translation engine.

Fig. 8. A simple robot script and the resulting lower level program

Requirements traceability and product line variability. The MEL also supports traceability to requirements as well as feature annotations to express product line variability. Since it is a complex and big topic on its own I have described this in a separate paper [15].

5 Discussion The experience in building the MEL for Lego Mindstorms allows us to conclude a number of things which we describe in this section. It is useful to extend plain C with concepts that are tailored for embedded programming. Programs become more readable and can be analyzed much more thoroughly. The ability to extend languages quickly and easily is very powerful. One really starts thinking differently about programming and modeling if the language isn't a fixed quantity anymore. More specifically, being able to go bottom (i.e. starting with

44

M. Voelter

C code, not with high-level models) up has proven useful. Additional abstractions are added when the need for them becomes apparent at any time during the project. The ability to mix what's traditionally considered programming and what's traditionally considered modeling is clearly an advantage. Being able to use C expressions in state machine guard conditions, or using C statements in the actions of state machines is very useful - especially since consistent IDE support is available and the symbols and type systems are seamlessly integrated.

Fig. 9. Dependencies between the languages mentioned in this paper

It is feasible to package the various aspects into separate language modules (see Figure 9). This makes sure languages do not become bloated - different users can extend the core with concepts suitable to what they want to do. Low level and high level constructs are all implemented in the same tooling makes cascading and incremental refinement feasible and mixing of abstraction levels possible. The generated C code is not different from what developers would have written by hand. Transformations or code generation is incremental (higher level constructs are transformed into instances of lower level constructs), making optimizations implemented in lower levels available to higher levels automatically. The effort for building the languages, the IDE and the language extensions is very modest. For example, developing the basic C implementation has taken about three weeks. Adding the state machine facilities (state machines, event keyword, stateswitch, including the generator down to C) has been done in one afternoon. Creating the robot routing DSL on top was a matter of 4 hours, including the mapping down to tasks and statemachines. This proofs that adding language abstractions as they become necessary is feasible.

6 Future Work In addition to continue working on our Lego proof-of-concept, we're planning to engage on a larger, real-world prototype embedded systems project. In this project we will • • •

identify and implement more abstractions and notations as well as the relationships between them to facilitate meaningful modularization understand and prototype the integration of the approach and the language workbenches with build, test, version control, requirements, and variant management tools to make sure the approach can be used in real development environments. integrate the languages with the debugger framework that will ship with the next version of MPS to be able to debug programs on MPS-source level.

Embedded Software Development with Projectional Language Workbenches

• •

45

explore the use of other notations, mainly tabular and graphical. MPS needs a couple of minor improvements to make these possible. These are planned to be available by the end of 2010. target a different platform, for example a real AUTOSAR-based [5] vehicle ECU

7 Related Work Language composition is researched by various groups, exemplified by tools such as SDF [16] and Monticore [17]. Projectional editing is also supported by Intentional Software's Domain Workbench [25]. However, since I describe language composition in detail in another paper [11], I will not discuss this topic any further here. The closest relative to the approach described in this paper is nesC [22], an extension to C designed to embody the concepts and execution model of TinyOS, an eventdriven operating system designed for sensor network nodes that have very limited resources. Like the MEL proposed in this paper, nesC is an extension of C. However, it is one specific extension, whereas this paper produces modular language extension as a general paradigm for efficient embedded software development. However, the nesC extensions are a good example of how extensions to a general purpose language are useful; nesC could be easily built with the approach described in this paper. SystemC [21] is a C++-based class library for systems engineering and embedded software development. It has some of the same goals as the MEL introduced here, but uses libraries, not language extension. Language extension is more powerful because the syntax can be adapted, IDE support can be provided and semantic validation can be more meaningful. Modelica [22] is an open standard for systems engineering and simulation. It provides many meaningful abstractions for systems engineering, among them the ability to define formulae and differential equations. However, Modelica does not allow language extension. I consider the ability to extend the language with domain-specific concepts the main contribution of the MEL. A similar statement can be made for Matlab [23]. It is very widely used in control and automation applications. Just like Modelica, Matlab comes with a simulation workbench. The language is textual and graphical (block diagrams). New blocks can be added through via libraries. Code generation is supported based on its Real-Time Workshop. However, real language extension is not possible, either. SCADE [21] is another language for embedded systems engineering with a strong focus on realtime and safety. Again, the core language is not extendible. It is not clear at this point whether extensible languages would make safety and certification issues simpler or more complicated. ECSL-DP [24] is a tool suite for distributed embedded control systems. It integrates a set of tools, among them, Matlab [20] and GME. It provides graphical notations, and, again, the idea of extending the languages in domain-specific ways is not part of the methodology. It presents one set of languages, not workbench for domain-specific extensions.

Acknowledgements Thanks to Alexander Bernauer, Christoph Elsner, Iris Groher, Michael Kircher, and Guy Philipp Bollbach for their feedback. I also want to thank Bernhard Merkle, who helped me get started with Mindstorms and OSEK. Finally, I want to thank Konstantin Solomatov (JetBrains) who tirelessly supported me when learning MPS.

46

M. Voelter

References 1. MISRA Group, Misra-C, http://www.misra-c2.com/ 2. Wikipedia, State Machines, http://en.wikipedia.org/wiki/Finite-state_machine 3. National Instruments, Block Diagram Data Flow, http://zone.ni.com/reference/ en-XX/help/371361B-01/lvconcepts/block_diagram_data_flow/ 4. ATESST Consortium, EAST ADL Specification, http://www.atesst.org/ home/liblocal/docs/EAST-ADL-2.0-Specification_2008-02-29.pdf 5. AUTOSAR Partnership, Automotive Open System Architecture, http://www.autosar.org/ 6. Fowler, M.: Language Workbenches: The Killer-App for Domain Specific Languages? http://martinfowler.com/articles/languageWorkbench.html 7. Wikipedia, View Model, http://en.wikipedia.org/wiki/View_model 8. Wikipedia, Traceability, http://en.wikipedia.org/wiki/Requirements_traceability 9. Eisenecker, U., Czarnecki, K.: Generative Programming. Addison-Wesley, Reading (2000) 10. JetBrains, Meta Programming System, http://jetbrains.com/mps 11. Voelter, M., Solomatov, K.: Language Modularization and Composition with Projectional Language Workbenches illustrated w/ MPS. In: SLE 2010 (submitted 2010) 12. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading (1994) 13. Lego, Mindstorms, http://mindstorms.lego.com 14. Sourceforge.net, nxtOSEK, http://lejos-OSEK.sourceforge.net/ 15. Voelter, M.: Product Line Engineering with Projectional Language Workbenches. In: GPCE 2010 (submitted 2010) 16. Visser, E.: Syntax Definition, http://swerl.tudelft.nl/bin/view/ EelcoVisser/SyntaxDefinition 17. Software Engineering Group at RWTH Aache, Project MontiCore, http://monticore.de/ 18. Open SystemC Initiative, SystemC, http://www.systemc.org/ 19. Modelica Association, Modelica, http://modelica.org/ 20. The MathWorks, Matlab - the language of technical computing, http://www.mathworks.com/products/matlab/ 21. Esterel Technologies, SCADE, http://www.esterel-technologies.com/products/scade-suite/ 22. Gay, D., Levis, P., von Behren, R., Welsh, M., Brewer, E., Culler, D.: The nesC language. ACM SIGPLAN Notices 38(5) (May 2003) 23. Fowler, M.: Domain Specific Languages, http://www.martinfowler.com/ bliki/DomainSpecificLanguage.html 24. Neema, S., Karsai, G., Vizhanyo, A.: Embedded Control Systems, Language for Distributed Processing (ECSL-DP), http://www.omg.org/news/meetings/workshops/ MIC_2004_Manual/06-1_Neema_etal.pdf 25. Intentional Software, Intentional Domain Workbench, http://intentsoft.com 26. Kästner, C., Thüm, T., Saake, G., Feigenspan, J., Leich, T., Wielgorz, F., Apel, S.: FeatureIDE: Tool Framework for Feature-Oriented Software Development. In: Proceedings of ICSE 2009 (2009), Formal Demonstration Paper

Concern-Based (de)composition of Model-Driven Software Development Processes Jendrik Johannes and Uwe Aßmann Technische Universit¨ at Dresden Institut f¨ ur Software- und Multimediatechnik D-01062, Dresden, Germany     

   

Abstract. An MDSD process is often organised as transformation chain. This can threaten the Separation of Concerns (SoC) principle, because information is replicated in, scattered over, and tangled in different models. Aspect-Oriented Software Development (AOSD) supports SoC to avoid such scatterings and tangling of information. Although there are integrations of MDSD and AOSD, there is no approach that uses concern separation for all artifacts (documents, models, code) involved in an MDSD process as the primary (de)composition method for the complete process. In this paper, we propose such an approach called ModelSoC. It extends the hyperspace model for multi-dimensional SoC to deal with information that is replicated in different models. We present a ModelSoC implementation based on our Reuseware framework that organises all information provided in arbitrary models during development in a concern space and composes integrated views as well as the final system from that. This is shown on the development of a demonstrator system.

1

Introduction

Model-Driven Software Development (MDSD) aims at decreasing the effort and costs for developing complex software systems. This is achieved by reusing information that is captured in artifacts (documents, diagrams, etc.) that are created during the development of such a system. These artifacts are regarded as models of the system and are integrated by means of transformation and composition. By this, the final system is eventually generated—without the need to manually implement the parts of the system that are already defined in models. MDSD profits from the OMG’s metamodelling standards MOF and OCL and their adoption in technologies such as the Eclipse Modelling Framework (EMF) [1]. These technologies include language-independent tools (e.g., model transformation engines) and meta tools for creating Domain-Specific Modelling Languages (DSMLs). The standards and tools allow not only for cost-efficient engineering of new DSMLs but also for the seamless integration of these DSMLs 

This research has been co-funded by the European Commission in the 6th Framework Programme project Modelplex contract no. 034081 (cf., www.modelplex.org).

D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 47–62, 2010. c Springer-Verlag Berlin Heidelberg 2010 

48

J. Johannes and U. Aßmann

into MDSD processes. Hence, MDSD processes can be tailored with languages suitable for the task at hand and domain experts can participate in development directly. Ultimately, however, the models defined in DSMLs have to be transformed into an implementation to make use of the information they contain. This is often performed stepwise by transforming them into more detailed models and refining these before generating code, which might require further refinement. In an MDSD process that is organised as transformation chain, replication, scattering and tangling of information can occur when information is repeatedly extracted and distributed over different models. This is the source of traceability and consistency problems which are often tackled by additional techniques on top of model transformations (e.g., publications in [2]). The problem can also be regarded as a Separation of Concerns (SoC) issue as investigated in the area of Aspect-Oriented Software Development (AOSD) [3]. Originally focused on programming languages, AOSD is now concerned with all parts of a software development process and thus there are a number of approaches that integrate ideas and technologies from MDSD and AOSD (e.g., publications in [4]). However, usage of AOSD in MDSD so far mostly focused on either specific parts of the development process (e.g., [5] or [6] for analysis/design; [7] or [8] for implementation) or offered a technology for model aspect weaving (e.g., [9]) without a SoC methodology. Although different approaches can be combined to use AOSD methods in all phases of MDSD processes, there exists, to the best of our knowledge, no approach and no universal technology that organises an MDSD process by concern (de)composition rather than transformation chain (de)composition. In this paper we present such an approach—the ModelSoC approach as an extension of the hyperspace model for multi-dimensional separation of concern defined by Ossher and Tarr [10]—and a supporting technology. The hyperspace model is well suited as a base for ModelSoC, since it (a) explicitly supports different dimensions for decomposition which is needed because in different DSMLs information is decomposed along different dimensions and (b) is independent of a concrete language (i.e., not limited to e.g. Java) or a concrete language paradigm (i.e., not limited to e.g. object-oriented languages). The approach is implemented in our Reuseware Composition Framework [11]. Our contribution is thus twofold. First, we introduce ModelSoC as an extension of the hyperspace model that can handle replication of information in different formats and usage of DSMLs for composing information. Second, we introduce Reuseware as a framework technology that enables usage of ModelSoC in practice in combination with existing Eclipse-based modelling tools. A comparable technology is not available for the hyperspace model itself that was implemented for Java only in the Hyper/J [10] and CME [12] tools. The paper is structured as follows: In Sect. 2, we introduce an MDSD process as an example to motivate the need for ModelSoC which we describe in Sect. 3. Next, we discuss how the Reuseware framework is used to put ModelSoC into practice in Sect. 4. The motivating example is revisited in Sect. 5, where we show how it is realised with ModelSoC and discuss advantages of that. In Sect. 6, we discuss related work and conclude the paper in Sect. 7.

Concern-Based (de)composition of MDSD Processes

2

49

Motivating Example

In the following, we motivate our work using the model-driven development of a reservation system in which customers can book tickets and perform other related activities. This demonstrator system is inspired by an example from [13]. Figure 1a shows the process defined as model transformation chain. Five types of models1 are used: OpenOffice use case documents (cf., [13] for structure details), UML use case models [14] annotated with invariants (as introduced in [13]), UML class models, Value Flow (a data flow DSML2 ) models and Java [15]. In the chain, information is transported between different models—i.e., different views on the system—by model transformations. This is not only necessary to integrate all information into the Java code at the end of the chain, but also to connect new information in different views to existing information. For example, the information about actors participating in use cases, initially defined in OpenOffice documents, is needed in all viewpoints, since it is central information around which other information is defined. An example of adding information is the refinement of a UML use case model, which we illustrate on the example of the use case BookTicket in Fig. 1a. Following [13], UML use cases are annotated with value added invariants. This means, that we define values (i.e., business objects) for each actor it holds before and after the execution of the use case. This is done by annotating the actors (not shown in Fig. 1). The total numbers of values in a use case needs to be invariant (i.e., a value that exists before use case execution needs still to be there after execution and a value can not appear out of nowhere). According to [13], violations of invariants may occur if there are actors that are not visible from outside the system (e.g., a passive storage that can not be observed as acting entity from the outside). They propose to add such actors in the UML use case view (but not to the use case documents). In the example of the BookTicket use case (cf., [13]), the actor Customer has an Account and an Address before execution of the use case and a Shipment and a Seat after execution. The Address is passed to the Clerk, while the Account is passed to the Bank. The Shipment is received from the Clerk. For the Seat however, there is no actor yet owning it before use case execution. Therefore, the new actor Hall, which owns the Seat before use case execution, is introduced in the UML use case view (Fig. 1a middle). Although the transformation chain approach enables us to add information to intermediate models (e.g., adding the Hall actor) it has a couple of drawbacks that are often a source of criticism on MDSD. First, once an intermediate model is refined manually, it cannot be recreated automatically, which essentially forbids modifications of models prior in the chain what leads to model inconsistencies that have to be fixed manually. For example, after we added Hall in the UML use case view, we cannot change the OpenOffice document and reexecute the transformation to UML use cases without loosing the information about 1 2

We treat all artifacts in an MDSD process as models, including documents and code; for each model, a metamodel is available.     ! " #$  %

& ' ' 

J. Johannes and U. Aßmann

  


$%#%











  














  






  


















% $% % &



&











  

50









 #



 !"

 








 





  






Fig. 1. MDSD process organised by: (a) transformation chain (b) concern separation

Hall. Second, similar information is extracted several times in the chain, which requires additional effort when defining the transformations. For example, the information about actors is extracted first from the OpenOffice document, then from the UML use case model (by two transformations) and finally from both Value Flow and UML class models to produce the Java code. Third, information is difficult to localise. When a particular information about the system has to be changed, one needs to know, where the information was defined. For example, if one discovers in the Java code that something about Hall should be changed, it is difficult to trace if Hall was introduced in the OpenOffice or the UML use case view, because the information has been transformed several times. To overcome these problems, we propose a different way of organising an MDSD process that is illustrated for the example in Fig. 1b. Instead of refining generated models, we propose to define additional information in separate models (Fig. 1b left). Here, the Hall actor is defined in a UML model, but separate from the generated UML use case model. All information about the system is organised in a central place—the concern management system—(Fig. 1b middle). Integrated views can be produced by selecting the information required from the pool of all information, transforming it into the correct format and composing it into an integrated model (Fig. 1b right). Instead of decomposing the MDSD process along the transformation chain, the information that is modelled is decomposed and organised w.r.t. the concerns that are in the system. For this, the concern management system has to analyse all information from different models to identify concerns and the relationships between them (concern analysis in Fig. 1). Furthermore, the system needs to be able to compose the information to produce different integrated views (concern composition in Fig. 1). In the next section, we present the ModelSoC approach for multi-dimensional concern separation with which concern management systems for MDSD processes can be designed. An implementation of the approach is presented in Sect. 4 that provides the tooling to define and use concern management systems in Eclipse.

Concern-Based (de)composition of MDSD Processes

3

51

ModelSoC for Multi-dimensional SoC in MDSD

In this section, we introduce ModelSoC: an approach to design MDSD processes based on concern separation and composition. The hyperspace model for SoC of Ossher and Tarr [10] supports the decomposition of a system into concerns along several concern dimensions. These span up an n-dimensional space—a hyperspace—where n is the number of utilised concern dimensions. Implementation artifacts are perceived as consisting of units. Each unit realises at most one concern in each concern dimension which is defined in a concern mapping that maps units to concerns. Units are composed into hyperslices and hypermodules. A hyperslice composes all units belonging to one concern. Hypermodules compose several hyperslices to a complete software module or program. The hyperspace model leaves it open, what exactly can be treated as unit, how concern mappings and hypermodules are specified and how the actual composition of a system from units is performed. The implementation Ossher and Tarr provide is Hyper/J [10], which supports different types of Java fragments as units (e.g., statements). It contains a dedicated language for concern mapping as well as a language for hyperslice and hypermodule definitions. Such definitions do not only enumerate concerns to compose, but also include calls to operators for composing Java units by bytecode weaving. Since the conceptual hyperspace model is independent of an implementation language, it can be used to separate concerns in models in an MDSD process, as the one shown in Sect. 2. As concern, we regard a piece of information about the system which does not require further decomposition. Examples of concerns are (a) Customer participates in Book Ticket (b) Bank participates in Book Ticket or (c) Account is exchanged between Customer and Bank. Concerns that follow the same (de)composition concept belong to the same concern dimension. For instance, a new actor is composed into a use case by adding it to a use case model. This works similar for all actors, thus both concerns (a) and (b) belong to the concern dimension Participation. On the contrary, a new value exchange is added by stating for a value which actor owns it before and which after use case execution (cf., value added invariant in Sect. 2). Thus, (c) follows different (de)composition rules and belongs to another concern dimension (Exchange). We identified three properties of MDSD that are difficult to map to the hyperspace model as it is, because they are either not considered by the model or further refine parts of the model that were left open [10]. First (Sect. 3.1), the hyperspace model does not consider that the same information may be present in multiple formats (e.g., same class in UML and Java). Second (Sect. 3.2), automated transformation of information is not covered by the hyperspace model. Third (Sect. 3.3), a refinement of the hyperspace model is that we want to forbid fixed concern mapping or hypermodule specification languages (as it is the case in Hyper/J). This is, because languages that are included in an MDSD process should be chosen based on the needs of the system’s domain, which would not be given if a technology enforces the inclusion of a predefined mapping or module language. Therefore, ModelSoC introduces the following three concepts as extensions and refinements of the hyperspace model.

52

J. Johannes and U. Aßmann








   








 

   


 




 


 





 


 





 


 

















         



    



 

Fig. 2. Multi-format units: (a) Customer participates in Book Ticket (b) Book Ticket

3.1

Multi-format Units: Realisation of Concerns in Different Formats

A fragment of a model that represents a certain concern is a unit (in the sense of [10]). Since there may be different viewpoints on the same concern in MDSD (e.g., in Fig. 1, information about actors and use cases is present in multiple views) there can be several units representing the same concern in different formats. We introduce the multi-format unit concept that bundles such units. As an example, consider Fig. 2 that shows the multi-format unit that realises the concerns Book Ticket and Customer participates in Book Ticket. To obtain a view that shows certain concerns, one has to select a viewpoint (e.g., UML use case) and if the format of the viewpoint is supported by all multi-format units that realises the corresponding concerns, the view can be composed. Hence, each multi-format unit supports a set of viewpoints, but not each multi-format unit needs to support all viewpoints used in an MDSD process. The viewpoint that is the final system (Java in the example), is most likely supported by all multiformat units. If support for a new viewpoint is needed for a multi-format unit, it can be added to without altering the existing units (i.e., existing viewpoints) in the multi-format unit (see also Sect. 3.2 below). A multi-format unit offers integration points and bindings between them to guide concern composition. Each unit has to support the integration points. This is comparable to the joinpoint concept [16]. Each unit offers its own version of the points typed by metaclasses of the metamodel for the unit (cf., Fig. 2). Thus, integration points can be defined on the metamodel of a unit (cf., Sect. 3.3 below). Since a unit may need integration along several concern dimensions, the set of integration points is not fixed but can be extended, when a new concern dimension needs to be supported. For example, the concern Book Ticket in the concern dimension UseCase (Fig. 2b) can exist on its own without the need for integration points because the concern dimension UseCase is independent of other concern dimensions. The concern Customer participates in Book Ticket in the concern dimension Participation (Fig. 2a) requires integration with Book Ticket since the Participation depends on the UseCase dimension. Therefore, the

Concern-Based (de)composition of MDSD Processes



  

53




 !"#

%$








 


 !"#

%$  
    
 


  





  


 


  





  


 

Fig. 3. Multi-format unit prototype for Participation concern dimension

multi-format unit for Customer participates in Book Ticket defines integration points for its own units and the units of Book Ticket and binds them. 3.2

Multi-format Unit Prototypes: Automating Unit Creation

It is not practical to create each unit of a multi-format unit manually. Rather, following the MDSD idea, units holding the same information should be created automatically. We note that different concerns of the same dimension have similar structure. For example, the multi-format unit realising the concern Bank participates in Book Ticket looks similar as the multi-format unit of Customer participates in Book Ticket shown in Fig. 2a (only the string  should be exchanged for  in each unit). We can use this similarity to abstract a multi-format unit to a multi-format unit prototype that defines a common structure for all concerns of one concern dimension. For this, we create one unit prototype for each format supported by the multi-format unit prototype. A unit prototype is a small template, that offers parameters for the parts that differ between units of the same concern dimension. Figure 3 shows the multi-format unit prototype for the Participation concern dimension. It has one parameter P1 for the actor name. A multi-format unit prototype can be instantiated to a multi-format unit by binding each parameter with a value (e.g., P1 can be bound to  in Fig. 3 to obtain Fig. 2a) and integration points with each other. Integration points exist in a multi-format unit prototype, but not the concrete bindings, because these integrate individual concerns. Since the parameter P1 is of the primitive type String, it is similar for all units. A parameter may also have a complex type that can differ for different views. In that case, different versions of a value are needed to bind the parameter. Integration points are always individually bound for each unit. 3.3

Meta-level Concern Mappings and Compositions

Figure 4 shows details of a concern management system for MDSD processes (cf., Fig. 1b) using the concepts introduced above. The figure illustrates that each concern dimension (a) has a multi-format unit prototype (b). The instantiation of prototypes (c), which includes binding of parameters and integration points between individual concerns, spans up the concern space (d). Having this space available, a viewpoint can be selected (e) which reduces multi-format units to normal units (f). By interpreting the bindings, these units can be composed (g)




 





 


 





 







 

 




 









 






 

 



 


J. Johannes and U. Aßmann

  





     

54








 







Fig. 4. Structure of a concern management system for an MDSD process (cf., Fig. 1b)

to an integrated view in the selected viewpoint (h). Such a view corresponds to a hyper module in the sense of [10]. Once the concern space has been established, steps (d) to (h) can be performed by a universal composition technology for any concern management system. Steps (a), (b) and (c) however, which cover the concern analysis phase (cf., Fig. 1b), require configuration for each MDSD process. Concretely, mechanisms are required to (a) define concern dimensions as well as integration points and parameters of the concerns in the dimensions, (b) define multi-format unit prototypes with integration points and parameters, (c) define how parameter and integration point binding information is extracted. (a) Concern dimensions, concern parameters and concern integration points can be defined independently of models and metamodels for an MDSD process. (b) Multi-format unit prototypes can be defined by modelling each unit prototype as a model fragment in the corresponding modelling language using an existing model editor (cf., Fig. 3). Parameters and integration points can be specified for each unit prototype based on the prototype’s metamodel. For example, the rules for IP1 must state that in the UML use case format an actor is connected to a use case by adding it to the use case’s     and for the Java format by adding the actor instantiation statement to the    realising the use case execution. Rules for the parameter P1 must state that    represents the parameter in the UML format and        represents it in the Java format. These rules effectively define the concern mappings. By assigning the model fragments and rules that make up a multi-format unit prototype to the corresponding concern dimension defined in (a), we know to which dimension the instances of the prototype belong. (c) Concern composition information is available in the user-defined models (Fig. 1b left). In the example, the information that Customer, Bank and Clerk participate in BookTicket is given in the BookTicket OpenOffice model and that Hall participates in BookTicket is given in the Hall UML model. This information can be extracted by rules based on the metamodels of the languages used. For instance, one rule must specify that each OpenOffice document instantiates the multi-format unit of the UseCase concern dimension and parameterises it with the name of the document. Furthermore, another rule must state that each mention of an actor in the document instantiates the multi-format unit prototype of the Participation dimension (cf., Fig. 3) and composes it with the

Concern-Based (de)composition of MDSD Processes

55

corresponding use case. This effectively forms the composition script for hypermodules. By assigning the rules for extracting the concern instantiation and composition information to a concern dimension defined in (a), we know which multi-format unit prototype to instantiate, which integration points to address and which parameters to fill with the extracted information.

4

Implementation Based on Reuseware

In this section we describe the implementation of ModelSoC with Reuseware [11]. Reuseware is an Eclipse-integrated tool that implements Universal Invasive Software Composition for Graph Fragments (U-ISC/Graph). ISC [17] is a program transformation approach that offers basic composition operators which can be combined to support the composition of different types of components. It is suited to realise complex and cross-cutting composition needs that arise when compositions along multiple dimensions are performed. With U-ISC [18], ISCbased composition systems can be created for arbitrary grammar-based languages with tooling that executes composition by merging syntax tree fragments. In U-ISC/Graph, we extended U-ISC to support languages defined by metamodels and work with graph fragments (i.e., model fragments). The first part of this work was presented in [19], where we only considered single modelling languages out of context of an MDSD process. In this paper, U-ISC/Graph is used to its full extent to realise ModelSoC. With U-ISC/Graph, one can define for an MDSD process (cf., Sect. 3.3): (a) concern dimensions with integration points and parameters, (b) multi-format unit prototypes and (c) concern composition rule extraction. These definitions are interpreted by Reuseware which then acts as concern management system for the MDSD process that can be used inside Eclipse in combination with Eclipse-based model editors. (a) In Reuseware, we can specify composition systems that we use to represent concern dimensions. Listing 1 (cf., [11] for notation) shows the composition system for the Participation concern dimension. The specification declares    , which we use to model the types of concerns of a dimension. Listing 1 declares the fragment roles    (which can be an actor) and 

  (which can be a use case). A fragment role holds a set of    that we use to declare integration points ( and  in the example) and parameters ( in the example). Ports can be connected with  , which define whether two ports are compatible ( and  in the example). (b) To put a composition system into use, it needs to be connected to a modelling language. This is done by specifying a component model that connects the concepts of the composition system with the concepts of the language using its metamodel (as shown in Listing 2; cf., [11] for notation). To define multiformat unit prototypes, we define each unit prototype in its languages using a suitable existing model editor and then use component models to identify parameters and integration points and relate them to a composition system and therewith to a concern dimension. For this, each port (i.e., parameter and integration point) is mapped to metaclasses of the metamodel, as shown for UML in Listing 2. The keywords  ,  ,  and ! represent different

56

J. Johannes and U. Aßmann

types of addressable points in model fragments that are modified when fragments are invasively composed (cf., [19] for details). When these mapping rules are applied to the multi-format unit prototype of the Participation and UseCase dimensions (cf., Fig. 3), the parameters and integration points are identified. (c) Component model specifications define where fragments can be integrated. On the contrary, composition language specifications help with defining which fragments are integrated. A composition language specification (shown in Listing 3; cf., [11] for notation) allows to use a modelling language as composition language. That is, it contains rules to extract information from models on which fragments are parameterised and integrated. For instance, Listing 3 defines that for each part of an OpenOffice document marked with the " #! Actor, a new actor fragment is instantiated with the  parameter bound to the name of the actor (extracted from the document with OCL query  $%& '(

'(; Line 5). Furthermore, we define that the binding of  and  is performed between the correct    and 

  by extracting the corresponding actor and use case names from the model and its ID (Lines 10/11). fragment role Participant { fragment role Collaboration { static port IP1; /*an integration point*/ static port IP2; /*an integration point*/ 3 static port P1; /*a parameter*/ 4 } } 5 contributing association Participation { Participant.IP1 --> Collaboration.IP2 }

1

2

Listing 1. (a) Composition system for concern dimension Participation

fragment role Participant { port IP1 { uml::Actor is prototype {} uml::Association is prototype {} uml::Association.ownedEnd is slot {} } port P1 {uml::Actor.name is value hook {}} }

1 2 3 4 5 6 7 8

fragment role Collaboration { port IP2 { uml::Package.packagedElement is hook {} uml::UseCase is anchor {} } }

Listing 2. (b) Parameter and integration point spec. for UML unit of Participation

1 2 3 4 5 6 7 8 9 10 11 12 13

fragment role Participant { odftext::SpanType if $styleName = ’Actor’$ { fragment = $’Participant:’.concat(self.mixed->at(1).getValue())$ ID = $Sequence{’lib’,’participation’,’Participant.’.concat(view)}$ port P1 { $self.mixed->at(1).getValue()$ } } } association Participation { odftext::SpanType if $styleName = ’Actor’$ { fragment = $’Participant:’.concat(self.mixed->at(1).getValue())$ --> fragment = $’UseCase:’.concat(ID.trimExtension().segment(-1))$ } }

Listing 3. (c) Concern composition (Participation) extraction rules for OpenOffice

Concern-Based (de)composition of MDSD Processes

57

With specifications given for all concern dimensions and viewpoints of a MDSD process, Reuseware acts as the concern management system (cf., Fig. 4) for that process. For this, Reuseware interprets the specifications to derive a composition program that represents the complete concern space (d) by showing concerns and relations between them as parameterised and linked unit prototypes. In fact, Reuseware can visualise composition programs graphically with a notation similar to the one used in step (d) in Fig. 4 (boxes with attached circles and lines between them; cf., [19]). To execute a composition program, Reuseware automatically selects suitable composition operators based on the metamodel of the involved units and therefore no further configuration is required for (e) to (h). Reuseware automatically executes the composition for all supported viewpoints by creating a composed model for each. The developer can decide at which view to look by opening a composed model in an editor of his or her choice.

5

Example Realisation and Discussion

To evaluate ModelSoC, we (1) defined the MDSD process introduced in Sect. 2 with Reuseware and (2) used it to develop a first version of the ticket shop system with the features book ticket and change seat. Afterwards, (3) we extended the MDSD process defined in (1) with a new viewpoint and concern dimension for security and used that to define security properties of the ticket shop system without changing the models defined in (2). (1) MDSD process definition Our MDSD process supports five different viewpoints as introduced in Sect. 2. Four of these viewpoints are used for refinement (i.e., manual modelling), while the UML class viewpoint is only for analysis (i.e., it gives an overview of all classes that appear in Java code, but does not support modification). We identified 11 concern dimensions that we defined as composition systems (cf., Listing 1). The average size of these specifications is 16 LOC. Each viewpoint can show concerns of certain concern dimensions as presented on the left side of Fig. 5. To add support for a concern dimension to a viewpoint, a unit prototype (created with a normal model editor) and one component model (cf., Listing 2) was defined (23 in total; average size 26 LOC). Four viewpoints support editing of concerns (i.e., instantiation of unit prototypes) shown on the right side of Fig. 5. To add editing support for a concern dimension to a viewpoint, a composition language specification (cf., Listing 3) was written (15 in total; average size 37 LOC). Note that, as expected in modeldriven development, certain concerns are created automatically. For instance, a class is created for an actor as soon as it appears in some use case and therefore the OpenOffice viewpoint influences the class dimension. All marks on the right side of Fig. 5 that have no counterpart on the left side identify such situations. Also, some concerns are shown but are not editable in the corresponding viewpoint (e.g., actors can not be changed in Java). All marks on the left side that have no counterpart on the right side identify these. If one wants to use ModelSoC for its own MDSD process, one has to write Reuseware specifications as discussed above. This is a metamodelling task which

J. Johannes and U. Aßmann usecase particip. exchange flow trigger factory class dataclass associate typebind. app security usecase particip. exchange flow trigger factory class dataclass associate typebind. app security

58

OpenOffice UML use case Value Flow UML class Java SecProp

x x x x x x x x x x x x x x x x x x1 x x x x x x2 x x x x2

x x x x

x x x x x x x x x x x

x

Fig. 5. Left side: viewpoints (y-axis) supported by concern dimension (x-axis); Right side: modelling languages used to model (y-axis) in concern dimension (x-axis) (1 factory concerns have complex parameters defined for Java format only; 2 security concerns have complex parameters defined individually for SecProp and Java formats)

is done instead of writing model transformations. Compared to traditional model transformations, Reuseware specifications are very modular as indicated by the small number of LOCs of the specifications in this example. This is not because the demonstrator system we developed with the process (discussed next) is relatively small—the process itself can be used to develop larger systems. (2) MDSD process usage Once the MDSD process is set up with Reuseware, developers can use existing model editors to edit and view different viewpoints. For composed views that are graphical, Reuseware also performs layout composition [20] in addition to composing the semantic information. Preserving layout between views helps developers to relate views to each other. Because of traceability issues, such layout preservation is often not well supported in transformation chain MDSD processes. Furthermore, developers can make mistakes which lead to inconsistencies that are discovered by Reuseware (e.g., use UML to add an actor to a use case for which no OpenOffice document exists). These errors are annotated to the source models of the error using Eclipse’s error marking mechanism. If the model editor used supports this mechanism well, the developer will most likely understand the error. However, this is not the case for all editors and sometimes external editors (e.g., OpenOffice) are used. Therefore, improving tool support and integration for error reporting and debugging is part of future work. Realising the MDSD process following ModelSoC, we are able to track information that is replicated in, scattered over, and tangled in different integrated views. A drawback of our approach, as presented now, is that the integrated views can not be edited directly. Rather, small models are edited and the integrated views are created immediately for inspection. Since tracing—which is already used for layout preservation—is simple with the explicit concern space representation, we believe that editable views can be realised by using a round-trip mechanism that propagates changes from the integrated views back. Such a mechanism could even allow editing information in a different viewpoint as it was defined in. We presented first successful results in this direction in [21].

Concern-Based (de)composition of MDSD Processes

59

While we implemented only two features of a demonstrator system with the MDSD process defined above (1), this process can be used to continue development on this or other (possible much larger) systems. For this, no modification of the process setup from (1) is required. Also for other MDSD processes, parts from (1) can be reused due to high modularity—each concern dimensions can be reused individually. (1) can also be flexibly extended as discussed next. (3) MDSD process extension To support our claim that ModelSoC supports flexible extension of an MDSD process, we extended our process (1) with a new concern dimension for security—after the two functional features were developed. Security is usually a cross-cutting concern that effects several places in a system. For modelling security information, we employed the DSML SecProp3 , to define access rights and encryption needs of the business objects in the system. This DSML was motivated by a DSML that was developed by an industrial partner in a case study in the Modelplex project [22]. There we applied our approach to add a security viewpoint to a system otherwise modelled with UML only. To allow the security modeller to see existing values that need security properties, the information from the concern dimensions Usecase, Participation and Exchange needed to be transported to the SecProp viewpoint. This was done by adding new unit prototypes (defined in SecProp) to the corresponding concern dimensions (cf., Fig. 5 bottom). A multi-format unit prototype for the security dimension was introduced supporting the SecProp and Java viewpoints. To allow integration with other dimensions, new integration points were added to the Exchange unit prototypes in SecProp and Java (by specifying a new component model; no changes to the existing specifications or Java fragments were required). Due to the given space limitations, we cannot give more details about the example here. The complete example can be found online4 . On the website, there are instructions on how to install Reuseware and the modelling tools used in the example. With this, all details of the example can be inspected by the interested reader. The site also contains visualisations of the concern space for the example.

6

Related Work

Many traditional SoC approaches are limited in so far that they can only be combined with object-oriented languages (role modelling [23], aspect-oriented programming [16] or Composition Filters [8]). In case of the hyper space model [10], only the implementation Hyper/J is limited to Java, but the model itself can be used with arbitrary languages. Thus, we used it as basis for ModelSoC. More generic SoC approaches exist in the AOM [4] area. The Theme approach [5] for AO analysis and design works with UML and requirement specifications. However, it is limited to these and enforces the usage of a predefined specification language for Themes (i.e., concern mappings). More approaches that are limited to UML and do not consider other DSMLs are discussed in [24]. 3 4

    ! " #$  %

#"(       )    '# !

60

J. Johannes and U. Aßmann

In the RAM [25] approach, different concerns are modelled in aspects where each aspect contains three views (structural, state, message) modelled with UML class, state and sequence models. Thus, an aspect in RAM can be seen as a multiformat unit supporting three different viewpoints, but no new viewpoints can be added which hinders the integration of DSMLs or GPLs such as Java. RAM makes use of the AOM tools Kompose [9] and GeKo [26] that can be configured by metamodels and thus can be, similar to Reuseware, used with arbitrary DSMLs. They are specialised for each metamodel individually, while in Reuseware the composition system concept allows us to define concern dimensions and relate them to different metamodels which we required for ModelSoC. AOSD with use cases [6] is related to our example where use case decomposition is one concern dimension. However, we support arbitrary dimensions. A recent study [27] discusses whether aspect weaving should be performed on models or code. This is motivated by the fact that some approach perform model weaving ([9,26]), while others offer translations to aspect (e.g., Aspect/J [7]) code ([5,6]). In our approach, weaving is performed with Reuseware for any viewpoint. While weaving on code level is mandatory to obtain the final system, weaving for other viewpoints can be supported if it aids development. In MDSD, many approaches support model transformation and manipulation (e.g., QVT [28], ATL [29], Epsilon [30] or SDM [31]). They relate to ModelSoC in two ways: First, all approaches named above give possibilities to declare rules that consist of three parts: (1) a pattern to match, (2) a template-like structure to produce, (3) and a mapping to insert matched data into the template. These three components are also found in ModelSoC. (1) is the concern analysis (2) are the unit-prototypes and (3) is the concern composition. We allow, compared to the other approaches, for independent reuse of (1) and the specification of (3) in concrete syntax. Second, model transformations can be used as basis technology to implement ModelSoC. Reuseware itself is implemented with SDM. UniTI [32], MCC [33], TraCo [34] and Megamodelling [35] organise MDSD processes by defining relations between models, metamodels and transformations. Compared to ModelSoC, they mainly use transformations as composition methodology. Still, ModelSoC could be used as part of a larger MDSD process and integrated with other model manipulations by one of these approaches. Finally, any MDSD approach and technology can potentially be combined with our approach, since the specifications and composition programs (which represent the concern space) in Reuseware are models with a well defined metamodel.

7

Conclusion

In this paper we presented ModelSoC, an approach to organise MDSD processes by concern (de)composition, and an implementation of it. ModelSoC enables universal separation of concerns in MDSD processes that involve arbitrary modelling languages and does not enforce the usage of predefined languages. It thus does not limit the strength of MDSD to utilise DSMLs for different viewpoints in development. Our implementation monitors the consistency of all models of

Concern-Based (de)composition of MDSD Processes

61

the system and provides a complete view of all concerns and their relationships at each point in time. ModelSoC allows for independent modification and extension of each concern dimension, thus allowing MDSD processes to evolve. We illustrated this on the model-driven development of a demonstrator system.

References 1. Steinberg, D., Budinsky, F., Paternostro, M., Merks, E.: Eclipse Modeling Framework, 2nd edn. Pearson Education, London (2009) 2. ECMFA Traceability Workshop Organisers: ECMFA Traceability Workshop Series (2010),   '*  "  " *'$ 3. Filman, R.E., Elrad, T., Clarke, S., Ak¸sit, M. (eds.): Aspect-Oriented Software Development. Addison-Wesley, Reading (2005) 4. Workshop on Aspect-Oriented Modeling Organisers: Workshop on Aspect-Oriented Modeling (AOM) Series (2010),  " '  5. Clarke, S., Baniassad, E.: Aspect-Oriented Analysis and Design: The Theme Approach. Addison-Wesley, Reading (April 2005) 6. Jacobson, I., Ng, P.W.: AOSD with Use Cases. Addison-Wesley, Reading (2004) 7. Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W.G.: An Overview of AspectJ. In: Knudsen, J.L. (ed.) ECOOP 2001. LNCS, vol. 2072, p. 327. Springer, Heidelberg (2001) 8. Bergmans, L., Aksit, M.: Composing Crosscutting Concerns Using Composition Filters. ACM 44(10), 51–57 (2001) 9. Fleurey, F., Baudry, B., France, R., Ghosh, S.: A Generic Approach For Automatic Model Composition. In: Proc. of AOM @ MODELS 2007. LNCS. Springer, Heidelberg (2007) 10. Ossher, H., Tarr, P.: Multi-Dimensional Separation of Concerns and The Hyperspace Approach. In: Proc. of Symp. on SWArch. and CompTechn. Kluwer, Dordrecht (2000) 11. Software Technology Group, Technische Universit¨ at Dresden: Reuseware Composition Framework (2010),     12. IBM: Concern Manip. Environment (2006),  "   " " 13. Roussev, B., Wu, J.: Transforming Use Case Models to Class Models and OCLSpecifications. Int. Journal of Computers and Applications 29(1), 59–69 (2007) 14. Eclipse: UML2 metamodel (2010), "'   '+ ",'15. Heidenreich, F., Johannes, J., Seifert, M., Wende, C.: Closing the Gap between Modelling and Java. In: van den Brand, M., Gaˇsevi´c, D., Gray, J. (eds.) SLE 2009. LNCS, vol. 5969, pp. 374–383. Springer, Heidelberg (2010) 16. Kiczales, G., Lamping, J., Menhdhekar, A., Maeda, C., Lopes, C., Loingtier, J.M., Irwin, J.: Aspect-Oriented Programming. In: Aksit, M., Matsuoka, S. (eds.) ECOOP 1997. LNCS, vol. 1241, pp. 220–242. Springer, Heidelberg (1997) 17. Aßmann, U.: Invasive Software Composition. Springer, Heidelberg (April 2003) 18. Henriksson, J.: A Lightweight Framework for Universal Fragment Composition— with an application in the Semantic Web. PhD thesis, TU Dresden (January 2009) 19. Heidenreich, F., Henriksson, J., Johannes, J., Zschaler, S.: On LanguageIndependent Model Modularisation. In: Katz, S., Ossher, H., France, R., J´ez´equel, J.-M. (eds.) TAOSD VI. LNCS, vol. 5560, pp. 39–82. Springer, Heidelberg (2009)

62

J. Johannes and U. Aßmann

20. Johannes, J., Gaul, K.: Towards a Generic Layout Composition Framework for Domain Specific Models. In: Proc. of DSM 2009 at OOPSLA (2009) 21. Johannes, J., Samlaus, R., Seifert, M.: Round-trip Support for Invasive Software Composition Systems. In: Bergel, A., Fabry, J. (eds.) SC 2009. LNCS, vol. 5634, pp. 90–106. Springer, Heidelberg (2009) 22. Modelplex: D1.1.a (v3): Case Study Scenario Definitions (2008),  ''  23. Steimann, F.: On the representation of roles in object-oriented and conceptual modelling. Data & Knowledge Engineering 35(1), 83–106 (2000) 24. Schauerhuber, A., Retschitzegger, W., Kappel, G., Kapsammer, E., Wimmer, M., Schwinger, W.: A Survey on AOM Approaches. Technical report, JKU Linz (2006) 25. Kienzle, J., Al Abed, W., Klein, J.: Aspect-Oriented Multi-View Modeling. In: Proc. of AOSD 2009, pp. 87–98. ACM, New York (2009) 26. Morin, B., Klein, J., Barais, O., J´ez´equel, J.M.: A Generic Weaver for Supporting Product Lines. In: Proc. of EA 2008, pp. 11–18. ACM, New York (2008) 27. Hovsepyan, A., Scandariato, R., Van Baelen, S., Berbers, Y., Joosen, W.: From Aspect-Oriented Models to Aspect-Oriented Code? In: AOSD 2010. ACM, New York (2010) 28. Object Management Group: Meta Object Facility 2.0 Query/View/Transformation, QVT (2008),   "* "+  './.0.1 29. Eclipse: ATLAS Transformation Language (2010), "'  - ' 30. Kolovos, D.S.: An Extensible Platform for Specification of Integrated Languages for Model Management. PhD thesis, University of York (2008) 31. Fischer, T., Niere, J., Torunski, L., Z¨ undorf, A.: Story Diagrams: A New Graph Rewrite Language Based on the UML and Java. In: Ehrig, H., Engels, G., Kreowski, H.-J., Rozenberg, G. (eds.) TAGT 1998. LNCS, vol. 1764, pp. 296–309. Springer, Heidelberg (2000) 32. Vanhooff, B., Ayed, D., Baelen, S.V., Joosen, W., Berbers, Y.: UniTI: A Unified Transformation Infrastructure. In: Engels, G., Opdyke, B., Schmidt, D.C., Weil, F. (eds.) MODELS 2007. LNCS, vol. 4735, pp. 31–45. Springer, Heidelberg (2007) 33. Kleppe, A.: MCC: A Model Transformation Environment. In: Rensink, A., Warmer, J. (eds.) ECMDA-FA 2006. LNCS, vol. 4066, pp. 173–187. Springer, Heidelberg (2006) 34. Heidenreich, F., Kopcsek, J., Aßmann, U.: Safe Composition of Transformations. In: Tratt, L., Gogolla, M. (eds.) ICMT 2010. LNCS, vol. 6142, pp. 108–122. Springer, Heidelberg (2010) 35. B´ezivin, J., Jouault, F., Valduriez, P.: On the Need for Megamodels. In: Proc. of Best Practices for MDSD Workshop (2004)

Flexible Model Element Introduction Policies for Aspect-Oriented Modeling Brice Morin1,2 , Jacques Klein3 , J¨ org Kienzle4 , and Jean-Marc J´ez´equel1,5 1

3

INRIA, Centre Rennes - Bretagne Atlantique, France [email protected] 2 SINTEF ICT, Oslo, Norway Interdisciplinary Centre for Security, Reliability and Trust University of Luxembourg [email protected] 4 School of Computer Science, McGill University [email protected] 5 IRISA, Universit´e de Rennes1, France [email protected]

Abstract. Aspect-Oriented Modeling techniques make it possible to use model transformation to achieve advanced separation of concerns within models. Applying aspects that introduce model elements into a base model in the context of large, potentially composite models is nevertheless tricky: when a pointcut model matches several join points within the base model, it is not clear whether the introduced element should be instantiated once for each match, once within each composite, once for the whole model, or based on a more elaborate criteria. This paper argues that in order to enable a modeler to write semantically correct aspects for large, composite models, an aspect weaver must support a flexible instantiation policy for model element introduction. Example models highlighting the need for such a mechanism are shown, and details of how such policies can be implemented are presented.

1

Introduction

Abstraction and separation of concerns are two fundamental principles applied in software engineering to address a continuously wider range of software development problems. In particular, abstraction and separation of concerns can help to deal with the increasing complexity of modern software. The Model-Driven Engineering (MDE) paradigm [17] proposes to consider models as first-class entities. A model captures a given aspect of the reality, for example the structure (class or component diagrams) or the behaviour (state machines or sequence diagrams) of a system. Even if a model is an abstraction 

This work was partially funded by the DiVA project (EU FP7 STREP, contract 215412, http://www.ict-diva.eu/), and the SPLIT project (FNR and CNRS funding, http://wiki.lassy.uni.lu/Projects/SPLIT), as well as the Canadian National Sciences and Engineering Research Council.

D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 63–77, 2010. c Springer-Verlag Berlin Heidelberg 2010 

64

B. Morin et al.

of the reality (simpler than the reality) and hides irrelevant details, modelling a complex system is not a simple task and the size of a model of an application can grow rapidly, thus reducing its maintainability, readability, etc. The Aspect-Oriented Modelling (AOM) paradigm [19, 1, 10], which is inspired by AOP [8, 9], mixins [18] and Feature-Oriented Programming [16], is an attempt towards a better separation of concerns in MDE. Over the last decade, many AOM approaches have been proposed with very few publicly available (or maintained) implementations. Noticeable exceptions are the Motorola WEAVR [2], dedicated to the weaving of AspectJ-like aspects into state machines, or the academic weavers implemented in Kermeta [15] by the Triskell team (and associated teams): Kompose1 [3] (with Colorado State University), GeKo2 [12] (with University of Luxembourg) and SmartAdapters3 [13] (Formerly with I3S NiceSophia Antipolis and Institut Telecom/Universit´e de Lille 1, recently improved within the DiVA project). Because of the lack of functioning weavers, many of the proposed approaches have only been applied to simple academic examples and were not tested on real-life models. In particular, these approaches have difficulties to weave aspects into composite or hierarchical models (class diagrams with packages, sub-packages and classes ; composite state machines ; composite component diagrams ; etc). Indeed, they often only offer one way for an aspect model to introduce new model elements into the base model. This paper argues that in order to enable a modeller to write semantically correct aspects for large, composite models, an aspect weaver must support a flexible instantiation policy for model element introduction. Section 2 motivates the need for such a mechanism by example. Section 3 explains that the desired flexibility can be added to existing AOM approaches by augmenting the weaver with an advice sharing capability. For every model element introduced by an aspect, the modeller can specify if and how instances of the element are shared between multiple applications of the advice model. Implementation details of advice sharing in the context of the SmartAdapter approach are presented in Section 4. Section 5 shows how advice sharing can be used in a real-world model to implement state recovery. Secton 6 presents related work, and the last section draws our conclusions.

2

Motivating Example: A (not so) Simple Log Aspect

We propose to illustrate the need for advice sharing in the context of hierarchical component diagrams. The example aspect that we are going to use is a simple Logging aspect presented in Figure 1. The effect of this aspect model consists in introducing a new Logger component into the model, and linking any component that requires the log service to it. In the following we illustrate how the result of applying the Logging aspect to different base models using different weaving policies can produce drastically 1 2 3

https://gforge.inria.fr/frs/?group id=32 http://se2c.uni.lu/tiki-index.php?page=Geko http://divastudio.gforge.inria.fr/bundle/latest build/DiVAStudio.zip

Flexible Model Element Introduction Policies for Aspect-Oriented Modeling

Any

Any

Pointcut

65

Logger Advice

Fig. 1. A Simple Logging Aspect

different results. If we apply the Logging aspect on a simple flat component architecture, a new Logger is introduced each time a match of the pointcut model (in this case a component Any) is detected in the base model. As a result, each component that requires the log service is going to be connected to its own logger, as illustrated in Fig. 2. Logger A

B

C

A

Base model

Logger

B

C

Woven model

Fig. 2. Weaving the Simple Logging Aspect Into a Flat Base

This result is probably not the one we would like to achieve. Rather, we would like to obtain the result illustrated in Figure 3. In this case, all the components that require the log service are connected to the same Logger instance. In other words, the aspect only introduces one unique instance of the Logger component. However, the link that is created between the component and the Logger instance is created per pointcut match. We introduced the original notion of uniqueness for aspect-oriented modeling in 2007 in the context of the SmartAdapters approach [14]. In 2009, Grønmo et al. [6] introduce a collection operator for graph transformation, which achieves a similar effect, thus confirming the need for more elaborate introduction control. In the following we will call this introduction strategy global, instead of uniqueness. Logger A

B

C

Fig. 3. Weaving the Simple Logging Aspect: Expected result

Let us now consider an architecture composed of a hierarchy of components, such as the one illustrated in Figure 4. In this case, we would like the application of our Logging aspect to result in the creation of a Logger component for each composite component. The Logger instance of the composite component would then be used by all the internal components of the composite. This strategy is useful in order to log warnings, errors, etc. separately for each composite with the aim of improving readability.

66

B. Morin et al.

A

B

D

E

C

Fig. 4. A Composite Architecture

Without a more fine-grained introduction support, we cannot write a simple Logging aspect that would achieve the desired effect. If we do not declare the introduced Logger component as global, we end up with 4 new Logger instances connected to A, B, D and E. We can not declare the introduced Logger component as global, because we want to introduce more than one Logger instance. Also, since a single model element cannot be contained by multiple containers (the sub-component relationship is a composite reference in the architectural metamodel), it is not possible to add the same logger component in different composite components. More precisely, the logger component will be added into the first composite component and bound to all the internal components, i.e. A and B. Next, it will be moved inside the second composite component, and bindings are established to C and D. At the end, this would lead to an erroneous configuration, with bindings that “cut across” the boundaries of their composite components as illustrated in Figure 5.

A

B

C

Logger D

E

Fig. 5. A Composite Architecture, with the Logging Aspect Badly Woven

We hope that this simple example highlights that there is a real need for a more flexible notion of model element introduction in AOM. The advice model should be able to specify how model elements that are introduced into the base model are shared between multiple join points. Note that the problem we are describing here is common to all the pointcut-based AOM weavers, including GeKo [12], MATA [19, 7], and XWeave [5]. This problem is not specific to composite architectural models, as we can find the problem in hierarchical state machines, class diagrams (with packages and sub-packages), or even sequence diagrams (see Section 5). In our Logger example, using a more flexible notion of sharing of model elements introduced by an advice, it should be possible to obtain the desired result illustrated in Figure 6.

Flexible Model Element Introduction Policies for Aspect-Oriented Modeling

67

Logger A

B

C

Logger D

E

Fig. 6. A Composite Architecture, with the Logging Aspect correctly woven

3

3.1

Flexible Policies for Sharing Introduced Model Elements between Multiple Join Points A Simple Metamodel for Pointcut-Based Weavers

In pointcut-based approaches (e.g. SmartAdapters), an aspect is composed of three parts, as illustrated by Figure 7: 1. an advice model, representing what we want to weave, 2. a pointcut model, representing where we want to weave the aspect and 3. weaving directives specifying how to weave the advice model at the join points matching the pointcut model. Both the advice and the pointcut models allow the designer to define the aspect in a declarative way (what), whereas the weaving directives allow the designer to specify the composition. This can be done using a simple statically-typed imperative (how) language (like in SmartAdapters [14]), with graphical composition directives (like in MATA [19] using and > stereotypes) or by specifying mappings (like in GeKo [12]).

Fig. 7. The SmartAdapters Core Metamodel

68

3.2

B. Morin et al.

A Metamodel for Sharing of Introduced Model Elements

The behavior of weavers in general is to weave the model elements that are introduced in an advice model into the base model each time the pointcut model matches. In [11] we had already introduced the notion of uniqueness for introduced advice model elements as part of the SmartAdapters approach. Unique elements are instantiated only once, making it possible to reuse these elements during each composition of an aspect within the same base model. However, as shown by example in section 2, this policy is not sufficient to handle models with hierarchy, e.g., state charts with composite states, component diagrams with composite components, class diagrams with packages and sub-packages, etc. Diagrams with object instances such as sequence diagrams or communication diagrams are also problematic, as shown later in section 5.

Fig. 8. Extended SmartAdapters Metamodel for Handling Introduction Strategies

The main contribution of this paper is to introduce the notion of sharing of introduced model elements into aspect-oriented modeling. To this aim, the advice model must conform to the extended metamodel MM’ shown in Fig. 8. We propose to associate an instantiation strategy to model elements introduced in an advice model. In the case the weaver determines several join points in the base model that match the pointcut model, the designer can choose among several instantiation strategies for each introduced model element in the advice model: – Per Pointcut Match. A new instance of the advice element is introduced for each pointcut match. See for example the bindings in Fig. 2. This is the standard behavior of conventional model weavers. – Global. A single instance of the model element is introduced into the base model, regardless of how many join point matches are found. In the case

Flexible Model Element Introduction Policies for Aspect-Oriented Modeling

69

where there are several join points, the model elements designated as global are introduced only the first time the advice is applied, and reused in the subsequent applications of the advice. The Logger component in Figure 3 is an example of a global element. – Per Role Match (pe1 , pe2 , ..., pen ). An instance of the element is introduced each time the pattern matcher associates a different tuple of base elements (be1 , be2 , ..., ben ) with the model elements (pe1 , pe2 , ..., pen ) in the pointcut model. In other words, we reuse the same instance of an introduced model element in all the weavings where base model element bei plays the role pei defined in the pointcut model. – Per Element Match (pe1 , pe2 , ..., pen ). An instance of the element is introduced each time the pattern matcher associates a different set of base elements bei with the model elements pei in the pointcut model. In other words, we reuse the same instance of an introduced model element in all the weavings where the set of base model elements bei that is matched by pei is the same, regardless if the actual role the base elements play remains the same or not. To illustrate the difference between per role match and per element match, let us introduce a very simple example, illustrated in Figure 9. The pointcut model is composed of two (symmetric) connected components Any and Another. The advice model simply links a component X to these two components. In the base model composed of two connected component A and B, the pointcut matches twice: (1) Any→A, Another→B, and (2) Any→B, Another→A. In the case of the PerElementMatch(Any, Another) strategy, a single instance of X is introduced, since both pointcut matches globally maps to the same set of model elements. However, in the case of the PerRoleMatch(Any, Another), X is instantiated twice because in the two pointcut matches, A and B play different roles. In hierarchical models the PerRoleMatch and PerElementMatch can be used to define a scope for a weaving as illustrated in the new version of the Logging

Aspect 1 Any

Another

Pointcut Model A

B

Any

Another

Advice Model

Aspect 2

X

Base Model Any

perElementMatch(Any,Another)

X

Another

Pointcut Model

Any

perRoleMatch(Any,Another)

Another

Advice Model X1 X2

X A

B

Result with perElementMatch strategy

A

B

Result with perRoleMatch strategy

Fig. 9. Per Role Match and Per Element Match strategies

70

B. Morin et al.

aspect shown in Fig. 10. We added in the pointcut the composite component Container containing the component that requires the log service. This composite allows us to define the scope of the Logger component and associate the logger component with a PerRoleMatch(Container) strategy4 to achieve the weaving illustrated in Fig. 6. Indeed, in this way, the Logger component will be only instantiated once for all pointcut matches in a same Container. Container

Any Pointcut

Container

Any

Logger

perRoleMatch (Container)

Advice

Fig. 10. Logging Aspect revisited with a PerRoleMatch Introduction Strategy

4

Implementation of Advice Sharing

This section provides implementation details on how we implemented the flexible introduction policies described in section 3 in the context of SmartAdapters. However, we believe that our description is general enough to provide insight to readers wishing to integrate the same strategies to other approaches. In our latest version of SmartAdapters, our weaver generates for each aspect model Drools and Java code to perform the weaving. Drools (a.k.a JBoss Rules) is a rule engine that implements the RETE algorithm [4] with optimization for object-orientation to efficiently find patterns in OO structures, and is used in SmartAdapters to perform join point detection. The Java code performs the actual weaving of the advice for each join point match. The use of Drools and Java is however completely hidden from the modeler. All scripts presented in this section were automatically generated by our weaver5. The generated script for the compiled version of the Logging aspect where the Logger component uses a global introduction policy (see Fig. 1 and Fig. 3) is shown below. In Drools, each application of a rule is independent from the previous ones. For example, if the pointcut (when clause lines 3 to 7) matches several times in a base model, it is not possible to directly know if an element from the advice (then clause lines 8 to 21) has already been created in a previous application of the aspect. This is not a problem for the standard PerPointcutMatch strategy, but becomes an issue that must be overcome in order to implement the other three introduction policies. 4

5

Note that in the case where only one model element is given in the introduction policy like it is the case in this example, PerRoleMatch and PerElementMatch yield identical results. The only modifications made to the generated scripts to improve readability are: the renaming of some variables, the introduction of comments, the removal of casts and the removal of the lines not relevant for the discussion.

Flexible Model Element Introduction Policies for Aspect-Oriented Modeling

71

Luckily it is possible to declare global variables, initialized by the Java code calling the Drools engine with the script, to share data between different application of the advice. We thus use the globalElem map (see line 1) as the structure that keeps track of the global elements of the advice model. Basically, each advice element is identified by a unique string. Before creating a unique element, we check if this element already exists in the globalElem global map (see line 12 and 13). It this element already exists, it is reused. Otherwise, it is created and stored in the global map (lines 14 and 15).

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

g l o b a l Map<S t r i n g , EObject> g l o b a l E l e m ; r u l e ” LoggingAspect ” when // P o i n t c u t $ l o g S e r v i c e : type . S e r v i c e ( name==”o r g . s l f 4 j . Logger ” ) $reqLogPort : t ype . Port ( r o l e==” c l i e n t ” , s e r v i c e==$ l o g S e r v i c e ) $anyType : typ e . P r i m i t i v e T y p e ( p o r t c o n t a i n s $reqLogPort ) $anyCpt : i n s t a n c e . P r i m i t i v e I n s t a n c e ( type==$anyType ) then // C r e a t i o n o f Advice model e l e m e n t s ... // D e f a u l t L o g g e r component ( u n i qu e ) i n s t a n c e . P r i m i t i v e I n s t a n c e logCpt = g l o b a l E l e m . g e t ( ” logCpt ” ) ; i f ( logCpt == n u l l ) { logCpt = c r e a t e P r i m i t i v e I n s t a n c e ( ) ; g l o b a l E l e m . put ( ” logCpt ” , logCpt ) ; } ... // Binding t o t h e D e f a u l t L o g g e r component ( p e r p o i n t c u t match ) i n s t a n c e . Binding b i n d i n g = c r e a t e B i n d i n g ( ) ; ... end

The following script is the compiled version of the Logging aspect when the Logger component uses the PerElementMatch(Container) instantiation policy (see Fig. 10). We also use a global map perElem; however, the key of this map is a set of EObject (model elements) from the base model. In Java, the hash code of a set is computed as the sum of all the hash codes of the elements contained in this set. It thus can be possible that two different sets (containing different elements) have the same hash code. While this is not recommended (for performance issues), a Map can handle this case and retrieve the right values even if two (different) keys have the same hash code. Indeed, according to the Java specification, the containsKey(Object key) method “returns true if and only if this map contains a mapping for a key k such that (key==null ? k==null : key.equals(k))”. Finally two sets are equals if “the two sets have the same size, and every member of the specified set is contained in this set (or equivalently, every member of this set is contained in the specified set).” This is exactly the behavior we need to implement the PerElementMatch introduction policy.

72

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

B. Morin et al.

g l o b a l Map<Set<EObject >,Map<S t r i n g , EObject>> perElem ; r u l e ” LoggingAspect ” when // P o i n t c u t $ l o g S e r v i c e : type . S e r v i c e ( name==”o r g . s l f 4 j . Logger ” ) $reqLogPort : t ype . Port ( r o l e==” c l i e n t ” , s e r v i c e==$ l o g S e r v i c e ) $anyType : typ e . P r i m i t i v e T y p e ( p o r t c o n t a i n s $reqLogPort ) $anyCpt : i n s t a n c e . P r i m i t i v e I n s t a n c e ( type==$anyType ) $anyComposite : i n s t a n c e . C o m p o s i t e I n s t a n c e ( subCpts c o n t a i n s $anyCpt ) then // I n i t o f t h e s t r u c t u r e managing t h e p e r e l e m e n t s t r a t e g y Set<EObject> c o m p o s i t e S c o p e = new HashSet<EObject >() ; c o m p o s i t e S c o p e . add ( $anyComposite ) ; i f ( perElem . g e t ( c o m p o s i t e S c o p e ) == n u l l ) { perElem . put ( c o m p o s i t e S c o p e , new Hashtable <S t r i n g , EObject >() ) ; } // C r e a t i o n o f Advice model e l e m e n t s ... // D e f a u l t L o g g e r component ( u n i q u e with s c o p e ) i n s t a n c e . P r i m i t i v e I n s t a n c e logComponent = perElem . g e t ( c o m p o s i t e S c o p e ) . g e t ( ” logComponent ” ) ; i f ( logComponent == n u l l ) { logComponent = c r e a t e P r i m i t i v e I n s t a n c e ( ) ; perElem . g e t ( c o m p o s i t e S c o p e ) . put ( ” logComponent ” , logComponent ) ; } ... end

In the same way, the perRoleMatch mechanism can be implemented with a Map<Map<String, EObject>, Map<String, EObject>>, where: – the • • – the • •

5

key is a Map<String, EObject>, where: the key is a String identifying the role of a pointcut model element the value is a base model element that matches the role value is a Map<String, EObject>, where: the key is a String identifying an advice model element the value is a clone of an advice model element

Using Flexible Introduction Policies to Implement Recovery

This section demonstrates by means of a real-world example how important it is for a weaver to support flexible sharing of introduced model elements. In data-centric dependable systems, the consistency of the state of the application is of utmost importance. Any modification of the application state is carefully checked to make sure that no inconsistencies are introduced. In the case where an error is detected, the application must perform recovery actions

Flexible Model Element Introduction Policies for Aspect-Oriented Modeling

73

in order to address the situation. To restore application consistency, forward or backward error recovery techniques can be used. Forward error recovery consists in first performing detailed damage assessment to determine which parts of the application state are inconsistent. Then, additional operations on the erroneous application state are performed to create a (new) consistent state. In backward error recovery, the application state is saved periodically. When an error is detected, the application is returned to that (old) consistent state by undoing all the state changes performed since the last save point. Forward and backward error recovery can be implemented using different techniques. One popular way is to keep track of all operation invocations on application data objects at run-time. This information is useful for detailed damage assessment (used in forward error recovery), as well as for undoing state changes by executing compensating actions (useful for backward error recovery). To implement operation tracing, an operation list is usually associated with each data object. Each time a modifying operation is invoked on the data object, the operation is saved in the list. In addition, each data object that is modified is registered with a recovery manager, i.e. with an object that coordinates the recovery process of all affected data objects in case of a failure. This behaviour can conveniently be described using a sequence diagram aspect model as shown in Fig. 11. The pointcut model states that we are looking for places where a caller instance of class C synchronously invokes a method m on a target instance of class Data. In this case the Data class encapsulates the valuable application data that needs to be kept consistent. It is obvious that in any real-world base model, a weaver would most likely find matches for such a pointcut. The advice model of the aspect in Fig. 11 states that several new model elements are to be introduced into the execution of the method call m: 1. a constructor call to create, which instantiates 2. a new myOps instance of the class OperationList 3. a call to the method insert of myOps

Pointcut caller : C

target : Data

Advice c : Caller

global()

target : Data : RecoveryManager

* m(..)

* m(..)

perElementMatch(target)

create()

myOps: OperationList

insert(m) register(target) perPointcutMatch()

Fig. 11. A Sequence Diagram Aspect Model for Recovery Support

74

B. Morin et al.

4. an unnamed instance of the RecoveryManager class 5. a call to the method register of the RecoveryManager instance In general, there is only one recovery manager per application, therefore the introduction of the RecoveryManager instance must be tagged as global. Every instance of the class Data that is the target of a method call must get its own associated OperationList instance to store the method invocation (and all future subsequent ones). Hence the myOps instance introduction is tagged as perElementMatch(target). As a result, the constructor call introduction must also be tagged as perElementMatch(target). The insert method call introduction, however, is tagged as perPointcutMatch, since each and every method invocation needs to be stored for recovery to be possible. Finally, each instance of the class Data that is accessed needs to register with the recovery manager. To make this happen only once for each Data object, the call to the register method is tagged perElementMatch(target). x:X

a : Account

deposit(10)

b : Account

withdraw(30) deposit(30)

Fig. 12. A Banking Base

Applying the aspect of Fig. 11 to a simple banking base model such as the one shown in Fig. 12 results in the woven model shown in Fig. 13. The result is as desired: there is only 1 instance of RecoveryManager, there are two OperationList instances, two calls to create, two calls to register, and 3 calls to insert.

6

Related Work

To the best of our knowledge, the current existing AOM weavers using a pointcutbased approach do not propose sophisticated solutions to deal with the problem of model element introduction in the presence of multiple join points. For instance, after a phase of detection of join points corresponding to a pointcut model, SmartAdapter [13] uses adaptations to compose an aspect model with a base model. But currently, even if these adaptations are fine grained, they only allow the specification of global or per pointcut match strategies [11]. Approaches such as MATA [19], XWeave [5] or GeKo [12] do not propose solution for the presented problem. MATA is based on graph transformations. The base model is converted into a graph. The aspect model that is to be woven is converted into a graph transformation rule, and the rule is executed on the base graph. XWeave is an asymmetric AOM approach based on the Eclipse Modeling Framework (EMF) Ecore meta-metamodel. In GeKo [12] the composition of the

Flexible Model Element Introduction Policies for Aspect-Oriented Modeling

x:X

a : Account

deposit(10)

create()

75

: RecoveryManager

b : Account myOps: OpList

insert(deposit) register(a)

withdraw(30) insert(withdraw)

deposit(30)

create()

myOps: OpList

insert(deposit) register(b)

Fig. 13. The Result of the Weaving (3 Matches)

aspect is specified thank to mappings between the pointcut and the base (automatically obtained) and the pointcut and the advice (specified by the designer). All these approaches could be extended with the introduction policies presented in this paper. In [6], Grønmo et al. define a collection operator for graph transformations to ease model transformation. More specifically, the collection operator allows the matching of a set of ”similar” join points (subgraphs in graph transformation). In this way, the transformation or the weaving can be applied once on the set of identified join points instead of applying the weaving at the level of each join point. Consequently, this technique can be seen as an example of implementation of our Global introduction policy. However, this technique is not flexible enough to specify complex composition strategies. For instance, it is not possible to mix PerPointcutMatch, perRoleMatch, and Global strategies in a same weaving. Since the collection operator is a flexible and interesting solution focusing on join point detection, this technique could be used to complement our approach. At a programming level, let us consider AspectJ [8]: it is interesting to note that by default an aspect has exactly one instance that cuts across the entire program. Consequently, because the instance of the aspect exists at all join points in the running of a program (once its class is loaded), its advice is run at all such join points. However, AspectJ also proposes some elaborate aspect instantiation directives6 : – Per-object aspects • perthis: If an aspect A is defined perthis(P ointcut), then one instance of A is created for every object that is the executing object (i.e., ”this”) at any of the join points matched by Pointcut. 6

More explanation can be found at http://www.eclipse.org/aspectj/doc/next/progguide/

76

B. Morin et al.

• pertarget : Similarly, if an aspect A is defined pertarget(P ointcut), then one instance of A is created for every object that is the target object of the join points matched by Pointcut. – Per-control-flow aspects • percflow or percflowbelow : If an aspect A is defined percf low(P ointcut) or percf lowbelow(P ointcut), then an instance of A is created for each flow of control of the join points matched by Pointcut.

7

Conclusions and Perspectives

In this paper, we presented the concept of sharing of model elements introduced by an advice model, which allows designers to specify how the advice should be integrated in the case there are multiple pointcut matches. We defined 4 introduction policies for introduced model elements. By default, new instances of the advice model elements are introduced for each pointcut match (PerPointcutMatch). However, it is possible to use other strategies to reuse the same instances for all the pointcut matches (Global ), or for a given matched set or tuple of model elements in the base model (PerElementMatch or PerRoleMatch). We implemented the four policies in the SmartAdapters [14] approach. The paper gives sufficient implementation details so that it could be integrated into any other AOM approach. SmartAdapters is currently used by the industrial partners of the DiVA project to realize real-life case studies (an airport crisis management system and a next-generation customer relationship management system). In DiVA, we are interested in weaving architectural aspects (component, ports, bindings, etc). Even if architectural models are a rather simple domain for AOM, it appears that the notion of sharing of introduced model elements was very useful for our industrial partners. Experience showed that while it is possible to achieve any desired model modification using only PerPointcutMatch introduction aspects, it typically requires several aspects with complex pointcut models to achieve the desired effect. We believe that flexible introduction policies also make writing of reusable aspect models a lot easier. They allow a modeler to state in a simple, base model-independent way under which conditions certain model elements are to be introduced. We intend to conduct experiments to validate this claim in the context of the Reusable Aspect Models (RAM) approach [10] in the near future.

References 1. Clarke, S., Baniassad, E.: Aspect-Oriented Analysis and Design: The Theme Approach. Addison-Wesley Professional, Reading (April 2005) 2. Cottenier, T., van den Berg, A., Elrad, T.: The Motorola WEAVR: Model Weaving in a Large Industrial Context. In: AOSD 2007: 6th International Conference on Aspect-Oriented Software Development - Industry Track, Vancouver, Canada (2007)

Flexible Model Element Introduction Policies for Aspect-Oriented Modeling

77

3. Fleurey, F., Baudry, B., France, R., Ghosh, S.: A Generic Approach For Automatic Model Composition. In: AOM@MoDELS 2007: 11th Int. Workshop on AspectOriented Modeling, Nashville TN USA (October 2007) 4. Forgy, C.: Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem. Artificial Intelligence 19(1), 17–37 (1982) 5. Groher, I., Voelter, M.: Xweave: Models and aspects in concert. In: AOM Workshop 2007 at AOSD, March 12 (2007) 6. Grønmo, R., Krogdahl, S., Møller-Pedersen, B.: A Collection Operator for Graph Transformation. In: Paige, R.F. (ed.) ICMT 2009. LNCS, vol. 5563, pp. 67–82. Springer, Heidelberg (2009) 7. 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., Opdyke, B., Schmidt, D.C., Weil, F. (eds.) MODELS 2007. LNCS, vol. 4735, pp. 151–165. Springer, Heidelberg (2007) 8. Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W.G.: An Overview of AspectJ. In: Knudsen, J.L. (ed.) ECOOP 2001. LNCS, vol. 2072, pp. 327–353. Springer, Heidelberg (2001) 9. Kiczales, G., Lamping, J., Menhdhekar, A., Maeda, C., Lopes, C., Loingtier, J.M., Irwin, J.: Aspect-Oriented Programming. In: Aksit, M., Matsuoka, S. (eds.) ECOOP 1997. LNCS, vol. 1241, pp. 220–242. Springer, Heidelberg (1997) 10. Kienzle, J., Al Abed, W., Klein, J.: Aspect-Oriented Multi-View Modeling. In: AOSD 2009: 8th ACM International Conference on Aspect-Oriented Software Development, pp. 87–98. ACM, New York (2009) 11. Morin, B., Barais, O., J´ez´equel, J.M., Ramos, R.: Towards a Generic AspectOriented Modeling Framework. In: 3rd Int. ECOOP 2007 Workshop on Models and Aspects, Handling Crosscutting Concerns in MDSD, Berlin, Germany (August 2007) 12. Morin, B., Klein, J., Barais, O., J´ez´equel, J.M.: A Generic Weaver for Supporting Product Lines. In: EA@ICSE 2008: Int. Workshop on Early Aspects, Leipzig, Germany (May 2008) 13. 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) 14. Morin, B., Barais, O., Nain, G., J´ez´equel, J.-M.: Taming Dynamically Adaptive Systems with Models and Aspects. In: 31st International Conference on Software Engineering (ICSE 2009), Vancouver, Canada (May 2009) 15. Muller, P.A., Fleurey, F., J´ez´equel, J.M.: Weaving Executability into ObjectOriented Meta-languages. In: Briand, L.C., Williams, C. (eds.) MoDELS 2005. LNCS, vol. 3713, pp. 264–278. Springer, Heidelberg (2005) 16. Prehofer, C.: Feature-oriented programming: A fresh look at objects. In: Aksit, M., Matsuoka, S. (eds.) ECOOP 1997. LNCS, vol. 1241, pp. 419–443. Springer, Heidelberg (1997) 17. Schmidt, D.: Model-Driven Engineering. IEEE Computer 39(2) (February 2006) 18. Smaragdakis, Y., Batory, D.: Implementing layered designs with mixin layers. In: Jul, E. (ed.) ECOOP 1998. LNCS, vol. 1445, pp. 550–570. Springer, Heidelberg (1998) 19. Whittle, J., Jayaraman, P., Elkhodary, A., Moreira, A., Ara´ ujo, J.: MATA: A unified approach for composing UML aspect models based on graph transformation. T. Aspect-Oriented Software Development VI 6, 191–237 (2009)

Role-Based Generic Model Refactoring Jan Reimann, Mirko Seifert, and Uwe Aßmann Technische Universit¨ at Dresden Institut f¨ ur Software- und Multimediatechnik D-01062, Dresden, Germany      

}   Abstract. Refactorings can be used to improve the structure of software artifacts while preserving the semantics of the encapsulated information. Various types of refactorings have been proposed and implemented for programming languages such as Java or C#. With the advent of Model-Driven Software Development (MDSD), the need for restructuring models similar to programs has emerged. Previous work in this field [1,2] indicates that refactorings can be specified generically to foster their reuse. However, existing approaches can handle only certain types of modelling languages and reuse refactorings only once per language. In this paper a novel approach based on role models to specify generic refactorings is presented. We discuss how this resolves the limitations of previous works, as well as how specific refactorings can be defined as extensions to generic ones. The approach was implemented based on the Eclipse Modeling Framework (EMF) [3] and evaluated using multiple modelling languages and refactorings.

1

Introduction

During the development and evolution of software systems new functionality is added or existing one is adjusted to new requirements. This challenges existing software architectures in terms of their flexibility. For some changes the architecture might be perfectly suitable. In other cases, earlier design decisions can render the implementation complicated. To enable the evolution of systems while keeping their architecture clear, there is constant need to change a system’s structure, which is the essence of Lehman’s Laws of Software Evolution [4]. To improve their software designs, developers spend a lot of time manually restructuring existing code. However, the manual restructuring has a big disadvantage—it has a high probability to introduce bugs. No matter how much attention is payed by the developer, if a system is large enough, there is a good chance that the restructuring changes the behaviour of the system. Thus, one should strive for restructurings that preserve the behaviour, for which [5] introduced the term refactoring. Ever since then, refactorings have been an essential tool for developers [6]. In parallel, the extension of code-centric development to MDSD brought many problems once examined in the context of programming languages to new attention. Developers that are used to restructure code both easy and safely do not want to give up this powerful tool when operating on models. D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 78–92, 2010. c Springer-Verlag Berlin Heidelberg 2010 

Role-Based Generic Model Refactoring

79

When looking at the differences between code and models, there is a number of things that come to mind. First, the structure of code is represented by grammars while models are prescribed by metamodels [7]. The former are based on abstract syntax trees, while the latter rely on graph structures. Second, the level of concreteness of code is supposed to be higher than the one of models. Models must abstract some details of a system’s implementation. Third, metamodelling allows for quickly defining new modelling languages. Domain-Specific Languages (DSLs) can be created with small effort. This will create a whole landscape of languages, which is significantly different for traditional programming languages, of which only a few are used in industry. Especially the third point (i.e., the large variety of modelling languages) demands for generic and reusable methods and tools. The effort to develop and maintain the growing number of DSLs can only be reduced by reusing tools across different languages. This does of course also apply to refactorings. If one wants to quickly establish refactoring support for new DSLs, a technology to reuse existing refactorings is needed [8]. A closer look at the reuse of refactorings raises the question about what can be reused across multiple languages and what cannot. Previous work in this area has shown that there is potential for reuse, but it is limited in one way or the other (see Sect. 2). But this research also indicated that some aspects cannot be captured in the reusable part of the refactoring. For example, a generic refactoring cannot make assumptions about the semantics of a language. Thus, reusing refactorings requires a combination of adapting existing generic parts to the modelling language of interest and the additional specification of languagespecific information. This paper presents a new technique for this combination. Our contributions are the following: 1) limitations of existing work on generic refactorings are identified, 2) a role-based approach is proposed to overcome these limitations, 3) the novel approach is evaluated by modelling refactorings for different modelling and meta-modelling languages (e.g., Unified Modeling Language (UML) [9] and Ecore), 4) an extensible refactoring framework based on the EMF is presented, serving as a basis for evaluation and future work. The structure of this paper is as follows. Before introducing the conceptual ideas of our approach in Sect. 3, we discuss the limitations of existing work in the area in Sect. 2. Based on an implementation of our approach, we evaluated the reuse of refactorings. Results of this evaluation can be found in Sect. 4. In Sect. 5 we draw conclusions and outline future work.

2

Related Work

To analyse the limitations of existing model refactoring approaches, in particular those that are generic, we will classify related work into three categories. Depending on the Meta Object Facility (MOF) meta layer [10] at which refactorings are specified (i.e., M3, M2, or M1), different observations can be made. M3 In [2] a generic approach to specify refactorings is presented. The authors introduce a meta-metamodel (GenericMT), which enables the definition

80

J. Reimann, M. Seifert, and U. Aßmann

of refactorings on the MOF layer M3. This meta-metamodel contains structural commonalities of object-oriented M2 models (e.g., classes, methods, attributes and parameters). Refactorings are then specified on top of the GenericMT. To activate them for a specific metamodel (i.e., a model on M2) a target adaptation is needed. Once such an adaptation exists, every defined refactoring can be applied to instances of the adapted metamodel. The adaptation contains the specification of derived properties declared in the GenericMT which are not defined in the metamodel of interest. By this, an aspect-oriented approach is achieved and the newly defined properties are woven into each target metamodel. However, this approach is restrictive w.r.t. the structures of GenericMT, because this contains object-oriented elements only. DSLs that expose such structure and that have a similar semantics can be treated, while other DSLs cannot. Refactorings that require other structures cannot be implemented. Furthermore, metamodels are mapped once for all refactorings. This does not allow to map the same structure twice (e.g., if a DSL contains two concepts similar to method ). A related approach was published by Zhang et al. in [11], where refactorings are specified on top of a custom meta-metamodel similar to MOF. With the specification on M3 a metamodel-independent solution of generic model refactorings is achieved, but again the DSL designer has limited control over the elements that participate in a refactoring. In summary one can say that the approaches targeting M3 are limited w.r.t. to the structures refactorings operate on. M2 Other approaches target the MOF layer where metamodels reside—M2. Defining refactorings on top of these metamodels implies that refactorings can work only on one specific language. [12] and [13] follow this approach and introduce the graphical definition of refactorings. DSL designers can graphically define a pre-condition model, a post-condition model and a model containing prohibited structures. All models can share links to express their relations and those which are not subject to modification during the transformation. By this technique, a graph is constructed and therefore further analysis can be conducted. The advantage of specifying refactorings on M2 is that the target structures of the metamodel can be controlled. However, reuse and the generic specification are sacrificed. Refactorings for specific metamodels cannot be reused for other languages, but must be defined again although the core steps are the same. M1 In [14] and [15] a refactoring-by-example approach is presented, which enables the user of refactorings to specify them on concrete instances of a specific metamodel (i.e., on level M1). Modifications are recorded and then abstracted and propagated to the specific metamodel. Since this metamodel is situated on the M2 layer again, this approach does not allow for reuse either. Based on the analysis of related works in the field, we observed that the specification of refactorings on a single MOF layer does not yield a satisfactory result. Therefore, a technique is needed that is able to combine the advantages of layer M3 and M2 specifications. Such a technique must solve the problem that M3 approaches are limited to a specific group of languages, by allowing

Role-Based Generic Model Refactoring

81

to use multiple structural patterns rather than a single one (e.g., the objectoriented concepts). It must also address the limitation of M2 approaches, which are specific to one language. A dedicated solution should allow DSL designers to reuse individual generic refactorings for multiple languages.

3

Specifying Refactorings with Role Models

Previously, we have argued that there is a strong need to reuse refactorings, in particular in the context of DSLs. To enable such reuse, the parts of refactorings that can be generalised must be separated from the ones that are specific to a particular language. Consider for example the basic refactoring RenameElement. The steps needed to perform this refactoring are equal no matter what kind of element needs to be renamed. After changing the value of a string-typed attribute, all references to the element need to be updated. The concrete attribute may vary for different languages, but the general procedure is the same. Depending on constraints that apply to particular languages (e.g., whether unique names are required) some renamings may be valid, while others need to be rejected. From the simple example we gained some initial insights. First, the structural part of a refactoring (i.e., the elements that are transformed) is a good candidate for reuse. Second, the semantics of a language can render concrete refactorings invalid. Also, the example shows that semantics—both static and dynamic—are language-specific and therefore, cannot be part of a generic refactoring. We have also seen that the execution of a refactoring can be a composition of a generic transformation and specific steps that differ from language to language. We will postpone the language specifics for a moment (see Sect. 3.4) and look at the structural and transformational aspects of refactorings first. To reuse the structural part of refactorings, a model of this structure is needed. More precisely, the structure of models that can be handled by a refactoring must be specified. For the RenameElement example, this structure basically consists of an attribute in the metamodel. Any model element that has such an attribute (i.e., it is an instance of the metaclass that defines the attribute) can be renamed. Other refactorings (e.g., ExtractMethod), have more complex structural constraints, such as requiring that the elements to extract (i.e., statements) need to be contained in a container object (i.e., a method). To model such structural properties—one may also consider these as structural requirements—we choose to use Role Models as they were proposed in [16]. Roles encapsulate the behaviour of a model element with regard to a context. Roles appear in pairs or sets, so-called collaborations. In the context of this work, roles can be considered as the types of elements that are subject to a refactoring. The role collaborations model the references between the elements required to execute a refactoring. More details about this will be presented in Sect. 3.1. To map the abstract structural definition of the input required by a refactoring to concrete languages, a relation between the structural definition (i.e., the role model) and the metamodel of the language must be established. This mapping defines which elements of the metamodel are valid substitutions for elements

82

J. Reimann, M. Seifert, and U. Aßmann

DSL Designer

DSL Meta Model

DSL User

DSL Model refers to

Role Mapping Metamodel

Role Metamodel

Transformation Metamodel

Refactoring Framework

Role Mapping

Role Model

Transformation Specification

Refactoring Designer

Refactoring Interpreter input for

instance of

Refactored DSL Model returns

Fig. 1. Metamodels, Relations and Stakeholders

in the role model. We call this relation a Role Mapping. We will discuss such mappings in Sect. 3.2. To reuse the transformational part of refactorings a third model is needed—a transformation specification. This model defines the concrete steps needed to perform the refactoring. In the example of renaming an element, this model must contain instructions to change the value of an attribute. Of course, the transformation needs to change the value of the attribute specified by the role model (i.e., it refers to the role model). Section 3.3 contains details about the transformation operators and the interpretation thereof. The models mentioned so far are depicted in upper right part of Fig. 1. Concrete models are related to their metamodel by instance-of links. The metamodels are provided as part of our framework. Two kinds of models (i.e., role models and transformation specifications) are provided by the refactoring designer. She creates generic refactorings, which consist of pairs of such models. DSL designers can then bind the generic refactorings to their languages by creating role mappings. This enables DSL users to apply refactorings to concrete models. 3.1

Specifying Structural Constraints Using Role Models

To explain role models in more detail, consider a concrete refactoring for Ecore models—Extract Superclass. This refactoring can be applied to a set of structural features (i.e., attributes or references) and moves the given set of features to a new EClass. The new EClass is then added to the list of super types for the original EClass. Suppose we are convinced that this type of refactoring (i.e., moving a set of elements to a new container) is useful for other languages too and we want to derive a generic refactoring—ExtractX. To capture the structural properties of our refactoring we use a role model. For the ExtractX refactoring, we consider elements that are extracted, their container and a new container where the elements are moved to. Elements participating in a refactoring form groups, where all elements within one group are handled equally. In other words, elements play a certain role w.r.t. a refactoring.

Role-Based Generic Model Refactoring

83


   
      
   
   
          

!"##"$ %&'       !(##)$    

!"##"$ %&'     !(##)$       !"##"$ %&'     !"##"$       !"##"$ %&'      !"##"$     

!"##)$ ''   *   !"##)$ +

(a) Graphical representation

(b) Textual representation

Fig. 2. Role Model for the ExtractX refactoring

The elements that are extracted (e.g., structural features) play the Extractee role. The object that contains the extractees plays the OrigContainer role. The object the extractees are moved to, plays the NewContainer role. In other words, roles abstract from the concrete metaclasses that are allowed as participants for a refactoring. Instead of referring to concrete metaclasses, the structure that can be transformed is specified by roles. Later on, when a refactoring is enabled for a concrete language, role mapping models map roles to concrete metaclasses. Between the roles that form the nodes in our structural description, certain relations hold (the collaboration). For example, the OrigContainer must hold a containment reference to the Extractee elements. Also, a reference between the original and the new container is needed to connect the new container to the old one. We use collaborations to model such structural dependencies between roles. The complete role model for the ExtractX refactoring is depicted in Fig. 2. One can identify the roles mentioned above (shown as boxes) as well as their collaborations, which are depicted by links between the boxes. Besides the roles mentioned above, there is a role ContainerContainer which models the fact that the new and the original container must be contained in a third element. For the ExtractSuperclass refactoring this role is played by the class EPackage, which is specified in the role mapping (see Sect. 3.2). The example gives an impression how role models specify the structural constraints that must be met by a language’s metamodel to qualify for the generic ExtractX refactoring. More concepts that can be used in role models are defined by the Role metamodel shown in Fig. 3. The concepts  and   are contained in a   . Roles may be annotated by several modifiers. An   role is not needed to be mapped to a specific metaclass (e.g., if a DSL’s metamodel doesn’t contain such a metaclass in the desired context). Roles which must serve as input of a refactoring are marked with the  modifier. In the ExtractX example the Extractee

84

J. Reimann, M. Seifert, and U. Aßmann

Fig. 3. Role Metamodel

must be provided as input. The  modifier expresses that, at runtime, all subclasses of the mapped metaclass play this role, too. For example, ExtractSuperclass for Ecore must allow to extract both attributes and references of EClasses. Therefore Extractee is modelled as super role to enable the mapping to EStructuralFeature by which EAttribute and EReference are comprised. Furthermore, a  can contain    s to express that it can own observable properties (e.g., a name) which may change during the role’s life cycle. Collaborations connect two s— and  . They are further distinguished into different types. A    constraint can be used to express that one role must also play another role. A    constraint states that two roles are mutually exclusive—an element playing one role must not play the other role. The other types are characterised by multiplicities, expressing that one role can collaborate with a specific number of elements playing the related role. To distinguish between containment and non-containment references,   s and  s can be used. Using this metamodel we were able to model the structures required by all refactorings presented in Sect. 4. The next step in the development of a generic refactoring is writing a transformation specification. Such specifications do only refer to the role model of the refactoring, not to a concrete metamodel. However, we will first look at role mappings, which DSL designers can use to bind role models to concrete languages. This is needed to understand the actual execution of refactorings as this can only be performed in the context of a mapping. 3.2

Role Mappings

To control the structures intended for refactoring, the role model needs to be mapped to the target metamodel (see middle level of Fig. 1), which is performed by the DSL designer. Based on this mapping, refactorings will only be applied to those structures to which they were mapped. An example for a mapping, namely the mapping for ExtractSuperclass is shown in Fig. 4(a). The mapping is written in our DSL for role mappings. If a single refactoring shall be activated for another part of the metamodel it needs to be mapped a second time. In Fig. 4(b) the ExtractX refactoring is instantiated for enumeration literals. In the

Role-Based Generic Model Refactoring

(a) Extract Superclass

85

(b) Extract Enum

Fig. 4. Role Mappings for different parts of the Ecore metamodel

case of ExtractSuperclass and ExtractEnum, the mapping is all that is required to enable support for these two concrete refactorings. In general, role mappings conform to the metamodel depicted in Fig. 5. Here, each      refers to an EPackage containing the target metamodel and owns several   s referencing the refactoring’s role model. Each     specifies which role is played by which metaclass from the target metamodel. If roles collaborate, the mapping must specify at least one    . Each pair points to a concrete EReference (contained in the target metamodel), which must lead to the specified EClass. By defining multiple    s it is possible to constitute a path from one EClass to another. This enables the control of the structures in a more flexible way. Besides mapping collaborations of a role, attributes can be mapped as well. With this mapping the possibilities of annotating a metamodel with a role model are completed—all structural features can be mapped. 3.3

Executing Refactorings

Returning to the viewpoint of the refactoring designer, the next step to consider is the execution of a refactoring. To abstract the transformation from concrete languages it must refer to the corresponding role model only. For this concern an extensible metamodel—the Refactoring Specification—and a textual syntax is used by the refactoring designer. To give an example, Fig. 6 shows the refactoring specification for the role model of the ExtractX refactoring (cf. Fig. 2). This specification is given in our refactoring DSL, called RefSpec, which is explained in the following.

86

J. Reimann, M. Seifert, and U. Aßmann

Fig. 5. Metamodel of role mapping DSL

Before interpretation, the referenced roles and collaborations are resolved using the role mapping. Then, six basic steps are sufficient to execute this refactoring. First, two object definitions bind concrete objects from the input (i.e., the selected elements) to symbolic names. Subsequently, the four core commands can be found. The   operator constructs a new object playing the first given role as a child of the object playing the second given role. In the next step   is used to pass a value to the attribute which was mapped to the given role attribute. The  command then relocates the elements playing the role of the collaboration with the first given role and the second given role becomes the new parent. The   operator achieves that duplicates will be rejected. For the ExtractX example this means that for equal structural features stemming from different EClasses only one instance will be created in the new parent. Finally the  command arranges that the object playing the first given role is referenced in the mapped collaboration of the object playing the second given role. Due to space restrictions, not all commands can be explained here in greater detail. However, it is important to say that the presented refactoring specifications differ from common model transformations (e.g., Query View Transformation [17] (QVT)). One can interpret the former only within the context of a

Fig. 6. Refactoring Specification for ExtractX

Role-Based Generic Model Refactoring

87

role mapping, while the latter directly refer to concrete metamodels. This is also the reason for developing a dedicated language here instead of reusing existing ones. As discussed by Opdyke in [5], certain conditions must be met before and after refactorings. To obtain a valid refactoring, all pre-conditions must be fulfilled before and all post-conditions must hold after the refactoring. Otherwise, the refactoring must be rolled back. In our approach these conditions can also be specified on top of the role models (e.g., using the Object Constraint Language (OCL)). A modified OCL interpreter then must translate the roles and collaborations w.r.t. to a role mapping. Until now, our implementation supports metamodel-specific constraints only. The interpreter for generic constraints has not been realised yet, but we do not foresee conceptual problems to do so. In summary one can say that the interpretation of generic transformation specifications in the context of role mappings, eventually bridges the gap between generic refactorings and their actual execution. It allows to define execution steps solely based on roles and collaborations between them (i.e., independent of a metamodel), but still enables the execution of refactorings for concrete models. 3.4

Custom Refactoring Extensions

Not all transformation steps specific to a concrete metamodel can be captured in the reusable part of a refactoring. For example, recall the ExtractSuperclass refactoring and suppose we would like to obtain a quite similar refactoring— ExtractInterface. The core steps are the same, but the two refactorings differ in two details. First, after executing ExtractInterface, the values   and

  of the newly created EClass must be set to . This is just a small difference, but still it cannot be handled by the generic ExtractX refactoring as it is. To support such language-specific adjustments, we introduced Post Processors which execute additional steps after the core refactoring. They can be registered for specific metamodels in combination with a role mapping. Post processors can obtain the runtime objects to which the roles have been resolved and can then invoke further transformation steps. The post processor for ExtractInterface therefore sets   and   to . Alternatively one could create a new generic refactoring, which incorporates the setting of attributes. However, one should not do so before at least a second specific refactoring is found that requires this feature. Then, support for inheritance among role models and refactorings specifications would certainly be useful, but this is subject to future work. In Sect. 4 we present further refactorings which required custom extensions. 3.5

Preserving Semantics

Refactorings are defined as preserving the behaviour of the program, or in our case the model, that is subject to a refactoring. The behaviour of any program (or model) is defined by its static and dynamic semantics. This does immediately

88

J. Reimann, M. Seifert, and U. Aßmann

imply that preserving behaviour requires a formal specification of this semantics. Without formalisation no guarantees can be given by a refactoring tool. It does also imply that the meaning of a model is highly language-specific and can therefore not be reused. From our point of view, a framework for generic refactorings can solely provide extension points to check the preservation of semantics. DSL designers can use these points to attach custom components that add additional constraints to enforce the correctness of a refactoring. The need for formal semantics poses a problem for general purpose languages. For complex languages (e.g., Java) there is either no complete formal definition of its semantics, or if there is one, it is rarely used by the respective refactoring tools to prove correctness. However, in the context of modelling languages there is a great chance to provide refactorings that are provable correct w.r.t. the preservation of the model’s semantics. Because of their reduced complexity, modelling languages offer the chance to have complete definitions of their formal semantics. In particular for DSLs, which may have a very narrow scope, the reduced semantical complexity may allow to prove the correctness of refactorings. This does of course assume a clean specification of the semantics rather than using loose transformations to source code as often observed in practise. In summary one can say that there is chance to avoid the limitations observed for general-purpose language refactoring engines, if DSL designers are willing to specify semantics formally. Assuming they do, proofs must be established to show that a refactoring’s pre-conditions suffice to guarantee the preservation of semantics. These proofs must be constructed by DSL designers for each DSL, similar to the proofs that were needed for refactorings for programming languages in the past.

4

Evaluation

To evaluate the feasibility of our generic refactoring approach, we collected refactorings for different modelling languages and implemented them according to the procedure outlined in Sect. 3. Based on EMF, we created metamodels for role models, role mappings and transformation specifications. We defined textual syntax for all three languages using EMFText [18] to easily create model instances. For the role models an additional editor based on the Graphical Modeling Framework (GMF) [19] was generated. The interpreter for the transformation specification was implemented manually. To apply refactorings to models, we implemented editor adaptors for the EMF tree editors, GMF editors and EMFText editors and a test suite to validate the execution of refactorings automatically. The goal of this evaluation was to collect information about the number of specific refactorings that can benefit from reusing a generic refactoring. In addition, the question how many refactorings would require specific extensions to the generic refactoring should be answered. This includes both extensions to the transformation executed by the refactoring, as well as additional pre- and post-conditions. To obtain a representative result, we tried to cover as many refactorings as possible. However, this list can never be complete, which is why the results of our evaluation must always be considered w.r.t. the languages and refactorings under study.

Role-Based Generic Model Refactoring

89

We used languages of different complexity and maturity for our evaluation. The metamodels for UML, Web Ontology Language (OWL) [20], Timed Automata and Java exposed the highest number of classes and structural features. Other languages (e.g., Ecore, ConcreteSyntax, Feature Models and BPMN) have a medium complexity. Some metamodels (e.g., Pl0, Office, Conference, Text Adventure, Sandwich and Forms) were rather small and taken from the EMFText Syntax Zoo1 . We are aware that this selection of metamodels is by no means exhaustive, but we are still convinced that it supports the idea of generic refactorings. In any case, we will extend the set of languages in the future to obtain a more complete picture of the applicability of generic refactorings. The concrete results of our evaluation can be found in Table 1. The metamodels to which refactorings were applied are depicted as columns, the generic refactorings form the rows. The numbers in the cells denote how often the generic refactoring was mapped to the metamodel. The numbers in parenthesis indicate how many role mappings needed a post processor to augment the generic refactoring with additional transformation steps.

Feature Models Timed Automata Pl/0 OWL Roles Conference Office Text Adventure Sandwich Forms Simple GUI

ConcreteSyntax

Java

BPMN

UML

Ecore

Table 1. Refactorings applied to metamodels

Rename X 1 1 1 1 1 1 1 3 1 1 1 2 2 1 1 Move X 1 4 1 Introduce Reference Class 1 2 1 Extract X 5(2) 2 Extract X with Reference Class 1(1) 1(1) 1(1) 1(1) 1 1 1 1 1 Extract Sub X 1 1

In total, we applied 6 generic refactorings to 16 metamodels by creating 47 mappings. The refactorings that were reused most often are RenameX and ExtractXwithReferenceClass. The latter is an extended version of ExtractX. Due to space restrictions, we cannot list the names of all the specific refactorings here. The complete list can be found on the web2 . In Sect. 2 we have identified two types of limitations of previous works. The first limitation—no reuse of refactorings across languages—applies to approaches that define refactorings on meta level M2. When looking at Table 1, one can see that each generic refactoring was applied to at least two metamodels. Some of them were even applicable to the majority of the languages under study. 1 2

       

90

J. Reimann, M. Seifert, and U. Aßmann

The second limitation—having a single fixed mapping for each metamodel— was observed for the approaches residing on M3. All cells from Table 1 that contain a value higher than 1 indicate cases where our approach is superior to existing approaches. Here, the same generic refactoring was mapped multiple times to a metamodel to obtain different specific refactorings. Even w.r.t. to the limited number of languages and refactorings that were evaluated, we think that the results support our approach. First, we were able to instantiate many specific refactorings from few generic ones, which shows that reusing refactorings specifications is beneficial. Second, the low amount of customisation that was needed (6 out of 47 refactorings), indicates that most refactorings can be instantiated without additional effort, besides specifying a role mapping.

5

Conclusion and Future Work

In this paper the limitations of existing work on generic refactorings have been identified and a novel approach to overcome them was presented. Based on role models, structural requirements for refactorings can be generically formalised. Using a mapping specification, such role models can be bound to specific modelling languages. This mapping defines which elements of a language play which role in the context of a refactoring. Based on the mapping, generic transformation specifications are executed to restructure models. Thus, generic refactorings can be reused for different languages only by providing a mapping. The transformation and generic pre- and post-conditions are reused. Furthermore, the same generic refactoring can be repeatedly applied to one language. We have discussed the extent to which generic refactorings can be reused and the preservation of semantics. Even though the latter is highly languagespecific, a generic refactoring framework can still provide extension points to be parameterised by a language’s semantics. An evaluation using an EMF-based implementation has shown that many generic refactorings can be reused. For the custom extensions that were needed in some cases, we observed that these were rather small and that they could be applied in a monotonic fashion (i.e., without making invasive changes to the generic refactorings). We do not claim that all refactorings should be realised as instantiations of generic ones. There will always be refactorings that are highly language-specific and which may therefore not benefit from reusing a generic refactoring. But, we believe that our evaluation has shown that reusing refactorings can be beneficial in many cases. We identified multiple open issues for future research. First, models are connected over multiple levels of abstraction. If the relations between those levels are known, refactorings should change dependent models to preserve the overall semantics of such a model stack. A similar connection exists between models on different meta levels. Thus, the evolution of metamodels can also be considered as refactorings. Here, the references of all instances of the metamodels must be changed in order to preserve the instance-of relation if a metamodel is changed. Second, the refactorings presented in this paper were mapped manually to the target languages. As the role models exactly define the structure required to

Role-Based Generic Model Refactoring

91

instantiate a generic refactoring, searching for refactoring candidates is an interesting task for further investigations. If such a search is possible, DSL designers could simply ask for all applicable refactorings for a given metamodel and select the ones they find suitable for their language. Third, the presented evaluation is only meaningful w.r.t. the languages and refactorings under study. To draw conclusions on a more broad basis, we currently perform a survey to collect more refactorings. The outcome of this survey will hopefully be an even bigger set of refactorings and modelling languages, which allows to justify the feasibility of our approach more accurately.

Acknowledgement This research has been co-funded by the European Commission within the FP6 project Modelplex #034081 and the FP7 project MOST #216691.

References 1. L¨ ammel, R.: Towards Generic Refactoring. In: Proc. of Third ACM SIGPLAN Workshop on Rule-Based Programming RULE 2002, Pittsburgh, USA. ACM Press, New York (October 2002) 2. Moha, N., Mah´e, V., Barais, O., J´ez´equel, J.-M.: Generic Model Refactorings. In: Sch¨ urr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 628–643. Springer, Heidelberg (2009) 3. Steinberg, D., Budinsky, F., Paternostro, M., Merks, E.: Eclipse Modeling Framework, 2nd edn. Pearson Education, London (2008) 4. Lehman, M.M.: On understanding laws, evolution, and conservation in the largeprogram life cycle. Journal of Systems and Software 1, 213–221 (1980) 5. Opdyke, W.F.: Refactoring Object-Oriented Frameworks. PhD thesis, University of Illinois at Urbana-Champaign (1992) 6. Fowler, M.: Refactoring: Improving the Design of Existing Code. Addison-Wesley Longman, Amsterdam (1999) 7. Kurtev, I., B´ezivin, J., Aksit, M.: Technological Spaces: An Initial Appraisal. In: International Symposium on Distributed Objects and Applications, DOA Federated Conferences, Industrial track, Irvine (2002) 8. Mens, T., Taentzer, G., M¨ uller, D.: Challenges in Model Refactoring. In: Proc. 1st Workshop on Refactoring Tools. University of Berlin (2007) 9. The Object Management Group: OMG Unified Modeling Language (OMG UML), Superstructure, Version 2.2. Technical report (February 2009) 10. The Object Management Group: Meta Object Facility (MOF) Core Specification. Technical report (January 2006) 11. Zhang, J., Lin, Y., Gray, J.: Generic and Domain-Specific Model Refactoring using a Model Transformation Engine. In: Beydeda, S., Book, M., Gruhn, V. (eds.) Research and Practice in Softw. Eng., vol. II, pp. 199–218. Springer, Heidelberg (2005) 12. Taentzer, G., M¨ uller, D., Mens, T.: Specifying Domain-Specific Refactorings for AndroMDA Based on Graph Transformation. In: Sch¨ urr, A., Nagl, M., Z¨ undorf, A. (eds.) AGTIVE 2007. LNCS, vol. 5088, pp. 104–119. Springer, Heidelberg (2008)

92

J. Reimann, M. Seifert, and U. Aßmann

13. Biermann, E., Ehrig, K., K¨ ohler, C., Kuhns, G., Taentzer, G., Weiss, E.: Graphical Definition of In-Place Transformations in the Eclipse Modeling Framework. In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 425–439. Springer, Heidelberg (2006) 14. Brosch, P., Seidl, M., Wieland, K., Wimmer, M., Langer, P.: The Operation Recorder: Specifying Model Refactorings By-Example. In: Arora, S., Leavens, G.T. (eds.) OOPSLA Companion, pp. 791–792. ACM, New York (2009) 15. Brosch, P., Langer, P., Seidl, M., Wieland, K., Wimmer, M., Kappel, G., Retschitzegger, W., Schwinger, W.: An Example Is Worth a Thousand Words: Composite Operation Modeling By-Example. In: Sch¨ urr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 271–285. Springer, Heidelberg (2009) 16. Riehle, D., Gross, T.: Role Model Based Framework Design and Integration. In: Proc. of OOPSLA 1998, pp. 117–133. ACM, New York (1998) 17. The Object Management Group: Meta Object Facility (MOF) 2.0 Query/View/Transformation. Specification Version 1.0 (April 2008) 18. Heidenreich, F., Johannes, J., Karol, S., Seifert, M., Wende, C.: Derivation and Refinement of Textual Syntax for Models. In: Paige, R.F., Hartman, A., Rensink, A. (eds.) ECMDA-FA 2009. LNCS, vol. 5562, pp. 114–129. Springer, Heidelberg (2009) 19. Gronback, R.C.: Eclipse Modeling Project: A Domain-Specific Language (DSL) Toolkit. Pearson Education, London (April 2009) 20. W3C: OWL 2 Web Ontology Language: Structural Specification and FunctionalStyle Syntax. Technical Report (October 2009)

Precise Detection of Conflicting Change Operations Using Process Model Terms Christian Gerth1 2 , Jochen M. K¨uster2 , Markus Luckey1 , and Gregor Engels1 

1

Department of Computer Science, University of Paderborn, Germany     2 IBM Research - Zurich, S¨aumerstr. 4 8803 R¨uschlikon, Switzerland    

Abstract. Version management of process models requires that changes can be resolved by applying change operations. Conflict detection is an important part of version management and the minimization of the number of detected conflicts also reduces the overhead when resolving changes. As not every syntactic conflict leads to a conflict when taking into account model semantics, a computation of conflicts solely on the syntax leads to an unnecessary high number of conflicts. In this paper, we introduce the notion of syntactic and semantic conflicts for change operations of process models. We provide a method how to eÆciently compute conflicts, using a term formalization of process models. Using this approach, we can significantly reduce the number of overall conflicts and thereby reduce the amount of work for the user when resolving conflicts.

1 Introduction Although model-based development (MBD) is accepted as a well-established development approach, there are still some shortcomings that let developers decide against MBD and for more traditional development paradigms. These shortcomings comprise a lack of fully integrated and fully featured development environments for MBD, for instance a comprehensive model version management. In this paper, we consider version management of business process models exemplarily for modeling languages that have non-trivial semantics. In our recent work [13,6], we have investigated di erent problems in version management of business process models, including the detection of conflicts between change operations, which is a crucial technique for the consolidation of di erent model versions. The detection of conflicts can be performed syntactically by analyzing the structure of the models andor by comparing change operations, e.g., using a conflict matrix [17]. However, conflict detection that is solely based on syntactical features potentially results in false-positive conflicts, that is two changes are detected as being conflicting, although both changes are semantically equivalent or overlap to a large degree. In this paper, we introduce a notion of syntactic and semantic conflicts between change operations and show how conflicts can be computed taking into account the C. Gerth is funded by the International Graduate School of Dynamic Intelligent Systems at the University of Paderborn. D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 93–107, 2010. c Springer-Verlag Berlin Heidelberg 2010

­

94

C. Gerth et al.

semantics of the modeling language. Our approach can also provide a hint on limitations of generic approaches to conflict detection, which do not consider semantics of specific modeling languages. By reducing the overhead for a user in merging di erent versions of a process model, we take a further step towards a versioning system for process models with the convenience and usability known from versioning systems for textual documents. The remainder is structured as follows: In Section 2 we introduce a typical merge scenario in distributed business process modeling. We show the shortcomings of existing approaches to conflict detection. In Section 3, we consider the basic foundations for our approach to conflict detection. In Section 4, we define syntactic and semantic conflicts of change operations. We present a novel method to compute precise conflicts in Section 5 and show that the amount of work for a user when resolving di erences can be significantly reduced. In Section 6 we discuss related work, and we conclude and give an outlook on future work.

2 Motivation In this section, we first provide a scenario for version management of business process models in distributed environments and we show why conflict detection needs to take semantics into account. Figure 1 shows three process models in the Business Process Modeling Notation (BPMN) [21], representing a typical multi-user scenario. The process models describe the necessary steps to open a banking account for a customer in a bank. The source model V in the middle of Figure 1 was created first and afterwards V was individually refined by di erent users into the versions V1 and V2 . fP1-V1 ParallelFork

Record Customer Data

V1

Check Customer Data

Compute Customer Scoring

Open Account

Source Model

Start

Activity Record Customer Data

ExclusiveDecision fC

< 3.5

Compute Customer Scoring

Prepare Prepaid Bank Card

Prepare Credit Card

Prepare Bank Card

≥ 3.5

fD

V2

Record Customer Data

x

Retrieve add. Data

X

Sign Contract

Remove Credit Card

Set Interest Rate to 0

End

Prepare Prepaid Bank Card

fP1-V2

Prepare < 3.5 Bank Card

x

Prepare Credit Card

+

X

Editing Operations Δ(V,V2) Check Customer Data

Set Credit Limit to 0

ParallelJoin

+

ExclusiveMerge

X fB

Select Credit Card Corporation Print Credit Card Contract

X ≥ 3.5

fA

+

+

Prepare < 3.5 Bank Card

Editing Operations Δ(V,V1)

V

Calculate Interest Rate

Compute Customer Scoring

X ≥ 3.5

+

Print Credit Card Contract Select Credit Card Corporation Ask for Credit Limit

Prepare Prepaid Bank Card

Set Credit Limit to 0

+ +

Remove Credit Card

Prepare Credit Card

Calculate Interest Rate Set Interest Rate to 0

Fig. 1. Dierent Versions of a Business Process Model

X

Open Account

Precise Detection of Conflicting Change Operations Using Process Model Terms

95

An overview of our scenario is given in Figure 2. Distributed process modeling is a classical 3-way merge Δ(V,V1) Δ(V,V2) scenario known from versioning systems for textual documents. At some point in time, a consolidated version V1 V2 VC is needed that integrates the changes applied to the VC di erent versions V1 and V2 . For that purpose, we have to consider the changes between the source process Fig. 2. Scenario Overview model V and the two versions V1 and V2 . VC is then created by applying a subset of the changes that were applied to achieve V1 and V2 . We assume that these changes are given in terms of change operations and are stored in change logs (V V1 ) and (V V2). The change logs are either created during the modeling of the version V1 and V2 or they are computed afterwards1 . Change operations include InsertAction, DeleteAction, and MoveAction operations to modify actions in process models. Analogously, the change operations InsertFragment, DeleteFragment, and MoveFragment are used to deal with entire fragments in process models [14]. Figure 3 shows the change logs with change operations representing the di erences between the process models V and V1 as well as V and V2 in our example presented in Figure 1. The first parameter of a change operation specifies the modified model element. The other parameters determine the position (i.e., the actual predecessor and successor) to which an element is inserted or moved to. In the remainder we refer to these parameters as position parameters. Whenever changes are applied individually on di erent versions of a process model, some changes might be conflicting. Informally, two change operations op1 (V V1) and op2 (V V2) are conflicting if the application of op1 on the consolidated version VC turns operation op2 inapplicable. Conflicts between change operations have to be detected before a consolidated version can be created. Existing approaches to conflict detection use e.g. conflict sets [2] or conflict matrices [17,12], which specify conditions under which two change operations are conflicting. For that purpose, change operations are analyzed by comparing the model elements which are modified by the operations and their position parameters to identify conflicting pairs of operations. Applying such an approach on our example (Figure 1) results in the conflicts between change operations indicated by arrows in Figure 3. The curled brackets are added for readability reasons and indicate that every operation within the bracket is in conflict. Overall 18 conflicts are detected, among them several conflicts between equivalent change operations. Two operations are equivalent if their applications have identical e ects on the process model. For instance, the operations that inserted the actions ”Set Credit Limit to 0” are inserted in process model V1 as well as in V2 at the same position. Thus, their e ects on the process model are equivalent and shall not give rise to a conflict. We refer to conflicts between equivalent operations as false-positive conflicts in the remainder. Approaches to conflict detection based on syntactic features result potentially in false-positive conflicts because they cannot identify equivalent change operations in

V

1

In our recent work [14] we have shown how change operations can be computed in the absence of a change log.

96

C. Gerth et al.

a) b) c) d) e) f) g) h) i) j) k)

Δ(V, V1): InsertAction(“Check Cust. Data”, “Record Cust. Data”, “Compute Cust. Scoring”) InsertAction(“Open Account”, “Check Cust. Data”, “Compute Cust. Scoring”) InsertParallelFragment(FP1-V1, “Prepare Bank Card”, “Prepare Credit Card”) InsertAction(“Print Credit Card Contract”, “ForkP1-V1”, “JoinP1-V1”) InsertAction(“Sign Contract”, “Print Credit Card Contract”, “JoinP1-V1”) InsertParallelFragment(FP2-V1, “ForkP1-V1”, “Calc. Interest Rate”) InsertAction(“Calc. Interest Rate”, “ForkP2-V1”, “JoinP2-V1”) InsertAction(“Select Credit Card Corp.”, “ForkP2-V1”, “JoinP2-V1”) InsertAction(“Set Credit Limit to 0”, “Prepare Prep. Bank Card”, “MergeA-V1”) InsertAction(“Remove Credit Card”, “Set Credit Limit to 0”, “MergeA-V1”) InsertAction(“Set Interest Rate to 0”, “Remove Credit Card”, “MergeA-V1”)

# of Conflicts: 18

Δ(V, V2): m) InsertAlt.Fragment(FA2-V2, “Record Cust. Data”, “Compute Cust. Scoring”) n) InsertAction(“Check Cust. Data”, “MergeA2-V2”, “DecisionA2-V2”) o) InsertAction(“Retrieve add. Data”, “DecisionA2-V2”, “MergeA2-V2”) p) InsertParallelFragment(FP1-V2, “Prepare Bank Card”, “Prepare Credit Card”) q) InsertAction(“Print Credit Card Contract”, “ForkP1-V2”, “JoinP1-2-V2”) r) InsertAction(“Calc. Interest Rate”, “JoinP1-1-V2”, “JoinP1-2-V2”) s) InsertAction(“Ask for Credit Limit”, “ForkP1-V2”, “JoinP1-1-V2”) t) InsertAction(“Select Credit Card Corp.”, “ForkP1-V2”, “JoinP1-1-V2”) u) InsertAction(“Open Account”, “MergeA-V2”, “End”) v) InsertAction(“Set Interest Rate to 0”, “Prepare Prep. Bank Card”, “MergeA-V2”) w) InsertAction(“Remove Credit Card”, “Prepare Prep. Bank Card”, “Set Interest Rate to 0”) x) InsertAction(“Set Credit Limit to 0”, “Prepare Prep. Bank Card”, “Remove Credit Card”)

Fig. 3. Change Logs (V V1 ) and (V V2 ) of our Example in Figure 1 with Conflicts

every case. For instance, a syntactic comparison of the change operations i and y that insert the actions ”Set Credit Limit to 0” results in a conflict, since the position parameters of the operations di er and it seems that the actions are inserted at di erent positions in V1 and V2 . The identification of equivalent operations is even more diÆcult in cases where elements are modified in structures that are syntactically di erent but semantically equivalent, which is often the case. To give an example, a syntactic conflict detection between change operations in the highlighted structures fP1 V1 and fP1 V2 in Figure 1 results in several false-positive conflicts (see operations d-h and q-t in Figure 3). For these operations that modify elements in this structures in V1 and V2 , it is not straight-forward to decide whether they are equivalent. A syntactic comparison of the change operations or the structures results in false-positive conflicts. However, considering the behavior of the structures in terms of their execution traces reveals that the structures are equivalent to a large degree and should not give rise to conflicts between all change operations within the structures. To prevent false-positive conflicts, the semantics of process models must be taken into account. In this paper, we address this problem and propose a method for precise conflict detection. Next, we introduce basic foundations.

3 Foundations In this section, we consider the basic foundations of our approach. We start with an introduction of process structure trees. Then, we briefly describe process model terms. 3.1 Process Structure Tree For the following discussions, we assume a business process model M to be expressed using the basic workflow graphs described in [25,26] and define the semantics of

Precise Detection of Conflicting Change Operations Using Process Model Terms

97

process models similar to the semantics of Petri nets [19] in terms of token flows. In our recent work [6], we have shown how concrete BPMN models can be abstracted to such process models and described the behavior of particular process model nodes in detail. To enable a comparison of individual parts of process models, they are decomposed into single-entry-singlefA exit fragments [26] (e.g., fA  fB   in process model V End in Figure 1). Such a fragment is a non-empty subgraph Start Record Compute Cust. Cust. in the process model with a single entry and a single Data Scoring fB exit edge. A fragment can either be an alternative fragXORXORfC fD Merge Decsion ment consisting of an Exclusive Decision and an Exclusive Merge node, a concurrent fragment consisting of a Prepare Prepare Prepare Bank Prepaid Credit Parallel Fork and a Parallel Join node or further types of Card Card Bank Card fragments including unstructured or complex fragments, which allow us to express all combinations of gateways. Fig. 4. Process Structure Tree For more details about fragment types the reader is re- of Process Model V ferred to [26]. Based on the decomposition into fragments we are able to compare individual pairs of fragments instead of relying on the complete process model. In addition, the PST specifies semantic information of the underlying process model e.g., the type of a fragment (parallel, alternative, complex, ...). Figure 4 shows the process structure tree (PST) [26] of the source process model V (Figure 1). The PST represents the fragments hierarchy. The fragments fA , fC , and fD are sequential fragments, and fB is an alternative fragment. 3.2 Process Models Terms Process model terms (PMT) [7] are a formalization of the process structure tree and are used to identify equivalences between di erent fragments, while taking their semantics into account. In contrast to process structure trees, PMTs specify the execution order of elements located in fragments and can be compared eÆciently. We use PMTs later to identify semantical conflicts within syntactical di erent fragments. Figure 5 summarizes the translation of PST elements to their corresponding term representation. ControlNodes are not added to process model terms, since they are already represented by their surrounding fragments. The transformation of process models into terms is straight-forward by traversing its PST using the infix approach. We define  to

PST Element InitialNode, FinalNode, Action n Sequence s Parallel Fragment p Alternative Fragment a Alternative Loop Fragment l Complex Fragment c

Term n s() p() a() l() c()

Fig. 5. Transformation of PST into Term

tP1-V2 = p(s1(‘Print Credit …’), s2(‘Select Credit …’), s3(‘Ask for Credit …’), s4(‘Calc. Interest Rate’)) OP1-V2 = {s2 < s4, s3 < s4} Fig. 6. Process Model Term t f P1

V2

98

C. Gerth et al.

be the partial order set over the set of sequences representing branches within a fragment. A PMT consists of a term and a partial order relation , which specifies the execution order of branches within fragments. The highlighted fragment fP1 V2 in process model V2 of our example (Figure 1) results in the PMT tP1 V2 shown in Figure 6. The sequences s2 and s3 are executed before sequence s4 , resulting in the partial order P1 V2   s2  s4  s3  s4 . Since s1 is executed in parallel to the other sequences, it is not in added to the partial order . In addition, we do not explicitly specify the execution order of elements within sequences, since it is given implicitly. The partial order within a fragment can be obtained easily by traversing all branches of each fragment using the depth first approach. Process model terms can be syntactically compared eÆciently. However, to compare the semantic equivalence of syntactically di erent models, their corresponding terms have to be transformed into a normal form to be considered equivalent, since syntactically di erent models result in di erent terms regardless of their semantic meaning. For that purpose, we have developed a term rewriting system [7] that transforms syntactically di erent process models with the same semantics into a unique normal form. The term rewriting system consists of 16 rules for the transformation of sequences, alternative, and parallel fragments of process models. The fragments can be structured or unstructured. For more details about the term rewriting system the reader is referred to [7].

4 Syntactic and Semantic Conflicts of Change Operations In this section, we introduce a notion of conflicts between change operations. For the following discussion, we assume that changes between a source process model V and independently modified versions V1 and V2 are given in terms of compound change operations in the change logs (V V1) and (V V2). Matchings between the versions and the source process model are given in terms of correspondences Corr(V V1 ) and Corr(V V2) that relate elements with the same functionality in the models. The set Corr(V1  V2 ) contains correspondences between elements with the same functionality that were newly inserted into the versions V1 and V2 . Corr(V1  V2 ) can be obtained by matching elements with same or similar name, e.g., by measuring the Levenshtein distance [16] between element names or using an ontology-based matching. Conflicts between change operations can be classified into syntactical or semantical conflicts. Informally, two changes are syntactically in conflict if the application of one change turns the other one inapplicable. Formally, we define syntactical conflicts of change operations by expressing them as model transformations [13], where an operaop tion op is applied on a model V leading to a model V ¼ (V  V ¼ ). Definition 1 (Syntactically Conflicting Change Operations). Let two change operaop1 op2 tions op1 (V V1) and op2 (V V2) be given such that V  V ¼ and V  V ¼¼ . We call op1 and op2 syntactically conflicting if op2 is not applicable on V ¼ or op1 is not applicable on V ¼¼ . In our example the change operations a) and m) (Figure 3) are syntactically conflicting. Both operations insert di erent elements at the same position in the process models.

Precise Detection of Conflicting Change Operations Using Process Model Terms

99

For the consolidation, only one of the operations can be applied on the source process model V. In the case of semantic conflicts, we first have to define when two process models are considered to be behavioral equivalent. For the following discussion we use trace equivalence [24] as equivalence relation that has been defined for process models in [10,22]. We consider two process models V1 and V2 to be trace equivalent (V1 trace V2 ) if their sets of traces are equal. Informally, two change operations modifying corresponding elements are semantically in conflict if the corresponding elements are executed at di erent positions, resulting in di erent execution traces. We define semantically conflicting operations as follows: Definition 2 (Semantically Conflicting Change Operations). Let two change oper(V V1) and op2 (V V2 ) be given that modify the elements (action ations op1 or fragments) x1 and x2 . Further, let x1 correspond to x2 , i.e. (x1  x2 ) Corr(V1  V2 ). op1 op2 Then we call op1 and op2 semantically conflicting if V  V ¼ , V  V ¼¼ , and not V ¼ trace V ¼¼ . An example for Definition 2 is represented by the operations b) and u) that insert the actions ”Open Account” in di erent positions in the process models V1 and V2 in Figure 1. Syntactical conflicts can be computed using existing theory, e.g., by using conflict matrices, with the described shortcomings (Section 2). A naive solution to identify semantically conflicting change operations would be to directly apply Definition 2. That would require that all changes need to be applied individually on V (with respect to dependencies between the changes) and their traces need to be computed to verify their trace equivalence. This approach su ers from several drawbacks: First of all, the application of the individual operations represents a significant overhead, since it requires in the worst case the application of all subsets of change operations, which is not always possible. Second, for the evaluation of trace equivalence all possible execution traces need to be computed that may result in exponential complexity. An approach to compute syntactical and semantical conflicts that overcomes these shortcomings is introduced in the following.

5 Computation of Conflicting Change Operations In this section, we present a novel method to compute conflicts between given change operations. It avoids false-positive conflicts by taking into account semantic equivalence of business process models. In the following, we classify change operations into independent and dependent operations, since the approaches of conflict detection di er for both categories. In [13], we have shown how dependencies of change operations can be computed eÆciently. For example, a change operation is dependent if it inserts or moves an element into a fragment, that was newly inserted itself. Based on this classification, our approach consists of two main steps (Figure 7 and 11): In the first step, we compute conflicts between independent change operations (Section 5.1) and in the second step we determine

100

C. Gerth et al.

conflicts between dependent operations (Section 5.2). In the following we explain the individual steps in detail. 5.1 Conflict Detection of Independent Change Operations In the first step, we compute conStep 1 Conflict Detection of Independent Change Operations flicts between independent change 1 Specify position parameters of change operations using fixpoints operations by comparing the change 1a Compute conflicts of operations modifying corresponding operations syntactically using conmodel elements using a conflict matrix and fixpoints Æ If no conflict: increase set of fixpoints and recompute flict matrices. However, in contrast position parameter to existing approaches we com1b Compute conflicts of operations modifying non-corresponding model elements using a conflict matrix and fixpoints pare the operations in a specific order and use dynamic computa- Fig. 7. Conflict Detection of Independent Operations tion of position parameters to determine the position of modified model elements uniquely. Thereby, equivalent independent operations are identified. First, position parameters for all independent change operations are specified using only corresponding model elements that are not modified by a change operation in the process models V1 and V2 (Step 1). We refer to these elements as fixpoints in the remainder. For instance, the actions ”Record Customer Data” in the models V1 and V2 constitute fixpoints, since they correspond to each other and are not modified. An algorithm to compute position parameters using fixpoints is presented in [13]. In Step 1a, we iterate over the independent change operations whose position parameters were specified using fixpoints in the change logs and syntactically compare (V V1) and op2 (V V2) that modify correspondpairs of change operations op1 ing model elements using a conflict matrix. Figure 8 shows an excerpt of our conflict matrix for change operations that specifies condition in which change operations are conflicting. In the case, that operations are not in conflict, the underlying corresponding model elements will be at the same position after the execution of the operations, resulting to equal traces. The corresponding model elements modified by op1 and op2 are added to the set of fixpoints. Before the next comparison of change operations, position parameters of the remaining change operations are recomputed to consider the increased set of fixpoints. In the case, that the operations are in conflict according to the conflict matrix, op1 and op2 are marked as conflict, since their application results in corresponding model elements at di erent positions. Figure 9 provides an example using the operations i,j,k and v,w,x from our example. In (a), the position parameters of the change operations are initially specified using

Conflict Matrix

InsertAction (X2,C,D)

MoveAction (X2,oP,oS,nP,nS)

DeleteAction (X2,C,D)

InsertFragment (F2,C,D)

MoveFragment (F2,oP,oS,nP,nS)

DeleteFragment (F2,C,D)

InsertAction (X1,A,B)

(X1 = X2 & C ≠ A & D ≠ B)

(nP = A & nS = B)

(nP = A & nS = B)

parent(X1) = F2

X1 inserted and X2 moved to same position

no conflict using fixpoints

(C = A & D = B)

same element inserted at different positions

X1 and F2 inserted at same position

X1 inserted and F2 moved to same position

X1 inserted into deleted fragment F2

(X1 ≠ X2 & C = A & D = B) different element inserted at same position

Fig. 8. Excerpt of our Conflict Matrix for the Comparison of Change Operations specified with Fixpoints

Precise Detection of Conflicting Change Operations Using Process Model Terms a) Δ(V, V1): … i) InsertAction(“Set Credit …”, “Prepare Prepaid …”, “MergeAV2”) j) InsertAction(“Remove …”, “Prepare Prepaid …”, “MergeAV2”) k) InsertAction(“Set Interest …”, “Prepare Prepaid …”, “MergeAV2”)

b)

… i) InsertAction(“Set Credit …”, “Prepare Prepaid …”, “MergeAV2”) j) InsertAction(“Remove …”, “Set Credit …”, “MergeAV2”) k) InsertAction(“Set Interest …”, “Set Credit …”, “MergeAV2”)

101

Δ(V, V2): … v) InsertAction(“Set Interest …”, “Prepare Prepaid …”, “MergeAV2”) w) InsertAction(“Remove …”, “Prepare Prepaid …”, “MergeAV2”) x) InsertAction(“Set Credit …”, “Prepare Prepaid …”, “MergeAV2”) … v) InsertAction(“Set Interest …”, “Set Credit …”, “MergeAV2”) w) InsertAction(“Remove …”, “Set Credit …”, “MergeAV2”) x) InsertAction(“Set Credit …”, “Prepare Prepaid …”, “MergeAV2”)

c) … i) InsertAction(“Set Credit …”, “Prepare Prepaid …”, “MergeAV2”) j) InsertAction(“Remove …”, “Set Credit …”, “MergeAV2”) k) InsertAction(“Set Interest …”, “Remove …”, “MergeAV2”)

… v) InsertAction(“Set Interest …”, “Remove …”, “MergeAV2”) w) InsertAction(“Remove …”, “Set Credit …”, “MergeAV2”) x) InsertAction(“Set Credit …”, “Prepare Prepaid …”, “MergeAV2”)

Fig. 9. Conflict Computation between Change Operations modifying corresponding Model Elements

fixpoints. We start the comparison with the operations i and x. Since they are not conflicting, their underlying model elements ”Set Credit Limit to 0” are added to the set of fixpoints and the position parameters are recomputed, reflecting the new fixpoint. Next in (b), the operations j and w are compared, with the result that ”Remove Credit Card” is added to the set of fixpoints entailing again a re-computation of the position parameter of the remaining operations. Finally in (c), the remaining operations k and v are compared and the actions ”Set Interest Rate to 0” are added to the set of fixpoints. Note, that compared to our previous approach from [13] by specifying position parameters of the operations i,j,k and v,w,x in terms of fixpoints and a dynamic computation of change operation parameters, no false-positive conflicts are detected between the equivalent operations. After Step 1a, all conflicts between independent change operations modifying corresponding model elements have been computed. In Step 1b, we compare the remaining independent change operations that modify non-corresponding model elements. According to the conflict matrix, a syntactic Δ(V, V1): a) InsertAction(“Check Cust. Data”, “Record Cust. Data”, “Compute Cust. Scoring”) b) InsertAction(“Open Account”, “Check Cust. Data”, “Compute Cust. Scoring”) c) InsertParallelFragment(FP1-V1, “Prepare Bank Card”, “Prepare Credit Card”) d) InsertAction(“Print Credit Card Contract”, -, -) e) InsertAction(“Sign Contract”, -, -) f) InsertParallelFragment(FP2-V1, -, -) g) InsertAction(“Calc. Interest Rate”, -, -) h) InsertAction(“Select Credit Card Corp.”, -, -) i) InsertAction(“Set Credit Limit to 0”, “Prepare Prep. Bank Card”, “MergeA-V1”) j) InsertAction(“Remove Credit Card”, “Set Credit Limit to 0”, “MergeA-V1”) k) InsertAction(“Set Interest Rate to 0”, “Remove Credit Card”, “MergeA-V1”)

# of Conflicts: 4 (after Step 1)

Δ(V, V2): m) InsertAlt.Fragment(FA2-V2, “Record Cust. Data”, “Compute Cust. Scoring”) n) InsertAction(“Check Cust. Data”, “MergeA2-V2”, “DecisionA2-V2”) o) InsertAction(“Retrieve add. Data”, “DecisionA2-V2”, “MergeA2-V2”) p) InsertParallelFragment(FP1-V2, “Prepare Bank Card”, “Prepare Credit Card”) q) InsertAction(“Print Credit Card Contract”, -, -) r) InsertAction(“Calc. Interest Rate”, -, -) s) InsertAction(“Ask for Credit Limit”, -, -) t) InsertAction(“Select Credit Card Corp.”, -, -) u) InsertAction(“Open Account”, “MergeA-V2”, “End”) v) InsertAction(“Set Interest Rate to 0”, “Prepare Prep. Bank Card”, “MergeA-V2”) w) InsertAction(“Remove Credit Card”, “Prepare Prep. Bank Card”, “Set Interest Rate to 0”) x) InsertAction(“Set Credit Limit to 0”, “Prepare Prep. Bank Card”, “Remove Credit Card”)

Fig. 10. Computed Conflicts after Step 1

102

C. Gerth et al.

conflict between these operations is detected if non-corresponding elements are located at the same position after the application of the operations. An example for such a conflict is the conflict between the operations a and m in Figure 10, which insert the action ”Check Customer Data” and the fragment F A1 V1 at the same position. Figure 10 shows the conflicts between the change operations in (V V1) and (V V2) that have been computed after Step 1. Conflicts of the highlighted operations have been computed in this step and are indicated by dotted arrows. In the following, we compute conflicts of the remaining dependent operations (d-h and q-t) within the fragments fP1 V1 and fP1 V2 . Since these change operations contain dependencies to each other, the conflict detection approach di ers from the one described above. 5.2 Conflict Detection of Dependent Change Operations Conflicts between dependent change Step 2 Conflict Detection of Dependent Change Operations operations cannot be computed 2a Compute conflicts of operations modifying corresponding based on a comparison of change model elements within fragments using Process Model Terms operations and their position pa2b Compute conflicts of operations modifying non-corresponding model elements using a conflict matrix and fixpoints rameters, due to the following Æ If position parameters cannot be specified using fixpoints: assign conflict to the operations. reasons: First, position parameters within fragments are diÆcult to compare because syntactically Fig. 11. Conflict Detection of Dependent Operations di erent fragments may have the same behavior in terms of their execution traces. Further, beside the actual position of an element within a fragment, also the execution order and logic of the fragment must be considered. To give an example, in the top of Figure 12 the highlighted fragments of our example (Figure 1) are shown. These fragments are syntactically di erent although they are semantically equivalent to a large degree comparing their behavior in terms of execution traces. Existing approaches to conflict detection that compare change operations based on a conflict matrix would mark all the dependent operations contained in modified fragments as conflicting regardless whether they are equivalent or not, resulting in falsepositive conflicts. In the case of the fragments fP1 V1 and fP1 V2 , most of the conflicts constitute false-positive conflicts. To avoid these false-positive conflicts, we check whether the corresponding elements within the two fragments lead to equivalent traces. For that purpose, in Step 2a, we iterate over corresponding fragments that are modified by a change operation. For each pair of these fragments we then leverage process model terms to identify conflicts of dependent change operations contained in the fragments. Process model terms enable us to compare two fragments for semantic equivalence (see Section 3.2) by detecting di erences in the terms. In the following, we first define di erences of process model terms, which we then use to identify conflicting change operations. Definition 3 (Term Di«erence). Let f1 V1 and f2 V2 be two corresponding fragments together with a mapping Corr(V1  V2 ) of V1 and V2 . Let further the normalized process model terms tCorr  f 1 , tCorr  f 2 of the fragments be given that are reduced to their corresponding elements (e1  e2 ) Corr(V1  V2 ). We define a term di«erence as a di«erence of the two terms tCorr  f 1 , tCorr  f 2 or a di«erence of their partial orders.

Precise Detection of Conflicting Change Operations Using Process Model Terms

103

Given a term di erence, we now define the operations that yield the term di erence as term-conflicting operations. Figure 12 shows the fragments fP1 V1 and fP1 V2 of our example. We first reduce the fragments to their corresponding model elements (by removing the actions ”Sign Contract” and ”Ask for Credit Limit”) and transform them into their process model terms. These terms are normalized using our term rewriting system introduced in [7]. The normal forms of the terms together with their graphical representation are shown in the bottom of Figure 12. Finally, we compare the normalized terms under consideration of commutativity in order to identify term di erences. Since the terms are not equal, a term di erence is obtained: The sequence s(Calc) in the normal form NF(tP1 V1 ) cannot be mapped to a sequence in NF(tP1 V2 ). In other words, in our example, the actions ”Calculate Interest Rate” and ”Select Credit Card Operation” are executed in parallel in fP1 V1 , however they are executed sequentially in fP1 V2 . Thus, the operations g and r that insert the actions ”Calculate Interest Rate” are term-conflicting.

fP1-V1

+ +

Calculate Interest Rate

fP1-V2

Select Credit Card Corporation Print Credit Card Contract

+

?

+

≈

+

Sign Contract

Print Credit Card Contract Select Credit Card Corporation

+ +

Ask for Credit Limit

Calculate Interest Rate

1. Transformation into Process Model Terms tCorr-fP1-V2 = p [s(Print), s(Select), s( ), s(Calc)] OCorr-fP1-V2 = {s(Select) < s(Calc), s( ) < s(Calc) }

tCorr-fP1-V1 = p [s(p [s(Calc), s(Select)]), s(Print)] OCorr-fP1-V1 = { }

2. Reduction into Normal Form NF(tCorr-fP1-V1) = p [s (Calc), s (Select), s(Print)] OCorr-fP1-V1 = { } NF(fP1-V1)

+

C

NF(tCorr-fP1-V2) = p [s(Print), s(Select, Calc)] OCorr-fP1-V2 = { } NF(fP1-V2)

Calculate Interest Rate Select Credit Card Corporation

≈

+

+

Print Credit Card Contract

Select Credit Card Corporation

Calculate Interest Rate

+

Print Credit Card Contract

Fig. 12. Term-Conflicting Operations

The following theorem shows the equivalence of term di erences in process model terms and di erences in the execution traces of process models. Theorem 1 (Equivalence of term di«erence and trace di«erence). Let f1 V1 and f2 V2 be two corresponding fragments together with a mapping Corr(V1  V2 ) of V1 and V2 be given that are reduced to the corresponding elements (e1  e2 ) Corr(V1  V2 ). Let

104

C. Gerth et al.

further the normalized process model terms tCorr  f 1 , tCorr  f 2 be given. Each di«erence between the terms tCorr  f 1 , tCorr  f 2 induces a trace di«erence in the execution traces of f1 and f2 and each di«erence in the traces of f1 and f2 lead to a term di«erence. Proof Sketch: To prove Theorem 1 we have to show that each term di«erence induces a trace di«erence and no term di«erence induces no trace di«erence.

Case 1 (term di«erence  trace di«erence): We assume that the terms tCorr f 1 , tCorr f 2 contain at least one di«erence. A di«erence can have two reasons. Either the term representations itself di«er, or there is a di«erence in the partial order of the branches of the fragments. A di«erence in the former case occurs if corresponding elements are in di«erent orders what obviously results in di«erent traces. In the latter case, there is no di«erence in the term representation, since all contained sequences can be matched. However, the partial orders of the terms are di«erent. That means, at least one branch is executed in a di«erent order resulting in di«erent execution traces. Case 2 (no term di«erence  no trace di«erence): We assume that in the terms tCorr f 1 , tCorr f 2 no term di«erence exists. That means, the corresponding elements in the terms itself are in identical orders. In addition, since the partial orders of the terms are identical, the sequences within the terms are executed in the same order. Thus, an execution of the fragments results in equal traces.

We have shown, that for each pair of term-conflicting change operations modifying corresponding model elements there exists a term di erence in the process model terms, which is equivalent to a trace di erence (Theorem 1). Hence, the term-conflicting operations constitute semantically conflicting change operations according to Definition 2. This shows that we have found a way to eÆciently compute semantically conflicting operations. In Step 2a, we have computed conflicts between change operations modifying corresponding model elements within fragments. What remains, is the computation of conflicts between dependent operations that modify non-corresponding elements that were ignored in the previous step. Similar to Step 1b, this can be done, using corresponding elements, whose change operations are not conflicting as fixpoints. Therefore, we compute position parameters of dependent change operations within the fragment in terms of fixpoint (e.g., operation e) InsertAction(”Sign Contract”, ”Print Credit...”, ”JoinP1 V1 ”)). Then the operations are compared using the conflict matrix to identify conflicts. In some cases, position parameters of dependent change operations cannot be specified using fixpoints only. These operations are marked as conflicting. Figure 13 shows the conflicts that are computed using our method. Our work shows that conflict detection can be performed on a semantic level using a term formalization of process models and their hierarchical structure. Thereby, we have significantly reduced the overall number of conflicts (from 18 to 6 in the example) between change operations and in particular the number of false-positive conflicts. Based on process model terms, equivalent operations contained in complex fragments cannot be identified using only our approach. Instead, for those fragments, we leverage trace equivalence. This still is way faster than a pure trace equivalence approach, since traces only need to be computed for fragments, which are significantly smaller compared to the whole process model. For more details about the term rewriting system the reader is referred to [7].

Precise Detection of Conflicting Change Operations Using Process Model Terms

105

Δ(V, V1): a) InsertAction(“Check Cust. Data”, “Record Cust. Data”, “Compute Cust. Scoring”) b) InsertAction(“Open Account”, “Check Cust. Data”, “Compute Cust. Scoring”) c) InsertParallelFragment(FP1-V1, “Prepare Bank Card”, “Prepare Credit Card”) d) InsertAction(“Print Credit Card Contract”, -, -) e) InsertAction(“Sign Contract”, “Print Credit Card Contract”, “JoinP1-V1”) f) InsertParallelFragment(FP2-V1, -, -) g) InsertAction(“Calc. Interest Rate”, -, -) h) InsertAction(“Select Credit Card Corp.”, -, -) i) InsertAction(“Set Credit Limit to 0”, “Prepare Prep. Bank Card”, “MergeA-V1”) j) InsertAction(“Remove Credit Card”, “Set Credit Limit to 0”, “MergeA-V1”) k) InsertAction(“Set Interest Rate to 0”, “Remove Credit Card”, “MergeA-V1”)

Overall # of Conflicts: 6

Δ(V, V2): m) InsertAlt.Fragment(FA2-V2, “Record Cust. Data”, “Compute Cust. Scoring”) n) InsertAction(“Check Cust. Data”, “MergeA2-V2”, “DecisionA2-V2”) o) InsertAction(“Retrieve add. Data”, “DecisionA2-V2”, “MergeA2-V2”) p) InsertParallelFragment(FP1-V2, “Prepare Bank Card”, “Prepare Credit Card”) q) InsertAction(“Print Credit Card Contract”, -, -) r) InsertAction(“Calc. Interest Rate”, -, -) s) InsertAction(“Ask for Credit Limit”, -, -) t) InsertAction(“Select Credit Card Corp.”, -, -) u) InsertAction(“Open Account”, “MergeA-V2”, “End”) v) InsertAction(“Set Interest Rate to 0”, “Prepare Prep. Bank Card”, “MergeA-V2”) w) InsertAction(“Remove Credit Card”, “Prepare Prep. Bank Card”, “Set Interest Rate to 0”) x) InsertAction(“Set Credit Limit to 0”, “Prepare Prep. Bank Card”, “Remove Credit Card”)

Fig. 13. Computed Conflicts after Step 2

6 Related Work One area of related work is concerned with model composition and model versioning. Alanen and Porres [1] describe an algorithm how to compute elementary change operations. Kolovos et al. [11] describe the Epsilon merging language which can be used to specify how models should be merged. Kelter et al. [9] present a generic model di erencing algorithm. In the IBM Rational Software Architect [15] or using the EMF Compare technology [5], dependencies and conflicts between versions are computed based on elementary changes. These approaches to model versioning deal with the problem of model merging but they do not study the concept of semantic conflicts in order to reduce the number of syntactic conflicts. In [20], Nejati et al. combine di erent matching strategies (static & behavioral) in their approach to statechart matching and merging. This may also lead to less falsepositive conflicts, however, conflict detection is not considered in their work. In the graph transformation community, dependencies of transformation rules have been studied in the literature: Mens et al. [18] analyze refactorings for dependencies using critical pair analysis. They first express refactorings as graph transformations and then detect dependencies using the AGG tool [23]. Our earlier work [12] formalizes change operations using graph transformations and then proposes dependency and conflict matrices for them. All these approaches follow a syntactic approach to conflict detection, based on transformation rules and conflict matrices. Brosch et al. [3] have recently identified the problem that the quality of conflict detection and resolution in model versioning systems is not suÆcient. They introduce an approach for identifying refactorings in modeling tools and propose to integrate these refactorings into the conflict detection of versioning systems. In [2], Altmanninger et al. make semantic aspects of modeling languages explicit using semantic views. Based

106

C. Gerth et al.

on the views semantic conflicts can be reported. These works can be considered complementary to our work which aims at making the conflict detection more precise by taking into account the execution semantics of models. Cicchetti et al. [4] propose a metamodel for the specification and detection of syntactical and semantical conflicts. In contrast to their work, we introduce a particular approach for eÆciently computing semantic conflicts. Rinderle et al. [22] have studied disjoint and overlapping process model changes in the context of the problem of migrating process instances but have not considered dependencies and conflicts between change sequences and di erent forms of conflict resolution.

7 Conclusion and Outlook In this paper, we have considered the detection of conflicting change operations in version management of business process models as an example for life-cycle support of models in model-based development. We have identified shortcomings of existing approaches that rely on a purely syntactic comparison and potentially result in falsepositive conflicts. To overcome these shortcomings, we have introduced a notion of syntactic and semantic conflicts. For the detection of conflicts, we have presented a dedicated method for version management of business process models using normalized process model terms. Our initial results have shown that taking the semantics of process modeling languages into account, helps to compute precise conflicts and avoids false-positive conflicts. The validation of our approach by integrating the semantic conflict detection between change operations into our existing tool support for model merging, is subject to future work. Acknowledgements. The authors wish to thank Jana Koehler for valuable feedback on an earlier version of this paper.

References 1. Alanen, M., Porres, I.: Dierence and Union of Models. In: Stevens, P., Whittle, J., Booch, G. (eds.) UML 2003. LNCS, vol. 2863, pp. 2–17. Springer, Heidelberg (2003) 2. Altmanninger, K.: Models in Conflict - Towards a Semantically Enhanced Version Control System for Models. In: Giese, H. (ed.) MODELS 2008. LNCS, vol. 5002, pp. 293–304. Springer, Heidelberg (2008) 3. Brosch, P., Langer, P., Seidl, M., Wimmer, M.: Towards End-User Adaptable Model Versioning: The By-Example Operation Recorder. In: ICSE Workshop on CVSM, pp. 55–60. IEEE, Los Alamitos (2009) 4. Cicchetti, A., Di Ruscio, D., Pierantonio, A.: Managing Model Conflicts in Distributed Development. In: Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., V¨olter, M. (eds.) MODELS 2008. LNCS, vol. 5301, pp. 311–325. Springer, Heidelberg (2008) 5. Eclipse Foundation. EMF Compare,        6. Gerth, C., K¨uster, J.M., Engels, G.: Language-Independent Change Management of Process Models. In: Sch¨urr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 152–166. Springer, Heidelberg (2009)

Precise Detection of Conflicting Change Operations Using Process Model Terms

107

7. Gerth, C., Luckey, M., K¨uster, J.M., Engels, G.: Detection of Semantically Equivalent Fragments for Business Process Model Change Management. In: SCC 2010, pp. 57–64. IEEE Computer Society, Los Alamitos (2010) 8. International Business Machines Corp (IBM). IBM WebSphere Business Modeler,       9. Kelter, U., Wehren, J., Niere, J.: A Generic Dierence Algorithm for UML Models. In: Liggesmeyer, P., Pohl, K., Goedicke, M. (eds.) Software Engineering 2005, GI. LNI, vol. 64, pp. 105–116 (2005) 10. Kiepuszewski, B.: Expressiveness and Suitability of Languages for Control Flow Modelling in Workflows. PhD thesis, Queensland University of Technology, Brisbane (2002) 11. Kolovos, D.S., Paige, R., 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) 12. K¨uster, J.M., Gerth, C., Engels, G.: Dependent and Conflicting Change Operations of Process Models. In: Paige, R.F., Hartman, A., Rensink, A. (eds.) ECMDA-FA 2009. LNCS, vol. 5562, pp. 158–173. Springer, Heidelberg (2009) 13. K¨uster, J.M., Gerth, C., Engels, G.: Dynamic Computation of Change Operations in Version Management of Business Process Models. In: K¨uhne, T., Selic, B., Gervais, M.-P., Terrier, F. (eds.) ECMFA 2010. LNCS, vol. 6138, pp. 201–216. Springer, Heidelberg (2010) 14. K¨uster, J.M., Gerth, C., F¨orster, A., Engels, G.: Detecting and Resolving Process Model Dierences in the Absence of a Change Log. In: Dumas, M., Reichert, M., Shan, M.-C. (eds.) BPM 2008. LNCS, vol. 5240, pp. 244–260. Springer, Heidelberg (2008) 15. Letkeman, K.: Comparing and merging UML models in IBM Rational Software Architect: Part 3. A deeper understanding of model merging. In: IBM Developerworks (2005) 16. Levenshtein, V.I.: Binary Codes Capable of Correcting Deletions, Insertions and Reversals. Soviet Physics Doklady 10, 707 (1966) 17. Mens, T.: A State-of-the-Art Survey on Software Merging. IEEE Trans. Software Eng. 28(5), 449–462 (2002) 18. Mens, T., Taentzer, G., Runge, O.: Analysing refactoring dependencies using graph transformation. Software and System Modeling 6(3), 269–285 (2007) 19. Murata, T.: Petri Nets: Properties, Analysis and Applications. Proceedings of the IEEE 77(4), 541–580 (1989) 20. Nejati, S., Sabetzadeh, M., Chechik, M., Easterbrook, S.M., Zave, P.: Matching and Merging of Statecharts Specifications. In: ICSE 2007, pp. 54–64. IEEE Computer Society, Los Alamitos (2007) 21. Object Management Group (OMG). Business Process Modeling Notation (BPMN),      !"#$ 22. Rinderle, S., Reichert, M., Dadam, P.: Disjoint and Overlapping Process Changes: Challenges, Solutions, Applications. In: Meersman, R., Tari, Z. (eds.) OTM 2004. LNCS, vol. 3290, pp. 101–120. Springer, Heidelberg (2004) 23. Taentzer, G.: AGG: A Graph Transformation Environment for Modeling and Validation of Software. In: Pfaltz, J.L., Nagl, M., B¨ohlen, B. (eds.) AGTIVE 2003. LNCS, vol. 3062, pp. 446–453. Springer, Heidelberg (2004) 24. Glabbeek, R.J.v.: The Linear Time-Branching Time Spectrum I - The Semantics of Concrete, Sequential Processes. In: Handbook of Process Algebra, ch. 1, pp. 3–99. Elsevier, Amsterdam 25. van der Aalst, W.M.P., Hirnschall, A., Verbeek, H.M.W.: An Alternative Way to Analyze Workflow Graphs. In: Pidduck, A.B., Mylopoulos, J., Woo, C.C., Ozsu, M.T. (eds.) CAiSE 2002. LNCS, vol. 2348, pp. 535–552. Springer, Heidelberg (2002) 26. Vanhatalo, J., V¨olzer, H., Leymann, F.: Faster and More Focused Control-Flow Analysis for Business Process Models Through SESE Decomposition. In: Kr¨amer, B.J., Lin, K.-J., Narasimhan, P. (eds.) ICSOC 2007. LNCS, vol. 4749, pp. 43–55. Springer, Heidelberg (2007)

Capturing the Intention of Model Changes Patrick K¨ onemann Informatics and Mathematical Modelling, Technical University of Denmark, 2800 Kgs. Lyngby, Denmark [email protected]

Abstract. Model differences calculated by differencing algorithms contain the atomic changes made to a model. However, they do not capture the user’s intention of the modification. We present concepts and a framework for abstracting from atomic changes to produce semantic changes, for example, “move all classes from package A to B” instead of “move classes X, Y, and Z from package A to B”. Semantic changes abstracted this way are closer to the user’s intention and are applicable to other models much like customizable refactorings. Keywords: Model differencing, Model refactoring, Model patching.

1

Introduction

Models are used as primary artifacts in software development processes to raise the level of abstraction. In this paper, we concentrate on MOF-based models (Meta Object Facility [10]) such as the UML (Unified Modeling Language [12]). Comparing models is subject to current research, in particular difference calculation and applying differences to other models. We assume that changes follow some intention of the user. However, current approaches only work on a lower technical level and do not describe the actual intention. This implies many limitations on the other model to which the difference shall be applied. Differencing technologies are able to calculate the differences between two model versions, but only as sets of atomic changes. Suppose that these changes can be used as patches, these patches are only applicable to models with very similar contents as the original model. Applying changes to models with different contents is not possible, because the expected model elements may not exist. In this paper, we propose a method for abstracting from atomic changes to create semantic changes. Semantic changes describe a change more generically, e.g. they are applicable to one or even to multiple model elements, although the model’s structure differs from the original model. This is achieved by individual and flexible matching strategies defined for each semantic change, instead of having one single matching algorithm for all changes. A matching produces a mapping that specifies which model elements will be modified by a change. Consequently, these semantic changes are applicable to models with different contents. Evidently, this is not a fully automatic procedure, some user interaction is required. D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 108–122, 2010. c Springer-Verlag Berlin Heidelberg 2010 

Capturing the Intention of Model Changes

109

A prototypic implementation is available that provides a framework for creating and applying semantic changes for EMF and UML models. It was successfully tested with refactorings [7] and design pattern elaborations [8].

2

Example and Terminology

This section presents an example to illustrate our work and introduces important terms. Fig. 1 shows the unchanged and changed version of a UML model MA containing a package data with classes Article, Book, and Cover, amongst others. The modeler’s intention was to apply the ’extract superclass’ refactoring [7] to the model; more concrete, ’to move the common attribute id of all classes to a common superclass’. Model differencing technologies, as discussed in Sect. 8, calculate the differences between two versions of a model. The difference representation is the abstract syntax, the difference visualization the concrete syntax. The representation consists of a set of changes, examples are listed in Table 1: one change for the new class IdElement (1), three changes for the deleted attributes (2–4), and three changes for generalizations from the classes from which the attributes were deleted to the newly added class IdElement (5–7). All these changes are atomic changes that describe one modification for one individual model element each. Model references specify which model elements are modified. Altogether do the changes capture the intention behind the overall modification (’extract superclass’) in model MA . Assume that the modeler wants to apply these changes to another model MB depicted in Fig. 2; in other words, model MB shall be modified such that the changes reflect the same intention as for model MA . Model MB contains a package customerdata with three classes Customer, Contract, and Invoice, of   

  

 

       



 

  

  

   



 



  

   



  

  

Fig. 1. Unchanged (left) and changed (right) version of an example UML model MA

110

P. K¨ onemann Table 1. List of changes (Δ) in model MA (Fig. 1) # Change type

Change description

1 add class

IdElement to data, including attribute id : String

2 delete attribute 3 delete attribute 4 delete attribute

id : String from Book in data id : String from Cover in data id : String from Article in data

5 add generalization 6 add generalization 7 add generalization

from Book in data to IdElement from Cover in data to IdElement from Article in data to IdElement

which the latter two own an attribute [class name] id : String. Simply calculating the differences Δ from model MA (Δ = δ(MA , MA )) and applying them to model MB (MB = π(MB , Δ)) will not work—in order to apply Δ to model MB (semantically: apply the ’extract superclass’ refactoring for id-attributes), several model elements must be matched (identified) in model MB : 1. the package to which the class IdElement should be added (customerdata); 2. the classes from which a generalization to the new class IdElement should be added (Contract and Invoice); 3. the attributes id : String which should be deleted (contract id : String and invoice id : String). Besides the problem that steps 2 and 3 must match two model elements in model MB (unlike three in model MA ), there are several structural differences between

         

 



  

  



     

 

        

    

Fig. 2. Some other UML model MB Table 2. List of abstracted changes (Δ ) that are applicable to model MB # old # Change type

Change description

1’

IdElement to package *data*, incl. attribute id : String

1

add class

2’ 2–4 delete attribute

*id* : String from all classes (that have one) in *data*

3’ 5–7 add generalization from classes (with id-attribute) in *data* to IdElement

Capturing the Intention of Model Changes

111

model MA (from which Δ was calculated) and model MB (to which Δ shall be applied): 1. the package is called customerdata, and not data; 2. the containing classes are named differently; 3. their id-attributes also have different names. The result of the matching process φ is called mapping Φ which maps the model references of each change in Δ to model elements in model MB : Φ = φ(Δ, MB ). In order to apply the refactoring to model MB , we rather need changes Δ as listed in Table 2. Similar changes are semantically grouped now: the deletion of attributes and the creation of generalizations are single changes, respectively. The specification of where they shall be applied is changed to a set of classes instead of being one specific class. The asterisks (e.g. in *data* ) are wildcards. The application of changes is corrected to MB = π(Δ , Φ, MB ), assuming we have abstract changes Δ and a mapping Φ available.

3

Problem

We assume that a model, maybe a UML model, underwent several changes. In terms of model differencing technologies, a change can be adding, removing, or changing model elements. Further, we assume that these changes were done due to a particular intention. All changes in our context are part of the same intention; hence, the overall modification is composed of several atomic changes. Our goal is to support the user in applying changes with the same intention to other models. These other models should be of the same kind (same metamodel), but they may differ structurally from the original model. Technically speaking, when performing the same semantic changes, a different set of atomic changes than for the original model might be applied to the other model. Challenge 1: Distil the intention of the original changes. Atomic changes made to the original model are on a low level and describe individual modifications on single model elements. However, other models do presumably have different contents, different model elements. To reach the goal, we need to abstract from the atomic changes and extract their intention into semantic changes such that these semantic changes are also applicable to other models. Challenge 2: Applicability to other models. The changes must be applicable to other models than the original model. Many differencing technologies, especially those integrated in versioning systems, do not support arbitrary models but require a common ancestor of the original and the other model (3-way-merge). The use case for our goal is different: the semantic changes should be applicable to other models that are structurally different; particularly with regard to those model elements that shall be changed. Challenge 3: Match semantic changes to the other model. In order to apply the semantic changes to the other model, all model elements have to be matched that shall be changed. Only if the matching is done successfully and a mapping is created, the mapped model elements can be changed.

112

P. K¨ onemann

1. calculate differences (į)

2. transform (ș1)

4. match model references (ij1)

5. refine mapping (ij2) (interactive)

6. apply changes (ʌ) Model MB (original)

Model MA (original)

Mapping Model MA (changed)

model differences (not applicable to other models)

3. additional transformations (ș2) (user’s choice) Creation of model-independent differences

model-independent differences (applicable to other models)

Model MB (changed)

Application of model-independent differences

Fig. 3. Complete model-independent difference creation and application process

Conclusion: We aim at extracting semantic changes from one model and applying them to another model. The focus of the use case is to extract the intention of the changes; examples are refactorings and pattern elaborations by example. This is much more generic than the traditional use case of patching models, in which the other models is expected to have very similar contents as the original model. Moreover, semantic changes require a metamodel that allows an adequate abstraction.

4

Conceptual Solution

The following process outlines our conceptual solution (sketched in Fig. 3). 1. Calculation of differences with atomic changes (Δ = δ(MA , MA )). There are many sophisticated model differencing technologies available (cf. Sect. 8), so there is nothing novel in this step. 2. Transformation into a model-independent format (Δa = θ1 (Δ)). The model-independent format decouples atomic changes from the original model. The resulting model-independent changes Δa can, for instance, be used as patches for models. However, they are only applicable to models with the same or very similar contents as the original model. 3. Abstraction from atomic to semantic changes (Δs = θ2 (Δa )). In this step, the user may select additional transformations to the changes; each of them yielding a particular purpose, e.g., to make changes applicable to multiple model elements, or to combine similar changes. The overall idea of these (pluggable) transformations is to keep the intention of the original changes but to extend their scope of application; that is, making them applicable to other models, too. 4. Initial (automatic) matching of changes to model elements in an arbitrary model or sub-model (Φ = φ1 (Δs , MB )). Each change in the model-independent format specifies individually to which model elements it is applicable. Further, it is self responsible for identifying

Capturing the Intention of Model Changes

113

these elements in an arbitrary model or (to reduce complexity and improve performance) sub-model. Doing that for all changes yields the initial mapping Φ from changes to model elements. 5. Interactive refinement of the mapping (Φ = φ2 (Φ)). The user may review and refine the initial mapping Φ. This is required if a change is mapped to too many or too few model elements. It is also possible to map a single semantic change to multiple model elements; an example is the movement of several elements (e.g. UML classes) from one container (e.g. UML package) to another. The user may in particular freely add/remove model elements to/from the mapping of each change. 6. Application of changes (MB = π(Δs , Φ , MB )). This step is straightforward; the framework automatically modifies all mapped model elements in model MB according to the changes Δs . Model References. There are many ways to specify the set of elements to which a change shall be applied. Most matching algorithms use either unique identifiers [3,5,9,19] or calculate the similarity to the original model element to find the (single) model element of interest [3,21,2,20]. In addition, we use model queries. All in all, we call all these different kinds of model references generically symbolic references, because they all have different referencing strategies. In principle, our framework supports all of them. Conclusion: We shift the focus from atomic changes to the intention of the modification. Instead of having one common matching algorithm during change application, the matching is defined for each change individually. That flexibility allows using several different matching strategies even in the same set of semantic changes; this is useful, for example, if one change in a set of semantic changes should be applied to multiple model elements whereas another one from the same set should be applied to one particular model element only. To sum it up, steps 2 and 3 are our novel concepts for the creation of semantic changes whereas steps 4 and 5 are novel for their application.

5

Model-Independent Difference Representation

This section explains the metamodel of our difference representation and its symbolic references. The metamodel contains a class hierarchy for all changes. The excerpt in Fig. 4 shows the abstract superclass of all changes, Change, and the hierarchy for added elements, AddElementChange. The changed model element is referenced using an ISymbolicReference, a generic interface for referencing model elements as stated in the next subsection. An added element is described by another generic interface, IModelDescriptor. In total, the metamodel supports nine types of changes: added, removed, and changed elements, attributes, and references. Other technologies use the same change types, so there is nothing novel here (our complete metamodel is available in [13]).

114

P. K¨ onemann

Change

   *

) ) )

&

Elem entChange

ISym bolicReference              

+)),   

+)), IModelDescriptor ) ) )

'

(     *

           UML class diagram

Fig. 4. Excerpt from metamodel for model-independent differences



& %

ISym bolicReference           

    

Condition

'(()





   "  #$

  

   

!    UML class diagram

Fig. 5. Interface for symbolic references and an implementation

5.1

Symbolic References

Symbolic references are an abstract concept for referencing model elements. The important requirement is that realizations must match those elements in a model which are described by it. This matching of model elements is step 4 in Sect. 4. There are several realizations of symbolic references in literature, e.g. using unique identifiers, similarity calculations, or signatures [6]; each of them has advantages and disadvantages (see Tab. 3). Especially their resolution to model elements is different. All of them can be plugged into our framework, they just need to implement the interface ISymbolicReference shown in Fig. 5. The method match(Model) is where the magic happens: it is called in the matching phase (step 4 in Sect. 4) and returns a set of elements to which a change shall be applied. Doing that for all symbolic references of all changes yields the initial mapping. The more precise the initial mapping is, the less the user has to refine in step 5. Only signature- (and condition-)based referencing strategies may match multiple model elements so far. However, the properties lower- and upperBound specify the cardinality for each symbolic reference. The default cardinality is 1..1, that is, each change is supposed to be applied to exactly one model element.

Capturing the Intention of Model Changes

115

Table 3. Several matching strategies of symbolic references Type id-based1

Uses Description [19,1,3] Each model element has a unique identifier. Then a symbolic reference refers to the element with a particular identifier. Adv.: fast, exact; Disadv.: unique identifiers are not always available, independently created models have different identifiers. similarity- [21,3,17] A reference model (e.g. copy of original model) is used to match based the same model elements; usually attribute values and graph structure are compared. Adv.: no unique identifiers required, generically applicable; Disadv.: complexity might yield performance issues. signature[6] A user-defined function is used to query the model and returns based the elements with particular properties (the signature). Adv.: flexibility, returns sets of elements; Disadv.: signature specification required, ambiguity is not always desired. condition[14] This specialization of signature-based referencing uses OCL conbased1 ditions as the signature.

Condition-based. The example realization ElementSetReference in Fig. 5 is a specialization of signature-based model referencing. It contains a set of conditions (the signature) expressed in the Object Constraint Language (OCL) [11]. A query on a model returns all elements for which the conditions hold true. Our default symbolic reference creator automatically produces expressions checking the values of all primitive attributes of an element; however, any kind of expression, e.g. checking referenced elements in the graph, is possible and can easily be added. A condition for a symbolic reference to the class Book in the example (cf. Fig. 1) would be ”name=’Book’ and abstract=false” (simplified). This expression obviously matches exactly one element in both, the unchanged and the changed version of the model, namely the class Book. In case of ambiguous matchings, a context may be used. Although the default cardinality for symbolic references is 1..1, this realization can potentially match multiple model elements; hence the name ElementSetReference. The abstractions in step 3 (Sect. 4) make use of that feature. 5.2

Model Descriptors

Now we can refer to arbitrary model elements, for instance, where a new element should be added. But how to express what shall be added? The challenge here is to store cross-references, that is, references from the added element to other elements in the model and vice versa. To this end, IModelDescriptor uses again symbolic references to store cross-references. 1

Implemented in our prototype.

116

P. K¨ onemann

During difference application, a model descriptor must contain enough information to restore a sub-model including cross-references. The interface IModelDescriptor (cf. Fig. 4) has two operations for applying the sub-model to a model: firstly (buildStructure), the objects and their properties are created; secondly (restoreCrossReferences), all cross-references are restored. The default implementation is straightforward: it uses EMOF reflection [10] to create model elements and to restore cross references. For non-EMOF models, an appropriate implementation of IModelDescriptor must be provided.

6

Creation and Transfer of Model-Independent Differences

This section explains how to use model-independent differences to capture the intention of modifications in one model in order to apply them to another model. The trick is to abstract from atomic changes and to make these abstracted changes (which we call semantic changes) applicable to other models. The following subsections explain how we realized each step from the solution outline in Sect. 4. 6.1

Difference Calculation

A difference calculation algorithm δ produces differences from two models (or three models in case of 3-way comparison): Δ = δ(M, M  ). Several technologies already exist for that purpose. Instead of inventing yet another one, we use existing technologies which have the advantage of being configurable and extendable. Our prototype supports EMF Compare so far; however, the framework is designed to work with other differencing technologies as well. 6.2

Computing the Difference Representation

This step produces model-independent differences from the output of a difference calculation algorithm: Δa = θ1 (Δ). We treat differences as models and use a model-to-model transformation specified as QVT Operation mappings for that. All model references are replaced with symbolic references; implementations of symbolic references must provide this creational function which is called during the transformation: toSymbolicReference(ModelElement): ISymbolicReference

The resulting changes are still atomic (hence Δa ) but have the format explained in Sect. 5.1 and can be used as a patch for models; however, they are not yet applicable to models with different contents. 6.3

Abstracting Atomic Changes to Semantic Changes

The goal is to make model changes applicable to other models whose contents differ from the original model. To this end, we analyzed atomic changes and identified three abstractions to make changes applicable to other models while preserving the intention of the original changes:

Capturing the Intention of Model Changes

117

1. Changes must be applicable to elements that differ from the original model elements (concerning attribute values and graph position). 2. The changes’ multiplicity of application must be open. 3. If the same change is made to multiple model elements, do not describe it for individual model elements but combine them into one generic change. The transformations θS , θC , and θM realize these abstractions (we present them in more detail in [15]) and produce semantic changes (hence Δs ): Δs = (θS ◦ θC ◦ θM )(Δa ) = θ2 (Δa ). Their order is irrevelant since they are commutative. Scope Expansion (θS ). The purpose of this transformation is to increase the fuzzyness in the matching process. That is, the scope of a change, which means the set of model elements that is matched, will be extended. In other words, even slightly different model elements will be matched. For similarity-based references, it means to decrease the threshold of when two elements are considered being the same; for example, not 90% but 50% of the elements’ properties must be equal. For condition-based references which check the elements’ attributes to query a model, we propose a modification of the OCL expression: instead of checking for equality of string attributes, the expression checks for similarity. For example, the expression for quering the UML package data (cf. Fig. 2) is changed from name=’data’ and... to name.isSimilar(’data ’,0.7) and... with a similarity threshold of 0.7. Although our similarity algorithm is based on case-insensitive containment checks, it already produces fairly good results in the evaluation. More sophisticated algorithms might slightly increase accuracy but will most likely reduce performance. Scope expanded references are denoted with wildcards (e.g. *data* ) in Tab. 2. Cardinality Expansion (θC ). Symbolic references based on unique identifiers match the one particular model element that has the given identifier. Conditionbased symbolic references, on the other hand, are able to match a set of model elements instead of just one. In order to make a change applicable to multiple elements, its cardinality must be expanded. That is done by changing its bounds from 1..1 (default) to 1..* (cf. bound attributes in Fig. 5). Some example scenarios are: – An attribute is deleted from several classes. – A generalization is added to several classes. – All classes in one package are moved to another package. In combination with Scope Expansion, this modification allows applying a change multiple times. It is also the basis for Merging Changes. Merging Changes (θM ). This transformation merges similar changes into single, generic changes: look for two or more changes that are equal except for the symbolic reference that specifies where the changes shall be applied. Replace these changes with one that combines the differing symbolic references.

118

P. K¨ onemann

For condition-based symbolic references, the replacement is done by keeping conditions that all changes have in common and removing all other conditions. Regarding the example, the deletion of the attribute id : String can be merged into a single change. These are the conditions of the individual changes before the merge: name.isSimilar(’ Article ’,0.7) and isAbstract=false and isActive=false and ... (type: Class) name.isSimilar(’Book’,0.7) and isAbstract=false and isActive=false and ... (type: Class) name.isSimilar(’Cover ’,0.7) and isAbstract=false and isActive=false and ... (type: Class) All of them have the same context, that is by default their container—the package data in our example. The conditions of the context are: name.isSimilar(’data ’,0.7) and visibility =#public (type: Package) And this is the merged condition: isAbstract=false and isActive=false and ... (type: Class) The context remains the same since it does not differ for the atomic changes. The symbolic reference of this merged change matches indeed all classes Article, Book, and Cover, as intended, but also Author ! However, since the change describes the deletion of an attribute, the framework is smart enough to keep only those model elements to which the change is applicable (i.e., to all elements that own such an attribute of interest) and, thus, removes the class Author from the set of matched model elements. 6.4

Change Application: Initial Matching

The previous steps served the creation of model-independent differences whereas the remaining steps deal with their application to another model. The initial matching creates a mapping Φ from all changes to the model elements that shall be modified: Φ = φ1 (Δs , MB ). This mapping is calculated automatically by calling ISymbolicReference.match(..) for all changes. Hence, the matching algorithm is distributed over all symbolic references. In case of condition-based symbolic references, for instance, an OCL engine executes the query on the model. The Mapping is described by the data structure defined in Fig. 6. It consists of ChangeMappings, one for each change; if the attribute ignore is set to true, then this change is completely ignored in steps 5 and 6 (the user can do that in

 

    1 Change

   1 ISym bolicReference           

0..* ModelElem ent

UML class diagram

Fig. 6. Definition of mapping from changes and symbolic references to model elements

Capturing the Intention of Model Changes

119

step 5). A ReferenceMapping maps a symbolic reference to the matched model elements. Right after the initial matching, the mapping is validated. The following two constraints are checked: (1) the number of matched model elements must be within the bounds of the symbolic reference; (2) the matched model elements must have the expected state. The first constraint can be checked by comparing the number of matched model elements with the respective bounds. The second constraint depends on the change; the deletion of a model element (like an attribute id ), for instance, requires that the particular model element exists. 6.5

Change Application: Refining the Mapping

In case the initial mapping is not valid, the user must resolve the issues as explained next. If the mapping is already valid, it may be refined by the user. The refinement is denoted Φ = φ2 (Φ). There are different strategies to make a mapping valid. If too few or too many model elements are matched for a symbolic reference such that the change is not applicable, the user has to add/remove model elements to/from the ReferenceMappings until the number matches the denoted bounds and the change is applicable. The user can, in particular, add arbitrary model elements to the mapping even if they were not matched by the symbolic references; the only condition is that the mapping is still valid (the bounds match and the change is still applicable). 6.6

Apply Model Differences

The final step in the process takes the model, the changes, and the mapping and applies all not ignored changes to the model: MB = π(Δs , Φ , MB ). This procedure is automated and straightforward: first, all references and elements are deleted; second, all elements and references are added; finally, all other changes like attribute changes and movements are performed. An optional subsequent step is the review of all applied changes. To this end, a model differencing technology can be used to compare and visualize the differences between models MB and MB . Another optional step is the creation of traceability links between the model differences and the changed model elements. This is in essence a persistent version of the mapping which can, for instance, be used for consistency checks [16].

7

Implementation and Evaluation

Our prototype implements the entire process described in Sect. 4 including two implementations of symbolic references (condition- and id-based) and the three transformations for abstracting changes. All steps in the presented process perform without noticable delay, except for the matching of condition-based symbolic references: it takes ca. two seconds (on a 2.2 GHz dual-core CPU) to match and apply 500 changes (all change types equally included). However, that is still sufficient for the proposed use cases.

120

P. K¨ onemann

The following procedure is used for correctness tests. It compares two versions of a model (a), performs the transformation (b), and applies the resulting changes again to the unchanged version of the model (c,d): 1. Δ = δ(M, M  ) 2. Δ = θ1 (Δ) 3. Φ = φ(Δ , M ) 4. π(Φ, Δ , M )=M ˇ  The actual test is the equality check =. ˇ This way, all change types and metamodel properties of EMF and UML models were tested. Further unit-tests check the application of abstracted Δ s to other models M2 (prepared expected model): ˇ 2 . 1’. as 1. 2’. Δ = (θ1 ◦ θ2 )(Δ) 3’. as 3. 3’. π(Φ, Δ , M2 )=M Besides these correctness tests, we captured 25 refactorings [7] (those, that are applicable to models) and 23 design patterns [8] from sample models and applied them to at least two other models each in order to test their applicability. It turned out that 14 refactorings and 8 patterns were generically applicable right away. 11 refactorings were only applicable if the models are similar to the sample models— the reason is that EMF Compare is not (yet) capable of detecting a movement into a newly added sub-model; instead, it detects adds and removals. The other 15 design patterns could be applied to a model, but not in a generic way; example scenarios were created instead which the user has to adjust afterwards. However, a parameterization of semantic changes would solve that issue.

8

Related Work

Most of related work either focuses on versioning systems using 3-way merge [18], or on difference transfer to other models as known as patching. Table 4 gives an overview of related work. Although some approaches have similar concepts for representing model differences and referencing model elements, none of them supports multiple referencing strategies at the same time. Table 4. Overview of related work Feature difference calculation changing model with common anchestor changing similar models changing arbitrary models merging changes

EMF Compare ✔

SiDiff ✔

EPatch ✗2

AMOR ✗2

Maudeling ✔

Chichetti ✗2

our work ✗2

✔

✔

✔

✔

✔

✔

✔

✗

✗

✔

✔

✔

✔

✔

✗

✗

✗

✔

✗

✔

✔

✗

✗

✗

✗

✗

✗

✔

EMF Compare [3] is a generic and extendable comparison framework for all EMF-based models including UML and many more domain specific languages. SiDiff [21] is a generic differencing algorithm which operates on basic graphs. It is 2

Other differencing technologies are used for difference calculation.

Capturing the Intention of Model Changes

121

highly configurable, can be adjusted to many different scenarios, and is integrated in several frameworks. However, neither of them is able to apply changes to other models like model MB . EPatch [5], an extension to EMF Compare, is a language for describing EMF-based patches using URIs for element references. Although an epatch is applicable to other models, their contents must not differ from model MA . AMOR is an adaptable model versioning technique for concurrent versioning systems. The operation recorder [2] defines refactorings as a set of model differences. They use OCL-based symbols for element references, similar to our condition-based symbolic references, and their generalization is similar to our abstractions. Maudeling [20] and the approach presented by Cicchetti et al. [4], both support patching others models. The latter uses model weaving concepts to be applicable to other models. However, none of the related work allows multiple matching strategies which is useful when dealing with different kinds of models.

9

Conclusion and Future Work

This paper presented novel concepts for a modular framework for extracting changes from a model such that the intention is preserved and the changes are also applicable to other models. The contribution includes the abstraction from atomic changes to semantic changes which are also applicable to other models. Moreover, we split the matching process into two phases: first, an automated initial matching; second, an optional, interactive refinement step. This allows the user to refine the set of model elements to which each change will be applied. The application of changes optionally produces traceability links between the model differences and the changed model elements. The prototype is currently based on EMF models (including UML) and EMF Compare as differencing technology but also extendable for other differencing technologies. It is freely available at http://modeldiff.imm.dtu.dk. Future work includes further research on symbolic references, in particular a way to parameterize condition-based model referencing. Moreover, we need more accurate difference detection, particularly concerning detection of movements.

Acknowledgment This project is supported by a DTU grant for the project: Model-synchronization Technology for Model-Based Software Engineering. I would like to thank Ekkart Kindler and Harald St¨ orrle for lots of helpful discussions and advice.

References 1. 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) 2. Brosch, P., Langer, P., Seidl, M., Wieland, K., Wimmer, M., Kappel, G., Retschitzegger, W., Schweinger, W.: An Example Is Worth a Thousand Words: Composite Operation Modeling By-Example. In: Sch¨ urr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 271–285. Springer, Heidelberg (2009)

122

P. K¨ onemann

3. Brun, C., Pierantonio, A.: Model Differences in the Eclipse Modelling Framework. CEPIS Upgrade – The European Journal for the Informatics Professional IX(2), 29–34 (2008) 4. Cicchetti, A., Ruscio, D.D., Pierantonio, A.: A Metamodel Independent Approach to Difference Representation. Journal of Object Technology 6(9), 165–185 (2007) 5. Eysholdt, M.: EPatch (2010), http://wiki.eclipse.org/EMF Compare/Epatch 6. Fleurey, F., Baudry, B., France, R.B., Ghosh, S.: A Generic Approach for Automatic Model Composition. In: Giese, H. (ed.) MODELS 2008. LNCS, vol. 5002, pp. 7–15. Springer, Heidelberg (2008) 7. Fowler, M.: Refactoring: Improving the Design of Existing Code. Object Technology Series. Addison-Wesley, Reading (June 1999) 8. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading (January 1995) 9. IBM Rational Software Architect (2010), http://ibm.com/software/awdtools/swarchitect 10. Object Management Group: Meta Object Facility (MOF) Core Specification (January 2006), http://www.omg.org/cgi-bin/doc?formal/2006-01-01 11. Object Management Group: Object Constraint Language Specification, Version 2.0. (May 2006), http://www.omg.org/cgi-bin/doc?formal/2006-05-01 12. Object Management Group: Unified Modeling Language, Superstructure, V2.2. (February 2009), http://www.omg.org/spec/UML/2.2/Superstructure/PDF 13. K¨ onemann, P.: Model-independent Diffs. IMM-Technical Report-2008-20, Technical University of Denmark (December 2008) 14. K¨ onemann, P.: Model-independent Differences. In: Proceedings: ICSE Workshop on Comparison and Versioning of Software Models, Vancouver, Canada, pp. 37–42. IEEE Computer Society, Los Alamitos (May 2009) 15. K¨ onemann, P.: Semantic Grouping of Model Changes. In: Proceedings: TOOLS EUROPE 2010 International Workshop on Model Comparison in Practise, Malaga, Spain, pp. 50–55. ACM, New York (July 2010) 16. K¨ onemann, P., Zimmermann, O.: Linking design decisions to design models in model-based software development. In: Babar, M.A., Gorton, I. (eds.) ECSA 2010, LNCS, vol. 6285, pp. 246–262. Springer, Heidelberg (2010) 17. Lin, Y., Gray, J., Jouault, F.: DSMDiff: A Differentiation Tool for Domain-Specific Models. European Journal of Information Systems, Special Issue on Model-Driven Systems Development 16(4), 349–361 (2007) 18. Mens, T.: A State-of-the-art Survey on Software Merging. IEEE Transactions on Software Engineering 28(5), 449–462 (2002) 19. Ohst, D., Welle, M., Kelter, U.: Differences between Versions of UML Diagrams. In: ESEC/FSE 2003, Dubrovnik, Croatia, pp. 227–236. ACM Press, New York (2003) 20. Rivera, J.E., Vallecillo, A.: Representing and Operating with Model Differences. In: Proceedings: TOOLS EUROPE 2008, Zurich, Switzerland. LNBIP, vol. 11, pp. 141–160. Springer, Heidelberg (2008) 21. Treude, C., Berlik, S., Wenzel, S., Kelter, U.: Difference Computation of Large Models. In: Proceedings: ESEC-FSE 2007, pp. 295–304. ACM Press, New York (2007)

Selective and Consistent Undoing of Model Changes Iris Groher and Alexander Egyed Johannes Kepler University Linz Altenbergerstr. 69, 4040 Linz, Austria {iris.groher,alexander.egyed}@jku.at

Abstract. There are many reasons why modeling tools support the undoing of model changes. However, the sequential undoing is no longer useful for interrelated, multi-diagrammatic modeling languages where model changes in one diagram may also affect other diagrams. This paper introduces selective undoing of model changes where the designer decides which model elements to undo and our approach automatically suggests related changes in other diagrams that should be undone also. Our approach identifies dependencies among model changes through standard consistency and well-formedness constraints. It then investigates whether an undo causes inconsistencies and uses the dependencies to explore which other model changes to undo to preserve consistency. Our approach is fully automated and correct with respect to the constraints provided. Our approach is also applicable to legacy models provided what the models were version controlled. We demonstrate our approach’s scalability and correctness based on empirical evidence for a range of large, third party models. The undoing is as complete and correct as the constraints are complete and correct.

1 Introduction We believe that the very nature of software modeling is about exploring design alternatives by trying out ideas and dismissing them if they are not satisfactory. However, today, modeling languages solely capture the final state of the model of a software system but fail to remember the many changes made along the way (the design history [9] with its decisions [13]). To compensate, modeling tools provide undo or version control mechanisms. However, these mechanisms capture the history of changes chronologically and if an undo is desired then a designer is forced to undoing changes chronologically (also undoing unrelated, intermittent changes). This paper presents an approach for the selective undoing of design changes during software modeling where previously discarded changes can be recovered without having to undo unrelated, intermittent changes. Selective undoing is particularly important during multi-view modeling (such as the UML with its many diagrammatic views) because logically related model elements are intentionally spread across independent diagrams to separate concerns [14]. Recovering a discarded model element may then require the recovering of model elements in other diagrams – or else risk causing inconsistencies in the model. D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 123–137, 2010. © Springer-Verlag Berlin Heidelberg 2010

124

I. Groher and A. Egyed

Unfortunately, designers do not explicitly capture all dependencies among model elements – nor would it be feasible to expect them to do so. It would also be invalid to expect related model elements to be in “close proximity” (time and space). Related model changes could be done independently by multiple designers – at different times and in different diagrams. Likewise, single designers may concurrently perform multiple unrelated model changes. Any heuristic that was to infer relationships among model elements based on the time the changes happened or their location would be fundamentally flawed and useless. This paper demonstrates that it is possible to automatically recover hidden dependencies among model changes through the help of consistency rules, wellformedness rules, and other design constraints [5] that typically exist and are enforced during software modeling. Constraints are specific to the modeling language or application domain. But our approach should be applicable to any modeling language for which such constraints are definable. In our experience, most modeling languages have such constraints and constraints are freely definable by the user. We previously demonstrated how to detect [5] and fix [6] inconsistencies in design models – but their use for recovering hidden dependencies among model changes is new. The designer first selects previously discarded versions of model elements for undoing (manual input) and our approach automatically evaluates whether the undoing of the designer-selected versions causes inconsistencies. If it does then our approach recursively tries to resolve the inconsistencies by automatically considering other undoing choices that have the potential of fixing the inconsistencies. If it finds them then our approach informs the designer of what other model elements to undo to avoid inconsistencies. Our approach is well-defined and precise. Its computational efficiency and scalability were evaluated through the empirical analysis of large, third-party, industrial software models. Since it detects dependencies among model elements based on model constraints, the quality of the undoing is as complete as the defined model constraints are complete. Correctness was assessed by validating whether the approach was able to recover a consistent state of the model after undoing (if it ever existed). Of course, our approach does not presume the models to be fully consistent [16]. Pre-existing inconsistencies are simply ignored.

2 Illustrative Example To illustrate the benefits of the selective undoing of model changes, consider the video-on-demand system in Figure 1. The left and middle models represent two existing model versions (snapshots), each containing three different diagrams (structural, scenario, behavioral). The top diagram of version 1 shows the static structure of the system in form of a class diagram: the display responsible for visualizing videos and receiving user input; the streamer responsible for downloading and decoding of video streams. The middle diagram presents a particular usage scenario in form of a sequence diagram. This diagram describes the process of selecting a movie and playing it. Finally, the bottom diagram shows the behavior of the streamer in form of a statechart diagram (a toggling between two states).

Selective and Consistent Undoing of Model Changes

125

Fig. 1. Two Versions of the Video-on-Demand System and Result of Undoing connect

Version 2 (Figure 1 middle) depicts a later design snapshot of the video-ondemand system. The designer has made several design changes. It has been decided that having a single method for both playing and pausing movies is no longer desired. Instead, the designer renamed the playPause() method to play() and created an additional method named pause(). The sequence diagram was adapted accordingly. Additionally, the connect() method in Streamer was deleted and the behavioral diagram of the Streamer and the scenario were adapted (e.g., selecting a movie no longer requires explicitly connecting to the streamer). The illustration does not depict logical dependencies among model elements in the different diagrams explicitly; however, they are present in form of model constraints. These constraints (often called consistency rules) describe conditions that a model must satisfy for it to be considered a valid model. Table 1 describes two such constraints on how UML sequence diagrams relate to class and statechart diagrams. Constraint 1 requires the name of a message to match an operation in the receiver’s class. If this constraint is evaluated on message stream in the sequence diagram in Figure 1 (version 1) then it first computes all operations of the message’s receiver class. The receiver of the stream message is the object streamer of type Streamer and the class’ methods are stream(), wait(), and connect(). The constraint is satisfied (i.e., consistent) because the set of operation names in Streamer contains one with the name stream – the name of the message. Constraint 2 states that the sequence of messages in the sequence diagram must correspond to allowed events in the statechart that describes the behavior of the receiver’s class. The given UML models are internally consistent (for simplicity) which is not required by our approach. Table 1. Sample Constraints (taken from literature)

Constriant 1 Constraint 2

Name of message must be declared as operation in receiver class operations=message.receiver.base.methods return(operations->name->contains(message.name))

Sequence of messages must correspond to events start=state transitions that correspond to first message return (start->exists(message sequence equal reachable sequence from start))

126

I. Groher and A. Egyed

Now imagine that the designer desires to recover the state of the model where the connect() message in the sequence diagram still existed (from version 2 to version 1) – without having to undo other changes that were made since (e.g., separate operations play and pause). The right of Figure 1 presents the desired result of this undoing which is a compromise between version 1 and version 2. It illustrates the challenge of selective undoing because simply recreating the connect message is insufficient since it causes two inconsistencies (no such operation exists in Streamer and no such transition exists in the statechart because both were deleted in version 2). Because of the logical dependency between this message in the sequence diagram and the operations defined in the message’s receiver class (cf. Constraint 1 in Table 1) we also need to undo the Streamer class to a version where the connect() operation existed. Further, because of the dependency between the connect() message and the transitions in the statechart (cf. Constraint 2 in Table 1) we need to undo the first transition to a version where it was named connect. However, we do not wish to undo the many other, unrelated changes. For example, the decision to change the playPause() operation in version 1 into separate operations play() and pause() in version 2 should not be affected by the undoing of the connect() message.

3 Related Work Existing version control systems such as CVS [1] or Subversion [2] support undoing of entire models to any version but the granularity is typically to coarse grained to support selective undoing of individual model elements. Even a finer-grained version control system would not solve the problem because such systems are not able to automatically infer logical dependencies among model changes. Undo mechanisms as provided by most modeling tools are much more fine-grained than versioning systems. However, their change history is typically not persistent and the undoing is purely chronological, which causes the undo of intermittent changes which may not be related. Selective undoing requires exploring the different versions of model elements that have existed in the past. To that extent, our approach treats the model elements with versions as “variables” and tries to set them such that inconsistencies are minimized. The constraint satisfaction problem (CSP) [10] and MaxSAT are thus related to our approach. In CSP, a constraint-based problem comprises a set of variables and a set of constraints across the variables. Solution techniques (CST) are capable of computing feasible values for all variables for all constraints (i.e., versions that satisfy all the consistency rules). Indeed, our approach makes use of how CST eliminates infeasible choices but not how the remaining ones are validated. Our approach also borrows from existing optimizations such as the AC3 optimization [11] which maps choices to affected constraints to efficiently determine what part of a model to re-evaluate when it changes (i.e., change=undoing). Unfortunately, CSP typically does not scale, especially not for large software models. Truth maintenance systems (TMS) [4] focus on facts that make constraints hold. This is similar to our approach where logical dependencies among changes are captured to allow for an automatic recovery during undoing. TMS require the existence of the relations in advance which is not the case in our approach. The

Selective and Consistent Undoing of Model Changes

127

dependencies are recovered automatically by observing constraints during their evaluation. Also TMS require the impact of constraints to be modeled from all perspectives (all kinds of changes) which is traditionally not done for modeling languages and thus it would be impractical to apply TMS here. The approach by Mehra et al. [12] supports differencing and merging of visual diagrams. Semantic problems that arise during the merging process can be detected (which is similar to our approach) but not resolved automatically. Furthermore, our goal is not to fix inconsistencies during undoing that have existed in the past nor does it require doing so. Thus our work supports living with inconsistencies [3, 8].

4 What Is the Problem? 4.1 Definitions and Input As input, our approach requires a model and a change history. Our approach either computes the change history by comparing different model versions (offline or legacy models) or by monitoring the designer and recording the model changes (online). For undoing, a designer must select a Location (or set thereof) which is a field of a model element (ModelElementFields) and must choose an earlier version. For example, fields of a UML class include its name, owned operations, and attributes. A Version is thus a value for a Location (cf. Figure 2).

Fig. 2. A Location, its Current Value, and previous Values

The list of all available locations for undoing is thus the list of all fields of model elements in the model where the number of versions is greater than 1. An undo is simply the assignment of a Version to a Location (only one version can be assigned to a location at any given time) although different locations could be assigned different versions (the following uses a syntax similar to OCL). Location ∈ ModelEleme ntFields

Locations := ModelEleme ntFields → select (l : Location | l.versions → size () > 1)

4.2 User Actions and Impact The user initiates the undoing by selecting one or more locations and versions. For example, in the video-on-demand illustration in Section 2, the user chooses to restore the connect() message. The approach automatically creates, modifies, or deletes the model element(s) selected for undoing. If the model element was deleted then undoing must re-create it and modify it to reflect the desired version (i.e., all its fields must be set in addition to creating the model element). If the element still exists then

128

I. Groher and A. Egyed

it must be modified or deleted. For undoing the connect message, we need to re-create the message, name it connect, and restore its other fields (e.g., including the ones that map it to a specific location in the sequence diagram). The undoing changes the model, which, in turn, affect the consistency of the model. User-induced undoing thus may cause inconsistencies because: 1. Incomplete undos: Caused by an incomplete selection of locations and versions. Additional locations need to be undone to solve the inconsistencies and the user needs to be given choices on what else to undo also. 2. Incompatible undos: The user selected locations and versions are incompatible. In this case the inconsistencies cannot be resolved and the user needs to be notified of the incompatibility. Existing technologies for consistency checking [5] are able to identify inconsistencies caused during undoing. But consistency checking alone is not the solution to the problem. We also need to identify which combinations of other undoing resolves the inconsistencies. 4.3 Naïve but Unscalable Solution To solve the problem we could automatically try other undos to see whether they resolve the inconsistencies caused by the user-initiated undoing. The tricky part is to find some combination of additional undos that resolve the inconsistencies caused by the user actions without causing new inconsistencies. A correct and simple solution would be to try all possible combinations of locations and their versions available in the change history (brute force solution). The computational complexity of such a brute force evaluation is unfortunately O(#C * #versions#locations) – exponential with the number of locations as the exponential factor and the number of versions as the exponential base. #C represents the total number of constraints imposed on the model. Table 2 illustrates the futility of the brute force approach on five, large UML models. # Snapshots shows the number of model snapshots we compared. # Changes shows the total number of model changes from version 1 to version n (note only those changes are included that are processed by the constraints included in this study). # Locations shows the number of locations the model consists of. # Combinations shows the number of combinations we would need to evaluate when using a naïve, brute force approach for selective undoing (AV#Changes where AV is the average number of versions per location that has changed). Table 2. Computational Complexity

caBIO Calendar UMS Flipper anonymous

# Snapshots 3 2 5 4 2

# Changes 101 73 98 55 104

# Locations 11,422 17,943 14,874 6,338 156,572

# Combinations 2.81101 2.073 3.1598 3.6955 2.0104

Selective and Consistent Undoing of Model Changes

129

The table shows that the number of combinations (# Combinations) is unmanageable regardless of model size. The next section presents our solution.

5 Undoing Model Changes In order to efficiently undo design changes we have to be able to: 1. detect inconsistencies caused during undoing quickly and 2. identify other model elements whose undoing resolve these inconsistencies Fortunately, part 1 was already solved by our previous work [5]. We use the Model/Analyzer approach for instant consistency checking to detect inconsistencies caused by the user-triggered undo. Part 2 (the automatic fixing of inconsistencies caused by exploring previous model element versions) is new and thus the focus of the remainder of this paper. As part 2 builds on top of part 1, we briefly summarize our solution to part 1 in the next section. 5.1 Part 1: Incremental Consistency Checking The Model/Analyzer approach [5] (previously known as UML/Analyzer) is capable of quickly and correctly evaluating the consistency of models after changes. This approach treats every evaluation of a constraint separately. It essentially instantiates a constraint as many times as there are model elements in the model that must be evaluated by that constraint. For example, constraint 1 in Table 1 must be evaluated 4 times for version 1 in Figure 1 – once for every message. The Model/Analyzer approach thus maintains 4 constraint instances (C1_selectVideo, C1_playPause, C1_connect, C1_stream). All 4 constraint instances are evaluated separately as they may differ in their findings (although all are currently consistent). To support incremental consistency checking, the approach monitors the behavior of the consistency checker to identify which model elements a constraint instance accesses during its evaluation. If one or more of these model elements change then the constraint instance must be re-evaluated. For example, constraint 1 in Table 1 compares message names and operation names. However, it does not randomly access operations and messages. Instead, the constraint starts at a predefined message and navigates the model to first identify the message receiver object (UML model element of type Lifeline), next accesses the class that this object instantiates, and finally accesses the operations of that class. The scope of the constraint is that a subset of ModelElementFields and consists of the message itself, its receiver, the receiver’s base class, and the operations of this class. On a concrete example (cf. Figure 1, version 1), the evaluation of the constraint instance C1_playPause accesses the message playPause() first, then navigates to the message’s receiver object display, its base class Display, and finally the methods selectVideo(), and playPause(). This list of model elements accessed during the evaluation of constraint instance C1_playPause is defined to be the scope of this constraint instance – it is observable automatically. Obviously, if the message name changes, the operation name changes, or certain other model elements part of the scope change, then the consistency is in jeopardy. In such a case, constraint C1_playPause is affected by the change and must

130

I. Groher and A. Egyed

be re-evaluated. The evaluation of other constraint instances have different (but often overlapping) scopes. Using the Model/Analyzer approach we can compute the constraint instances affected by a location. It is simply all constraint instances where the location is part of their scope. AffectedCo nstraints (l : Location ) := Constraint s → collect (c : Constraint | c.scope → includes (l ))

The changes caused during undoing thus trigger automated re-evaluations of all those constraints that contain the changed location(s). With the creation and deletion of model elements, constraints must also be re-instantiated or disposed of. This capability also existed and was discussed in [5, 6]. The undoing is complete if the changes triggered do not cause inconsistencies. On the other hand, if the undoing of model elements (i.e., the deletion, creation, or modification) causes inconsistencies then further undoing may be necessary. In the example, the undo of the message connect() to a version where it existed causes two inconsistencies because the Streamer class no longer contains the corresponding operation with the name connect(). Also, the statechart no longer contains a transition with the name connect(). The undoing thus violates two constraint instances of constraints 1 and 2 defined in Table 1 (it is important to observe here that with constraint instances we are in essence referring to the model elements in the scope and no longer to the types of model elements). Table 3 reveals that a constraint is problematic if it was consistent before the undoing but no longer is thereafter; or if the undoing causes the instantiation of a constraint that is then inconsistent. Both cases imply that the undoing may have been incomplete (i.e., other model elements may also need to be undone) or that the undoing may be composed of incompatible locations. This distinction is explored later. Table 3. Effects of Undoing Changes on Constraints

Before

Constraints consistent inconsistent disposed

Consistent no problem no problem no problem

After Inconsistent problem no problem problem

Disposed no problem no problem no problem

5.2 Part 2: Incremental Version Exploration If the undoing causes inconsistencies then our approach investigates these inconsistencies and attempts to fix them by exploring additional locations to undo that would resolve them (first individually, then combined). We initially presume that an inconsistency caused during undoing is caused due to incomplete undoing. Our approach thus searches for additional locations to undo such that they resolve the inconsistency at hand. If no such locations can be found then the inconsistency must have existed previously and thus cannot be resolved; or the user-selected undo included incompatible versions (only applies if the user selected two or more locations for undoing). Figure 3 presents a sketch of the algorithm. The approach first changes the userselected locations to the versions selected, The Model/Analyzer approach will identify

Selective and Consistent Undoing of Model Changes

131

all constraint instances (in the following denoted as constraints for brevity) affected by this change and also instantiate new constraints if so needed. The affectedConstraints collection includes all these constraints. The algorithm then iterates over all affected constraints, evaluates them one by one, and, if the consistency was affected, adds them to the inconsistencies collection. If inconsistencies is empty then the undoing is complete. For all inconsistent constraints, additional undoing is necessary to fix them. In our example of undoing the connect message, the Model/Analyzer approach identifies the constraints C2_streamer and C1_connect as affected. C2_streamer refers to an existing constraint whereas C1_connect was instantiated because the connect message was re-created. Both constraints are inconsistent after undoing and both constraints needed to be investigated further to identify additional locations for undoing. undoSelectedVersions (selectedVersions) for all selectedVersions affectedConstraints = change(selectedVersions) for all constraint:affectedConstraints if (not validate(constraint)) inconsistencies.add(constraint) end if (inconsistencies.size>0) undoAdditionalVersions(inconsistencies) undoAdditionalVersions (inconsistentConstraints) for all constraint:inconsistentConstraints locations = validate(constraint) for all additionalVersions: locations x versions change (additionalVersions) if (validate(constrain)) validAssignment=additionalVersions end end end affectedConstraints = IntersectionValidAssignments (validAssignments) if (affectedConstraints.size>0) undoAdditionalVersions(affectedConstraints)

Fig. 3. Undoing Selected Versions

In [6] we showed how to narrow down the search for fixing inconsistencies. In essence, an inconsistency can be fixed only by changing one or more model elements that the inconsistent constraint accessed during its evaluation. We already identified this list of accessed elements as the scope of a constraint (recall Section 2). To fix inconsistency C1, we would have to change one or more of these scope elements. However, only those scope elements can be changed for which we have alternative versions available. Locations (c : Constraint ) := Locations ∩ c.scope

The locations for fixing an inconsistency caused during undoing are simply the intersection of all valid locations (=model elements for which multiple versions are available) and the scope elements for that constraint. The undoAdditionalVersions algorithm explores this. The algorithm iterates over all inconsistent constraints (in the first run those are the ones identified in the undoSelectedVersions function in Figure 3) and identifies which locations the constraint accesses during its evaluation The algorithm then explores the cross product of all possible fixes for each

132

I. Groher and A. Egyed

inconsistent constraint. That is, the algorithm tries all combinations of model versions for this subset of locations only. An Assignment for a Constraint is one such exploration where we have to set a Version for every Location encountered by that constraint (excluding the user-selected versions which are fixed). Assignment(c : Constraint) := Locations(c) → collect(l : Location| random(l.versions→ value))

A constraint exploration is then simply the function of an assignment onto a truthvalue such that the truth value reflects the consistency of the constraint for the given assignment. A valid assignment is defined as an assignment where the constraint evaluates to true. ValidAssignment(c : Constraint , a ∈ Assignment(c)) := Evaluation(c, a ) = true

The ValidAssignments (if size>0) represents additional undos (=model changes) to fix the inconsistencies caused by the initially user-selected undoing. A ripple effect. refers to the situation where the additional undos may, in turn, affect additional constraints. In other words, the inconsistencies caused by the user-selected undoing can only be resolved by undoing additional model element, which in turn, may cause more inconsistencies with respect to their affected constraints. This ripple effect is recursive and terminates only once no more inconsistencies are caused. All valid assignments that contain versions that differ from the last version require additional undos. The set of affected constraints thus needs to be incrementally expanded. The last lines of the undoAdditionalVersions function selects the assignments consistent with all affected constraints, determines which constraints are affected by these assignments, and then computes the ripple effect via recursive descend. The recursive descend terminates when no more inconsistencies are encountered. Figure 4 illustrates how versions and constraints are incrementally explored for the example introduced in Section 2. The user chose to undo the connect message. Two constraints are initially affected (the instantiated constraint C1_connect and the existing constraint C2_streamer) because both evaluate to false and thus need further undoing. During evaluation of C1_connect and C2_streamer new locations are incrementally instantiated (with all their versions as choices). For C1_connect, there is one such location only: base[operations]. Note that in Figure 4, only the locations that have versions are displayed. Both versions available for base[operations] are thus explored and constraint C1_connect is evaluated separately for each one. The assignment {stream, wait, connect} is valid because it contains the missing operation connect. The assignment {stream, wait} is not valid as it misses that method. The list of valid assignments for constraint C1_connect thus contains {stream, wait, connect}. Because the chosen valid assignment contains an older version of the location base[operations], we now need to investigate which constraints are affected by the change of this location (this is no longer a user-selected location and thus the initially computed list of affected constraints is no longer complete). Two additional constraints are affected: both C1_wait and C1_stream contain this base[operations] in their respective scopes and both need to be evaluated now also. Both were consistent before the undoing of base[operations] and after re-evaluating them, we find that both a still consistent. This means that the undoing of base[operations] did not negatively impact these additional constraints and no further undoing is required. The recursion stops here. If they would have been inconsistent then we would have had to try the versions of all locations in scope of C1_wait and C1_stream.

Selective and Consistent Undoing of Model Changes

133

C1_wait (C)

base[operations] stream, wait stream, wait, connect

C1_connect (0 -> I)

C1_stream (C)

transition[name] connect

message connect waiting[outgoings]

stream C2_streamer (C -> I)

stream, wait streaming[outgoings] wait wait, stream

Fig. 4. Incremental Version and Constraint Exploration

Thus far, we only dealt with one of the two initially affected constraints. The other initially affected constraint was C2_streamer which must be explored next. In its scope are not one but three locations for undoing. Each location in Figure 4 is indicated as a triangle and each location has two versions. There are thus 23=8 possible assignments and constraint C2_streamer is explored for all of them. Of these eight assignments, four are valid assignments ({connect, stream, wait}, {connect, stream, wait-stream}, {connect, stream-wait, wait}, {connect, stream-wait, waitstream}). So, we have several options here. The value of the location transition [name] needs to be set to connect. The locations waiting[outgoings] and streaming[outgoings] both have 2 correct choices. Since our goal is minimal undoing, we prefer to choose the latest versions if we have multiple valid choices. The latest versions of the two locations (the assignment with the cumulative least amount of undoing) are selected ({stream, wait} and {wait, stream}). A detailed description of how assignments are selected is given in the next section. No further constraint is affected by those locations. The resulting model after all undos corresponds to the right of Figure 1.

6 Selective Undo with the IBM Rational Software Modeler Tool Our approach is fully tool supported and integrated with IBM Rational Software Modeler (RSM) design tool and our Model/Analyzer consistency checking tool. The consistency checker receives change notifications from RSM and implements the instant consistency checking and fixing of inconsistencies as described in [5-7]. The consistency rules are written in Java and OCL. The tool also supports the computation of change histories for legacy models as wells as the recording of finegrained change histories.

7 Validation This section demonstrates that our approach scales - even for models with tens of thousands of elements. We empirically validated our approach on five versioned,

134

I. Groher and A. Egyed

third-party UML models and 22 types of consistency and well-formedness rules taken from literature. Table 2 already listed the models which differ substantially in model size and types of model elements used. 7.1 Computational Complexity The total number of possible assignments for a constraint is the cross-product of all versions for all locations encountered by that constraint. The computational complexity of such an exploration is O(AC * #versions#locations) – or exponential with the number of locations as the exponential factor and the number of versions as the exponential base. AC represents the number of constraints affected by an undo. While exponential growth is daunting in general, we will demonstrate next through extensive empirical evidence, that in context of single constraint instances, both #versions and #locations are very small and do not increase with the model size.

Fig. 5. Average Number of Versions per Location

7.2 Scalability Drivers We measured the number of locations (#locations) of over 140.000 constraint instances [5] across all five models. There exist a wide range of values between the minimum and maximum number of locations but the averages stayed constant with the size of the model. Over 95% of all 140.000 constraint instances evaluated less or equal than 25 model elements which is an important scalability factor because it implies that the exponential factor is a constant. It is also important how many constraints are affected by an undo (AC). In [5] we computed the number of constraints affected by a single change. We again found a wide range of values between the smallest and largest number of constraints but the average also stayed constant with the model size. Our evaluations showed that in average only 1-10 constraints had to be evaluated. Now that we have seen that both the number of locations (#locations) and the number of affected constraints (AC) are small values that stay constant with the size of the model, we need to look at the remaining scalability factor #versions: the number of versions per location. Figure 5 depicts the average number of versions per location for all five models which also appears to stay constant with the size of the

Selective and Consistent Undoing of Model Changes

135

model with 1.09 versions per location. Indeed, the likelihood for a location to have versions decreases exponentially with the number of versions (data omitted for brevity). So, while the evaluation of a constraint is exponentially complex within its locations and versions, the fact that all exponential factors are small and do not increase with the size of the model implies that our approach scales. There is however another potential scalability problem: the incremental exploration of affected constraints. Our approach only investigates constraints if they directly relate to changes caused by undos. If an undo causes inconsistencies then further changes are necessary which may uncover additional, affected constraints. The exploration, which we referred to as the ripple effect, may in theory snowball into a very large number of incrementally affected constraints where, perhaps, the exploration of individual constraints is scalable but not the ripple effect. In Figure 6, we thus empirically evaluated the average impact of the ripple effect on all five models. We found that the initial number of affected constraints was between 3 and 4.5 constraints, depending on model but that this number decreased in average with every ripple and always terminated before the 4 ripple (note: a ripple is a recursive descend where a change affects constraints which need to be changed which affects more constraints which…)

Fig. 6. Ripple Effect

7.3 Correctness Whenever inconsistencies were caused by the undoing of model changes, we also explored (in both a brute force manner as well as our approach) whether they were resolvable and could be resolved by our approach. We found in all cases that our approach was able to compute a consistent undo if such a consistency had existed in the past. Interestingly, our approach sometimes also resolved inconsistencies that had always existed. It is unclear to us whether this is a benefit or whether intentionally unresolved inconsistencies should remain so (i.e., living with inconsistencies). This feature could be disabled if needed. 7.4 Memory Consumption In [5] we found that there exists a linear relationship between the model size and the memory cost for storing the scopes. The memory cost rises linearly with the number

136

I. Groher and A. Egyed

of constraint instances and is O(#constraints * scope size). The storage of the change history is also manageable because only few model elements change. Since we have 1.09 versions per location, it follows that the memory cost for the change history is 1.09 times the model size plus overhead. 7.5 Threats to Validity As any empirical study, our exploratory experiments exhibit a number of threats to validity [15]. A threat to construct validity – are we measuring what we mean to measure? – is the potential that our validation may underrepresent the construct. We validated our approach on 5 large-scale, industrial models with tens of thousands of model elements and up to 5 versions. The models and their versions cover years of development and we thus believe that they represent typical undoing scenarios found in industry. The threat to internal validity – are the results due solely to our manipulations – is selection, in particular the selection of the models and the consistency rules. The models are different in size and domain and our approach performed well in all models. Also, the 22 selected consistency rules are covering nearly a complete set of dependencies between UML class diagrams, sequence diagrams, and state charts. Regarding conclusion validity we have seen that our approach scales for large models up to 150.000 locations. With respect to external validity – can we generalize the results – we took real-world large models representing realistic application contexts. Our empirical validation does not definitively proof that more versions are possible per model elements but it does confirm that most model elements never change (these models and their versions cover years of development). Even if the actual number of versions is higher, it is not a problem because, in general, few model elements change. However, one could argue that when using versioned models, we do not always see all changes because a location may change multiple times between versioned model snapshots. Yet, the versions we used represent major milestones of the system under development and missing intermediate versions, if they did exist, are likely less interesting results or else they likely would have been version controlled. The biggest threat to external validity, however, is that we did not yet assess the usability of our approach by monitoring and interviewing engineers that used our tool. This is part of our future work. We plan to evaluate how difficult it is for users to manually fix inconsistencies introduced during selective backtracking compared to using our tool.

8 Conclusion This paper discussed an approach for the selective undoing of design changes. Designers can explore earlier alternatives concurrently and undo them independently if needed. This is also beneficial if multiple designers are working on the same model and want to undo changes without necessarily undoing other designer’s changes. Selective undoing of changes is a difficult problem because of the complex, logical dependencies among design changes. We solved this problem by automatically discovering dependencies among versions of model elements through the help of consistency rules. We demonstrated on five case studies that our approach scales and

Selective and Consistent Undoing of Model Changes

137

produces correct results. Our approach does not require a consistent model as input. Neither is it limited to certain constraints only. Acknowledgments. We like to thank Alexander Reder for his help on the tool. This research was funded by the Austrian FWF under agreement P21321-N15.

References [1] Concurrent Versions System (2009), http://www.nongnu.org/cvs/ [2] Subversion (2009), http://subversion.tigris.org/ [3] Balzer, R.: Tolerating Inconsistency. In: Proceedings of 13th International Conference on Software Engineering (ICSE), pp. 158–165 (1991) [4] Doyle, J.: A Truth Maintenance System. Artificial Intelligence 12, 231–272 (1979) [5] Egyed, A.: Instant Consistency Checking for the UML. In: Proc. of the 28th Intern. Conf. on Software Engineering, Shanghai, China, pp. 381–390 (2006) [6] Egyed, A.: Fixing Inconsistencies in UML Design Models. In: Proceedings of the 29th International Conference on Software Eng., pp. 292–301 (2007) [7] Egyed, A., Wile, D.S.: Support for Managing Design-Time Decisions. IEEE Transactions on Software Engineering 32, 299–314 (2006) [8] Fickas, S., Feather, M., Kramer, J.: Proceedings of ICSE 1997 Workshop on Living with Inconsistency, Boston, USA (1997) [9] Gall, H.: Of Changes and their History: Some Ideas for Future IDEs. In: Proc. of 15th Working Conf. on Reverse Eng., Antwerp, Belgium, p. 3 (2008) [10] Henteryck, P.: Strategic Directions in Constraint Programming. ACM Computing Surveys 28 (1996) [11] Mackworth, A.K.: Consistency in Networks of Relations. Journal of Artificial Intelligence 8, 99–118 (1977) [12] Mehra, A., Grundy, J., Hosking, J.: A Generic Approach to Supporting Diagram Differencing and Merging for Collaborative Design. In: Proceedings of the 20th International Conference on Automated Software Engineering (ASE), Long Beach, CA, pp. 204–213 (2005) [13] Robbes, R., Lanza, M.: A Change-based Approach to Software Evolution. Electron. Notes Theor. Comput. Sci. 166, 93–109 (2007) [14] Tarr, P., Osher, H., Harrison, W., Sutton Jr., S.M.: N Degrees of Separation: MultiDimensional Separation of Concerns. In: Proceedings of the 21st International Conference on Software Eng., pp. 107–119 (1999) [15] Wohlin, C., Runeson, P., Höst, M., Ohlsson, M.C., Regnell, B., Wesslén, A.: Experimentation in Software Engineering: An Introduction. Kluwer Academic Publishers, Dordrecht (2000)

Modeling Features at Runtime Marcus Denker1 , Jorge Ressia2 , Orla Greevy3 , and Oscar Nierstrasz2 1

INRIA Lille Nord Europe - CNRS UMR 8022 - University of Lille (USTL) http://rmod.lille.inria.fr 2 Software Composition Group, University of Bern, Switzerland http://scg.unibe.ch 3 Sw-eng. Software Engineering GmbH Berne, Switzerland http://www.sw-eng.ch

Abstract. A feature represents a functional requirement fulfilled by a system. Since many maintenance tasks are expressed in terms of features, it is important to establish the correspondence between a feature and its implementation in source code. Traditional approaches to establish this correspondence exercise features to generate a trace of runtime events, which is then processed by post-mortem analysis. These approaches typically generate large amounts of data to analyze. Due to their static nature, these approaches do not support incremental and interactive analysis of features. We propose a radically different approach called live feature analysis, which provides a model at runtime of features. Our approach analyzes features on a running system and also makes it possible to “grow” feature representations by exercising different scenarios of the same feature, and identifies execution elements even to the sub-method level. We describe how live feature analysis is implemented effectively by annotating structural representations of code based on abstract syntax trees. We illustrate our live analysis with a case study where we achieve a more complete feature representation by exercising and merging variants of feature behavior and demonstrate the efficiency or our technique with benchmarks. Keywords: models at runtime, behavioral reflection, feature annotations, dynamic analysis, feature analysis, software maintenance, feature growing.

1

Introduction

Many researchers have recognized the importance of centering reverse engineering activities around a system’s behavior, in particular, around features [8,15,22]. Bugs and change requests are usually expressed in terms of a system’s features, thus knowledge of a system’s features is particularly useful for maintenance [17]. This paper presents a novel technique to perform fine-grained feature analysis incrementally at runtime, while minimizing adverse effects to system performance. For an in-depth discussion about features and feature analysis in general, we refer the reader to our earlier publications [10, 11, 12]. D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 138–152, 2010. © Springer-Verlag Berlin Heidelberg 2010

Modeling Features at Runtime

139

Features are abstract notions, normally not explicitly represented in source code or elsewhere in the system. Therefore, to leverage feature information, we need to perform feature analysis to establish which portions of source code implements a particular feature. Most existing feature analysis approaches [22, 15] capture traces of method events that occur while exercising a feature and subsequently perform post-mortem analysis on the resulting feature traces. A post-mortem feature analysis implies a level of indirection from a running system. This makes it more difficult to correlate features and the relevant parts of a running system. We lose the advantage of interactive, immediate feedback which we would obtain by directly observing the effects of exercising a feature. Post-mortem analysis does not exploit the implicit knowledge of a user performing acceptance testing. Certain subtleties are often only communicated to the system developer when the user experiences how the system works while exercising the features. Clearly, in this case, a model-at-runtime of features, with the added ability to “grow” the feature representation as the user exercises variants of the same feature offers advantages of context and comprehension over a one-off capture of a feature representation and post-mortem analysis. We propose an approach which we call live feature analysis. Essentially, our technique is to annotate the structural representation of the source code based on Abstract Syntax Trees (ASTs). We build up a model of the features over time, as variants of feature behavior are being exercised. Our feature representation is thus immediately available for analysis in the context of the running system. The goal of this paper is to highlight the advantages of using a runtime model of feature over a static, post-mortem feature representation. Live feature analysis addresses various shortcomings of traditional post-mortem approaches: – Data volume. By tracking features in terms of structured objects rather than linear traces, the volume of data produced while exercising features is constant with respect to the number of source code entities. Data produced by traditional feature analysis approaches is proportional to the execution events of the source code entities, thus higher. Different strategies to deal with large amounts of data have been proposed, for example: (1) summarization through metrics [7], (2) filtering and clustering techniques [13, 26], (3) visualization [2,12] (4) selective instrumentation and (5) query-based approaches [19]. The net effect of applying these strategies however, is loss of information of a feature’s behavior in the feature representation to be analyzed. – Feature growing. Variants of the same feature can be exercised iteratively and incrementally, thus allowing the analysis representation of a feature to “grow” within the development environment. The problems of tracing at sub-method granularity are performance and large amount of gathered data. Traditional approaches deliver a tree of execution events which are hard to manipulate. Our technique delivers a set of source code entities on top of which any logical operation can be applied. – Sub-method feature analysis. Many feature analysis techniques are restricted to the level of methods. Our technique allows us to dive into the structure

140

M. Denker et al.

of more complex methods to see which branches are dedicated to particular features. The fine-grained sub-method information is particularly relevant when “growing” features as it is typically at this level that variations in the execution paths occur. – Interactive feature analysis. Traditional feature analysis approaches perform a post-mortem analysis on the trace data gathered at runtime to correlate feature information with the relevant parts of the source code. Any changes in the source code will require the data gathering and the post-mortem analysis to be run again to refresh the feature data. The essential drawback of the post-mortem approach is due to its static, snapshot representation of a feature, limited to data captured during only one path of execution. Postmortem analysis is incompatible with an interactive exploration of features as it is typically disconnected from the running application. With traditional feature analysis approaches the feature information only becomes available after the features of the application have been exercised and a post-mortem analysis has been performed. The key contributions of this paper are: 1. We describe our live feature analysis approach based on partial behavioral reflection and AST annotation; 2. we show how this technique supports feature analysis at sub-method granularity; 3. we describe how to iteratively and incrementally grow feature analysis using our technique; and 4. we demonstrate the advantages of using a runtime model of features. We previously proposed the notion of using sub-method reflection in the context of feature tagging in a workshop paper [6]. In this paper, we expand on this idea to focus on its application to runtime feature analysis (live feature analysis). We present our working implementation and validate our technique by applying it to the analysis of the features of a content-management system, Pier, as a case-study. In the next section, we provide a brief overview of unanticipated partial behavioral reflection, as it serves as a basis for our approach. We introduce our feature annotation mechanism and present the feature runtime model. Using the feature annotation and the runtime model we obtain the flexibility to grow feature representations incrementally. We validate our approach in Section 3 by means of a case study and detailed benchmarks. Section 4 outlines related work in the fields of dynamic analysis and feature identification. Finally, we conclude in Section 5 by outlining possible future work in this direction.

2

Live Feature Analysis with Partial Behavioral Reflection

To achieve live feature analysis, we need a means to directly access runtime information associated with features and at the same time minimize the negative impact of slowing down the running application under investigation due

Modeling Features at Runtime

141

to instrumentation. In a previous work [5] we proposed that Partial Behavioral Reflection as pioneered by Reflex [23] is particularly well-suited for dynamic analysis as it supports a highly selective means to specify where and when to analyze the dynamics of a system. Before explaining Partial Behavioral Reflection in more detail, we present a brief review of Structural Reflection and Behavioral Reflection. Structural reflection models the static structure of the system. Classes and methods are represented as objects and can both be read and manipulated from within the running system. In today’s object-oriented systems, structural reflection does not extend beyond the granularity of the method: a method is an object, but the operations the method contains, such as method invocations, variable reads and assignments, are not modeled as objects. To overcome this limitation we have extended Pharo Smalltalk1 to support sub-method structural reflection. More in-depth information about this system and its implementation can be found in the paper on sub-method reflection [4]. Behavioral reflection provides a way to intercept and change the execution of a program. It is concerned with execution events, i.e., method execution, message sends, or variable assignments. We developed a framework called Reflectivity [3], which leverages an extended AST representation provided by our sub-method structural reflection extension to realize behavioral reflection. Prior to execution, the AST is compiled on demand to a low-level representation that is executable, for example to bytecodes executable by a virtual machine. Partial behavioral reflection offers an even more flexible approach than pure Behavioral Reflection. The key advantage is that it provides a means to selectively trigger reflection, only when specific, predefined events of interest occur. The core concept of the Reflex model of partial behavioral reflection is the link (see Figure 1). A link sends messages to a meta object upon occurrences of marked operations. The attributes of a link enable further control of the exact message to be sent to the meta-object. Furthermore, an activation condition can be defined for a link which determines whether or not the link is actually triggered. Links are associated with nodes from the AST. Subsequently, the system automatically generates new bytecode that takes the link into consideration the next time the method is executed. Reflectivity was conceived as an extension of the Reflex model of Partial Behavioral Reflection [23]. Reflex was originally realized with Java. Therefore, our approach can in be implemented in a more static mainstream language like Java. The reason for choosing Smalltalk and Reflectivity for this work is that it supports unanticipated use of reflection at runtime [3] and is integrated with an AST based reflective code model [4]. A Java solution would likely be more static in nature: links cannot be removed completely (as code cannot be changed at runtime) and the code model would not be as closely integrated with the runtime of the language. 1

http://pharo-project.org/

142

M. Denker et al. meta-object links

activation condition source code (AST)

Fig. 1. The reflex model

2.1

Dynamic Analysis with Reflectivity

A trace-based feature analysis can be implemented easily using partial behavioral reflection. In a standard trace-based feature analysis approach, a tracer is the object responsible for recording a feature trace of method invocations. With our partial behavioral reflection approach, we define the tracer as the meta-object (as shown in Figure 2). We define a link to pass the desired information for feature representation (e.g., the name and class of the executed method) as a parameter to a meta-object. The link then is installed on the part of the system that we want to analyze. This means that the link is associated with the elements of the system that we are interested in. Subsequently, when we exercise a feature and our tracer meta-object will record a trace. tracer metaobject link source code (AST)

Fig. 2. A tracer realized with partial behavioral reflection

The resulting system is similar to existing trace-based systems, but with one key advantage: the scope of tracing can now easily be extended to cover submethod elements of the execution, if required. 2.2

Feature Annotation

In contrast to typical dynamic feature analysis approaches, our reflection-based approach does not need to retain a large trace of executed data. This is because our analysis is live rather than post-mortem. Our technique focuses on exploiting feature knowledge directly while the system is running. With the annotatable representation provided by sub-method reflection, our analysis can annotate every statement that participates in the behavior of a feature. So instead of recording traces, the analysis tags with a feature annotation all the

Modeling Features at Runtime

143

feature tagger metaobject tags node with feature annotation on execution

link

source code (AST)

Fig. 3. The nodes are tagged at runtime with feature information

AST nodes that are executed as a result of invoking features at runtime. To achieve this, we define a link to call our FeatureTagger meta-object, as shown in Figure 3. Subsequently, we install this link on all the AST nodes of the system that we plan to analyze. When a feature is exercised, different AST nodes (method, instructions, assignments, etc.) linked to the FeatureTagger meta-object are executed. This meta-object is executed as well and each executed node is annotated stating that this node belongs to a specific feature. Due to tagging we no longer need to retain large traces. Thus our approach results in less data to be managed and analyzed (see Section 3). Information about multiple executions of the same methods or order of execution can be efficiently stored in the annotation. 2.3

Model-at-Runtime

In Figure 4 we can see the runtime feature model on top of the structural representation of the language. The Feature abstraction is used for annotating which parts of the AST belongs to a feature. Multiple features can be attached to a single AST node providing a way of specifying that this node belongs to several features. Since the user or developer has the implicit feature knowledge, he must specify which feature is going to be exercised. The activeFeature in the class RuntimeFeatureAnalyzer models this. This feature is used for annotating the AST nodes. If no feature is specified no annotation will occur.

1 RuntimeFeatureAnalyzer activeFeature packages 1

0..* 1 Class

1

1

Feature 1

0..*

ASTNode

1

0..*

Fig. 4. Feature runtime model

1 Annotation

0..*

144

M. Denker et al.

The RuntimeFeatureAnalyzer is also responsible for adapting the AST nodes. The user has to specify over which nodes he would like to perform the feature analysis. At present we offer the possibility to specify which packages should be adapted, but any AST granularity could be used. All the classes, methods and AST nodes of the specified packages will be adapted. New nodes or packages could be added at any point due to new development being carried out. The link installed in the AST nodes specifies that whenever the node is executed the same node has to be annotated with the activeFeature specified in the RuntimeFeatureAnalyzer. This information is immediately available for the different development tools, like the code browser or the debugger. Performance is a major consideration when performing dynamic analysis. To minimize adverse effects on performance, our goal is therefore to limit both where and when we apply behavioral reflection. The where can be controlled by installing the link only on those places in the system that we are interested in analyzing. For the when, we leverage the fact that we can directly uninstall links at runtime from the meta-object. The RuntimeFeatureAnalyzer takes care of removing the links when there is no active feature. 2.4

Growing Features

Our feature annotation analysis can easily support many existing feature analysis techniques. For example, we could exercise a feature multiple times with different parameters to obtain multiple paths of execution. This can be important, as the number of traces obtained can be considerable depending on the input data. For trace-based approaches this results in multiple traces being recorded. One feature is represented by multiple traces and therefore it is needed to manage a many-to-one mapping between features and traces. Using our approach, if the execution path differs over multiple runs, newly executed instructions will be tagged in addition to those already tagged. Thus we can use our approach to iteratively build up the representation of a feature covering multiple paths of execution. 2.5

Towards Optional Tracing

Instead of multiple runs resulting in one feature annotation, the feature annotations can be parameterized with the number of executions that are the result of exercising the feature. Our approach also accommodates capturing instance information or feature dependencies as described in the approaches of Salah et al. [22] and Lienhard et al. [16]. Naturally, the more information that is gathered at runtime, the more memory that is required. In the worst case, recording everything would result in recording the same amount of information as a complete trace of fine-grained behavioral information. The execution cost will also be higher due to the inserted code of the behavioral reflection technique. One major disadvantage when adopting filtering strategies to reduce the amount of data gathered at runtime is the loss of dynamic information that may have been relevant for the analysis. Thus it is crucial to define which information is necessary when performing a feature analysis. A change in a selection

Modeling Features at Runtime

145

strategy implies a need to exercise a feature again. In contrast to filtered traces, analysis approaches based on complete traces provide the flexibility to perform a variety of post-mortem analyses of feature traces, where each analysis focuses on a different level of detail. For example one analysis may choose to focus on the core application code and filtering out library code, whereas another analysis would choose to home in on the use of library code by a feature. With our approach we can extend feature annotation gradually. Instead of uninstalling the tagger meta-object after the first execution, we can use it to gather an invocation count. This approach would be useful for building so-called feature heat maps i.e., visualizations that show how often a part of the system (i.e., a specific node) takes part in a feature [21]. Even adding optional support for recording full traces can be interesting: the node can reference the trace events directly, providing an interesting data-structure for advanced trace analysis.

3

Validation

We present the feature analysis experiment we performed to highlight the difference between the amount of data gathered with a trace-based approach and the annotation based approach. Our experiment was performed using a mediumsized software system of approximately 200 classes, a content-management system (CMS) Pier, which also encompasses Wiki functionality [18] as a case-study. For our experiment we selected a set of Pier features similar to those chosen for a previous post-mortem experiment (login, edit page, remove page, save page) with the same case study [9] In this paper, we illustrate the application of our analysis technique on the login feature. 3.1

Case Study: The Pier CMS

We apply our live feature analysis to show some empirical results on an example feature of the Pier CMS. We chose the login feature as it is easy to explain the concept of growing a feature as a result of exercising variants of feature behavior. When exercising a login feature, different behavior is invoked when a user enters a correct username and password, as opposed to when incorrect information is entered and an error message is displayed. Our first execution scenario of our experiment expresses when the username and password are entered correctly and the user successfully logs into the system. Variants of execution behaviors are: (i) (ii) (iii) (iv) 3.2

no information is entered and the user presses login, only the username is entered, only the password is entered, an invalid username or password is entered. Live Analysis

In the first column of Table 1 we can see the results of applying sub-method feature analysis to the login feature. For the different possible input combinations we obtain different numbers of annotated AST nodes. This reveals that

146

M. Denker et al.

Table 1. Number of annotations with features exercised individually, and with feature growing Individual features Feature growing (i) Empty username and password (ii) Only username (iii) Only password (iv) Valid username and password

1668 1749 1668 2079

1668 1749 1749 2126

different parts of the code inside the methods, namely sub-method elements, are being executed. We can also see that when no username is provided, case (i) and case (iii), the number of nodes associated to the feature is the same. One possible explanation for this is that a validation is performed whether or not the username is valid before dealing with the password. We presented our results to the developer of the application who verified our findings. 3.3

Growing Features

One of the key characteristics of our technique is the ability to grow feature representation over multiple executions, thus achieving a more complete analysis of the feature under consideration. By taking into account all possible execution paths of a particular feature from the user’s perspective, we increase the precision of our dynamic analysis approach. It is possible to achieve the same feature coverage with a classical post-mortem feature analysis by gathering the data at the end of each run and then by merging this data into one representation of a feature. The advantage of our approach is that it exploits an exploratory analysis that is both iterative and interactive. It benefits from immediate feedback and direct access to growing feature representation, as different scenarios are executed and different code fragments (i.e., methods, branches and variable accesses) are highlighted as belonging to the current feature under analysis. Considering the CMS login feature of our Pier case study, we grow our representation of our login feature without interrupting the dynamic session to perform offline, post-mortem analysis. We simply exercise different variants of behaviors, while our technique builds up the feature representation. In the second column of Table 1 we illustrate how our login feature grows. The different behavioral variants were tested in the same order as presented in the table. In case (iii) we see that in fact no new parts of the code were executed for this variant as case (iii) is in fact contained in case (i). And finally for case (iv) the number of annotations is higher than the regular analysis since we are keeping the annotations for the code of all possible paths. An important aspect of our technique is that the entire live feature analysis can be performed at runtime and that there is no need to interrupt a system under analysis to access the feature representation information. This is a key advantage over traditional techniques as it is not always possible to interrupt production systems to gather information about malfunctioning features.

Modeling Features at Runtime

3.4

147

Benchmarks

Performance is critical for the practical application of any runtime analysis technique. A key characteristic of our live feature analysis approach is that we can uninstall the trace code (the links) at runtime as soon as possible to avoid a long term adverse effect on performance of the system under analysis. We have carried out a benchmark to test our hypothesis that uninstalling links at runtime actually improves performance. We take advantage of the extensive test-suite of Pier to generate a substantial amount of runtime data. We install our feature annotation system on all the Pier classes in the package Pier (179 classes, 1292 methods, i.e., not considering library classes). Subsequently, we performed our live feature analysis with three different annotation scenarios: – No feature annotation. We execute the unit tests without feature annotation installed as the base case. – Feature annotation removed. Feature tagging is enabled and the link is removed immediately after setting the annotation on the node. – Feature annotation retained. To perform this scenario, we use a modified version of our feature tagging code where the link is not removed. We ran the unit tests of Pier three times (see Table 2) for each of the scenarios (run1, run2 and run3 show the results for each run).2 Our results demonstrate that uninstalling the link improves performance, despite the fact that in this case the bytecode needs to be regenerated for all the methods where links are removed. This is shown in the time difference between run2 and run3: the second time the code has to be recompiled without the link and the third time it is executed normally. Table 2. Performance of annotation – three runs run1 (msecs) run2 (msecs) run3 (msecs) No feature annotation Feature annotation removed Feature annotation retained

680 34115 38584

667 2344 13067

637 649 10920

Removing feature tagging once the feature annotation has been performed delivers a zero penalty after the third execution due to dynamic recompilation of code. However, keeping the feature tagging enabled has a penalty of 16 times slower. But this negative impact is only perceived in the nodes that have been annotated. The rest of the system has no performance penalty. 3.5

Number of Events Generated

Our paper on sub-method reflection [4] discusses the memory properties of the AST model. In the context of live feature analysis, it is interesting to assess the 2

The benchmarks were performed on a MacBook Pro Core2Duo 2.4Ghz.

148

M. Denker et al.

difference in space required to annotate static structures by live feature analysis as opposed to that required to record traces in a postmortem approach. We compare the number of events generated in each case. To measure the size of a trace, we install a counter mechanism that records method invocations that are activated while exercising our example features. When we annotate features, the result are annotations on the static structure. Therefore, we count the resulting annotations. Our benchmarking was performed once again on the Pier case study. We annotate the entire Pier package. Table 3 shows the numbers of events and the number of annotations required for different features. Our results show that the number of dynamic events that a Tracer records is far higher than the resulting entities annotated with feature annotation. Table 3. Dynamic events compared to number of annotations Feature Display Page Call Page Editor Save Page Page Settings

Number of events Number of annotations Factor 24792 28553 41737 17709

1956 12.67 2348 12.16 3195 13.06 1879 9.42

Depending on the feature exercised our approach generates up to 13 times less data for representing the same information compared to a traditional approach.

4

Related Work

We review dynamic analysis system comprehension and feature identification approaches and discuss the similarities and shortcomings of these approaches in the context of our live feature analysis technique. Many approaches to dynamic analysis focus on the problem of tackling the large volume of data. Many of these works propose compression and summarization techniques to support the extraction of high level views [10, 14, 26]. Our technique is in effect also a summarization technique in that the annotation does not need to be repeated for multiple executions of the same parts of the code. However, our annotation can easily encompass information about number of executions of a mode in the code representation and also order of execution, so that the dynamic information is efficiently saved in a compressed form and would be expandable without loss of information on demand. Dynamic analysis approaches to feature identification have typically involved executing the features of a system and analyzing the resulting execution trace [1, 8, 24, 25]. Typically, the research effort of these works focuses on the underlying mechanisms used to locate features (e.g., static analysis, dynamic analysis, formal concept analysis, semantic analysis or approaches that combine two or more of these techniques).

Modeling Features at Runtime

149

Wilde and Scully pioneered the use of dynamic analysis to locate features [24]. They named their technique Software Reconnaissance. Their goal was to support programmers when they modify or extend functionality of legacy systems. Eisenbarth et al. described a semi-automatic feature identification technique which used a combination of dynamic analysis, static analysis of dependency graphs, and formal concept analysis to identify which parts of source code contribute to feature behavior [8]. For the dynamic analysis part of their approach, they extended the Software Reconnaissance approach to consider a set of features rather than one feature. They applied formal concept analysis to derive a correspondence between features and code. They used the information gained by formal concept analysis to guide a static analysis technique to identify featurespecific computational units (i.e., units of source code). Wong et al. base their analysis on the Software Reconnaissance approach and complement the relevancy metric by defining three new metrics to quantify the relationship between a source artifact and a feature [25]. Their focus is on measuring the closeness between a feature and a program component. All of these feature identification approaches collect traces of method events and use this data to locate the parts of source code that implement a feature. Feature identification analysis is thus based on manipulating and analyzing large traces. A key difference to our live feature analysis approach is that these dynamic analyses focus primarily on method execution, thus do not capture fine-grained details such as sub-method execution events such as conditional branching and variable access. This information may prove essential when focusing on a malfunctioning feature or on boundary conditions. A main limiting factor of extracting this level of detail is the amount of trace data that would result. The key advantage of our approach is that we eliminate the need to retain execution traces for post-mortem analysis, as we perform a more focused, live analysis and discard the information when it is no longer needed. Thus there is no limitation to annotating all events (methods and sub-methods) involved in a feature’s behavior. Furthermore, a key focus of feature identification techniques is to define measurements to quantify the relevancy of a source entity to a feature and to use the results for further static exploration of the code. These approaches do not explicitly express the relationship between behavioral data and source code entities. To extract high level views of dynamic data, we need to process the large traces. Other works [1, 9] identify the need to extract a model of behavioral data in the context of structural data of the source code. Subsequently feature analysis is performed on the model rather than on the source code itself.

5

Conclusions and Future Work

In this paper we have proposed a live feature analysis approach based on Partial Behavioral Reflection to address some of the limitations of traditional tracebased feature analysis approaches. This technique relates features to the running code, thus opening up a number of possibilities to exploit feature information

150

M. Denker et al.

interactively and in context of the running system. While running the application to assess a reported problem a feature representation is built up at the same time, which is available for analysis in the context of the running system. Our implementation of live feature analysis is based on the Reflectivity framework. We presented the implementation and applied our approach to a case-study that illustrates the usefulness and practicality of the idea, in particular from the point of view of growing features and obtaining fine-grained sub-method information in the feature representation. To summarize, we revisit the goals defined in Section 1: – Data volume reduction. Since feature information is recorded in live object structures, considerably less space is needed than with a post-mortem trace, which necessarily contains a great deal of redundant information. As an immediate side effect, the recorded information is easier to access and analyze. – Feature Growing. Variants of the same feature can be exercised iteratively and incrementally, thus allowing analysis of the feature to “grow” within the development environment. – Sub-method feature analysis. As shown in the validation section, feature analysis can be performed at sub-method level. This is of particular interest for long and complex methods. – Interactive feature analysis. Features are analyzed at runtime for selected parts of the application. Features can be analyzed on-demand, depending on the task at hand. The performance impact of our implementation is visible only at the first execution as we have shown that certain techniques can be introduced to attenuate this impact. Having feature annotations represented in the system at the statement level opens up many possibilities for visualizing fine-grained feature behavior and interaction between different features. We plan to explore the idea of visualizing feature interaction at a sub-method level with microprints [20]. Another interesting direction for future work is to experiment with advanced scoping mechanisms. We want to experiment with the idea of scoping dynamic analysis towards a feature instead of static entities like packages and classes. In addition, we plan to explore the notion of scoping feature analysis itself towards features, which leads to the notion of analyzing the dependencies between features. When analyzing which sub-method entity takes part in a feature, we up to now install the link very generously on all nodes of the AST. This is not needed as we only need to make sure that we put annotations at runtime on all nodes in the method where the control-flow diverges. In a second step, we can use static analysis to propagate the information down the tree. We plan to experiment with this scheme in the future. Acknowledgments. We gratefully acknowledge the financial support of the Swiss National Science Foundation for the projects “Bringing Models Closer to Code” (SNF

Modeling Features at Runtime

151

Project No. 200020-121594, Oct. 2008 - Sept. 2010) and “Biologically inspired Languages for Eternal Systems” (SNF Project No. PBBEP2-125605, Apr. 2009 - Dec. 2009) and CHOOSE, the Swiss Group for Object-Oriented Systems and Environments. We also thank Nicolas Anquetil and Lukas Renggli for their detailed reviews of drafts of this paper.

References 1. Antoniol, G., Guéhéneuc, Y.-G.: Feature identification: a novel approach and a case study. In: Proceedings of the IEEE International Conference on Software Maintenance (ICSM 2005), pp. 357–366. IEEE Computer Society Press, Los Alamitos (September 2005) 2. Cornelissen, B., Holten, D., Zaidman, A., Moonen, L., van Wijk, J.J., van Deursen, A.: Understanding execution traces using massive sequence and circular bundle views. In: Proceedings of the 15th International Conference on Program Comprehension (ICPC), pp. 49–58. IEEE Computer Society, Los Alamitos (2007) 3. Denker, M.: Sub-method Structural and Behavioral Reflection. PhD thesis, University of Bern (May 2008) 4. Denker, M., Ducasse, S., Lienhard, A., Marschall, P.: Sub-method reflection. In: Journal of Object Technology, Special Issue. Proceedings of TOOLS Europe 2007, vol. 6(9), pp. 231–251. ETH (October 2007) 5. Denker, M., Greevy, O., Lanza, M.: Higher abstractions for dynamic analysis. In: 2nd International Workshop on Program Comprehension through Dynamic Analysis (PCODA 2006), pp. 32–38 (2006) 6. Denker, M., Greevy, O., Nierstrasz, O.: Supporting feature analysis with runtime annotations. In: Proceedings of the 3rd International Workshop on Program Comprehension through Dynamic Analysis (PCODA 2007), pp. 29–33. Technische Universiteit Delft (2007) 7. Ducasse, S., Lanza, M., Bertuli, R.: High-level polymetric views of condensed runtime information. In: Proceedings of 8th European Conference on Software Maintenance and Reengineering (CSMR 2004), pp. 309–318. IEEE Computer Society Press, Los Alamitos (2004) 8. Eisenbarth, T., Koschke, R., Simon, D.: Locating features in source code. IEEE Computer 29(3), 210–224 (2003) 9. Greevy, O.: Enriching Reverse Engineering with Feature Analysis. PhD thesis, University of Bern (May 2007) 10. Greevy, O., Ducasse, S.: Correlating features and code using a compact two-sided trace analysis approach. In: Proceedings of 9th European Conference on Software Maintenance and Reengineering (CSMR 2005), pp. 314–323. IEEE Computer Society, Los Alamitos (2005) 11. Greevy, O., Ducasse, S., Gîrba, T.: Analyzing feature traces to incorporate the semantics of change in software evolution analysis. In: ICSM 2005, pp. 347–356. IEEE Computer Society, Los Alamitos (September 2005) 12. Greevy, O., Ducasse, S., Gîrba, T.: Analyzing software evolution through feature views. Journal of Software Maintenance and Evolution: Research and Practice (JSME) 18(6), 425–456 (2006) 13. Hamou-Lhadj, A., Lethbridge, T.: A survey of trace exploration tools and techniques. In: CASON 2004, Indianapolis IN, pp. 42–55. IBM Press (2004)

152

M. Denker et al.

14. Hamou-Lhadj, A., Lethbridge, T.: Summarizing the content of large traces to facilitate the understanding of the behaviour of a software system. In: ICPC 2006, Washington, DC, USA, pp. 181–190. IEEE Computer Society, Los Alamitos (2006) 15. Kothari, J., Denton, T., Mancoridis, S., Shokoufandeh, A.: On computing the canonical features of software systems. In: WCRE 2006 (October 2006) 16. Lienhard, A., Greevy, O., Nierstrasz, O.: Tracking objects to detect feature dependencies. In: ICPC 2007, Washington, DC, USA, pp. 59–68. IEEE Computer Society, Los Alamitos (June 2007) 17. Mehta, A., Heineman, G.: Evolving legacy systems features using regression test cases and components. In: Proceedings ACM International Workshop on Principles of Software Evolution, pp. 190–193. ACM Press, New York (2002) 18. Renggli, L.: Magritte — meta-described web application development. Master’s thesis, University of Bern (June 2006) 19. Richner, T., Ducasse, S.: Using dynamic information for the iterative recovery of collaborations and roles. In: ICSM 2002, p. 34. IEEE Computer Society, Los Alamitos (October 2002) 20. Robbes, R., Ducasse, S., Lanza, M.: Microprints: A pixel-based semantically rich visualization of methods. In: Proceedings of 13th International Smalltalk Conference, ISC 2005, pp. 131–157 (2005) 21. Röthlisberger, D., Nierstrasz, O., Ducasse, S., Pollet, D., Robbes, R.: Supporting task-oriented navigation in IDEs with configurable HeatMaps. In: ICPC 2009, pp. 253–257. IEEE Computer Society, Los Alamitos (2009) 22. Salah, M., Mancoridis, S.: A hierarchy of dynamic software views: from objectinteractions to feature-interacions. In: ICSM 2004, pp. 72–81. IEEE Computer Society Press, Los Alamitos (2004) 23. Tanter, É., Noyé, J., Caromel, D., Cointe, P.: Partial behavioral reflection: Spatial and temporal selection of reification. In: OOPSLA 2003, pp. 27–46 (November 2003) 24. Wilde, N., Scully, M.: Software reconnaisance: Mapping program features to code. Journal on Software Maintenance: Research and Practice 7(1), 49–62 (1995) 25. Wong, E., Gokhale, S., Horgan, J.: Quantifying the closeness between program components and features. Journal of Systems and Software 54(2), 87–98 (2000) 26. Zaidman, A., Demeyer, S.: Managing trace data volume through a heuristical clustering process based on event execution frequency. In: CSMR 2004, pp. 329–338. IEEE Computer Society Press, Los Alamitos (March 2004)

Metamodel-Based Information Integration at Industrial Scale Stefan Berger, Georg Grossmann, Markus Stumptner, and Michael Schrefl University of South Australia, Advanced Computing Research Centre , Adelaide SA 5095, Australia [email protected], {georg.grossmann,mst,mis}@cs.unisa.edu.au

Abstract. Flexible data integration has been an important IT research goal for decades. About ten years ago, a significant step was taken with the introduction of declarative methods (e.g., Clio). Since this work, mostly based on classic dependency analysis, extensions have been developed that express more powerful semantic relationships. However, much of this work has remained focused at the relational database (i.e., relatively low) level, and many of the extensions revert to specific algorithms and function specifications. At the same time, models have evolved to incorporate more powerful semantics (object or ontology-based methods). The work presented in the paper uses flexible metamodel-based mapping definitions that enable a model-driven engineering approach to integration, allowing declarative mapping specifications to be automatically executed at runtime within a single-formalism and single-tool framework. The paper reports how to create executable mappings for large-scale data integration scenarios with an interactive graphical tool. Keywords: General-purpose modeling languages, model-based development, tools and meta-tools.

1 Introduction Despite considerable progress made during the last decade, information integration remains a challenging task. Even when interoperability efforts were first codified in the 1980s with standards such as EDIFACT or STEP APIs, modeling of application data (in terms of record structures and relational database schemas) remained “too flexible”. This lead to a situation where two independently developed systems are likely to find their data structures mutually inconsistent and thus non-interoperable. Questions of low-level encoding and data types have become less of an issue with the rise of XML and its derivatives for data exchange, but the higher complexity resulting from increased modelling power has opened the gap even wider. Data and application integration is therefore an ever-present issue and capabilities in this space are forcefully advertised by major information architecture vendors. To be strict, much of their emphasis lies on 

This research was partially supported by the Australian Research Council (ARC) under grant DP0988961 and by the Cooperative Research Centre for Integrated Engineering Asset Management (CRC CIEAM) under projects SI302 and MD201.

D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 153–167, 2010. c Springer-Verlag Berlin Heidelberg 2010 

154

S. Berger et al.

data transformation and interchange rather than wholesale migration. Systems such as IBM Websphere or SAP Netweaver present an XML-syntax, SOA based interface to the world, but the structure and meaning of data still needs to be adjusted by developers ensuring that the right data structures are exchanged and transformed at the right time. Schema matching tools [16,11] are widely used in areas such as Extract-TransformLoad (ETL) in data warehousing, but still accommodate only a limited degree of heterogeneity. Manual mapping editors such as MapForce remain focused on direct schema comparisons with limited model heterogeneity. But, with the spread of Model-Driven Architecture and the limited take-up of ontology-based modelling methods, the expressiveness of mapping methods also must increase, e.g., by considering also the behavior of models [10]. In particular, more and more complex data models in practical use call for more powerful techniques to represent mappings between models. This suggests applying a Model-Driven Engineering approach for integration, where powerful models are employed to establish a mapping that is executable on various target platforms. In this paper we focus on the definition and execution of structural mappings. We introduce a semi-automatic mapping tool, based on model-driven principles and a modular, extensible architecture. Our tool is implemented as module for the DoME metamodelling tool; the underlying Smalltalk language is platform independent (cf. Sect. 4). The key point of our approach are so-called mapping templates—small reusable fragments—which considerably facilitate the laborious integration process. Upon execution, our tool’s transformation engine finds occurrences of mapping templates in specific source models, and it composes the target model(s). Thus, our work ideally supplements automated schema matching, and we are planning to incorporate such tools in future versions of the mapping tool. Strictly speaking, our approach is too generic to be called a Domain-Specific Language. Yet the examples we use for illustration come from a specific application area, that of Engineering Asset Management—i.e., the management and administration of large-scale industrial systems. Due to the complexity and size (in terms of components) of industrial plants, large amounts of data have to be exchanged between many highly automatized processes and operations. The complexity of the data to be exchanged, and the exchange across the domain boundaries of business-oriented and engineering-oriented systems pose further challenges to be overcome. In the next section we describe the overall structure of our approach and introduce the example application area. We then describe the typical integration process, and the models involved in setting up the specific example transformation. The paper concludes with an overview of our tool support and its evaluation in several industrial case studies.

2 Architecture of a Metamodel-Based Integration Framework Current approaches on information integration lack sufficient flexibility to account for evolving models and/or changing information requirements. In particular, most current tools cover only partial aspects of the integration process. Therefore, users have to acquaint themselves with several different tools in order to deal with both the schema- and data-specific aspects of mappings between heterogeneous information systems [11]. Metamodel-based information integration tackles the integration problem at a higher level of abstraction, while it also increases the flexibility of mappings through reusable

Metamodel-Based Information Integration at Industrial Scale

155

mapping templates. This means that integration decisions are made for generic small fragments of models with conversion operators defined at the metamodel level, typically for a single conceptual entity of the underlying domain model (e.g., a fuel pump). Once the user has specified how to convert a particular entity among different metamodels, this mapping can be reused as a template for all model fragments that represent the same entity. Moreover, layered (meta-)models are easier to evolve over time [9]. tr ep xe ni a m od

ern igs ed no tia rg ten I ers u no tia cli pp A

Fig. 1. Architecture of the metamodel-based integration framework

Our metamodel-based approach defines three levels of abstraction: meta-model, model and instance. Each level is assigned with certain tasks or roles of the information integration process. Along these lines, we propose the object oriented framework for flexible holistic integration of schema and data of enterprise models depicted in Fig. 1. 2.1 Example Domain Our main example comes from the oil and gas industry sector. Oil and gas processing companies are engaged in global networks for the engineering, procurement, construction and maintenance of their plants and assets (e.g., assembly of drilling platforms or refineries). These activities constantly require large-scale exchange of data between different sections of a company, between business partners in a venture, and between clients and providers in terms of equipment and services. One of the most important applications in the so-called Engineering Asset Management (EAM) domain is to exploit lifecycle data of industrial plants for more accurate planning and management of maintenance actions, thus saving substantial costs [13]. Despite considerable efforts towards standardization of plant data management and exchange in the oil and gas industry, standards such as ISO 15926 [7] have not solved the interoperability problem.

156

S. Berger et al.

Different parts of the industry use competing standards for representing engineering assets—ISO15926 [1,7], and the MIMOSA Open Systems Architecture for Enterprise Application Integration (OSA-EAI) [14,5,8]. Both standards facilitate the integration and exchange of heterogeneous information on industrial plants [12]. The same holds for the lesser known ISO 14224 standard on maintenance systems descriptions. Engineering companies (i.e., equipment producers, design and CAD companies such as Intergraph or Bechtel) generally use ISO15926. With certain exceptions, the maintenance providers and control systems companies (e.g., IBM/MAXIMO, Microsoft, Rockwell Automation, Emerson, Yokogawa) use MIMOSA. Both sides have established a significant code base and market share-driven vested interest in maintaining a separate platform, even though any company would profit from superior interoperability. The ISO 15926 standard defines an information model and exchange infrastructure for industrial plants. Although the title of the standard emphasizes the oil and gas industry, the data model is generic and allows representing assembly and lifecycle data of all kinds of industrial plants. Formally, the data model of ISO 15926 is based on set theory and first order logic, specified in the EXPRESS modeling language [2]. The model is also nominally defined in the OWL Semantic Web language, although its expressivity is insufficient to fully capture technical knowledge about the domain. As a result, OWL is mainly used for simple type consistency checks1. The official ISO 15926 repository uses RDF (Resource Description Framework) as the internal representation. MIMOSA OSA-EAI is rather specified in UML as an object-oriented information model which corresponds to the MIMOSA relational schema (CRIS) [14]. Basically OSA-EAI is an implementation of the ISO 13374 functional specification [3]. This means that OSA-EAI complements the functionality blocks of the ISO 13374 standard with interface methods. The MIMOSA object and relational models are separately maintained but the object model is gaining in relative importance. Both ISO 15926 and MIMOSA nominally support XML as an interchange format. Many of the XML formats of ISO 15926 vendors are mutually noninteroperable, though, as the limited use of semantic annotations leaves too much flexibility in the implementation of the standard. 2.2 Model Level Interaction The deployment of the approach for a particular integration scenario is executed in three stages following the metamodel stack from the top down to the instance level. At the metamodel level, i.e. the most abstract level, the domain experts define two fundamental components of the mapping architecture. First, they design the generic Mapping metamodel representing some application domain as entities, relationships and mapping operators that may be instantiated at the model level and at the instance level. Each Mapping metamodel interrelates at least two metamodels, which we call its submetamodels. Second, they administrate the set of sub-metamodels and design the entities, relationships and mapping operators of those sub-metamodels. For example, the domain expert could support ISO 15926 and MIMOSA OSA-EAI as sub-metamodels, and design an appropriate EAM domain model as generic metamodel (see Fig. 1). 1

Also, the ISO 15926 formalization employs non-standard set theoretic principles, although no case is known to us where the postulated cyclic set containments have actually arisen.

Metamodel-Based Information Integration at Industrial Scale

157

At the model level the integration designers decide how the sub-metamodels relate in terms of entities and mapping operators of the generic metamodel. For that purpose, they develop mapping templates specifying how to convert some fragment of a source metamodel to the generic metamodel, and how to adequately represent this fragment in the target metamodel. In other words, a template instantiates some part of the generic metamodel as well as the corresponding fragments of the source and target sub-metamodels. Each template and is stored in the template library. For example, a template library for the EAM domain will contain a number of mapping templates between the ISO15926 and MIMOSA OSA-EAI sub-metamodels in either direction. Finally, at the instance level, the application users semi-automatically create individual target model instances from a source model. For example, an application user may be interested in the ISO15926 compliant representation of a fuel pump modeled in OSA-EAI. The system automatically browses the template library for appropriate fuel pump mapping templates. It instantiates the target part of the matching template(s), composes the model, and presents it to the application user for review and refinement. The flexibility of this metamodel-based approach originates from combining both, schema and instance information in the mapping templates. Intuitively, the mapped entities and their properties serve as arguments of the template, which enables the conversion of data chunks across modeling levels. Given the different rationale behind the various EAM standards in use, such a degree of flexibility is necessary, particularly for ISO15926 which often blurs the schema and instance levels. Semantically equivalent data often reside at different modeling levels across the standards (e.g., property values of OSA-EAI objects commonly map to concepts called relations of ISO15926). Our metamodel architecture depicted in Fig. 1 utilizes mapping templates with instance information to derive better transformations of source models to the target representation. Metamodel-based information integration offers the following advantages which help reducing the mapping effort among heterogeneous metamodels: – Mapping operators introduced at the metamodel level are generally available for all mapping templates defined at the model level. – The template library allows to reuse mapping fragments between interrelated metamodels. Thus, domain specific integration knowledge is stored once at some central repository, independent of any particular application. – Mapping templates are interpreted without any “direction” to augment reusability. – The transformation process is transparent for the application users.

3 Concepts of a Metamodel-Based Information Integration Tool Our tool is employed for metamodel-based information integration as follows. The only task necessary for the application user is to import a source file whereupon the tool automatically converts the source model and data to a semantically equivalent target representation. In this process, the transformation engine applies the mapping templates predefined by the integration designer. Templates employ the mapping operators and conversion operators on the conceptual entities, attributes and relationships of the

158

S. Berger et al. Metamodel-level Source metamodel

convert

Generic metamodel

convert

Target metamodel

Model-level

export

...

Template library generate export

Instance-level XML file [source metamodel]

import

Model instance

Model instance

XML file [target metamodel]

export database data

Fig. 2. Conceptual view of a metamodel-based integration tool (transformation engine)

underlying application domain, as specified in the generic metamodel by the domain expert. The former operators transform model elements between different metamodels, whereas the latter allow transformations within one and the same metamodel. Fig. 2 illustrates our transformation engine, based on the tool architecture presented in Sec. 2. In MDA terms, we encounter an intriguing situation. Essentially, all descriptions within the box in Fig. 2 correspond to the Platform Independent Model (PIM) level of the MDA approach. They abstract from the syntax and low-level application code, and the model semantics are wholly expressed in terms of its structure. The differences captured by the metamodel mapping are differences in the organization of the content, not a result of the platform used. For instance, we can split an address into a street name and a number regardless of the underlying model (relational, XML-based, or objectoriented). These mappings capture modelling differences, not platform differences. The actual PIM-to-PSM mapping is therefore restricted to the import and export functions (which includes the actual access to the systems being mapped). Not all information described at this PIM level is ontologically equal. While the information captured in the different metamodels is, by necessity, to some degree domain dependent, this term has to be understood loosely. For example, the higher level concepts of the ISO15926 model follow lines of distinction such as that between physical and nonphysical objects, a rather abstract ontological difference. In contrast, the mapping templates need to examine specific aspects of the domains involved in the mapping and place them in relation to each other. Therefore we refer to them as Scenario Specific PIMs (SSPIMs), whereas the higher levels are Scenario Independent PIMs (SIPIMs). Some authors use MDA terminology in the sense that a high level formal business process model is a Computation Independent Model (CIM). From the traditional viewpoint, which we follow, a CIM is not captured by tools because it is computation independent, and supporting it with a tool requires at least identifying the formal semantics of what one wants to represent—in other words, defining a PIM for the CIM. In the following subsections we illustrate the concepts behind our metamodel-based integration approach for the Engineering Asset Management domain introduced in the previous section. We describe how to apply our approach in order to establish a library of mapping templates between the ISO15926 and MIMOSA OSA-EAI standards.

Metamodel-Based Information Integration at Industrial Scale

159

3.1 Metamodel Level Concepts The metamodel level of the proposed information integration architecture defines the fundamental concepts of the to-be-integrated data. The generic top metamodel (denoted as Mapping metamodel in Fig. 1) is the topmost abstraction layer of the underlying application domain. Therefore, the Mapping metamodel has to be both, sufficiently expressive to satisfy the information needs of all applications and users, and generic enough to represent all semantically interrelated sub-metamodels. The top metamodel provides a static and a dynamic perspective on the application domain it describes. On the one hand, the entities, attributes and relationships of the top metamodel represent the static viewpoint on the application domain. Furthermore, the static view comprises all sub-metamodels which express similar semantics and are therefore connected to the top metamodel. On the other hand, the mapping operators between the sub- and top metamodels as well as the conversion operators within particular metamodels specify the dynamic viewpoint on the application domain. Intuitively, the dynamic view describes in detail the options available for converting data between the different metamodels while preserving the original semantics of the data. For example, to apply our metamodel-based integration approach in the Engineering Asset Management (EAM) domain we would first define a Mapping metamodel generic enough to express both, ISO15926 and MIMOSA OSA-EAI data. The UML class diagram shown in Fig. 3 illustrates the (simplified) static view of the generic metamodel we developed for that application domain. Note that our generic metamodel is an object-oriented spatio-temporal data model (cf. [21,15,22]). Thus, the top metamodel is generic enough to represent both, the 4D data model of ISO15926 (i.e., 3-dimensional space plus time) [1], and the object identity principle used in the MIMOSA OSA-EAI core data model [5]. In particular, the Enterprise, Site and Segment metaclasses reflect the hierarchical composition of industrial plants from smaller physical or logical units and subunits. In turn, Asset, Model and Manufacturer allow modeling the exact physical structure of Segments, the smallest subunits of plants. Finally, ObjectData and its subclasses provide a generic mechanism for representing attributes or other pieces of information not captured by any of the top-level metaclasses. Figure 4, in turn, shows the dynamic view of our generic metamodel. Most conversion operators are represented as relationships, but we also need the Constant, DerivedValue and RandomValue classes to allow for completion of source model data in mapping templates with fixed respectively calculated values. In particular, the dynamic part of our generic EAM metamodel comprises four families of DataFlow operators (generate, specify, export, convert), plus the aforementioned Constant operator hierarchy. The generate operators read the result of a RandomValue operator, and assign the result to STEntity objects of the generic top metamodel (see Fig. 3). In contrast, the specify and export operator families read and write object names (setName, exportName) or attribute values (setValue, exportValue) from and to entities of sub-metamodels, respectively. Finally, the convert family provides more complex operations, like splitting an object name at some position (e.g., split(5)), or concatenating two values with merge. To complete our definition of an EAM information integration framework we also need to specify the ISO15926 and MIMOSA OSA-EAI metamodels, and define them as sub-metamodels of the generic top metamodel. Space limitations force us to omit a

160

S. Berger et al. 1

STEntity -entityId {id}

0..* Time

1 hasObjectData

Geometry Enterprise

Timestamp

Interval Line

Point

Polygon

Site ObjectData

0..*

* 0..1

-value

* «utility» AgentRoleType

Agent *

Segment Numeric

Character

AgentRole installedAt * *

Binary

Asset ofModel madeBy*

* 0..1

Model

0..1 Manufacturer

Fig. 3. Generic metamodel for the Engineering Asset Management domain

detailed illustration of these sub-metamodels. Albeit laborious, this task is straightforward because it simply consists of translating both the ISO15926 data model [1] and the OSA-EAI data model [5] to an object oriented metamodel analogous to the generic metamodel (Fig. 3). Note that the generic metamodel—except for the spatial and temporal classes—corresponds to the core package of the OSA-EAI data model. 3.2 Model Level Concepts The model level of our information integration architecture comprises the collection of mappings in the template library. Each mapping specifies how to convert a small fragment of information from the source to the generic metamodel, and then to the target metamodel. Typically, a mapping template describes the transformation pattern for a single conceptual entity of the application domain. Notably, it is possible to define mapping templates in either direction, i.e., with any of the sub-metamodels acting as the mapping source, and one of the other sub-metamodels as the mapping target. For instance, in order to specify how to transform MIMOSA OSA-EAI data about a kerosene pump to the ISO15926 standard we define a mapping as instance of the generic metamodel depicted in Fig. 3, having the MIMOSA OSA-EAI sub-metamodel as its source and the ISO15926 sub-metamodel as target. To transform OSA-EAI entities to the generic metamodel, and then to ISO15926 entities we employ the mapping and conversion operators introduced in the previous Subsection (see Fig. 4). Accordingly, we show a possible mapping template for kerosene pumps in Fig. 5. While the OSA-EAI representation of the kerosene pump in Fig. 5 is self-explanatory, its ISO15926 counterpart calls for some clarifying remarks. Most significantly, the

Metamodel-Based Information Integration at Industrial Scale

161

Fig. 4. Mapping operators of the generic metamodel for Engineering Asset Management

ISO15926 standard defines an extraordinarily generic data model. On top of this, the ISO15926 “metaclasses” blur the metamodel level by incorporating metaclasses and even meta-metaclasses in the model without any semantic distinction except a naming convention. Conversely, the actual hierarchy of equipment types is not specified as part of the standard’s class hierarchy, but stored in a relational schema rather than given in diagram form.2 Therefore we use ClassOfIndividual together with MultidimensionalObject, PossibleIndividual, and FunctionalPhysicalObject as “metaclasses” in the same diagram. Furthermore, the ISO15926 standards body semi-formally encourages the use of so-called “templates” [17,4] 3 . In Fig. 5 we employ two of these ISO templates in much simplified form. First, the classification of the kerosenePump object as an ’Induction Motor’ with the help of a MultidimensionalObject instance follows the “classification of an individual” ISO template [4, 7.3.1]. Second, the connection between the kerosene pump and its ’rated voltage’ property, again using a MultidimensionalObject instance, adheres to the “possession of an indirect property by a temporal part of a physical object” ISO template [17, /3401.htm]. Compared to average sized models and mappings used in practice, the kerosene pump example has been simplified considerably. To allow for an easier presentation we intentionally keep the example and sample mapping template at minimum possible size. Nevertheless, it shows usage patterns for every operator family introduced at the metamodel level (Constant, generate, specify, export, convert). The sample mapping includes at least one example operator for each operator family. The mapping template in Fig. 5 shows abstract mapping operations directly from the source to the target metamodel, which sketch the application user’s intuitive view, while internally these operations correspond to mapping and conversion operators. In 2 3

For details about this lack of distinction between syntax and modelling level, and a discussion of other shortcomings see [19]. The name similarity to our mapping templates is accidental. An ISO15926 template is a way to introduce n-ary relations by permitting the reification of assocations. The OWL/RDF based repository cannot represent n-ary relations directly since OWL is restricted to binary relations.

162

S. Berger et al.

particular, the sample mapping employs the following operations to map an OSA-EAI representation of the sample kerosene pump to the generic metamodel, and the generic entities to ISO15926 compliant data: – Operation transferName corresponds to the juxtaposition of two mapping operators, setName and exportName: • First, setName reads the name of the kerosene pump Mimosa.Asset object, and assigns the name to the ’Kerosene Pump’ object of type Generic.Asset. • Second, exportName reads the name of the generic Asset object and assigns it to the appropriate ISO15926.functionalPhysicalObject instance. – Operation append ’Obj’ employs a merge conversion operator, which concatenates the kerosene pump name returned by the setName operator with a string ’Obj’. – Finally, the extractUnit and extractValue operations correspond to sequences of split, setValue and exportValue operators on the kerosene pump’s ’rated voltage’ property: • In order to derive the value and measure unit, the split operator applies on the pump’s Mimosa.ObjectData instance representing the voltage property. • The setValue operator then writes voltage 2300 to a Numeric object’s value attribute, and measure unit ’Volts’ to a Character object’s value attribute. • Two exportValue operators write the Numeric and Character value attributes to the target ISO15926 objects, denoted someScale respectively someValue. It is important to notice that the mapping template transforms the classification of the source model’s kerosene pump as ’Motor, AC’ in MIMOSA OSA-EAI to its equivalent classification as ’Induction Motor’ in ISO15926 without using any conversion operator. This is general domain knowledge and valid for all instances of such a kerosene pump. Thus, this kind of conversion without operators constitutes the fixed part of the mapping template. In contrast, the name, voltage, serial number, and other attributes are bound to some specific instance of a kerosene pump; this kind of information therefore builds the variable part of the mapping template. Every time we match the template to a source model and execute the mapping, the transformation engine of our mapping tool instantiates the operators with actual values from the source files (cf. Fig. 2). 3.3 Instance-Level Concepts In our metamodel-based integration framework the instance level merely serves as the interface between the application users and the mapping tool depicted in Fig. 2. Both ISO15926 and MIMOSA OSA-EAI provide open, XML-based storage formats for serializing and exchanging model files [1,5]. In order to convert the model and data of an input file to an equivalent representation in some target metamodel, the application user opens the input file with the mapping tool. Next they start the transformation process, whereupon the tool compares the input model with all source model fragments of the mapping template library. In case of a successful match, the tool executes the mapping operators given in the template with the actual values read from the source model. Should even several templates trigger, the tool collects and composes the target model fragments of all matching templates in a single output model. Finally, the tool presents the output model to the user who may process the result (e.g., for manual corrections).

Metamodel-Based Information Integration at Industrial Scale

163

Fig. 5. Sample mapping template from the OSA-EAI to the ISO 15926 metamodel (simplified)

The final target model is ready to be saved to the file system, or exported using an arbitrary export format supported by the framework (e.g., into a database schema). For example, an application user could be interested in converting the OSA-EAI model file of a kerosene pump named ’01G-7A S/N 400560 Pump’ (see Fig. 6 left) to an ISO15926 compliant model using our mapping tool. In this example, the given model corresponds exactly to the template we designed earlier, except that the sample model file gives an additional ’Max Capacity’ property of the pump. Our mapping template depicted in Fig. 5 produces the ISO15926 representation of the given kerosene pump as depicted in the right-hand-side of Fig. 6. Note that the ’max capacity’ property is ignored in the output model since it does not match the mapping template. To incorporate the ’max capacity’ property in the output model one would simply repeat the pattern employed for the ’rated voltage’ property; i.e., use a Mimosa.ObjectType and Mimosa.ObjectData instance connected with a hasObjectData relationship.

164

S. Berger et al.

Fig. 6. Sample kerosene pump modeled in OSA-EAI (left). Result of the sample mapping template in Figure 5, transforming the kerosene pump model to the ISO 15926 metamodel (right).

4 Tool Support and Experience The transformation engine is built as an extension of the open source DoME metamodelling tool, which generates interactive model drawing editors based on a metamodel specification. The underlying Smalltalk platform guarantees dynamic compilation and execution of mappings as well as binary compatibility across all common deployment environments. The implementation provides wrappers to relational databases (ODBC), XML, Web services (WSDL/SOAP) and a range of proprietary environments (e.g., SAP RFC, MS Access). The original mapping editor, supporting a subset of the Meta Object Facility (MOF), was developed in autumn 2008. From September 2009, besides the EAM metamodel definitions we simply implemented some extensions to support our conversion operators. Specifically, the tool provides built-in QVT and OCL implementations, including QVT visualization through the DoME metamodel editor. QVT is ideally suited for the schema level execution of mappings as it allows to express conceptual entity mappings in straightforward manner, but falls short if the mapping requires instance information. In the latter case, the mappings rather need to be expressed as OCL constraints; e.g., if property “Type=‘Electric Motor” of a motor instance represented in MIMOSA OSA-EAI holds, then it should be mapped to concept “ElectricMotor” in ISO15926. OCL statements, though, can be easily complex with the code concealing the mapping logic. As, to the best of our knowledge, tool support for the full QVT standard is unavailable, and because of the shortcomings of QVT mentioned above, we tested our industrial example cases with stub implementations of QVT transformations for the conversion operators. The integration toolbox has been in practical use in an environment incorporating multiple interactions and transformations since early 2009. Tests involved systems such as the Foxboro Reactor Control and Monitoring System for the OPAL research reactor in Lucas Heights, Sydney, operated by ANSTO (Australian Nuclear Science and Technology Organisation), the ERP system used by ANSTO (SAP R/3), various monitoring

Metamodel-Based Information Integration at Industrial Scale

165

and analysis applications based on MS Access, MS Excel, and an asset management decision support system that communicates with the integration component through Web services. The target application was maintenance relevant information concerning the primary cooling circuit and pumps. Communication with SAP initially was executed via RFCs as the site had not upgraded to the NetWeaver Web Service communication package; this migration has since taken place. Since the mapping definition is essentially restricted to interactive editing of diagrams, the actual mapping execution is something of which end users are potentially capable. The largest source of complexity lies in the SAP link due to the size of the SAP conceptual model. Furthermore, BAPI (Business Application Interface) calls must exist to access or write actual data items, even though the low-level access details are wrapped and therefore transparent. Consequently, the difficulty lies mostly in navigating the SAP data model to identify the mapping possibilities. This is supported by accessing the SAP Business objects metamodel, parts of which are transformed into the PIM space. The editor presents appropriate business object subnets to the user, based on heuristical analysis of the references within the PIM representation. (The SAP consultants appreciated this functionality as being very useful even outside the strict transformation scenario.) In this respect, our mapping editor mimics the functionality of schema matching tools which highlights that both approaches—metamodel-based information integration, and automatic schema matching—efficiently supplement each other. In general EAM practice, as exhibited in the case study that formed our example earlier in the paper, the complexity of the data and size of the models is different. Models of industrial plants or drilling rigs (e.g., “piping & instrumentation diagrams”) easily comprise many thousands of objects since it is essential for plant operators to maintain an exact picture of the plant reality—literally speaking, the goal according to the current state of the art is to trace the fate of individual nuts and bolts over the lifecycle of, say, an oil drilling rig. This huge complexity of industrial plant models is the basic motivation that drives this application case. Our approach helps abstracting the complexity of the underlying models from the application users’ perspective. Thus, flexible metamodel driven information integration is particularly beneficial for the EAM and CBM departments in traditional industries, as we sketch with our case study. The transformation engine was demonstrated as part of multi-way interoperability demos co-organized by POSC/CAESAR and the Open O&M Consortium at two major oil and gas symposia in Houston, TX: ISA-EXPO’09, October 2009, and Digital Plant, March 2010. These meetings involved nine partners on the ISO15926 side, among them Intergraph, Bechtel, as well as IBM, Microsoft, Rockwell Automation, Emerson on the MIMOSA side. The demonstration simulated the transfer of equipment data in both directions as part of a complex maintenance workflow sequence involving fault diagnosis, accessing part design information, and activating the ERP maintenance workflow on the business side. In the first case, the meta-metamodel implementation was not yet available, and the metamodel mapping was defined explicitly. In the second case, the full metamodel hierarchy and mappings were developed within less than four weeks. (Notably, the ISO1926 partners in the demos were unable to provide an actual subschema specification for the data involved within less than four weeks due to the complexity of the data model; the mapping was reverse engineered from our team’s knowledge of the standard and a set of otherwise undocumented sample data.)

166

S. Berger et al.

Apart from the generic schema matching and mapping work mentioned earlier, the work most closely related to ours is that of [6,18]. Their work follows a maximum power approach involving a large number of different model groups including semantic annotations, reasoning about QoS requirements, ontology-based models in RDF, OCL and process algebra, and an according family of supporting tools. Ultimately, as stated in [6], this also is not sufficient to completely handle real world conflict situations and one has to fall back on manual mappings. In comparison, we are aiming at a lightweight integration approach that encapsulates the requisite information within one model hierarchy in the reflective and dynamic DoME environment, remains otherwise agnostic of execution environment issues, and uses a minimum of external tools. This narrow footprint strategy has proven highly beneficial both, to minimize deployment and setup time for the international demo settings, and to meet the concerns of the security and safety conscious ANSTO environment. We built the tool in modular fashion to facilitate its integration with either an automated schema matcher, or our existing service composition engine [20]. These linking tasks are currently ongoing.

5 Conclusion In this paper we have described a metamodel-based schema mapping tool for providing lightweight data exchange in a model-driven fashion. By using a multilayered metamodelling approach, the tool is independent of particular data models or languages; syntactical differences are handled at the PSM level, while the multilayered PIM level (from more to less domain independent) captures transformations in structure and content. Mappings at every level can be established by graphical editing. They are currently executed straight from the PIM Level, although explicit code generation is a possibility. By utilizing a small set of powerful concepts rather than a large family of tools and languages, the style of mapping definitions appears consistent across multiple levels, facilitating interactive use of our tool (at the bottom level, that of the actual model mapping, suitable to use even by non-experts). Although designed with a Service-Oriented Architecture setting in mind, it is complementary to service-based integration architectures by major vendors such as Websphere or Netweaver. The tool has been in in-house use with an industry partner in multiple scenarios for a year, in scenarios of varying complexity up to integration with SAP R/3. The main example in the paper is based on the integration of two major industrial reference data management standards at the upper end of the complexity scale and the tool has been tested in multi-vendor interoperability demos in the oil and gas industry to demonstrate data interchange with little setup time and a minimum of semantic encodings.

References 1. ISO 15926 – Industrial automation systems and integration: Integration of life-cycle data for process plants including oil and gas production facilities: Part 2: Data model. ISO (2003) 2. ISO 10303 – Industrial automation systems and integration: Product data representation and exchange: Part 11: Description methods: EXPRESS language reference manual. ISO (2004) 3. ISO 13374 – Condition monitoring and diagnostics of machines: Data processing, communication and presentation: Part 2: Data processing. ISO, Geneva (2007)

Metamodel-Based Information Integration at Industrial Scale

167

4. ISO 15926 – Industrial automation systems and integration: Integration of life-cycle data for process plants including oil and gas production facilities: Part 7: Implementation methods for the integration of distributed system – Template methodology. ISO, Geneva (2008) 5. Open Systems Architecture for Enterprise Application Integration – Version 3.2.2 Specification, MIMOSA (2010), http://www.mimosa.org/?q=resources/specs/osa-eai-v322 6. Agt, H., Bauhoff, G., Cartsburg, M., Kumpe, D., Kutsche, R.-D., Milanovic, N.: Metamodeling foundation for software and data integration. In: Proc. 3rd Intl. United Information Systems Conf. (UNISCON), pp. 328–339. Springer, Heidelberg (2009) 7. Batres, R., West, M., Leal, D., Price, D., Masaki, K., Shimada, Y., Fuchino, T., Naka, Y.: An upper ontology based on ISO 15926. Comp. & Chemical Eng. 31(5-6), 519–534 (2007) 8. Bengtsson, M.: Standardization issues in condition based maintenance. In: Proc. 16th Intl. Cong. on Condition Monitoring and Diagnostic Eng. Mgmt., pp. 651–660. Univ. Press (2003) 9. Draheim, D., Himsl, M., Jabornig, D., K¨ung, J., Leithner, W., Regner, P., Wiesinger, T.: Concept and pragmatics of an intuitive visualization-oriented metamodeling tool. J. Vis. Lang. Comput. 21(3), 157–170 (2010) 10. Grossmann, G., Ren, Y., Schrefl, M., Stumptner, M.: Behavior based integration of composite business processes. In: van der Aalst, W.M.P., Benatallah, B., Casati, F., Curbera, F. (eds.) BPM 2005. LNCS, vol. 3649, pp. 186–204. Springer, Heidelberg (2005) 11. Haas, L.M., Hentschel, M., Kossmann, D., Miller, R.J.: Schema and data: A holistic approach to mapping, resolution and fusion in information integration. In: Proc. 28th Intl. Conf. on Conceptual Modeling (ER), pp. 27–40. Springer, Heidelberg (2009) 12. Hakkarainen, S., Hella, L., Strasunskas, D., Tuxen, S.: A semantic transformation approach for ISO 15926. In: Roddick, J., Benjamins, V.R., Si-said Cherfi, S., Chiang, R., Claramunt, C., Elmasri, R.A., Grandi, F., Han, H., Hepp, M., Lytras, M.D., Miˇsi´c, V.B., Poels, G., Song, I.-Y., Trujillo, J., Vangenot, C. (eds.) ER Workshops 2006. LNCS, vol. 4231, pp. 281–290. Springer, Heidelberg (2006) 13. Lin, S., Gao, J., Koronios, A., Chanana, V.: Developing a data quality framework for asset management in engineering organisations. IJIQ 1(1), 100–126 (2007) 14. MIMOSA (April 2010), http://www.mimosa.org/?q=about/what-mimosa 15. Pelekis, N., Theodoulidis, B., Kopanakis, I., Theodoridis, Y.: Literature review of spatiotemporal database models. The Knowledge Eng. Review 19(3), 235–274 (2004) 16. Rahm, E., Bernstein, P.A.: A survey of approaches to automatic schema matching. VLDB J. 10(4), 334–350 (2001) 17. Template specifications for ISO15926 part 7, http://rdlfacade.org/files/iso15926-7/ts/ 18. Shtelma, M., Cartsburg, M., Milanovic, N.: Executable domain specific language for message-based system integration. In: Sch¨urr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 622–626. Springer, Heidelberg (2009) 19. Smith, B.: Against idiosyncrasy in ontology development. In: Frontiers in Artificial Intelligence and Applications (FOIS), vol. 150, pp. 15–26. IOS Press, Amsterdam (2006) 20. Thiagarajan, R.K., Mayer, W., Stumptner, M.: A generative framework for service process composition. In: Baresi, L., Chi, C.-H., Suzuki, J. (eds.) ICSOC-ServiceWave 2009. LNCS, vol. 5900, pp. 358–363. Springer, Heidelberg (2009) 21. Tryfona, N., Price, R., Jensen, C.S.: Conceptual models for spatio-temporal applications. In: Sellis, T.K., Koubarakis, M., Frank, A., Grumbach, S., G¨uting, R.H., Jensen, C., Lorentzos, N.A., Manolopoulos, Y., Nardelli, E., Pernici, B., Theodoulidis, B., Tryfona, N., Schek, H.J., Scholl, M.O. (eds.) Spatio-Temporal Databases. LNCS, vol. 2520, pp. 79–116. Springer, Heidelberg (2003) 22. Yuan, M.: Use of a three-domain repesentation to enhance GIS support for complex spatiotemporal queries. Trans. on GIS 3(2), 137–159 (1999)

Inferring Meta-models for Runtime System Data from the Clients of Management APIs Hui Song1 , Gang Huang1, , Yingfei Xiong2 , Franck Chauvel1 , Yanchun Sun1 , and Hong Mei1 1

Key Lab of High Confidence Software Technologies (Ministry of Education) School of Electronic Engineering & Computer Science, Peking University, China {songhui06,huanggang,franck.chauvel,sunyc,meih}@sei.pku.edu.cn 2 Generative Software Development Lab, University of Waterloo, Canada [email protected]

Abstract. A new trend in runtime system monitoring is to utilize MOFbased techniques in analyzing the runtime system data. Approaches and tools have been proposed to automatically reflect the system data as MOF compliant models, but they all require users to manually build the meta-models that define the types and relations of the system data. To do this, users have to understand the different management APIs provided by different systems, and find out what kinds of data can be obtained from them. In this paper, we present an automated approach to inferring such meta-models by analyzing client code that accesses management APIs. A set of experiments show that the approach is useful for realizing runtime models and applicable to a wide range of systems, and the inferred meta-models are close to the reference ones.

1

Introduction

Monitoring is becoming more and more important for running software systems. The core of monitoring is to retrieve and process the runtime system data (such as its memory occupation, instantiated components, user load, etc.), which describe the state, structure and environment of the system. Currently, for most systems, runtime monitoring is still a code-level task. Developers have to write code upon the system’s management API, like the JMX API of JEE systems [1]. Runtime model is a promising approach to raising the abstraction level of runtime monitoring [2]. By representing the intangible runtime system data as explicit and well-formed models, system monitoring could be performed in a model-based way, with full semantic basis, utilizing the plenty of model-based techniques such as OCL, QVT, GMF, etc. Runtime model is an extension of the traditional model-driven methodology at runtime. Since different systems provide totally different runtime data, the first task for supporting runtime model on a system is to construct a proper meta-model, which defines the types of the system data that can be retrieved from the system’s management API, as well as the association between these data types. To 

Corresponding author.

D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 168–182, 2010. c Springer-Verlag Berlin Heidelberg 2010 

Inferring Meta-models for Runtime System Data

169

our knowledge, the current generic runtime model supporting tools [3,4,5,6] all require users to define such meta-models by hand. However, it is not easy to define such a meta-model. First, many management APIs conform to standard interfaces, like JMX, OSGi, DOM. Such APIs do not provide specific classes for different types of system data, and thus we cannot get the data types from the static type systems of the APIs. Second, many systems do not provide clear documents about what kinds of data they provide, and even if there are such documents, it is still tedious to convert the informal specifications into meta-models. On the other hand, developers may understand the system data from existing API clients (programs using the APIs). Although the clients do not usually contain the direct definition of data types, but they carry the experts’ understanding about what data can be obtained and how to use them. The problem is that the client code is often too complicated for human users, especially when it is full of branches and inter-method logics. In this paper, we present an automated approach to inferring the meta-model of runtime system data under management APIs, by means of static analysis of the API client code. The process is automated, without requiring users to annotate the source code. Our contributions can be summarized as follows. – We clarify the relation between the API client code and the data types manipulated by it, and provide a novel static code analysis approach to extract such data types automatically. – We construct an automated tool for meta-modeling a system’s runtime data. The output meta-model guides developers in using the API, and is also an input of our previous tool-set to realize the runtime model. – A set of experiments reveal the usability, wide scope, and effectiveness of our approach, and also reveal that static analysis on API sample clients is sufficient to meta-model the data under management APIs Our tool and experiments are stored at http://code.google.com/p/smatrt. The rest of the paper is organized as follows. Section 2 gives an overview of the approach. Section 3 to Section 5 explain the approach in three steps. Section 6 introduces our implementation briefly and evaluates the approach based on a set of experiments. Finally, Section 7 introduces related research approaches and Section 8 concludes the paper.

2 2.1

Approach Overview Motivating Example

We take SUN’s reference JEE server, Glassfish [7], as an example. Figure 1 shows how to monitor the memory status through its JMX interface. From the two parameters url and account, the printMem method first constructs a JMX connector, and then obtains a management entry mbsc. After that, it queries out an ObjectName of the MBean (Management Bean, the basic management unit of JMX) for memory (Lines 6-8). Using this MBean, it obtains the heap usage information (7-8), and checks if the memory is verbose (9). If verbose, it prints

170

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

H. Song et al.

public class JMXClient { public void printMem(JMXServiceURL url, Map account) throws Exception { JMXConnector connector = JMXConnectorFactory.connect(url, account); MBeanServerConnection mbsc = connector.getMBeanServerConnection(); ObjectName memory = ObjectName.getInstance("*type=Memory"); memory = mbsc.queryNames(memory,null).iterator().next(); CompositeDataSupport heapUsage=(CompositeDataSupport) mbsc.getAttribute(memory,"HeapMemoryUsage"); Boolean verbose=(Boolean)mbsc.getAttribute(memory, "Verbose"); String attr=""; if(verbose.booleanValue()) attr="max"; else attr="used"; System.out.println(String.format("%d,after%dGCs", heapUsage.get(attr), countGC(mbsc))); } public long countGC(MBeanServerConnection mbsc) throws Exception{ Set gcs=mbsc.queryNames( ObjectName.getInstance("java.lang:type=GarbageCollector,*"),null); long total=0; for(ObjectName gc: gcs) total+=((Long)mbsc.getAttribute(gc, "CollectionCount")).longValue(); return total; } }

Fig. 1. Sample JMX client to monitor the memory status of Glassfish Server

(a) Runtime Model

(b) Meta-Model for System Data GlassfishServer

server : GlassfishServer url = "localhost:8686" account = gc1 : GC collcount = 434

memory

memory : Memory gc

collcount = 89

gc

verbose = false heapUsage : HeapUsage

gc2 : GC

+url : JavaServiceURL +account : Map

max = 13768 used = 8953

(c) JMX Types MBSC

HeapUsage +max : long +used : long

queryNames

getAttribute

java.lang.Object

memory

GC

Memory

+collcount : int

+verbose : bool

heapUsage

ObjectName getAttribute

Fig. 2. The runtime model for the memory status of Glassfish

the maximal heap size (11,14), otherwise, the used heap size (12, 14). Finally, it invokes the other method countGC (14), to get the MBean for garbage collection (17-18), and sums up the total number of collections. Figure 2(a) shows a runtime model that intuitively represents the memory status. Figure 2(b) is the meta-model needed for such a runtime model. This meta-model contains two aspects of information: 1) What kinds of system data can be obtained through the JMX API. 2) The association between the data types. The target of this paper is to automatically construct such a meta-model. We cannot simply transform the API static type system into a meta-model. In that way, we will just get a meta-model like Figure 2(c), because JMX provides a general ObjectName for all kinds of data. Therefore, we need the knowledge about how people use the general class. The API client carries this information.

Inferring Meta-models for Runtime System Data

2.2

171

Inferring Meta-Models from the API Clients

We can infer meta-models of the system data from API clients because the clients were written by developers according to their understanding about the data types and associations. In other words, when the developer wrote this client, she had a meta-model like Figure 2(b) in her mind. 1. A class or a primitive data type defines a kind of system data, which can be obtained by accessing the API. For example, from the Memory class, developers knew there is an MBean for memory status (Lines 3-6). 2. A property of a class type means accessing the API with the help of this type of data could obtain another type of data. For example, from the heapUsage association and the verbose attribute of Memory, developers knew that from a memory MBean, they can get the heap usage information and the verbose flag, and thus wrote the code like Lines 7-9. 3. Different classes and properties indicate different ways to access the API. Here different ways not only mean invoking different methods, but also mean invoking the same method with different parameters. Reasoning reversely from the above scenarios, to recover the meta-model from client code, we need to find out 1) all the different ways existing in the client for accessing the API, and 2) what other system data are used in each way of API access. The former indicates potential classes or primitive data types in the meta-model, while the latter indicates the properties connecting them. To answer these two questions, we abstract the API access appeared in the client code as a transition from a set of input data to a single output data. For example, heapUsage.get(attr) in Line 14 is a transition from heapUsage and attr to an intermediate value. For each transition, we analyze how the client feeds it. Here “feeding a transition” means providing it the required input data. We can get two different slices in the client code to feed the above transition: One is to use the system data heapUsage obtained from Line 7 and a constant value "max" assigned in Line 11, and the other is to use the same heapUsage but a different constant value "used" from Line 12. So there may be two types of system data, and they are properties of HeapUsage. We generate the meta-model by investigating all the API accesses, and analyzing how they are fed. The approach has three steps, as shown in Figure 3. We first abstract the source code as a data transition diagram (DTG). From the extracted DTG, we analyze all the different slices to feed each transition of API access, and generate classes and properties accordingly. Finally, we simplify the raw meta-model to remove the redundant classes.

APIClient Source Code

extract

Data Transition Diagram

infer

Raw MetaͲ Model

Fig. 3. Approach overview

simplify

Final MetaͲModel

172

3

H. Song et al.

Extracting Data Transition Graphs

We model the source code as a data transition graph (DTG). The meaning of DTG is similar to the data-based program dependence graph [8], but with explicit record of variables and API accesses. Specifically, a DTG D = (P, T ) is constituted of places and transitions 1 . Places indicate where the data may appear. A place corresponds to an appearance of a variable or an implicit intermediate result inside an expression. A Transitions T : ℘(P ) → P , is a function from a set of input data to one output data. A transition corresponds to an assignment, an invocation, or a field access, etc. We name the transitions corresponding to API accesses as API involved transitions, notated as A. Figure 4(L9) shows a sample DTG extracted from Line 9 of Figure 1, and we notate the only transition in this DTG as follows. τ = {p(mbsc), p(memory), p( V erbose )}

getAttribute

−→

p(verbose)

We give each place or transition a signature to link it with the original source code. For the above τ , we use the following notations to retrieve the information it carries. 1) get input places: τ.i = {p(mbsc), p(memory), p( V erbose )}, 2) get the output place:  τ.o = p(verbose). We also popularize these notations onto DTGs, i.e., D.i = τ ∈D.T τ.i.

Fig. 4. Sample DTGs

We construct DTGs in three steps. We first ignore the control structures such as sequences, branches or loops, and construct a DTG for each of the individual expressions or assignments. Then we merge the disjointed DTGs within the bounds of method declarations, considering the control structures. Finally, we merge the DTGs constructed from different method declarations. We define a function χ : Expr → T to construct DTGs from expressions and assignments, based on Sahavechaphan.[9]’s summary on Java expressions. var

– Variable access. χ(var) = φ −→ p(var) – – – –



=

Assignment. χ(el = er ) = {χ(er ).o} −→ χ(el ).o cls.f un Static invocation. χ(cls.f un(e1 , ..., en )) = {χ(e1 ).o, ..., χ(en ).o} −→ p() f ld Field access. χ(e.f ld) = {χ(e).o} −→ p() Instance invocation. χ(e.f un(e1 , ..., en )) = {χ(e).o, χ(e1 ).o, ..., χ(en ).o} f un

−→ p() 1

We borrowed the names and notations from petri-net, but the semantics are not the same.

Inferring Meta-models for Runtime System Data

env

url Ājava.lang.typ=GarĂ,*ā

connect getInstance

c

mbsc

gc

ĀConnĂā 0

getAttribute

e b

passpara ĀVerboseā

=

Ājava.lang:type= Memoryā getInstance

connector getMB...

memory

mbsc

queryNames

Āā

queryNames memory ĀheapĂgeā

= attr

getAttribute += verbose

total

173

=

= or attr

getAttribute heapUsage

Āmaxā Āusedā

d

Ā%dĂā

get

a

return String.format

Fig. 5. The DTG for our running example

Figure 4(L13) illustrates the DTG we construct from Lines 13-14 of Figure 1. We first visit the static invocation of String.format, and construct a transition. After that, we recursively visit its parameters, constructing three other transitions, and appointing their outputs as the inputs of the first transition. When merging DTGs, we combine an input place π1 with an output place π2 , if they correspond to the same variable, and the statement of π2 is an effective assignment for the statement of π1 . For example, we combine the output of Figure 4(L4) with the first input of (L9). Here Line 4 is an effective assignment for Line 9 because they belong to the same sequence (so L4 will be executed before L9, assigning value to mbsc), and there is no other assignments to mbsc between them (so the value will not be flushed). Similarly, Line 11 and Line 12 are two effective assignments to attr for Line 14, but Line 10 is not, because it is completely shielded by the above two assignments, and thus we combine them as shown in Figure 5(a). We determine effective assignments using Ramanathan et al.’s work on statement precedence, which is powerful enough to handle sequences, branches and loops [10]. We combine DTGs across methods, with the help of parameter passing: We first remove the transition for the method invocation. And then we connect the input places from the actual parameters of the invocation with the places from the formal parameters in the method declaration. Finally, we connect the output place of the original transition with the output place extracted from the returned expression of the method declaration. For example, Figure 5(b) is the DTG extracted and combined from method countGC, we substitute it with the original countGC (Figure 4(L13)), obtaining this DTG. Finally, we obtain the DTG for the sample client as shown in Figure 5. The gray bars represent the API involved transitions.

174

4

H. Song et al.

Inferring the Meta-model

We infer the meta-model by finding out all the potential ways in the client code to feed API accesses, and the system data used in each of these ways. 4.1

Analyzing How to Feed the Transitions

We analyze all the different ways to feed each API involved transition, by extracting the valid sub-DTGs ending up with the transition. Definition 1. For a DTG D and a transition τ ∈ D, Dv is a τ -ended valid sub-DTG (VSD) of D (notated as Dv τ D), iff Dv is a sub graph of D, and it satisfies the following requisitions. 1. τ ∈ Dv ∧ τ.o ∈ / Dv .i. That means τ is an end of Dv . / Dv .i ⇒ π = τ.o That means τ is the only end of Dv . 2. ∀π ∈ Dv .o, π ∈ 3. ∀π ∈ Dv .i, π ∈ D.o ⇒ π ∈ Dv .o. That means if an input place π is neither a global input nor a constant value (because there are transitions in D that output to π), then there must be a transition inside Dv that outputs to π. = τ2 .o. That means there cannot be different transitions 4. ∀τ1 , τ2 ∈ Dv .τ1 .o  outputting to the same place. For the sample DTG in Figure 5 (we name it as D), the sub graph marked as c (named as Dc ) is a VSD ending up with connect (Dc connect D). Similarly, Dd getAttribute D. However, De  getAttribute D because mbsc’s source transition is not included. Da cannot constitute a VSD ending up with get, because there are two transitions outputting to the same place attr. A Dv τ D represents a sufficient and necessary subgraph to feed τ . Sufficiency is ensured by Requisition 3: Any transition in Dv can be fed by transitions inside the subgraph, or by global inputs or constant values. Necessity means if any transition in Dv is removed, τ cannot be fed, and it is ensured by Requisition 2 and Requisition 4 together. As a result, each Dv τ D represents a different slice to feed τ . Definition 2. For a Dv τ D, we say τ  ∈ Dv ∩ A is a direct API involved feeder of τ , if ∃D˜v τ˜∈Dv ∩A Dv , τ  ∈ D˜v . For example, in Figure 5(d), queryNames is a direct API involved feeder of getAttribute. τ  ∈ Dv ∩ A means the output of τ  (a kind of system data) is useful to feed τ , and ∃D˜v τ˜∈Dv ∩A Dv , τ  ∈ D˜v means that τ  directly feeds τ , without using other system data as intermediary. In a word, for a specific slice to feed τ , each of its direct feeder represents a system data which is directly used. 4.2

The Meta-model Inferring Algorithm

We infer a raw meta-model by analyzing all the VSDs for all the API involved transitions, and finding their direct feeders. In this step, the raw meta-model

Inferring Meta-models for Runtime System Data

175

Algorithm 1. Inferring the meta-model

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Input: A DTG D extracted and combined from the sample code Output: A set P ack of classes, constituting the meta-model cr ← class : {name → Root a : input → T ype}, P ack ← {cr } for τ ∈ A ∩ D do V ← {DT G(τ )} while ∃Dt ∈ V, Dt  τ D do Dt ← any({Dt ∈ V |Dt  τ D}) π ← any({π ∈ D.o|π ∈ / Dt .o}) V ← V − {Dt } if ∃τ  ∈ AD , τ  .o = π then foreach Dt τ  D do V ← V ∪ {Dt ∪ Di } else foreach τi ∈ D ∧ τi .o = π do V ← V ∪ {Dt ∪ {τi }} end end for Dt ∈ V do cn ← class:{name → CName (τ .o) } foreach τ  as a direct API involved feeder of Dt do cp ∈ P ack is generated from Dv τ  Dv cp ← cp ∪ {r : RName(Dt , Dav ) → cn } end if ∃τ  as a direct feeder then cr ← cr ∪ {r : RName(Dt ) → cn } P ack ← P ack ∪ cn end end return P ack

only contains classes and associations. We assume that every different way for an API access corresponds to a different class, and every type of system data directly used to obtain another type corresponds an association. We construct all the VSDs ending up with any API involved transition, and generate a class for each of them. In Figure 5, for the getAttribute transition that outputs heapUsage, we can construct one VSD, marked as “d” (named Dd ). And thus we generate the class named Comp--Usage as shown in Figure 6 for this VSD. Alternatively, for the transition get, we can construct two VSDs. Both of them contain Dd and the transition get, but one of them contains the assignment transition from "max", while the other contains the one from "used". Thus we generate two classes for this transition, named Long-1 and Long-2. For each VSD Dv constructed before, we find the direct feeders τ  , construct VSDs Dv τ  Dv , and generate an association to connect the class of each Dv with the class of Dv . In the above example, for the first VSD constructed from get, getAttribute is a direct feeder. Thus we generate the association from Comp--Usage to Long-1.

176

H. Song et al. Root url account

getInstancejava...Meory

ObjectName-1

getInstance-java...

JMXConnector

connect

getMBeanServerConnection

ObjectName-2

MBeanServerConnectionMbsc queryNames

queryNames queryNames

ObjectNameMemory getAttributeVerbose

BooleanVerbose

getAttributeHe...ge

CompositeDataSupportHeapUsage getmax

Long-1

queryNames

ObjectNameGcs

getused

getAttributeCollectionCount

LongTotal

Long-2

Fig. 6. The raw meta-model

We write our meta-model inferring algorithm as the pseudocode shown in Algorithm 1. The algorithm first constructs a root class (Line 1). Then it enumerates all the API involved transitions (Lines 2-23) to 1) construct all the VSDs ending up with this transition, and then 2) generate classes and associations. The first step is to trace back from the current transition τ , and construct a set V of all VSDs ending up with τ . It initials V with only one DTG which has only one transition τ (Line 3). If there are still invalid DTGs in V , it takes a Dt that is still not valid (Line 5), finds a place π that make Dt invalid. If π is the output of an involved transition τ  (Line 8), it gets the VSDs ending up with τ  , uses them to expand Dt , and puts the results back into V. If π is the output of n non-involved transitions, it grows Dt with each of these transitions, constructing n new subgraphs. The second step is to create classes and associations. For each constructed VSD Dt stored in V , the algorithm creates a new class cn (Line 15). The method CName calculates the class name by combining the names of the variable and its Java type, like ObjectNameMemory. After that, it enumerates all the direct feeders. For each feeder τ  , it constructs a VSD Dv τ  Dv , finds the class cp generated from Dv (Line 17), and creates an association to link cp with cn (Line 18). The name is calculated by RName, combining the transition signature and the constant inputs, like getAttributeVerbose. Figure 6 shows the complete raw meta-model of our running example.

5

Simplifying the Raw Meta-model

We summarize five automated rules (antipatterns followed by refactoring actions) to simplify the raw meta-model, remove the non-significant or duplicated classes and associations, and weaken the classes into simple data types if they are never used to obtain other data. To formalize these rules, we introduce a new notation named reachability. For two classes c and c in the same meta-model, we say c is reachable from c by r r (noted as c → c ), if there is an association r in c and its type is c . We say c is

Inferring Meta-models for Runtime System Data

177

reachable from c, if there is a sequence of classes to transfer reachability from c ∗ to c , noted as c −→ c . r

Rule 1. Merge equivalent references.

r

name name 1 2 c−→c 1 , c−→c2 , r1 = r2 , c1 = c2 c←c−{r2 →c2 }

According to our generation algorithm, if a class contains two associations with the same name, then that means the client invokes the same method with the same parameter. If the two target classes also have the same name, then that means the developer appoints the same variable name to the invocation results. So we determine the two associations as duplicated, and delete one of them. r

r

1 2 c1 −→c 2 , c2 −→c3 , |c2 .r|=1, c2 .a=φ Rule 2. Remove the forwarding classes. c1 ←c1 −{r1 →c2 }∪{r1 →c3 }

For example, the class ObjectName-1 (as c2 in the above formula) has no other usage except serving as an intermediate during the access from Root to ObjectNameMemory. We remove this forwarding class, and link the two classes. ∗

r

r

1 2 c −→c2 , c2 −→c 3 , c1 −→c3 Rule 3. Remove shortcut references: 1 c1 ←c1 −{r2 →c3 }

After removing ObjectName-1 (according to Rule 1), Root (as c1 ) could reach ObjectNameMemory (c3 ) in two ways: one is through a direct association, and one is through an intermediate class MBSC (c2 ) . That means to obtain an ObjectNameMemory instance, we need both an MBSC instance and its parent, a Root instance. Since an instance’s parent always exists, the second path implies the first one, and thus we remove the direct association. r

1 c1 −→c 2 , c2 .a=φ, c2 .r=φ Rule 4. Weaken the leaf classes to attributes. c ←c −{r 1 1 1 →c2 }∪{a →O(c2 )}

From an instance of ObjectNameMemory (c1 ), we can access an association (r1 ) to obtain an instance of BooleanVerbose (c2 ). This instance does not have its own states nor points to other instances, but only depicts if the memory is verbose or not. Therefore, we regard it as an attribute of ObjectNameMemory. The function O means getting original primitive data type. ∗

→c root Rule 5. Removing dangling classes. P ack←P ack−{c} After applying the previous rules, some associations may be removed, leaving some classes unreachable from Root. We simply remove such dangling classes. For a generated meta-model, we apply the rules iteratively, until it does not satisfy any anti-patterns. Figure 7 shows the simplified result of our running example. This result is quite close to Figure 2(b), ignoring the difference on names. The only structural difference is that we generate a redundant class, MBean--tion, because the current algorithm cannot differentiate control element and data element of the API.

178

H. Song et al. Root url account

getMBean...ion

MBeanServerConnectio... queryNames

queryNames

ObjectNameMemory getAttributeVerbose : EJavaObject

ObjectNameGcs getAttributeCollectionCount : ELong

getAttributeHeapMemoryUsage

CompositeDataSupportHeapUsage getmax : ELong getused : ELong

Fig. 7. The simplified meta-model

6

Implementation and Evaluation

We implement the whole approach on the Eclipse platform, providing an automated meta-modeling tool for runtime system data. Specifically, we utilize Eclipse Java Development Tools (JDT) to represent the source code as an Abstract Syntax Tree, utilize Eclipse Modeling Framework (EMF) to represent the meta-model, and define a simple model to represent DTGs. We also develop an Eclipse plug-in to implement all the algorithms presented in this paper. We evaluate this approach from three aspects. We first present a case study to show that it can be used for realizing runtime model. Then we report a set of experiments to show that it applies to a wide range of systems. Finally, we use two quantitative criteria, namely accuracy and efficiency, to evaluate the above experiments, revealing that the approach generates good meta-models. 6.1

The JOnAS Case Study

Utilizing the meta-modeling tool presented in this paper, we upgrade an original runtime model case on JOnAS [4] with a more complete meta-model, which is automatically inferred from two API clients: 1) an official sample shipped with the release version of JOnAS, and 2) the official web-based JOnAS administration console, jonasAdmin, which organizes and displays the runtime data by HTML pages. The clients and the meta-models are described in Table 1. These generated meta-models work well with the original SM@RT tool, maintaining a runtime model representing the running JOnAS server. We evaluate the validity of this runtime model by a complete traversal on it. This traversal successfully passes through at least one model element for every class2 . The traversal successfully receives a value (including “null”) for almost every attribute, except for 17 ones (out of 424) where the system throws exceptions. The average number of attributes contained by the elements is about 7, and most elements contain less than 10 attributes. The traversal reaches the attributes from the root in about 5 steps on average. A careful analysis reveals that this meta-model covers 46 different types of MBeans, and 361 effective and unique attributes of them. 2

We configured the server carefully, so that it contains all kinds of system data.

Inferring Meta-models for Runtime System Data

179

Table 1. Experiments and results. In experiment design, we list the target systems, their APIs, the clients and their sizes. In result, we show the sizes of the generated metamodels (including the numbers of classes, attributes and references), and the time spent for analyzing. In evaluation, we list the meta-models we choose as references, and the accuracy and efficiency of the generated meta-model, comparing with this reference.

# 1 2 3 4 5 6

6.2

System Glassfish JOnAS JOnAS Equinox Jar WSDD

Experiment design API Client JMX Home-made JMX J2EEMgmt JMX jonasAdmin OSGi Eclipse console BCEL JarToUML DOM Axis Admin

LOC 24 870 16K 5K 3K 813

cls 5 9 59 13 21 8

Result attr ref Time 6 4 2.2 22 10 2.8 424 58 15.2 42 12 19.3 62 20 4.9 23 7 1.8

Evaluation Reference Figure 2 MBeans MBeans Internal classes Official Doc Official Schema

Acc 1 1 0.96 0.80 0.84 0.89

Eff 0.87 0.71 0.89 0.56 0.31 0.88

Experiments and Results

We undertook a set of experiments to see the applicability of this approach, as summarized in Table 1. The first row describes the motivating example. #2 and #3 are the cases mentioned in the above case study. #4 is an attempt to model the bundle information of Equinox platform, and the client is the command-line console provided by Eclipse. #5 is originally a use case of MoDisco [6], aiming to model the Java class structure through byte code files. We utilize the source code of the original implementation on BCEL. #6 is an attempt to model the web service deployment descriptor, utilizing the WSDD analyzer in Axis. For all the experiments, the tool generates meta-models. The size of the metamodel depends on both the size and the function of the client. Regarding the performance, these experiments take 2 to 20 seconds. Since the analysis task only need to performed once for a system, this performance is tolerable. 6.3

Experiment Evaluation

This section evaluates the experimental results, to see whether the approach infers good meta-models for the above experiments. We found a reference metamodel for each system. For the running example, the reference meta-model was the one shown in Figure 2. For #2 and #3, the references were reversely constructed by us according to the final runtime model and our knowledge about JOnAS. When doing this, we carefully examined the runtime model to filter out wrong or duplicated classes and attributes. For #4 to #6, we derived the reference meta-models manually from the internal implementation, the official documents or the XML schema. We evaluate the inferred meta-models by checking if they are close to the reference ones, using two quantitative criteria named accuracy and efficiency. Accuracy assesses how much content in the inferred meta-model also appears in the reference one. For a generated meta-model M and its reference R, we regard their attributes (M.a and R.a) as the definitions to actual system data.

180

H. Song et al.

We determine their subsets M.a and R.a which are the common parts between the two sets of attributes (ignoring difference between names), and define acc(M, N ) = M.a / |M.a|. Efficiency assesses for the same data, the ratio of elements used in the reference meta-model divided by the ones used in the generated one. For M.a ⊆ M.a , we construct a sub meta-model P rune(M, M.a) by pruning M of the attributes that are not in M.a, as well as the classes from which any attributes in M.a cannot be R in the same  reached. We prune   way, and define efficiency as eff (M, N ) = P rune(R, R.a) / P rune(M, M.a). If M and N are isomorphic, accuracy and efficiency all equal to 1. The accuracy declines if we infer wrong definitions. The efficiency declines if we construct duplicated attributes, or redundant classes. We do not evaluate “completeness” here, because the inputted API clients cannot cover all types of system data. As shown in Table 1, The accuracy is generally good: more than 80% of the inferred data types really define the system data. The wrong data are usually caused by regarding control-purpose API accesses as data retrievals. For the clients mainly used for representing data (#3), the accuracy is higher. Although the reference model for #3 is not official defined, the accuracy score is not overestimated, because all the attributes are strictly examined according to the real JOnAS system. The efficiency is not ideal. We infer many duplicated data types, if the client developer used different ways to obtain the same type of data. Take #5 for example, the developer obtains Java classes from different sources, like Jar file, eclipse project, file system, etc., and we wrongly regard them as different types. From the experiments, we learn two things. First, the quality of inferred metamodel depends on the purpose of the client. It is better to choose the client that purely represents system data (like #3). Second, we need further techniques to differentiate data access operations and the configuration operations, as well as the techniques to identify and merge duplicated data types.

7

Related Work

Runtime model is a hot research topic [2]. Its original intention is to introduce model-driven methodology into the runtime stage of the software life-cycle. P. Oreizy et al. [11] utilize software architecture to support the monitor and control of system structures. H. Goldsby et al. [12] use models to help represent and reason about the system and environment states. Many other related approaches can be found in the annual MoDELS workshop named [email protected]. To support such runtime model applications, some researchers are trying to provide generic tool to realize runtime models. Rainbow [3] models the system data based on the input architecture style. Jade [5] represents system data as a Fractal model, guided by the provided Fractal ADL. The MoDisco project [6] provides reusable components for “model discovers” that represent system data as MOF compliant models, according to the MOF meta-models. The authors of this paper also present a SM@RT tool [4] to generate a runtime model synchronizer from a MOF meta-model. These tools all require users to provide a meta-model first. The approach in this paper attempts to provide such meta-models automatically.

Inferring Meta-models for Runtime System Data

181

There is some related work targeting at inferring the data types for XML data [13] or plain text data [14]. The basis for their inference is the “shape” of the target data. Since the runtime system data are intangible, we cannot infer the type based on the data themselves, but on the usage of data. Turning to the techniques, the kernel of our meta-model inference is the static code analysis on API clients. There are related approaches on analyzing the source code of API clients to establish the relation between API types, like Prospector [15] and XSnippet [9]. These approaches tell developers how to reach a specific type of API instance (an object of a class defined by the API). They are not enough for inferring the underlying data types and relations of the management APIs, because API instances of the same type may stand for different kinds of system data. Our idea is also related to the engineering of domain-specific modeling languages: We want to model runtime system data, but different systems provide different types of runtime data. This approach constructs proper meta-models specific to the systems. Our solution of constructing such meta-models from API clients is also similar to FSML [16]. The difference is that FSML focuses on the APIs themselves, but we target at the data hidden behind the APIs.

8

Conclusion

In this paper, we present an automated approach to inferring the type of runtime system data by analyzing the client code of the management APIs. The result data types are defined as MOF meta-models that can be used to construct runtime models for the systems. We successfully use the approach with our previous runtime model supporting tool, and further experiments illustrate that the approach applies to a wide range of systems and the inferred meta-models are close to the reference ones. Note that the inferred meta-model are not complete, only defining the system data covered by the chosen API client. But since many of the clients are the official and widely used management tools, the data covered by them are enough in most cases. The major limitation of the current approach is that its effect depends on the input clients. For the clients that have other functions than representing system data, or retrieving same data in different ways, the approach may infer wrong or redundant data types. We plan to improve this by precise classification of API accesses, as well as more effective duplicate checking. Knowing what kind of data can be accessed is only the first step, we will investigate the way to automatically extract how to access each type of data by slicing the client code according to the meta-model. Acknowledgment. This work is sponsored by the National Basic Research Program of China (973) under Grant No. 2009CB320703; the National Natural Science Foundation of China under Grant No. 60873060, 60933003, 60873060; the High-Tech Research and Development Program of China under Grant No. 2009AA01Z16, 2008AA01Z139; the EU Seventh Framework Programme under

182

H. Song et al.

Grant No. 231167; the Program for New Century Excellent Talents in University; the Science Fund for Creative Research Groups of China under Grant No. 60821003. Thank Prof. Zhenjiang Hu in National Institute of Informatics (Japan) for his early discussion and suggestion on this work.

References 1. Shannon, B.: Java Platform, Enterprise, 5th edn., Specifications (April 2006) 2. Blair, G., Bencomo, N., France, R.: Models@ run.time. Computer 42(10), 22–27 (2009) 3. 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) 4. Song, H., Xiong, Y., Chauvel, F., Huang, G., Hu, Z., Mei, H.: Generating synchronization engines between running systems and their model-based views. In: Ghosh, S. (ed.) MODELS 2009. LNCS, vol. 6002, pp. 140–154. Springer, Heidelberg (2010) 5. Sicard, S., Boyer, F., De Palma, N.: Using components for architecture-based management: the self-repair case. In: International Conference on Software Engineering (ICSE), pp. 101–110 (2008) 6. MoDisco Project, http://www.eclipse.org/gmt/modisco/ 7. Sun Microsystems, http://java.sun.com/javaee/community/glassfish/ 8. Horwitz, S., Reps, T.: The use of program dependence graphs in software engineering. In: International Conference on Software Engineering (ICSE), pp. 392–411 (1992) 9. Sahavechaphan, N., Claypool, K.: XSnippet: Mining for sample code. In: International Conference on Object Oriented Programming, Systems, Languages and Applications (OOPSLA), pp. 413–430 (2006) 10. Ramanathan, M., Grama, A., Jagannathan, S.: Path-sensitive inference of function precedence protocols. In: International Conference on Software Engineering (ICSE), pp. 240–250 (2007) 11. Oreizy, P., Medvidovic, N., Taylor, R.N.: Architecture-based runtime software evolution. In: International Conference on Software Engineering (ICSE), pp. 177–186 (1998) 12. Goldsby, H., Cheng, B.: Automatically Generating Behavioral Models of Adaptive Systems to Address Uncertainty. In: Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., V¨ olter, M. (eds.) MODELS 2008. LNCS, vol. 5301, pp. 568–583. Springer, Heidelberg (2008) 13. Garofalakis, M., Gionis, A., Rastogi, R., Seshadri, S., Shim, K.: XTRACT: a system for extracting document type descriptors from XML documents. ACM SIGMOD Record 29(2), 165–176 (2000) 14. Fisher, K., Walker, D., Zhu, K., White, P.: From dirt to shovels: Fully automatic tool generation from ad hoc data. In: Principles of Programming Languages (POPL), pp. 421–434 (2008) 15. Mandelin, D., Xu, L., Bodik, R., Kimelman, D.: Jungloid mining: helping to navigate the API jungle. In: Programming Language Design and Implementation (PLDI), pp. 48–61 (2005) 16. Antkiewicz, M., Czarnecki, K., Stephan, M.: Engineering of framework-specific modeling languages. IEEE Trans. Software Eng. 35(6), 795–824 (2009)

A Meta Model for Artefact-Orientation: Fundamentals and Lessons Learned in Requirements Engineering Daniel Méndez Fernández, Birgit Penzenstadler, Marco Kuhrmann, and Manfred Broy Technische Universität München, Germany

Abstract. Requirements Engineering (RE) processes are highly volatile due to dependencies on customers’ capabilities or used process models, both complicating a standardised RE process. A promising solution is given by artefactorientation that emphasises the results rather than dictating a strict development process. At such a basis one is able to incorporate domain-specific methods for producing artefacts without having to take into account the variability of process definitions. Although artefacts are known to support customisable development processes, there still is no common agreement about the structure and semantics of artefact-based methodologies. In this paper we discuss different interpretations of the term artefact considering aspects like process integration capabilities and necessities within individual project environments. We contribute a meta model for artefact-orientation that is inferred from two RE models elaborated within industrial cooperation projects of our research group. We conclude with a discussion of performed case studies and ongoing work.

1 Introduction Modelling systems during the development process has become a widely accepted paradigm in the development of software and embedded systems. One goal is, finally, to generate source code from models. Not only in such an approach, where system models are systematically derived from requirements, the precise specification of requirements is crucial. Obviously, if the requirements are to be precisely specified, the structure, syntax and semantics of requirements documentation, that capture various aspects, have to be described, too. Typically, requirements are collected for a specific family of systems (like business information systems), so a systematic interpretation of the basic concepts that respect the needs of the application domain is required. This leads to the tendency of defining a systematic artefact-based requirements engineering (RE) process, where artefact models are used as reference models that capture the domain-specific results of the development steps. In addition to the need of capturing the basic concepts of a domain of application, early stages of development are characterised by volatile or changing project environments due to the dependency to customers’ capabilities, to used process models and to produced specification documents. Also this barrier can be tackled by artefact models since they guide the systematic elaboration of measurable results independent of the chosen development process for the artefacts, i.e. the development result is described independently of the process producing it. D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 183–197, 2010. © Springer-Verlag Berlin Heidelberg 2010

184

D. Méndez Fernández et al.

In a model-based design and development paradigm, however, an artefact is seen as a structured abstraction of modelling elements used as input, output, or as an intermediate result of a process. An artefact has particular properties (structure, behaviour, etc.) and may be precisely described using standardised (semi-)formal modelling concepts. Upon such a description one is able to incorporate different techniques and notions, define clear responsibilities, and support a progress control for the production of artefacts. Hence, as the definition of an artefact model as a backbone supports a customisable process, it has become a well-accepted approach for defining development processes [10]. Internal (micro-) processes are transparent for contract-parties. They agree upon deliverables (artefacts) and do not have to care about the realisation. Furthermore, if artefacts are defined for exchange, development environments can easily be coupled [11], also abstracting from concrete methods or tools. However, a first step towards the definition of an artefact-based methodology for a company-wide use consists in the precise definition of the artefacts and their relations being of interest for a particular development process, in our case for RE. This guarantees that all parties in a project have the same understanding of what will be exchanged within this RE process. Once an artefact model is defined, it is obligatory for customers and all team members working on it. The next step consists in the integration of the artefact-based RE approach into the development process by establishing the associations of requirements artefacts with development contents (process integration). A mandatory prerequisite for this integration is the definition of interfaces. Thereby, compatibility of the artefact-based RE process and the used development process has to be achieved. This means that the RE process has to be described by following the rules of the envisioned development process. Furthermore, the roles relevant for RE have to be harmonised with the roles given by the development process. This achieves finally a seamless integration of RE as an interconnected discipline to architecture, design, code, and quality assurance. Problem Statement. So far, there is no common understanding and agreement about artefact-orientation in general and the term artefact in particular. There are interpretations in the granularity range from general document structures to data models defined using domain-specific languages (DSLs [3]). We believe all perspectives have to be considered in order to address the necessary process integration capabilities and at the same time precision of the artefacts produced within single projects. Although, this problem is understood, so far there exists not enough guidance to tackle it since the definition of an artefact model and the view taken strongly depends on the exact purpose of the artefact model. Contribution. We contribute a meta model for artefact-based RE that results from lessons learned in different cooperation projects of our research group. This meta model is suitable to cover the RE domain, its usual artefacts and relations ready to be integrated into the process. Applying meta modelling on RE means to define a language (respectively an abstract syntax) to model (1) requirements artefact types, (2) artefact structures and dependencies/associations and (3) content items and content relations. Furthermore, operations can be introduced to build concrete exemplars (instances) of particular artefacts in a consistent frame and to provide capabilities for customisation and express variability. To cover all necessary elements of a project, the RE meta model contains structure, information and semantics of not only

A Meta Model for Artefact-Orientation

185

artefacts, but also processes and roles. The meta model is compared to DSL-based modelling [3] a concrete DSL. In contrast to the multi-layered abstraction hierarchy of the Object Management Group (OMG), we position the meta model according to Henderson-Sellers [27] as an abstraction of an artefact-based methodology and not as an abstraction of a modelling language for generating code (like the UML). In general, meta models capture only basic types, therefore a domain-specific interpretation is needed to come up with concrete RE artefacts, e.g. by establishing an artefact-based methodology for the application domain of business information systems. Using a meta model, it is possible to integrate operations to support such interpretations systematically, e.g. commonalities and variabilities according to product line approaches [2], or explicit relations to enhance variability etc. However, meta models can be created in different ways: One option is to create a meta model constructively “from scratch”. This option is usually used in completely new domains by developing DSLs. Another option is to infer a meta model by analysis of existing elements from given domain-specific models. In this paper we use the second variant. We present two RE models that have been elaborated in research projects for two different domains of applications: for the one of embedded systems and for the one of business information systems. We infer in a second step a meta model by analysing and abstracting the results and concepts of the two developed RE models. Hence, we construct a unified framework that benefits the future elaboration of artefact-based RE models. We use this contribution as a basis for tasks, such as domain-specific modelling, process integration and tool-support. We finally discuss the advantages of the approach and its applicability with respect to several performed case studies. Outline. The remainder of this work is organised as follows: In the following Sect. 2 we describe the fundamentals and related work in the areas of our contribution. Section 3 describes two sample RE models that have been elaborated within research cooperations for two different application domains. Both serve as a basis for analysing similarities in Sect. 4. The meta model for artefact orientation is then inferred in Sect. 5. In Sect. 6 we discuss the results for example with respect to performed case studies, before finally giving in Sect. 7 concluding remarks.

2 Foundation and Related Work Method engineering [25] contributes important approaches for the design of domainspecific RE processes. Method engineering deals with the construction of domainspecific methods to deploy modelling techniques for the elaboration of artefacts. The selection of methods according to individual project settings is known as “situational method engineering”, the integration of methods into a development process model is known under the term “method weaving”. Compared to method engineering, where the focus lies on the definition, the selection and the integration of methods into a development process, artefact-orientation gives a more detailed view onto the corresponding results structure with the purpose of enabling seamless modelling of consistent results without having to take into account the variability of volatile processes and the compatibility of methods. Still, while the area of method engineering provides with meta models a clear structure of method-based methodologies, there still is no common agreement on the structure and semantics of artefact-based methodologies.

186

D. Méndez Fernández et al.

There exist different interpretations of same and similar terms, like artefact, work product or product type. Terms like these often co-exist in different process models, such as the referred work products that are described in the rational unified process or the product types that are in scope of the V-Modell XT [23], a German artefact-based development standard for software and systems development projects. Available approaches differ in their understanding towards artefacts and artefact models, whereby artefact models are defined considering different views (Fig. 1): structure models, generic content models, domain-specific content models, and finally integrated modelling theories. The variations of artefact models shown in Fig. 1 are characterised in the following: Structure Models. Structure models include a basic description of general topics and terminology to be considered within a structure reference for documents or data sets. One example is given by the IEEE Std. 830-1998 recommended practice for software requirements specifications [1] that defines a taxonomy as a reference model for the construction of specification documents. Another example is given by the mentioned V-Modell XT, where artefacts are defined from a comprehensive process viewpoint as an abstract result set of an overall development process including for each artefact a taxonomy of general topics and content to be covered. Structure models in general emphasise the structure of the results and aim at a common, standardised understanding on what should be produced in general within individual projects. Generic Content Models. Generic content models define contents, using for example semi-formally structured checklists. Such checklists describe independent of the chosen structure the content to be considered and give guidance for choosing exemplary methods. The Volere requirements specification templates [4] is an example. Still, the semantics of the contents is not precisely defined within such taxonomy-based standards. Hence, they give no guidance with respect to the elaboration of the contents and their interdependencies and fail therefore at guiding the elaboration of (syntactically) consistent artefacts. One step towards this direction in the context of RE has been made with the requirements engineering reference model (REM) [5] of the Technische Universität München and Siemens Corporate Research. REM defines the structure of goals, requirements and specifications within a proposed taxonomy-based guideline and informally describes dependencies between the guideline elements based on proposed refinement principles. REM was not developed for a specific domain of application. Existing approaches like the introduced ones use models only to

Fig. 1. Variations of Artefact Models and Implications

A Meta Model for Artefact-Orientation

187

establish a generic reference model of the general content and relations to be considered. Still, those models provide no concrete information about the possible concepts like for constructing use case models and thereby they do not formally capture the interdependencies between the concepts like the dependency of use case models to actor descriptions. In fact, the description of concrete concepts strongly depends on a chosen domain of application what leads to domain-specific content models. Domain-specific Content Models. The next step in the direction of formalisation are domain-specific content models that abstract from the content of documents and data sets of a particular domain of application. In such approaches, modelling concepts, including types and dependencies, are used to describe artefacts and complex artefactbased systems. Here also a formal syntax and bits of semantics are used to define artefacts’ structure, their creation, and content. On this level of abstraction, (domainspecific) modelling languages can be defined [3,6,7] using, e.g., data models for their representation. These data models provide the possibility to specify the desired amount of redundancy of contents. Furthermore, one is able to establish a comprehensive tool support on this level, as data models are available for computing. Schätz describes in [17] the possibilities of additionally enriching domain-specific concept models with conformance constraints in order to guide the elaboration of RE models at project-level (as known from the area of automated model-driven approaches). Thereby, he ensures quality within those models in terms of ensuring conformance of the models being produced within a project to the reference model. In particular, the application of conformance constraints to the concept model benefits the domainspecific awareness of the results in terms of ensuring syntactic completeness and consistency in a tool-supported manner. How conformance constraints are defined, depends on the chosen quality assurance techniques. One possibility is to define the conformance constraints in terms of logic-based formalisms, as done in [8]. Integrated Modelling Theory. Mathematical models give the most formalised view onto artefact models and are often used to precise a comprehensive modelling theory. For instance, by defining properties of modelling concepts like “services” and mathematical relations to other concepts like “business processes” and, thus, they create a semantic foundation for commonly used terms. Mathematical models mostly offer their own syntax or are used as a basis for the definition of a syntax with a precise mathematical meaning (see e.g. Focus, [8]). Since the elements to be produced within a project are all defined according to the mathematical model, the syntactic consistency is ensured. Summarised, the definition of an artefact model and the understanding of the term artefact strongly depends on the purpose of the model [18], e.g. concerning the coupling of different tools or concerning the definition of a flexible process model. Some of the resulting views onto an artefact exclusively focus on structure of artefacts and some (although implicating also a notion of structure) emphasise the content. Each of the given views implies going in Fig. 1 from left to right a higher degree of operationability and precision in the design of an artefact model. Precision considers the structure and the content of specifications from which the models abstract for a particular domain of application. The higher the degree of precision (as given by the latter examples), the higher the enforcement of syntactic consistency as artefact models are used as a domain-specific reference model for a particular syntax. At the same time

188

D. Méndez Fernández et al.

the less the degree of flexibility. For practical usage, the establishment of domainspecific concept models has become a wide accepted technique, mostly arising from the benefit of enabling seamless modeling. Seamless modelling is enabled because such models do not only describe how a RE model is structured, but also how valid instances are created. For valid instances, all artefacts based on the defined reference model are created the same way and all artefacts of the same type have the same basic structure (e.g. each use case has at least one actor assigned, a detailed description of what this use case is good for, …). This information is a basic component to build up interfaces to other (process) disciplines and their artefacts and to provide finally toolsupport in a project. Therefore, defining artefact models from this perspective, a process-integrated, seamless and tool-supported modelling of requirements is possible, what finally is not in scope of the area of method engineering.

3 Requirement Engineering Approaches This section describes two concrete samples of requirements engineering approaches that have been elaborated in recent research projects. We first describe the REMsES project considering a RE model for embedded systems and afterwards the REMbIS project considering the domain of business information systems. Similarities of both models are analysed in detail in Sect. 4 in order to infer a meta model for artefact orientation in Sect. 5. 3.1 REMsES The REMsES project was a research collaboration with partners from academia and industry (see http://www.remses.org). Goal of the project was the elaboration of a practical guide for systematic requirements engineering and management of embedded systems, especially in the automotive domain [12]. The result is an approach with a reference artefact model (see Fig. 2). This reference model is based on two key concepts: support for abstraction levels and coverage of three content categories. The structure supports requirements engineers in determining which type of model they should use and what kind of abstractions they should create in a particular project. Coverage of Abstraction Levels. Requirements at different levels of detail, ranging from business goals to fine-grained technical requirements (e.g. concerning the system hardware), need to be included in the requirements document. High-level requirements provide a justification for detailed requirements and support the understandability of the requirements. Low-level requirements are needed to provide enough information for implementing the system correctly. In the REMsES project, a hierarchy of three abstraction levels was adopted: system level, function groups level, and HW/SW level. The abstraction levels form the vertical dimension of the structure shown in Fig. 2. At the System Level, the stakeholders have a black box view of the system. RE artefacts modelled at this levels focus on the system usage by humans and other systems, but no system-internal or auxiliary functions are considered. The Function Groups Level represents a whitebox view of the system. At this level, the system is viewed as a network of interacting, logical units

A Meta Model for Artefact-Orientation

189

Fig. 2. REMsES Artefact Model

obtained by a functional decomposition of the system. These function groups have defined interfaces and can interact with each other as well as with the environment. At the Hardware/Software Level, a coarse-grained partitioning of the system’s functionality into HW and SW is defined. For this purpose, a system is decomposed into a (coarse-grained) HW topology and SW architecture. Coverage of 3 Content Categories. By analysing RE documents in the automotive domain, three main content categories were identified: context, requirements, and (high-level) design. The categories context and design contain important information for the RE process and therefore have a considerable influence on the requirements. The content categories relate to the horizontal dimension of the structure shown in Fig. 2. The three categories are defined orthogonally to the abstraction layers. The Context of the system is the part of the real world that influences the system requirements. Context artefacts are laws, business goals, general constraints, environmental conditions, etc. The context sets the frame in which the system is developed. Requirements are expressed using modelling concepts. Three types of such concepts, i.e. goal models [13], scenario models [14], and function models [15], are identified as the most important models for supporting the RE process of embedded systems. Design as the third part plays an important role. In the development of embedded systems, requirements and design are tightly intertwined, because the knowledge about major system components is inevitable to specify detailed requirements. By introducing design explicitly as a content category, we support developers in documenting requirements and design as separate models, rather than intermingling the two. 3.2 REMbIS REMbIS results from a research corporation between the Technische Universität München and Capgemini sd&m AG. REMbIS is a model-based RE approach for the

190

D. Méndez Fernández et al.

application domain of business information systems. It consists of (1) an artefact abstraction model that defines horizontal abstraction and modelling views, (2) a concept model that defines those aspects dealt with during construction of models including the definition of possible notions for producing the models and finally (3) a method description that defines the activities and tasks of the RE process. Each submodel is subsequently described. Artefact Abstraction Model. The artefact abstraction model defines horizontal levels of abstraction that represent the stages of refinement of different RE-specific results. Modelling views structure each level according to environment, behaviour, structure and information. The levels and the views serve as a basis for traceability among the results. The left side of Fig. 3 depicts the artefact abstraction model of REMbIS, while embedding exemplary concepts (denoted by the boxes). The levels are divided into two major areas concerning the description of an organisation’s and business structure (the upper three layers) and the compliant description of requirements for the underlying IT infrastructure (the last depicted levels). The organisation’s context defines high-level long-term steering principles and objectives of a company. The business process hierarchy describes the organisation’s structure, including a taxonomy of the main offered business activities. Derived from this structural view, the business process logic emphasises the internal realisation of the activities in terms of a business process model that defines a workflow description including interchanged information and participating roles. The information system service hierarchy defines the external behaviour of single systems by defining what business processes shall be supported by the system. It defines uservisible characteristics of the system by means of an (information system) service description and a use case model. The information system’s constraints capture single quantified requirements that address the system in its applications, architecture and environment.

Fig. 3. Excerpt of the Artefact Models and the Concept Model of REMbIS

A Meta Model for Artefact-Orientation

191

Concept Model. The concept model defines all elements and relations of used modelling techniques for the construction of domain-specific RE models in individual project environments (such as structure and content of use case models and their relation to service models). For each of the concepts, the approach includes a description of recommended modelling languages. The right side of Fig. 3 shows an excerpt of the concept model defining the contents of the information system service hierarchy. The concepts shall not be discussed in detail, but illustrate how the model serves as a basis for defining the terminology and consistency rules of all produced entities of a project. Methods. Based on the concept model, REMbIS offers a description of all the tasks performed in order to use, modify and produce selected concepts, enriched with best practices that provide a set of chosen notions for constructing the concepts.

3 Analysis and Inference Based on the two project samples described above, we analyse both approaches with respect to their similarities. This first step is aimed at abstracting from the specialities of the variants to identify similarities. Based on the results, we infer a basis for defining a meta model for artefact orientation in the following section. Table 1 illustrates a summary of both RE models, REMsES and REMbIS, which are subsequently compared according to different scopes. Domain. The two approaches have been elaborated for different domains of application: REMsES for the one of embedded systems, REMbIS for the one of business information systems. As a consequence, the meta model shall not be described using any domain-specific aspects. Refinement. REMsES and REMbIS both offer means to refine the results of RE over different domain-specific degrees of abstraction. For each of the described degrees of abstraction, a subset of the results is grouped according to either content category or view, where both describe common characteristics of different contents. Hence, the least common denominator is the necessity of describing vertical and horizontal abstraction for RE models. Table 1. Analysis of the Example Models with respect to core Issues Scope Domain

REMsES Embedded Systems

Refinement

Refinement over abstraction layers and content categories Focus on structural aspects and notations

Results

Methods

Specification techniques and process close to RUP

Roles

Coarse-grained definition

REMbIS Business Information Systems Refinement over abstraction levels and modelling views

Superset Generic, domainindependent approach Abstraction levels and views

Concept models abstracting from description techniques and notions Set of specific tasks (methods), checklists and milestones inspired by RUP Roles coupled to concepts and tasks

Artefact types separating structure and content with syntax Process interface to couple methods and artefacts Interface to assign roles and artefacts

192

D. Méndez Fernández et al.

Results. REMsES emphasises the structure of the results and syntactical possibilities for producing them. A major benefit is easy integration within process structures, because workflow entities can be coupled to cohesively described results. Instead, REMbIS defines a concept model based on the elements of domain-specific modelling techniques with focus on consistency among the results rather than on process integration. As a consequence, REMbIS has been defined in a process-agnostic manner and features an indirect overall structure that results from the dependencies between the concepts. Each content concept lays the foundation for choosing a specific syntax. The explicit distinction between structure and content enables a process integration and at the same time consistency among the results. Methods. Both approaches offer a set of specification techniques and follow a process integration in terms of defining an abstract sequence of producing the results. In particular, REMsES defines concrete tasks and a coarse-grained integration into a general development process. REMbIS defines milestones and tasks both coupled to the results, but does not define any specific process. Hence, the meta model shall offer a description of a generic process model that allows to couple methods to results without dictating a concrete process. Roles. Roles are defined both in REMsES and REMbIS, but REMbIS additionally provides their assignment to concepts and tasks.

4 Meta Model for Artefact-Oriented RE As we identified a common superset for the two RE models, we are now able to infer a meta model that describes a language for the artefact-oriented paradigm. Fig. 4 illustrates the artefact-oriented RE meta model, which is structured into single submodels. These sub-models define major areas of concern with a specific set of connectors (association classes) in between these areas. This modular structure fits to the aspects identified in Sec. 4 and an ease modification of the single identifies areas. We subsequently describe the single sub-models: the artefact model, the artefact abstraction model, the generic process model and finally the generic role model. Artefact Model. The artefact model builds the backbone by defining structure and content of domain-specific results of RE activities. The structure addresses the aspects of hierarchically ordered documents or data sets being produced during development tasks in which single content items serve as containers for the concepts, respectively concept models. The concept models (the artefacts’ content) define according to Schätz those aspects of a system under consideration dealt with during the development process [16] and reflected in the elements of the description techniques and their relations [17]. How the models are exactly defined depends on the chosen application domain from which the selection of description techniques arises (thereby often referred to as domain models). Based on these differentiating angles from which an artefact is tackled, we define an artefact as follows: An artefact is a deliverable that is produced, modified, or used by a sequence of tasks that have value to a role. Artefacts are subject to quality assurance and version control and have a specific type. They are hierarchically structured into content items

A Meta Model for Artefact-Orientation

193

that define single areas of responsibility and that are the output of a single task. Each content item encompasses at its lowest level of decomposition: 1. A concept defines the elements and their dependencies of domain-specific description techniques used to represent a content item concern. Concepts have a specific type and can be decomposed to concept items. The latter differentiation is made if different items of a concept can be described with different techniques. 2. The syntax defines a concrete language or representation that can be chosen for a specific concept. 3. The method (or task) describes the sequence of steps that is performed in order to make use of a concept. When discussing artefacts, we usually refer to artefact types (“requirements specification”) rather than to a specific artefact (“requirements specification ’Travel Ordering System’”). Similarly, when discussing concepts, we refer to concept types (“Use Case”) instead of specific concepts (“UML Activity Diagram: ’Search Hotel’”). Furthermore, each artefact has dependencies. We distinguish between content dependencies and structural dependencies. The structural dependencies are defined by composition, as an artefact type is decomposed into several content items (e.g. representing chapters within the specifications). For complexity reasons the content dependencies are not restricted by specific types within the meta model. Hence, as the content dependencies are not typed, the domain-specific instances need a definition of conformance constraints. A possibility to define such constraints is given by the use of the Object Constraint Language (OCL) for supporting the conformance of the models being created in a project to the reference models in a tool-supported manner.

Fig. 4. Meta Model for Artefact-Orientation

194

D. Méndez Fernández et al.

Note that the conformance of domain-specific instances to the meta model at hand is given, if these are described in the language defined by the meta model. Artefact Abstraction Model. The artefact abstraction model defines the domainspecific abstraction that refers to the construction and refinement (and / or decomposition) of the artefacts. We distinguish between (1) horizontal abstraction, that reflect aspects like structure, behaviour or roles and referred to as modelling views [19] and (2) vertical abstraction that describes, for each of the views, the refinement and / or decomposition of corresponding artefacts, also referred to as levels of abstraction [20,21]. These levels of abstraction have specific characteristics that match with the degree of detail of an artefact’s underlying concept and its concern. Generic Process Model. The generic process model defines all entities of a workflow description that can be used to define a specific process. In particular, we define (1) milestones in terms of a point in time in which an artefact or content item should be completed and (2) tasks that build a part of phases and activities. A phase (e.g. requirements engineering) defines a repeatable set of activities which, in turn, define major areas of concerns (e.g. requirements elicitation). For such an area of concern, there exist several tasks where each consists of a sequence of atomic steps that are performed by a role in order to produce, modify and / or use an artefact as input or output. Hence, a task is a method in the sense as it is defined in the area of method engineering [22]. A task supports the selection of which artefacts are needed as basis for modifying or producing further artefacts by the choice of a specific syntax. The generic process model also describes the interface to be used for integrating the RE meta model into a development process model. Model elements such as milestones are underspecified, as precise descriptions have to be delivered by the process model. Generic Role Model. The generic role model describes a logical representation of the individuals who directly participate in or indirectly contribute to the development process. A role has the responsibility for at least one artefact while performing a set of activities. Similar to the process model, the generic role model is underspecified, as the instance role model has to be provided by the development process.

5 Discussion With the meta model, presented in Sect. 5, we define a language for artefact-oriented RE. This language provides applicable guidelines for domain-specific RE models that support consistency and completeness within the results across different projects, continuity within the process and variability in the process definitions. Syntactic Consistency and Completeness. Using the proposed language for the description of domain-specific RE models supports syntactic and semantic consistency and completeness among the results of RE. Syntactic consistency and completeness include the restriction of possible description techniques (by defining concept models) and thereby lay the foundation for consistency and completeness conditions with respect to the choice of a syntax. In explicit, the RE model answers the question “How is the syntax of artefact A related to the syntax of artefact B?”. Semantic consistency means consistency between project-specific contents, i.e. it provides an answer to the

A Meta Model for Artefact-Orientation

195

question “Does the statement of artefact A fit to what the model of artefact B declares?”. This can not be handled by an artefact model, but verification of semantic consistency requires syntactical consistency. Continuity. Artefact-orientation fundamentally enables continuity within the development process. As the concept model provides the basis for seamless modelling, the process that is coupled to the artefact model provides a continuous workflow when elaborating the artefacts. Variability supporting Customisation. Artefact-orientation tackles the problem of variability in designing a process within volatile environments. The meta model offers a modular structure and supports process integration capabilities, i.e. the customisation of artefact-based RE models at organisational levels by integrating them into development processes for particular companies. This process integration can be performed for example with the V-Modell XT [23], a meta model-based German standard for software & systems development, by integrating single elements over the association classes into the organisation-specific process models (see also Sect. 5). In general, the connections given by several association classes state what connection points have to be available (obviously, a meta model-based development process model is a mandatory prerequisite for integrating the RE meta model). The artefact-centric view unifies the definition of taxonomy-based structures of documents or data sets and the definition of domain-specific modelling concepts (content). In a second step, we couple all elements of a process model to the artefact model. Therefore, while methodbased methodologies face problems with respect to syntactic variability during the integration of new methods, artefact-oriented approaches support a systematic integration of methods by innately restricting the results’ contents and therefore indirectly the possibilities of selecting methods producing them. As each domain-specific RE model derived from the meta model exhibits the same modular structure, it satisfies the needs of customisation at project level in addition to process integration capabilities. Therefore, it serves as a reference model that guides through the elaboration of the results of RE being compliant to the RE model. Moreover, it can be customised according to varying project parameters that strongly affect the elaboration of single artefacts. Therefore, it tackles the deficiencies of process-driven approaches. Trade-Off between Precision and Flexibility. When establishing an artefact-based approach supporting an efficient and effective RE process, there is a trade-off between flexibility and precision: The more options are provided for syntax or concepts, the higher is the variability with respect to the relations between artefacts and the more complex is the verification of consistency. The higher the restrictions for syntax, the more suffers the flexibility for applying the models at variable project-levels due to making knowledge explicit. Referring to Fig. 1, there is a conflict between a general and a precise view. The more precision there is in the chosen way of defining an artefact model, the more capabilities there are in gaining consistency and completeness within the models considered compliant to the artefact models. Following the provided meta model of Sect. 5, artefact models perform therefore a unique combination of two views, the view onto content and dependencies via concept models embedded into a second taxonomy-based structure view. The necessary degree of flexibility is ensured while the degree of variability when constructing and representing the content decreases since we still have restrictions on the content and the syntax.

196

D. Méndez Fernández et al.

Evaluation in Case Studies. The introduced meta model is suitable to cover the stated needs since it abstracts from two concrete RE models that both have been evaluated in industry. The REMsES approach was evaluated in case studies, student experiments, and pilot projects at the sites of the industrial partners (see also [26]). The REMbIS approach is fully integrated into the development process of Capgemini sd&m AG. Their engineers have been trained on REMbIS in seminars and constantly apply it in custom software development projects in which an evaluation can not be published for reasons of confidentiality. The meta model was the basis for the development of BISA that offers customisation capabilities for process integration and project-specific customisation. The latter is performed by customising the artefact model according to project parameters that influence the possibilities and necessities of elaborating single artefacts to which the parameters are coupled (see also [28]). The process integration has been performed with the V-Modell XT, a meta model based standard process including a comprehensive tool chain. The resulting integrated, customisable VM BISA [24] has successfully been applied in a project hosted by Siemens.

6 Conclusion This paper concentrates on the paradigm artefact-orientation in requirements engineering and presents a meta model. This meta model is inferred from two concrete domain-specific RE models of our research group in two application domains: embedded systems and business information systems. Both RE models have been evaluated in real-life projects and thereby validated with respect to applicability. We outlined the advantages of artefact-orientation. Taking an artefact model as backbone of project execution benefits (1) syntactic consistency and completeness of the results being compliant to the domain-specific reference model, (2) seamless modelling of the results and continuity within the development process chain and, (3) can be customised to individual needs. Such a customisation can be performed at organisational level in terms of process integration and at project level by adapting domain-specific artefact models according to the influences of individual project environments. The integration into a comprehensive process framework and the definition of a customisation approach considering the project level is performed in [24] and successfully applied in a project hosted by Siemens.

References [1] Recommended Practice for Software Requirements Specifications. IEEE Std 830-1998 [2] Rombach, D.: Integrated Software Process and Product Lines. In: Li, M., Boehm, B., Osterweil, L.J. (eds.) SPW 2005. LNCS, vol. 3840, pp. 83–90. Springer, Heidelberg (2006) [3] Greenfield, J., Short, K.: Software Factories. Wiley and Sons, Chichester (2004) [4] Robertson, J., Robertson, S.: Volere Requirements Specification Templates-Edition 11 (August 2007), http://www.volere.co.uk [5] Geisberger, E., Broy, M., Berenbach, B., Kazmeier, J., Paulish, D., Rudorfer, A.: Requirements Engineering Reference Model. Technische Universität München (2006) [6] Gronback, R.: Eclipse Modeling Project. Addison-Wesley, Reading (2009)

A Meta Model for Artefact-Orientation

197

[7] Steinberg, D., Budinsky, F., Paternostro, M., Merks, E.: EMF -Eclipse Modeling Framework. Addison-Wesley, Reading (2009) [8] Schätz, B.: The ODL Operation Definition Language and the Autofocus/quest Application Framework AQUA. Technische Universität München (2001) [9] Ameluxen, C., Rötschke, T., Schürr, A.: Graph Transformations with MOF 2.0. In: 3rd International Fujaba Days (2005) [10] Managing Successful Projects with Prince 2. Office of Government and Commerce (2009) [11] Kuhrmann, M., Kalus, G., Chroust, G.: Tool-Support for Software Development Processes. In: Social, Managerial, and Organizational Dimensions of Enterprise Information Systems. IGI Global (2009) [12] Penzenstadler, B., Sikora, E., Pohl, K.: Guiding Requirements Modelling in the Embedded Systems Domain with an Artefact Reference Model. In: REFSQ (2009) [13] van Lamsweerde, A.: Requirements Engineering: From Craft to Discipline. In: SIGSOFT 2008/FSE-16: Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of Software Engineering, pp. 238–249. ACM, New York (2008) [14] Cockburn, A.: Writing Effective Use Cases. Addison-Wesley Longman Publishing Co., Inc., Boston (2000) [15] Davis, A.M.: Software Requirements: Objects, Functions, and States. Prentice-Hall, Inc., Upper Saddle River (1993) [16] Schätz, B., Pretschner, A., Huber, F., Philipps, J.: Model-Based Development of Embedded Systems. In: Bruel, J.-M., Bellahsène, Z. (eds.) OOIS 2002. LNCS, vol. 2426, pp. 298–311. Springer, Heidelberg (2002) [17] Schätz, B.: Model-Based Development of Software Systems: From Models to Tools. Habilitation, Technische Universität München (2008) [18] Endres, A., Rombach, H.: A Handbook of Software and Systems Engineering: Empirical Observations, Laws and Theories. Addison-Wesley, Reading (2003) [19] Broy, M., Schätz, B., Wild, D., Feilkas, M., Hartmann, J., Gruler, A., Penzenstadler, B., Grünbauer, J., Harhurin, A.: Umfassendes Architekturmodell für das Engineering eingebetteter software-intensiver Systeme. Technische Universität München (2008) [20] Gorschek, T., Wohlin, C.: Requirements Abstraction Model. Requir. Eng. 11(1), 79–101 (2005) [21] Ramesh, B., Jarke, M.: Toward Reference Models for Requirements Traceability. IEEE Trans. Softw. Eng. 27(1), 58–93 (2001) [22] Braun, C., Wortmann, F., Hafner, M., Winter, R.: Method Construction -a Core Approach to Organizational Engineering. In: SAC, pp. 1295–1299. ACM, New York (2005) [23] V-Modell XT (2008), http://v-modell-xt.de/ [24] Mendez Fernandez, D., Kuhrmann, M.: Artefact-based Requirements Engineering and its Integration into a Process Framework. Technische Universität München (2009) [25] Brinkkemper, S., Joosten, S.: Method Engineering and Meta-Modelling. Special Issue. Information and Software Technology (1996) [26] Braun, P., Broy, M., Houdek, F., Kirchmayr, M., Müller, M., Penzenstadler, B., Pohl, K., Weyer, T.: Entwicklung eines Leitfadens für das Requirements Engineering softwareintensiver Eingebetteter Systeme. Technische Universität München (2009) [27] Gonzalez-Perez, C., Henderson-Sellers, B.: A Powertype-based Metamodelling Framework. Software and Systems Modeling 5, 72–90 (2006) [28] Mendez Fernandez, D., Wagner, S., Lochmann, K., Baumann, A.: Field Study on Requirements Engineering Artefacts and Patterns. In: Proceedings of 14th International Conference on Evaluation and Assessment in Software Engineering, Staffordshire, UK (2010)

A Common Framework for Synchronization in Requirements Modelling Languages Shahram Esmaeilsabzali, Nancy A. Day, and Joanne M. Atlee Cheriton School of Computer Science University of Waterloo Waterloo, Ontario, Canada, N2L 3G1        

Abstract. The ability to describe synchronization between the components of a model is a fundamental primitive in modelling languages. After studying existing modelling languages, we discovered that many synchronization mechanisms can be organized into a common abstract framework. Our framework is based on a notion of synchronization between transitions of complementary roles. It is parameterized by the number of interactions a transition can take part in, i.e., one vs. many, and the arity of the interaction mechanisms, i.e., exclusive vs. shared, which are considered for the complementary roles to result in 16 synchronization types. We describe how many modelling constructs, such as multi-source, multidestination transitions, many composition operators, and many workflow patterns are forms of synchronization. By generalizing and classifying synchronization types independently of a particular language, our goal is to enable language designers to adopt an appropriate synchronization type for a domain e«ectively.

1 Introduction The ability to describe synchronization between the components of a model is a fundamental primitive in modelling languages. Process algebras, such as CSP [9] and CCS [14], make synchronization the focus of the model. Requirements modelling languages, such as statecharts [8, 18], its variants [2], and UML StateMachines [16], have generally been more centred around behaviour described using events, guards, and actions on variables. The concurrency primitives included in these languages usually have little or no explicit synchronization mechanisms. In some cases, syntax such as multi-source and multi-destination transitions hides a form of synchronization. However, models of systems can often be more precisely and concisely expressed when using explicit synchronization mechanisms. Inspired by the clean and useful synchronization mechanisms of process algebras, our goal is to understand the role of synchronization in big-step modelling languages (BSMLs). In previous work, we introduced the term BSMLs to describe a popular class of requirements modelling languages, where the model’s reaction to an environmental input is described as a big step consisting of a sequence of small steps each with possibly multiple, concurrent transitions [5, 6, 4]. We found that while the BSML family has many variations of ways in which generated events trigger transitions in subsequent small steps, in general, they are lacking in the means to describe how transitions should D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 198–212, 2010. c Springer-Verlag Berlin Heidelberg 2010

­

A Common Framework for Synchronization in Requirements Modelling Languages

199

be synchronized together within a small step. In this paper, we extend the family of BSMLs to support di erent types of synchronization. In studying the potential use of synchronization mechanisms in BSMLs, we find that there are many di erent possible synchronization types and that we can organize the design space of these options using a language-independent, parameterized framework. Our framework is based on a notion of synchronization between transitions of complementary roles, analgeous to CCS [14]. Our framework is parameterized by the number of interactions a transition can take part in, i.e., one vs. many, and the arity of the interaction mechanisms, i.e., exclusive vs. shared, which are considered for both complementary roles to result in 16 types of synchronization. In this paper, we focus on the applications of these synchronization types in requirements modelling languages. Our framework allows us to show how many modelling constructs, such as multi-source, multi-destination transitions [8, 18], many composition operators [15], many workflow patterns [1], and a notion of signal [17] are forms of synchronization. Furthermore, our framework gives us a vocabulary for including a variety of types of synchronization in one model. Compared to previous work on classifying synchronization mechanisms, our work describes a di erent (cf., [10]) or a larger (cf., [15]) set of synchronization types; it allows multiple types to be used within one model; and it is focused on BSMLs. Our contribution in this paper is threefold. First, we present a framework for classifying synchronization types in a language-independent way. Second, we introduce the family of synchronizing big-step modelling languages (SBSMLs) that combine existing BSMLs with synchronization capabilities. Third, we demonstrate the usefulness and generality of our framework by describing how many modelling constructs are forms of synchronization that can be expressed using the synchronization types of SBSMLs. By generalizing and classifying synchronization types independently of a particular language, our framework allows language designers to consider the synchronization types appropriate for a domain in relation to other modeling concepts found in the domain without historical syntactic and semantic dependencies found between language constructs. Thus, a language designer can choose and adopt an appropriate synchronization type for a language in a domain e ectively. The remainder of the paper is organized as follows. Section 2 briefly describes the syntax and the semantics of BSMLs. Section 3 presents our synchronization syntax in SBSMLs, our framework of 16 synchronization types, and the role of these synchronization types in the semantics of SBSMLs. Section 4 presents how synchronization can describe the semantics of various modelling constructs. Section 5 considers related work, including the comparison of our work with languages that are specialized for specifying deterministic behaviour. Section 6 concludes the paper, laying out the direction of our future work.

2 Background: Big-Step Modelling Languages (BSMLs) In this section, we present an overview of the common syntax and semantics of BSMLs [5, 6, 4]. We adopt a few syntactic definitions from Pnueli and Shalev’s work [18]. A BSML model is a graphical, hierarchical, extended finite state machine, consisting of: (i) a hierarchy tree of control states, and (ii) a set of transitions between them.

200

S. Esmaeilsabzali, N.A. Day, and J.M. Atlee

A control state has a type, which is one of And, Or, or Basic. All Basic control states of a model, and only they, appear at the leaves of the hierarchy tree of the model. A control state is compound if its type is either And or Or. Each compound control state has a set of child control states. A control state that is a child of another control state through transitivity is its descendant. Similarly, the parent and ancestor relations are defined with their usual meanings. In the graphical representation, the children of an And control state are separated by dashed lines. Fig. 1 shows an SBSML model that we use to describe the syntax and semantics of BSMLs and SBSMLs. The model characterizes a set of simple synchronized ice skating programs. Initially, all skaters are together, represented by the Basic control state Together. During the program, the skaters can split into three groups to perform the intersection maneuver, represented by the And control state Intersection.1 To avoid a clash, at each point of time, only one of the three groups can initiate an intersection maneuver. Control states Group1 , Group2 , and Group3 are Or control states, and are the children of control state Intersection. The skaters can merge back into a group, but the program can only end by a transition to the End control state, when the skaters are split. Each Or control state has a default control state, which is one of its children that is graphically signified by an arrow without a source control state; e.g., the default control state of control state Group1 is G11 . The least common ancestor of a set of control states is the lowest (closest to the leaves) control state in the hierarchy tree such that each of the control states is its descendant. Two control states are orthogonal if neither is an ancestor of the other and their least common ancestor is an And control state; e.g., Group1 and Group2 are orthogonal. Intersection : t3: Split t2: Circle

Group1

t5: x

G11

(x) Group2

t8: x

G21

Group3

t11: x

G31 t14: Finish End

Together t7: x

t10: x t6: x

t1: Line

G12

t13: x t9: x

G22

t12: x G32

t4: Merge

Fig. 1. A model for a set of synchronized ice skating programs

Each transition has a source control state and a destination control state. Additionally, a transition can have: (i) enabling conditions, in the form of an event trigger, which is the conjunction of a set of events and negations of events, and a guard condition, which is a boolean expression over variables; and (ii) a set of actions, in the form of variable assignments and generated events. For example, in the model in Fig. 1, the source and destination control states of t3 are Together and Intersection, respectively; its event trigger is Split. A transition is a self transition if its source and destination control states are the same; e.g., transitions t1 and t2 are self transitions, which represent the circle and line maneuvers, respectively.2 Two transitions are orthogonal if their source control states are orthogonal, as well as, their destination control states; e.g., t5 and t9 . 1 2

In the intersection maneuver, the skaters in one group skate between the skaters of another. In these maneuvers, the skaters create a formation in a circle and a line pattern, respectively.

A Common Framework for Synchronization in Requirements Modelling Languages

201

A BSML semantics specifies how the reaction of a model to an environmental input is computed as a big step. A big step is an alternating sequence of snapshots and small steps, which ends when there are no more enabled transitions. At a snapshot of a model, there could exist multiple potential small steps, each of which can be taken as the next small step. Each small step is the execution of a maximal set of transitions that are enabled and pairwise orthogonal. Each snapshot captures the information about the state of the model, including the control states that the model resides in, the statuses of events, etc., which determine the enabledness of a transition. If a model resides in an And control state, it resides in all of its children. If a model resides in an Or control state, it resides in one of its children. The execution of a small step of a model updates the current snapshot of the model to a new snapshot that captures the e ects of executing the transitions in the small step. If the destination control state of a transition in a small step is a compound control state, the default arrows are followed to determine the control states of the next snapshot. As an example, when the model in Fig. 1 resides in control state Together and environmental input events Circle and Split are received, either of the two potential small steps t2  and t3  can be taken, arriving at control state Together or Intersection, respectively. There are many variations in the semantics of how a BSML determines the enabledness of a transition and its execution e ects [5,6,4].

3 Synchronizing Big-Step Modelling Languages (SBSMLs) In this section, first, we introduce our synchronization syntax for SBSMLs. We then present our parametric classification of 16 synchronization types together with a description of their roles in the semantics of SBSMLs. 3.1 Synchronization Syntax A compound control state of an SBSML (both And and Or control states) can have a set of synchronizers, which are graphically positioned at the top of the control state. For example, the control state Intersection in the model in Fig. 1 has one synchronizer: (x). Each synchronizer Y(L) has: (i) a synchronization type, Y; and (ii) a label set, L, surrounded by parentheses, instead of curly brackets. There are 16 synchronization types, each of which is a string of four letters, where a letter represents an aspect of the semantics of the synchronization type. The label set of a synchronizer declares a unique set of identifiers (labels) that are used by transitions that are to be synchronized by the synchronizer. In the model in Fig. 1, synchronizer (x) has synchronization type , and declares the identifier x in its label set x. A transition in an SBSML model can have: (i) a set of role sets, and (ii) a set of co-role sets. Each role set is a set of labels, each of which is an identifier. Each corole set is a set of co-labels, each of which is an over-lined identifier. For example, in the model in Fig. 1, the set of role sets of t6 is x and the set of co-role set of t8 is x. The well-formedness criteria of SBSMLs, summarized at the end of this section, require that all of the labels (co-labels) of a role set (co-role set) are associated with the identifiers of the same synchronizer. When the set of role sets or the set of co-role sets of a transition is a singleton, its curly brackets are dropped. A role set is called uni-role if it is a singleton and poly-role otherwise. Similarly, a co-role set is called uni-co–role

202

S. Esmaeilsabzali, N.A. Day, and J.M. Atlee

or poly-co–role. For example, the only role set of t6 is a uni-role. Transitions t6 , t8 , and t11 can execute together because synchronizer (x) match their role and co-role sets. 3.2 Synchronization Types and Semantics A synchronization type consists of a sequence of four letters, each of which is a value for one of the four parameters that together create the set of 16 synchronization types. Table 1 describes the role of each parameter and its corresponding two possible values, when considered for an arbitrary synchronizer Y(L). The “Index” column relates the position of a letter in the synchronization type with its corresponding parameter. Next, we describe the semantics of synchronization types in detail. Table 1. Synchronization types and their parameters, when considered for synchronizer Y(L) Index Parameter Purpose 1

How an identifier can be used in the role sets of transitions

2

How an identifier can be used in the co-role sets of transitions

3 4

How many instances of a label can appear in the role sets of transitions in a small step How many instances of a co-label can appear in the co-role sets of transitions in a small step

Values for Synchronizer Y(L) : The identifiers in L can be used only in uni-roles : The identifiers in L can be used in poly-roles : The identifiers in L can be used only in uni-co-roles : The identifiers in L can be used in poly-co-roles : One, exclusively : Many, in a shared manner : One, exclusively : Many, in a shared manner

From a set of enabled, orthogonal transitions, T , determined by the semantics of BSMLs, a potential small step, X, X  T , must satisfy the constraints of all of the synchronizers that control transitions in T . In a synchronizer Y(L), the first two letters of its synchronization type, Y, indicate how the identifiers in L can be used in transitions within the scope of Y(L). A in the first position means that for all identifiers l  L, all transitions in X that have l in their role sets, l must belong to a uni-role (i.e., a singleton role set). A in the second position means that for all identifiers l  L, all transitions in X that have l in their corole sets, l must belong to a uni-co-role set. A  in the first or second position of the synchronization type places no such constraints but only has a di erent meaning from a if there are multiple identifers in L. The constraints of the first two indices in the synchronization type can be checked syntactically by well-formedness constraints. As in some process algebras, such as CCS [14], a label in a role set, e.g., m, is matched with a co-label in a co-role set that has the same identifier, i.e., m. For every transition, t, included in X, the labels in all its role sets and the co-labels in all its co-role sets must participate in a match: For every label, m, in a role set, there must be a matching co-label, m, from another transition included in X, and vice-versa for every co-label, n, in its co-role sets. The third and fourth indices of the synchronization

A Common Framework for Synchronization in Requirements Modelling Languages

203

type indicate how many transitions can participate in this match: E ectively, how many labels, m, can match an m and vice-versa, amongst the role sets and co-role sets of the transitions in X. For a synchronizer with label set L and a synchronization type whose third letter is , i.e., one of the  synchronization types, every identifier, l  L, can appear at most once in the role sets of all transitions in X. For synchronization types , every over-lined identifier of L, l, can appear at most once in the co-role sets of all transitions in X. For synchronization types  (and ), an identifier l  L can appear multiple times in the role sets (and co-role sets) of the transitions in X. In summary, after collecting the role sets and co-role sets of all the transitions within X that use identifiers of L, we have a set of role sets and a set of co-role sets: r11 r12 c11 c21

     

r21 r22 c12 c22

     

and

     

These sets should satisfy all of the following conditions: - Every label ruv must have a corresponding co-label cyx  ruv , and vice versa for every co-label; and - If the synchronization type is , for every co-label cyx , there is exactly one corresponding label ruv , such that  cyx  ruv ; - If the synchronization type is , for every label ruv there is exactly one corresponding co-label cyx , such that ruv  cyx ; and - Finally, the set X must be maximal, i.e., it is not possible to add one or more transition in T and to satisfy the above constraints of the synchronization type. Table 2 shows examples of synchronizing transitions according to 10 synchronizers of distinct types. The transitions in each row are enabled, orthogonal transitions. Intuitively, the first two letters of a synchronization type specify the number of interactions, i.e., the number of matchings over distinct identifiers, that a transition can take part in, i.e., biparty vs. multiparty interaction. The last two letters of a synchronization type specify the arity of the interaction mechanism, i.e., exclusive vs. shared interaction.

Table 2. Examples of synchronizing transitions Synchronizer (m) (m) (m) (m n) (m n) (m n) (m n) (m n p q) (m n p q) (m n p q)

Synchronizing Transitions t1: m t2: m t1: m t2: m t3: m t1: m t2: m t3: m t4: m t1: m t2: n t3: m n t1: m t2: m t3: n t4: n t5: m n t1: m t2: m t3: m n t4: m n t1: m t2: m t3: n t4: n t5: m n t6: m n t1: m n t2: p q t3: m p t4: n q t1: m n p q t2: m n t3: p q t4: m p t5: n q t1: m n p q t2: m n t3: p q t4: m n p q t5: m p t6: n q

204

S. Esmaeilsabzali, N.A. Day, and J.M. Atlee

In the model in Fig. 1, when the model resides in G11 ,G21 , and G31 , the set of transitions t5 t9 t11  is a potential small step of the model, which satisfies the constraints of synchronizer (x): (1) only uni-roles use x; (2) only uni-co-roles use x; (3) only t9 has a role set including x; and (4) both t5 and t11 have co-role sets including x. The other two potential small steps are: t6 t8 t11  and t5 t8 t12 . The model neither permits two groups to initiate an intersection maneuver simultaneously, nor a group to initiate two intersection maneuvers consecutively. Each pair of synchronization types  and  ,  and ,  and  ,   and ,  and , and  and   are symmetric. A synchronizer with one of these types can be replaced with a synchronizer with the same label set but the symmetric type, with the role sets and co-role sets of transitions being swapped. If a model has more than one synchronizer, the constraints of their corresponding synchronization types should be considered together; i.e., the set X above should satisfy the synchronization requirements of all of the synchronizers together. Lastly, in the semantics described above, a few well-formedness conditions were assumed. An SBSML model is well-formed if all of the following five conditions hold, i Each label uniquely belongs to the label set of exactly one synchronizer. ii No two synchronizers of a control state have the same synchronization type. iii For each label l of synchronizer m and each transition t, l is associated with at most one of the role sets or co-role sets of t. Furthermore, m is associated with the lowest control state that is an ancestor of the source and destination control states of the transitions that use the labels of m in their role sets or co-role sets. iv Two labels that are associated with the same synchronization type do not belong to two di erent role sets or two di erent co-role sets of the same transition. v For each label l, if there is at least one transition with a poly-role that includes l, then the synchronization type of its corresponding synchronizer should be a synchronization type whose first letter is  (i.e., ), otherwise it must be one of the  synchronization types. Similarly, the second letter of a synchronization type is specified based on the characteristics of the co-role sets of transitions. Hereafter, by an SBSML model, we mean a well-formed SBSML model.

4 Applications: Semantics of Modelling Constructs Through examples, this section describes how the essence of the semantics of modelling constructs such as as multi-source, multi-destination transitions [8,18], composition operators [15], and workflow patterns [1] can be captured succinctly using synchronization in SBSMLs. We also show how some of the semantic variations of BSMLs can be modelled using synchronizers, thereby allowing multiple BSML semantics to exist in di erent components of a model. Lastly, we show how a notion of a signal and the negation of a signal used in some BSMLs can be modelled in SBSMLs. 4.1 Modelling Multi-source, Multi-destination Transitions Multi-source, multi-destination transitions embody a form of concurrent, synchronized execution: When a multi-source, multi-destination transition is executed, it exits all of

A Common Framework for Synchronization in Requirements Modelling Languages

205

its source control states and enters all of its destination control states [8, 18]. A multisource, multi-destination transition of a model can be replaced with a set of regular transitions that are always taken together by synchronizing via a synchronizer of type . As an example, the SBSML model in Fig. 2(b) is equivalent to the model in Fig. 2(a), which has two multi-source, multi-destination transitions x and y. For example, transition x is replaced by transitions x1 , x2 , and x3 . One of the transitions, x1 , adopts the enabledness conditions, the actions, and the role sets and co-role sets of x, along with a new co-role set with co-labels for every other transitions. The other transitions each has one singleton role set, to match the co-role set of the first transition. The number of control states in the source and destination of a multi-source, multi-destination transition need not be the same, in which case new dummy control states are introduced to make the number of source control states and destination control states equal. For example, in the model in Fig. 2(b), control state R4 is such a dummy control state.

R : (a1 a2 b1 b2 ) y1: b1 b2  M

y y2: b1  M1 M2

M3

R

M¼

M

¼

M11

M12

M21

M22

M31

M32

M1

x

M2¼ M3¼

¼ M11

¼ M12

¼ M21

¼ M22

¼ M31

¼ M32

R1

R11

R12

x1:

R¼ R¼1

a1 a2  R2

R3

R21

R22

R31

R32

x2: a1 

R¼2 R¼3

R¼11

R¼12

R¼21

R¼22

R¼31

R¼32

y3: b2 

(a)

R4 x3 : a2 

(b)

Fig. 2. Multi-source, multi-destination transitions using regular transitions

4.2 Modelling BSML Semantic Variations In previous work, we deconstructed the semantics of BSMLs into eight high-level, mainly orthogonal, semantic aspects and their semantic options [5, 6, 4]. These aspects were divided into: (i) dynamic aspects, which determine the enabledness of a single transition and the e ect of its execution; and (ii) structural aspects, which specify the possible small steps from a set of enabled transitions [4]. Using synchronization, we show that the semantic options for the structural semantic aspects of concurrency and preemption are not needed, thus a single SBSML can include a combination of the semantic options of these semantic aspects. Concurrency: A dichotomy in the semantics of BSMLs is whether a small step can include more than one transition or exactly one transition. Using the semantic option that a maximal set of transitions can be taken together in a small step along with a synchronizer (a), an And control state can be constrained to execute at most one

206

S. Esmaeilsabzali, N.A. Day, and J.M. Atlee

of its transitions at each small step: Every transition within the And control state is modified to synchronize with a new self transition: t: a.3 Preemption: Some BSMLs support preemptive semantics, in which an interrupt transition can supersede another transition, whose scope is lower than the interrupt transition. Other BSMLs support non-preemptive semantics, in which an interrupt transition can be taken together with the interrupted transition. A BSML that supports the nonpreemptive semantics can model the preemptive semantics, by using synchronizers of type  . For example, in the model in Fig. 3(a), transition st4 , which is an interrupt transition, can be taken together with transitions st2 and st3 by the non-preemptive semantics. Similarly, transition st5 can be taken together with transitions st1 and st2 . In the model in Fig. 3(b), which simulates the preemptive semantics, for each pair of transitions in which one is an interrupt and the other is interrupted, only one of them can be taken in a small step. For example, transitions dt4 and dt2 cannot be taken together because only one of them can synchronize with t2 . DES :  (a1 a2 a3 )

S RC S S1

D

st4 S 11

st1

S

S 12

¼

D1

dt4: a2 a3  D11

dt1: a1 

D21

dt2: D 22 a2 

D31

dt3: D 32 a3 

¼

S2

S3

S 21

st2

S 31

st3

S1 S 22 S ¼2 S 32 st5

(a)

D2

D3

D

D12

¼

D¼1

t1: a1  D4 t2: a2  D5

D¼2 t3: a3  dt5: a1 a2 

D6

(b)

Fig. 3. Deriving preemptive behaviour in a non-preemptive semantics

4.3 Modelling Composition Operators In our previous work on template semantics [15], a set of composition operators were introduced, each of which represents a useful execution pattern in modelling. In this section, we describe how the behaviour of rendezvous, environmental synchronization, and interleaving composition operators can be modelled using synchronizers. For each of the remaining composition operators in template semantics, there is a similar workflow pattern [1], whose semantics we consider in the next section. Rendezvous: The rendezvous binary composition operator, analogous to the CCS composition operator [14], requires one of the transitions of one of its operands to generate a synchronization event and one of the transitions of the other operand that is triggered with that event to consume it, in the same small step. The semantics of the rendezvous composition operator is the synchronizer of type . 3

This mapping is analogues to the derivation of asynchrony from synchrony in SCCS [13, 14].

A Common Framework for Synchronization in Requirements Modelling Languages C1

207

C2

C11

C12

A1

C21

A2

st1: e [b1 ] B1

st2: e [b2 ]

A3 env e

B2

st3: e [b3 ] B3

C22 A4 st4: e [b4 ] B4

(a) Environmental synchronization composition operator. Env :  (u v w) E1 E11

t1: e [b1 ] u v w r 

dt1: e [b1 ] u v w r t2: e E12 u v w r

(r) E2 E21 dt2: e [b2 ] r u E22

t3: e [b2 ] u r

t4: e u r

E3 E31 dt3: e [b3 ] r  v E32

t5: e [b3 ] v r

t6: e v r

E4 E41 dt4: e [b4 ] r  w E42

t7: e [b4 ] w r

t9: r E5

t8: e w r

(b) Equivalent SBSML model for the model in Fig 4(a).

Fig. 4. Modelling the environment synchronization operator in SBSMLs

Environmental Synchronization: The environmental synchronization composition operator requires its two operands to synchronize over transitions that are triggered with the same synchronization event received from the environment. At each snapshot, it is possible that no, one, or more than one transition in each operand is enabled and triggered with the synchronization event. When all concurrent parts of the operands have enabled transitions that are triggered with the synchronization event, a synchronizer of type   can be used to execute all of them together in the same small step. Otherwise, when there is an arbitrary number of enabled transitions that are triggered with the synchronization event, additionally a synchronizer of type  is needed to ensure that a maximal set of such transitions are taken together in the same small step. As an example, the model in Fig. 4(a) uses the environmental synchronization composition operator over event e to coordinate the execution of C1 and C2 . Each of the transitions in the model has a guard condition, enclosed by a “[ ]”, on a boolean variable that is assigned a value by the environment. Fig. 4(b) is an SBSML model that has the same behaviour as the model in Fig. 4(a). Each control state of the model in Fig. 4(b) has a self transition to accommodate for the execution of synchronization transitions when not all of them are ready to execute. Self transition t9 is necessary when executing dt1 , dt2 , dt3 , dt4 together in the same small step. Transitions dt1 , dt2 , dt3 , dt4 each synchronizes via two synchronizers. Interleaving: The interleaving composition operator requires that exactly one of its operands to execute its transitions in each small step, exclusively. As an example, in the model in Fig. 5(a), in each small step, either transitions of C1 or those of C2 should be executed. The SBSML model in Fig. 5(b) uses a synchronizer of synchronization type

208

S. Esmaeilsabzali, N.A. Day, and J.M. Atlee

C1 C11 A1 st1 B1

C2 C12

C21

A2 st2

A3 int

B2

st1 B3

Int : C22 A4 st3 B4

I1

(a1 a2 ) I2

I11 dt1: a1  I12

(a)

I3

I21 dt2: a1  I22

I4

I31 dt3: a2  I32

I41 dt4: a2  I42

t1: a1  I5 t2: a2 

(b)

Fig. 5. Modelling the interleaving composition operator in SBSMLs

 to enforce the interleaving semantics of the model in Fig. 5(a), by executing either t1 or t2 in a small step, but not both. 4.4 Modelling Workflow Patterns There are five basic workflow patterns [1]: (i) sequence, which executes two activities sequentially: Once the first activity finishes, the second activity starts; (ii) parallel split, which starts executing multiple activities in parallel; (iii) synchronization, which merges multiple parallel activities into a single activity; (iv) exclusive choice, which non-deterministically chooses to execute one activity from a set of possible activities; and (v) simple merge, which requires exactly one of the alternative activities to finish before a next activity starts. Fig. 6 shows examples of how each of the basic workflow patterns can be modelled in SBSMLs. The model in Fig. 6(a) uses the first three patterns. The model in Fig. 6(c) uses the last two patterns, together with the sequence pattern. The circled operators seq, par, syn, xor, and mer represent the sequence, parallel split, synchronization, exclusive choice, and simple merge workflow patterns, respectively. Fig. 6(b) and Fig. 6(d), which use multi-source, multi-destination transitions, are equivalent SBSML models for the models in Fig. 6(a) and Fig. 6(c), respectively. The parallel split and synchronization workflow patterns are usually used together; e.g., as in the fork & join construct in activity diagrams in UML [16]. For the sake of brevity, we modelled only the basic workflow patterns, but it is not diÆcult to derive the semantics of other patterns, especially the ones that do not involve instances of activities. In interpreting and modelling the semantics of the sequence pattern above, an additional idle small step is introduced between the last small step of the first activity and the first small step of the second activity. This extra small step can be avoided by using an interrupt transition that transfers the control flow to the second activity simultaneously when the last small step of the first activity is being executed. 4.5 Modelling Signals and Negations of Signals Some BSMLs, such as -Charts [17], support a notion of a signal that when generated in a small step of a model can be sensed as present by all of the transitions of the model in

A Common Framework for Synchronization in Requirements Modelling Languages

209

S RC1 M M1

P1

M11 st1 M12 seq

M2

Q P11 st3 P12

par

M21 st2 M22

syn P2

Q1

Q11 st5 Q12

Q2

Q21 st6 Q22

seq

P21 st4 P22

(a) A workflow model using sequence, parallel split, and synchronization workflow patterns. DES 1 H

I

H1

H11 dt1 H12

H2

H21 dt2 H22

I1 t1

I2

K I11

dt3 I 12

I21

dt4 I 22

t2

K1

K11 dt5 K12

K2

K21 dt6 K22

(b) Equivalent SBSML model for the model in Fig. 6(a). S RC2 M

Q

M1

M11 st1 M12

M2

M21 st2 M22

seq

P1

P11 st3 P12

P2

P21 st4 P22

xor

mer

seq

Q1

Q11 st5 Q12

Q2

Q21 st6 Q22

(c) A workflow model using sequence, exclusive choice, simple merge workflow patterns. DES 2 :

(x1 x2 )

H

K

t1: x1 

H1

H11 dt1 H12

H2

H21 dt2 H22

I1

I11

dt3 I 12

I21

dt4 I 22

t3

K1

K11 dt5 K12

K2

K21 dt6 K22

t5: x1  X1

I2

t4

t6: x2 

t2: x2 

(d) Equivalent SBSML model for the model in Fig. 6(c).

Fig. 6. Modelling workflow patterns in SBSMLs S RC S1 S 11 st1: (I  a  b  c) S 12

DES : (u v w)  (x y z x¼ y¼ z¼ ) S2

S3

S 21

S4

S 31

st2: (I  a b  c) S 22

st3: a c S 32

(a)

D1

S 41 st4: b c S 42

D2

D11 dt1: I x¼  v w D12

D3

D21 dt2: I y¼  u w D22

D4

D31

D41

dt3: u w x z D32

dt4: v w y z

D42

(b)

Fig. 7. Modelling the semantics of a notion of signal in SBSMLs

t1: x¼  t2: x D5 t3: y¼ 

t4: y

D6 t5: z¼  t6: z D7

210

S. Esmaeilsabzali, N.A. Day, and J.M. Atlee

the same small step.4 The semantics of such signals can be modelled by synchronizers of type . A set of signals generated by a transition corresponds to a poly-role. The conjunction of signals in the trigger of a transition corresponds to a poly-co-role. To model the negation of a signal, a synchronizer of type   and two labels can be used to disallow both a signal to be generated by a transition and its negation to be the trigger of a transition, in the same small step. As an example, in the model in Fig. 7(a), on page 209, when the model is initialized and input signal I is received from the environment, either of the potential small steps st1 st4  and st2 st3  can be taken, non-deterministically. (In the model in Fig. 7(a), the set of generated signals of a transition is prefixed with a “ ”). The model in Fig. 7(b) has the same behaviour as the one in Fig. 7(a). Labels u, v, and w correspond to signals a, b, and c, respectively. Input signal I is maintained in the model in Fig. 7(b). Labels x, y, z, together with labels x , y , z , ensure that each of the signals a, b, and c can be exclusively either generated or its negation can trigger a transition, respectively. For example, transitions dt1 and dt3 cannot be taken together because t1 and t2 cannot be taken together.

5 Related Work Our classification of synchronization types overlaps with the classification of multiparty interaction mechanisms by Joung and Smolka [10]. They present a novel classification for synchronization mechanisms based on four criteria, which, in our terminology, can be described as: (i) whether or not the role sets and co-role sets of all transitions are singletons; (ii) whether or not a transition, in addition to specifying its role sets and co-role sets, can specify a particular transition (or transitions in a part of the hierarchy tree) with which it wishes to synchronize; (iii-a) whether or not the number of role sets and co-role sets of a transition together can be more than one; (iii-b) whether or not a control state can be the source control state of more than one transitions that can synchronize; and (iv) whether only a minimal set of synchronizing transitions are taken at each small step or a maximal set of all synchronizing transitions should be taken at each small step. Criterion (i) corresponds to the first two letters of our synchronization types, with our criteria being more distinguishing. Criterion (ii) is not relevant for us since it can be modelled by a naming convention for labels (cf., [10, p. 85]). Criterion (iii), called conjunctive vs. disjunctive parallelism [10], is meant to distinguish between process algebras such as SCCS (synchronous CCS) [13], which can perform multiple handshakes in one small step, and CCS, which can do at most one handshake; this criterion is closely related to the criterion (i) [10, p.83]. Part (a) of the criterion is not relevant in our framework since multiple role sets, or multiple co-role sets, related to the same synchronizer are merged into one. Part (b) of the criterion corresponds to a syntactic constraint in our framework. Lastly, we do not consider criterion (iv), focusing on semantics in which a maximal set of synchronizing transitions is always taken. Compared to Joung and Smolka’s taxonomy, our framework additionally considers the role of the third and fourth letters of our synchronization types. Also, additionally, our framework permits multiple synchronization types in one language. In general, the 4

In previous work [5, 6], we have categorized this semantics of signals as the same semantic variation for events.

A Common Framework for Synchronization in Requirements Modelling Languages

211

taxonomy of Joung and Smolka “is based on issues that may a ect the complexity of scheduling multiparty interaction” [10, p.78], where as our framework is based on issues relevant for designing suitable modelling languages for requirements specification. Our synchronizer syntax is inspired by the encapsulation operator in Argos [12]. The encapsulation operator specifies the scope in which a signal can be used. Our syntax is di erent in that multiple synchronizers can be attached to the same control state. A class of BSMLs called synchronous languages [7], which includes languages such as Esterel [3] and Argos [12], have been successful in the specification of deterministic behaviour: “In contrast with traditional thread- or event-based concurrency models that embed no precise or deterministic scheduling policy in the design formalism, synchronous language semantics take care of all scheduling decisions.” [20] The main characteristic of the synchronous languages is that the statuses of signals of a model are constant throughout a big step, which, in turn, introduces semantic diÆculties such as non-causality and global inconsistency [12,7,3,18]. Using the synchronization capability of SBSMLs, it is possible to simulate the subset of the responsibilities of signals in synchronous languages that deal with the coordination of the simultaneous execution of transitions. As such, when using signal-like artifacts is not an option in a domain, e.g., UML StateMachines [16], synchronization could be used to achieve determinism in a model, by constructing the model such that each snapshot yields a unique small step. SBSMLs, however, as opposed to synchronous languages, do not guarantee determinism as an inherent property of their semantics.5 When a deterministic behaviour is desired in an SBSML model, care should be taken when using a synchronizer that has a synchronization type with its third andor fourth letter being , which permits synchronization with an arbitrary number of transitions. Similarly, care should be taken when using multiple synchronizers in a model, which could allow multiple sets of transitions to synchronize, according to di erent synchronizers, thereby creating di erent potential small steps. As an example, in the model in Fig. 7(b), if we remove labels x, y, and z from the model and replace x, y, and z in the co-role sets of t2 , t4 , t6 with u, v, and w, respectively, the model can create a wrong small step that would include dt1 , dt2 , dt3 , and dt4 . The wrong small step is possible because label x in dt1 can match its corresponding label in t1 , while label u of dt3 can match its corresponding label in dt2 . Similarly, dt2 and dt4 can match their corresponding labels in t3 and dt1 , respectively.

6 Conclusion and Future Work We presented a framework of 16 synchronization types based on criteria relevant for requirements modelling languages. We described how the class of big-step modelling languages (BSMLs) can be enhanced with these synchronization types creating the family of synchronizing big-step modelling languages (SBSMLs). We validated the usefulness and generality of our framework by describing how underlying the semantics of many modelling constructs, there is a notion of synchronization that can be modelled in SBSMLs. Similar to our framework for BSMLs [4], we are working on a parametric framework to give formal semantics to the family of SBSMLs. Using the results of 5

A model in a synchronous language with a possible nondeterministic behaviour is conservatively rejected at compile time.

212

S. Esmaeilsabzali, N.A. Day, and J.M. Atlee

Joung and Smolka [10], we plan to analyze the complexity of implementing a set of synchronization types in an SBSML, to provide measures for a language designer or a software engineer to choose one SBSML over another. Lastly, we plan to provide a parametric tool support for SBSMLs, in the same style as in our previous work [11,19].

References 1. Aalst, W., Hofstede, A., Kiepuszewski, B., Barros, A.P.: Workflow patterns. Distributed and Parallel Databases 14(1), 5–51 (2003) 2. von der Beeck, M.: A comparison of Statecharts variants. In: Langmaack, H., de Roever, W.-P., Vytopil, J. (eds.) FTRTFT 1994 and ProCoS 1994. LNCS, vol. 863, pp. 128–148. Springer, Heidelberg (1994) 3. Berry, G., Gonthier, G.: The Esterel synchronous programming language: Design, semantics, implementation. Science Computer Programming 19(2), 87–152 (1992) 4. Esmaeilsabzali, S., Day, N.A.: Prescriptive semantics for big-step modelling languages. In: Rosenblum, D.S., Taentzer, G. (eds.) FASE 2010. LNCS, vol. 6013, pp. 158–172. Springer, Heidelberg (2010) 5. Esmaeilsabzali, S., Day, N.A., Atlee, J.M., Niu, J.: Semantic criteria for choosing a language for big-step models. In: RE 2009, pp. 181–190. IEEE Computer Society Press, Los Alamitos (2009) 6. Esmaeilsabzali, S., Day, N.A., Atlee, J.M., Niu, J.: Deconstructing the semantics of big-step modelling languages. Requirements Engineering 15(2), 235–265 (2010) 7. Halbwachs, N.: Synchronous Programming of Reactive Systems. Kluwer, Dordrecht (1993) 8. Harel, D.: Statecharts: A visual formalism for complex systems. Science of Computer Programming 8(3), 231–274 (1987) 9. Hoare, T.: Communicating Sequential Processes. Prentice-Hall, Englewood Cli«s (1985) 10. Joung, Y.J., Smolka, S.A.: A comprehensive study of the complexity of multiparty interaction. Journal of the ACM 43(1), 75–115 (1996) 11. Lu, Y., Atlee, J.M., Day, N.A., Niu, J.: Mapping template semantics to SMV. In: ASE 2004, pp. 320–325 (2004) 12. Maraninchi, F., R´emond, Y.: Argos: an automaton-based synchronous language. Computer Languages 27(1»3), 61–92 (2001) 13. Milner, R.: Calculi for synchrony and asynchrony. Theoretical Computer Science 25(3), 267– 310 (1983) 14. Milner, R.: Communication and Concurrency. Prentice-Hall, Englewood Cli«s (1989) 15. Niu, J., Atlee, J.M., Day, N.A.: Template semantics for model-based notations. IEEE TSE 29(10), 866–882 (2003) 16. OMG: OMG Unified Modeling Language (OMG UML), Superstructure, v2.1.2, formal»2007-11-01 (2007) 17. Philips, J., Scholz, P.: Compositional specification of embedded systems with statecharts. In: Bidoit, M., Dauchet, M. (eds.) CAAP 1997, FASE 1997, and TAPSOFT 1997. LNCS, vol. 1214, pp. 637–651. Springer, Heidelberg (1997) 18. Pnueli, A., Shalev, M.: What is in a step: On the semantics of statecharts. In: Ito, T., Meyer, A.R. (eds.) TACS 1991. LNCS, vol. 526, pp. 244–264. Springer, Heidelberg (1991) 19. Prout, A., Atlee, J.M., Day, N.A., Shaker, P.: Semantically configurable code generation. In: Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., V¨olter, M. (eds.) MODELS 2008. LNCS, vol. 5301, pp. 705–720. Springer, Heidelberg (2008) 20. Tardieu, O.: A deterministic logical semantics for pure Esterel. ACM TOPLAS 29(2), 8:1– 8:26 (2007)

A Systematic Review of the Use of Requirements Engineering Techniques in Model-Driven Development Grzegorz Loniewski, Emilio Insfran, and Silvia Abrah˜ ao ISSI Research Group, Department of Computer Science and Computation Universidad Polit´ecnica de Valencia Camino de Vera, s/n, 46022, Valencia, Spain [email protected], [email protected], [email protected]

Abstract. Model-Driven Development (MDD) emphasizes the use of models at a higher abstraction level in the software development process and argues in favor of automation via model execution, transformation, and code generation. However, one current challenge is how to manage requirements during this process whilst simultaneously stressing the benefits of automation. This paper presents a systematic review of the current use of requirements engineering techniques in MDD processes and their actual automation level. 72 papers from the last decade have been reviewed from an initial set of 884 papers. The results show that although MDD techniques are used to a great extent in platformindependent models, platform-specific models, and at code level, at the requirements level most MDD approaches use only partially defined requirements models or even natural language. We additionally identify several research gaps such as a need for more efforts to explicitly deal with requirements traceability and the provision of better tool support. Keywords: model-driven development, requirements engineering, systematic review.

1

Introduction

Software engineering experiences show that in recent decades, the model-based development of systems has become an essential factor in reducing costs and development time. Furthermore, correctly managed, well-documented and easily understandable software requirements definitions have a great impact on final product quality [4]. However, requirements engineering (RE) is one of the software engineering disciplines in which model-based approaches are still not widespread. Requirements are generally regarded as text fragments which are structured to a greater or lesser extent and are interpreted by stakeholders and developers, who manually manage the requirement interrelationships [22]. A variety of methods and model-driven techniques have been published in literature. However, only a few of these explicitly include the requirements discipline in the Model-Driven Development (MDD) process. D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 213–227, 2010. c Springer-Verlag Berlin Heidelberg 2010 

214

G. Loniewski, E. Insfran, and S. Abrah˜ ao

This paper presents a review of those scientific papers published in the last decade which include the use of RE techniques in the context of an MDD process. In order to provide a balanced and objective summary of research evidence, we have chosen to carry out a systematic literature review (SLR) since this process is considered to be an appropriate method by which to tackle the realization of reviews of this kind in software engineering [2]. Various systematic reviews have been performed in the field of RE, such as that of Davis et al. [4] which presented an SLR on the effectiveness of requirements elicitation techniques. However, RE techniques focused on model-driven methodologies and processes are rarely researched. An attempt to describe a combination of these two fields of software engineering can be seen in the work of Nicol´ as and Toval in [28] in which the authors show the influence of models on the generation of textual requirements. To date, no literature reviews for requirements models applied to the model-driven environment have been found. Model-driven development is often applied to Platform-Independent Models (PIMs) and Platform-Specific Models (PSMs), but is hardly ever found in Computation-Independent Models (CIMs). In order to investigate this issue in greater depth, we present a systematic literature review with the principal objective of studying the use of requirements engineering techniques in MDD processes and their actual level of automation. The systematic review presented in this paper was started in December 2009 and was later updated in February 2010. This paper is organized as follows. Section 2 describes the protocol followed to carry out the systematic review. Section 3 presents the results obtained. Section 4 discusses the threats to the validity of the results. Finally, Section 5 presents our conclusions and suggests areas for further investigation.

2

Research Method

We follow the approach proposed by Kitchenham [14] for systematic literature reviews. A systematic review is a means of evaluating and interpreting all the available research that is relevant to a particular research question, topic area, or phenomenon of interest. It aims to present a fair evaluation of a research topic by using a trustworthy, rigorous, and auditable methodology. A systematic review involves several stages and activities, which are briefly explained below: – Planning the review: the need for the review is identified, the research questions are specified and the review protocol is defined. – Conducting the review: the primary studies are selected, the quality assessment used to include studies is defined, the data extraction and monitoring is performed and the data obtained is synthesized. An activity to test the reliability of the review protocol was added during this stage. – Reporting the review: dissemination mechanisms are specified and a review report is presented. The activities concerning the planning and conducting phases of our systematic review are described in the following subsections. The report on the review stage is presented in Section 3.

A Systematic Review of the Use of Requirements Engineering Techniques

2.1

215

Research Question

In order to examine the current use of requirements engineering techniques in model-driven development and their actual level of automation, we formulated the following research question: ”What requirements engineering techniques have been employed in model-driven development approaches and what is their actual level of automation?”. The intention of this research question was to enable us to define a process with which to collect current knowledge about requirements engineering techniques in MDD and to identify gaps in research in order to suggest areas for further investigation. The review has been structured by following the PICOC criteria [30]: – – – – –

Population: Research papers presenting MDD processes and techniques, Intervention: Requirements engineering methods and techniques, Comparison: Analysis of all approaches based on the specified criteria, Outcome: Not focused on achieving any specific result, Context: Research papers based on RE techniques used in MDD.

Our review is more limited than a full systematic review, such as that suggested in [14], since we did not follow up the references in papers. In addition, we did not include other references such as technical reports, working papers and PhD thesis documents. This strategy has been used in another systematic review conducted in the software engineering field [25]. 2.2

Source Selection

Two types of search methods were used to select appropriate and representative papers in the field of requirements and model-driven engineering. The first type, automatic searching, was based on four main sources of scientific paper databases: IEEE Xplore (IE), ACM Digital Library (ACM), Science Direct (SD), and SpringerLink (SL). A manual search was also carried out in the following representative conferences and journals: Requirements Engineering conference (RE), the Conference on Model Driven Engineering Languages and Systems (MODELS), and Requirements Engineering Journal (REJ). This manual search method was applied in order to verify the correctness of the automatic review and to carry out a more in-depth study of those works published in these sources that explore new trends and approaches. 2.3

Identifying and Selecting Primary Studies

The research goal, was used as a basis for the creation of a search string with which to identify primary studies. The search string consisted of three parts: the first part linked those works that describe requirements engineering techniques using models, the second part was related to model-driven engineering concepts, and finally the third part described the relation between requirements and other models in the MDD process. We experimented with several search strings and the following retrieved the greatest amount of relevant papers:

216

G. Loniewski, E. Insfran, and S. Abrah˜ ao

(requirements engineering OR requirements-based OR requirements-driven OR requirements model OR business model OR CIM OR Computation Independent Model) AND (MDA OR MDE OR model-driven OR model-based OR model*) AND (transform* OR traceability). The specific syntax of this search string was adapted to each digital library we used. 2.4

Inclusion Criteria and Procedures

The searching configuration included limitations to the type of papers and content. The papers that were taken into consideration were exclusively those research papers that present approaches for MDD-based requirements engineering or software development processes with requirements traceability. Moreover, only papers published in conferences/workshops proceedings and scientific journals between January, 1999 and January, 2010 were considered as significant for the research. The following types of papers were excluded: i) papers describing model-driven principles without describing a concrete requirements engineering technique; ii) papers presenting requirements engineering techniques that are not related to model-driven principles; iii) books, tutorials, standards definitions, poster publications; iv) short papers (papers with less than 4 pages); v) papers not written in English. 2.5

Data Extraction Strategy

The data extracted were compared according to the research question stated, which is here decomposed into the following criteria that are described below. – Type of requirements (criterion 1). This can be of two types: software requirements which are requirements that describe only the functionalities of software under development, and business requirements which include information that is related not only to the functionality of the future system, but also to the business context, organizational structure of the enterprise, processes, etc. which will not necessarily be a part of the system to be developed. – The information concerning the type of requirements structure (criterion 2) is then collected. Requirements can be represented as models (two types of models are distinguished: standard models expressed in the only modeling language that is considered as a standard (UML from OMG) and other nonstandard types of models). Requirements can also be expressed in natural language or other types of textual or graphical representation. – In the case of using models for requirements specification, the information concerning the type of models (criterion 3) is gathered. These models can be: structural, behavioral, functional or of another type. – Model transformations provided (criterion 4). This is an interesting topic which concentrates on an important amount of research work. – Level of transformations (criterion 5), as proposed in Mens et al. [26]. For transformations we can also analyze the languages in which both source

A Systematic Review of the Use of Requirements Engineering Techniques

–

–

–

–

–

–

–

1

217

and target models and their abstraction levels are expressed. In this case transformations are classified as endogenous when the source and target model are expressed in the same language and in the same abstraction level, and exogenous when different modeling languages and abstraction levels are used to express source and target models (e.g. in UML languange: a source model can be expressed as a use case model and the target model as an activity diagram). Use of transformation languages (criterion 6) is also analyzed. Transformations can be defined with standard languages such as QVT or ATL1 or with non-standard transformation languages. Transformation automation level (criterion 7). We consider a transformation to be automatic if the entire process of obtaining the target model can be carried out without the transformation user’s participation. We then distinguish interactive (semi-automatic) or manual approaches. Requirements traceability (criterion 8). Requirements traceability refers to the ability to describe and follow the life of a requirement, in both a forwards and backwards direction. We focus on the post-requirements specification (post-RS). Post-RS refers to those aspects of a requirement’s life that result from inclusion in a requirements specification as defined by Gotel and Finkelstein [9]. The papers reviewed were analyzed to study the traceability to and from analysis, design, and implementation artifacts. Traceability automation (criterion 9). This is investigated to provide us with some conclusions regarding the effort needed to manage the traceability within the MDD process. Tool support (criterion 10). We analyzed whether there is a tool that performs the MD transformations on requirements and generates model(s), and also whether it provides support for requirements traceability and its monitoring during the entire software development process. Type of validation (criterion 11) conducted. Three different types of strategies can be carried out depending on the purpose of the validation and the conditions for empirical investigation [7]: survey, case study, and experiment. A survey is an investigation performed in retrospect, when the method has been in use for a certain period of time. A case study is an observational study in which data is collected for a specific purpose throughout the study. An experiment is a formal, rigorous, controlled investigation. The set of validation methods does not include theoretical examples of proof-ofconcepts. Finally, the actual usage (criterion 12) of the requirements engineering technique is analyzed. The paper is classified as being industrial if it presents a requirements engineering technique which was proposed for (and is being used in) the context of a company. Otherwise, it is classified as academic if the paper describes an academic environment and no evidence of its current usage is provided.

We include ATL in the standard category since it is widely used in academia and can be considered as a de facto standard.

218

2.6

G. Loniewski, E. Insfran, and S. Abrah˜ ao

Conducting the Review

The stage in which the review is conducted consists of the following activities: selection of primary studies, data extraction, and data synthesis. The previous sections describe how and from which sources the primary studies were selected. Based on this information, the search resulted in 867 potentially related papers which might be significant for the research topic. A manual search (MS) was also conducted in order to find any relevant papers that might exist and had not been discovered with the automatic search (AS). The MS sources include the RE and MODELS conferences and the REJ journal, and resulted in 17 relevant papers related to the research topic which are additional to those selected by the AS. Table 1 presents the results of the final set of relevant papers selected for each of the sources. Search results row shows the number of papers obtained from each source that resulted from the search string and the manual search, the finally selected row indicates the number of papers that remaind for review after the rejection of papers that satisfied at least one of the exclusion criteria or whose topic was not suitable for the purpose of the systematic review. Duplicated papers were discarded by taking into consideration the first digital library in which they appear, along with the most recent or the most complete publication. 65 papers were consequently chosen for the final review. The research was first carried out in December 2009 and was then updated by January, 31, 2010. A complete list of the papers reviewed is available at: www.dsic.upv.es/~einsfran/review-remdd.htm. Table 1. Number of review results

Source

Automatic search IE ACM SD SL

Manual search (MS) RE/MODELS/REJ

Search results Finally selected

163 641 24 39 21 25 9 7

17 10

3

Total 884 72

Results

This section discusses the results of the review, in which each criterion is commented on. Table 2 shows a summary of the number of papers obtained as a result of the review. This table is organized into groups regarding the selection criteria and the publication sources. The results for the requirements type (criterion 1) show that the majority of works (60%) focus on software requirements (e.g., Insfran et al. in [11], in which requirements are represented through the use of the Techniques for Requirements and Architecture Design (TRADE) such as mission statement, function refinement tree, and use cases). In this context, the Service Oriented Architecture (SOA) has gained a significant amount of popularity in recent years. Various

A Systematic Review of the Use of Requirements Engineering Techniques

219

Table 2. Systematic review results Selection criteria 1 Requirements type

Software Business 2 Requirements structure Standard model Non-standard model Template Structured natural language Natural language Other 3 Type of models Structural Behavioral Functional Other 4 Transformations provided Yes No 5 Transformations level Endogenous Exogenous 6 Standard transformations Yes No 7 Transformations automation Automatic Interactive Manual 8 Traceability requirements To analysis To design To implementation None 9 Traceability automation Automatic Manual 10 Tool support Traceability only Transformation only Traceability&transformation None 11 Type of validation Survey Case study Experiment None 12 Approach scope Academic Industry

Sources Total % IE ACM SD SL MS 14 7 5 9 0 6 2 0 3 8 2 2 19 2 4 16 1 16 7 4 9 8 3 4 12 5 4 1 5 1 14 0 11 0 10 14 7

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

5 6 3 2 4 1 2 1 0 0 2 0 1 3 1 1 1 1 5 2 0 0 2 0 8 4 1 3 0 1 8 3 0 0 6 4 3 0 2 1 2 2 2 5 1 1 1 0 5 2 3 2 0 2 1 3 4 2 1 0 3 2 0 1 2 2 0 1 7 3 7 5 2 3

5 5 6 4 0 2 0 0 0 9 2 0 8 2 0 8 2 6 6 1 1 1 0 1 8 2 0 1 6 0 3 0 7 0 3 8 2

43 29 25 25 1 17 8 2 9 39 6 5 58 14 9 52 7 46 27 11 22 20 12 12 41 17 12 9 23 2 37 1 32 2 37 53 20

60 40 32 32 1 22 10 3 15 69 10 8 81 19 15 85 13 87 45 18 37 24 14 14 48 59 41 13 32 3 52 1 45 3 51 73 27

works describe automation methods for services specification, e.g., Jamshidi [12] proposes a new method called ASSM (Automated Service Specification Method) with which to automatically specify the architecturally significant elements of the service model work product from the requirements. Only 40% of the papers reviewed use business requirements as a basis for further development. At this point it is worth mentioning that many approaches use the i* notation to describe these business requirements. For example, Maz´ on et al. [24] introduce the use of the i* framework to define goal models for data warehouses and automatic conceptual modeling. Other approaches for generating UML models from business requirements also exist, such as that of Raj et al. [31]. This approach presents an automated transformation of business designs from SBVR Business Design (Semantics of Business Vocabulary and Rules) to UML models which bridges the gap between business people and IT people. The results for the requirements structure (criterion 2) show that of the papers reviewed, 64% of those that apply some RE techniques in the MDD

220

G. Loniewski, E. Insfran, and S. Abrah˜ ao

approach used models as a means to represent the requirements. The two types of models are distinguished as follows: UML standard models (32%) (the most frequently used are class, use cases, activity, and sequence diagrams) and nonstandard models (32%) such as goal, aspect, feature, or task-based requirements models. Other alternatives with which to represent the requirements are: i) structured natural language (22%) in which requirements are described in an easy to analyze manner. For example, Mauco et al. [23] use a natural language oriented model which models the vocabulary of a domain by means of the Language Extended Lexicon (LEL); ii) natural language (10%), for example, Fliedl et al. in [8] in which the use of sophisticated tagging in the requirements lexical analysis is proposed; iii) templates (1%) (e.g. the requirements traceability approach presented by Cleland-Huang et al. in [3]) and finally, iv) other types of specifications which are mostly proprietary domain specific (3%). These results are shown in Figure 1(A). The results for the type of models (criterion 3) show that of those approaches that use models for requirements specification the most frequently used type of model is the behavioral model (69%). In many works, this type of model is used as use case specifications (e.g. [19], [10] and [33]) or, very often, as goal models (e.g. in [18], [17] or [16]). Other less frequently used alternatives are: structural (15%), functional (10%) (e.g. activity or sequence UML diagrams), and other types of models (8%) such as the Requirements-Design Coupling (RDC) model proposed by Ozkaya et al. [29] or the Stakeholder Quality Requirement Models described with semantic web technology in [1]. A summary of these results is shown in Figure 1(B). The results for the transformations from requirements phase (criterion 4) show that a total of 81% of the papers reviewed describe different types of transformations from requirements specifications. We can distinguish different types of transformations such as mappings, transformations using patterns and templates, transformations implemented in transformation languages (QVT, ATL), linguistic operations on textual requirements or graph transformations, etc. On the other hand 19% of papers do not provide such transformations (see Figure 1(C.a)), and the approach is focused on other aspects of MDD such as the traceability of requirements, e.g. Cleland-Huang et al. [3]. The results for the level of model transformations (criterion 5) give an outcome concerning the abstraction level of source and target models in the transformation process (see Figure 1(B.b)) according to the aforementioned classification presented by Mens et al. in [26]. The vast majority of approaches (85%) transform a source model into a different type of model (exogenous transformations). The alteration of the target model specification language or abstraction level in relation to the source models (principally goal models or natural language scenario descriptions) mostly takes place in works that apply UML models as a target model. For example, in [5], Debnath et al. describe a natural language requirements transformation to a UML class model. Also, many approaches that start the MDD process from business requirements specifications propose exogenous transformations, as can be seen in [31] in which the business requirements

A Systematic Review of the Use of Requirements Engineering Techniques

221

that are specified with the Semantics of Business Vocabulary and Rules (SBVR) are transformed into UML models (other examples might be [13] and [37]). Some works provide transformations of models within the same modeling language, but in a different abstraction level, e.g. transforming UML use case diagrams into UML activity diagrams. Endogenous transformations are applied in 15% of the approaches reviewed. For example, this type of transformations is used by Laguna and Gonzalez-Baixauli in [16], in which endogenous transformations are considered as requirements configurations used to validate the completeness and consistency of the initial requirements configurations represented as a set of goal and feature models. Another approach with this kind of transformations was used in a validation of scenarios presented by Shin et al. in [35]. The results for the use of transformation languages (criterion 6) show that 87% of transformations included in this systematic review use different kinds of specific mappings, refinements or pattern based transformations or languages other than standardized transformation languages (see Figure 1(C.c)), e.g. Raj et al. [31] define some specific mapping rules with which to transform business design to UML models. Only 13% of the works use one of the two considered in this work as standard languages: QVT and ATL. For example, in [15] Koch et al. propose transformations based on QVT as a transformation language for Web system design. The results for the transformations automation level (criterion 7) show the current state of automation for the transformations defined in the MDD process. 45% of the approaches perform fully automatic transitions from requirements specifications to analysis and design models. For example, Zhang and Jiang in [37] propose a well-defined mapping of requirements defined in the Visual Process Modeling language (VPML) at the CIM level to the Business Process Execution Language (BPEL) description at the PIM level. 18% of the papers describe interactive or semi-automatic transformation methods, e.g. [17] or [21]; 37% of the papers discuss manual transformations, e.g. [16]. Figure 1(D) shows a summary of the results for this criterion. The results for the traceability requirements (criterion 8) show support for requirements traceability in the papers reviewed. With regard to the classification of traceability presented in [9], this work focuses on post-RS traceability, which is the relationship between requirements specification (RS) artifacts and analysis, along with design artifacts. This traceability can be forward and backward traceability. Since this work deals with the model-driven environment, the majority of approaches that possess model transformations assume that forward traceability exists, although not all of these approaches have explicit mechanisms for that traceability support. 48% of works do not provide backwards traceability, although forward traceability is possible. This situation arises in the approach described by Insfran in [11], in which the forward traceability is implicitly assumed by the transformation rules provided, yet there is no reference to the backward traceability. Moreover, 24% of works provide backward traceability from the analysis phase (e.g. in [17], in which goal models are transformed into statecharts and the backward traceability is recorded); 14% of works provide

222

G. Loniewski, E. Insfran, and S. Abrah˜ ao

Fig. 1. Results for some representative criteria of the systematic review

traceability from design and implementation phases mainly from user interface prototypes and test case implementations (e.g., Sousa et al. in [36] present an approach for requirements tracing from user interface implementation). In addition, some authors, such as Naslavsky et al. in [27], describe complete solutions for tracing products from different phases to requirements (specified as scenarios). These results are shown in Figure 1(E). The results for the traceability automation (criterion 9) show that more than half of the methods (59%) that have some traceability support provide an automated tool for traceability management, e.g. [27]. This signifies that in these approaches the effort needed to manage the requirements traces within the MDD process is quite low, or is none-existent. The number of manual traceability approaches is also significant: 41%. For example, in the work of Sousa et al. [36] user interfaces can be logically linked to the business processes defined at the requirements level. The results for the tool support (criterion 10) for the MDD approach show that of the papers reviewed, as was expected, not even half of them have tool support. With regard to those approaches that have some type of process automation tool, the following categories are distinguished: 32% of approaches have tool support for model transformations, e.g. [37], in which a tool for automatic BPEL models creation is supported based on the source model; 13% of works

A Systematic Review of the Use of Requirements Engineering Techniques

223

only support traceability, e.g., in [3] Cleland-Huang et al. propose a traceability of requirements specification without any previous model transformations; and finally, only 3% of the papers describe technological solutions including both transformations and traceability support. One of the works of Rash et al. [32] could serve as a good example here since it provides R2D2C transormations in addition to including traceability support. Retrieving models and formal specifications from existing code is also possible. On the other hand, 52% of works do not offer any tool support. However, most of them emphasize this necessity and state that it will be a part of their future work. These results are shown in Figure 1(F). The results for the type of validation (criterion 11) give an overview of the evaluation methods used in the papers selected. Three validation methods were considered in order to classify the results: survey, case study, and experiment. 51% of the papers reviewed do not present any sort of validation, and a more or less detailed example is the only mean provided to ilustrate the feasibility of the approach. More or less well-defined case studies were used in 45% of the cases. The majority of the papers, particularly those describing academic research, use theoretical examples (e.g. [20]), whereas industrial research, were very often evaluated with a case study (e.g. [34]), although this also ocurred in the other types of research. It is also worth noting that controlled experiments were used in only 3% of the works (e.g. [6]), and validation via surveys were used in only 1% of the papers. Finally, the results for the actual usage (criterion 12) show that 73% of the selected papers were defined in an academic context and 27% were defined in an industrial setting. The predominance of the academic proposals found in this review shows that new approaches to deal with techniques for modeling, transformations, and processes, that include RE as a part of the MDD process in industrial contexts, are still needed. One representative attempt from industry to apply model-driven RE in the development process is the AQUA project [6].

4

Threats to Validity

This section discusses the threats to validity that might have affected the results of the systematic review. We have validated our review protocol to ensure that the research was as correct, complete, and objective as possible. With regard to the source selection we have selected four digital libraries (IEEEXplore, ACM, Science Direct, and Springerlink) containing a very large set of publications in the Software Engineering field. The search string was defined by attempting different combinations of terms extracted from papers concerning Requirements Engineering and model-driven techniques. We also applied patterns for search terms and adapted the search string to advanced methods of source searching in each digital library selected. This made the reproducibility of the automatic search for results possible. Possible limitations of this study concern publication bias, publication selection, inaccuracy in data extraction, and misclassification. Publication bias refers

224

G. Loniewski, E. Insfran, and S. Abrah˜ ao

to the problem that positive results are more likely to be published than negative results [14]. We have attempted to alleviate this threat, at least to some extent, by scanning relevant conference proceedings and journals. In addition, the digital libraries contain many relevant journal articles and conference proceedings. With regard to publication selection, we chose the sources in which RE and MDE works were normally published. However, we did not consider grey literature (e.g. industrial reports, PhD thesis) or unpublished results. With regard to the search string, we attempted to collect all the strings that are representative of the research question. We refined the search string several times in order to obtain the maximum number of papers related to the systematic review. We have also considered synonyms and have included the lexeme of words. We attempted to alleviate the threats to inaccuracy in data extraction and misclassification by conducting the classifications of the papers with two reviewers. The discrepancies among the evaluations were discussed and a consensus was reached.

5

Conclusions and Future Work

In this paper we have presented a systematic review on the use of requirements engineering techniques in MDD processes. In particular, our study is focused on the research for automating model transformations and traceability in the requirements phase. Research in the last decade has shown increasing progress with regard to the precision and automatic support that can be applied to requirements engineering specifications. However, a complete solution which includes requirements models as part of MDD processes is still lacking. In addition, little tool support with which to manage requirements models and to make further use of them in an automatic manner is currently provided. Many MDD methodologies include some requirements engineering activities but these are hardly ever included in the mainstream of automated model transformation and code generation activities. Moreover, this systematic review verifies that models are not exclusively used to describe requirements in the MDD context to serve as the input for modeldriven transformations, but that templates, structured and non-structured natural language are also used. To date, automated model transformations appear to be poorly used since the majority of them are designed as different kinds of mappings and graph transformations that use non-standard transformation languages. After analyzing the results of our systematic review we can draw the conclusion that models are not as frequently used as we expected in the requirements phase of a MDD envirnoment (only 64%). Natural language specifications are also very important. Furthermore, post requirements specification traceability is not well-defined. In addition, there are no complete proposals that are welldocumented and evaluated, particularly in the industrial setting. Moreover, there is a lack of more empirical studies in MDD environments to show the benefits of the use of RE techniques as a part of the automated transformation processes.

A Systematic Review of the Use of Requirements Engineering Techniques

225

Although our findings may be indicative of the field, further investigation is needed to confirm the results obtained. As a future work we plan to extend this study by including other bibliographical sources of scientific papers and industrial papers. Moreover, this systematic review is a part of a more extensive research work whose principal objective is to propose a methodology for an automated RE method for MDD processes.

Acknowledgement This research work is supported by the MULTIPLE project (with ref. TIN200913838) funded by the ”Ministerio de Ciencia e Innovaci´on (Spain)”.

References 1. Biffl, S., Mordinyi, R., Schatten, A.: A model-driven architecture approach using explicit stakeholder quality requirement models for building dependable information systems. In: WoSQ 2007: Proceedings of the 5th Int. Workshop on Software Quality, p. 6. IEEE CS, Washington (2007) 2. Brereton, P., Kitchenham, B.A., Budgen, D., Turner, M., Khalil, M.: Lessons from applying the systematic literature review process within the software engineering domain. J. Syst. Softw. 80(4), 571–583 (2007) 3. Cleland-Huang, J., Hayes, J.H., Domel, J.M.: Model-based traceability. In: TEFSE 2009: Proceedings of the 2009 ICSE Workshop on Traceability in Emerging Forms of Software Engineering, pp. 6–10. IEEE CS, Washington (2009) 4. Davis, A., Dieste, O., Hickey, A., Juristo, N., Moreno, A.M.: Effectiveness of requirements elicitation techniques: Empirical results derived from a systematic review. In: RE 2006: Proceedings of the 14th IEEE Int. Requirements Engineering Conf., pp. 176–185. IEEE CS, Washington (2006) 5. Debnath, N., Leonardi, M., Mauco, M., Montejano, G., Riesco, D.: Improving model driven architecture with requirements models. In: ITNG 2008: Fifth Int. Conf. on Information Technology: New Generations, pp. 21–26 (2008) 6. Escalona, M.J., Guti´errez, J.J., Rodr´ıguez-Catal´ an, L., Guevara, A.: Model-driven in reverse: the practical experience of the aqua project. In: EATIS 2009: Proceedings of the 2009 Euro American Conference on Telematics and Information Systems, pp. 1–6. ACM, New York (2009) 7. Fenton, N.E., Pfleeger, S.L.: Software Metrics: a rigorous and practical approach. International Thompson Computer, 2nd edn. (1996) 8. Fliedl, G., Kop, C., Mayr, H.C., Salbrechter, A., Vhringer, J., Weber, G., Winkler, C.: Deriving static and dynamic concepts from software requirements using sophisticated tagging. Data & Knowledge Engineering 61(3), 433–448 (2007) 9. Gotel, O.C.Z., Finkelstein, C.W.: An analysis of the requirements traceability problem. In: Proceedings of the First Int. Conf. on Requirements Eng., pp. 94–101 (1994) 10. Hinchey, M.G., Rash, J.L., Rouff, C.A., Gracanin, D.: Achieving dependability in sensor networks through automated requirements-based programming. Computer Communications 29(2), 246–256 (2006) 11. Insfran, E., Pastor, O., Wieringa, R.: Requirements engineering-based conceptual modeling. Requirements Engineering Journal 7, 61–72 (2002)

226

G. Loniewski, E. Insfran, and S. Abrah˜ ao

12. Jamshidi, P., Khoshnevis, S., Teimourzadegan, R., Nikravesh, A., Shams, F.: Toward automatic transformation of enterprise business model to service model. In: PESOS 2009: Proceedings of the 2009 ICSE Workshop on Principles of Engineering Service Oriented Systems, pp. 70–74. IEEE CS, Washington (2009) 13. Kherraf, S., Lefebvre, E., Suryn, W.: Transformation from cim to pim using patterns and archetypes. In: ASWEC 2008. 19th Australian Conf. on Software Engineering, pp. 338–346 (2008) 14. Kitchenham, B.: Procedures for performing systematic reviews. Tech. rep., Keele University and NICTA (2004) 15. Koch, N., Zhang, G., Escalona, M.J.: Model transformations from requirements to web system design. In: ICWE 2006: Proceedings of the 6th International Conference on Web Engineering, pp. 281–288. ACM, New York (2006) 16. Laguna, M.A., Gonzalez-Baixauli, B.: Requirements variability models: metamodel based transformations. In: MIS 2005: Proceedings of the 2005 Symposia on Metainformatics, p. 9. ACM, New York (2005) 17. Lapouchnian, A., Yu, Y., Liaskos, S., Mylopoulos, J.: Requirements-driven design of autonomic application software. In: CASCON 2006: Proceedings of the 2006 Conference of the Center for Advanced Studies on Collaborative Research, p. 7. ACM, New York (2006) 18. Letier, E., van Lamsweerde, A.: Deriving operational software specifications from system goals. In: SIGSOFT 2002/FSE-10: Proceedings of the 10th ACM SIGSOFT Symp. on Foundations of Sw. Eng., pp. 119–128. ACM, New York (2002) 19. Li, X., Liu, Z.: Prototyping system requirements model. Electronic Notes in Theoretical Computer Science 207, 17–32 (2008); Proceedings of the 1st Int. Workshop on Harnessing Theories for Tool Support in Software (TTSS 2007) 20. Liew, P., Kontogiannis, K., Tong, T.: A framework for business model driven development. In: The 12th Int. Workshop on Sw. Technology and Engineering Practice, pp. 8–56 (2004) 21. Machado, R.J., Fernandes, J.M., Monteiro, P., Rodrigues, H.: Transformation of uml models for service-oriented software architectures. In: ECBS 2005: Proceedings of the 12th IEEE Int. Conf. and Workshops on Eng. of Computer-Based Syst., pp. 173–182. IEEE CS, Washington (2005) 22. Marschall, F., Schoenmakers, M.: Towards model-based requirements engineering for web-enabled b2b applications. In: ECBS 2003: 10th IEEE Int. Conf. and Workshop on the Engineering of Computer-Based Systems, pp. 312–320. IEEE CS, Huntsville (2003) 23. Mauco, M., Leonard, M., Riesco, D., Montejano, G., Debnath, N.: Formalising a derivation strategy for formal specifications from natural language requirements models. In: Proceedings of the Fifth IEEE Int. Symp. on Signal Processing and Inf. Technology, pp. 646–651 (2005) 24. Maz´ on, J.N., Trujillo, J., Lechtenbrger, J.: Reconciling requirement-driven data warehouses with data sources via multidimensional normal forms. Data & Knowledge Engineering 63(3), 725–751 (2007) 25. Mendes, E.: A systematic review of Web engineering research. In: ISESE 2005: Int. Symp. on Empirical Sw. Eng., pp. 498–507. IEEE, Los Alamitos (2005) 26. Mens, T., Czarnecki, K., Gorp, P.V.: 04101 discussion – a taxonomy of model transformations. In: Bezivin, J., Heckel, R. (eds.) Language Engineering for ModelDriven Software Development. No. 04101 in Dagstuhl Seminar Proceedings, Internationales Begegnungs- und Forschungszentrum f¨ ur Informatik (IBFI), Schloss Dagstuhl, Germany, Dagstuhl, Germany (2005)

A Systematic Review of the Use of Requirements Engineering Techniques

227

27. Naslavsky, L., Alspaugh, T.A., Richardson, D.J., Ziv, H.: Using scenarios to support traceability. In: TEFSE 2005: Proceedings of the 3rd International Workshop on Traceability in Emerging forms of Software Engineering, pp. 25–30. ACM, New York (2005) 28. Nicol´ as, J., Toval, A.: On the generation of requirements specifications from software engineering models: A systematic literature review. Inf. Softw. Technol. 51(9), 1291–1307 (2009) 29. Ozkaya, I., Akin, O.: Requirement-driven design: assistance for information traceability in design computing. Design Studies 27(3), 381–398 (2006) 30. Petticrew, M., Roberts, H.: Systematic Reviews in the Social Sciences: A Practical Guide. Blackwell Publishing, Malden (2006) 31. Raj, A., Prabhakar, T.V., Hendryx, S.: Transformation of sbvr business design to uml models. In: ISEC 2008: Proceedings of the 1st Conf. on India Software Engineering, pp. 29–38. ACM, New York (2008) 32. Rash, J., Hinchey, M., Rouff, C.: Formal requirements-based programming for complex systems. In: ICECCS 2005: Proceedings of the 10th IEEE Int. Conf. on Engineering of Complex Computer Systems, pp. 116–125 (2005) 33. Regnell, B., Runeson, P., Wohlin, C.: Towards integration of use case modelling and usage-based testing. Journal of Systems and Software 50(2), 117–130 (2000) 34. Santos, J., Moreira, A., Araujo, J., Amaral, V., Alferez, M., Kulesza, U.: Generating requirements analysis models from textual requirements. In: MARK 2008: First International Workshop on Managing Requirements Knowledge, pp. 32–41 (2008) 35. Shin, J.E., Sutcliffe, A.G., Gregoriades, A.: Scenario advisor tool for requirements engineering. Requirements Engineering Journal 10 (2004) 36. Sousa, K., Mendon¸ca, H., Vanderdonckt, J., Pimenta, M.S.: Supporting requirements in a traceability approach between business process and user interfaces. In: IHC 2008: Proceedings of the VIII Brazilian Symp. on Human Factors in Computing Syst., SBC, Porto Alegre, RS, Brazil, pp. 272–275 (2008) 37. Zhang, L., Jiang, W.: Transforming business requirements into bpel: A mda-based approach to web application development. In: WSCS 2008: IEEE International Workshop on Semantic Computing and Systems, pp. 61–66 (2008)

Slicing of UML Models Using Model Transformations Kevin Lano and Shekoufeh Kolahdouz-Rahimi Dept. of Computer Science, King’s College London

Abstract. This paper defines techniques for the slicing of UML models, that is, for the restriction of models to those parts which specify the properties of a subset of the elements within them. The purpose of this restriction is to produce a smaller model which permits more effective analysis and comprehension than the complete model, and also to form a step in factoring of a model. We consider class diagrams, individual state machines, and communicating sets of state machines.

1

Introduction

Slicing of programs was introduced by [12] as a technique for the analysis of software, and has also been used for reverse-engineering and re-factoring of software. With the advent of UML and model-based development approaches such as Model-Driven Development (MDD) and Model-Driven Architecture (MDA), models such as UML class diagrams and state machines have become important artifacts within the development process, so that slicing-based analysis of these models has potential significance as a means of detecting flaws and in restructuring these models. Slicing techniques for specification languages such as Z [13] and Object-Z [1] have been defined, based on variants of the concepts of control and data dependence used to compute slices for programs. However, UML contains both declarative elements, such as pre- and post-conditions, and imperative elements, such as behaviour state machines, so that slicing techniques for UML must treat both aspects in an integrated manner. We will use a generalised concept of slicing: a slice S of an artifact M is a transformed version of M which has a lower value of some complexity measure, but an equivalent semantics with respect to the sliced data: S <syn M ∧ S =sem M The relations <syn and =sem used depend on the type of analysis we wish to perform on M : S should have identical semantics to M for the properties of interest, but may differ for other properties. The slicing may be structurepreserving, so that S has the same structure as M although containing only a subset of its elements, or may be amorphous, with a possibly completely different structure [2]. D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 228–242, 2010. c Springer-Verlag Berlin Heidelberg 2010 

Slicing of UML Models Using Model Transformations

229

We will consider techniques for the structure-preserving and amorphous slicing of class diagrams and state machines. Model transformations will be used to perform slicing, each transformation will satisfy the <syn and =sem relations, resulting in a slice which also satisfies these relations compared to the original model. In general, applying slicing at a high level of abstraction simplifies the calculation of the slice, and means it is possible to detect specification flaws at an early development stage, thus reducing development costs.

2

Slicing of Class Diagrams

We consider first the most abstract form of UML specification using class diagrams to define the structure of classes and associations, and constraints in OCL to define behaviour by means of invariant constraints of classes and preand post-condition constraints of operations. The range of UML constructs considered here corresponds to the UML-RSDS subset of UML [5]. We assume that the client-supplier relation between different classes forms a tree structure. The class at the root of this tree is termed the controller class of the system: it will usually serve as the access point to the services of the system for external users. Operations are assumed to be deterministic. Figure 1 shows an example of this style of specification, for a lift control system. The data features of such a system are all the attributes of classes in the system, including association ends owned by the classes. For each class C there is also the system data feature C .allInstances() of all currently existing instances of C . Slicing will be carried out upon class invariants and operation pre and postconditions by considering the predicates P of which they are composed. A predicate is a truth-valued formula, whose main operator is not and . Class invariant predicates can be either assertions: properties which are expected to be invariant for

Lift maxfloor: Integer {frozen} lfloor: Integer dest: Integer lm: LMState dm: DMState dopen: Boolean dclosed: Boolean

lfloor is the current floor position of the lift dest is the next destination floor lm is the lift motor state, dm the door motor state dopen = true if the lift doors are fully open dclosed = true if the lift doors are fully closed maxfloor is the highest floor number

arrive(fpsx: Integer) request(fpsx: Integer) doorstartsopening() dooropens() doorstartsclosing() doorcloses()

> DMState opening closing stopped

> LMState up down stop

Fig. 1. Lift control system

230

K. Lano and S. Kolahdouz-Rahimi

objects of the class, but which do not contribute to the effect of operation postconditions, or effective: implicitly conjoined to the postcondition of each update operation. In order to reduce the dependencies in a model, we assume that certain effective class invariant predicates, and operation postcondition predicates are operational1 , if they have the form L implies R where R is a formula such as f = e, f →includes(e), f →excludes(e), f → includesAll (e), f →excludesAll (e), ref .f = e, ref .f →includes(e), ref .f → excludes(e), ref .f →includesAll (e), ref .f →excludesAll (e). f is a feature name, possibly with a selector →at (g) in the case of equality, for some expression g, in the case of an ordered role f . f is not a pre-form of a feature (ie, not x @pre for some feature x ). f is called the writable feature of the constraint. L may be omitted. L is the test part of the predicate, e the value part, ref the reference part, and g the index part. Other predicates are termed non-operational, they may (in the case of postcondition predicates) consist of a mixture of features in pre form and post form, all the features in post form are assumed to be writable in this case, and to be mutually data-dependent. In the lift example, there are class invariant constraints dclosed = false implies lm = stop dopen = true implies dclosed = false 0 ≤ dest and dest ≤ maxfloor 0 ≤ lfloor and lfloor ≤ maxfloor of Lift . Apart from the first predicate, these are all assertions. The operations of the lift can be specified as follows: init() /* Invoked at object creation */ post: lfloor = 0 and dest = 0 and dclosed = false and dopen = true and lm = stop and dm = stopped arrive(fpsx : Integer ) /* Lift arrives at floor fpsx */ pre: 0 ≤ fpsx and fpsx ≤ maxfloor post: lfloor = fpsx and fpsx = dest implies lm = stop and fpsx = dest implies dm = opening and dclosed = false implies lm = stop request(destx : Integer ) 1

/* Request to go to floor destx */

In the UML2Web toolset for UML-RSDS, developers can designate effective constraints as operational when they are created.

Slicing of UML Models Using Model Transformations pre: 0 ≤ destx and destx ≤ maxfloor post: dest = destx and destx > lfloor and dclosed = true implies destx < lfloor and dclosed = true implies destx = lfloor implies lm = stop and destx = lfloor and dopen = true implies destx = lfloor and dopen = false implies destx = lfloor and dclosed = false implies destx = lfloor and dclosed = true implies dclosed = false implies lm = stop doorstartsopening() pre: dclosed = true post: dclosed = false

and

231

lm = up and lm = down and dm = stopped and dm = opening and dm = closing and dm = stopped and

lm = stop

doorstartsclosing() pre: dopen = true post: dopen = false doorcloses() pre: dclosed = false and dopen = false post: dclosed = true and dm = stopped and dest > lfloor implies lm = up and dest < lfloor implies lm = down dooropens() pre: dopen = false and dclosed = false post: dopen = true and dm = stopped

For any system there are also implicit operational constraints which relate the two ends of binary associations (Figure 2). In this case a change to one end of the association implies a change to the other, because of the implicit constraints relating these ends (Table 1). The features which consist of these opposite association ends are data-dependent upon each other because they are derived features in terms of each other. Assertion constraints arise from the multiplicity restrictions of association ends, ie, a 0..n multiplicity end br has a constraint br →size() ≤ n. If class C is a subclass of class D then there is an effective non-operational constraint D .allInstances()→includesAll (C .allInstances()) and likewise for association ends r which specialise other ends s: s→includesAll (r ) and union relationships between association ends: ru = r1 ∪ . . . ∪ rn . Further implicit constraints for a class are the invariant constraints inherited from any superclass. Preconditions and postconditions from superclass versions of an operation are not inherited, if an explicit definition of the operation is defined in the subclass: this explicit definition replaces superclass definitions for objects of the subclass.

232

K. Lano and S. Kolahdouz-Rahimi

A

B ar M1

br M2

Fig. 2. Binary association Table 1. Implicit derivation constraints linking association ends M1 M2 Constraints * * ar = A.allInstances()→select(ax br = B .allInstances()→select(bx 1 * ar = A.allInstances()→select(ax br = B .allInstances()→select(bx * 1 ar = A.allInstances()→select(ax br = B .allInstances()→select(bx 1 1 ar = A.allInstances()→select(ax br = B .allInstances()→select(bx

| ax .br →includes(self )) | bx .ar →includes(self )) | ax .br →includes(self ))→any() | self = bx .ar ) | self = ax .br ) | bx .ar →includes(self ))→any() | self = ax .br )→any() | self = bx .ar )→any()

We will slice a class diagram specification M by slicing the controller class C of M : this class is directly or indirectly a client of all other classes in M and is not a supplier of any other class in M . A history of a specification M is a finite sequence of invocations of update operations on instances of C . A history is valid if operations are only invoked on instances which have been created, and for which the operation precondition is true at the point of call, in addition the history should conform to the protocol state machine SMC of C . For example, createLift (cx ), cx .request (10), cx .doorstartsclosing(), cx .doorcloses(), cx .arrive(1) is a valid history for the lift control system example, if maxfloor = 15. The definition of slicing we will use for class diagrams M is the following: S <syn M if the slice S has a subset of the elements of M . S =sem M holds, with respect to a given state s in the protocol state machine of C , and set V of data features of M , if any valid history σ with final state s of M is also a valid history with final state s in S , and if the values of the features in the slice set V in S in the final state of σ are equal to the values of these features in M at the final state when σ is applied to both models, starting from the same initial values for the features they have in common. We assume that the protocol state machines of C in M and S have the same states (more generally, the states in M could be a refinement of those in S ). The set of features and constraints in a slice S can be determined by examining the data dependencies of the constraints of the original model.

Slicing of UML Models Using Model Transformations

233

The first step in producing a slice of a class C is to normalise the class invariant, and each pre and post condition, so that these are all in the form of conjunctions of predicates. Formulae P implies R and Q are rewritten as P implies R and P implies Q, etc. Then the effective invariant predicates are copied to the postconditions of each update operation. Assertion predicates are not copied. For each postcondition predicate p we define the sets of features read and written in p, and its internal data dependencies: – wr (p) is the set of features written to in p. If p is operational, this set is the single writable feature of p, otherwise it is the set of features not in pre form in p. – rd (p) is the set of features read in p. If p is operational this is the set of all features occurring in the test, value, reference or index expressions in p, and the pre form f @pre of the writable feature f (in the case of a simple equality f = e, the pre form f @pre of the writable feature f itself is not included, unless it occurs in e). For other predicates rd (p) is the set of features in pre form, or input parameters. – In the case of a formula C .allInstances()→exists(P ) specifying creation of an instance of C satisfying P , C .allInstances() is a written feature and C .allInstances()@pre a read feature. – In the case of formulae x .oclIsNew () or x .isDeleted (), where x is of class type C , C .allInstances() is a written feature and C .allInstances()@pre and x are read features. – The internal data-dependencies of an operational predicate p are then: dep(p) = rd (p) × wr (p) and for a non-operational predicate dep(p) = (rd (p) ∪ wr (p)) × wr (p) There is data-dependency between two different predicates p and q in the same postcondition if p writes a feature which q reads: p → q ≡ wr (p) ∩ rd (q) = {} The write frame of an operation op is the union of wr (p) for the predicates p in its postcondition, this is denoted wr (op). The predicates in the postcondition of an operation are assumed to be control dependent on the predicates in the precondition [1]. At the level of particular features, f , g, there is a direct dependency of f on g in an operation op, if: – g → f is in some dep(p) for a postcondition predicate p of op. Let rop be the (non-reflexive) transitive closure of this relation. Then the feature dependency relation ρop of op includes the pairs:

234

K. Lano and S. Kolahdouz-Rahimi

– g → f if g occurs in the precondition and f is in wr (p) for some postcondition predicate p – g  → f if g is an input parameter of the operation, or is a feature not in wr (op), and g  → f is in rop – g → f if g@pre  → f is in rop – x  → x if x ∈ wr (op). The meaning of this relation is that the value of g at the start of the operation may affect the value of f at the end. Initial values of features not in ρ−1 op (| V |) cannot affect the value of any feature in V at termination of the operation. The feature dependencies of arrive in the control system are therefore: {maxfloor  → lfloor , fpsx  → lfloor , fpsx  → lm, dest  → lm, fpsx  → dm, dest  → dm, dclosed  → lm, lm  → lm, dm  → dm, maxfloor  → lm, maxfloor  → dm, dest  → dest , dclosed  → dclosed , dopen  → dopen, maxfloor  → maxfloor } For doorcloses they are: {dclosed  → dclosed , dopen  → dclosed , dclosed  → dm, dopen  → dm, → lm, dest  → lm, lfloor  → lm, dclosed  → lm, dopen  → lm, lm  dopen  → dopen, dest  → dest , lfloor  → lfloor , maxfloor  → maxfloor } In order to analyse dependencies between data in different operations, we need to consider the possible life histories of objects of the class. A UML class C may have a protocol state machine SMC as its classifierBehavior [6], this state machine defines what sequences of operations can be applied to the object, and under what conditions. This allows us to restrict dependencies by considering the possible orders in which data can be defined in one operation and used by another. Figure 3 shows the protocol state machine for the Lift class. State invariants such as dm = opening are considered as assertions and do not contribute to data or control dependencies. If an explicit protocol state machine is not provided for a class, then the default behaviour of the class is a state machine with a single state, and self transitions for each operation on this state, guarded by the operation preconditions. The state machine SMC can be used as the basis of the data and control flow graph GC of the class C . We assume that only basic and OR-composite states are present in SMC , and there are no history states. We carry out normalisation of the pre and post-conditions of each transition of t , so that these are conjunctions of predicates. The primary nodes of GC are: – The basic states of SMC – A precondition/guard node pret for each transition t of SMC – A postcondition node postt for each transition t of SMC .

Slicing of UML Models Using Model Transformations

235

arrive(f)[f /= dest] at floor [lm = stop] travelling

arrive(f)[f = dest]

[lm /= stop]

door starts to open [dm = opening]

doorstartsopening()

door opening [dm = opening]

doorcloses()

dooropens()

idle [dm = stopped] request(f) [f = lfloor]

request(f)[f /= lfloor] door starts to close [dm = closing] doorstartsclosing() door closing [dm = closing]

Fig. 3. Lift protocol state machine

Within each node pret there are subordinate nodes for each predicate of the guard of t , and each predicate of the precondition of the operation op that triggers t . Within each node postt there are subordinate nodes for each predicate of the postcondition of t , and each predicate of the postcondition of the operation op that triggers t . There is direct data dependency from a write occurrence d of a feature f within predicate p of a postcondition node n, to a read occurrence d  of f within predicate q of a node n  if either: = q and both d and d  are f 1. n = n  , p  2. n = n , d is f , d  is f @pre in a postcondition node, or f in a precondition node, and n  is reachable from n along a path σ following the control flow of the state machine, and there is no intermediate node m strictly between n and n  in σ which contains a write occurrence of f in its predicates. Figure 4 shows part of the data and control flow graph of the lift system, with direct data dependencies for dclosed between different top-level nodes marked by dashed lines. The dependency relation ρC is then the transitive closure of the union of the data-dependency and control-flow relations on predicates. The following algorithm is used to carry out the slicing transformation, for a state s and set V of features, using the graph GC . We associate a set Vx of features to each basic state node of the data and control flow graph. 1. Initialise each Vx with the empty set of features, except for the target state s, which has the set V of features.

236

K. Lano and S. Kolahdouz-Rahimi arrive_pre 0 dm = opening dclosed = false => lm = stop arrive_post lfloor = f f = dest => lm = stop f = dest => dm = opening dclosed = false => lm = stop

arrive_pre

arrive(f)[f /= dest]

0 lm = up dest < lfloor => lm = down

dooropens_post dopen = true dm = stopped idle [dm = stopped]

doorcloses_pre dclosed = false dopen = false

request(f) [f = lfloor]

request(f)[f /= lfloor] door starts to close [dm = closing]

Fig. 4. Lift data and control flow graph

2. For each transition t : s1 → s2, add to Vs1 the set ρ−1 op (| Vs2 |) of features upon which Vs2 depends, via the version of the operation op executed by this transition (with precondition and postcondition formed from both the class and state machine predicates for op and t ). Mark as included in the slice those predicates of pret , postt which are in ρ−1 C (| ps |) where ps is the set of predicates contained in postt which have write occurrences of features in Vs2 . The set of features (with pre removed) used in the marked predicates are also added to Vs1 . The second step is iterated until a fixed point is reached. Each Vx then represents the set of features whose value in state x can affect the value of V in state s, on one or more paths from x to s. (Parameter values of operations along the paths may also affect V in s). Let V  be the union of the Vx sets, for all states x on paths from the initial state of SMC to s. The set of features retained in the slice S will be set equal to V  . If the lift system is sliced with s = idle, V = {dm}, then V  is the set of all features of the lift, with lm removed. The new class invariant constraints are: dopen = true implies dclosed = false 0 ≤ dest and dest ≤ maxfloor 0 ≤ lfloor and lfloor ≤ maxfloor The sliced init and request operations of the lift are: init() post: lfloor = 0 and dest = 0 and dclosed = false dopen = true and dm = stopped

and

Slicing of UML Models Using Model Transformations

request(destx : Integer ) pre: 0 ≤ destx and destx post: dest = destx and destx = lfloor and dopen destx = lfloor and dopen destx = lfloor and dclosed destx = lfloor and dclosed

237

≤ maxfloor

= true implies dm = stopped and = false implies dm = opening and = false implies dm = closing and = true implies dm = stopped

If an effective invariant predicate does not occur in any operation postcondition in the slice, then it can be removed from the class. If a data feature does not occur in any operation or effective invariant within the specification, then it can be removed, together with any assertions that refer to it. In the above example, lm can be removed from the Lift class, together with the invariant involving lm. In general, the sliced specification will be smaller, more easy to analyse and verify, and will define the same properties as the original system for the features V . Therefore, slicing may substantially reduce the size of the model to be checked, and make verification, eg, by translation to a proof tool such as B [11], feasible when verification of the original model was not feasible. This form of slicing is structure-preserving. The transformation we have described above does produce a semantically correct slice S of a model M , using the definition =sem of semantic equivalence, because, if σ is a valid history of M (ie, of the controller class C of M ), ending in the slice target state s, and V a set of features of M , then: – σ is also a valid history of S , since the set of states in the controller class state machine are the same in both models, as are the preconditions and guards of each transition in the models – the features retained in S are the union V  of the sets Vx of the features upon which V in s depends, for each state x of any path to s, and hence V  contains Vx for each state on the history σ, and in particular for the initial state – since the values of the features of V  in the initial state are the same for S and M , and the values of operation parameters are also the same in the application of σ to S and M , the values of V in s are also the same in both models.

3

Behaviour State Machine Slicing

Operations may have their effect defined by a behaviour state machine, instead of a postcondition. Such state machines do not have operation call triggers on their transitions, instead their transitions are triggered by completion of the source state. The state machines will also have a final state, representing termination of the operation whose effect they define. Slicing can be carried out for such state machines, using data and control flow analysis to remove elements of the

238

K. Lano and S. Kolahdouz-Rahimi {}

s2 [dest > lfloor]/lm := up

{dm}

/dm := stopped s1

[dest = lfloor]

{dm} {dm} [dest < lfloor]/lm := down

s3 {dm}

Fig. 5. doorcloses state machine

machine which do not contribute to the values of a set of features in the final state of the machine. The criteria for a slice S of a state machine M are: S <syn M if S has fewer elements (states, transitions, transition actions, etc) than M . S =sem M if for all possible sequences e of input events of M , starting from S and M in their initial states, with the same values for their common features in the initial states, the state s of interest is reached by S as a result of the sequence e whenever it is reached by M as a result of the same sequence, and then the value of the features V of interest in the state s of interest are the same in the two models. We assume that s is in both state machines2 . This means that any analysis which concerns the value of the slice features V in the selected state s, over all paths to this state, can be performed on the slice S , and the result will also apply to M . In particular, if predicate P can be proved to be a state invariant of s in S , then it will also be a state invariant of s in M . States which cannot occur in paths from the initial state to the state of interest can be deleted from the model, together with their incoming and outgoing transitions. Care must be taken concerning the state machine notation considered, and the semantics adopted, since the computation of the slice will differ from version to version. Three alternative semantics can be used, in the case that there is not a complete set of guards covering all possibilities of an event occurrence in a given state [8]: skip/ignore semantics; precondition/exception semantics; blocking semantics. We will assume skip semantics for behaviour state machines. Actions on state machine transitions will either be assignments or, for communicating state machines, invocations of operations on supplier objects. Figure 5 shows an example state machine, of the doorcloses operation. The predicate dclosed = true remains in the operation postcondition, the other effects of the operation are defined by the state machine. Given a particular state s in a state machine and a set V of features of interest in that state, we determine the slice of the state machine with respect to s and V by computing for each state x of the state machine, a set Vx of features such 2

In the case of behaviour state machines for operations, the empty sequence is the only case that needs to be considered for e.

Slicing of UML Models Using Model Transformations {}

239

s2 [dest > lfloor]

{dm}

/dm := stopped s1

[dest = lfloor]

{dm} {dm} [dest < lfloor]

s3 {dm}

Fig. 6. doorcloses state machine after transition slicing

that: the value of the features of Vx in state x may affect the value of a feature in V in state s, but that no other feature in state x can affect V in state s. That is, for all possible paths from x to s, the value of V in s at the end of the path depends only upon the values of Vx in x at the start of the path. The sets Vx are computed by an iteration over all the transitions of the state machine. They are initialised to {} for x = s, and to V for Vs . For each transition tr : s1 →op(p)[G]/acts s2 the set Vs1 of features of interest in s1 are augmented by all features which appear in Preop and G, and by all features which may affect the value of Vs2 in s2 as a result of the class definition of op(p), followed by acts 3 . This iteration is repeated until there is no change in any Vx set. These dependencies can be simplified, and the Vx sets made smaller, by omitting features of the guards in cases where the values of features in Vs in s always depend on the Vx in the same way, regardless of the paths taken from x to s because of different guards. In Figure 5 the transition guards do not affect the value of dm in the final state, so their features do not need to be added to the dependency set {dm} of s1. Using the sets Vx , further transformations can be applied to simplify the state machine: transition slicing, transition deletion, transition merging and state merging, and replacing variables by constants. Individual transitions are sliced by removing actions which cannot contribute to the values of the features V in state s. For a transition tr : s1 →op(x )[G]/acts s2 all updates in acts which do not affect Vs2 in s2 can be deleted from acts to produce a simpler transition. Figure 6 shows the operation example after transition slicing, for V = {dm} and s being the final state. Transitions can be deleted if their guard is equivalent to false. Two transitions can be merged if their sources, targets and actions are the same. The 3

The usual definition of data-dependency due to assignment is used: in x := e x depends on all features in e, and features apart from x depend on themselves. Dependencies for operation calls are calculated from the definition of the called operation.

240

K. Lano and S. Kolahdouz-Rahimi

guard of the resulting transition is the disjunction of the original guards. tr 1 : s1 →op(x )[G1]/acts s2 and tr 2 : s1 →op(x )[G2]/acts s2 can be replaced by: tr : s1 →op(x )[G1

or G2]/acts

s2

A further transformation that can be applied is to replace a feature v by a constant value e throughout a state machine, if v is initialised to e on the initial transition of the state machine, and is never subsequently modified. A group K of states can be merged into a single state k if: 1. All transitions between the states of K have no actions. 2. All transitions which exit the group K are triggered by events distinct from any of the events that trigger internal transitions of K . If two transitions that exit K have the same trigger but different target states or actions, they must have disjoint guard conditions. 3. Each event α causing exit from K cannot occur on states within K which are not the explicit source of a transition triggered by α. Two states can also be merged if their sets of outgoing (or incoming) transitions are equivalent [3]. In the doorcloses example, the states s2 and s3 can be merged, and the two incoming transitions to the merged state can then be merged, to give a condition dest = lfloor . The transformations have been specified as rules in the UML-RSDS model transformation language [7]. For example, transition merging can be defined by: mergeTransitionPair (t1 : Transition, t2 : Transition) : Transition pre: t1.source = t2.source and t1.target = t2.target and t1.trigger = t2.trigger and t1.effect = t2.effect post: Transition.allInstances()→includes(result) and result.oclIsNew () and result.source = t1.source and result.target = t1.target and result.trigger = t1.trigger and result.effect = t1.effect and result.guard = or (t1.guard , t2.guard ) and t1.isDeleted () and t2.isDeleted ()

An algorithm combining these state machine slicing transformations has been implemented in the UML2Web tool, and applied to several complex examples, including manufacturing control systems based upon [10]. Slicing with respect to a subset V of the actuators of a control system produces a subcontroller which explicitly identifies which sequences of events and which subset of sensors actually determine the actuator settings, supporting semantic analysis and remodularisation of controllers.

4

Slicing of Communicating State Machines

The above slicing approach can be extended to systems which consist of multiple communicating state machines, attached to linked objects, provided that the

Slicing of UML Models Using Model Transformations

241

communication dependencies M 1 → M 2 (M 1 sends messages to M 2) form a tree structure. The data of a state machine then also includes implicitly the data of all machines directly or indirectly subordinate to it (ie, the data of objects whose operations are invoked from the state machine). The same concepts of <syn and =sem can be used as for single state machines, but with respect to the full data of each state machine, including the data of subordinate (supplier) machines.

5

Related Work

Several approaches have been defined for the slicing of state machine models, such as Korel [4] and Clark [2]. These are based upon generalisations of program slicing using concepts of node post-domination [9] within graphs. However these approaches involve the construction of potentially a possibly very large data-and-control flow graphs. Our technique is based instead upon the semantic notion of path-predicates, as used in static analysis tools such as SPADE. This technique assigns to each program path a predicate which defines how the values of variables at the end state of the path relate to the values at the start state, over all executions of the path. We approximate these predicates by computing the sets Vx of variables in the path predicate for each state in the state machine. Acknowledgement. This research has been supported by the SLIM EPSRC project.

References 1. Bruckner, I., Wehrheim, H.: Slicing Object-Z Specifications for Verification. In: Treharne, H., King, S., Henson, M.C., Schneider, S. (eds.) ZB 2005. LNCS, vol. 3455, pp. 414–433. Springer, Heidelberg (2005) 2. Clark, D.: Amorphous Slicing for EFSMs. In: PLID 2007 (2007) 3. Ilie, L., Solis-Oba, R., Yu, S.: Reducing the size of NFAs by using Equivalences and Preorders. In: Apostolico, A., Crochemore, M., Park, K. (eds.) CPM 2005. LNCS, vol. 3537, pp. 310–321. Springer, Heidelberg (2005) 4. Korel, B., Singh, I., Tahat, L., Vaysburg, B.: Slicing of State-based Models. In: ICSM 2003, 19th IEEE International Conference on Software Maintenance. IEEE Press, Los Alamitos (2003) 5. Lano, K.: Constraint-Driven Development. Information and Software Technology 50, 406–423 (2008) 6. Lano, K. (ed.): UML 2 Semantics and Applications. Wiley, Chichester (2009) 7. Lano, K., Kolahdouz-Rahimi, S.: Model Migration Transformation Specification in UML-RSDS. In: TTC 2010, Malaga, Spain (2010) 8. OMG, UML superstructure, version 2.1.1. OMG document formal/2007-02-03 (2007) 9. Ranganath, V.P., Amtoft, T., Banerjee, A., Hatcliff, J.: A New Foundation for Control Dependence and Slicing for Modern Program Structures. ACM Trans. Prog. Lang. and Sys. 29(5) (August 2007)

242

K. Lano and S. Kolahdouz-Rahimi

10. Sanchez, A., Aranda-Bricaire, E., Jaimes, F., Hernandez, E., Nava, A.: Synthesis of product-driven coordination controllers for a class of discrete-event manufacturing systems. Elsevier Science, Amsterdam (2009) (preprint) 11. Snook, C., Wheeler, P., Butler, M.: Preliminary Tool Extensions for Integration of UML and B, IST-2000-30103 deliverable D4.1.2 (2003) 12. Weiser, M.: Program slicing. IEEE Transactions on Soft. Eng. 10, 352–357 (1984) 13. Wu, F., Yi, T.: Slicing Z Specifications. ACM Sigplan 39(8) (August 2004)

An Adjustable Transformation from OWL to Ecore Tirdad Rahmani, Daniel Oberle, and Marco Dahms SAP Research, CEC Karlsruhe Vincenz-Priessnitz-Str. 1, 76131 Karlsruhe, Germany {tirdad.rahmani,d.oberle,marco.dahms}@sap.com

Abstract. Although there are sufficient similarities between the W3C Web Ontology Language OWL and the software modeling language Ecore, little research has been conducted into approaches which allow software engineers to incorporate existingWeb ontologies into their familiar Ecore-based software engineering environments. This is becoming important since the number of significant Web ontologies is growing and software engineers are increasingly challenged to build software relying on such ontologies. Therefore, we propose an automatic transformation between OWL and Ecore, that is adjustable between the two extremes of a result which is simple to understand, or a result, which preserves as much as possible of the source ontology. The transformation is realized as an Eclipse plug-in and, thus, integrates seamlessly with a software developer’s familiar environment.

1 Introduction The Semantic Web is an evolving development of the WWW in which the meaning of information and services on the web is formalized. [2] Since its inception, the WWW Consortium (W3C) created several language recommendations for describing the meaning of information. A prominent recommendation is the Web Ontology Language (OWL) [10], which is increasingly being used in the Web. OWL serves as a language for more expressive ontologies and is typically used to define reference ontologies, such as the ISO 15926 Oil and Gas ontology standard [8]. So far, the Semantic Web community has addressed the software engineering community by applying its strengths in formality and reasoning capabilities to software engineering for quality and productivity improvement. A good example for this stream of work is given in [14]. However, there has been little research on allowing software engineers to incorporate existing Web ontologies into their familiar software engineering environments. At first sight, the task of incorporating ontologies seems straightforward since the main modeling primitives are classes and relations in both cases. This task is becoming important since the number of significant Web ontologies is growing and software engineers are increasingly challenged to build software relying on such ontologies. As an example, consider the Oil and Gas industry whose goal is to enable information integration based on ISO 15926 to support the interpretation of sensor data, information validation and web services [13]. Corresponding software solutions, such as [3], rely on the ontology but typically require manual remodeling of ISO 15926 in a software engineering or MDA language. In order to prevent such manual efforts and D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 243–257, 2010. c Springer-Verlag Berlin Heidelberg 2010 

244

T. Rahmani, D. Oberle, and M. Dahms

still enable software engineers to use their familiar environments, we propose a transformation between OWL and the modeling languages Ecore plus OCL. At second sight, there are less similarities between both languages, which makes the transformation intricate. For example, OWL does not rely on the unique name assumption unlike Ecore. In addition, this lack of similarities opens configuration options for transforming OWL ontologies. Therefore, we allow a software engineer to adjust the transformation between the two extremes of a result simple to understand or a result that preserves as much as possible of the source ontology. The paper is structured as follows: Section 2 outlines the fundamental properties of OWL and, in particular, highlights the differences to software engineering languages such as Ecore. Section 3 presents our contribution, viz., transforming the OWL modeling primitives into the Ecore modeling primitives. In Section 4 we continue with detailing the realization of an adjustable transformation of a complete ontology. Finally, related work, a discussion, and conclusion are given in Sections 5 to 7, respectively.

2 Comparison of OWL and Ecore Fundamentals In this section we detail the language properties of OWL and point out the differences to Ecore. Understanding the differences is a prerequisite for understanding our proposed transformation in Section 3. Open vs. Closed World Assumption. Semantic Web languages such as OWL are based on the open world assumption (OWA). The absence of a particular statement within the web means that the statement has not been made explicit yet. In this case one must not infer, that the statement is false. On the other hand, the closed world assumption (CWA) is adopted by many software engineering languages such as Ecore, since complete control of information about the modeled software systems is a strong requirement. As an example, consider the statement Daniel is a Person and assume nothing is asserted about Tirdad. The answer to the question Is Daniel a Person? would be yes for both assumptions. However, assuming an open world, the answer to Is Tirdad a Person? would be unknown whereas in a closed world the answer would be no. Web Compliance. The Web Ontology Language OWL is specifically designed for publishing and exchanging knowledge on the Web. Accordingly, everything that can be specified in OWL, e.g., classes, and even the modeling primitives themselves, are identified via URIs. For example, the owl:Class primitive is assigned to http://www. w3.org/2002/07/owl#Class or a user-defined class such as Person to http:// www.myexample.org#Person. In contrast, languages in the software engineering and MDA realm use GUIDs and are not meant for publishing on the Web. Unique Name Assumption. The Unique Name Assumption (UNA) states that if two things have different names they are handled as different entities. OWL does not make this assumption, i.e., entities must be explicitly declared as different or identical by using the owl:differentFrom and owl:sameAs constructs, respectively. On the contrary, different names identify different entities within software engineering approaches.

An Adjustable Transformation from OWL to Ecore

245

As discussed above, all resources must have an URI as their unique identifier in OWL and are organized in namespaces. Furthermore, two different names, e.g., two different URIs, can refer to the same class. In Ecore however, elements are organized in packages. The package name and class names within one package must be unique. Properties as First-Class Citizens. At first glance, the notions of reference in Ecore corresponds to what is called a property in OWL. However, properties are first-class modeling elements, that means they can exist “on their own” without being mandatorily attached to a class. Therefore, properties can be applied between several different pairs of classes, and can be organized as a hierarchy. Furthermore properties can be locally or globally constrained. As an example, consider the property part which can be applied between Person and Bodypart as well as between House and ConstructionElement and any other arbitrary pair of classes. In contrast, references in Ecore have to be attached to exactly one pair of classes leading to two separate part references. Expressiveness. The expressiveness of OWL and Ecore does not completely overlap. For example, OWL allows the intensional definition of classes, such as Person ≡ Man ∪ Woman, or the definition of property hierarchy via the owl:subPropertyOf assertion. Native Ecore does not feature such modeling constructs. In addition, Ecore defines the notion of interfaces, abstract classes, and methods. Individuals. OWL can be used to model what is called a TBox (Terminological Box) and an ABox (Assertional Box) at the same time. The TBox basically corresponds to a class diagram, i.e., the definition of classes and references. The ABox consists of class individuals and facts about them and corresponds to an object diagram in the software engineering world. In contrast, Ecore is built based on MOF and divides modeling in four layers, viz., M3 to M0, where M0 is only considered at runtime. Example: In OWL we can specify that a Person is a class (TBox) and Tirdad and Daniel are individuals of this class (ABox). In Ecore it would require either two different types of meta languages (class vs. object diagram) or the specification on different layers. Cardinality. Another significant aspect is the intuition of cardinality constraints. When a software engineer specifies an attribute, e.g., Age, the cardinality is implicitly constrained to 0..1. When an ontologist defines a datatype property, the cardinality is constrained to 0..*, although they implicitly mean 0..1, since there are few use cases where several assigned Ages to one individual make sense. Model and Proof Theory. OWL is actually a description logic [7] with underlying formal semantics based on a Tarski-style model-theory [12]. The formal semantics allows one to assign truth values to each syntactic expression that is valid in the language. In our running example, the syntactic expression Daniel is a Person would evaluate to true. In turn, a model-theory is a prerequisite for a proof-theory. The proof-theory enables automatic inferences based on a logic calculus. OWL inference engines (also called reasoners) implement and typically support the following three reasoning tasks: – Subsumption Checking concerns the TBox and infers super- and subclass relations between classes. Being applied mutually to every possible pair of classes, subsumption checking makes it possible to build the whole class hierarchy. As an example,

246

T. Rahmani, D. Oberle, and M. Dahms

consider the complex class definition Person that is equivalent to the union of the classes Man and Woman. The reasoner would automatically infer that both classes Man and Woman are subclasses of Person. – Consistency Checking concerns the TBox and ABox and examines whether an ontology contains contradictions. A simple example for an inconsistency would be the assertions Tirdad is a Man, Tirdad is a Woman, together with the disjointness of both classes, i.e, Man owl:disjointFrom Woman. – Instance Classification concerns the ABox and checks whether an instance i is a member of a class C. Given the aforementioned definitions and assertions, instance classification performs a membership test and would yield Person and Man as the classes to which the individual Daniel belongs.

3 Transformation of OWL Modeling Primitives In this section we introduce the transformation of OWL modeling primitives to Ecore in detail. For a more comprehensive study, the reader is referred to [4]. 3.1 Class Hierarchy Generally, the corresponding counterpart of OWL classes and sub- and superclass declarations are Ecore classes and supertype declarations. In OWL two classes Thing and Nothing exist by default so that Thing is the superclass of all classes. Thing denotes the root of the class hierarchy. Correspondingly, the class Nothing is the subclass of every class and no individual can be asserted to the Nothing without losing consistency. Additionally, the definition of anonymous classes is possible in OWL. Anonymous classes are unnamed classes representing a set of individuals of a given characteristic. For instance, the anonymous class Woman ∪ Man is the set of all individuals that are either a woman or a man and the class ∃hasFriend.Artist is the class of individuals that have at least one artist as a friend. Such classes can be made explicit in the Ecore world, like Person ≡ Woman ∪ Man or handled as local restrictions as further explained in section 3.5. When the ABox is to be transformed, individuals that are already explicitly asserted to an anonymous class must be made explicit. In addition, one has to consider that OWL allows individuals to be members of several classes that are not necessarily in a sub- or superclass relation. This is by nature not possible in the Ecore world. The solution that we propose is the definition of the following equivalent relation on the set of individuals where ζ is the set of all classes included in the OWL ontology and I1 and I2 are two arbitrarily chosen individuals: I1 ≡ I2 :⇐⇒ ∀C∈ζ : I1 ∈ C ⇔ I2 ∈ C. Based on the proposed relation additional helper classes for each equivalent class will be included in the hierarchy at a position where all individual assertions become preserved. The position can be determined by the membership class of each equivalent class. The membership class includes all classes to which the individuals of an equivalent class have been asserted. The new helper classes will be declared as a subclass of all membership classes or the subclass of the common subclass of all membership classes, if such a class already exists (cf. the example of Demigod and King in Fig. 1).

An Adjustable Transformation from OWL to Ecore

247

On the right hand side of Fig. 1, a set of individual assertions is illustrated with the built equivalent classes based on the previously introduced equivalent relation together with the membership classes. The created helper classes are positioned correctly in the class hierarchy depicted on the left hand side, which leads to the hierarchy in the middle of the figure. Individual Assertions:

Thing

Thing

Human={Hercules, Helen, Tirdad} King={Constantine, Alexander} Demigod={Achilles, Hercules, Helen}

God

God

Human

Human Demigod

Demigod

King

King

Nothing

Help3

Nothing

Equivalent Classes: [Achilles] = {Achilles, Hercules, Helen} [Alexander] = {Constantine, Alexander} [Tirdad] = {Tirdad}

Membership Classes (MC):

Help2 Help1

God={Alexander}

MC([Achilles])={Demigod, God, Human} (See Class Help1) MC([Alexander])={God, Human} (See Class Help2) MC([Tirdad])={Human} (See Class Help3)

Fig. 1. Helper classes required for the correct ABox transformation

3.2 Individuals The counterpart of individuals in the OWL world are objects or instances in the Ecore world. In order to handle individuals properly in the Ecore world special EAttributes and EReferences are assigned to the class Thing. For instance, the EAttribute nameOfIndividual is used to capture the name of an individual and namespacePrefixOfIndividual is used to store the namespace qualifier of an individual. Through usage of this attributes it will be possible to pinpoint a concrete individual in OCL invariants. On the one hand, OWL does not implement the unique name assumption and generally individuals can neither be inferred to be identical nor different as long as it is not explicitly specified by sameAs and differentFrom definitions. On the other hand, Ecore objects are different by default. Therefore, the class Thing in the Ecore world has two EReferences to itself with the names sameAs and differentFrom that are marked as EOpposite references to themselves. 3.3 Properties Properties in OWL are either object properties or datatype properties. Object properties will be transformed to EReferences and datatype properties to EAttributes. Domain and range specifications of object properties can either be not specified or specified as an explicitly named or anonymous class. If there is nothing specified then the class Thing becomes the domain resp. range of the object property. In case of anonymous classes the domain and range specifications will firstly be made explicit through an equivalent class declaration, which leads to an extension of a copied version of the required ontology for the transformation. Furthermore, if the object property has an inverse property then the corresponding EReference will be marked as an EOpposite reference.

248

T. Rahmani, D. Oberle, and M. Dahms

The domains of datatype properties are handled analogously as the domains of object properties. The range of a datatype property can be unspecified or can consist of multiple datatype specifications which is possible in OWL 1.1 and prohibited in OWL 2. On the other hand, Ecore is a strictly typed modeling language. Therefore, we use the EString type for EAttributes for such range specifications, which makes it possible to store at least every asserted data value. In all other range specification cases the corresponding datatype in the Ecore world will be chosen, e.g., EInt for Integers, or a new EDataType will be created if no correspondence exists. Finally, multiplicities for EReferences are set to 0 for lower bound and -1, which is equal to * for upper bound for all kind of properties without an explicit cardinality constraint. 3.4 Property Hierarchy As mentioned earlier, OWL properties are first order citizens that can be organized in a hierarchy of binary relations. For the object property pairs hasUncle and hasRelative where hasUncle is a direct subproperty of hasRelative, the domain of hasUncle will be inferred by the reasoner to be a subclass of the domain of hasRelative and the range of hasUncle to be a subclass of the range of hasRelative. Additionally, the reasoner will infer the fact hasRelative(a,b) from the relation pair hasUncle(a,b). Consequently, the transformation of the ABox requires the materialization of all inferred implicit knowledge by the reasoner, since in the Ecore and OWL world only specification and query mechanisms are available. Additionally, the following OCL constraint added to the domain class Person of the property hasUncle ensures the sub and super property relation given in the OWL world. P e r s o n . a l l I n s t a n c e s ()−> f o r A l l ( x , y | x . h a s U n c l e −>i n c l u d e s ( y ) i m p l i e s x . h a s R e l a t i v e −>i n c l u d e s ( y ) ) For the datatype property pair spouseName and partnerName where spouseName is direct subproperty of partnerName the domain of spouseName will be inferred by the reasoner to be a subclass of the domain of partnerName. If the ranges match and are of the same type (exactly one type) the following OCL constraint will be added to the domain class Person of spouseName, which ensures a consistent data property hierarchy in Ecore. P e r s o n . a l l I n s t a n c e s ()−> f o r A l l ( x | x . spouseName = x . p a r t n e r N a m e ) 3.5 Local Restrictions Local restrictions in OWL are statements about properties with respect to individuals of a certain class. Usually one defines an anonymous class expression and declares it as superclass or equivalent class of a given class. Through inheritance all individuals are then forced to adhere to the restrictions stated by the anonymous class expression. Let us assume the property P with the domain class D to be restricted on the class A. Thus, A automatically becomes subclass of D through inference of the reasoner. After the transformation to an Ecore model, class A would already own an EReference

An Adjustable Transformation from OWL to Ecore

249

P through inheritance from class D. In conclusion, it is necessary and sufficient to use OCL invariants attached to class A in the Ecore world to handle local restrictions. In the following, OCL invariants for all essential local restrictions are illustrated based on comprehensive examples. AllValuesFrom with A=Person and P=hasPet: ObjectAllValuesFrom( a:hasPet a:Dog ) P e r s o n . a l l I n s t a n c e s ()−> c o l l e c t ( x | x . h a s P e t )−> f o r A l l ( y | y . o c l I s K i n d O f ( Dog ) ) SomeValuesFrom with A=Person and P=fatherOf : ObjectSomeValuesFrom( a:fatherOf a:Man ) P e r s o n . a l l I n s t a n c e s ()−> c o l l e c t ( x | x . f a t h e r O f )−> e x i s t s ( x | x . o c l I s K i n d O f ( Man ) ) UnionOf with A=Person and P=hasRelative: ObjectAllValuesFrom( a:hasRelative ObjectUnionOf( a:Woman a:Man)) P e r s o n . a l l I n s t a n c e s ()−> c o l l e c t ( x | x . h a s R e l a t i v e )−> f o r A l l ( x | x . o c l I s K i n d O f ( Woman) or x . o c l I s K i n d O f ( Man ) ) IntersectionOf and ComplementOf with A=Person and P=hasYoungSister: ObjectAllValuesFrom(a:hasYoungSister ObjectIntersectionOf( a:Woman ObjectComplementOf( a:AdultWoman)) P e r s o n . a l l I n s t a n c e s ()−> c o l l e c t ( x | x . h a s Y o u n g S i s t e r )−> f o r A l l ( x | x . o c l I s K i n d O f ( Woman) and n o t x . o c l I s K i n d O f ( AdultWoman ) ) Enumeration Classes with A=Wine and P=hasColour: ObjectAllValuesFrom(a:hasColour ObjectOneOf(a:White a:Red)) Wine . a l l I n s t a n c e s ()−> c o l l e c t ( x | x . h a s C o l o u r)−> f o r A l l ( y | y . n a m e O f I n d i v i d u a l = ’ w h i t e ’ or y . n a m e O f I n d i v i d u a l = ’ r e d ’ ) HasValue with A=AlexandersChildren and P=hasFather: ObjectHasValue(a:hasFather Alexander) A l e x a n d e r s C h i l d r e n . a l l I n s t a n c e s ()−> c o l l e c t ( x | x . h a s F a t h e r)−> e x i s t s ( x | x . nameOfIndividual = ’ Alexander ’ ) Cardinality without sameAs relation: ObjectMaxCardinality( 2 a:hasParent ) P e r s o n . a l l I n s t a n c e s ()−> c o l l e c t ( x | x . h a s P a r e n t)−> s i z e () c o l l e c t ( x | x . h a s P a r e n t)−> i t e r a t e ( x :A ; a c c 1 : S e t (A) = s e l f . h a s P a r e n t | i f acc1−>i n c l u d e s ( x ) and x . sameAs−>a s S e t ()−> s i z e () >0 then acc1−>a s S e t ()−> s e l e c t ( y | x . sameAs−>i n c l u d e s ( y))−> i t e r a t e ( z :A ; a c c 2 : S e t (A) = S e t {} | acc1−>e x c l u d i n g ( z ) ) e l s e a c c 1 e n d i f )−> s i z e () i t e r a t e ( x :A; a c c 1 : S e t (A) = s e l f . h a s f a t h e r | i f acc1−>i n c l u d e s ( x ) and x . sameAs−>a s S e t ()−> s i z e () >0 then acc1−>a s S e t ()−> s e l e c t ( y | x . sameAs−>i n c l u d e s ( y))−> i t e r a t e ( z :A; a c c 2 : S e t (A) = S e t {} | acc1−>e x c l u d i n g ( z ) ) e l s e a c c 1 e n d i f )−> s i z e () f o r A l l ( x , y | ( x . f a t h e r O f −>s i z e () >0 and y . f a t h e r O f −>s i z e () >0 and ( x . f a t h e r O f −>a s S e t ( ) = y . f a t h e r O f −>a s S e t ( ) ) i m p l i e s x=y or x . sameAs−>i n c l u d e s ( y ) ) ) Symmetric and Transitive Object Properties: Generally, symmetric and transitive object properties are symmetric and transitive binary relations R in the mathematic sense over a specific set X, which is the domain and range of the property. The following OCL constraints will force software engineers to keep on satisfying the symmetric and transitive characteristic of the corresponding association created by the transformation in the Ecore world.

An Adjustable Transformation from OWL to Ecore

251

OWL Assertion: SymmetricObjectProperty(a:hasFriend) P e r s o n . a l l I n s t a n c e s ()−> f o r A l l ( x , y | ( x . h a s F r i e n d −>a s S e t ()−> i n c l u d e s ( y ) ) i m p l i e s ( y . h a s F r i e n d −>a s S e t ()−> i n c l u d e s ( x ) ) ) OWL Assertion: TransitiveObjectProperty(a:ancestorOf) P e r s o n . a l l I n s t a n c e s ()−> f o r A l l ( x , y | x . a n c e s t o r O f −>i n c l u d e s ( y ) i m p l i e s x . a n c e s t o r O f −>a s S e t ()−> f o r A l l ( z | x . a n c e s t o r O f −>a s S e t ()−> i n c l u d e s ( z ) ) ) Remark about Property Characteristics for ABox Transformation: In the Ecore and OCL world there only exist query mechanisms without any reasoning support. This fact requires the transformation to materialize implicit knowledge inferred about individuals of an ABox. For instance, a reasoner can deduce xRy from yRx when R is a symmetric object property. Similar inferences are possible for all other property characteristics and need to be considered. For example, in case of a transitive property, the transitive closure has to be materialized. 3.7 Further Modeling Primitives In this section, the transformation of further modeling primitives, viz., Annotation Properties, Equivalent Classes, Identical Individuals, and Namespaces is discussed briefly. Annotation Properties in OWL can be used to annotate any modeling primitive with additional information. The counterpart in the Ecore world are EAnnotations which consist of a source attribute of type EString used to specifiy the type of the Annotation and a HashMap from EString to EString used to store relevant information contained in an EAnnotation. OWL classes can be declared to be equivalent, which has impact on the subsumption reasoning and instance classification. Ecore classes cannot be marked as equivalent. Therefore, within our transformation firstly a copied version of the ontology becomes modified in a way to simplify the transformation. For example, in case of equivalent classes the software engineer will be approached to specify one representative class. In all assertions including one of the equivalent classes a replacement with the representative class takes place. The class names of the equivalent classes will be attached as an EAnnotation to the corresponding Ecore class so that the software engineer has enough insight about naming issues for possible changes after the transformation. Two transformation options are foreseen for handling identical individuals. In the first option, all identical individuals are transformed and then marked to be identical by the EReference sameAs. Through OCL constraints value equivalence for EReferences and EAttributes will be forced between identical individuals. But on the object level they remain different. The second option is to specify a representative individual used for replacement in all assertions including an identical individual. The names of the identical individuals will be stored in the EAttribute namesOfIndividuals of the Ecore class Thing typed as List<EString>. Namespaces in OWL are URIs that might also have a qualified name. For individuals in Ecore there are two EAttributes namespaceOfIndividual and namespacePrefix

252

T. Rahmani, D. Oberle, and M. Dahms

OfIndividual assigned to the class Thing, which allows one to pinpoint individuals precisely in any OCL constraint. For all other modeling primitives the software engineer can decide between two options. In the first option an EPackage representing the namespace with an EAnnotation assigned to it, capturing the exact namespace information can be chosen. The second option foresees all modeling elements to be in the same package. To prevent naming conflicts in the latter case the namespace prefix will be appended to all modeling primitive names. If no prefix exists the software engineer will be approached to specify a prefix. Furthermore, he can also specify to which EPackage the helper classes should be assigned. 3.8 OWL 2 Modeling Primitives The second version of the Web Ontology Language, called OWL 2, adds several modeling primitives whose transformation to Ecore and OCL is explained in the following. Additional Property Characteristics: OWL 2 introduces additional property characteristics: reflexive, irreflexive, and asymmetric. These characteristics will be incorporated in reasoning services and a materialization of the inferred knowledge based on them is required for ABox transformation. The OCL constraints ensuring consistency for the corresponding EReferences in Ecore are shown in the following: OWL Assertion: ReflexiveObjectProperty(a:anyProperty) A. a l l I n s t a n c e s ()−> f o r A l l ( x | x . a n y P r o p e r t y −>i n c l u d e s ( x ) ) OWL Assertion: IrreflexiveObjectProperty(a:anyProperty) A. a l l I n s t a n c e s ()−> f o r A l l ( x | x . a n y P r o p e r t y −>e x c l u d e s ( x ) ) OWL Assertion: AsymmetricObjectProperty(a:anyProperty) A. a l l I n s t a n c e s ()−> f o r A l l ( x , y | x . a n y P r o p e r t y −>i n c l u d e s ( y ) i m p l i e s y . a n y P r o p e r t y −>e x c l u d e s ( x ) ) Disjoint Properties: If two properties are declared to be disjoint, an individual can refer to an other individual at most by one of the two properties. Assume the class Person to be domain and range of the disjoint object properties hasParent and hasSpouse. Then we add the following OCL constraints to the domain class: P e r s o n . a l l I n s t a n c e s ()−> f o r A l l ( x , y | x . h a s P a r e n t −> i n c l u d e s ( y ) and x . o c l I s K i n d O f ( P e r s o n ) i m p l i e s x . h a s S p o u s e−>e x c l u d e s ( y ) ) P e r s o n . a l l I n s t a n c e s ()−> f o r A l l ( x , y | x . h a s S p o u s e−> i n c l u d e s ( y ) and x . o c l I s K i n d O f ( P e r s o n ) i m p l i e s x . h a s P a r e n t −>e x c l u d e s ( y ) ) Property Chains: Property chains provide a means to define properties as a composition of other properties. Assume we have the classes {A1 , . . . , An } so that A1 references A2 with P1 , A2 references A3 with P2 and so forth as shown in Fig. 3.8. The composition of these properties defines the property P between the class A1 and An . To specify

An Adjustable Transformation from OWL to Ecore

253

this characteristic in the Ecore world the following two generic OCL constraints will be attached to the class A1 : A1 . a l l I n s t a n c e s ()−> f o r A l l ( a | a . P−> f o r A l l ( b | i f a . P−>s i z e () >0 and a . P−>a s S e t ()−> i n c l u d e s ( b ) then a . P1 . P2 . P3 . . . Pn−>i n c l u d e s ( b ) e l s e t r u e e n d i f ) ) A1 . a l l I n s t a n c e s ()−> f o r A l l ( a1 | a1 . P1−>a s S e t ()−> f o r A l l ( a2 | a2 . P2−>a s S e t ()−> f o r A l l ( a3 | a3 . P3−>a s S e t ( ) f o r A l l ( a ( n + 1 ) | a1 . P−>i n c l u d e s ( a ( n + 1 ) ) ) \ l d o t s ) ) )

. . . −>

P A1 P1

An A2

P2

A3

An−1

Pn−1

Fig. 2. Composition of properties into a property chain

Keys: A number of properties can be specified as a key of a class expression. Each individual of this class expression can then be uniquely identified by the values of the defined key properties. Assume the class Person with the property hasSSN (SSN = social security number) that is defined as a key property for all individuals of the class Person. Ecore plus OCL allow specifying that two instances having the same SSN are connected by the EReference sameAs. Furthermore, inferred knowledge by the reasoner through key specification needs to be materialized. P e r s o n −> a l l I n s t a n c e s ()−> f o r A l l ( x< >y | x . hasSSN−>a s S e t ()−> i n c l u d e s A l l ( y . hasSSN−>a s S e t ( ) ) and ( y . hasSSN−>a s S e t ()−> i n c l u d e s A l l ( x . hasSSN−>a s S e t ( ) ) i m p l i e s ( x . sameAs . i n c l u d e s ( y ) ) ) Negative Property Assertion: A negative property assertion states that a concrete individual is not allowed to be linked to a specific individual or data value. For instance, assume the OWL classes Man and Woman and an object property hasWife with the domain class Man and the range class Woman. We can state that the individual Bill is not married to Mary: OWL Assertion: NegativeObjectPropertyAssertion( a:hasWife a:Bill a:Mary ) Man . a l l I n s t a n c e s ()−> f o r A l l ( x | x . N a m e O f I n d i v i d u a l= ’ B i l l ’ i m p l i e s x . h asWif e−>a s S e t ()−> f o r A l l ( y | y . N a m e O f I n d i v i d u a l < > ’ Mary ’ ) )

254

T. Rahmani, D. Oberle, and M. Dahms

Self Restriction: A self restriction defines a class of all objects that are related to themselves via a given object property. For instance, one can define the class AutoRegulatingProcesses that consists of all individuals that are related to themselves by the object property regulate: OWL Assertion: SubClassOf(:AutoRegulatingProcess ObjectHasSelf(a:regulate)) A u t o R e g u l a t i n g P r o c e s s . a l l I n s t a n c e s ()−> f o r A l l ( x | x . r e g u l a t e −>a s S e t ()−> i n c l u d e s ( x ) )

4 Realization of an Adjustable Transformation

TBox + OCL

TBox

Customized TBox

Reflecting on the previous section, a first observation is that there is a multitude of possibilities for transforming a complete ontology. The possibilities trade off between the two extremes of (i) a result simple to understand and (ii) a result which preserves a maximum of the original ontology. Depending on the use case, the users should be enabled to adjust the transformation meeting their requirements. Therefore, the realization of our transformation features two “sliders” for adjusting the ABox and TBox transformation (cf. Fig. 3), based on the transformation analysis in section 3.

ABox + OCL

Customized ABox

ABox

Maximum Preservation

No ABox

Maximum Simplicity

Fig. 3. Sliders for adjusting the transformation

The first slider is concerned with the TBox and the second with the ABox transformation options. By default, both sliders are in the initial position, where only the TBox will be transformed. At the next marks of the sliders customized TBox and ABox transformations will be performed. At this slider positions, the handling of Equivalent Classes, Namespaces, and Helper Classes for the TBox and the handling of Identical Individuals and Namespaces together with Materialization options for individuals can be specified. In the last mark of the sliders all transformation options, including OCL constraints, which are introduced in section 3, can be managed. For example, one could specify that the property hierarchy is not important but the transitive property characteristic

An Adjustable Transformation from OWL to Ecore

255

should be considered which can also cause a materialization of inferred knowledge about individuals, if the ABox is marked by the second slider. A second observation is that the transformation of a complete ontology requires specific preparation steps which are depicted in Figure 4. The transformation can only start if the ontology is consistent (cf. consistency checking in section 2). Afterwards, the user can adjust the two sliders as mentioned above and specify further transformation options based on his selection. These options can lead to a slightly modified copy of the ontology in order to simplify the transformation. For example, anonymous class definitions can be named explicitly and representatives for equivalent classes and identical individuals can be replaced by assertions. All these modifications make up the ontology extension step. Further preparation steps are the inference of the class hierarchy and the classification of all instances (cf. subsumption check and instance classification in section 2). Subsequently, the actual transformation starts according to the specifications given in Section 3. The results of the transformation are stored in an OntoTBox.ecore file containing the TBox, and in an OntoABox.OntoTBox file containing the ABox.

Adjusting Transformation Options ‰Onto.owl (TBox+ABox)

Yes

‰OntoTBox.ecore ‰OntoABox.OntoTBox Ontology Extension

Start

Consistency Checking

Is ontology consistent ?

Transformation

End

Subsumption Checking

No Instance Classification

Fig. 4. Flow chart of necessary preparation steps required for the transformation

Our corresponding Eclipse plug-in implements the aforementioned functionality. It makes use of the OWL API1 for accessing and managing an OWL ontology. The OWL API allows to plug in different reasoners for performing the required reasoning tasks. In our case, we used the open-source reasoner Hermit.2

5 Related Work A work similar to ours is [9] which transforms ontologies into EMF in order to leverage the existing model transformations to code. However, the motivation is limited to (Semantic) Web Services whereas our claim is to cover a broader range of use cases. Their work relies on the OWL2Ecore transformation of the Eclipse Ontology Definition 1 2

http://owlapi.sourceforge.net/ http://hermit-reasoner.com/

256

T. Rahmani, D. Oberle, and M. Dahms

Metamodel (EODM).3 EODM has been discontinued since 2008 and its OWL2Ecore transformation is not adjustable and does not make use of OCL. A comparable effort has been developed by Guillaume Hillairet which applies ATL to transform from OWL to Ecore. 4 We could not find any documentation of this Eclipse plug-in, but a code analysis revealed that it neither allows preservation adjustments, nor considers the ABox, nor makes use of OCL. The plug-in is part of a larger framework for using MDE for publishing data on the Semantic Web [6]. There are a number of more general approaches that shed light on the direction of representing ontologies in software engineering and UML tools and languages. Examples are [11], [1], or [5]. However, none of them seems to go into much detail and, besides, they do not offer an adjustable transformation. Further, ABox transformations and the use of OCL for preserving more of the source ontology are not considered.

6 Discussion Code generation, generation of database or XML schemata are fundamental functionalities offered by every established software engineering environment. Software engineers should be enabled to leverage existing knowledge manifested in ontologies by using such environments. This paper focusses on the theoretical foundations of an adjustable transformation. Consequently, the paper does not report on practical use. In addition, the idea of having an adjustable transformation is to be use case agnostic. Another point worth discussing is the choice of the source and target language of the transformation. With respect to the source language, there are several candidate ontology languages. However, our focus is the W3C Semantic Web Recommendations, viz., RDF(S) and the OWL family of languages (OWL Lite, OWL DL, and OWL Full), because of their normative character. We concentrated on OWL DL since this is the most expressive language which is still decidable. Decidability is a prerequisite for practical reasoning. Although UML is a prominent candidate for a target language, our choice is Ecore since it is the core modeling language of the well established Eclipse software engineering environment. In addition, Ecore is an unambiguous subset of the MOF specification and UML modeling constructs. Hence, a transformation from OWL to UML plus OCL would be identical. Furthermore, a transformation to UML requires the consideration of UML class and object diagram metamodels on the M2 layer in order to represent OWL TBox and ABox on the M1 layer. Since Ecore can be put on M3, our transformation puts the TBox on M2 and the ABox on M1.

7 Conclusion In this paper we have shown that it is possible to transform an arbitrary OWL ontology into an Ecore/OCL model in a way which preserves a maximum of knowledge of the ontology. In general, a software engineer may not want to transform the entire ontology. 3 4

http://www.eclipse.org/modeling/mdt/eodm http://perso.univ-lr.fr/ghillair/projects.html

An Adjustable Transformation from OWL to Ecore

257

Therefore, we introduced a “control slide” metaphor where the software engineer can choose between the two extremes of (i) a result simple to understand or (ii) a result which captures as much as possible of the original ontology (maximum preservation). The approach is usable by software engineers in the Eclipse community who are not necessarily familiar with OWL ontologies. The ability to transform OWL to Ecore saves software engineers from having to manually remodel existing models expressed using OWL.

References 1. Baclawski, K., Kokar, M.M., Kogut, P.A., Hart, L., Smith, J.E., Holmes III, W.S., Letkowski, J., Aronson, M.L.: Extending UML to Support Ontology Engineering for the Semantic Web. In: Proceedings of the 4th Int. UML Conference 2001, pp. 342–360 (2001) 2. Berners-Lee, T., Hendler, J., Lassila, O.: The Semantic Web. Scientific American Magazine (May 2001) 3. Credle, R., Akibola, V., Karna, V., Panneerselvam, D., Pillai, R., Prasad, S.: Discovering the Business Value Patterns of Chemical and Petroleum Integrated Information Framework. Red Book SG24-7735-00. IBM (August 2009) 4. Dahms, M.: OWL2Ecore: A theoretical and practical investigation. Technical report, SAP Research, CEC Karlsruhe, http://www.marco-dahms.de/sap/research/ OWL2Ecore.pdf 5. Falkovych, K., Sabou, M., Stuckenschmidt, H.: UML for the Semantic Web: TransformationBased Approaches. In: Knowledge Transformation for the Semantic Web, pp. 92–106 (2003) 6. Hillairet, G., Bertrand, F., Lafaye, J.-Y.: MDE for Publishing Data on the Semantic Web. In: Proceedings of 1st Int. Workshop on Transforming and Weaving Ontologies in Model Driven Engineering, TWOMDE, pp. 32–46 (2008) 7. Horrocks, I.: OWL: A Description Logic Based Ontology Language. In: van Beek, P. (ed.) CP 2005. LNCS, vol. 3709, pp. 5–8. Springer, Heidelberg (2005) 8. Kl¨uwer, J.W., Skjæveland, M.G., Valen-Sendstad, M.: ISO 15926 templates and the Semantic Web. In: Position paper for W3C Workshop on Semantic Web in Energy Industries; Part I: Oil and Gas (2008) 9. Li, T.-H., Chen, C.-C.: From Ontology to Semantic Web Service via Model-Driven System Development. Technical report, Department of Computer Science, National Chengchi University, Taiwan (2006) 10. Motik, Patel-Schneider, Parsia: OWL 2 Web Ontology Language. Structural Specification and Functional-Style Syntax, W3C Recommendation (October 2009), http://www.w3. org/TR/owl2-syntax/ 11. Schreiber, G.: A UML Presentation Syntax for OWL Lite. Incomplete draft (2002) 12. Vaught, R.L.: Alfred Tarski’s Work in Model Theory. Journal of Symbolic Logic 51(4), 869– 882 (1986) 13. Verhelst, F., Myren, F., Rylandsholm, P., Svensson, I., Waaler, A., Skramstad, T., Ornæs, J.I., Tvedt, B.H., Høydal, J.: Digital Platform for the Next Generation IO: A Prerequisite for the High North. In: SPE Intelligent Energy Conference and Exhibition (2010) 14. Walter, T., Parreiras, F.S., Staab, S.: OntoDSL: An Ontology-Based Framework for DomainSpecific Languages. In: Sch¨urr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 408–422. Springer, Heidelberg (2009)

Transforming Process Models: Executable Rewrite Rules versus a Formalized Java Program Pieter Van Gorp and Rik Eshuis Eindhoven University of Technology School of Industrial Engineering

Abstract. In the business process management community, transformations for process models are usually programmed using imperative languages (such as Java). The underlying mapping rules tend to be documented using informal visual rules whereas they tend to be formalized using mathematical set constructs. In the Graph and Model Transformation communities, special purpose languages and tools (such as GrGen 1 ) are being developed to support the direct execution of such mapping rules. As part of our ongoing effort to bridge these two communities, we have implemented a transformation from petri-nets to statecharts (PN2SC ) using both approaches. By relying on technical comparison criteria and by making the solutions available for online replay, we illustrate that rule-based approaches require less specification effort due to their more declarative specification style and automatic performance optimizations. From a tool perspective, GrGen has better visualization and debugging support whereas Java tools support evolution better.

1

Introduction

This paper contributes to the emerging field of transformation engineering. We define transformation engineering as the discipline of (i) decomposing complex transformation problems into manageable parts, (ii) making reproducible decisions when designing a transformation solution, (iii) benchmarking and selecting transformation languages and tools, and (iv) verifying transformation results. Although transformations are already developed for decades in various communities (such as the compiler community, the program transformation communityand the business process management (BPM) community), it is relatively new to study the strengths and weaknesses from transformation approaches across community boundaries. In this paper, we illustrate how a transformation program from the BPM domain can be systematically compared with a behaviorally equivalent solution based on graph rewriting techniques. This provides novel insights in the strengths and weaknesses of the two approaches. The transformation program is written in Java whereas the graph rewriting solution is based on GrGen but the results can easily be extended for other solutions based on similar platforms. 1

We use the short GrGen name to denote GrGen.NET 2.6 [6].

D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 258–272, 2010. c Springer-Verlag Berlin Heidelberg 2010 

Transforming Process Models

259

As a conceptual framework, we rely on the “taxonomy of model transformation” [12,17]. In general, taxonomies are used for a wide variety of purposes [7]. This specific taxonomy has for example been used in education as well as in research (see [19] for examples). We improve the structure of the taxonomy by classifying transformation solutions on four taxonomy levels (the conceptual, the design, the language, and the tool level) and put quantitative results in a proper qualitative perspective. The organization in four levels is often inspiring, as one can for example observe that a particular limitation of a Java based transformation program is not a consequence of using that language but merely the consequence of a design decision. This paper does not present the complete taxonomy. [17] provides a wider and deeper coverage. Moreover, [19] provides more details on the case study. In the next section, we present related work from the field of transformation engineering. Section 3 introduces the case study that we solved using Java as well as using GrGen. Section 4 describes the solutions, Section 5 elaborately evaluates them and Section 6 presents our conclusions. All results from this paper can be reproduced in an online virtual machine [18].

2

Related Work

This paper contributes to the aforementioned field of transformation engineering. This field is emerging from a series of satellite events from graph and model transformation conferences. The “graph transformation tools contest” in 2007 used a transformation from UML activity diagrams to CSP as a case study to compare 11 graph transformation based approaches [21]. The 2008 edition of that contest did not involve a case study related to BPM. The 2009 edition of that contest used a transformation from BPMN to the BPEL as a case study to compare 10 transformation approaches [4]. Our participation in these events has lead to refinements of the taxonomy that supports in this paper. This two transformation approaches that are evaluated in this paper have been selected with care: for the 2007 edition of the contest, there was no Java based solution available for comparison. This was a severe drawback, since most contributions to BPM conferences are based on Java based implementations. Using GrGen to represent the wide range of graph transformation tools makes sense, since the GrGen platform is recognized as state-of-the-art in that area [20]. This paper clearly separates the underlying mapping rules from design, language and tool related features. We have explicitly defined a set of “core” mapping rules for which we compare the two implementations in detail. In contrast, solutions to the BPMN2BPEL case from the 2008 contest implement different sets of mapping rules, which makes it unfair to compare the solutions from a non-functional point of view. Focusing on non-functional properties is important since in transformation engineering all platforms under study tend to be equally expressive. Therefore, any set of conceptual mapping rules can eventually be implemented using any of the evaluated platforms, which means that their fundamental differences relate to non-functional properties only.

260

P. Van Gorp and R. Eshuis

van Amstel et al. have proposed a set of metrics to quantify the quality of model transformation programs [1]. In summary, that work should be extended with metric implementations for more transformation languages. This would enable the quantification of quality attributes such as size and complexity. For this paper, we only quantify transformation performance and size. As described in Section 5.5, we currently quantify transformation size using the very basic Lines Of Code (LOC) metric but we are collaborating with van Amstel on the development of more advanced measurement instruments.

3

Case Study: Translating Petri-nets to Statecharts

This section introduces the PN2SC case study that we have solved using Java and GrGen. We assume that the reader is at least aware of petri-nets [13] and statecharts [10] (the language of the input and output models of our case study). Others are invited to consider [19] first. We do not assume in-depth knowledge of advanced petri-net analysis methods or of high level petri-nets. Similarly, we only assume basic familiarity with statecharts. Having two executable Petri-Net to Statechart (PN2SC) implementations is not considered a BPM contribution in itself, and we also refer the reader to [5] for (i) a proof on the completeness of the reduction rules for a particular subclass of petri-nets and (ii) a discussion of the practical consequences thereof. Notice again though that our classification method can be applied to other mapping problems, languages and tools. 3.1

Example Input and Output Model

Fig. 1 is based on the running example from the original paper on the PN2SC mapping [5]. Black dots visualize tokens. These tokens represent data. Circles visualize places. Places can hold tokens. A particular distribution of tokens across a petri-net (often called a marking) represents a particular process state. Black bars visualize transitions. A transition represents a process activity. When such activities occur, the net moves to a new state, that is: tokens a redistributed across the net. More specifically, a transition t that fires moves tokens from the places which have an incoming arc to t (the input places) to places which have an outgoing arc from t (the output places). A transition can only fire if all of its input places hold a token. In such a case, the transition is said to be enabled. [5] restricts the class of input petri-nets for PN2SC to those which never reach a state with more than one token in a place. A key feature of the translation PN2SC is that it maps a petri-net to a statechart in a structure-preserving way, such that the statechart syntax resembles the petri-net syntax. The translation is behavior-preserving according to the petri-net token game (i.e., standard) semantics. It can be used as a foundation for implementing translations from event-driven petri-nets to event-driven statecharts. The translation enables the exchange of models between tools. For example, BPM designers can use petri-net tools to design and analyze business processes and use statechart-based tools to generate code from their design.

Transforming Process Models

261

Fig. 1. Example petri-net model that can be used as input for PN2SC

(a)

(b)

Fig. 2. Statechart representations of the running example

Fig. 2 ((a) and (b)) represents the running example in statechart syntax. More precisely, this diagram represents the above process model in the “state machine diagram” syntax from the Eclipse MDT-UML2Tools plugin. In the context of the PN2SC mapping, the relevant characteristic of the output formalism is that it has the notion of “concurrent regions” within “compound states”. In statechart terminology, states that hold concurrent regions are called “AND nodes” whereas the individual regions are called “OR nodes”. An OR node can in turn hold compound concurrent states (AND nodes) as well as “basic nodes” . The black dot that is connected to P0 represents an “initial state”. The topmost AND node (labeled $15832433 ) holds only one OR node, which contains the one initial state. Thus, the process clearly has a single entry point. Fig. 2 ((a) and (b)) also shows two black dots surrounded by a circle. These dots represent “final states”. The transitions from our input petri-net are mapped to hyperedges. Hyper-edges with exactly one input and output state are visualized as an atomic arc. Hyper-edges representing fork and join behavior are displayed as black bars (similar to transitions in petri-nets). Notice that these hyper-edges can either be shown explicitly (as in Fig. 2 (a)) or transformed into additional start and final states within the concurrent OR regions (as in Fig. 2 (b)). States in which decisions are made or where conditional branched paths merge again are represented as rhombi (see the elements after state P1 and state P3 ).

262

P. Van Gorp and R. Eshuis

(a) rule for creating AND nodes

(b) rule for merging OR nodes

Fig. 3. Visual documentation for mapping rules

3.2

Mapping Rules

This paper defines the “core” of the PN2SC mapping as the set of mapping rules that make that hierarchy explicit. Section 5.1 clearly separates that task from other subproblems (such as mapping to UML style.) Fig. 3 is extracted from [5]. Remark that Fig. 3 is intended to document the mapping rules. [5] also presents a mathematical formalization of the rule preconditions as well as a pseudo code description of the rule side-effects and the rule scheduling algorithm. Other applications of this specification style can be found for example in [13] (to document petri-net reduction rules) and [3] (to document a mapping from BPMN to petri-nets). The observation that several transformations in the BPM domain are documented in this manner is an important one, since (i) it indicates that the mathematical formalizations are not considered adequate documentation, and (ii) it provides a basis for judging the understandability of the implementations that are compared in this paper. The upper part of the rules, as shown on Fig. 3, visualizes how elements from the input net should incrementally be folded into a single place. Since each rule application reduces the amount of possible rule matches, the rule set is known to be terminating. The bottom part of the rules, as shown on Fig. 3, visualizes how the hierarchical structure is introduced in the output model. The rule shown on Fig. 3 (a) expresses that all statechart elements corresponding to an input place of an AND join transition should be grouped. The lower part shows how a new AND parent node is introduced in the statechart domain. The upper part shows restrictions on the applicability of the rule: notice how dashed crosses visualize what kind of transitions should not be present when applying this rule. When applying the rule, arcs between qi and tj are redirected to a newly created element p. This paper does not aim to make the full meaning of the rule clear; instead, it intends to give an idea of the nature of

Transforming Process Models

263

the rules (and the way in which they are documented) and refers to [5] for more details. Notice that the complete mapping also contains a rule for AND splits (parallel fork patterns [15]). That rule resembles the one shown on Fig. 3 (b) but has the arcs connected to t in the reverse direction. The rule shown on shown on Fig. 3 (b) shows that the algorithm does not accept arbitrary sequential structures: again, the dashed cross syntax is used to depict patterns that prevent the rule from matching. In summary, it seems desirable that these rules are implemented on a platform that supports the specification of positive as well as negative patterns.

4

Description of the Solutions

This section describes the two solutions that implement the rules from Section 3.2. The solutions are classified and compared in the next section. Fig. 4 shows a fragment from the Java solution while Fig. 5 shows the corresponding fragment from the GrGen solution. To clarify the rationale behind the Java solution, we first explain a previous version thereof. In the original Java version, each of the two reduction rules ((a) and (b) from Fig. 3) was implemented by a separate method. The reduction procedure was started by invoking the method for rule b.In the method for rule b, transitions were processed one by one. For each transition it was checked whether the precondition for rule b was satisfied and if so, rule b was applied, and the method was called again recursively. If rule b was not applicable to any transition, then the method for rule a was invoked. In this method, each transition was processed to check whether the precondition for rule a was satisfied. If so, rule a was applied and the method for rule b was invoked again. If rule a was not applicable to any transition, the reduction procedure failed. Clearly, in this initial design, the set of transitions was traversed many times and sometimes unnecessary. This observation led to the current version of the Java solution, which uses a search algorithm (see line 7 to 13 and lines 43 to 57) to select a transition to which the rules can be applied in order, that is, first rule a (see lines 14 to 39) is applied to the preset and postset, and next rule b. If one of the rules fails for the selected transition, the complete reduction procedure fails. In contrast, if in the original Java version all reduction rules failed on a certain part of the net, another part of the net was searched to which the reduction rules could be applied. The search algorithm has been formalized in pseudo code [5] too. The Java solution represents a large class of other Java based transformation approaches in that input elements are traversed explicitly: a while loop (cfr., lines 2 to 41) iteratively checks whether there are still transitions (from the petri-net) that need to be transformed. A perhaps unconventional feature of the Java solution is that it heavily relies on vector indexing (cfr., lines 5, 8 and 26.) Since the formal description of the mapping does not rely on indices [5], one can conclude that the Java solution contains redundant technical details. A Java solution based on collection iterators would not have that disadvantage.

264

P. Van Gorp and R. Eshuis

1 public String reduce () { 2 while ( trs . size () >0) { 3 // f i n d l o w e r b o u n d t r a n s i t i o n t 4 int i =1; 5 Transition t =( Transition ) trs . get (0) ; 6 // t is l o w e r b o u n d 7 while (i < trs . size () ) { 8 Transition t2 =( Transition ) trs . get (i ); 9 if ( check (t2 ,t )) { 10 t = t2 ; 11 } 12 i ++; 13 } 14 Vector sources =t . getSources () ; 15 if ( sources . size () >1){ 16 if ( checkTransitions ( sources ) ){ 17 Vector toreplace = new Vector ( sources ); 18 String tId = t . getId () ; 19 State newState = new State ( tId ) ; 20 newState . addChildren ( toreplace ) ; 21 newState . setAnd () ; 22 State newStParent = new State ( " xx_o") ; 23 newStParent . addChild ( newState ); 24 newStParent . setOr () ; 25 for ( i =0; i < trs . size () ;i ++) { 26 Transition tx =( Transition ) trs . get (i) ; 27 Vector sourcesx = tx . getSources () ; 28 if ( contain ( sourcesx , toreplace ) ){ 29 tx . clearSources ( toreplace , newStParent );

30 31 32 33

} Vector targetsx = tx . getTargets () ; if ( contain ( targetsx , toreplace )){ tx . clearTargets ( toreplace , newStParent ); }

34 35 } 36 states . add ( newStParent ); 37 states . removeAll ( toreplace ); 38 } 39 } 40 ... // c o d e f o r o t h e r r u l e s 41 } 42 } 43 public boolean check ( Transition t1 , Transition t2 ){ 44 Vector sources1 = t1 . getSources () ; 45 Vector targets2 = t2 . getTargets () ; 46 if ( targets2 . containsAll ( sources1 ) 47 && sources1 . size () < targets2 . size () ){ 48 return true ; 49 } 50 Vector sources2 = t2 . getSources () ; 51 Vector targets1 = t1 . getTargets () ; 52 if ( sources2 . containsAll ( targets1 ) 53 && sources2 . size () > targets1 . size () ){ 54 return true ; 55 } 56 return false ; 57 }

Fig. 4. Java code for handling AND joins (cfr., Fig. 3a and 5)

Another property of the Java solution is that it does not leverage Java classes to check the type-safety of the generated output elements. More specifically, the setAnd and setOr calls (cfr., lines 21 and 24) are used for dynamic changing the metaclass of the transformed elements. As a final observation, notice that the Java solution hard-codes one particular sequential order of execution for the mapping rules (cfr., line 40, which obviously represents several more lines of code.) This over-specification may seem harmless from a behavioral point of view but (i) new programmers may get the wrong impression that the rules are required to execute in that particular order and (ii) it makes rule oriented optimization (cfr., [11]) virtually impossible. Remark that this fundamental problem can only be overcome by embedding in Java a String-based graph transformation language interpreter. See section 5.3 for other language-specific characteristics and section 5.2 for characteristics that only relate to design choices of the transformation writer. The GrGen “code” fragment shown on Fig. 5 may come as a surprise to some readers, since it is rather uncommon to program graph transformation systems using textual syntax. On the other hand, the fragment contains applications of language constructs that one may know from graph transformation systems based on visual transformation languages: for example, the “negative” construct supports the specification of negative application conditions [9]. In a nutshell, the construct provides formal support for the realization of the dotted crosses shown on Fig. 3. The most commonly known characteristic of graph transformation rules is however that they consist of two dominant parts (a left-hand and a right-hand side.) The left-hand side of a rule describes the pattern that needs to be looked up in the input model (the host graph), the left-hand side describes the pattern that should be realized when applying the rule. For example, in the trans AND join rule, the left-hand side (between lines 2 and 4 of Fig. 5) specifies a pattern

Transforming Process Models

1 rule trans_AND_join { 2 -: pre -> t : Transition t; // f o l d 7 // u p d a t e t r e e 8 : HSCandState or : HSCorState ; // t a k e OR 17 p -: PN2HSC -> : HSCorState -: HSCcontains -> 18 parentAND : HSCandState ; 19 modify { 20 or <EnumAttribute name="Architecture" defaultValue="x86"> AVR MSP x86 PowerPC <StringAttribute name="MacAddress" defaultValue="00:00:00:00:00:00"/> <StringAttribute name="IPAddress" defaultValue="192.168.0.1"/> <StringAttribute name="NetMask" defaultValue="192.168.0.1"/> <StringAttribute name="Gateway" defaultValue="192.168.0.1"/> <EnumAttribute name="Speed" defaultValue="Mbps100"> Mbps10 Mbps100 Gbps1 <StringAttribute name="Port"/> <EnumAttribute name="BaudRate" defaultValue="B38400"> B9600 B19200 B38400 B115200 <EnumAttribute name="Parity" defaultValue="None"> None Even_Parity Odd_Parity <EnumAttribute" name="StopBit" defaultValue="S_1"> S_1 S_1_5 S_2 <EnumAttribute name="FlowControl" defaultValue="None"> None Hardware XON_XOFF

Fig. 4. Example Model of the First Phase Defining Processing and Communication Capabilities

An extract of the model used for the SOA project is shown in figure 4. The model defines in addition to the two capability types ProcessingUnit and Communication the concrete capabilities CPU, Ethernet and RS232. The focus of this model lies in the specification of the basic capabilities with their attributes supported by the run-time system. The great benefit of the three step approach can be seen here. The run-time system experts only need to consider and model the currently supported capabilities and their according attributes. New capabilities or additional attributes can be appended in the future as needed. Thereby the effort for the first modeling iteration can be reduced to an absolute minimum, without complicating any later system extensions. A subsequent enhancement of the metamodel does not lead to inconsistencies in older models of following phases, because adding new capabilities in contrast to deleting existing capabilities does not restrict the validity of old models [6]. In case that additional

Model-to-Metamodel Transformation for Component-Based Systems

397

attributes need to be added to already existing capabilities, default values can be used to ensure that the code generation for old models is still working and leads to the same result as before. A similar approach has been realized for software components in the SOA project, which are defined by their provided (output) and supported (input) ports. 3.2

Specification of the Available Components

Component suppliers are able to describe their available components and complement the code generation process regarding their specific component requirements. Therefore, an adequate metamodel is generated out of the model from the first phase so that the specified capability types and capabilities are integrated as independent types into the metamodel. This generated metamodel can then be used to instantiate models for the second phase using the capabilities defined in the previous phase. The generic base structure of the metamodel can be seen in figure 5. Figure 6 on the other hand shows the metamodel generated from the example model of the first phase (figure 4). In the generated metamodel the relationship between the input model of the first phase is easily noticeable objects are becoming classes. These classes are now available for the component producers to describe their components. The component producers are able to specify unchangeable values for attributes (e.g. Architecture of CPU ), restrict the allowed values of attributes further (e.g. limit the transmission Speed of Ethernet to values supported by the hardware component), define default values for attributes (e.g. Ethernet IPAddress) or leave the configuration open for the following phase. Figure 7 depicts an extract of the projects second phase model. The example model describes three hardware modules: a PC based on a dual-core processor, a controller using an ATmega 8 and an Ethernet card. Some of the capability properties are already fixed in this model (e.g. attributes of capability CPU of module PC ). Others are further restricted like Speed of Ethernet. Based on the information of this modeling step, component producers are able to specify the



  

  



    





 




  


  






  





Fig. 5. Generic Metamodel of the Second Phase Based on Modules (Base and Extension Modules) and Capabilities with their Attributes

398

G. Kainz et al.

Fig. 6. Concrete Metamodel of the Second Phase Resulting from the Example Model of the Previous Phase (Figure 4) <ExtensionModule name="EthernetCard"> <Ethernet> <Ethernet_MacAddress value="00:00:00:00:00:00" changeable="true"/> <Ethernet_IPAddress value="192.168.0.1" changeable="true"/> <Ethernet_NetMask value="192.168.0.1 changeable="true""/> <Ethernet_Gateway value="192.168.0.1" changeable="true"/> <Ethernet_MTU value="1024" changeable="true"/> <Ethernet_Speed" Value="Mbps100" supportedValues="Mbps10, Mbps100" changeable="true"/>

Fig. 7. Example Model of the Second Phase Defining and Preconfiguring a PC, a Controller and an Ethernet Card

Model-to-Metamodel Transformation for Component-Based Systems

399

component specific code generation comprising for example the required device drivers for an actuator or sensor component. The metamodel created in the second phase is going to be changed more often than the one of the first phase, due to the high variety of different components. These changes do not concern already existing components and therefore do not affect established models based on former metamodels, which are remaining compatible with the new metamodel as long as no components are removed or changed. Another advantage of this approach is the possibility to encapsulate the knowledge used for the component code generation. Thereby the intellectual property of the component producers is protected against others2 . The presented approach has also been implemented for the available software components, where service instances can be created and configured. 3.3

Creation of the Application through Selection of Components

During the third phase the application developer selects and connects the components used for realizing the application like in a modular construction system. All the components defined by component producers in the second phase can be used as building blocks. They are defined in the metamodel, which is the output of a M2MM transformation based on the previous model. After selecting the appropriate components, they must be configured by the application developers according to the application requirements. The definition of attribute values and the restriction of allowed values for attributes in the second phase lead to a much simpler final configuration step and help to prevent erroneous configurations. The generic structure of the metamodel and a metamodel based on the example model of the second phase (figure 7) are presented in figure 8 and 9.

Fig. 8. Generic Metamodel of the Third Phase Based on Nodes and Extension Modules with their Associated Capabilities

As shown in figure 9, the metamodel of the third phase introduces a big increase in the number of different capabilities, which only represent specializations of the capabilities already available in phase two, e.g. PC RS232 and Controller RS232. This is necessary to reflect the value ranges of particular component attributes of the different components produced by different manufacturers and helps to ease the correct configuration of components with respect to 2

The support of the encapsulation is currently not implemented.

400

G. Kainz et al.

Fig. 9. Concrete Metamodel of the Third Phase Resulting from the Example Model of the Previous Phase (Figure 7)

Fig. 10. Example Model of the Third Phase where the Application is Assembled and Configured According to the Requirements

their offered functionality. To prevent the handling of all these auxiliary capabilities in the following code generation step it is useful to convert them back to their corresponding base types through a model-to-model (M2M) transformation before starting code generation. Thus the number of types is significantly decreased and the complexity of the code generation is reduced. An example model with the final attribute values for the third phase taken from SOA is shown in figure 10. Some of the attributes shown have already fixed values, which cannot be changed anymore. The modeled application consists of one PC module using RS232 extended with an Ethernet card and one controller using RS232. In the following, M2M transformations and code generation are performed based on the given input from the third phase. However the mechanisms of the code generation are founded on the model of the first and second phase, which have been defined by the run-time system experts respectively the component producers. The third phase is only utilized to configure the application according to the needs. 3.4

Implementation Details

The implementation of the approach is based on the Eclipse Modeling Framework (EMF) [7]. EMF constitutes an equivalent implementation of the Essential Meta Object Facility (EMOF) [8] of the Object Management Group (OMG)3 . MOF 3

http://www.omg.org/

Model-to-Metamodel Transformation for Component-Based Systems

401

constitutes a standardized meta-metamodel according to the model hierarchy presented in figure 2 and specifies rich functionality for introspection. Hence it offers the possibility for generic handling of models and metamodels. The M2MM transformations are achieved through manual implementation based on the static structure of the input models: the data of the input models is read and transformed according to the tooling requirements. While the generation of the metamodel for the second phase has been straight forward, the generation of the third metamodel has been comparably complex. This is due to the fact that besides the information provided in the second model, also information from the first model has to be taken into account for the generation of the metamodel for the third phase. The model of the first phase is required, because a great part of the second phase metamodel depends on the model of the first phase. So for automatic handling of the second phase model, either the model of the first phase has to be available or the information has to be extracted from the metamodel of the second phase. In the current implementation the information of the first model is directly extracted from the metamodel of the second phase using the reflective API of EMF. This procedure prevents that incompatible models / metamodels of the previous phases are used as input for the M2MM transformation, but also requires that all the required information of the first phase model is encoded into the metamodel of the second phase even if the information is not used for modeling in phase two. Due to the big differences between the different M2MM transformations no significant commonalities could be identified and extracted. As a consequence, the development team needs to implement almost all transformations by themselves to meet the current tooling requirements. The current implementation only comprehends the generation of the metamodels through the M2MM transformations. The next step will be to include the model analysis and code generation of the SOA project. Nevertheless a much better structure of the models could already be achieved through the separation into three different phases (capabilities supported by the run-time system, available components and application assembling). Furthermore, the extension of the models is much simpler and even possible for developers without in-depth knowledge of our development tool. Now the tool enhancement is integrated in the tool itself and requires no manual adaption of the base code, resulting in less effort when extending the tool’s functionality. 3.5

Code Generation

The presented approach involves supplementary changes in the area of code generation. Coarsely the code generation can be divided into two parts as shown in figure 11. The first part comprises the generation and adaption of the components to the specified application requirements. This task has to be achieved by component producers. The second part targets the generation of the underlying run-time system, which serves as container for the components. Hence this fragment of the code generation is implemented by run-time system experts. Interoperability of the different parts is assured through the compliance

402

G. Kainz et al.

Fig. 11. Simplified Picture of Resulting Code Generation only Showing the Processing Steps for Hardware Components without any Model-to-Model Transformations

to predefined interface specifications. The responsibility for the code generation is thereby split between different groups of developers. This helps to increase the utilization of the existing expertise, as each expert must only concentrate on its own area of expertise. The system interoperability is then assured with the help of the development tool. In the current implementation the code generation process as described above is hand written and does not automatically adapt to the inputs of the multiphase modeling. The automated adjustment of the code generation according to the models has to be done in the future.

4

Related Work

Our multi-phase approach is based on the ideas of MDA [9] from OMG and the concept of model hierarchies [3]. The proposed approach extends MDA by introducing a new kind of model transformation. In addition to the well-known M2M transformation, where platform independent models (PIMs) are transformed towards platform specific models (PSMs), also M2MM transformations are supported. While M2M transformations operate on the same level of the model hierarchy, M2MM transformations operate across different levels of the model hierarchy. The approach introduces the possibility to extend the underlying metamodels in a flexible way. The changes to the metamodels are achieved by modifying models of a previous phase, which are the source for the M2MM transformations responsible for the creation of the metamodels. So our approach is an extension of the techniques described in MDA.

Model-to-Metamodel Transformation for Component-Based Systems

403

State of the art for model-driven development tools targeting component-based systems is the usage of generic libraries, as in tools like Ptolemy II [10], MATLAB/Simulink4 and so on. The structures of those libraries are fixed and are not intended to change, meaning that the way to describe components is static and cannot be changed / extended. When a concrete component is instantiated in such systems, the structure of the component is extracted from the generic description. The components included in a model are afterwards stored in a generic way. The whole system relies upon a correct interpretation of the generic component description. In contrast, our approach supports frequent changes of the metamodel structure. For each new component type the metamodel used by the application developer is automatically adapted to perfectly reflect the component description. The result is a strong typed system with all its benefits. A drawback of this strong typing is that it is harder to use generic editors. Bragan¸ca and Machado [11] describe a similar approach supporting multiphase modeling. In their work they use the term model promotion instead of M2MM transformation. Compared to our approach where flexibility is provided in each transformation step, they can only specialize their initial metamodel by annotating models with information utilized for automatic M2MM transformation. This restricts the power of their M2MM transformations to the predefined set of transformations offered through annotations. It also limits the usable domain concepts to the concepts introduced in their first metamodel and requires the specification of metamodel information in the model. Therefore as many M2MM transformations as needed can be conducted. Atkinson and K¨ uhne [12] describe problems related to shallow instantiation used in model hierarchies and suggest using deep instantiation instead. With deep instantiation, metamodels can influence the structure of all models in lower levels and not only the models exactly one level below. To use the full power of deep instantiation, related concepts need to be continuous over different levels. It is also possible to introduce new concepts on an arbitrary model level, but this requires the specification of these concepts in the base metamodel. Thus the structure of all the following levels is described in one base metamodel. Compared to our approach, where new concepts can be introduced based on the input of the previous model, their approach is restricted to object instantiation only. The presented approach also relates to type theory / hierarchies [13] as it establishes its own kind of type hierarchy. The advantages of the proposed approach in contrast of using ordinary type hierarchies of object oriented systems become obvious with respect to refinement of relations. In object oriented systems, a refinement of relations can only be done in addition to the inheritance of the original relation. The suggested approach provides transformation-based rules to support the refinement in a natural way: the generic relation of components is removed and replaced by component-specific relations. In addition, the interface to access generic relations can be automatically generated. Therefore, the approach helps to cope with the potential danger of inconsistencies when modifying objects using both, the generic and the specific, interface. 4

http://www.mathworks.com

404

G. Kainz et al.

Another interesting approach to extend metamodels in a flexible way is presented by Morin et al. [14]. They use aspect-oriented modeling (AOM) techniques to weave variability into metamodels. A similar technique could be used to extend our metamodels, but inevitably results in a separate aspect model for each new component instead of having a central point where all the components are defined. Furthermore, the extension of the system always requires a manual aspect model creation. As the user is able to influence the whole existing metamodel with his aspect model this can lead to unnecessary failures. In addition, it is unclear how to adapt this approach to support multi-phase modeling.

5

Conclusion

Domain-specific model-driven tools and component-based approaches are used to simplify the development process of embedded systems. Tools encapsulate system commonalities as domain concepts in the modeling language and in the code generation. Components are used to encapsulate frequently used functionality. Up to now, these concepts are mainly used for the development of applications, but not for the metamodels used by the development tool itself. Due to the heterogeneity of embedded systems, this focus is problematic, since the metamodels must be frequently changed if new types of components are introduced. In this paper, a new approach for a multi-phase model-driven development of component-based systems has been presented based on model-to-metamodel (M2MM) transformations. Additionally to the support of the application developers, this approach also focuses on the support of the run-time system experts and component producers. In individual phases, these experts can focus on their view on the system and extend the system easily. In context of SOA, it has been shown that our approach presented in this paper is well suited for the new use case and offers a significant improvement for the development of componentbased systems. Resulting advantages are a better structure of the metamodels and a separation of the code generator development into two separate phases (run-time system and components). Our approach has been demonstrated for modeling in the context of a development tool for distributed sensor / actuator systems. The current results indicate a much better extensibility of the whole system and a faster and easier development process. In the future the code generation of the tool has to be adapted to this approach and finally evaluated with respect to already existing systems.

References 1. Szyperski, C.: Component Software. Addison-Wesley Professional, Reading (November 2002) 2. OMG: Common Object Request Broker Architecture (CORBA/IIOP) Specification Version 3.1. (January 2008) 3. Stahl, T., Voelter, M.: Model-Driven Software Development: Technology, Engineering, Management, 1st edn. Wiley, Chichester (2006)

Model-to-Metamodel Transformation for Component-Based Systems

405

4. Buckl, C., Sommer, S., Scholz, A., Knoll, A., Kemper, A.: Generating a tailored middleware for wireless sensor network applications. In: Proceedings of the IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing, pp. 162–169. IEEE, Los Alamitos (June 2008) 5. Buckl, C., Sommer, S., Scholz, A., Knoll, A., Kemper, A., Heuer, J., Schmitt, A.: Services to the field: An approach for resource constrained sensor/actor networks. In: 2009 International Conference on Advanced Information Networking and Applications Workshops, pp. 476–481. IEEE, Los Alamitos (2009) 6. 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) 7. Steinberg, D., Budinsky, F., Paternostro, M., Merks, E.: EMF: Eclipse Modeling Framework, 2nd edn. Addison-Wesley Professional, Reading (2008) 8. OMG: Meta Object Facility (MOF) Core Specification Version 2.0. (January 2006) 9. Miller, J., Mukerji, J.: MDA Guide Version 1.0.1. (June 2003) 10. Brooks, C., Lee, E.A., Liu, X., Neuendorffer, S., Zhao, Y., Zheng, H.: Heterogeneous concurrent modeling and design in Java, vol. 1, Introduction to Ptolemy II. Technical Report UCB/EECS-2008-28, EECS Department, University of California, Berkeley (April 2008) 11. Bragan¸ca, A., Machado, R.J.: Transformation patterns for multi-staged model driven software development. In: SPLC 2008: Proceedings of the 2008 12th International Software Product Line Conference, Washington, DC, USA, pp. 329–338. IEEE Computer Society, Los Alamitos (2008) 12. Atkinson, C., K¨ uhne, T.: The essence of multilevel metamodeling. In: Gogolla, M., Kobryn, C. (eds.) UML 2001. LNCS, vol. 2185, pp. 19–33. Springer, Heidelberg (2001) 13. Winskel, G.: The Formal Semantics of Programming Languages. MIT Press, Cambridge (1993) 14. Morin, B., Perrouin, G., Lahire, P., Barais, O., Vanwormhoudt, G., J´ez´equel, J.M.: Weaving variability into domain metamodels. In: Sch¨ urr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 690–705. Springer, Heidelberg (2009)

Architectural Descriptions as Boundary Objects in System and Design Work Lars Pareto1, Peter Eriksson2, and Staffan Ehnebom2 1

Chalmers, University of Gothenburg, Gothenburg, Sweden [email protected] 2 Ericsson AB, Gothenburg, Sweden {peter.r.eriksson,staffan.ehnebom}@ericsson.com

Abstract. Lean and Agile processes have resolved longstanding problems in engineering communication by replacing document based communication with face-to-face collaboration, but do not yet scale to very large and heterogeneous projects. This paper proposes a compatible extension to lean and agile processes that addresses this limitation. The core idea is to adopt the view of documentation as boundary objects: shared artefacts that maintain integrity across a project’s intersecting social worlds. The paper presents a case study, in which interviews with system engineers and designers were analysed to obtain requirements on an architectural description serving as boundary objects in a telecommunications project. The main result is a list of 18 empirically grounded, elementary requirements, worth considering when implementing lean and agile processes in the large. Keywords: MBSE, engineering communication, architecture, boundary object.

1 Introduction Large product developing organizations often encompass system engineering units responsible for system specification and design units responsible for realizing system component using available technologies and platforms. This division of work is motivated for systems beyond a certain size, but easily leads to process problems: handover problems arise when system engineers throw specifications “over the wall”; lead times increase when system specifications are over-engineered; product quality drops when designers fail to realize new ideas, because of “heavy tolls” for crossing organizational boundaries. Recent movements in software engineering address these problems by promoting collaboration over documentation. For instance agile software development advocates face-to-face communication and negotiation over rigid documentation [1, 2]. Lean software development classifies over-processing, unnecessary handovers, and waiting as waste and seek to eliminate this waste by empowering designers to take their own decisions [3-5]. Streamline development proposes cross- functional and crossdisciplinary teams, with end-to-end responsibility for new product features [6]. However, there are clear signs that contemporary lean and agile processes may be taking this view on documentation too far. Case studies within Ericsson report on too D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 406–419, 2010. © Springer-Verlag Berlin Heidelberg 2010

Architectural Descriptions as Boundary Objects in System and Design Work

407

little focus on architecture leading to bad design decisions, on coordination of many small projects not scaling well to large projects, and on troubles with handovers between requirements and design work [7]. Internal feasibility studies, by the authors, in the context of base station development, point in the same direction: for multi-site development of large, heterogeneous systems (such as base stations), out-of-the box implementation of available lean and agile processes would lead to managerial nightmares regarding architecture- and coordination work. This paper proposes a different (but compatible) approach to improved engineering communication in product development. Rather than to diminish the role of documentation, we recognize the role of documentation as boundary object [8], i.e., as an artefact created and managed to develop and maintain coherence across intersecting social worlds. The boundary object construct is recurrent in research on computer supported cooperative work, and has been used to examine and improve engineering communication in the contexts of electric power equipment design [9], public transit system design [9], aircraft technical support [10], manufacturing and distribution [11], building construction [12], and user interface design [13]. The purpose of this paper is to examine the role of system architectural descriptions (SADs) as boundary objects within large-scale, heterogeneous product development. Our view of architectural description is given in Fig. 1, and follows IEEE1471 [14]: a SAD consists of an aggregated set of models (e.g. requirementssystem-, and design models), providing stakeholders (e.g., system engineers, designers, testers) with architectural views (e.g., system decomposition-, and deployment views). By large-scale, we mean involvement of 1000 people of more. By heterogeneous product development, we mean that activities span several engineering disciplines (e.g., H/W design, real time systems design, signals and systems engineering, radio signalling, antenna design, power supply design, user interface design). Our strategy is case study research [15]. Through interpretation of interviews with users of an existing SAD, informed by years of on-site fieldwork, we build

Fig. 1. System Architectural Descriptions as defined by IEEE1471. (Simplified).

408

L. Pareto, P. Eriksson, and S. Ehnebom

understanding of de facto social groups, their goals and tasks, their information needs, support for these needs, limitations in the support, and how limitations may be resolved. Through selection, analytical generalization, and analogical reasoning, we obtain a characterization of SADs serving as boundary objects within large-scale heterogeneous product development. Our case is a unit within Ericsson with a SAD that connects several dozens of social groups and hundreds of stakeholders at three sites. Roughly, each group is responsible for producing either requirements, system models, design & implementation models, tested software components, interface specifications, product documentation or other deliverables for either a specific subsystem or for the system as a whole. All groups use the SAD, but different parts of it for different purposes. The unit is presently not using lean and agile development, but is highly aware of the approach— in particular streamline development [6], successfully implemented by other Ericsson units for similar albeit smaller and less heterogeneous projects. Because of the size and heterogeneity of the unit’s projects, grounded doubts have been raised whether existing lean and agile processes scale to the unit’s projects without more explicit support for architecture work, which is the motivation of this research. The research question addressed in this paper is what elementary requirements a SAD should satisfy, to serve as boundary objects in systems and design work. By elementary requirement, we mean a requirement of foremost importance to satisfy, with influence on choices of modeling technology or ways of working, and whose existence does not depend on particular choices of design philosophy, technology, or process. The focus on system and design work is motivated by a previous case study [16] in which effective engineering communication between system engineers and designers stood out as particularly challenging: system engineers and designers work with the same components at different levels of granularity and abstraction from different viewpoints; they depended on each other’s knowledge with intricate temporal relationships; they must avoid inconsistencies, double work, and work falling between chairs. By providing a view on architectural documentation as a boundary object and by phrasing the needs of system engineers and designers as general, yet concrete, requirements on architectural documentation, we hope to support organizations that implement lean and agile processes in the large or that just want to improve the communication between system engineering- and design units. The paper is organized as follows: Section 2 describes our case and our research methods; Section 3 presents the requirements found; Section 4 discusses their scope and nature; Section 5 discusses related work; Section 6 presents our conclusions.

2 Research Methods 2.1 Our Case – A Unit Developing Base Stations The unit considered develops base stations for several international markets, using model based engineering and model driven development. The unit’s SAD aggregates 9 models: a requirements model consisting of use cases; a system model specifying major system components and their characteristics; 7 design models that further refine

Architectural Descriptions as Boundary Objects in System and Design Work

409

the components, and which are used for code generation. In addition, the SAD integrates free-form diagrams and tables. Design models are owned by distinct sub-units responsible for system sub-domains (e.g., radio communication and equipment control). Each design model is further divided into sub-models. Altogether, design models embed some 50 separately managed models each owned by a team. 2.2 Data Collection The paper is based on 18 interviews with users of the unit’s SAD conducted during 2007-2010. Key informants include a system engineer and member of the architecture team responsible for the unit’s system model and the processes surrounding it, a senior designer, working with component realization at the subsystem level, with attention to platform matters and subsystem architecture, and a senior designer working with product documentation and interface coordination, in the borderland of systemand design work. Other informants include testers, managers, designers, and architects in various specialised roles. Interviews were open ended and concerned with experiences and potential improvements of the unit’s SAD. 2.3 Data Analysis Interviews with the key informants were interpreted in search for requirements related to communication and division of work, with attention to usability, understandability, maintainability, and workflows. Each requirement was (1) given a succinct, technology independent definition, with the goal to make the requirement understandable for typical engineers and managers within the unit, (2) categorized using a previously developed taxonomy of requirement areas in MDD [17], and (3) presented in the form of a requirements specification report. Each requirement was presented along with quotations that supported it, a rationale, an assessment of its fulfilment, and suggestions for improvement. In all, the data analysis resulted in 78 requirements. For the purpose of preparing this paper, requirements were further abstracted. Situation specific phenomena were reinterpreted to use the terminology of IEEE1471. Conceptually overlapping requirements were merged. Situation specific requirements that did not lend themselves to generalization were omitted, as were instances of more general requirements and requirements not qualifying as elementary. 2.4 Validation Requirements were validated using member checking in two stages. The requirements specification was reviewed in a two session workshop (1h + ½ day) involving two key informants and the authors of this paper. Each workshop participant studied the requirements specification in advance; workshop time was spent discussing validity of the requirements identified, their communicability, their completeness, and their relative importance. In the workshop, five requirements were discarded as nonrequirements; eight were revised to improve precision or readability. The further abstracted requirements, i.e., the ones presented in this paper, were reviewed by the second and third author of this paper, which had not been involved in the data analysis per se. These authors work full time at the unit (in the roles of senior technical specialist and senior software architect) and were thus were in good position

410

L. Pareto, P. Eriksson, and S. Ehnebom

to detect misinterpretations. Review outcomes were that all requirements were valid and captured the unit’s most important needs related to design documentation.

3 Requirements on SADs Serving as Boundary Objects The data collection, analysis, and validation steps outlined in Section 2 resulted in the 18 requirements on SADs given in Table 1. Requirements range over the main objectives of SADs, their design principles, special features they should have, and their evolution. The requirements are further presented in the following sections. Table 1. Requirements on System Architectural Descriptions

R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 R16 R17 R18

Main Objectives of System Architectural Descriptions The SAD should provide a single common view of the system built. The SAD should support contextual understanding. The SAD should communicate and enforce architectural rules. The SAD should support coordination of interfaces. The SAD should feed into design automation chains. System Architectural Description Design Principles The SAD should distinguish prescriptive and descriptive information. The SAD should support tabular as well as graphical modeling. The SAD should support free form annotation and diagramming. The SAD should recognize generated reports as first class views. The SAD’s rationale should document the role and relationship of each view. Special Features of System Architectural Descriptions The SAD should support hyperlinks, drill down, and tagging. The SAD should support book-keeping of design pattern usage. The SAD should support multiple abstraction. The SAD should support integration point interlocking. The SAD should provide on-the-fly abstraction (a.k.a. model filtering). System Architectural Description Evolution A modeling architecture team should be responsible for evolving the SAD. A tooling team should be responsible for evolving the modeling environments. Processes used for resource allocation and quality management should involve activities for SAD evolution.

3.1 Single Common View of the System Built The perhaps most important role of a SAD is to provide a single common view of the system. A large heterogeneous system may have more that 100 architectural concerns, and 20 or more architectural views [16]; a 1000 person project may involve hundreds of social worlds. If people do not think of the system in the same way, significant communication barriers develop. A manager in the unit stated that “these fundamental pictures are so important, because if you do not settle on a common, core skeleton

Architectural Descriptions as Boundary Objects in System and Design Work

411

view, then everyone will have different views: the product will look like a human to some, and a dinosaur to others, with obvious consequences to the result”. Although a common view may seem an obvious thing to have, it is evident from our interview data, that this may be difficult to obtain in practice. Further, processes de-emphasizing documentation, give little concrete guidance on how a common view should be maintained and communicated. 3.2 Contextual Understanding A related role for SADs is to support contextual understanding: to provide designers, testers, and project leaders with a quick entry into the system that introduces and highlights key concepts, structures, and other information necessary for understanding a component, its immediate surroundings, and the system as a whole. Designers in the unit report on insufficient such support, e.g., “The system engineers produce things to allow themselves to keep on systemizing, and sometimes to provide designer with some information...but too little is done to support someone trying to get into the system to understand it, such as a person new on the job”. Support for contextual understanding may seem an obvious requirement, but turns out to be a controversial within the unit. Proponents argue that great savings can be made if newcomers are helped into the system more quickly. Opponents argue that supporting contextual understanding is a luxury activity that, under economical pressure, falls back to providing designers and others with the bare essentials of information they need to “do their job”. Nevertheless “support for understanding” is a recurrent requirement in our interview data that many see as important. Regardless of whether such support is cost effective in the context studied or not, we regard R2 essential when SADs serve as boundary objects in lean and agile settings. 3.3 Communication and Enforcement of Architectural Rules A central activity in systems architecture work is to make sure that architectural principles are understood and followed. This is done by the use of architectural rules, in various forms, e.g., design rule documents, check scripts, platform interfaces, frameworks, and transformations, all of which find a natural home in a SAD. We view the communication and enforcement of architectural rules as one of the main objectives of architectural modeling, and also a necessity in supporting a system’s long term evolution. 3.4 Coordination of Interfaces A base station must conform to literally hundreds of protocols: protocols defined by telecommunication standards; protocols defined by realization platforms; internal protocols between system components. Many of these protocols evolve at a steady pace as new revisions of standards and platforms emerge, as better internal architectures are found, and as newer product generations are developed. Communicating the details and variations of all these protocols, ensuring that all engineers in a project works towards the same set of protocols, and detecting protocol conflicts are activities that require tool support. One informant declares that “one of

412

L. Pareto, P. Eriksson, and S. Ehnebom

the ideas behind the current system model is that the system specification model and the design models should be held together by reuse of the very same interface specifications used for code generation”. 3.5 Design Automation Chains The unit makes extensive use of design automation. MDD is used for code generation. Various syntactic checks and scripts are used to maintain consistency between the requirement model, the system model, and the design models. When design automation is used, the SAD becomes a natural hub for model transformation chains. For example, feature models as used in software product lines, formal protocol definitions as used in MDD, and platform independent models as used in MDA may advantageously be integrated within the SAD. To be able to use architectural elements as input to transformation chains is indeed one of the main arguments in favour of using formal models (and not just informal diagrams). 3.6 Prescriptive and Descriptive Information Distinguishable SADs play a dual role in that some parts are abstractions of existing system components (descriptive parts) whereas other parts are specifications of components to be (prescriptive parts). For instance, the system model of the unit contains descriptive models of all software interfaces present in the underlying hardware platform, and also prescriptive models for the protocols connecting major system components. For some parts, descriptiveness/prescriptiveness is a function of time. An interface definition for a component may be prescriptive initially, descriptive later, and eventually prescriptive again. To know whether a part of a model is descriptive or prescriptive at a given point in time may be a delicate matter—in particular if agile processes are used. We regard book-keeping and presentation of a model element’s role as descriptive or prescriptive, as a necessity in avoiding integration problems. 3.7 Support for Tabular as Well as Graphical Modeling Analysis of the unit’s SAD revealed a considerable use of not only UML models, but also tables that modelled configurations, data parameters, processor loads, performance requirements, response times, configurations, and logging. Although tables were essential input to many designers, and their processing potentially automatable, they did not belong to the SAD’s formal part but were placed in auxiliary spreadsheets and documents in its informal part. We regard formal tabular modeling (realised by XML schema or other techniques) as a desirable and important complement to graphical modeling in SADs that opens up for higher degrees of automation. 3.8 Free Form Annotation and Diagramming Available modeling artefacts do not always support user needs, causing users to circumvent their limitations. For instance, in the unit (1) engineers developed conventions for specifying logical control in sequence diagrams using comments, (2) architectural views not expressible in UML were placed in the SAD’s informal part as ordinary text documents.

Architectural Descriptions as Boundary Objects in System and Design Work

413

We regard support for free form annotation and diagramming —not to be confused with informal modeling—to be a requirement on a system model. By supporting (a disciplined use of) free form modeling, engineers are empowered to evolve the modeling practice as needs as arise, while architects responsible for a SAD are provided with concrete feedback on its fitness-for-purpose, and concrete suggestions on how it could be improved. 3.9 Reports as First-Class Format for Views SAD Stakeholders include engineers and managers in many roles (in our case architects, requirement engineers, system engineers, designers, testers, product documentation engineers, line managers, project leaders, product responsible, change managers, quality managers, and other roles). For reasons related to learning and tooling costs, it is not realistic to expect all these stakeholders to work with modeling tools. For some stakeholders, reports generated from the SAD, in the form of text documents, navigable sets of snapshots, or dynamic web pages, are more adequate. It is essential to give such reports a central position in the SAD: reports must be easily recognizable as parts of the SAD; they must not be taken for auxiliary documents. Without such a position, architects are likely to code needed views as models, and thereby accidentally introduce usability problems 3.10 Documentation of Role and Relations of Modeling Artefacts A SAD may provide hundreds of viewpoints of the system, e.g., our unit’s system model defines 26 kinds of views, and each design model defines many more. To communicate the role of each such view, its relationships to other artefacts, its relationships to the system built, its relationship to the enclosing process, and the details on its accurate use, is a major communication challenge. The unit’s system model has metamodel documentation that explains the role of all system model views. This documentation is, however, too brief to serve the needs of the designers, and its existence is not widely known. One designer states that “one may describe things in many different ways, but we do not, I feel, have sufficient support for how things are supposed to be described [...] we would need firmer guidance.” Just as grammars and descriptions of static semantics are needed to use a programming language well, concise metamodel documentation is needed to use a SAD well. 3.11 Support for Hyperlinks, Drill Down, and Tagging Hyperlinks, drill down, and tagging are standard concepts in user interface design. Hyperlinks are references that readers can directly follow (and typically add freely in text). Drill down stands for the ability to move from summary information to detailed data by focusing in on selected objects. Tagging is a technique by which users themselves can categorize content, and share categories with other users, without dependence on pre-made categories. Our interviews are full of references to the need for such features. An architect observed that hyperlinks, which was a standard feature in modeling tools of the 1980s, had disappeared in contemporary tools, and that this restrained him. A system engineer reported on being locked out from the design model, which undermined his understanding of the non-functional requirements he

414

L. Pareto, P. Eriksson, and S. Ehnebom

was supposed to specify. A designer concluded that “[With wiki style tags] one would be able to freely add relations to state that this is searchable, that this refers to that [...] to add tags to things in one way or the other”. By incorporating these well known features into a SAD, we help system engineers, designers, and others, with accessing and navigating each other’s worlds. 3.12 Bookkeeping of Design Pattern Usage Uphold of architectural principles becomes increasingly difficult as a system comes to age: original architects may no longer be around; new principles may have been introduced; abandoned principles may live on in the system’s legacy parts; designers unaware of old principles may inadvertently violate such; motivations for past deviations from design principles may have been forgotten. By keeping track of the use of design patters, by documenting any deviations made from these, and by making deviations navigable and searchable, we equip designers with tools to maintain the system’s architectural integrity as the system evolves. 3.13 Multiple Abstraction Large-scale products are typically protocol intensive, which means that a SAD should support and integrate models at several levels of abstraction. For a simple example, think of a system with two components that communicate by a layered protocol with a message layer and a transport layer. In the system model, we only want message level signaling, whereas in the design model, we also use transport level signaling; in the SAD, we want system and design models to hold together through a visible refinement relation that is also used for consistency checking. Our interviews are full of examples of this need, e.g., “In the [system] model, we only show [message level] signals. We do not show how the details on how radio link setup has been transported as an [X frame] over an [Y channel], on an [Z cell] that in turn is transported on an [L link], and so on”. 3.14 Integration Point Interlocking A major difference between code- and model centric development is that the latter approach involves more integration points−sets of artefacts that must be consistent. Where agile, code centric development only has one integration point to worry about—the code—model centric development has several. For instance, the studied unit’s SAD has 9 models that each constitutes an integration point. If design teams are empowered to work with these models in their preferred order, branch and merge problems are inevitable—think of three teams working in parallel, unaware of each other. Branch and merge conflicts are by no means unique to model centric development. However, because of the large number of integration points that model centric development brings, branch and merge management becomes more difficult. We regard integration point interlocking as a necessary feature of a SAD that should serve as boundary object for concurrent teams. Just as railway systems needs interlocking to prevent conflicting movements through arrangement of train tracks,

Architectural Descriptions as Boundary Objects in System and Design Work

415

teams need support not to collide with other teams when moving through a SAD’s many components. 3.15 On-the-Fly Abstraction (or Model Filtering) Abstraction is a fundamental technique to increase understandability and reduce perceived complexity. In practical modeling, abstraction needs to be used sparingly, as networks of models at different levels of abstraction tend to be expensive to maintain and to keep consistent. Even though an updated domain model is of value to certain stakeholders, this value is (in many situations) not high enough to motivate maintenance costs. Several engineers in the unit see automated abstraction as a solution to this problem: by projecting detailed models, onto viewpoint definitions, views containing only the relevant details are generated. Such projections are often provided by modeling tools: many sequence diagram editors support instant abstraction by removal of certain objects or families of messages; report generators support abstraction through scripting languages with precise control of report output. 3.16 A Modeling Architecture Team Responsible for SAD Evolution Architectural engineering extends far beyond providing the organization with a SAD and tools for working with it: the SAD, its metamodel and support tools must also be evolved; views important to stakeholders need to be recognized and realized; models need to be integrated; surrounding processes updated; the level of detail used in the SAD’s models need to be coordinated and managed. These activities require deep knowledge not only in modeling and architecture, but also in the system’s technical domains, company internal processes, and business constraints. A common opinion, in the unit, is that just a handful of its engineers have the breadth and experience needed for these activities. Because of this, we regard an architectural team consisting of highly experienced staff as a necessity for effective evolution of a SAD. 3.17 Tooling Team Supporting Architects To be useful in large-scale projects, modeling technologies typically require extensive adaption, and configuration. However, model tooling is an activity of different nature than architecture work. One informant stressed the importance of a dedicated tooling team: “you need this depot team that lubricates the modeling environment...because you [add immense trouble] when you introduce a lot of [modeling] tools that can cease working at any time, and suddenly no-one has a clue of what is not working.” 3.18 Recognition of SAD Evolution We regard it essential that an organization recognizes the relationship between SAD evolution and project efficiency, and includes SAD evolution in its quality- and resource allocation instruments. Without this recognition, evolution work is likely to be under-financed, with negative economical consequences to the project as a whole.

416

L. Pareto, P. Eriksson, and S. Ehnebom

4 Discussions 4.1 Implementing SADs as Boundary Objects A SAD, in the sense defined by IEEE1471, is a single object shared by multiple stakeholders with different goals and concerns, and thus by definition a boundary object. Main challenges in implementing the approach described in this paper is to make the organizations fully aware of this, and to utilize the potential of a shared, multi faceted knowledge object for cooperation between different social worlds in a heterogeneous environment — all too often, design documentation, is viewed as coded knowledge sent along channels defined in process definitions, potentially replaceable by face-to-face communication. By providing organizations with a concrete set of requirements that (if adhered to) implant the idea of SADs as boundary objects into a SAD implementation, we hope to ease organizational implementation: illustrative requirements on what a next generation SAD should contain are somehow easier to build acceptance for, and to realize, than philosophical arguments about benefits of a changed view on documentation— even though the power of the approach lies in this changed view. We foresee organizational implementations to involve the following steps: (1) consideration of each of the requirements in section 3, with attention to situation specific constraints; (2) elicitation of situation specific requirements; (3) realization of the SAD by integration of the modeling- and team collaboration technologies available to the organization; (4) changes to software process to allow for the communication enabled by the new SAD; (5) organizational change to accommodate for the SADs evolution. Potential benefits of the approach are increased agility also for large and heterogeneous projects (because coordination and communication between system work and design work is improved), reduced lead times (because stakeholder orientation makes many tasks easier), and reduced effort (because investments made by other social groups can be re-used more easily). Organizations adopting a view of design documentation—and not only the code—as boundary object, also reduce the risk of throwing out the baby with the bath water when implementing lean and agile processes in the large. 4.2 Generality of Findings The requirements presented in section 3 are an abstraction of a larger set of situation specific requirements, guided by analogical reasoning of what we see as typical for model based software engineering in large-scale, heterogeneous product development, and what informants have emphasized as most important. Naturally, other organisations experience other such concrete requirements, and a similar abstraction of these would give different requirements sets. This said, we have included only requirements we see as generally valid. In particular, we have deliberately omitted requirements on the structure of the SAD. These are situation specific, and in any case not elementary. Further, this paper focuses on the study on needs related to system and design work. Although many of the requirements capture needs shared by testers, managers, and other social groups, a wider requirements elicitation scope results in additional requirements.

Architectural Descriptions as Boundary Objects in System and Design Work

417

4.3 Threats to Validity Qualitative studies are generally sensitive to (1) the analysts own understanding of the phenomena studied and the context in which they occur, and (2) analyst bias. We handled 1 by extensive on-site presence (one to two days per week during three years) during which the analyst assimilated and internalized the unit’s challenges, and aligned the world view with that of the unit’s practitioners. We handled 2 by member checking. Member checking has in itself a number of limitations: they are (3) taxing on informant time, and (4) sensitive to the engagement of the informants. We handled 3 by compensating informants with time and by the choice of a workshop format appreciated by practitioners at the unit; we handled 4 by choosing members with a clear stake in improving the units SAD.

5 Related Work Studies on lean and agile software development in large organizations have recognized several problems with communication: Karlström and Runeson, and Pikkarainen et al with inter-team communication [7, 18, 19]; Petersen and Wohlin with handovers between requirements and design, and with identification of dependencies [7]; Tomaszewski et al. with long-term architecture deterioration [6]; Lindvall et al. with handovers between requirement engineers and teams, communication with change control boards, alignment to baseline architecture, compatibility with quality systems, and inter-team communication [20]; Pikkarainen et al. with featurerequirement dependencies, task-subtask dependencies, clarity in responsibility, comprehensibility of requirements, and comprehensibility in testing [21]. Pikkarainen et al. explicitly recognize the need for engineered communication systems while noticing that “current research has, however, failed to provide valuable insight or discussion on the effects of agile practices on communication”. Some of our identified phenomena have already been recognized by researchers in computer supported cooperative work: (provision of a single common view of the system built) Pawlowski et al. identify the role of a boundary object to align multiple groups towards a common purpose [11]; (support contextual understanding) Lutters and Ackerman found that interpretation of historical elements of boundary objects relies on re-contextualization, and suggest augmentation of such elements with critical context capture [10]; (communicate and enforce architectural rules, an architecture team responsible for evolving the SAD) Subrahmanian et al observed significantly better success in design to test when design rules, and designs were used as boundary objects maintained by a responsible engineer [9]; (distinction between prescriptive and descriptive information) Phelps and Reddy conclude that boundary objects need to be designed so that they push and pull the right type of information at the right level of detail at the right time for the project [12]; (institutionalized SAD evolution) Subrahmanian et al. conclude that changes in structure, process, and information flow in engineering organizations are accompanied by the potential deterioration of common grounds, thus requiring creation of new boundary objects [9]. Although there is conceptual overlap between these findings and our requirements, they are not traceable to concrete uses of SADs. As for other requirements (coordination of interfaces,

418

L. Pareto, P. Eriksson, and S. Ehnebom

feeding automation chains, tabular as well as graphical modeling, free form annotation and diagramming, reports as first class views, documented rationale for each view, hyperlinks, drill down, and tagging, book-keeping of design pattern usage, multiple abstraction, integration point interlocking, model filtering, tooling team responsible for SAD evolution) we are not aware of explicit recognition of these.

6 Summary and Conclusion Contemporary lean and agile processes give excellent support for certain communication needs in large organizations, but insufficient support for inter-team communication. Studies of computer supported cooperative work in organizations conclude that common information spaces are critical for efficiency. A view of documentation as a boundary object (interconnecting intersecting stakeholder groups while satisfying group specific information needs) helps in understanding what additional support is needed in lean and agile processes. Using the notion of boundary object as theoretical lens, we have studied the role that a model based system architectural description plays in the communication between system engineers and designers in a large-scale, heterogeneous, product development project. Our main contribution is 18 empirically grounded requirements worth considering when implementing system architectural descriptions. We propose system architectural descriptions designed as boundary objects with attention to these requirements, as a compatible extension to lean and agile processes to solve their inter-team communication problems. Acknowledgments. This work has been supported by Ericsson Software Research through Ericsson’s Software Architecture and Quality Centre (SAQC).

References 1. Lindvall, M., Muthig, D., Dagnino, A., Wallin, C., Stupperich, M., Kiefer, D., May, J., Kahkonen, T.: Agile Software Development in Large Organizations. IEEE Computer 37(12), 26–34 (2004) 2. Abrahamsson, P., Warsta, J., Sippon, S.T., Ronkainen, J.: New Directions on Agile Methods: A Comparative Analysis. In: Proceedings of the 25th International Conference on Software Engineering, pp. 244–254. IEEE Computer Society, Washington (2003) 3. Mehta, M., Anderson, D., Raffo, D.: Providing Value to Customers in Software Development Through Lean Principles. Software Process: Improvement and Practice 13(1), 101– 109 (2008) 4. Poppendieck, M., Poppendieck, T.: Lean Software Development: an Agile Toolkit. Addison-Wesley, Boston (2003) 5. Poppendieck, M., Poppendieck, T.: Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, Upper Saddle River (2007) 6. Tomaszewski, P., Berander, P., Damm, L.O.: From traditional to streamline development opportunities and challenges. Software Process: Improvement and Practice 13(2), 195–212 (2008)

Architectural Descriptions as Boundary Objects in System and Design Work

419

7. Petersen, K., Wohlin, C.: A Comparison of Issues and Advantages in Agile and Incremental Development Between State of the Art and an Industrial Case. Journal of Systems and Software 82(9), 1479–1490 (2009) 8. Star, S.L., Griesemer, J.R.: Institutional Ecology, ‘Translations’, and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39. Social Studies of Science 19(4), 387–420 (1989) 9. Subrahmanian, E., Monarch, I., Konda, S., Granger, H., Milliken, R., Westerberg, A.: Boundary Objects and Prototypes at the Interfaces of Engineering Design. Computer Supported Cooperative Work 12(2), 185–203 (2003) 10. Lutters, W.G., Ackerman, M.S.: Beyond Boundary Objects: Collaborative Reuse in Aircraft Technical Support. Computer Supported Cooperative Work 16(3), 341–372 (2007) 11. Pawlowski, S., Robey, D., Raven, A.: Supporting Shared Information Systems: Boundary Objects, Communities, and Brokering. In: 21st International Conference on Information Systems, pp. 329–338. Association for Information Systems, Atlanta (2000) 12. Phelps, A.F., Reddy, M.: The Influence of Boundary Objects on Group Collaborationin Construction Project Teams. In: Proceedings of the ACM 2009 International Conference on Supporting Group Work, pp. 125–128. ACM, New York (2009) 13. de Paula, M.G., Barbosa, S.D.J.: Investigating the Role of a Model-Based Boundary Object in Facilitating the Communication between Interaction Designers and Software Engineers. In: Winckler, M., Johnson, H., Palanque, P. (eds.) TAMODIA 2007. LNCS, vol. 4849, pp. 273–278. Springer, Heidelberg (2007) 14. ANSI/IEEE Std 1471 :: ISO/IEC 42010 - Systems and Software Engineering - Recommended Practice for Architectural Description of Software-Intensive Systems. International Standard, ANSI/IEEE (2007) 15. Yin, R.K.: Case Study Research: Design and Methods. Sage Publications, Thousand Oaks (2003) 16. Pareto, L., Eriksson, P., Ehnebom, S.: Concern Visibility in Base Station Development: an Empirical Investigation. In: Schürr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 196–210. Springer, Heidelberg (2009) 17. Pareto, L., Staron, M., Eriksson, P.: Ontology Guided Evolution of Complex Embedded Systems in the Direction of MDA. In: Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., Völter, M. (eds.) MODELS 2008. LNCS, vol. 5301, pp. 874–888. Springer, Heidelberg (2008) 18. Pikkarainen, M., Haikara, J., Salo, O., Abrahamsson, P., Still, J.: The impact of agile practices on communication in software development. Empirical Software Engineering 13(3), 303–337 (2008) 19. Karlström, D., Runeson, P.: Combining Agile Methods with Stage-Gate Project Management. IEEE Software 22(3), 43–49 (2005) 20. Lindvall, M., Muthig, D., Dagnino, A., Wallin, C., Stupperich, M., Kiefer, D., May, J., Kahkonen, T.: Agile software development in large organizations. IEEE Computer 37(12), 26–34 (2004) 21. Pikkarainen, M., Haikara, J., Salo, O., Abrahamsson, P., Still, J.: The impact of agile practices on communication in software development. Empirical Software Engineering 13(3), 303–337 (2008)

Author Index

Ab Rahim, Lukman I-166 Abid, Saad Bin I-211 Abrah˜ ao, Silvia II-213, II-288 Almeida da Silva, Marcos Aur´elio II-303, II-318 Amaral, Vasco I-136 Ambroziewicz, Albert I-241 Arcuri, Andrea I-286 Arendt, Thorsten I-121 Aßmann, Uwe II-47, II-78 Atlee, Joanne M. II-198 Bagheri, Hamid II-376 Balogh, Andr´ as I-76 Balogh, Zolt´ an I-76 Barais, Olivier I-91 Barroca, Bruno I-136 Batory, Don II-2 Beaudoux, Olivier I-91 Bendraou, Reda II-303, II-318 Berger, Stefan II-153 Bergmann, G´ abor I-76 Biermann, Enrico I-121 Blanc, Xavier II-303, II-318 Blouin, Arnaud I-91 Botterweck, Goetz I-211 Briand, Lionel I-286 Broy, Manfred II-183 Buckl, Christian II-391 Chauvel, Franck II-168 Cheng, Betty H.C. I-316 Cleland-Huang, Jane I-226 da Costa, Andrew Diniz I-301 da Cruz, Ant´ onio Miguel Rosado I-256 da Silva, Viviane Torres I-301 Dahms, Marco II-243 Day, Nancy A. II-198 de Lara, Juan I-16, I-106, I-376 de Lucena, Carlos Jos´e Pereira I-301 Denker, Marcus II-138 dos Santos, Osmar Marchi I-106

Egyed, Alexander II-123 Ehnebom, Staffan II-406 Engels, Gregor II-93 Eriksson, Peter II-406 Eshuis, Rik II-258 Esmaeilsabzali, Shahram II-198 Faria, Jo˜ ao Pascoal I-256 Fuhrmann, Hauke I-196 Garc´es, Kelly I-61 Garcia, Alessandro I-301 Garc´ıa-Izquierdo, Francisco J. II-361 G´erard, S´ebastien I-392 Gerth, Christian II-93 Gervais, Marie-Pierre II-303 Goldsby, Heather J. I-316 Gonzalez-Huerta, Javier II-288 Greevy, Orla II-138 Groher, Iris II-123 Gr¨ onniger, Hans I-331 Grossmann, Georg II-17, II-153 Guerra, Esther I-16, I-106, I-376 Heinrich, Matthias I-271 Herrmannsdoerfer, Markus ´ Horv´ ath, Akos I-76 Hu, Zhenjiang I-181 Huang, Gang II-168

I-61

Insfran, Emilio II-213, II-288 Iqbal, Muhammad Zohaib I-286 J´ez´equel, Jean-Marc I-91, II-63 Johannes, Jendrik II-47 Jurack, Stefan I-121 Kainz, Gerd II-391 Karsai, Gabor I-46 Kienzle, J¨ org II-63 Klein, Jacques II-63 Knoll, Alois II-391 Kolahdouz-Rahimi, Shekoufeh II-228 Kolovos, Dimitrios S. I-61, I-106, I-211, I-376

422

Author Index

K¨ onemann, Patrick II-108 Krause, Christian I-121 K¨ uhne, Thomas I-31 Kuhrmann, Marco II-183 Kulkarni, Vinay II-331 K¨ uster, Jochen M. II-93 Lano, Kevin II-228 Lee, Edward A. II-273 Loniewski, Grzegorz II-213 L´ ucio, Levi I-136 Luckey, Markus II-93 Lussenburg, Vincent II-346 M¨ ader, Patrick I-226 Madsen, Ole Lehrmann I-1 Mei, Hong I-181, II-168 M´endez Fern´ andez, Daniel II-183 Møller-Pedersen, Birger I-1 Morin, Brice II-63 Mougenot, Alix II-318 Nierstrasz, Oscar II-138 Noyrit, Florian I-392 Oberle, Daniel ¨ os, Andr´ Okr¨ as

II-243 I-76

Paige, Richard F. I-61, I-106, I-211, I-376 Pardillo, Jes´ us I-407 Pareto, Lars II-406 Peischl, Bernhard I-151 Penzenstadler, Birgit II-183 Polack, Fiona A. C I-61, I-211 Preußner, Andr´e I-271 Rahmani, Tirdad II-243 Rajbhoj, Asha II-331 R´ ath, Istv´ an I-76 Reddy, Sreedhar II-331 Reimann, Jan II-78 Reiß, Dirk I-331 Ressia, Jorge II-138 Rich´e, Taylor L. II-2

Robin, Jacques II-318 Rodriguez-Priego, Emilio II-361 Rose, Louis M. I-61, I-211 ´ Rubio, Angel Luis II-361 Rumpe, Bernhard I-331 Saxena, Tripti I-46 Schramm, Arne I-271 Schrefl, Michael II-17, II-153 Schwarzl, Christian I-151 Seifert, Mirko II-78 Selic, Bran I-392 Shiraishi, Shin’ichi I-346 ´ Smia lek, Michal I-241 Sommer, Stephan II-391 Song, Hui II-168 Stumptner, Markus II-17, II-153 Sullivan, Kevin II-376 Sun, Yanchun II-168 Taentzer, Gabriele I-121 Terrier, Fran¸cois I-392 Thiele, Michael I-361 van der Storm, Tijs II-346 Van Gorp, Pieter II-258 Varr´ o, D´ aniel I-76 Vin, Harrick M. II-2 Vinju, Jurgen II-346 Voelter, Markus II-32 Vogel, Lars I-271 von Hanxleden, Reinhard I-196 Wang, Bo I-181 Warmer, Jos II-346 Wende, Christian I-361 Whittle, Jon I-166 Wilke, Claas I-361 Williams, James R. I-61 Xiong, Yingfei

I-181, II-168

Zave, Pamela II-1 Zhang, Wei I-181 Zhao, Haiyan I-181