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 <<delete>> 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()

<<enumeration>> DMState opening closing stopped

<<enumeration>> 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 <= f f <= maxfloor f /= dest

arrive_post lfloor = f f = dest => lm = stop f = dest => 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 <= f f <= maxfloor f = dest

travelling

arrive(f)[f = dest]

[lm /= stop]

door starts to open doorstartsopening_pre dclosed = true

[dm = opening] doorstartsopening()

doorstartsopening_post dclosed = false lm = stop

door opening doorcloses_post

dooropens_pre dopen = false dclosed = false

[dm = opening] dooropens()

dclosed = true dm = stopped dest > lfloor => 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 () <=2 Cardinality with 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)−> 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 () <=2

250

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

In some cases there might be individuals involved in local restrictions, for example in Enumeration Classes or in HasValue statements pointing to a specific individual. Furthermore, confusion remains about how to handle, e.g., cardinality constraints where counting of individuals is essential. In our transformation the software engineer has the option to mark whether he wants to consider the sameAs and differentFrom relations of the Ecore class Thing and based on that the adequate OCL constraint will be generated and attached. 3.6 Property Characteristics In general, OWL properties can be declared to be functional or inverse-functional. In particular, object properties can be declared to be symmetric and/or transitive. The expressiveness of Ecore is not enough to handle property characteristics, which makes the use of OCL unavoidable to achieve a maximum level of preservation. In the following sections, we show how OWL 1.1 property characteristics can be translated to OCL constraints. We assume that the OWL class Person will be translated to a corresponding Ecore class Person with some properties of certain characteristics. Functional and Inverse Functional Properties: Generally, object properties are binary relations R ⊆ A  B with the set A as the domain and the set B as the range. A functional object property declares the binary relation R to be a partial function from A to B. On the other hand, an inverse functional object property states for the binary relation R that: ∀x1 , x2 , y : x1 Ry∧x2 Ry ⇒ x1 = x2 . For transforming the TBox it is sufficient to transform the functional and inverse functional object property assertions to the following OCL constraints: OWL Assertion: FunctionalObjectProperty(a:hasFather) s e l f . h a s F a t h e r −> 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 () <=1 OWL Assertion: InverseFunctionalObjectProperty(a:fatherOf) 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 . 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 <-: pre -; // at l e a s t t w o 3 negative { : RoguePrePlace ( t); } 4 negative { : RoguePostPlace (t) ; } 5 modify { 6 p : Place -: pre -> t; // f o l d 7 // u p d a t e t r e e 8 : HSCandState <-: HSCcontains - : HSCorState 9 <-: PN2HSC - p ; 10 eval { p. name= " ANDJOIN_ " +t . name; } 11 exec ([ handlePrePlace_AND_join (t ,p ) ]) ; 12 } 13 } 14 rule handlePrePlace_AND_join (t: Transition ,p : Place ) { 15 q_i : Place -: pre -> t; // e a c h p l a c e in p r e s e t 16 q_i -: PN2HSC -> or : HSCorState ; // t a k e OR 17 p -: PN2HSC -> : HSCorState -: HSCcontains -> 18 parentAND : HSCandState ; 19 modify { 20 or <-: HSCcontains - parentAND ; // m o v e OR n o d e 21 exec ([ move_incoming_arcs (q_i , p) ] 22 | [ move_outgoing_arcs ( q_i ,p )] 23 | [ cleanupP ( q_i ) ]) ; // I N P U T DESTRUCTIVE 24 }

265

25 } 26 27 rule move_outgoing_arcs ( srcPl: Place , trgPl : Place ) { 28 otherTrans : Transition <- e1 : pre - srcPl ; 29 alternative { 30 // A L T E R N A T I V E P A T T E R N 1 31 NotYetPresent { 32 negative { 33 otherTrans <-: pre - trgPl ; 34 } 35 modify { 36 otherTrans <-: pre - trgPl ; 37 } 38 } 39 // A L T E R N A T I V E P A T T E R N 2 40 AlreadyPresent { 41 otherTrans <-: pre - trgPl ; 42 modify { 43 // do n o t l i n k o t h e r T r a n s to t r g P l a g a i n ! 44 } 45 } 46 } 47 modify { 48 delete ( e1 ) ; 49 } 50 }

Fig. 5. GrGen Rule and Subrule for handling AND joins (cfr. Fig. 3a and 4)

consisting of a transition that has at least two incoming arcs. The right-hand side (between lines 6 and 11) specifies among other things that a new Place element should be inserted before that transition. That element is represented by variable p, exactly as in Fig. 3 (a). Also notice that elements that have no name in the informal specification (i.e., in the rules shown on Fig. 3) can be left anonymous in the formal GrGen specification too (e.g., the two anonymous edge variables of type pre on line 2.) Unlike the imperative Java solution discussed above, GrGen programs require no explicit element traversal, nor element indices. Another characteristic of the GrGen solution is that it heavily relies on subpatterns (e.g., “:RoguePrePlace(t)” on line 3). Such subpatterns enable reuse and encapsulation The example fragment also shows how the right-hand side of the trans AND join triggers another rule (the handlePrePlace AND join rule) using the exec statement (e.g., lines 11 and 21). Within exec statements, subrules can be orchestrated using various control flow constructs ( for example “[]” denotes the concurrent execution of a rule on all possible matches in the host graph). Initially, the GrGen solution was implemented based on the Java solution, as described in [5], so using the search algorithm. It turned out that it was difficult to specify the search criterion in GrGen and the runtime performance was poor. We therefore decided to also implement a GrGen solution without the search algorithm. This new GrGen solution, which is presented in this paper, resembles the initial Java version, but with the distinction that in GrGen the ordering of the rules does not need to be explicitly specified by the user: the GrGen engine determines the ordering (scheduling) of the rules automatically. The new GrGen solution turns out to be much more efficient than the initial GrGen solution and even outperforms the optimized Java solution. In retrospect, we conclude that the development of model transformations using imperative programming languages like Java may bias researchers towards optimizations

266

P. Van Gorp and R. Eshuis

that are specific to imperative programming and it may blur the distinction between conceptual mapping rules and technical details that are specific to an implementation technology.

5

Evaluation of the Solutions

This section classifies the solutions according to the conceptual, design, language and tool level and then presents quantitative results. 5.1

Conceptual Classification

Before comparing the two solutions further from a design, language or tool perspective, we need to ensure that the solution fragments under consideration are responsible for exactly the same conceptual tasks. Since we want to focus our comparison on the realization of the core mapping rules that were presented in Subsection 3.2, we first need to decompose the large PN2SC translation problem into more manageable parts. We also need to check the correctness of both solutions. Decomposition of the PN2SC Case Study. Different subproblems can be classified by transformation type (translation, reiteration, or rephrasing), input/output type (text-to-model, model-to-model, or model-to-text) and abstraction effect (horizontal or vertical ) [19]. The core transformation is of type translation, since the input modeling language (petri-nets) is clearly different from the output modeling language (statecharts). We also agree to treat the core as a model-to-model transformation, which implies for example that input parsing and output serialization is considered a separate text-to-model and model-to-text transformation steps. We also agree that adapting the input and output elements to the proposed meta-model is not the responsibility of the core solution. Similarly, the core does not handle adaptation to UML syntax, removal of hyper-edges (i.e., the step between Fig. 2 (a) and (b)), or adaptation to standards such as XMI. In [19], we also characterize these subproblems, since that helps defining their scope without becoming overly technical. For the sake of this paper, the primary purpose of the decomposition into subproblems is however that it enables the comparison of integrated transformation solutions from an end-user perspective. More specifically, in Section 5.1, we can now outline the completeness of the integrated transformation chains in which the two core solutions are embedded. Completeness and Correctness of the two Solutions. Table 1 shows that besides the core problem, both solutions tackle a series of other challenges. The table contains a cross in a cell if the solution from that row implements the feature from that column (see [19] for details). Several features support the exchange of models for benchmarking purposes: the read/write PNML and read/write GRPN features have enabled us to test both solutions on (conceptually)

Transforming Process Models

267

Table 1. Completeness of the solutions from a User perspective core r. PNML w. PNML PN MM’ r. GRPN w. GRPN w. GRSC rm. HE to UML style w. XMI Java

x

GrGen

x

x

x x

x x

x

x

x x

x

x

the same set of input models. The GrGen solution is unique in that it implements several extensions to the basic mapping rules from [5]: it implements the “remove hyper-edges” feature (as discussed in the context of Fig. 2 (b)) as well as the features related to the UML. The correctness of both solutions was verified by means of input/output testing. For this purpose, we have composed a test-suite consisting of real-life process models (among others: models from the SAP reference model [16]), manually fabricated process models (to test specific patterns) as well as automatically fabricated process models. The latter type of test models were used to evaluate the performance and scalability of the solutions. This type of models was generated based on models from a petri-net benchmark by Bergmann et al. [2,19]. 5.2

Design Specific Classification

Classifying the design of a transformation is a key ingredient for making fair comparisons between transformation solutions: it would for example be unfair to generalize for example the quantitative results from Section 5.5 towards conclusions about any other Java and GrGen transformation. In this section, we use standard transformation jargon to classify those design choices that could have been made otherwise in Java and GrGen. The Java solution has been designed as an endogenous, in-place model transformation: firstly, the metamodel for input and output models is realized as a data structure that has no clear separation between petri-net and statechart related properties. Secondly, input model elements are destroyed during transformation execution, since they become an integral part of the output model. In contrast, the GrGen solution has been designed as an exogenous, out-place model transformation: firstly, input and output models have two distinct metamodels, and secondly output elements are populated by copied values from the input elements. During transformation execution, traceability links are maintained between input elements and the corresponding output elements. For the sake of comparability and simplicity, the GrGen solution destroys the input petri-net during transformation execution too: more specifically, the folding operations that are visualized on Fig. 3 are realized by removing input elements. We mention this simplification, since it may be undesirable when the transformation would be deployed in an integrated modeling environment, where input and output models are supposed to co-evolve. Both the Java and the GrGen solution automatically transform all elements from the input model. Again it is well possible to change both solutions into a variant that only transforms a controlled subset of the input model. However,

268

P. Van Gorp and R. Eshuis

taking the GrGen fragment from Fig. 5 as an example, this would require the trans AND join rule to have a parameter of type Transition. This parameter would need to be instantiated explicitly by another rule. Similar extensions would need to be made to the Java solution. These changes would have little impact on simple size metrics such as LOC but may significantly impact metrics that were proposed for transformation complexity (such as val-in/out and fan-in/out [1].) In general, different design choices will have an impact on the usability of the solution fragments under consideration. Before making quantitative comparisons concerning size and complexity, one needs to take these differences into account. Moreover, these choices are design (not language or tool ) specific. The Java and GrGen designs are similar in terms of other taxonomy elements [19]: both solutions are unidirectional, they do not support change propagation and they do not support tolerating inconsistencies(e.g., indicating that some non-safe petri-net elements should be ignored.) The main threat for performing a further evaluation of both approaches is that the Java design is endogenous/in-place whereas the GrGen solution is exogenous/out-place: an exogenous solution in Java would for example require more metamodel definition effort. We have not created an endogenous/in-place variant of the Java solution since that would only strengthen the results of our quantitative analysis (cfr., Section 5.5), rather than raise new insights. 5.3

Language Specific Classification

This section discusses those solution properties that are a direct consequence of the underlying transformation (programming) languages. This paper focuses on those properties that convey interesting differences between the two solutions. In those cases that both Java and GrGen suffer from a limitation that has already been addressed by other transformation languages, the reader is referred to the related literature. The primary strength of the GrGen language over Java relates to the declarative constructs for pattern matching and rule scheduling. As an example of the pattern matching part, consider line 2 from Fig. 5, which very concisely specifies that this rule for and joins applies only to those transitions that have at least two incoming pre arcs. As an example of the GrGen rule scheduling operators, consider the following fragment, which models explicitly that the trans place and trans transition rules need to be executed before the other rewrite rules, whereas the order in which the transformation system iterates over the transform singleton pre post, trans AND split and trans AND join rules is left implicit (by using the “$” operator). Since Java only offers the sequential “;” operator, it is less declarative from the rule scheduling perspective: [trans_place]&&[trans_transition]&&[trans_post]&&[trans_pre]&&[trans_token] | (transform_singleton_pre_post $|| trans_AND_split $|| trans_AND_join)*

From the perspective of genericity and modularization however, Java is a more expressive language than GrGen. GrGen for example has no support for rule specialization (a form of genericity) and also lacks mechanisms to hide or import

Transforming Process Models

269

rules using module constructs. In [19], we refer to QVT, Story Diagrams, Triple Graph Grammars (TGGs) as examples of rule based languages that have already overcome these limitations. These languages also have more declarative support for traceability, incremental updates and bidirectionality than both GrGen and Java. Notice that neither the GrGen nor the Java solution from this paper implements these features. Although one can explicitly implement these features using any general purpose language, any TGG or QVT/Relations solution would inherently support them. A cognitive analysis of the solutions based on Green and Petre [8] has primarily learned us that GrGen specifications are closer to the problem domain: all variables shown on Fig. 5 map directly to variables from the informal rule shown on Fig. 3. In contrast, there are various helper variables (e.g., i and tId ) needed in the corresponding Java fragment shown on Fig. 4. The cognitive analysis also enables us to name a problem that has caused some errors during the solution development: the GrGen language is inconsistent about its default matching semantics. As concrete evidence from consequences for the PN2SC case, [19] shows a GrGen implementation fragment that is surprisingly more complex than its mathematical counter-part. Moreover, the GrGen textual syntax enforces some pre-mature commitment (as defined by [8]) with regards to the order of statement specification: even though the aforementioned “$” operator provides semantic support for conveying that rules are allowed to be executed in any order, a textual syntax forces one to trigger rules in a particular (and artificial) syntactic order. Finally, the highly declarative and textual operators for rule scheduling may require hard mental operations (as defined by [8]) for developers with a history in using more imperative languages. Except for the inconsistent default matching semantics, Java exposes the same cognitive problems as GrGen. Both languages also lack support for the “secondary notation” [8], while visual languages typically enable one to use layout and color to convey additional semantical clues. Finally, remark that more Java programmers are available on the job market but many may be interested in learning language such as GrGen as more experimental results become available. 5.4

Tool Specific Classification

In this section, we only discuss those tool features that we have found most useful during the development of the PN2SC solutions. Firstly, we rate the debugger usability of Eclipse lower than that of the GrGen suite, for two reasons: (i) the Java debugger from Eclipse has no rule-oriented user interface so developers should know which particular methods or parts thereof happen to implement a transformation rule and (ii) the Eclipse debugger shows irrelevant technical variables on the same level as pattern variables. Secondly, Eclipse does not provide a generic visualizer for the transformed models. The Java solution does include integration code for the dot visualization framework but since Eclipse is unaware thereof there is for example no

270

P. Van Gorp and R. Eshuis 14

700

GrGenoptimized,including optimizationtime

12

600 500

10

400

8 java grgen

300

GrGennonͲoptimized Java

6

200

4

100

2 0

0 reused

mapping

UI

metamodel

(a)

0

5000

10000

15000

(b)

Fig. 6. Size (LOC) and performance (execution time seconds) of the solutions

integration with the Eclipse debugger. Moreover, the dot framework exposes performance problems that do not occur when using the GrGen suite. From an interoperability perspective, Eclipse provides some support for standards such as XMI or MOF. Since the Java solution pre-dates the related Eclipse plugins, the core of the Java solution to PN2SC has been written without taking that into account. At the time of writing, only the GrGen solution provides XMI support. Remarkably, the GrGen suite has once provided tool-level support for XMI too, but the functionality was broken in up-to-date versions of the tool. Therefore, explicit XMI related rules had to be written for the PN2SC case. As a threat to the generalizability of our experimental observations, we highlight that we did not need to perform large changes to the solution designs once they were finished. Therefore, we did not need much tool support for refactoring. However, we do observe – independently of our experiment – that the refactoring support for Java is very elaborate in tools such as Eclipse whereas it is not supported at all for GrGen. 5.5

Quantitative Evaluation

Fig. 6 (a) shows that the size the implementations of the core mapping rules only differs by a factor five. The main difference in size (and hence specification effort) relates to user interface (UI) aspects: for the Java solution, all user interface widgets for loading the input model and triggering the transformation is programmed specifically for the case study. The Java code also integrates with the dot framework. That code is reused from another tool (see the leftmost bar in Fig. 6 (a)) and therefore it is not counted as part of the solution specific UI code. GrGen programs can rely on a flexible shell that makes user interface code unnecessary. Moreover, GrGen includes a visualization engine with a very concise configuration language. As a result, the Java solution contains about ten times as much case study specific UI code, compared to the GrGen solution. Fig. 6 (a) also shows that GrGen offers a concise language for metamodel definition.

Transforming Process Models

271

Fig. 6 (b) displays the runtime performance of the two solutions, based on the automatically generated suite of test-model that is discussed in Section 5.1. Although Fig. 6 (b) has a limited scale, we have used test-models of 100, 200, ... elements to about 300.000 elements. All results can be reproduced via an online virtual machine [18]. In general, the performance of both solutions scales linearly for models of normal size (requiring always less than a second.) For models with thousands of elements, the GrGen solution exhibits an (x2 ) time complexity. Notice on Fig. 6 (b) that for models consisting of less than 10.000 elements, the time that is required for analyzing the input model and generating optimized code does not outweigh the speedup. Therefore, for small input models one should turn GrGen engine optimizations off. The Java solution cannot process more than about 15.000 elements, due to limitations of the address space of the 32 bits Java virtual machine that we have used. Fig. 6 (b) also indicates that for inputs models with more than 10.000 elements, the required processing time increases significantly too. For models of some hundreds of thousands of elements, the GrGen engine optimizations reach a speedup factor of almost two.

6

Conclusions

From a completeness perspective, both solutions solve the core mapping problem of the PN2SC case study adequately for a head-to-head comparison. Their designs are comparable and this paper carefully analyzes their differences. Most importantly, the Java design contains a case-specific optimization algorithm whereas the GrGen solution only relies on engine optimizations. Several design decisions could have been made differently by other transformation writers so conclusions about our specific solution sizes should not be taken out of context. From the perspective of the transformation language though, the GrGen solution does have more declarative constructs for pattern specification and rule scheduling. Conversely, Java has more advanced constructs for genericity and modularity. From a cognitive perspective, the GrGen language enables specifications that are closer to the problem domain. This paper also describes the threats related to comparing the proposed Java and GrGen solutions with solutions based on languages with built-in support for traceability, change propagation and bidirectionality. One should extend the Java and GrGen solutions with such features before incorporating them in our quantitative evaluation. Finally, from a transformation tool perspective, we observe that the GrGen solution is supported by more usable debugging and visualization tools. Java on the other hand has better support for refactoring. The Java solution requires more specification effort without yielding a better runtime performance. Remarkably, the Java solution has even been revised for performance reasons. Its mathematical formalization had to co-evolve, leading to considerable overall complexity. The GrGen development did not require such iterations. We therefore conclude that for developing mappings such as the PN2SC translation, rule-based languages and tools are more appropriate.

272

P. Van Gorp and R. Eshuis

References 1. Amstel, M.F., Lange, C.F., Brand, M.G.: Using metrics for assessing the quality of ASF+SDF model transformations. In: Paige, R.F. (ed.) ICMT 2009. LNCS, vol. 5563, pp. 239–248. Springer, Heidelberg (2009) ´ R´ 2. Bergmann, G., Horv´ ath, A., ath, I., Varr´ o, D.: A benchmark evaluation of incremental pattern matching in graph transformation. In: Ehrig, H., Heckel, R., Rozenberg, G., T¨ antzer, G. (eds.) ICGT 2008. LNCS, vol. 5214, pp. 396–410. Springer, Heidelberg (2008) 3. Dijkman, R.M., Dumas, M., Ouyang, C.: Semantics and analysis of business process models in bpmn. Inf. Softw. Technol. 50(12), 1281–1294 (2008) 4. Dumas, M.: Case study: BPMN to BPEL model transformation. In: 5th International Workshop on Graph-Based Tools, Satellite Workshop to TOOLS 2009 (2009) 5. Eshuis, R.: Translating safe petri nets to statecharts in a structure-preserving way. In: Cavalcanti, A., Dams, D.R. (eds.) FM 2009. LNCS, vol. 5850, pp. 239–255. Springer, Heidelberg (2009); Extended as Beta WP 282 at Eindhoven University of Technology 6. Geiß, R., Kroll, M.: GrGen.net: A fast, expressive, and general purpose graph rewrite tool. In: Rensink, T¨ antzer (eds.) [14], pp. 568–569 7. Graef, J.: Managing taxonomies strategically. Montague Institute Review (2001) 8. Green, T.R.G., Petre, M.: Usability analysis of visual programming environments: A ‘cognitive dimensions’ framework. Journal of Visual Languages and Computing 7(2), 131–174 (1996) 9. Habel, A., Heckel, R., T¨ antzer, G.: Graph grammars with negative application conditions. Fundamenta Informaticae 26(3-4), 287–313 (1996) 10. Harel, D.: Statecharts: A visual formalism for complex systems. Sci. Comput. Program. 8(3), 231–274 (1987) 11. Horv´ ath, A., Bergmann, G., R´ ath, I., Varr´ o, D.: Experimental assessment of combining pattern matching strategies with VIATRA2. In: STTT (2010) 12. Mens, T., Van Gorp, P.: A taxonomy of model transformation. In: Karsai, G., T¨ antzer, G. (eds.) Proc. GraMoT 2005. ENTCS, vol. 152, pp. 125–142. Elsevier, Amsterdam (March 2005) 13. Murata, T.: Petri nets: Properties, analysis and applications. Proceedings of the IEEE 77(4), 541–580 (1989) 14. Rensink, A., T¨ antzer, G. (eds.): AGTiVE 2007, Kassel, October 10-12. LNCS, vol. 5088. Springer, Heidelberg (2007) (Revised Selected and Invited Papers) 15. Russell, N., ter Hofstede, A., van der Aalst, W., Mulyar, N.: Workflow control-flow patterns: A revised view. Technical Report BPM-06-22, BPMcenter.org (2006) 16. SAP. Discovering processes, SAP library (2010), http://help.sap.com/SAPHELP NW04S/helpdata/EN/26/1c6d42ab7fd142e10000000a1550b0/content.htm 17. Van Gorp, P.: Model-driven Development of Model Transformations. PhD thesis, University of Antwerp (April 2008) 18. Van Gorp, P.: Online demo: PN2SC in Java and GrGen (2010), http:// is.ieis.tue.nl/staff/pvgorp/share/?page=ConfigureNewSession&vdiID=343 19. Van Gorp, P., Eshuis, R.: Transforming process models: executable rewrite rules versus a formalized java program. Technical Report Beta WP 315, Eindhoven University of Technology (2010) 20. Van Gorp, P., Mazanek, S., Rensink, A.: Transformation Tool Contest – Awards (2010), http://is.ieis.tue.nl/staff/pvgorp/events/TTC2010/?page=Awards 21. Varr´ o, D., Asztalos, M., Bisztray, D., et al.: Transformation of UML models to CSP: A case study for graph transformation tools. In: Rensink, T¨ antzer (eds.) [14], pp. 540–565

Disciplined Heterogeneous Modeling Invited Paper Edward A. Lee EECS, UC Berkeley [email protected]

Abstract. Complex systems demand diversity in the modeling mechanisms. One way to deal with a diversity of requirements is to create flexible modeling frameworks that can be adapted to cover the field of interest. The downside of this approach is a weakening of the semantics of the modeling frameworks that compromises interoperability, understandability, and analyzability of the models. An alternative approach is to embrace heterogeneity and to provide mechanisms for a diversity of models to interact. This paper reviews an approach that achieves such interaction between diverse models using an abstract semantics, which is a deliberately incomplete semantics that cannot by itself define a useful modeling framework. It instead focuses on the interactions between diverse models, reducing the nature of those interactions to a minimum that achieves a well-defined composition. An example of such an abstract semantics is the actor semantics, which can handle many heterogeneous models that are built today, and some that are not common today. The actor abstract semantics and many concrete semantics have been implemented in Ptolemy II, an open-source software framework distributed under a BSD-style license.

1

Introduction

Occam’s razor is a widely used principle in science and engineering that prefers theories and hypotheses with the fewest assumptions, postulates, or entities that are sufficient to accomplish the goal. The principle can be expressed as “entities must not be multiplied beyond necessity” (entia non sunt multiplicanda praeter necessitatem) or as “plurality should not be posited without necessity” (pluralitas non est ponenda sine necessitate) [1]. The principle is attributed to 14th-century English logician, theologian and Franciscan friar William of Ockham. 

This work was supported in part by the Center for Hybrid and Embedded Software Systems (CHESS) at UC Berkeley, which receives support from the National Science Foundation (NSF awards #0720882 (CSR-EHS: PRET) and #0931843 (ActionWebs), the U. S. Army Research Office (ARO #W911NF-07-2-0019), the U. S. Air Force Office of Scientific Research (MURI #FA9550-06-0312 and AF-TRUST #FA9550-06-1-0244), the Air Force Research Lab (AFRL), the Multiscale Systems Center (MuSyC) and the following companies: Bosch, National Instruments, Thales, and Toyota.

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

274

E.A. Lee

Despite its compelling value, the principle has its limitations. Immanuel Kant, for example, felt a need to moderate the effects of Occam’s razor, stating “the variety of beings should not rashly be diminished.” (entium varietates non temere esse minuendas) [2]. Einstein allegedly remarked, “everything should be made as simple as possible, but not simpler” [3]. When applied to design techniques, Occam’s razor biases us towards using fewer and simpler design languages and notations. However, experience indicates that redundancy and diversity can both be beneficial. For example, there is benefit to using UML class diagrams even if the information they represent is already encoded in a C++ program, making the diagrams redundant. There is also value in use-case diagrams, which express concepts that are not encoded at all in a C++ program that realizes a design. The use-case diagrams represent aspects of the design not (directly) represented in a class diagram, or even in the program itself. The plurality of notations in UML and its derivatives runs distinctly counter to the principle in Occam’s razor. To take an extreme position, arguably, everything that can be expressed in UML can be expressed in natural language. In fact, historically, natural language specifications of design are the precursors of UML specifications. The syntax of natural languages (at least the Indo-European languages) is simpler and less diverse than the syntax of UML, and it is already familiar to anyone who would engage in design. So what is gained by this antirazor? One might postulate that UML diagrams offer more precision than natural language descriptions. This is partly true of some diagrams. Consider class diagrams, for example. These have a rather simple syntax, but are not as precise as a set of C++ header files, for example. In particular, the varied interpretations of associations and the extension mechanisms make it possible to create standard-compliant class diagrams that mean almost anything. In general, UML standards emphasize syntax over semantics, and compliance with the standard is about the structure and appearance of diagrams, and not so much about their meaning. So improved precision can’t possibly be the justification for the anti-razor. Design of software systems is essentially a creative process. Engineers create artifacts that did not previously exist. Occam’s razor should not be applied to creative processes. A plurality of media for expression enrich process, even when the plurality is not driven by necessity. In this paper, I will argue for an anti-razor in a class of design representations called actor-oriented models. Actors are concurrent components that share data by sending messages via ports. An amazing variety of techniques have evolved that fit this general description. Were we to apply Occam’s razor, we would seek the single unifying actor-oriented modeling language. I argue that instead we need a plurality of distinct actor-oriented modeling languages, together with mechanisms for composing models in these languages, each with a strong and clear semantics. But to support the design of complex systems, we must also provide for heterogenous composition of models.

Disciplined Heterogeneous Modeling

275

The technique I describe is that developed in the Ptolemy Project, and largely previously presented in [4,5,6]. The key idea is to use a common abstract syntax for a diverse set of actor-oriented models, and to hierarchically compose those models using an abstract semantics. This paper is organized as follows. The next section justifies the need for heterogeneous modeling. Section 3 describes the common abstract syntax used in Ptolemy II. Section 4 describes the actor abstract semantics. Section 5 describes a few of the many possible models of computation that have proved useful. Conclusions follow.

2

Heterogeneity

Complex systems demand diversity in the modeling mechanisms. We see this diversity of models very clearly with cyber-physical systems (CPS), which combine computing and networking with physical dynamics, and hence require model combinations that integrate dynamics (often described using differential equations) with models of software. We also see it in applications where timed interactions between components are combined with conventional algorithmic computations, such as in networked computer games. We even see it in traditional software systems when we have concurrent interactions between algorithmic components. One way to deal with a diversity of models is to create very flexible or underspecified modeling frameworks that can be adapted to cover models of interest. The downside of this approach is a weakening of the semantics of the modeling frameworks that compromises interoperability, understandability, and analyzability of the models. An alternative approach is to embrace heterogeneity and to provide mechanisms for a diversity of models to interact. Model diversity arises in various ways [7]. In multi-view modeling, distinct and separate models of the same system are constructed to model different aspects of a system. For example, one model may describe dynamic behavior, while another describes physical design and packaging. In amorphous heterogeneity, distinct modeling styles are combined in arbitrary ways within the same model without the benefit of structure. For example, some component interactions in a model may use rendezvous while others use publish-and-subscribe. In hierarchical multimodeling, hierarchical compositions of distinct modeling styles are combined to take advantage of the unique capabilities and expressiveness of the distinct modeling styles. A familiar example is Statecharts [8], which hierarchically combines synchronous concurrent composition with finite state machines. This paper will focus on a disciplined form of hierarchical multimodeling studied in the Ptolemy project and implemented in the Ptolemy II software environment. Using hierarchy, one can effectively divide a complex model into a tree of nested submodels, which are at each level composed to form a network of interacting actors. Our approach constrains each of these networks to be locally

276

E.A. Lee

homogeneous, using a common execution and communication semantics called a model of computation (MoC). The key is to use constrained MoCs with strong semantic properties as much as possible, and to allow hierarchical composition of distinct MoCs to overcome the constraints that are the price for strong semantic properties.

3

A Common Abstract Syntax

The Ptolemy approach uses a common abstract syntax across diverse models. An abstract syntax defines the structure of models and may be described by a meta model. A meta model for the Ptolemy II abstract syntax is shown in Figure 1. Everything in a Ptolemy II model is an instance of NamedObj, which has a string name (not shown in the meta model). There are four specific kinds of NamedObj: Attribute, Entity, Port, and Relation. Any NamedObj has a name and a collection of instances of Attribute. An Entity contains a collection of instances of Port. Ports are associated with instances of Relation, which mediate connections between ports. A CompositeEntity is an Entity that contains instances of Entity and Relation. An AtomicActor is an executable Entity. A CompositeActor is executable CompositeEntity. A Director is an executable Attribute. An example is shown in Figure 2 using the concrete syntax of Vergil, a visual editor for Ptolemy II models. In that figure, the top-level of the hierarchy is labeled “Model: CompositeActor,” which means that its name is Model and that it is an instance of CompositeActor. Model contains an instance of Director, three actors, and one relation. Actors A and C are composite, whereas actor B is atomic. The ports of the three actors are linked to the relation. In Figure 2, actor A contains one Port named p, one Director, one actor D, and one Relation. The port of D is linked to the port p via the relation.1 Actor C is similar except that it does not contain an instance of Director, and it contains an Attribute (indicated with a bullet). In Ptolemy II, some attributes have values given in an expression language. For details, see [9]. A composite actor that contains a director is said to be opaque, and one that does not is said to be transparent. As I will explain below, opaque composite actors are key to hierarchical heterogeneity. From outside, an opaque composite actor looks just like an atomic actor. Its inside structure cannot be seen. It is a black box. In contrast, a transparent composite actor is simply a syntactic grouping with no semantic meaning. The inside structure is fully visible from outside. It is a white box. The block diagram in Figure 2 uses one of many possible concrete syntaxes for the same model. The model can also be defined in Java syntax or in an XML schema known as MoML [10]. All three syntaxes describe model structure. We will next give the structure some meaning. 1

Vergil will typically not show this relation, but it is there in the model structure nonetheless.

Disciplined Heterogeneous Modeling

277

NamedObj

Attribute 0..1 +Attribute(container : NamedObj, name : String)

0..n

+getAttribute(name : String) : Attribute +attributeList() : List

«Interface» Executable container Entity +fire() +initialize() +postfire() : boolean +prefire() : boolean +getPort(name : String) : Port +isAtomic() : boolean +preinitialize() +isOpaque() : boolean +wrapup() +portList() : List

0..1

0..n link

0..n

link 0..n

Port -_container : Entity +link(relation : Relation) +linkedRelationList() : List #_checkLink(relation : Relation)

0..n

0..1 container 0..1

«Interface» Actor

CompositeEntity

+linkedPortList() : List

0..n

container

+getDirector() : Director

AtomicActor 0..n

0..1

CompositeActor

0..1 container

Director

Relation

0..1

Fig. 1. A meta model for Ptolemy II

Fig. 2. A hierarchical model in Ptolemy II

ComponentRelation

278

4

E.A. Lee

The Actor Abstract Semantics

In an actor-oriented model, components called actors execute concurrently, receiving data from other actors (or from themselves in feedback systems) at their input ports and sending data to other actors (or themselves) via their output ports. What exactly it means to “execute concurrently” and to send or receive data depends on the specific model of computation. The MoC has a concrete semantics. To permit hierarchical composition of distinct MoCs, the concrete semantics conforms to an abstract semantics. We describe this abstract semantics informally. A formal framework can be found in [11]. The abstract semantics has three distinct aspects, execution control, communication, and models of time. We discuss these in order. 4.1

Execution Control

The semantics of execution and communication is governed by a director in a composite actor, which implements a particular MoC. As shown in Figure 1, a Director is an Attribute that implements the Executable interface. It is rendered in Vergil as a green rectangle, as shown in Figure 2. Inserting a Director into a composite actor makes the composite actor executable. Atomic actors also implement the Executable interface. An execution of an executable actor has the following phases: setup, iterate, and wrapup, where each phase has more fine-grained phases. The setup phase is divided into preinitialize and initialize phases, methods of the Executable interface. In the preinitialize subphase, an actor performs any actions that may influence static analysis (including scheduling, type inference and checking, code generation, etc.). For example, a composite actor may fix its own internal structure, creating internal actors, etc. The initialization phase initializes parameters, resets local state, and sends initial messages on output ports, if any. Typically, the preinitialization of an actor is performed exactly once during the actor’s lifetime in a model execution, and before any other execution of the actor. The initialization of an actor is performed once after the preinitialization and type resolution. It may be performed again if the semantics requires that the actor to be re-initialized, for example, in the hybrid system formalism [12]. Actors perform atomic executions (called iterations) in the iterate phase. An iteration is a (typically finite) computation that leads the actor to a quiescent state. The MoC of a composite actor determines how the iteration of one actor is related to the iterations of other actors in the same composite (whether it is concurrent or interleaved, whether and when it is scheduled, etc.). In order to coordinate the iterations among actors, an iteration is further broken down into three subphases called prefire, fire, and postfire. Prefire tests the preconditions for the actor to execute, such as the presence of sufficient inputs to complete the iteration. The computation of the actor is typically performed during the fire phase, where it will read inputs, process data, and produce outputs. An actor may have persistent state that evolves during execution. The postfire phase is used to update that state in response to any inputs.

Disciplined Heterogeneous Modeling

279

Note that despite the fact that computation occurs during the fire phase, the state of the actor is not updated until postfire. This supports fixed-point iteration in some MoCs, such as synchronous reactive models and continuous time differential equations. Directors implementing an MoC with a fixed-point semantics compute the fixed point of actor outputs while keeping the state of each actor constant. The state of an actor can only be updated after the fixed point has been reached. This requires the firing of each actor several times before the actor is postfired. Such a strategy helps to ensure that the MoC is determinate. This strategy is only followed by actors conforming to the strictest form of the actor abstract semantics. In [13], Goderis et al. classify actor-oriented MoCs into three categories of abstract semantics call strict, loose, and loosest. In the strict actor semantics, prefire, fire, and postfire are all finite computations where only postfire makes any changes to the state of the actor. In the loose actor semantics, changes to the state may be made in the fire phase. In the loosest actor semantics, the fire phase may not be finite. It could represent a non-terminating computation. An actor that conforms with the strict actor semantics can be used with any actor-oriented director. Such an actor is said to be domain polymorphic. An actor that conforms only with the loose actor semantics can be used with fewer directors. An actor that conforms only with the loosest actor semantics can be used with still fewer. Some actors are designed to work only with a single specific type of director. These actors are not domain polymorphic. A director also implements the same phases of execution. When put within a composite actor, making it opaque, the director endows that composite actor with an executable semantics. If the director conforms to the strict actor semantics, then an opaque composite actor with that director is domain polymorphic. Such directors support the most flexible form of hierarchical heterogeneity in Ptolemy II. 4.2

Communication

A director determines how actors communicate. It does this by creating an object called a receiver and placing that object in input ports. There is one receiver for each communication channel. Receivers can implement FIFO queues, mailboxes, execution control

data transport

Basic Transport: receiver.put(t)

send(0,t)

init() fire() E1

P1

get(0) P2

R1

token t

IOPort IORelation Actor

E2

Receiver (inside port)

Fig. 3. Communication mechanism in Ptolemy II

280

E.A. Lee

IOPort 0..n

0..1

«Interface» Receiver

NoRoomException

throws

throws

NoTokenException

+get() : Token +getContainer() : IOPort +hasRoom() : boolean +hasToken() : boolean +put(t : Token) +setContainer(port : IOPort)

Mailbox

«Interface» ProcessReceiver

QueueReceiver

DEReceiver

SDFReceiver

1..1

1..1 1..1

CTReceiver

CSPReceiver

PNReceiver

1..1

FIFOQueue

ArrayFIFOQueue

Fig. 4. Meta model for communication in Ptolemy II

proxies for a global queue, rendezvous, etc. They do this by conforming to the meta model shown in Figure 4. When an actor sends data t to an output port p1 , the mechanics of the send are delegated to the receiver in each input port p2 that the output port is connected to, as shown in Figure 3. When an actor gets data from an input port, that action is also delegated to the receiver. Thus, what it means to send data to an output port of get data from an input port is determined by the director.

4.3

Models of Time

Some models of computation have a notion of time, meaning that they assume that when they are fired, their environment provides a value representing the time of that firing. A part of the actor abstract semantics provides a mechanism for accessing and controlling the advancement of time. Ptolemy II uses a model time known as superdense time [12,14]. Superdense time is represented in Ptolemy II as pair (t, n), where n is of type int and t = mr is an arbitrarily large multiple m of a time resolution r. The multiple m is realized as a Java BigInteger (an arbitrarily large integer), and r is of type double. The pair (t, n) models a physical time t and an index n. The index is used to disambiguate simultaneous events that are causally related [12]. Time is ordered lexicographically, which means that (t1 , n1 ) < (t2 , n2 ) if either t1 < t2 , or t1 = t2 and n1 < n2 .

Disciplined Heterogeneous Modeling

281

When an actor fires, it can ask for the current time. If it does this in the postfire phase of execution, then it is assured that time is nondecreasing. If it does it in the fire phase, there is no such assurance because some directors speculatively advance time while converging to a fixed point [15]. An actor can also request that it be fired at some future time. The director is responsible for ensuring that that the requested future firing occurs. There may be an arbitrary number of intervening firings before the one at that future time. The model hierarchy is central to the management of time. The top-level director advances time. If the top-level director does not implement a timed model of computation, then by default only the index n is incremented. The current physical time remains at the default start time, with value zero. Timed models of computation may be interleaved in the hierarchy with untimed models of computation (see below). There are certain combinations that do not make sense, however. For example, if the top-level director never advances time, and an actor requests a firing at a future time, then the request cannot be honored. Such combinations result in an exception at run time. Time can also advance non-uniformly in a model. In particular, modal models support a notion of local time where advancement of time can be temporarily suspended [16]. Within the submodel there is a monotonically non-decreasing gap between local time and environment time. This mechanism is used to model temporary suspension of a submodel.

5

Models of Computation

In Ptolemy II an implementation of a model of computation is called a domain.2 A domain defines the communication semantics and the execution of actors within the domain. We present here some domains that we have realized in Ptolemy II. This is far from a complete list. The intent is to show the diversity of the models of computation under study. Process network. In the process network (PN) domain, actors represent processes that communicate by (conceptually infinite capacity) FIFO queues [17]. Receivers in this model implement these FIFO queues. Writing to the queues always succeeds, while reading from an empty queue blocks the reader process. The simple blocking-read, nonblocking-write rule ensures the determinacy of the model [18]. This domain is untimed. We have extended the model with specific support for certain forms of nondeterminism. Each actor executes in its own Java thread, so on multi-core machines they can execute in parallel. Dataflow. Ptolemy II includes several dataflow domains, all restricted special cases of PN [19]. The synchronous dataflow (SDF) domain [20] is a particularly restricted special case with strong, decidable, formal properties. When an actor is executed in this model, it consumes a fixed number of tokens from each input 2

The term “domain” comes from a fanciful notion in astrophysics, that there are regions of the universe with different sets of laws of physics. A model of computation represents the “laws of physics” of the submodel governed by it.

282

E.A. Lee

port, and produces a fixed number of tokens to each output port. A valuable property of SDF models is that deadlock and boundedness can be statically analyzed, and schedules (including parallel schedules) can be statically computed. Receivers in this domain represent FIFO queues with fixed finite capacity, and the execution order of components is statically scheduled. SDF can be timed or untimed. The dynamic dataflow (DDF) domain is more flexible, but computes schedules on the fly. Discrete event. In the discrete event (DE) domain, actors communicate through events placed on a time line. Each event has a value and a time stamp. Actors process events in chronological order. The output events produced by an actor are required to be no earlier in time than the input events that were consumed. In other words, actors in DE are causal. The execution of this model uses a global event queue. When an actor generates an output event, the event is placed in the queue, and sorted according to its time stamp. Receivers in this domain are proxies for the global event queue. During each iteration of a DE model, the events with the smallest time stamp are removed from the global event queue, and their destination actor is fired. The DE domain supports simultaneous events. At each time where at least one actor fires, the director computes a fixed point [15]. The semantics of DE is given in [21]. Finite-state machines. The finite-state machine (FSM) domain is the only one of the domains discussed here that is not actor oriented [16]. The entities in this domain represent states, and the relations represent transitions between states. Attributes are used to represent guards, which determine when a transition is taken from one state to another. Each state has one port for incoming transitions and one for outgoing transitions. Thus, although FSM models can be represented with the same abstract syntax as actor models, the ports are not used for communication but rather for sequential control. The FSM domain interoperates with all other domains hierarchically, providing a powerful construct called a modal model [16]. In a modal model, each state of an FSM represents a mode of execution. The state can have one or more refinements, which are submodels with a director that are active when the FSM is in that state. When a submodel is not active, its local time does not advance. Continuous time. The Continuous domain [12,22] models ordinary differential equations (ODEs), extended to allow the handling of discrete events. Special actors that represent integrators are connected in feedback loops in order to represent the ODEs. Each connection in this domain represents a continuoustime function, and the components denote the relations between these functions. Each receiver in the Continuous domain is a buffer with size one. It contains the value of the continuous function of the corresponding connection at a specific time instant. The execution of a Continuous model involves the computation of a numerical solution to the ODEs. In an iteration of a Continuous model, time is advanced by a certain amount determined by the solver. At each instant, the director computes a fixed point for all signal values using the principles

Disciplined Heterogeneous Modeling

283

of synchronous/reactive models (see below) [15]. To advance time, the director chooses a time step with the help of a solver and speculatively executes actors through this time step. If the time step is sufficiently small (key events such as level crossings, mode changes, or requested firing times are not skipped over), then the director commits the time increment and proceeds to the postfire phase. The Continuous director conforms to the strict actor semantics, and hence interoperates with all other timed Ptolemy II domains. Combining it with FSMs yields a particular form of modal model known as a hubrid system [12,16]. Combinations with discrete-event and synchronous/reactive are also particularly useful [15]. Redezvous. In the Rendezvous domain, actors represent processes that communicate by atomic instantaneous rendezvous. Receivers in this domain implement the rendezvous points. An attempt to put a token into a receiver will not complete until a corresponding attempt is made to get a token from the same receiver, and vice versa. As a consequence, the process that first reaches a rendezvous point will stall until the other process also reaches the same rendezvous point [23]. Like PN, this domain supports explicit nondeterminism.

6

Related Work

The actor-oriented models I consider here are syntactically related to composite structure diagrams of UML 2 [24,25], or more directly its derivative SysML [26]. The internal block diagram notation of SysML, which is based on the UML 2 composite structure diagrams, particularly with the use of flow ports, is closely related to actor models. In SysML, the actors are called “blocks,” presumably because the term “actor” was already in use in UML for another purpose. SysML, however, defines the syntax of these diagrams, not their semantics. Although the intention is that “flow ports are intended to be used for asynchronous, broadcast, or send-and-forget interactions” [26], there is nothing like an MoC given in SysML. Therefore, the same SysML diagrams may in fact represent many different designs. Standardizing the notation is not sufficient to achieve effective communication among designers. MARTE (modeling and analysis of real-time and embedded systems) goes a bit further [27], but specifically avoids “constraining” (or even defining) the execution semantics of models. This flexibility may account for some of the success of these notations, but it is arguable that constraints that lead to well-defined and interoperable models have value as well. Our notion of actor-oriented modeling is related to the term actor as introduced in the 1970’s by Hewitt to describe the concept of autonomous reasoning agents [28]. The term evolved through the work of Agha and others to describe a formalized model of concurrency [29]. Agha’s actors each have an independent thread of control and communicate via asynchronous message passing. The Ptolemy version embraces a larger family of models of concurrency that are often more constrained than general message passing. Our actors are still conceptually concurrent, but unlike Agha’s actors, they need not have their own

284

E.A. Lee

thread of control. Moreover, although communication is still through some form of message passing, it need not be strictly asynchronous. Some authors use the term multi-paradigm modeling for the mixing of models of computation [30]. In this paper, we focus on techniques that combine actors with multi-paradigm modeling. An early systematic approach to such mixed models was realized in Ptolemy Classic [4]. Ptolemy II is a successor to Ptolemy Classic [5]. Influenced by the Ptolemy approach, SystemC is capable of realizing multiple MoCs [31,32]. So are ModHel’X [33] and ForSyDe [34,35]. Another approach supports mixing concurrency and communication mechanisms without the structural constraints of hierarchy [36,37]. A number of other researchers have tackled the problem of heterogeneity in creative ways [38,39]. For each MoC, a Ptolemy model contains a director, which annotates the model to assert the MoC being used, and provides either a code generator or an interpreter for the MoC (or both). An interesting alternative is given by “42” [40], which integrates with the model a specification of a customized MoC. Mathematical foundations of heterogeneous actor models are given by the tagged-signal model [11]. The model offers a declarative semantics that facilitates comparing variants and defining heterogeneous composition. Several of the above mentioned tools and techniques are extensible in that there is no fixed finite set of MoCs. Several widely used tools, in contrast, provide fixed combinations of a few MoCs. Commercial tools include Simulink/StateFlow (from The MathWorks), which combines continuous and discrete-time actor models with finite-state machines, and LabVIEW (from National Instruments), which combines dataflow actor models with finite-state machines and with a time-driven MoC. Statemate [41] and SCADE [42] combine finite-state machines with a synchronous/reactive formalism [43]. Giotto [44] and TDL [45] combine FSMs with a time-driven MoC. Several hybrid systems modeling and simulation tools combine continuous-time dynamical systems with FSMs [46]. The Y-chart approach approach supports heterogeneous modeling and is popular for hardware-software codesign [47]. This approach separates modeling of the hardware architecture that will realize a system from modeling of application behavior (a form of multi-view modeling), and provides mechanisms for bringing these disparate models together. These mechanisms support explorations of the design space that can trade off hardware cost and complexity with software design. Metropolis is a particularly elegant tool realizing this approach [36]. It introduces a notion called a “quantity manager” that mediates interactions between functionality and the resources required to implement the functionality. Modelica [48] also has actor-like semantics in that components are concurrent and communicate via ports, but the ports are neither inputs nor outputs. Instead, the connections between ports declare equation constraints on variables. This approach has significant advantages, particularly for specifying physical models based on differential-algebraic equations (DAEs). However, the approach also appears to be harder to combine heterogeneously with other MoCs.

Disciplined Heterogeneous Modeling

7

285

Conclusion

This paper reviews actor-oriented modeling of complex systems, arguing that it provides a disciplined approach to heterogeneity. The central notion in hierarchical model decomposition is that of a domain, which implements a particular model of computation. Technically, a domain serves to separate the flow of control and data between components from the actual functionality of individual components. Besides facilitating hierarchical models, this factoring potentially also dramatically increases the reusability of components and models.

Acknowledgements Hundreds of people have contributed to Ptolemy II and its predecessor, Ptolemy Classic. For the particular topics in this paper, I give credit to Christopher Brooks, Joe Buck, Thomas Huining Feng, Soonhoi Ha, Jie Liu, Xiaojun Liu, Dave Messerschmitt, Stephen Neuendorffer, Tom Parks, John Reekie, Yuhong Xiong, and Haiyang Zheng.

References 1. Encyclopedia Britannica: Ockham’s razor. Encyclopedia Britannica (retrieved June 24, 2010) 2. Smith, N.K.: Immanuel Kant’s Critique of Pure Reason. Macmillan and Co., Basingstoke (1929) 3. Shapiro, F.R.: The Yale Book of Quotations. Yale University Press, New Haven (2006) 4. Buck, J.T., Ha, S., Lee, E.A., Messerschmitt, D.G.: Ptolemy: A framework for simulating and prototyping heterogeneous systems. Int. Journal of Computer Simulation, special issue on “Simulation Software Development” 4, 155–182 (1994) 5. Eker, J., Janneck, J.W., Lee, E.A., Liu, J., Liu, X., Ludvig, J., Neuendorffer, S., Sachs, S., Xiong, Y.: Taming heterogeneity—the Ptolemy approach. Proceedings of the IEEE 91(2), 127–144 (2003) 6. Lee, E.A., Neuendorffer, S., Wirthlin, M.J.: Actor-oriented design of embedded hardware and software systems. Journal of Circuits, Systems, and Computers 12(3), 231–260 (2003) 7. Brooks, C., Cheng, C., Feng, T.H., Lee, E.A., von Hanxleden, R.: Model engineering using multimodeling. In: International Workshop on Model Co-Evolution and Consistency Management (MCCM), Toulouse, France (2008) 8. Harel, D.: Statecharts: A visual formalism for complex systems. Science of Computer Programming 8, 231–274 (1987) 9. Brooks, C., Lee, E.A., Neuendorffer, S., Zhao, Y., Zheng, H.: Heterogeneous concurrent modeling and design in Java. Technical Report Technical Memorandum UCB/EECS-2008-28, University of California (April 1, 2008) 10. Lee, E.A., Neuendorffer, S.: MoML - a modeling markup language in XML. Technical Report UCB/ERL M00/12, UC Berkeley (March 14, 2000) 11. Lee, E.A., Sangiovanni-Vincentelli, A.: A framework for comparing models of computation. IEEE Transactions on Computer-Aided Design of Circuits and Systems 17(12), 1217–1229 (1998)

286

E.A. Lee

12. Lee, E.A., Zheng, H.: Operational semantics of hybrid systems. In: Morari, M., Thiele, L. (eds.) HSCC 2005. LNCS, vol. 3414, pp. 25–53. Springer, Heidelberg (2005) 13. Goderis, A., Brooks, C., Altintas, I., Lee, E.A., Goble, C.: Heterogeneous composition of models of computation. Future Generation Computer Systems 25(5), 552–560 (2009) 14. Liu, X., Matsikoudis, E., Lee, E.A.: Modeling timed concurrent systems. In: Baier, C., Hermanns, H. (eds.) CONCUR 2006. LNCS, vol. 4137, pp. 1–15. Springer, Heidelberg (2006) 15. Lee, E.A., Zheng, H.: Leveraging synchronous language principles for heterogeneous modeling and design of embedded systems. In: EMSOFT, Salzburg, Austria. ACM, New York (2007) 16. Lee, E.A.: Finite state machines and modal models in Ptolemy II. Technical Report UCB/EECS-2009-151, EECS Department, University of California, Berkeley (November 1, 2009) 17. Lee, E.A., Parks, T.M.: Dataflow process networks. Proceedings of the IEEE 83(5), 773–801 (1995) 18. Kahn, G., MacQueen, D.B.: Coroutines and networks of parallel processes. In: Gilchrist, B. (ed.) Information Processing, pp. 993–998. North-Holland Publishing Co., Amsterdam (1977) 19. Lee, E.A., Matsikoudis, E.: The semantics of dataflow with firing. In: Huet, G., Plotkin, G., L´evy, J.J., Bertot, Y. (eds.) From Semantics to Computer Science: Essays in memory of Gilles Kahn. Cambridge University Press, Cambridge (2009) 20. Lee, E.A., Messerschmitt, D.G.: Synchronous data flow. Proceedings of the IEEE 75(9), 1235–1245 (1987) 21. Lee, E.A.: Modeling concurrent real-time processes using discrete events. Annals of Software Engineering 7, 25–45 (1999) 22. Liu, J.: Continuous time and mixed-signal simulation in Ptolemy II. Memo M98/74, UCB/ERL, EECS UC Berkeley, CA 94720 (July 1998) 23. Hoare, C.A.R.: A theory of CSP. Communicating Sequential Processes 21(8) (August 1978) 24. Bock, C.: SysML and UML 2 support for activity modeling. Systems Engineering 9(2), 160–185 (2006) 25. Booch, G., Jacobson, I., Rumbaugh, J.: The Unified Modeling Language User Guide. Addison-Wesley, Reading (1998) 26. Object Management Group (OMG): System modeling language specification v1.1. Technical report, OMG (2008) 27. Object Management Group (OMG), A UML profile for MARTE, beta 1. OMG Adopted Specification ptc/07-08-04, OMG (August 2007) 28. Hewitt, C.: Viewing control structures as patterns of passing messages. Journal of Artificial Intelligence 8(3), 323–363 (1977) 29. Agha, G.A., Mason, I.A., Smith, S.F., Talcott, C.L.: A foundation for actor computation. Journal of Functional Programming 7(1), 1–72 (1997) 30. Mosterman, P.J., Vangheluwe, H.: Computer automated multi-paradigm modeling: An introduction. Simulation: Transactions of the Society for Modeling and Simulation International Journal of High Performance Computing Applications 80(9), 433–450 (2004) 31. Patel, H.D., Shukla, S.K.: SystemC Kernel Extensions for Heterogeneous System Modelling. Kluwer, Dordrecht (2004)

Disciplined Heterogeneous Modeling

287

32. Herrera, F., Villar, E.: A framework for embedded system specification under different models of computation in SystemC. In: Design Automation Conference (DAC), San Francisco. ACM, New York (2006) 33. Hardebolle, C., Boulanger, F.: ModHel’X: A component-oriented approach to multi-formalism modeling, MODELS 2007 Workshop on Multi-Paradigm Modeling, Nashville, Tennessee (October 2, 2007) 34. Jantsch, A.: Modeling Embedded Systems and SoCs - Concurrency and Time in Models of Computation. Morgan Kaufmann, San Francisco (2003) 35. Sander, I., Jantsch, A.: System modeling and transformational design refinement in ForSyDe. IEEE Transactions on Computer-Aided Design of Circuits and Systems 23(1), 17–32 (2004) 36. Goessler, G., Sangiovanni-Vincentelli, A.: Compositional modeling in Metropolis. In: Second International Workshop on Embedded Software (EMSOFT), Grenoble, France. Springer, Heidelberg (2002) 37. Basu, A., Bozga, M., Sifakis, J.: Modeling heterogeneous real-time components in BIP. In: International Conference on Software Engineering and Formal Methods (SEFM), Pune, pp. 3–12 (2006) 38. Burch, J.R., Passerone, R., Sangiovanni-Vincentelli, A.L.: Overcoming heterophobia: Modeling concurrency in heterogeneous systems. In: International Conference on Application of Concurrency to System Design, p. 13 (2001) 39. Feredj, M., Boulanger, F., Mbobi, A.M.: A model of domain-polymorph component for heterogeneous system design. The Journal of Systems and Software 82, 112–120 (2009) 40. Maraninchi, F., Bhouhadiba, T.: 42: Programmable models of computation for a component-based approach to heterogeneous embedded systems. In: 6th ACM International Conference on Generative Programming and Component Engineering (GPCE), Salzburg, Austria, pp. 1–3 (2007) 41. Harel, D., Lachover, H., Naamad, A., Pnueli, A., Politi, M., Sherman, R., ShtullTrauring, A., Trakhtenbrot, M.: STATEMATE: A working environment for the development of complex reactive systems. IEEE Transactions on Software Engineering 16(4) (1990) 42. Berry, G.: The effectiveness of synchronous languages for the development of safetycritical systems. White paper, Esterel Technologies (2003) 43. Benveniste, A., Berry, G.: The synchronous approach to reactive and real-time systems. Proceedings of the IEEE 79(9), 1270–1282 (1991) 44. Henzinger, T.A., Horowitz, B., Kirsch, C.M.: Giotto: A time-triggered language for embedded programming. In: Henzinger, T.A., Kirsch, C.M. (eds.) EMSOFT 2001. LNCS, vol. 2211, p. 166. Springer, Heidelberg (2001) 45. Pree, W., Templ, J.: Modeling with the timing definition language (TDL). In: Broy, M., Kr¨ uger, I.H., Meisinger, M. (eds.) ASWSD 2006. LNCS, vol. 4922, pp. 133–144. Springer, Heidelberg (2008) 46. Carloni, L.P., Passerone, R., Pinto, A., Sangiovanni-Vincentelli, A.: Languages and tools for hybrid systems design. Foundations and Trends in Electronic Design Automation 1(1/2) (2006) 47. Kienhuis, B., Deprettere, E., van der Wolf, P., Vissers, K.: A methodology to design programmable embedded systems. In: Deprettere, F., Teich, J., Vassiliadis, S. (eds.) SAMOS 2001. LNCS, vol. 2268, p. 18. Springer, Heidelberg (2002) 48. Fritzson, P.: Principles of Object-Oriented Modeling and Simulation with Modelica 2.1. Wiley, Chichester (2003)

Design Guidelines for the Development of Quality-Driven Model Transformations Emilio Insfran, Javier Gonzalez-Huerta, and Silvia Abrahão ISSI Research Group, Department of Information Systems and Computation Universidad Politécnica de Valencia Camino de Vera, s/n, 46022, Valencia, Spain +34-96-387 93 51 {einsfran,jagonzalez,sabrahao}@dsic.upv.es

Abstract. The design of model transformations is a key aspect in model-driven development processes and is even more important when alternative transformations exist. The transformation designer must be able to identify which alternative transformations produce models with the desired quality attributes. This paper presents design guidelines for defining model transformations to deal with alternative transformations in which the selection of the alternatives is done based on quality attributes. The design guidelines are defined in the context of a multimodeling approach which, unlike conventional transformation processes that only use source models as input to apply transformations, also uses two additional models: a quality model for representing quality attributes, and a transformation model for representing the relationships among quality attributes and the alternative transformations in a particular domain. Keywords: Model-Driven Development, Model Transformation Design, Model Quality Assurance.

1 Introduction Model-Driven Development (MDD) is an approach to software development that proposes the use of models at various levels of abstraction and model transformations as its main artifacts. Models are not only used for documentation but also for analysis, simulation, test cases and code generation. In this context, model transformations thus become a key aspect in the development process. Model transformation is the process of converting one model (source) into another model (target) of the same system [11]. This means that part of the development effort is relocated to the transformation design and implementation. The design of model transformations needs to deal with not only a functional concern, i.e., how to move from a source model to a target model, but also with nonfunctional concerns, which are the desired quality attributes of the target model. A quality attribute is a inherent property or characteristic of an entity that can be distinguished quantitatively or qualitatively by human or automated means (e.g., reusability of a model) [7]. In order to do this, the transformation designers need to D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 288–302, 2010. © Springer-Verlag Berlin Heidelberg 2010

Design Guidelines for the Development of Quality-Driven Model Transformations

289

identify possible alternative transformations and choose those alternatives that produce the target model with the desired quality attributes. In current model transformation design practices, the required quality attributes of the target model are hard-coded in the transformation definition even though this information is not directly related to the functional concern of the transformation. Hard-coding refers to the software development practice of embedding input or configuration data directly into the source code of a program or specification, rather than of obtaining the required information or data from external sources. This paper presents design guidelines for the definition of model transformations dealing with alternative model transformations in which the selection of the alternatives is done based on quality attributes. In order to avoid the hard-coding of the transformation, and to improve the flexibility of the transformation definition, the design guidelines are defined in the context of a multimodeling approach. A multimodel is a collection of models supporting different views of a system, characterized by the existence of relationships among elements of their correspondent metamodels [3]. Unlike other transformation processes, which only use source models as input to apply the transformations, our approach proposes the use of two additional models: a quality model to represent quality attributes, and a transformations model to represent the relationship among quality attributes and the alternative transformations in a particular domain. The main purpose of the design guidelines is to help transformation designers properly define multimodel-based transformations that deal not only with the traditional source and target models but also with the quality and transformations models. The paper is structured as follows. Section 2 discusses some existing approaches dealing with aternative model transformations. Section 3 presents an overview of our quality-driven model transformation approach and describes the main artifacts used. Section 4 presents the design guidelines for the development of quality-driven model transformations. Section 5 presents a case study conducted to test the usefulness of the proposed guidelines. Finally, Section 6 presents our conclusions and further work.

2 Related Work In this section, we focus on discussing some of the proposals that deal with the selection of alternative model transformations from the perspective of certain quality attributes. It is worth mentioning that the mechanisms used to choose an appropriate alternative transformation may differ greatly depending on the nature and the domain of the transformation, in addition to the quality attribute that is chosen. In [10], Merilinna proposed a tool which helps the architect in chosing the architecture for a system with certain quality attributes, however the architect must take some decisions manually. The approach considers only horizontal transformations (PIM-to-PIM transformations), which are those that are executed within the same level of abstraction. These transformations are specified in order to define the mappings between patterns from the source model to the target model. If there are several alternatives, the architectdetermines which architecture is the best solution by considering the information gathered in a database called StyleBase. The StyleBase contains a set of design patterns and architectural styles with information about the quality attributes and optional rationale.

290

E. Insfran, J. Gonzalez-Huerta, and S. Abrahão

In [8], Kurtev proposed a formal technique for the definition of transformation spaces, which supports the analysis of alternative transformations for a given source model. This technique provides operations for the selection and reduction of transformation spaces based on certain desirable quality properties of the resulting target model. The transformation space was generated through the definition of a process which takes a source model and its metamodel, the target metamodel, and the quality properties as input. The quality properties are used as selection criteria among the alternatives and are explicitly included in transformation spaces. This approach specifically deals with the adaptability and the reusability of model transformations to obtain XML schemas from UML class models. These two proposals focus on defining vertical transformations for model refinement [8] and horizontal transformations for model refactory [10]. Our approach can be adapted to both vertical and horizontal transformations, thus permitting it to cover transformations from the whole MDD lifecycle. In addition, we propose a generic approach that can be applied to any domain. In these proposals the relations between quality attributes and transformations are coded within the transformation definition, thus reducing the maintainability and reusability of model transformations. Our transformation definitions are based on multimodels in which the transformation rules are modeled and weighted. The most appropriate of these rules can be chosen at run-time according to the quality attributes that are required in the target model. In general, other quality-driven model transformation approaches deal with model quality in terms of a small number of quality attributes and specific types of transformations. There is a need for both more flexible definitions of alternative model transformations and more generic approaches that cover the entire MDD lifecycle to support any number of quality attributes.

3 A Quality-Driven Model Transformations Architecture Figure 1 presents an overview of our architecture to support quality-driven modeltransformations. A key aspect of this architecture is the use of two models as active artifacts to drive the selection and execution of model transformations: a quality model to represent quality attributes, and a transformation model to represent the relationship among quality attributes and the alternative transformations. The architecture divides the transformation process into two phases: Rules Analysis and Transformation. In the Rules Analysis phase, the software engineer performs the Alternatives Identification activity to identify the alternative transformations in a particular domain. The domain expert also performs the Trade-Off Analysis activity among quality attributes and alternative model transformations. This trade-off analysis is performed by means of the Analytic Hierarchy Process (AHP)[1]. The AHP is a decision-making technique that is widely used to resolve conflicts in which it is necessary to address multi-criteria comparisons. In our approach, we use the two main phases of the AHP technique: i) Value Score Computation, and ii) Normalization. In the first phase of the AHP, the domain expert performs two pair wise comparisons, weighting the relative importance of the different quality attributes identified by comparing every pair of quality attributes using the AHP weighting scale [1] and obtaining a Wz value. The domain expert then determines how each design alternative relatively supports the relevant quality attributes. For every quality attribute, we compare all the alternatives in a pair-wise fashion, thus obtaining the

Design Guidelines for the Development of Quality-Driven Model Transformations

291

values of Siz which allows us to then compute the value score for each possible alternative transformation i for the structural pattern j using the following formula: (1) Finally, in the second phase of the AHP, the value scores obtained in the previous phase are normalized. The value scores from different decisions must be compared, and they are then scaled relatively.

Fig. 1. Phases and artifacts of the quality-driven model transformation architecture

Once the trade-off analysis has been completed, the software engineer performs the Rules Selection activity. This activity uses the results from the trade-off analysis and the quality attributes selected by the software engineer to generate the Active Rules Model, which contains the selected transformations from the set of alternative transformations that produces a target model that best fits the desired quality attributes. In the second phase of our architecture (Transformation), the Quality-Driven Model Transformation activity is performed by using both the definition of non-alternative transformations and the definition of the selected transformations from the Active Rules Model. Since only those alternative transformations which best support the desired quality attributes are executed, we ensure that the produced target model satisfies the desired quality attributes. The two phases of our quality-driven model transformation architecture has been implemented in the Eclipse environment using QVT-Relations [12] as a transformation language and MediniQVT as transformation engine. In this section we introduce the artifacts of our architecture, describing their metamodels. 3.1 The Quality Model The quality model is defined as being the set of characteristics and the relationships between them, which provide a framework for specifying quality requirements and

292

E. Insfran, J. Gonzaleez-Huerta, and S. Abrahão

evaluating quality [7]. These kinds of models are often used to represent hierarchhies of quality attributes. Top-leevel attributes represent general quality characteristics (ee.g., usability, maintainability) while w bottom-level attributes represent measurable propperties of software artifacts. Our quality model allows the transformation designer to select the quaality attributes to be considered by the transformation process. Its corresponding metam model is composed of four claasses (see Figure 2): a QualityModelclass which is the ccontainer class, and the Charracteristic, Subcharacteristic and Attribute classes whhich represent the ISO 25000 (S SQuaRE) [7] hierarchical quality decomposition structture for quality attributes. Thesee classes have three attributes which represents the naame, description information, an nd the stakeholder’s perspective. Different categoriess of stakeholders have their ow wn quality perspective signifying that the particular sett of quality characteristics variees according to the stakeholders’ different categories (ee.g., maintainability is perceived d by the software engineer whereas time behavior is pperceived by the end users). The T Attribute class has an additional attribute, checkedd to represent the selection mad de by the software engineer. The quality model contains the complete ISO attribute deccomposition and the domain expert can choose a subseet of those quality attributes thatt are relevant for a given domain to define the Transform mations Model (see Section 3.2). We use an extensible and standard-based quality moodel in order to been capable to adapt this approach to multiple domains.

F 2. SQuaRE-based Quality Model Fig.

3.2 The Transformationss Model The transformations model represents the relationships among alternative transform mations and quality attributess (trade-off analysis results) in a given domain. The m most relevant classes of the correesponding metamodel are described in Figure 3. The Characteristic, Subcharacteristic, and Attribute classes are used to repressent the domain-specific subset of the quality model from Section 3.1. The domain exppert can also define new associaations among subcharacteristics and among attributes. The Attribute class has an a attribute for representing the AHP ranking of the quaality attributes obtained from thee trade-off analysis. The impacts between quality attribuutes and the relative importancee of these impacts (weight) are expressed by means of the Impact class. The Transforrmations Model also contains a StructuralPattern classs to represent the structural patterns in the source model that will be transformed iinto elements of the target modeel. A structural pattern is a subset of elements in the souurce model that has a transform mation definition. A transformation definition is definedd by the Rule class. In this transfformations model we include only those structural patteerns that have alternative transfformations (those structural patterns that have no alterrnatives are not related to quality attributes nor are they weighted since they must alw ways be executed). A structural pattern is defined by an id, name, and description. T The

Design Guidelines for the Development D of Quality-Driven Model Transformations

293

different alternative transfo ormations for a structural pattern are represented by the association between the Strructural Pattern class and the Alternative class. Finally, the transformatiion of a structural pattern using one alternative or anotther may have a different effect on the quality attributes of the target model. These effeects are quantified by the domaain expert during the trade-off analysis and are represennted in this metamodel by meeans of the Weight class, which is associated with the alternative and its respectiv ve quality attribute.

F 3. Transformations Metamodel Fig.

3.3 The Active Rules Mo odel The active rules model reprresents the information from the transformation rules whhich are eventually selected fro om among the alternatives through which to perform the transformation of the sourrce model. This model is generated automatically by the rules selection activity in th he first phase of the architecture. The corresponding metamodel shown in Figure 4 is composed of three classes, the ActiveRulesModel cllass which is a container class, the StructuralPattern class that represents the informattion concerning the structural patterns, p and the Rule class that represents the informattion concerning the selected tran nsformation rules.

Fig. 4. Active Rules Metamodel

4 Design Guidelines In this section, we introducce the design guidelines for defining model transformatiions that deal with alternatives based on quality attributes. The guidelines are definedd in

294

E. Insfran, J. Gonzalez-Huerta, and S. Abrahão

the context of a multimodeling approach to allow the quality information needed, which will drive the selection of the alternatives, to be obtained from a quality model and a transformations model. The application of these design guidelines will avoid hard-coding the quality information in model transformation definitions, thus improving the flexibility and maintainability of them. A model transformation definition contains transformation rules. Transformation rules are the units in which transformations are defined. A transformation rule is responsible for transforming a particular selection (structural pattern) of the source model into constructs of the target model. In this work, we deal with transformation rules as a specification of relations between elements in the left-hand and right-hand models [6] [4]. A transformation rule consists of two parts: a left-hand side (LHS) and a right-hand side (RHS). The LHS accesses the source model, whereas the RHS expands in the target model. The transformation process is controlled by matches. A match occurs during the application of a transformation when elements from the left-hand and/or right-hand model are identified as meeting the constraints specified by the declaration of a transformation rule. A match triggers the creation (or update) of model elements in the target model, and is driven by the declarative and/or implementation parts of the matched rule [6] [4]. The design guidelines are organized as follows: i) identifyingandselecting alternative transformation rules; ii) refactoring of transformation rules; iii) defining transformation rules; iv) analyzing transformation rule conflicts; and v) defining the transformations model. These guidelines are illustrated with the graphical QVTrelations notation. However, they can also be applied in any other transformation language (e.g., ATL) by defining the correspondences among concepts. 4.1 Identifying and Selecting Alternative Transformation Rules In order to identify alternative transformations it is first necessary to identify whether a structural pattern in the source model can be transformed into different structural patterns in the target model by applying different (alternative) transformation rules. The behavior of the transformation process will be different, depending on whether or not alternative transformations exist. Rules which do not form part of any alternative transformation are treated as usual in the transformation process. However, those transformation rules that are alternatives for a given structural pattern need to be weighted with regard to quality attributes to determine which alternative transformation produces the structural pattern in the target model that best satisfies, under the point of view of the domain expert, the required quality attributes. These alternative transformation rules may therefore need to be refactored in order to use them in our multimodeling architecture. 4.2 Refactoring of Transformation Rules The need to refactor transformation rules arises from the fact that the size of the structural patterns on the left-hand side of the transformation rules should be kept as small as possible to maximize cohesion and minimize coupling. Large and complex transformation rules will have less flexibility (and reusability) and their relationships with quality attributes will be more difficult to establish. Complex transformations may be defined by composing two or more existing transformation rules. The composition of

Design Guidelines for the Development of Quality-Driven Model Transformations

295

transformation rules requires proper modularity constructs and compositional operators within a single transformation language [2]. 4.3 Defining Transformation Rules A transformation could be declaratively defined as a relation among models. Relations in a transformation declare constraints that must be satisfied by the elements of the participating models. A relation is defined by two or more domains, preconditions, and post-conditions that specify a relationship that must hold between the elements of participating models [12]. The precondition specifies the conditions under which the relationship needs to hold. The post-condition specifies the condition that must be satisfied by all model elements that participate in the relation. In our approach, a model transformation definition contains two kinds of rules: top-level transformation rules and non top-level transformation rules, similar to the classification performed in the QVT-relations language [12]. Existing alternative rules in the transformation definition will be modified to become non top-level transformation rules, and a new top-level rule will be added for each structural pattern with alternative transformations. The alternative rules will never automatically match; they will be called from the new top-level rule which will perform the transformation based on the information in the active rules model. Top-level transformation rules. The alternative transformations are dealt with by performing a transformation composition [2] of the alternative transformation rules. Figure 5(a) shows an example of a generic top-level transformation rule for alternative transformations using the graphical QVT-relations notation [11].

Fig. 5. A generic top-level and non-toplevel with the QVT graphical notation

296

E. Insfran, J. Gonzalez-Huerta, and S. Abrahão

The set of all the alternative transformation rules for a given structural pattern are grouped into a new top-level transformation rule. This top-level transformation rule defines the common structural pattern among all the alternatives in the source model (see Figure 5(a1)). The structural pattern in the active rules model defines the association between the name of the alternative and the various nontop-level rules that create or update the corresponding particular constructs in the target model (see Figure 5(a2)). The post-condition of the top-level transformation rule deals with the invocation of the corresponding alternatives represented as nontop-level rules (see Figure 5(a4)). Preconditions may be needed to describe constraints that must hold in order to execute this transformation rule (see Figure 5(a3)). Non top-level transformation rules. The constructs created or updated in the target model are specified by the non top-level transformation rules. These consist of a lefthand side that defines the structural pattern in the source model and a right-hand side that describes the constructs in the target model. Preconditions may be needed to describe constraints that must hold in order to execute this transformation rule. Figure 5(b1) shows the structural pattern definition in the source model. Figure 5(b2) shows the constructs in the target model, and Figure 5(b3) shows a precondition using the when clause. 4.4 Avoiding Conflicts among Rules When dealing with transformation rules, one of the problems that might arise is the conflict among rules. A conflict appears when an structural pattern in the LHS of a transformation rule overlaps with an structural pattern in the LHS of any other transformation rule. The application of our two-phase architecture reduces the number of possible conflicts, due to the selection among alternatives performed in the first phase. We define the granularity of a transformation rule as the size of structural pattern in the LHS of the transformation rule. A transformation rule has higher granularity if its structural pattern covers a larger portion of the source model. The theoretical idea for solving the granularity issue is to define a high-order relationship (hereafter HOR function), which assigns a value to each transformation rule based on the number of entities covered by the structural pattern defined in the domain of the source model. This also reduces the ambiguity of the whole transformation process. In a Term Rewriting System R, an overlapping can be defined as follows: Given two rules, R1 and R2 R, l1 r1 and l2 r2they overlap if there exists almost one non-variable instance u of l1 (or l2) such as l1/u (alternatively l2/u) unifies with l2 (alternatively with l1) [5]. If we consider the transformation rules as a term rewriting system, then we can reduce the possible ambiguity among rules by incorporating a high-order relationship. Using the example described in Figure 5(a) as TopRelation1 we could have another rule (TopRelation2) defined on a structural pattern that includes the structural pattern of the TopRelation1. (2) Therefore, when an aEntity and bEntity in the source domain of TopRelation1 are found in the source model (see Figure 5(a1)), and if the entities defined in the

Design Guidelines for the Development of Quality-Driven Model Transformations

297

structural pattern of the TopRelation2 are also found in the source model, only TopRelation2 will be executed, and TopRelation1 will fail due to the precondition shown in Figure 5(a3). This precondition is defined by means of a query. A query is an expression that is evaluated over a model. The result returned by a query is one or more instances of types defined in the model, or defined by the query language [6]. Executing a query can be considered as a specific transformation task, since it only returns elements from the model or entities defined by the query language. This query evaluation verifies the presence of the whole LHS of another rule that has a larger value in the HOR, and this query is therefore evaluated as true, causing the precondition of TopRelation1 to be evaluated as false, and that it cannot consequently be executed. 4.5 Building the Transformations Model The transformation model represents the associations among structural patterns with alternative transformations, their corresponding alternative transformation rules, and their impacts on different quality attributes. The structural patterns with alternative transformations are created as instances of the StructuralPattern class, the alternative transformations for each structural pattern are created as instances of the Alternative class, and all the alternative rules are created as instances of the Rule class. In addition, each rule is associated with the corresponding alternative transformation. Finally, the results of the trade-off analysis among quality attributes are used to build the transformations model. This information includes the definition of quality characteristics, subcharacteristics, and attributes, which are identified as relevant by the domain expert and the association among alternative transformations and those quality attributes by means of instances of the Weight class.

5 Case Study This section presents the use of the design guidelines in developing quality-driven model transformations. In order to illustrate the design of transformations that deal with alternatives based on quality attributes, we show an excerpt of a case study which was conducted to transform UML class models into XML schemas. This section follows the same steps used to present the design guidelines in Section 4. 5.1 Identifying Alternative Transformations Transforming UML class models into XML Schemas has many possibilities depending on the preferences and point-of-view of the transformation designer. Owing to space constraints we shall focus only on one specific structural pattern with alternative transformations. This structural pattern in the UML source model is the inheritance, and it is composed of two classes and the inheritance relationship between them. In the target model, this structural pattern can be represented as (at least) three different XML Schema structures: •

Alternative 1 (InheritToSupCxType): to represent the inheritance as a unique complex type with the name of the superclass, including the attributes of both the superclass and the subclass in addition to one additional attribute for the kind of object.

298

• •

E. Insfran, J. Gonzalez-Huerta, and S. Abrahão

Alternative 2 (InheritTo2CxType):to represent the inheritance as two complex types: the first with the name and attributes of the superclass; and the second with the name and attributes of the subclass. Alternative 3 (InheritToSubCxType):to represent the inheritance as a complex type, with the name of the subclass and the attributes of both the superclass and the subclass.

These transformations will be selected as alternative transformation rules to be redefined according to our design guidelines. 5.2 Rule Refactoring The transformation rules may be refactored in order to allow the reuse of these rules by the different alternative and non-alternative transformations. For example, a set of alternative transformations could be initially implemented as only one atomic transformation rule. This atomic transformation rule will have low flexibility (and reusability) as a result of its low cohesion. Its relationship with quality attributes will also be difficult to establish. As a solution, we suggest that every alternative should be split into at least one different transformation rule. 5.3 Top-Level and Non-top Level Rule Definition A single top-level transformation rule must be defined by grouping all the alternatives for a given structural pattern. This top-level transformation rule for the inheritance structural pattern of our case study (simpleInheritance) has three domains: the source model domain which describes the two classes and the inheritance relationship, the active rules domain which describes the inheritance pattern, and the target model domain with the common structures among the alternatives to create constructs in the target model. The preconditions define the conditions under which this transformation rule can be executed (a UML class model must be previously transformed into an XML Schema) and other clauses to avoid conflicts among rules. The postconditions of this rule are the calls to the specific non-top level rules that perform the corresponding alternative transformations. The three non top-rules responsible for performing the alternative transformations are: InheritToSupCxType InheritTo2CxType, and InheritToSubCxType.

Fig. 6. Excerpt of a top-level transformation rule in the QVT-Relations syntax

Design Guidelines for the Development of Quality-Driven Model Transformations

299

InheritToSupCxType for Alternative 1 creates a class with the attributes of both classes. InheritTo2CxType for Alternative 2 creates two independent classes, the first with the name and attributes of the superclass and the second with the name and attributes of the subclass. Finally,InheritToSubCxType for Alternative 3 creates a class with the name of the subclass and the attributes of both classes. In order to design the different alternative transformations, non top-level transformation rules must be defined by following the principles of coupling and cohesion. Figure 6 shows an excerpt of the simpleInheritance transformation rule. 5.4 Conflict Avoidance To avoid conflicts among rules, we apply an implementation of the high-order relationship concept defined in Section 4.4 (HOR function). The application of this concept, allow us to detect that there is a conflict between the inheritance structural pattern and the non-inheritance structural pattern, which is composed of a class with no inheritance relationships. This conflict is caused by the fact that the noninheritance structural pattern is included in the inheritance structural pattern. In order to avoid this conflict we define a query in the precondition clause of the smaller structural pattern (non-inheritance structural pattern) to ensure that only the larger structural pattern will be executed. 5.5 The Transformations Model The first step in the definition of the transformation model is that of defining the characteristics, sub-characteristics, and attributes identified as relevant by the domain expert (a subset of the quality model). In this case study, we focus on the maintainability, which is defined as the capability of the software product to be modified. Modifications may include corrections, improvements or adaptation of the software to changes in the environment and in requirements and functional specifications [7]. The structural complexity of an XML schema affects its maintainability: the more complex the schema is, the more difficult it is to maintain it. The flexibility is defined as the ease with which the XML schema can cope with business and/or regulatory change [13]. Another quality attribute to be considered is flexibility, which is defined as the ease with which a given element can cope with business and/or regulatory changes [9]. These quality attributes are ranked by the domain expert in the trade-off analysis. The results of this ranking are represented in the rank field of each attribute. The next step is to deal with alternative transformations regarding the selected quality attributes. The inheritance structural pattern has three alternative transformations. Each alternative transformation is weighted for each quality attribute in the trade-off analysis. The normalized values are then stored as instances of the Weight class in the Transformation Model, as is shown below: • • •

Alternative 1 has a weight of 0.8 associated with the maintainability attribute. Alternative 2 has a weight of 0.7 associated with the flexibility attribute. Alternative 3 has a weight of 0.4 associated with the flexibility attribute and a weight of 0.5 associated with the maintainability attribute.

300

E. Insfran, J. Gonzalez-Huerta, and S. Abrahão

5.6 Applying the Transformation This subsection shows an application of our design guidelines to a concrete UML class model to generate different XML Schema models according to different quality attributes. We use one UML class model from the specification of a Library Management System. Figure 7 shows the classes and relationships for the classification of a LibraryItem. It consists of a superclass that defines the common properties of the LibraryItem and three subclasses: Book, DVD, and Journal. DVD

LibraryItem +Tittle +Year +Notes

+Publisher +genre

Book

Journal +ISBN +Number +Number +Editor +Date

+ISBN +Editor +genre

Fig. 7. UML class model for the Library Item classification

By following our approach for quality-driven model transformations and applying the defined design guidelines, we obtain the following outputs: • • •

the quality model, including the information of quality attributes, the transformation model, including the information regarding selected quality attributes and alternative transformation rules. These rules were identified and appropriately weighted by a domain expert (a librarian), the active rules model, which contains only those alternative transformation rules that best deal with the desired quality attributes.

Fig. 8. Alternative Target Models

Design Guidelines for the Development of Quality-Driven Model Transformations

301

Given the three identified alternatives (see Section 5.1): InheritToSupCxType, InheritTo2CxType, InheritToSubCxType, three different target models can be obtained depending on which specific alternative transformation rule is selected. These alternative transformations rules were weighted by a domain expert (a librarian) according to the quality attributes in the trade-off analysis. In this case study, we consider the maintainability and flexibility quality attributes as indicated in Section 5.5. If the desired quality attribute is maintainability then the selected alternative transformation rule will be Alternative 1 (InheritToSupCxType). The resulting target model is shown in Figure 8(a). If the desired quality attribute is flexibility then the selected alternative transformation rule will be Alternative 2 (InheritToSupCxType). The resulting target model is shown in Figure 8(b). Finally, if the desired quality attribute are both maintainability and flexibility then the selected alternative transformation rule will be Alternative 3 (InheritTo2CxType). The resulting target model is shown in Figure 8(c).

6 Conclusions and Further Work This paper has presented design guidelines for the development of quality-driven model transformations. The guidelines have been proposed in the context of a multimodeling approach that uses a quality model for expressing quality attributes and a transformations model for expressing the relations between alternative model transformations and their impact on quality attributes. The approach allows the transformation designer to incorporate quality attributes as a decision factor in the selection of alternative transformations. The feasibility of the approach has been illustrated through a case study which transforms UML class models into XML schemas. We have focused on a set of alternative transformation rules for inheritance relationships between classes. We have also discussed how the selection of each alternative affects the quality of the target models, specifically with regard to their maintainability and flexibility. This case study has allowed us to fine-tune the design guidelines, which are currently being applied in order to develop a set of transformations rules to obtain UML class diagrams from requirements specifications. We believe that the adoption of this approach will improve the current model transformation practices since it provides guidelines for the software engineer on how to design transformations where alternatives exist. Quality is therefore introduced early on the design of the transformation process as a decision factor for selecting transformation rules, thus improving the current practices in which quality evaluation is often conducted as a separate activity once a model has been transformed. As future work, we plan to apply the guidelines to other domains and to build a wizard in the Eclipse environment to help designers in the definition of the alternative transformations using our multimodeling architecture. We also plan to empirically validate the effectiveness and ease of use of these guidelines with students from a Software Engineering Masters’ course at the Universidad Politécnica de Valencia in Spain. We also plan to define and validate metrics for measuring the quality of the generated target models in order to provide feedback. This can be achieved byupdating the weights for the alternative transformations at run-time using information of the target models being produced.

302

E. Insfran, J. Gonzalez-Huerta, and S. Abrahão

Acknowledgments. This research is part of the MULTIPLE project (with ref. TIN2009-13838), and the CALIMO project (with ref. GV/2009/103).

References 1. Al-Naeem, T., Gorton, I., Ali Babar, M., Rabhi, F., Benatallah, B.: A QualityDrivenSystematic Approach for Architecting Distributed Software Applications. In: Proceedings of International Conference onSoftware Engineering ICSE 2005, pp. 244–253 (2005) 2. Belaunde, M.: Transformation Composition in QVT. In: First European Workshop on Composition of Model Transformations (CMT), Bilbao, Spain (2006) 3. Boronat, A., Knapp, A., Meseguer, J., Wirsing, M.: What is a Multi-Modeling Language? In: Corradini, A., Montanari, U. (eds.) WADT 2008. LNCS, vol. 5486, pp. 71–87. Springer, Heidelberg (2009) 4. Czarnecki, K., Helsen, S.: Feature-based Survey of Model Transformation Approaches. IBM Systems Journal 45(3), 621–645 (2006) 5. Dershowitz, N., Jouannaud, J.P.: Rewrite Systems. In: van Leeuwen, J. (ed.) Formal models and semantics. Handbook of Theoretical Computer Science, vol. B, pp. 243–320. Elsevier/ The MIT Press, Amsterdam (1990) 6. Gardner, T., Griffin, C., Koehler, J., Hauser, R.: A Review of OMG MOF 2.0 Query/Views/Transformations Submissions and Recommendations Toward the Final Standard. In: OMG Document, Object Management Group, ad/03-08-02 (2003), http://www.omg.org/cgi-bin/doc?ad/03-08-02 7. International Organization for Standardization ISO/IEC.: Software engineering Software product Quality Requirements and Evaluation SQuaRE (2005) 8. Kurtev, I.: Adaptability of Model Transformations. PhD Thesis. University of Twente, Twente, the Netherlands (2005) 9. Lammel, R., Kitsis, S., Remy, D.: Analysis of XML Schema Usage. In: Conference Proceedings XML, Atlanta, Georgia, USA (2005) 10. Merilinna, J.: A Tool for Quality-Driven Architecture Model Transformation. PhD thesis. VTT Technical Research Centre of Finland, Vuorimiehentie, Finland (2005) 11. MDA Guide Version 1.0.1. http://www.omg.org/cgi-bin/doc?omg/03-06-01.pdf 12. Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification (2003) 13. Šumak, B., Hericko, M., Pušnik, M.: Towards a Framework for Quality XML Schema Evaluation. In: Proceedings of the 29th International Conference on Information Technology Interfaces, Cavtat, Croatia (2007)

Early Deviation Detection in Modeling Activities of MDE Processes Marcos Aur´elio Almeida da Silva1, , Reda Bendraou1, Xavier Blanc1 , and Marie-Pierre Gervais1 LIP6, UPMC Paris Universitas, France

Abstract. Software Process Models (SPM) are used to communicate around the processes and analyze it. They represent the entry point to PSEEs (Process-centered Software Engineering Environments) which use them to coordinate process agents in their tasks. When the process execution doesn’t match the model, the common option in PSEEs is ignoring the model. If the actions of the agents are not tracked during deviations it is impossible to evaluate the effect of these deviations on the success or failure of the process. In this paper we propose to deal with agent deviations during process execution. The originality of our approach comes from the fact that it is Process Modeling Language’s (PML) independent and that it proposes early deviation detection. We validate our approach by implementing a prototype of a process definition and execution environment and evaluating its effectiveness to a group of developers enacting a process defined in it.

1

Introduction

A Software Process Model (SPM) represents the set of partially ordered steps, with sets of related artifacts, human and computerized resources, that intend to produce and maintain software deliverables [1]. SPMs are extensively used to communicate around the process and to analyze it. Moreover, they represent the entry point to PSEEs (Process-centered Software Engineering Environments) which use them to coordinate process agents in their tasks and to automate the process’ non-human routines. During process execution, the agents follow the instructions of the PSEE, perform some creative actions for delivering or modifying artifacts, and then submit their outcomes to the PSEE in order to be routed to the next process’ step. The process model and the PSEE serve then as means to enforce and to ensure that the agents are strictly following the process. However, what are PSEEs supposed to do during the process execution if the agents are not following the process model? Currently, they have the choice between: (i) stopping the execution, allow the process modeler to modify the process model and restarting it again; (ii) allowing 

This work was partly funded by ANR project MOVIDA Convention N◦ 2008 SEGI 011.

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

304

M.A. Almeida da Silva et al.

the process modeler to modify the process model on the fly and then continuing its execution; or (iii) continuing the process execution ignoring the process model and therefore providing no support to the agent. Obviously, restarting the process execution is not the ideal option since some processes may span months and restarting them would be just unproductive. Besides, on the fly process evolution [2] has been proven to be effective when coping with major process deviations but unsuitable in situations that require minor, temporary deviations from the process model [3]. In this case, ignoring the process model remains the only option. Unfortunately, if the agent works in complete contradiction with the process model, it is impossible to evaluate the effect of these deviations on the success or failure of the process. Moreover, in case of critical deviations, there are no means to prevent the agent from a blocking state or to propose solutions in order to reconcile the agent with the process. The deviation is then a fatal issue for the process continuity. Whatever the process model, it yet would be too restrictive to assume that the process is fixed, immutable and that it anticipates all possible situations. Thus, instead of forcing agents to follow a potentially sound process, a better solution would be to provide PSEE with the necessary flexibility for dealing with deviations. In this paper we propose to deal with agent deviations by: (i) providing process agents the ability to perform their activities even though that may cause deviations inside the control of the PSEE; and (ii) tracking agent’s deviations and warning him/her with possible ways to avoid them. The originality of our approach comes from the fact that it is Process Modeling Language’s (PML) independent and that it proposes early deviation detection, i.e. the PSEE follows each agent’s step in its affected activity and will warn her/him immediately in case of a deviation. In the next section we start by demonstrating main issues for detecting deviations in modeling activities and in Section 3, we give the requirements for the realization of a support environment to handle them. Section 4 presents Praxis and Praxis Rules, our building blocks for detecting and handling process deviations. In Section 5 we validate our intuition through a presentation of our tool and the results of some experiments we achieved in the context of this work. Section 6 gives the related work. Section 7 discusses the outcome of our results and concludes this work by sketching some perspectives.

2

Issues in Detecting Deviations in Modeling Activities

In the context of an MDE development process, many of project deliverables are models [4]. These models are either generated from other models through some automated transformation, composition or refactoring operations or represent the outcome of a manual modeling activity performed by a human. Whatever the kind of the activity (automated or manual) performed for producing these deliverables, it should appear in the process model. In the case of automated activities, they are modeled as a call to an external tool or a

Early Deviation Detection in Modeling Activities of MDE Processes

305

script with some inputs and optionally configuration parameters. At process execution time, the PSEE executes the activity by providing the required inputs, by performing the call, and by routing the outputs to the next process’s activity. Conversely, in the case of manual activities, they are often modeled using a sequence of steps, each step representing a narrative description in natural language of what the agent is expected to do. It represents more a guidance than an automated support for the agent. The agent becomes then the unique responsible of the model accuracy s/he is producing. Her/his unique interaction with the PSEE comes down to simply indicating when s/he starts the activity and by submitting the outcome model when s/he finishes the activity. In the current state of the art of PSEEs [5,6,3,7], these interactions represent the only way of supporting manual modeling activities. After the completion or the starting of an activity, the PSEE performs a structural check on the delivered models and artifacts in order to verify some structural constraints, usually in the form of post or pre-conditions [8]. However, current PSEEs provide no means to verify if the agent is following the appropriate modeling actions and constraints during the model construction as expected by the process modeler, i.e. they lack a behavioral check. Since these modeling actions are performed outside the control of the PSEE, it is impossible to detect precisely when the agent is deviating. Example 1. Let us imagine a simplified design process that consists of three activities: 1. Use case modeling: in this activity the developer should gather the requirements and build a use case model of the system. 2. Class diagram modeling: in this activity, the developer should build a class diagram with the help of a requirements document and the use cases s/he described in the previous activity. 3. Apply design pattern: in this activity, the developer should refactor the class diagram s/he built in the previous activity in order to apply a specific design pattern to it. Given the current PSEEs, it would be possible to validate the artifacts produced after the completion of the above cited activities. PSEEs mainly perform structural checks. They check that that the produced UML models are in conformance with their respective metamodels, i.e., that contain only instances of the expected metaclasses. However, they do not provide means to detect deviations, e.g., the modification of the use case diagram during the creation of the class diagram or the creation of an activity diagram when the agent should be defining a use case diagram. It would be harder to check if the agent is applying the design pattern properly and that s/he is creating the appropriate classes, operations or associations. Moreover, some modeling operations require a precise order. Having a simple structural check on models at the end of the activity is clearly not enough. It would not warn the agent when s/he is

306

M.A. Almeida da Silva et al.

actually deviating but simply tell her/him at the end of the activity that the model is not well-formed.

3

Requirements and Architecture for Process Deviation Detection Environments

In order to provide an early deviation detection support for modeling activities we identified the following requirements: Requeriment 1. Each action performed by an agent must be traced, since it may be a cause of deviation. Requeriment 2. A check must be applied to the traced actions in order to detect potential deviations. From these requirements, we propose the architecture of a Process Deviation Detection Environment. Such architecture comes in form of three components: The Process Execution Engine (PEE): it is responsible for executing the process model. It takes as input the process model and ensures that activities are properly sequenced, that roles are assigned and that artifacts are correctly routed. The PEE is also aware of all process’s activity states i.e., executing, finished, ready to start, etc. The Modeling Action Listener (MAL): it is responsible for providing the traces of modeling actions performed by the agent to build the model. Using the PEE and the MAL we are able to check what the agent is actually performing within each modeling activity and the position of the activity in the process. The MAL has to be integrated to the modeling tool used by the developers in order to capture modeling action traces and to the PEE in order to gather information that is important to detecting deviations, e.g. the initial timestamp of the current activity. In our approach, these traces are represented using our formalism Praxis which is presented in the next section. The Deviation Detection Engine (DDE): This is the building block of our approach. It checks if the agent is deviating from the process model. At this aim, the DDE uses the traces of agent’s modeling actions captured by the MAL, the information given by the PEE about the activity being executed and the description of the allowed actions within the activity, provided in the process model. While in current approaches activity’s allowed actions are given in natural language, we promote the use of modeling rules. These rules are expressed using a Rule Description Language (RDL) and serve as input to the DDE for detecting agent’s deviations. These rules are not only used to describe the allowed actions within the activity but also structural constraints on the delivered model. Thus, the DDE performs a double check. The first one concerns the continuous verification of agent’s actions while s/he is performing the activity. The second one checks at the end of the

Early Deviation Detection in Modeling Activities of MDE Processes

307

activity that the delivered model is well-formed. For rule descriptions, we defined a RDL named Praxis Rules. Praxis rules can be used independently of any PML.

4

Praxis and PraxisRules

As stated earlier, Praxis and Praxis Rules are the building blocks of our approach. Praxis is used to represent each of the elementary modeling actions performed by the agent for building a model. This representation comes in the form of an editing action [9]. Thus, a model construction is represented as a sequence of Praxis editing actions. In order to check if the agent is performing the right actions or if the model s/he is delivering is free of inconsistencies, we apply Praxis Rules on top of this sequence. If the agent is deviating or if the model is not well-formed, a warning is triggered. In the following section, we introduce Praxis. Praxis Rules is presented in Section 4.2. 4.1

Praxis

Figure 1 presents a UML model whose Praxis representation is displayed in Figure 2. This model contains a package called Azureus that owns two classes: Client and Server. The Server class defines an operation called send(). In Praxis, each editing action is annotated with a timestamp which indicates the moment when it was executed by the user. The actions are inspired by the MOF reflective API [10]. The create(me, mc, t) and delete(me, t) actions respectively create and delete a model element me, that is an instance of the meta-class mc at the timestamp t. The addP roperty(me, p, value, t) and remP roperty(me, p, value, t) add or remove the value value to or from the property p of the model element me at timestamp t. Similarly, the actions create(p1,package,1) addProperty(p1,name, ‘Azureus’,2) create(c1,class,3) addProperty(c1,name, ‘Client’,4)) create(c2,class,5) addProperty(c2,name,‘Server’,6) addReference(p1,ownedMember,c1,7) addReference(p1,ownedMember,c2,8) addReference(p1,ownedElement,c1,9) addReference(p1,ownedElement,c2,10) create(o1,operation,11) addProperty(o1,name, ‘send’, 12) addReference(c2, ownedProperty, o1, 13) addReference(c2, ownedElement, o1, 14) Fig. 1. Sample UML model

Fig. 2. Model construction operation sequence

308

M.A. Almeida da Silva et al.

addRef erence(me, r, target, t) and remRef erence(me, r, target, t) add or remove the model element target to or from the reference r of the model element me at timestamp t. In Figure 2, the action at timestamp 1 creates the package p1. The second action sets its name to Azureus. The actions with the timestamps 3 and 4 and those with the timestamps 5 and 6 create the classes c1 and c2 and set their names to Client and Server respectively. The actions with the timestamps from 7 to 10 state that both classes are owned by the package p1. The actions with the timestamps 11 and 12 create the operation o1 whose name is send and the actions with timestamp 13 and 14 add it to the class c2. 4.2

PraxisRules

Praxis Rules is a rule-based logical language we defined in order to specify activity’s allowed actions in a process model. It is also used to specify the structure and constraints of the expected output models of an activity. The PSEE uses Praxis Rules to perform both structural and behavioral checks on the process execution and its deliverables. In Figure 3 we present a simplified version of its metamodel1 .

Fig. 3. PraxisRules Metamodel

Definition 1 (Activity Post-condition Rule). An activity post-condition rule is a rule whose objective is verifying a structural pattern in the model sequence. The Activity Post-condition Rules are the logical rules used in order to verify structural properties. They are represented by the metaclass Rule in Figure 3. Such rules represent formulae that identify patterns in the sequence of Praxis 1

The complete metamodel can be found at the deliverable D2.1 of MOVIDA ANR project, http://movida.gforge.inria.fr.

Early Deviation Detection in Modeling Activities of MDE Processes

309

editing actions. Composite formulae represent logical connectives such as and, or and not over atomic formulae. The most important atomic formulas are represented by the P raxisQueries. They represent operations on the sequence of editing actions. Example 2 (Activity Post-condition rule). Let us for instance analyse the following rule: createModelPackagePost() <=> and { create(P, #package), addProperty(P, #name, "Model") }. The name of this rule is createM odelP ackageP ost. It checks if there exists a package called “Model” in it. In the context of a process, this rule verifies the post condition of an activity that creates such package. Syntatically this rule is described as a query that is a composite formula that is a conjunction of two atomic formulas. The atomic formula create(P, #package) searches for the creation of a package in the model sequence and matches the identifier of the package being created with the variable P. The atomic formula addProperty(P, #name, "Model") searches for the last addition of a value to the name property of the element P . This operation should add the value “Model” to that property. In case of instance when an agent is applying the MVC pattern, such a rule can enforces the fact the model should at least contains the three packages named “Model”, “View” and “Controller”. The same thing can be applied for instance for specifying the necessity of having a method called “getInstance()” when an agent is applying the Singleton pattern [11]. This example is quite simple but of course, more complicated constraints can be expressed using this language. Definition 2 (Activity Invariant Rule). An activity invariant rule is a temporized rule that; taking the whole activity as an event optionally composed of other events of lower granularity; decides if an operation is allowed or not in it. The second kind of rules we use in our approach is called Activity Invariant Rules. They are used to perform behavioral checks i.e., to validate the operations performed by the agent during the execution of an activity. As a complement to the purely first order logical rules we define the metaclass Temporized Rules (c.f. Figure 3) which describe events in the model construction history. For example, the event “Class c is renamed to d” is an abstract description for an operation addProperty(c, name, d) in the model sequence. Events may also represent a set of closely related operations. For example, the event “Class c is moved from package p to package q” involves at least two operations: an operation remReference(p, member, c) followed by an operation addReference(q, member, c), namely, the removal of c from p and the addition of c to q. Notice that in this specific example we need to be able to detect the correct order of the actions. More generally, in such situations we need to be able

310

M.A. Almeida da Silva et al.

to reason about the order of events. That is why we defined the temporal formulae (metaclass T emporalF ormula). These formulae allow us to describe five different order relations among events: – bef ore{e1 , e2 }: the event e1 happens before the event e2 in the model sequence; – af ter{e1 , e2 }: the event e1 happens after the event e2 in the model sequence; – f irst{e}: the variables in formula e match to the first time such event happens in the model sequence; – last{e}: the variables in formula e match to the last time such event happens in the model sequence; – between{e1 , e, e2 }: the event e happens after the event e1 and before the event e2 in the model sequence. Example 3 (Activity Invariant Rule). Let us take the following activity invariant rule as a concrete example: createModelPackageInv() @ operation <=> or { operation @ create(P, #package), and { create(P, #package), or { operation @ addProperty(P, Prop, Val), operation @ remProperty(P, Prop, Val), operation @ addReference(P, Ref, Elem), operation @ remReference(P, Ref, Elem), operation @ addReference(Elem, Ref, P), operation @ remReference(Elem, Ref, P) } } }. This rule, called createM odelP ackageInv defined the activity invariant rule of an activity in which the agent should create a package. The @ operation part acts as a temporal variable for the operation executed by the agent and corresponds to the temporizer attribute in the metamodel. According to the rule, the operation executed by the agent (named operation) is either the creation of a package called P (represented by the action create(P, #package) or by one of the following six operations involving P : – addProperty(P, Prop, Val) or remProperty(P, Prop, Val): the modification of a property P rop of P ; – addReference(P, Ref, Elem) or remReference(P, Ref, Elem): the modification of a reference Ref from P to other model element Elem; – addReference(Elem, Ref, P) or remReference(Elem, Ref, P): the modification of a reference from a model element Elem to P ;

Early Deviation Detection in Modeling Activities of MDE Processes

311

It is important to note that the level of granularity of these rules may be fine tuned to give either a more descriptive or a more prescriptive flavor to the process. For example, we could have specified this activity invariant in different levels of abstraction: – Only an action create(P, #package) immediately followed by an action addProperty(P, #name, "Model") is allowed; – Only actions creating and modifying packages are allowed; – Only actions creating new elements and modifying elements during this activity are allowed. This means that even if the language is powerful enough to prescribe the order in which the actions may be executed in a very low level of abstraction, this level may be adjusted according to the objectives of the process modeler.

5

Validation

We validated our work in two steps: first, we implemented a prototype environment for process definition, execution and enactment. It follows the architecture and the requirements described in Section 3. Second, we carried out a case study with a group of developers of our university. They were asked to follow the process we present in Section 5.2 in order to evaluate our approach. 5.1

Prototype Implementation

As mentioned in Section 2, our approach is PEE, PML and modeling tool independent. As a validation step, we tested the approach using two different PEEs and PMLs. Firstly, we used UML4SPM, our PEE and PML [7,12]. We then used Eclipse Cheatsheets as a PEE [13] and UML2.0 Activity diagrams as PML [14]. In the following, we focus on the second experiment. We use our prototype Praxis environment as a MAL [9]. This tool was integrated with the Eclipse EMF-based tool called Papyrus UML2 Editor2 but any modeling tool could have been used. To check the actions and the structure of the model after the end of the activity, a DDE based on PraxisRules was implemented. All these components are integrated in a unique environment and interact with each other transparently. A process is deployed as an Eclipse plugin, which contains the Process Cheatsheet to be used by the PEE and the Process Activity Post-condition and Invariant rules to be used by the DDE. These artifacts are generated from the UML activity diagram that is used as process model. For each action in the activity diagram one step on the cheat sheet and two rules (an Activity Post condition and an Activity Invariant Rule) are generated automatically. Initially, these rules are empty and are supposed to be redefined by the process modeler. 2

http://www.papyrusuml.org/

312

M.A. Almeida da Silva et al.

Fig. 4. Our prototype environment running on top of Eclipse

In Figure 4 we show the enactment of a software process on top of Eclipse. On the left of the screen we see a UML model being edited; on the right we see the Eclipse cheatsheet containing the process (on the top) and the textual guidance for the current activity (on the bottom); on the middle of the screen we have the error message that is displayed everytime an action that is not allowed is found in the model sequence. It provides two options to the user: rollbacking the offending actions and continuing the process execution or ignoring the warning and proceeding anyway. 5.2

Case Study: A Process for Refactoring Models into MVC

In this section we present a case study of a process for refactoring any model into the MVC pattern as supported by Apple [15]. This pattern consists in separating the classes of the system in three packages; namely Model, View and Controller. The package View should contain the classes dealing with the graphical user interface; the package Model should contain the business classes of the application; and the package Controller contains the classes that manage the events generated by the interaction of the agent with the classes in the View and translate them into business requests. In the figure below we show the activity diagram that represents our process. It consists of 6 steps3 : 3

Notice that the process presented at this section does not intend to be a general solution for the MVC refactoring problem. Additionally, we do not claim that it is going to produce the most elegant solutions.

Early Deviation Detection in Modeling Activities of MDE Processes

313

1. createMVCPackages: at this step the agent should create three packages called Model, View and Controller ; 2. movePureModelClassesToModel: at this step the agent should move the classes that take only model responsibilities into the model package; 3. movePureViewClassesToView: at this step the agent should move the classes that take only view responsibilities into the view package; 4. movePureControllerClassesToController: at this step the agent should move the classes that take only controller responsibilities into the controller package; 5. extractMixedViewClasses: at this step, the classes that take mixed responsibilities between view and controller (namely by being a subclass of a view class and having controller responsibilities should be changed in order to avoid this problem. The solution proposed by our process is to replace the inheritance link by an association. The rationale of this change is to let the view responsibilities in the graphical class and the controller responsibilities in the other one; 6. moveAllRemainingClassesToController: at this step the agent should move the remaining classes to the controller package; The rules for monitoring and verifying this process were writen in PraxisRules. They consist of 29 rules (6 × 2 invariant and post condition rules plus 17 other rules). For the sake of brevity, we include here only the rules for the movePureModelClassesToModel activity (below). The whole set of rules can be found in http://meta.lip6.fr/?page id=183. movePureModelClassesToModelInv() @ action <=> and { action @ call moving(C, P), or { create(C, #class), create(C, #interface) }, or { create(P, #model), and { create(P, #package), addProperty(P, #name, "Model") } } }.

314

M.A. Almeida da Silva et al.

movePureModelClassesToModelPost() <=> not { and { call references(C1, C2), or { create(C1, #class), create(C1, #interface) or { create(C2, #class), create(C2, #interface) addReference(P, #ownedelement, C1), addProperty(P, #name, "Model"), addReference(PA, #ownedelement, AnotherClass), not { addProperty(PA, #name, "Model") } } }.

}, },

The first rule is the activity invariant rule for this activity. It states that only actions moving a class or interface C into a package P called “Model” are allowed. The second rule is an activity post-condition rule for the same activity. It states that there’s no pair of classes or interfaces C1 and C2 such that they reference one another, one of them is in the package P called “Model” and the other is not in it. Observe that moving(C,P) and references(C1,C2) are calls to other rules that are not described in this code snippet. The first one matches every action in the model construction sequence that represents that the class C is being moved from or to the package P . The second one represents that there is a reference between the classes C1 and C2 , e.g. C2 is the type of an attribute, operation or association of C2 . 5.3

Case Study and Prototype Evaluation

In order to assess the effectiveness of our approach we evaluated our case study and prototype environment with a group of 11 developers from the University Pierre & Marie Currie. They were randomly separated into two groups of 5 and 6 students. The first group (the process group) used our prototype environment in order to refactor a model with 16 classes into the MVC pattern by following the process introduced in Section 5.2. The second group (the control group) was supposed to do the same exercise without the help of our process enactment environment and to act as a control group. We hypothesized that the process group would perform its task faster and would produce better quality models than the control group. We measured the total time taken by each student to decide if s/he had finished the exercise. We also measured the quality of the final models by giving 0–20 “quality points” to each model. Results & Analysis: three students didn’t finish the exercise in the 1h10 time frame we gave to them, one in the control group and two in the process group. The students in the process group finished in 40min in average, while the ones in the control group took 55min to finish. In terms of quality, the process group averaged 14 points whereas the control group averaged 13 points. The process group was able to provide slightly better quality models (the averages differ in 1 point) faster than the control group (the averages differ 15min).

Early Deviation Detection in Modeling Activities of MDE Processes

315

We argue that this was achieved thanks to the guidance provided by the process and the ability of the enactment tool to warn the user when s/he deviated from the process model. We emphasize that the results of this study may not generalize to other groups of subjects neither to other processes.

6

Related Work

Early detection of deviations in process enactment is promptly available in artifact-centered process modeling languages [3,16]. These languages define a process as a set of artifacts, the set of possible abstract states of these artifacts and the editing operations that trigger the transitions between these states. The downside of this kind of approach is that every possible way of changing the artifacts should be documented in the process model. These languages also don’t include constructs for defining activities (i.e. a structured way of representing the agent’s work and the flow of artifacts). Our approach is built on top of a small and fixed set of possible change actions as provided by Praxis. Higher granularity operations may also be described by called rules. We also support complex activity flows by being completely independent of the process modeling language. Other works that allow the detection of deviations are based on activity centered process modeling languages [17,18,6]. In [17], Yang et al define a mapping from an activity language into a temporal logic, so that action traces expressed in that logic can be proven to follow or not the process model. Unfortunately, they leverage an “off-line” approach for this verification: the traces are not compared to the process model at runtime but at a later time, providing no guidance to the agents. Some other works do allow the verification of the process enactment at runtime [18,6]. However they are only able to describe the post-conditions of the activities, i.e. structural checks on the output models. Therefore, they are not able to provide any guidance to the agent during her/his activities. A major pitfall of such activity-centered process modeling languages lies on the fact that the only way to at least describe the lower level steps that the user is expected to execute for each activity is to refine the specification down to its lower details. This way, finer grained actions would appear as atomic steps in the activity diagram. However, as supported by Osterweil in [8], the more detailed is a process model, the less clean and understandable it will be. We argue that such details constitute in fact another viewpoint [19], in the sense that it requires looking at the process model from a different perspective. That’s why we leverage an approach in which these perspectives constitute two different models; one containing the execution perspective; i.e. which activities should be carried out, in which order and working on which artifacts; and one containing the guidance perspective; i.e. which information is needed in order to decide if the agents are or not respecting the process model and how to guide them otherwise.

316

7

M.A. Almeida da Silva et al.

Conclusion

To achieve a certain level of process maturity, organizations go through several and continuous iterations of process modeling, validation, execution and analysis steps. At the end of each iteration, the delivered software is analyzed, the costs and schedule are evaluated and, depending on the results, a set of improvement steps are possibly identified. However, these improvements assume that the agent has strictly followed the process model as prescribed by the PSEE and do not take into account agent’s actions performed outside the control of the PSEE. In case of unforeseen situations, agents have to deviate and perform actions that may have a considerable effect on the success or failure of the process. It is then crucial to provide PSEEs that capture all agent’s actions, even those deviating from the process description and to consider them not only for process improvements but also for preventing from a possible process blocking state. In this paper we introduced the requirements and architecture of such a PSEE. The building blocks of our approach are a rule description language called Praxis Rule and a rule checking engine. They provide the process modeler with the ability to describe structural constraints on the expected process’s deliverables as well as on the agent’s allowed actions while s/he is performing process activities. The originality of our approach comes from the fact that it offers early deviation detections to ensure process continuity and safety and that it is PML, PEE and modeling tool independent. To validate our approach, we first built a PSEE on top of Eclipse Cheatsheet and Praxis Rules and we used UML activity diagrams as a PML. Secondly, we realized a case study and an empirical evaluation to prove the effectiveness of our approach. This was done by submitting our tool and a process example to a group of developers in order to evaluate the impact of using our PSEE. The study demonstrated that they were able to use the tool to follow the process without any problems and we consider using our tool and approach in the two following cases. The first one is to use our tool as a possible means to continuously improve the process as described by the CMMI maturity levels. The second one is to provide organizations having the CMMI’s Defined Level or more the means to preserve their maturity level by preventing the agents for possible deviations during process enactment. As a perspective of this work we are currently studying the resolution of the optimal path to reconcile the agent with the process description in case late deviation detections i.e. the early deviation detection is turned off by the agent. We also plan to use our tool in an industrial context and to put in place a more important empirical study for validating our approach.

References 1. Lonchamp, J.: A structured conceptual and terminological framework for software process engineering. In: Proceedings of the Second International Conference on the Software Process, pp. 41–53. IEEE Computer Society Press, Los Alamitos (1993)

Early Deviation Detection in Modeling Activities of MDE Processes

317

2. Bandinelli, S.C., Fuggetta, A., Ghezzi, C.: Software process model evolution in the spade environment. IEEE Trans. Softw. Eng. 19(12), 1128–1144 (1993) 3. Cugola, G.: Tolerating deviations in process support systems via flexible enactment of process models. IEEE Trans. Software Eng. 24(11), 982–1001 (1998) 4. Schmidt, D.C.: Guest editor’s introduction: Model-driven engineering. Computer 39(2), 25 (2006) 5. Dami, S., Estublier, J., Amiour, M.: Apel: a graphical yet executable formalism for process modeling. Automated Software Engineering 5, 61–96 (1997) 6. Wise, A.: Little-jil 1.5 language report. Technical report, University of Massachusetts (2006) 7. Bendraou, R., Gervais, M.P., Blanc, X.: Uml4spm: A uml2.0-based metamodel for software process modelling. In: Briand, L.C., Williams, C. (eds.) MoDELS 2005. LNCS, vol. 3713, pp. 17–38. Springer, Heidelberg (2005) 8. Osterweil, L.J.: Formalisms to support the definition of processes. J. Comput. Sci. Technol. 24(2), 198–211 (2009) 9. Blanc, X., Mougenot, A., Mounier, I., Mens, T.: Detecting model inconsistency through operation-based model construction. In: Robby (ed.) Proc. Int’l Conf. Software engineering (ICSE 2008), vol. 1, pp. 511–520. ACM, New York (2008) 10. OMG: Meta Object Facility (MOF) 2.0 Core Specification (January 2006) 11. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns. Addison Wesley, Reading (1995) 12. Bendraou, R., J´ez´equel, J.M., Fleurey, F.: Combining aspect and model-driven engineering approaches for software process modeling and execution. In: Wang, Q., Garousi, V., Madachy, R., Pfahl, D. (eds.) ICSP 2009. LNCS, vol. 5543, pp. 148–160. Springer, Heidelberg (2009) 13. Tiedt, P.: Cheat sheets in Eclipse. IBM Developer Networks (August 2006) 14. OMG: Unified Modeling Language: Super Structure version 2.1 (January 2006) 15. Apple Inc.: Cocoa Design Patterns (2010) 16. Leonhardt, U., Kramer, J., Nuseibeh, B., Finkelstein, A.: Decentralised process enactment in a multi-perspective development environment. In: Proceedings of 17th International Conference of Software Engineering, pp. 255–264. ACM Press, New York (1995) 17. Yang, Q., Li, M., Wang, Q., Yang, G., Zhai, J., Li, J., Hou, L., Yang, Y.: An algebraic approach for managing inconsistencies in software processes. In: Wang, Q., Pfahl, D., Raffo, D.M. (eds.) ICSP 2007. LNCS, vol. 4470, pp. 121–133. Springer, Heidelberg (2007) 18. Kabbaj, M., Lbath, R., Coulette, B.: A deviation management system for handling software process enactment evolution. In: Wang, Q., Pfahl, D., Raffo, D.M. (eds.) ICSP 2008. LNCS, vol. 5007, pp. 186–197. Springer, Heidelberg (2008) 19. Finkelstein, A., Kramer, J., Nuseibeh, B., Finkelstein, L., Goedicke, M.: Viewpoints: A Framework for Integrating Multiple Perspectives in System Development. International Journal of Software Engineering and Knowledge Engineering 2(1), 31–57 (1992)

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

Abstract. CASE tools provide artifact guidance and process guidance to enhance model quality and reduce their development time. These two types of guidance seem complementary since artifact guidance supports defect detection after each iterative development step, while process guidance supports defect prevention during each such step. But can this intuition be empirically confirmed? We investigated this question by observing developers refactoring a UML model. This study attempted to assess how general were the observations made by Cass and Osterweil on the benefits of guidance to build such model from scratch. It turns out that they do not generalize well: while their experiment observed a benefit on quality and speed with process guidance (but none with artefact guidance), we, in contrast, observed a benefit on quality at the expense of speed with artefact guidance (but none with process guidance).

1

Introduction

CASE tools provide automated services that assist a development team to perform iterative artefact construction and revision more systematically, safely and efficiently. Two key classes of such services are artifact guidance and process guidance. The former assists developers to produce artifacts that conform to some structural pattern, while the latter assists them in following a step-by-step plan whose execution results in such pattern-conforming set of artefacts [6,11,2]. One key subclass of artifact guidance service is structural pattern violation detection and diagnosis [10,7,3]1 . One key subclass of process guidance consists of plan deviation detection and diagnosis [15]. Intuitively, these respective subclasses of artefact guidance and process guidance seem to bring complementary software quality gains, since the former focuses on defect detection after each iterative development step, while the latter focuses on defect prevention during each such step. But can this intuition be empirically confirmed? Do the two together provide a quantitatively significative improvement over each of them alone (and hopefully over no guidance whatsoever)? Beyond software quality,   1

This work was partly funded by ANR project MOVIDA Convention N◦ 2008 SEGI 011. This work was partly funded by the french DGA. Another one is violation repair suggestion [8,9].

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

Artifact or Process Guidance, an Empirical Study

319

what are their respective and combined effects on development speed? Is the time overhead involved in performing each of them alone or together clearly inferior to the time they allow saving through artefact defect prevention and quick correction? Cass and Osterweil [4] pioneered the investigation of these crucial questions through a first experiment in which 16 novice designers were asked to build from scratch a UML class diagram that conformed to the MVC architectural pattern[12]. The single quality metric used in this experiment was the degree of conformance of the diagram to this pattern, as graded by a group of specialists; and the single efficiency metric was the time spent building the diagram. These parameters were measured for four subject subgroups that respectively used no guidance, artifact guidance alone, process guidance alone and both guidance. This experiment yielded one expected result, that following process guidance alone significantly improved both the quality and efficiency metrics, and one unexpected result, that no significative effect was measured for artifact guidance on these metrics. In this paper, we report on an experiment that furthers the Cass and Osterweil’s research by trying to generalize their results. In order to be able to draw clear insights from our experiment, we designed it to differ from Cass and Osterweil’s by a minimum two controlled features. The first is the starting point of the experiment. We asked our subjects to refactor a given UML diagram that did not conform to the MVC pattern into one that does, instead of building a conform diagram from scratch. The second differing feature of our experiment is the process guidance that we provided to the subjects. This was an unavoidable consequence of the first, since a refactor process obviously differs from a construction one. We kept the other features of our experiment, such as the dependent and independent variables and the subject partitioning method, as similar as possible to those of the Cass-Osterweil experiment. While their experiment reported significant benefits for process guidance but no effect for artifact guidance, ours intriguingly reports completely different results: regarding artifact guidance, significant negative effect in terms of efficiency but no significant effect in terms of quality; regarding process guidance, no significant effect at all. It suggests that a lot more experimental research is needed before we can clearly determine which guidance is more beneficial under which circumstances. For our experiment, we followed the empirical experiment protocol defined in [14]. The rest of the paper follows the structure advocated by this protocol: Section 2 presents the definition and planning of the empirical study. Section 3 presents its instrumentation. Section 4 presents our concrete realization of this study and synthesizes our results. Finally, Section 5 we discuss our results before concluding in Section 6.

2

Experiment Definition and Planning

In this section, we define the experiment following Wohlin’s approach [14]. Section 2.1 briefly defines the goal of our experiment. Section 2.2 presents the

320

M.A. Almeida da Silva et al.

decisions we took when planning this experiment. Then section 2.3 presents the experiment null hypothesis. Finally, section 2.4 identifies potential threats to its validity. 2.1

Experiment Overall Definition

According to [14], an empirical study is essentially defined by five features: object(s), purpose, quality focus, perspective and context. The essence of any experiment can thus be summarized by a single sentence that briefly defines all five of these features. Definition 1 summarizes our experiment this way. Definition 1 (Goal of the empirical study). Analyze the refactoring of a UML class diagram to turn it conformant to the MVC pattern for the purpose of artifact and process guidance evaluation with respect to efficiency and quality from the perspective of a software architect and quality manager in the context of novice designers using a UML CASE tool. Each experiment feature is briefly elaborated below: Object: the object of this study consisted in refactoring a UML class diagram to make it follow the Model-View-Controller pattern[12]. Purpose: The general purpose of this empirical study was to measure whether or not process and artifact guidance do provide efficiency and quality benefits for developers. Quality Focus: This study considered that benefits provided by process and artifact guidance were efficiency and quality. Efficiency was measured as the time needed to complete the object. Quality was measured as the degree of conformance to the MVC design pattern. Perspective: The intent of this study was to be interpreted by a software architect and quality manager. These professionals have the skills necessary to define both kinds of guidance and to evaluate the result of their respective use. Context: The subjects were master students, at the end of their course. To refactor a UML class diagram into the MVC pattern, they used the UML CASE tool Papyrus [5], extended by three plug-ins that we implemented specially for the experiment. Our experiment had a single object carried out by multiple subjects. It can thus be classified as a muti-test within object experiment in the taxonomy of empirical studies [14]. 2.2

Experiment Planning

Object As there are many flavors of MVC patterns, we used the one popularized by Apple [1]. It requires the classes and interfaces of the model to be partitioned into three components: the Model, the View and the Controller. The model classes hold the persistent data structure of the system, the view classes hold the

Artifact or Process Guidance, an Empirical Study

321

visual elements of the GUI and the controller classes handle the events generated by user interaction with the view classes into calls to business code in the model. The pattern prohibits any direct coupling between model and view classes. All interactions between them must be mediated through controller classes that together also encapsulate the overall system’s control flow. We decided to take the input class diagrams to refactor from an implemented running application used as case study. This application is a toy maze game composed of 16 classes. We chose this particular example because, on the one hand, refactoring a significantly smaller system would be too simple. On the other hand, a significant bigger system would make the input diagram to suffer from another design defect, namely lack of cognitively manageable substructures, that is orthogonal to the focus of our experiment, namely non-conformance to an architectural pattern. It would thus have muddled the interpretation of our results. The input class diagrams violated the MVC patterns in various ways. It contained classes that grouped together features related to view and model aspects. It also contained direct dependencies between classes that only contained features related to view aspects and classes that only contained features related to model aspects2 . Purpose. We decided to specify the artefact guidance thanks to a set of inconsistency rules[3]. These rules (see Figure 1) enforce: (i) the presence of the correct packages in the expected pattern (rules 1–6); (ii) the fact that the classes in the model (respectively view) should not depend on classes outside of it (rules 7 and 8); (iii) the fact that graphical classes3 should be in the view package and that every class should be in one of the three packages (rules 9 and 10). 1. 2. 3. 4. 5. 6. 7.

The model should own exactly three packages. Nesting packages is forbidden. The Model package is missing. The View package is missing. The Controller package is missing. Empty packages are forbidden. Some class in the Model package references another class outside of this package. Only classes in the Controller package can reference classes outside of it. 8. Some class in the View package references another class outside of this package. Only classes in the Controller package can reference classes outside of it. 9. Some class is graphical and is not in the View Package. 10. Some class is not included in any package. All classes must be included in either the Model, View or Controller. Fig. 1. Artifact guidance 2 3

The complete set of artifacts used during this experimentation is available at http://meta.lip6.fr/?page id=186. To facilitate the identification of a graphical class by our subjects, who were all Java programmers, all these class in the diagram to refactor extended a class from one of Java’s graphical API.

322

M.A. Almeida da Silva et al.

We decided to specify the process guidance as a software process that subjects were asked to follow. Figure 2 represents this process. It consists of 6 tasks whose objective is (i) create the model, view and controller packages (task 1); (ii) move the classes that trivially belong to one of the packages to it (tasks 2–4) and then (iii) breaking the responsibilities between the classes that would belong to more than one package and then move the remaining classes to the controller (tasks 5–6). Notice that this process neither intends to be a general solution for this problem, nor will produce the most elegant solutions for it. 1. createMVCPackages: for this task, create three packages called Model, View and Controller ; 2. movePureModelClassesToModel: for this task, move the classes with pure model responsibilities (i.e., that represent persistent data and business rules) to the model package; 3. movePureViewClassesToView: for this task, move the classes with pure view responsibilities (i.e., that only contain GUI features) to the view package; 4. movePureControllerClassesToController: for this task, move the classes with pure controller responsibilities (i.e., that define the control and data flow between model and view classes) into the controller package; 5. extractMixedViewClasses: for this task, divide classes with mixed view and controller responsibilities into one class with pure view responsibilities and one class with pure controller responsibilities and link them an association (from the controller one to the view one); 6. moveAllRemainingClassesToController: for this task, move the remaining classes to the controller package; Fig. 2. Process Guidance

Quality Focus. We decided to measure the effects of the artefact and process guidance with respect to design time and quality. Where “design time” is a ratio variable measuring the time in minutes needed for a subject to carry out the refactoring. Regarding quality, we decided to measure the quality of the final models in a ratio scale, by giving 20 quality points to each model and then decreasing this number by a fixed number of points for each common mistake (see Table 14 ). Our empirical study then defines two independent variables (Ga for artifact guidance and Gp for process guidance) and two dependent variables (T for the time needed to carry out the task and Q for the quality of the result). The experiment thus follows a two factors with two treatments design. Table 2 presents the four possibilities. Each of these possibilities represents a treatment of our study. 4

We defined “minor dependencies” as the ones generated by types of parameters of operations that are harder to find on the model. Additionally, we defined“forbidden dependencies” as dependencies between the MVC packages that are not allowed by the pattern, e.g. a dependency from a Model class to a view class.

Artifact or Process Guidance, an Empirical Study

323

Table 1. The most common mistakes found in the students’ models Mistake Points Minor dependencies not broken -1 Forbidden dependencies partially handled -2 Operations or parameters missing in the final model -2 Ignored forbidden dependencies -5 Graphical classes in controller -6 Model classes in controller -7 Most controller classes not in controller -7 Out of scope -20

Table 2. Two factors with two treatments experiment Ga = f alse Ga = true Gp = f alse A = no guidance B = artifact guidance Gp = true C = process guidance D = both

Context. We decided to choose software engineering master students at the end of their cursus as our subjects. This choice was motivated by two factors: (1) the low-cost availability of such subjects and (2) their level of experience in designing that is comparable to the subjects of the Cass-Osterweil experiment (novice). Regarding the subject set partitioning; our experiment used a stratified random sampling. The 21 subjects of our experiment were partitioned into three skill levels corresponding to their average grade in the MSc. program. Random sampling was then applied over this skill partition to create treatment partitions of equal average skill. One group with six students and three groups with five were created and randomly assigned to our four treatments as represented in Table 2. 2.3

Hypothesis

The following hypotheses are specified to evaluate the impact of artifact and process guidance on design time and quality. These four hypotheses specify that the use of artifact guidance and process guidance do not provide any improvement to the dependent variables. If any of these hypotheses is rejected, the corresponding guidance has a significant effect. Deciding whether such effect is positive or negative is done by comparing the averages of the values of the variables in each data set. Definition 2 (Null Hypothesis) H0 (1) Design time without process guidance is equal to design time with process guidance. H0 (2) Design time without artifact guidance is equal to design time with artifact guidance.

324

M.A. Almeida da Silva et al.

H0 (3) Design quality without process guidance is equal to design quality with process guidance. H0 (4) Design quality without artifact guidance is equal to design quality with artifact guidance. 2.4

Threats to Validity

Internal validity. We avoided selection and history bias by stratifying the subjects by skills and then assign them to group of equal average skill. We avoided instrument threats by having all subjects using the same tool (modulo the extra-views defining the independent guidance variable differences). External validity. The results we obtained with masters students of our university may not be generalizable to other groups of novice designers and even less to expert designers. The specificity of the input class diagram to refactor, as well as the artifact and process guidance services that we proposed might also represent a threat to the external validity of our experiment. Construct validity. Determining whether a class diagram follows or violates the MVC pattern ultimately involves cognitive judgment calls made by subjects based on their understanding of the contextual semantics of each class. This judgment is thus in part subjective and cannot be fully automated. It directly threatens the validity of the dependent variable Q. Since subjects deliver their refactored diagram when they either judge it fully conform to the MVC pattern or when they no longer can find a way to improve its level of conformity, this partial subjectivity also indirectly threatens the validity of the dependent variable T .

3

Instrumentation

Our experiment’s instrumentation consisted of an UML CASE tool built on top of Eclipse. It provides four perspectives, one for each treatment. All those perspectives include four basic views provided by the open-source Papyrus UML editor5 (see Section 3.1). The perspectives for the artefact guidance treatments (B and D) add the Artefact View (see Section 3.2), while the perspective for the process guidance treatments (C and D) add the Process View (see Section 3.3). 3.1

Basic Views

Figure 3 shows the perspective with no guidance (treatment A). This perspective is composed of the following four basic views : 1. Editor Area View: this view contains the UML class diagram to be refactored. This diagram is displayed and edited with the Papyrus UML2 editor. 2. Property Pane View: this view allows the subjects to manipulate the properties of the elements in the diagram. 5

http://www.papyrusuml.org/

Artifact or Process Guidance, an Empirical Study

325

3. Outline View: this view displays the model’s element tree. It provides another representation of the model that complements the class diagram. 4. Birdview: this view displays an overview of the whole class diagram zoomed out.

Fig. 3. Basic Environment

3.2

Artifact Guidance View

Figure 4 shows the Artifact Guidance View. The Artifact Guidance View shows the number of inconsistencies found in the model (1) and the list of model elements that violate each design rule (2). 3.3

Process Guidance View

The Process Guidance View is based on the Eclipse Cheatsheets [13] as shown in Figure 5. It displays the process by the means of a tree of tasks (see area numbered (1) in fig. 5). When executing a task, this view shows a detailed textual description of it (see area numbered (2) in fig. 5), which explains the concepts underlying the actions to perform and the expected state of the model at the end of this task. Finally, at the bottom of the screen, a link reading “Click here to finish” is provided (see area numbered (3) in fig. 5). A click on it causes the model state to be validated against the task’s postcondition (e.g., at

326

M.A. Almeida da Silva et al.

Fig. 4. Artifact Guidance View

Fig. 5. Process Guidance View

the end of a task “Create X” the model is validated to make sure “X” exists). A task postcondition can be seen as an finer grained form of artifact guidance for intermediary model states). If it is violated, the tool gives the subject two options: (i) going back to the task to correct the model or (ii) disregard the tool’s warning and move on to the next tasks in the process.

4 4.1

Operation and Results Execution of the Experiment

The experiment described in the last section was carried out by 21 subjects over 2 consecutive hours. These two hours where divided in four periods: three training periods lasting 10 minutes each, following by one 90 minutes period to complete the task.

Artifact or Process Guidance, an Empirical Study

327

The first two training period consisting in viewing video tutorials: the first on the Papyrus UML CASE tool and the second on the artifact and process guidance plug-ins (each group saw only the parts of the videos relevant to its assigned treatment). These videos remained available as a form of help, on each machine while the subject refactored the input model. During the third training period, the subjects were asked to experiment using with the CASE tool. After this 30 min of training, the subjects they received a textual description of the MVC pattern together with the input model to refactor. As soon as the last subject received this description, they started to work on it. The subjects had autonomy to decide when they felt that they had completed refactoring. The CASE tool stored the model that they submitted as refactored, together with the log of the editing commands they executed to obtain it. The final model was reviewed to assign it a quality measure. The log could be used to perform postmortem finer grained analysis. The impact of the subject’s degree of adherence to the process guidance on both speed and final model quality was beyond the scope of this study. 4.2

Results and Analysis

Figure 6 shows the results obtained by the subjects regarding the time needed to perform the refactoring (T ) and the quality of the returned design (Q). A n/a in the time column indicates that the subject has not finished the refactoring in the time frame. A B C D (no guidance) (artefact guidance) (process guidance) (both guidances) T (min) Q T (min) Q T (min) Q T (min) Q 8 20 15 20 47 63 47 59 15 19 13 34 63 40 n/a 15 66 13 65 15 32 15 67 14 14 18 12 68 63 n/a 4 60 15 60 n/a 10 n/a 0 n/a 9 n/a 0 Fig. 6. Time (T ) and quality (Q) results for each treatment

We used the ANOVA6 method against these results to asses the effect of the guidance. This tests assumes normal distribution and interval scale data. We confirmed the normality of our data set by executing the Shapiro-Wilk normality test. We obtained respectively ρ = 0.01055 and ρ = 0.04667 for T and Q. In the case of the subjects that had not completed the refactoring (T = n/a), only the design quality of the produced models was considered. 6

This test is used to compare the variances of two data sets in order to determine if they present statistically significative differences. The lower the obtained ρ-value the more significative is the difference.

328

M.A. Almeida da Silva et al.

The following observations were made: – The H0 (1) null hypothesis has neither been rejected nor accepted with ρ = 0.602. As a consequence, the difference in the average design time of the groups with process guidance (groups C and D, average design time = 50.8 min) and the groups without it (groups A and B, average design time = 58.7 min) is not statistically significant. – The H0 (2) null hypothesis has been rejected with ρ = 0.001. As a consequence, the difference in the average design time of the groups with artifact guidance (groups B and D, average design time = 62.9 min) and the groups without it (groups A and C, average design time = 49.3min) is statistically significant. – The H0 (3) null hypothesis has neither been rejected nor accepted with ρ = 0.488. As a consequence, the fact that the average design quality of the groups with process guidance (groups C and D, average design quality = 15.2) and the groups without it (groups A and B, average design time = 15.2) is the same is not statistically significant. – The H0 (4) null hypothesis has neither been rejected nor accepted with ρ = 0.523. As a consequence, the difference in the average design quality of the groups with artifact guidance (groups B and D, average design quality = 16.7) and the groups without it (groups A and C, average design quality = 13.6) is not statistically significant. However, upon finer analysis, when considering one subject of group A as an outlier, due to the fact that the quality of result s/he delivered is far off the average of other subjects, then the H0 (4) null hypothesis is rejected with ρ = 0.006 and the difference becomes statistically significant.

5 5.1

Result Interpretation Result Synthesis

The results we measured and that have been validated thanks to the ANOVA method can be synthesized by the Definitions 3 and 4: Definition 3 (Significant effects) Subjects that used the artefact guidance took more time to perform the refactoring, but delivered design of better quality. Definition 4 (Non significant effects) No significant effects were measured for the design quality and time with process guidance. 5.2

Discussion

Beyond the overall statistical results given above, we made a set of interesting finer grained observations. Subjects provided with artefact guidance considered their refactoring completed only when the error list displayed was empty. This

Artifact or Process Guidance, an Empirical Study

329

suggests that such guidance helps developers decide when they have completed a refactoring task. The initial model contained 5 initial errors. Therefore, at the beginning of the study, five errors were displayed in the error list. During the study, we observed that up to 20 errors could be detected by the artefact guidance and displayed in the error list. Those errors obviously didn’t have the same complexity to solve. At the end of the study, all of the subjects provided with artefact guidance were impeded by a same error. This error targeted one of the UML class that had to be split in two parts as it has a mixed responsibilities. Subjects spent much time on resolving this error that were, indeed, more complex to correct. This suggests that developers with artefact guidance took much more time than the others as they all try to solve all the errors, including the difficult ones. Subjects provided with process guidance complete process 1 to 4 quite quickly, but they spend more time on tasks 5 and 6. This may be explained by the fact that tasks 1-4 are defined in very prescriptive terms, easy to understand and can be carried out with a very short editing action sequence. This was also the case of the tasks in the Cass-Osterweil experiment that observed benefits to process guidance. In contrast, the definition of tasks 5-6 are more descriptive. Mapped them onto an editing action sequence require more design skills and a deeper understanding of the class contextual semantics. This may explain why no effect has been measured for the process guidance regarding efficiency and quality. Since we designed our study to differ from Cass and Osterweil’s [4] by a minimal two controlled features, the fact that we observed almost opposite results may suggest that the conclusion of both studies do not generalize well. As a consequence, we argue that the benefits of the artefact and process guidance seem to be not measurable in general. Rather, regarding a specific pair of artefact and process guidance, it should be possible to statistically measure their respective effects.

6

Conclusion

In this paper, we presented an empirical study that aimed at measuring the effects of two types of services provided by advanced CASE tools: artefact guidance and process guidance. More precisely, we measured the effects on the time required to perform a model refactoring and on the quality of the resulting model. This is the first study of this kind, though a similar study was carried out for the task of building a model from scratch [4]. This earlier study reported that for such task, process guidance statistically significantly improved both design time and quality, while artefact guidance had no statistically significant impact. In contrast, for the present task, we report no statistically significant impact for process guidance. We also report that artefact guidance statistically significantly increases design time and that it only statistically significantly improves the quality of the resulting models if we discard one subject as an outlier. Our study shows that much further research needs to be carried out in this field before we can answer, on strong statistical ground, to questions such as:

330

M.A. Almeida da Silva et al.

– For what tasks are artefact and process guidance complementary and for what tasks are they redundant? – Are there tasks for which neither guidance positively impact on development speed and software quality? – What subclasses of artefact and/or process guidance are more helpful than others?

References 1. Apple Inc.: Cocoa Design Patterns (2010) 2. Bendraou, R., Gervais, M.-P., Blanc, X.: UML4SPM: A UML2.0-Based Metamodel for Software Process Modelling. In: Briand, L.C., Williams, C. (eds.) MoDELS 2005. LNCS, vol. 3713, pp. 17–38. Springer, Heidelberg (2005) 3. Blanc, X., Mougenot, A., Mounier, I., Mens, T.: Detecting model inconsistency through operation-based model construction. In: Robby (ed.) Proc. Int’l Conf. Software engineering (ICSE 2008), vol. 1, pp. 511–520. ACM, New York (2008) 4. Cass, A.G., Osterweil, L.: Process support to help novices design software faster and better. In: Proc. Int’l Conf. Automated Software Engineering (ASE 2005), pp. 295– 299. ACM, New York (2005) 5. Cuccuru, A., Radermacher, A., G´erard, S., Terrier, F.: Constraining type parameters of uml 2 templates with substitutable classifiers. In: Sch¨ urr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 644–649. Springer, Heidelberg (2009) 6. Curtis, B., Kellner, M.I., Over, J.: Process modeling. Commun. ACM 35(9), 75–90 (1992) 7. Egyed, A.: Instant consistency checking for UML. In: Proceedings Int’l Conf. Software Engineering (ICSE 2006), pp. 381–390. ACM Press, New York (2006) 8. Egyed, A.: Fixing inconsistencies in UML design models. In: Proc. Int’l Conf. Software Engineering (ICSE 2007), pp. 292–301. IEEE Computer Society, Los Alamitos (2007) 9. Egyed, A., Letier, E., Finkelstein, A.: Generating and evaluating choices for fixing inconsistencies in UML design models. In: Proc. ACM/IEEE Int’l Conf. Automated Software Engineering (ASE 2008), pp. 99–108. ACM, New York (2008) 10. Finkelstein, A., Kramer, J., Nuseibeh, B., Finkelstein, L., Goedicke, M.: Viewpoints: A Framework for Integrating Multiple Perspectives in System Development. International Journal of Software Engineering and Knowledge Engineering 2(1), 31–57 (1992) 11. Fuggetta, A.: Software process: a roadmap. In: ICSE - Future of SE Track, pp. 25–34 (2000) 12. Krasner, G.E., Pope, S.T.: A cookbook for using the model-view controller user interface paradigm in smalltalk-80. J. Object Oriented Program. 1(3), 26–49 (1988) 13. Tiedto, P.: Cheat sheets in Eclipse. IBM Developer Networks (August 2006) 14. Wohlin, C., Runeson, P., Host, M., Ohlsson, C., Regnell, B., Wessl´en, A.: Experimentation in Software Engineering: an Introduction. Kluwer Academic Publishers, Dordrecht (2000) 15. Zhang, H., Kitchenham, B.A., Pfahl, D.: Reflections on 10 years of software process simulation modeling: A systematic review. In: Wang, Q., Pfahl, D., Raffo, D.M. (eds.) ICSP 2008. LNCS, vol. 5007, pp. 345–356. Springer, Heidelberg (2008)

Scaling Up Model Driven Engineering – Experience and Lessons Learnt Vinay Kulkarni, Sreedhar Reddy, and Asha Rajbhoj Tata Consultancy Services, 54B, Industrial Estate, Hadapsar, Pune, 411013 India {vinay.vkulkarni,sreedhar.reddy,asha.rajbhoj}@tcs.com

Abstract. Model driven engineering (MDE) aims to shift the focus of software development from coding to modeling. Models being at a higher level of abstraction are easy to understand and analyze for desired properties, leading to better control over software development life cycle. Models are also used to automate generation of implementation artefacts resulting in greater productivity and uniform quality. The focus of the MDE community is largely on exploring modeling languages and model transformation techniques. Not much attention is paid to the issues of scale. Large business applications are typically developed over multiple geographical locations and have a lifecycle running into decades. This puts several additional demands on MDE infrastructure – multi-user multi-site model repository, versioning and configuration management support, change-driven incremental processes etc. We describe our MDE infrastructure, experience of using it to deliver several large business applications over past 15 years, and the lessons learnt. Keywords: Modeling, Meta model, Code generation, Business applications.

1 Introduction We have been using model-driven techniques for developing large business applications over the past 15 years. This work began when our organization decided to develop a banking product. One of the key requirements was easy delivery into multiple technology platforms to be able to keep pace with technology advance. Large business applications are typically implemented using distributed architecture. This requires expertise in a variety of technologies such as graphical user interface frameworks, middleware platforms, databases and a variety of programming languages. These applications have to deal with large volumes of data being accessed by a large number of users demanding very high availability. This calls for a good handle on issues such as concurrency management, response time, throughput, optimal batch processing window, and so on. Application architecture is a balancing act as multiple strategies exist to address these issues with different tradeoffs. Different problem contexts demand different application architectures. However, architecture expertise is in short supply, and conceiving the right application architecture and ensuring that it is implemented correctly and efficiently by a large team of developers is a difficult problem. Having a background in compilers, we felt, these varied requirements would D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 331–345, 2010. © Springer-Verlag Berlin Heidelberg 2010

332

V. Kulkarni, S. Reddy, and A. Rajbhoj

be better addressed through a specification-driven approach wherein specifications abstract out implementation-level details that can be filled in later through code generation. We devised a set of models to capture relevant facets of the desired application architecture, and a high level model-aware language to specify business logic. For instance, a GUI model to specify presentation facet, a database model to specify data management facet, a component model to specify application services and so on. We came up with a unified meta model that enabled us to specify the relationships between the various models and the consistency constraints that govern these relationships. For instance, whether a GUI screen is able to display data corresponding to input and output parameters of a service being invoked from the screen; whether all attributes of a persistent class hierarchy are mapped onto columns of database tables; whether relationships between persistent classes are mapped to primary and foreign key attributes of relevant tables and so on. Compiler of our high level language treats the various models as its type system thus ensuring consistency between code and models. Large size of application required sub-teams performing specialized tasks such as creating analysis models, refining analysis models with design details, specifying business logic, transforming models and business logic to code, testing the implementation, deploying into the desired deployment set-up etc. These sub-teams need to share a unified view of the models in order to ensure that different models are consistent with each other, and business logic is consistent with the models. To achieve this, we developed a centralized multi-user repository for storing models. We used a 3rd party source code control system to store business logic specifications and used the model repository to store links between these specifications and models. With this in place, the simplest way to achieve a unified view is to have everyone work off a single copy. However, this enforces everyone to be in lock-step thus sacrificing flexibility in development. To balance this concern, we developed a component abstraction to support the notions of private and public workspaces, and devised a protocol for synchronizing them. Large outsourced projects typically have an onsite and an offshore development team. Most of the projects that used our approach were of this nature. The geographical separation places an additional requirement on repository synchronization. This was addressed by enhancing the protocol for local synchronization suitably. Large software development engagements are typically delivered in phases where each phase constitutes a well-defined baseline in the project lifecycle. Even after final delivery, the project continues to evolve due to variety of reasons such as introduction into new geographies, complying with new regulatory frameworks and exploiting technological breakthroughs. To address this need, we developed robust and comprehensive versioning and configuration management capabilities for application specifications – both models and business logic. In many business applications, it is critical to have short turn-around times for changes – especially in maintenance phase. This requires all development / maintenance processes to be change-driven i.e. effort required to implement a change should be proportional to the size of the change. We engineered our MDE processes and tools supporting them to be incremental in nature.

Scaling Up Model Driven Engineering – Experience and Lessons Learnt

333

App layer meta model

GUI layer meta model

*

* has

UIClass 1..* has *

UIAttribute mapsTo

0..1

Attribute

implements

*

* destination

1

1

*

Class

opens

1 has *

* 1..*

*

0..1

* *

Window has

source

Operation

Button 0..1

* realizes

0..1

call

*

Task *

* precedes

Db layer meta model

0..1

Association

mapsTo

*

1

Table 1

has

has *

*

Column

Attribute * ofType 1

1 has

*

0..1

0..1

mapsTo

1..*

0..1

Key *

composedOf

DataType

* has 1..*

Process

Fig. 1. A subset of the unified meta model

Over the past 15 years, we have delivered several solutions in several business verticals. There is a large amount of commonality across the solutions belonging to a vertical. In absence of a mechanism to capture this commonality, one is forced to introduce a new feature and / or a bug fix at several places. This is effort intensive and error-prone. We discuss the need for managing commonality and variability at model level, and present our ideas. Section 2 gives an overview of the model-driven development approach we have been practicing. The MDE infrastructure and processes we developed to scale this approach to the demands of industry practice are discussed in sections 3 and 4 respectively along with our experience and lessons learnt. Section 5 discusses the need for supporting commonality and variability in MDE infrastructure in order to scale to the demands of industry practice. Section 6 concludes with a short discussion.

2 Our Model-Driven Development Approach We started with the objective of cleanly separating the functional concerns from the technology concerns in order to enable application developers to concentrate on business requirements without having to worry about implementation-level details such as persistence, transaction processing, large dataset handling and concurrency. We used UML[1] to model application functionality and extended UML meta model where required to model various aspects of interest. Business applications can be seen as comprising of three broad classes of functionalities, namely online, batch and reports. In this paper, in the interest of space, we restrict the discussion to online functionality only. Online functionality is typically implemented using a layered architecture consisting of presentation layer, business logic layer and data manager layer as shown in fig 1. We used UML class diagrams to capture business entities and their relationships, UML use-case diagrams to describe business scenarios, and UML activity diagrams to describe process flows. We extended UML class models with additional properties

334

V. Kulkarni, S. Reddy, and A. Rajbhoj

and associations in order to capture architectural information, such as classes that make up a message, classes that need to be persisted in a database, classes that need to be displayed on a GUI screen, operations that need to be deployed as services having transactional behaviour and attributes that are mandatory. We designed a model-aware high-level language (Q++) to specify the business logic. Q++ treats the extended UML class models as its type system, provides constructs for navigating model associations, and allows for declarative specification of errors and exceptions. Also, the language abstracts out details such as memory management and exception handling strategy. Model-aware nature of Q++ guarantees that business logic specifications will always be consistent with the models. We extended UML to specify the presentation layer in terms of special abstractions, namely windows and windowtypes. A windowtype specifies a pattern such as a form screen, a list screen, and so on. A window is an instance of a windowtype. It specifies which data elements of which business entity to display using which controls and which buttons should invoke which business services and/or open which windows. Our presentation layer model was independent of the implementation platform except for the event code. We extended UML to specify relational database schemas and complex database accesses. Object – relational mapping was realized by associating object model elements to the schema model elements, i.e. class to table, attribute to column, association to foreign key etc. We defined a Query abstraction to provide an object façade over SQL queries with an interface to provide inputs to, and retrieve results from the query. We used a slightly modified SQL syntax in order to bind input/output parameters. We came up with a unified meta model to specify the above mentioned models and their relationships. Fig. 1 highlights the associations spanning these models. These associations help keep the three specifications consistent with respect to each other and thus ensure that the generated platform-specific implementations are also consistent [2]. For example, the association Button.call.Operation can be used to check if a window is capable of supplying all the input parameters required by an operation being called from the window. Similarly, we were also able to model other facets such as batch functionality, reports etc. From these various models and high level specifications, we were able to generate a complete application implementation.

3 MDE Infrastructure Model driven engineering needs, at a minimum, a means for creating models of interest and a means for transforming those models into software development life cycle (SDLC) artefacts. UML has become a de facto modeling language in industry. General practice is to fit all modeling requirements into abstractions provided by UML and its extension mechanisms such as stereotypes. These models are then transformed into code fragments that need to be completed and put together manually. In contrast, we generate complete applications from models. Therefore, we capture all facets of business applications as models. As these models are the principal artefacts in SDLC, they must be first class entities, intuitive and closer to the problem domain. We found

Scaling Up Model Driven Engineering – Experience and Lessons Learnt

335

Object

0..* instanceOf

instance Of Level 1

Meta meta model instance Of

Level 2

Meta model instance Of

Level 3 Information system or user model

Association

instanceO

1 type instanceOf

Class

srcRoleName : String 0..* source name : String tgtRoleName : String 1 isAbstract 0..* target : Boolean srcCard : String tgtCard : String 1 isSrcOwner : Boolean isTgtOwner : Boolean instanceOf

Attribute

name : String 1 attribute dataType : String 0..* 1 0..* inheritsFrom

Fig. 2. Modeling levels

Fig. 3. Reflexive meta meta model

that by force-fitting all models into UML or UML stereotypes, these important properties are lost. In our experience, no two projects had exactly the same requirements on MDE infrastructure. At the same time, the infrastructures were not entirely different either. There was a large amount of commonality across these infrastructures. There is a need for a good composition mechanism to address the commonality and variability in MDE infrastructure. 3.1 Modeling Infrastructure 3.1.1 Meta Modeling An information system can be seen as collection of parts and their relationships. A model of an information system is a description of these parts and relationships in a language such as UML. The modeling language itself can be described as a model in another language. The latter language is the meta model for the former as shown in Fig 2. We use a reflexive modeling language that is compatible with OMG MOF [3] to define models at all levels. A model at each level is an instance of the model at the previous level. The model at level 1, the meta meta model, is an instance of itself. The meta meta model shown in Fig. 3 is the base model. It is the schema for describing meta models. The meta meta model is capable of describing itself, i.e., it can model itself. Everything in a model is an object. An object is described by its class. A class is specified in terms of a set of attributes and associations. An object is an instance of a class that has attribute values and links to other objects as specified by its class. Since everything is an object, a class is also an object that is specified by another class called metaclass. In Fig. 3, the class class is a metaclass which is an instance of itself. A meta model specification consists of: a model schema which is an instance of the meta meta model, a diagramming notation to edit its instance models, and a set of constraints and rules to specify consistency and completeness checks on its instance models. We provide a reflexive modeling language-aware generic model editor for creating models as well as their meta models. We use OCL [4] to specify wellformed-ness constraints over models. We provide a diagram definition workbench to define visual notations and map them onto meta model elements. Having a meta modeling framework enabled us to extend modeling languages as per need.

336

V. Kulkarni, S. Reddy, and A. Rajbhoj

derives 0..* 1

0..* contains

Configuration

1

0..*

Partition

0..* derives 1

0..* 0..* contains Partition Version

has

1..* 1

contains 0..*

Object

Fig. 4. Meta model for versioning and configuration management

3.1.2 Multi-user Repository Large sized applications require sub-teams performing several specialized tasks. These sub-teams need to share a single version of truth in order to ensure that different models are consistent with each other and business logic is consistent with the models. We developed a central repository for storing models that provided concurrent access to multiple users. Multi-user operation requires support for transaction and concurrency management. Models being the core artefacts in MDE, these features are critical to maintain integrity of models. Choice of our own file-based storage mechanism for models would have meant having to implement robust transaction and concurrency management features ourselves. Instead, we chose industry-strength relational database as a storage mechanism which provides a robust implementation of these critical features. We do support a file-based storage mechanism, but, for single user operation only. 3.1.3 Versioning and Configuration Management To manage complexity and enable concurrent development, we developed a Partition abstraction using which a large model can be decomposed into a set of related units. We developed a Configuration abstraction using which a set of compatible Partitions can be put together with a guarantee of completeness. Fig. 4 shows our meta model for versioning and configuration management. R Conradi and B Westfechtel have published a detailed survey and classification of various version models [5]. Our versioning model provides extensional versioning with configuration as the recursive composition structure and Partition as the versioned entity, with in-built composability constraints. Partition Partition is a container for model elements such as objects, properties and associations. After creation, an object is placed in a Partition and carries the identity of the Partition. Models are versioned at the level of a Partition. Versions of compatible Partitions are assembled, within a configuration, to represent model of the complete system. An object belongs to a Partition and is versioned with the Partition. Thus, an object gets the version number of its container Partition, but two versions of an object will always have the same ObjectId. When an object is contained in a partition version, its properties and the associations owned by it are also contained in that partition version. Partition is a typeless construct, i.e. an instance of any meta object can be placed in a Partition. Associations can either be between objects belonging to the same Partition or different Partitions. An inter-partition association establishes a

Scaling Up Model Driven Engineering – Experience and Lessons Learnt

337

relationship between two partition versions and it belongs to the partition version to which the owner object of the association belongs. A partition version guarantees change isolation i.e. changes made to the objects in one version are not visible in other versions. Conceptually, a new version of a Partition contains copies of the objects of the version from which it is derived. Thus, a Partition enables concurrent development of different parts. Configuration Configuration is a container for assembling partition versions. It provides the context for creating inter-partition associations. Two configurations can share a partition version. Thus, configuration versions are designed to support sharing, while partition versions are designed to support change isolation. Also, a configuration can contain other configurations. Configuration enforces completeness through the “ownership” property of associations – if a configuration contains a Partition X having an object O that owns the association A, then the configuration must contain a Partition Y having the object at the destination end of the association A. For example, the association calls from function to function is owned by the caller function and hence a configuration that only contains caller functions is incomplete. Diff and Merge We provide a facility to compare (‘Diff’) and merge models contained in two partition versions or two configurations. Two versions of an object are compared based on their ObjectIds and in terms of their property values and associations. Often, comparison of two objects by themselves is not of much value unless it is done in the context of its associated objects. Such a context is also necessary while merging versions of an object. In general, in a given model, some objects play the role of primary objects and others play the role of companion objects. For example, in the OO model, Class is a primary object and Attribute is a companion object. Two Attributes should only be compared in the context of the Classes to which they belong. Such context sensitive comparison and merge operations can be performed by specifying object-association graphs or patterns. An example pattern for comparing classes in two partitions could be: ‘Class-attribute-Attribute’ and ‘Class-operation-Operation’. 3.2 Model Transformation Infrastructure We transform models into a variety of SDLC text artefacts such as code, deployment descriptors, user documentation and makefiles. We developed a scripting language specially designed to traverse a model and emit code. The language treats meta model as its type system, provides special constructs for navigating associations, and common imperative constructs such as if-else, for and while loops. The language also enables specification of text to be generated in a wysiwyg manner. We found that this language was sufficient for all our model-based code generation requirements. Even though we use a number of meta models, they are not related to each other in a transformational sense. Rather, they have associations between them and a set of constraints to ensure the models are consistent with respect to each other. The closest use-case for model-to-model transformation we found was that of object – relational mapping, and even here the mappings were rather simplistic.

338

V. Kulkarni, S. Reddy, and A. Rajbhoj Q++ code

Design strategies

Model to PB translator

GUI layer in PB

Q++ to C++ translator

App logic layer in C++

Model to C++ translator

DM layer in ProC

Query to ProC translator Model to JSP translator Extended UML models

Query code

Q++ to Java translator

GUI layer in JSP

Model to Java translator

App logic layer in Java

Query to JDBC translator

DM layer in JDBC

Fig. 5. Scattering and tangling in code generation

3.3 Building Blocks As can be seen from Fig. 5, different code generators are needed to deliver the same business functionality on different technology platforms. This is despite these code generators sharing a great deal of common functionality and differing mostly only in the use of primitives offered by the target technology platform e.g. syntax differences of programming languages and data type differences of databases. Even while delivering identical business functionalities on identical technology platforms, we ended up implementing different code generators in order to deliver onto different architectures such as synchronous and queue-based messaging. Similarly, choice of different design strategies resulted in different code generators. In the case of design strategies, the problem was exacerbated even further. Since many design strategies cut across several architectural layers, changing an existing design strategy or adding a new design strategy required modifications to multiple code generators in multiple places. Ensuring complete and consistent implementation of such a change became difficult as it required thorough knowledge of all the concerned code generators on the part of a tool implementer. This problem became more acute as the number of variants of the code generators grew. The tangling of model-based code generators, as shown in Fig. 5, is due to lack of separation of the various concerns, namely, technology platform, architecture and design strategies, and the cross-cutting nature of design strategies. An improved architecture for model-based code generation is where the models are successively refined by application of the various design strategies to a stage from where a platform specific implementation can be realized through a simple task of models to text transformation. As the platform-specific code generators are independent of design strategy related issues, the same model-to-text transformation specifications can be reused with different design strategies and vice versa. This separation of concerns enables a tool variant to be viewed as a composition of design strategy and technology platform aspects of choice. We developed Building Block abstraction to support this separation of concerns and composition. A building block encapsulates a choice along one of these dimensions. A code generator is the desired hierarchical composition of building blocks [6]. The process of model-driven code generation is realized through a post-order traversal of the building block hierarchy in three sequential steps, namely, Instantiation, Transformation and Weaving. The instantiation step stamps out models

Scaling Up Model Driven Engineering – Experience and Lessons Learnt

339

and merges them [7]. The transformation step transforms models into code snippets and generates weaving specifications for composing them [8]. The weaving step composes the generated code snippets by processing the weaving specifications. We could organize multiple variants of a code generator as different compositions of building blocks into a family as follows: − − −

Commonality across variants can be specified using a set of common building blocks Functionality specific to each variant can be specified using a set of variant building blocks Composable nature of building blocks enables realization of the desired family member as a composition of suitable common and variant building blocks

4 Model-Driven Development Process 4.1 Component-Based Development Large business applications require large development teams. Typically, development effort is partitioned along functional modules that have high internal cohesion and low external coupling. In absence of explicitly stated dependencies, such a partitioning may introduce spurious dependencies that can lead to integration problems. For instance, a consumer module should not refer to internal implementation-specific details of its supplier module. This becomes more critical in model-driven development where the development artifacts comprise of both models and code, as a result, spurious dependencies can be introduced either in model, code or both. In our experience, this turned out to be a significant issue during development of our banking product which had a peak team size of around 150. We introduced a component abstraction to manage these dependencies at model and code level. A component specifies its interface in terms of model elements such as Classes, Operations and Queries. The consumer-supplier relationship between components is explicitly modeled through depends association between the components. A component can only use the model elements specified in the interface of the components it depends upon. As Q++ is model-aware, we can honour these modellevel dependencies automatically in code as well. A component has two associated workspaces, a model workspace and a code workspace as shown in Fig. 6. The model workspace is a configuration comprising of own Partition and Partitions of the components it depends on. In a component workspace, one is only allowed to change the contents of own Partition. As workspaces provide change isolation, a consumer component is not immediately affected by the changes introduced in its supplier components. A special workspace, configuration MSP of Fig. 6, is provided for exchanging models between components. A (supplier) component releases its model to this special workspace for sharing, from where its consumer components pick it up as shown in Fig. 7. Model well-formedness constraints and consumer-supplier dependencies are then automatically checked in the consumer component workspace. A similar workspace, directory CSP of Fig. 6, is provided for sharing code between components. Components are allowed to share code only after they share their models.

340

V. Kulkarni, S. Reddy, and A. Rajbhoj Check for well-formedness constraints and consumer-supplier dependencies

4

Modeling workspace of consumer component

Modeling workspace of supplier component 3

Configuration

1 keptInSync

MSP

Directory

M_Workspace 0..* refer 0..*

Partition

Workspace 1 has 1

C_Workspace keptInSync

0..* Component

1..*

Coding workspace of supplier component

Coding workspace of consumer component 5

1

Release

CSP

2 Release

Workspace for sharing code (CSP)

0..* depends

Fig. 6. Meta model for workspaces

kept in sync

Workspace for sharing models (MSP)

1..* 1 own 1

Release

Fetch kept in sync

1

Fig. 7. Synchronizing components

Model-awareness of Q++ ensures consistency across consumer-supplier components at code-level as well. The process is realized through a set of roles, each responsible for performing a set of well-defined tasks on a component in a workspace. A role essentially identifies a set of logically coherent process steps. For instance, all modeling related tasks are grouped into the modeler role, all coding related tasks are grouped in the programmer role, all workspace synchronization related tasks are grouped in the manager role, all setup related tasks are grouped in the administrator role. Explicit modeling of interfaces and dependencies provided better control over integration of components being developed independently. This enhanced structure was used to compute change impact leading to significantly reduced testing effort. 4.2 Geographically Distributed Development Large business applications are developed in a distributed manner over multiple sites. Ideally, in a repository-centric development approach, it should be possible for distributed teams to connect to a central database. However, we found several issues in performance intensive actions such as diagram editing when connected over WAN or web. We decided to replicate the repository at multiple sites and synchronize it using a well-defined protocol. One of the alternatives was to use background database synchronization products. However, synchronization of models needs manual supervision which renders such products unsuitable. We devised our own synchronization protocol which is an extension of the one shown in Fig. 7. The ‘workspaces for sharing models’ from different sites were synchronized using a meta model pattern based diff-merge process (discussed below). This enabled individual teams to continue working in their respective local workspaces undisturbed. We ensured globally unique identifiers for model elements across sites to avoid clashes. 4.3 Delta-Driven Processes The performance of various model processing operations such as model validation, diff/merge, model transformation and code generation tends to deteriorate with increasing model sizes. This in turn affects turn-around times for change management. Ideally, these operations should only consume time that is proportional to the size

Scaling Up Model Driven Engineering – Experience and Lessons Learnt

341

of the change and remain unaffected by the total size of the model. We devised a pattern-based approach for implementing incremental execution of common modeldriven development processes such as model transformation, model comparison and merging, model validation, model export and code generation. We also developed a meta model for recording changes and integrated it into the model repository for efficient change processing. Models are well-structured graphs, and many model processing operations can be formulated in terms of graphs. Also, most models are processed in clusters of related elements; for instance, a class, its attributes and operations are usually processed together. Each such cluster has a primary element that identifies the cluster; for instance ‘Class’ in the above example. We used meta model patterns to specify such clusters with the root identifying the primary element of the cluster. We then specified the model processing operations in terms of these patterns. For example, when we want to compare class models of two UML models, we want the comparison to be conducted on clusters of model elements centered around class objects; in pattern model terms we want to treat class as the primary object, with its attributes, operations and associations making up the rest of the connected elements of the cluster. In execution terms, a diff operation can be seen as being invoked repeatedly for each matching root element of the pattern from both the source and target models. Fig. 8 shows the meta model for recording model changes that occur in a model repository. We call this model a delta model. A Delta is a record of a single change; it has a timestamp property that records the time of the change and an opCode property that records the operation causing the change, namely, one of ADD/MODIFY/DELETE. ObjectDelta records changes to objects; PropDelta records changes to properties; and AssocDelta records changes to associations. ObjectDelta has an association to Object to identify the object that has changed; it also stores the ID of the object (ID is required because that is the only way to identify an object that has been deleted from the repository). PropDelta has an association to Property to identify the property that has changed, and records two values – new and old (if any). AssociationDelta has an association to Association to identify the association that has changed, and two links to ObjectDelta corresponding to the two end objects. The associations between ObjectDelta, PropDelta and AssocDelta mirror the associations between Class, Property and Association in the meta meta model, and thus record the same structure. We devised an algorithm that, given a model pattern, computes the impacted root objects from a given model and its delta model for the set of changes recorded in a given time period. oldValue newValue Property

PropDelta

0..1

0..1 PropValue

* 1

Class

Object

ObjectDelta

Delta

ObjectID

Timestamp opCode

end2 1 *

Association

1 end1 *

AssocDelta

MOF model

Fig. 8. Delta model

342

V. Kulkarni, S. Reddy, and A. Rajbhoj

Thus, we could identify which root objects in the model have changed in a given change cycle and apply the necessary model processing operations only on these root objects. This resulted in minimal code generation for the model changes. We used ‘make’ utility which is time-stamp sensitive, and hence subsequent compilation – build – test – deploy processes are also incremental.

5 Commonality and Variability We discovered that different solutions in the same business domain were not exactly alike even for identical business intent. With toolset providing no means to capture commonality and variability, application development teams had to resort to copypaste of application specifications. As a result, what should have been a variant of an application ended up being a separate application thus leading to maintenance and evolution problems. These problems compounded with every new solution being delivered. We extended our model-driven development approach to support the family concept [9]. We have different meta models to describe different layers of application as shown in Fig 1. We enhanced these meta models to support family concept so as to impart configurability and extensibility properties to the generated applications. We illustrate this in the context of application layer. Application layer specifies business logic in terms of Class, Attribute and Operations. Fig. 9 depicts the meta model for imparting configurability and extensibility at the granularity of class. This meta model is an extension of the application layer meta model highlighted in Fig 1 as follows: -

-

-

-

-

Classification of Attributes into fixed, free and delmod. A Class contains fixed attributes in all situations whereas free attributes are specific to a situation. Attributes tagged delmod represent situation-specific deletions and/or modifications. An Attribute can conform to different types. Classification of Operations into Configurable and Concrete: The former have situation-specific behavior whereas the latter have fixed behavior in all situations. Body of a Configurable operation is a Template with well-defined extension points (TxtnPoint) where different behaviors can be plugged in. An extension point is specified in the form of an interface invocation – a factory returns the appropriate object (Txtn) that implements the extension. Extending existing behavior amounts to providing a new extension (Ov) for existing extension points or defining a new template (Ox) for the operation being extended or both. Cv depicts situation-specific class definition. A situation helps select the desired variant of a class from multiple alternatives [10]

Thus, the above meta model enables modeling of a family of classes wherein each family member serves the same intent in a specific situation. By making the above information available as metadata, application can switch from one known situation to another at run-time. A new situation is handled by adding a new row in the metadata

Scaling Up Model Driven Engineering – Experience and Lessons Learnt

343

Fig. 9. Extended Application Layer meta model

tables. Not all situational adaptations can be handled at run-time though, for instance, addition of a new behavior extension (Ox or Ov) would need recompilation (followed by redeployment). Similarly, definition of a new class altogether, as an extension to existing functionality, cannot be handled at run-time. However, the meta model enables a new situation to be added to the existing set of configuration alternatives. We extended other application layer meta models on the similar lines.

6 Discussion We have used model-driven techniques to deliver more than 70 business critical applications over the past 15 years. For instance, a policy administration system we developed for a large insurance company comprises of ~75 components, ~4500 classes, ~100K model elements, and ~2M lines of higher level language specifications. Size of the generated application is around 20M lines of C++ code. This application is operational for the past 12 years with 1500 person-years worth effort having gone into it so far. First delivery of system had a peak team size of around 250 distributed onsite and offshore. Design and Construction phases of application development witnessed more than double productivity improvements – principally due to generation of solution architecture related code from models. For instance, database schema definition, primary-key based data access methods such as Create, Modify, Delete, Get and Exists and methods for navigating along class associations were completely generated for classes marked as Persistent in the model. Our Query abstraction enables specification of complex database accesses in a simple extension of SQL syntax. We translate a query into a class having Execute method which is essentially a wrapper for the SQL statement and handles the peculiarities of RDBMS and data

344

V. Kulkarni, S. Reddy, and A. Rajbhoj

access mechanisms such as ODBC, JDBC and DAO. Treating Query as a class enables type safety when invoked from application logic layer. A query can be annotated to be a cursor query or a paging query which leads to generation of additional methods, for instance, Open, Fetch and Close in case of the former, and GetNext and GetPrevious in case of the latter. On similar lines, we generate solution architecture specific code for business logic and presentation layers. However, onsite and offshore nature of work needed significant manual effort for coordination. This effort coupled with inadequate support for testing and requirement capture phases ate into productivity benefits due to model-based code generation. Several enhancements have been delivered since with total team size not exceeding 50. Overall effort savings of around 20% have been realized over the operational span of the system. In our experience, having a robust central repository and repository-centric processes proved to be a significant advantage for managed evolution as all stakeholders had access to a single version of truth. By hosting our repository on an industry-strength RDBMS, we could delegate transaction management and concurrency control responsibilities to the RDBMS enabling us to support a large number of concurrent users. Most MDE tools available wouldn’t have scaled up to our needs as they are based on single-user file-based storage for models. These tools do provide basic mechanisms to organize models into containers and code into directory structures. However, every project team has to build the superstructure to keep model containers and their code counterparts in sync, and to keep different model containers in sync with each other. Our MDE infrastructure has a pre-defined meta model to define components, workspaces and a synchronization protocol as discussed in section 4.1 thus obviating the need for building the superstructure for each project. Most MDE tools delegate versioning and configuration management responsibilities to file-based version control tools. As models are also stored in files, these files can also be managed by the same versioning tool. However, as the structure inherent in the model is not visible to the versioning tool it cannot exploit the structure for fine-grained version control. Also, as the versioning tool is oblivious of model content, it cannot provide semantically meaningful configuration management. Project teams need to build these features on top. Our MDE infrastructure has a pre-defined versioning and configuration management meta model (ref section 3.1.3) thus obviating the need for building this superstructure for each project. Most MDE tools do not come with a change model inbuilt. As a result, the onus of determining what has changed in a model, what impact the change has on other model and code artefacts, and how to propagate the change correctly to all the impacted artefacts lies entirely with the developer. This is an error-prone and effort-intensive activity. Our MDE infrastructure has a pre-defined delta meta model (ref section 4.3) and a pattern-based change propagation mechanism relieving the developer of this burden. Delta-driven processing has brought down complete build time for a component of the insurance policy administration system application from about 60 mins to an average 6 mins. From our experience, the above issues are critical for scaling MDE to the demands of enterprise scale applications. Going by literature, it appears MDE community isn’t paying enough attention to these issues. As MDE begins to gain industry acceptance, we believe such issues are going to become more critical.

Scaling Up Model Driven Engineering – Experience and Lessons Learnt

345

References 1. Unified Modeling Language, http://www.omg.org/spec/UML/2.2/ 2. Kulkarni, V., Venkatesh, R., Reddy, S.: Generating Enterprise Applications from Models. In: OOIS Workshops 2002, pp. 270–279 (2002) 3. Model Object Facility, http://www.omg.org/spec/MOF/2.0 4. Object Constraint Language, http://www.omg.org/spec/OCL/2.2 5. Conradi, R., Westfechtel, B.: Version Models for Software Configuration Management. ACM Computing Surveys (June 1998) 6. Kulkarni, V., Reddy, S.: An abstraction for reusable MDD components: model-based generation of model-based code generators. In: GPCE 2008, pp. 181–184 (2008) 7. MOFTM Query / Views / Transformations, http://www.omg.org/spec/QVT/1.1/Beta2 8. MOF Models to text Transformation Language, http://www.omg.org/spec/MOFM2T/1.0/ 9. Parnas, D.E.: Designing software for ease of extension and contraction. In: ICSE 1978, pp. 264–277 (1978) 10. Czarnecki, K., Kim, C.H.P.: Cardinality-Based Feature Modeling and Constraints: A Progress Report. In: OOPSLA 2005 International Workshop on Software Factories (online proceedings) (2005)

Mod4J: A Qualitative Case Study of Model-Driven Software Development Vincent Lussenburg1, Tijs van der Storm2,3, Jurgen Vinju2,3 , and Jos Warmer1 1

Ordina {vincent.lussenburg,jos.warmer}@ordina.nl 2 Centrum Wiskunde & Informatica {t.van.der.storm,jurgen.vinju}@cwi.nl 3 Universiteit van Amsterdam

Abstract. Model-driven software development (MDSD) has been on the rise over the past few years and is becoming more and more mature. However, evaluation in real-life industrial context is still scarce. In this paper, we present a case-study evaluating the applicability of a stateof-the-art MDSD tool, M OD 4J, a suite of domain specific languages (DSLs) for developing administrative enterprise applications. M OD 4J was used to partially rebuild an industrially representative application. This implementation was then compared to a base implementation based on elicited success criteria. Our evaluation leads to a number of recommendations to improve M OD 4J. We conclude that having extension points for hand-written code is a good feature for a model driven software development environment.

1 Introduction Model Driven Software Development (MDSD) has gained in popularity the recent years. However, research that directly evaluates the application of MDSD in an industrial setting is still scarce. In this paper we present a qualitative case study to evaluate the use of the state-of-the-art model driven development tool, M OD 4J1 . We evaluate how well an application that is built using M OD 4J fulfills all of its requirements. This research project commenced just as M OD 4J delivered a first, stable version suitable for production use at Ordina. In this version, there is modeling support for three out of four logical application layers and work is being done to support modeling of the presentation layer. We evaluate this early version because we are interested in improving M OD 4J and the applications it generates [5]. The results may also influence the current development of the presentation layer which uses the currently existing functionality as foundation. In the remainder of this section we first motivate and introduce M OD 4J. Then we describe our method of requirement elicitation and product evaluation in Section 2. An in-depth qualitative analysis produces a lot of data and discussion. A full account can be found in [10]. Section 3 contains a summary with the most interesting observations. We discuss threats to validity and related work in Section 4 before we conclude in Section 5. 1

http://www.mod4j.org/

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

Mod4J: A Qualitative Case Study of Model-Driven Software Development

347

1.1 Motivating Model Driven Software Development at Ordina This research has been conducted at J-Technologies, a division of Ordina employing personnel specialized in the Java programming language. The services offered by JTechnologies range from hiring out Java professionals to building and designing software in the in-house development infrastructure called Smart-Java. Smart-Java supports application development by offering the necessary infrastructure tools and services, such as version control, build servers, issue trackers, customized Integrated Development Environments (IDEs) and software artifact distribution. The majority of the applications built in the Smart-Java development infrastructure are web- or service oriented administrative business applications. It is observed that Smart-Java applications were of very different overall quality and their development often suffers from suboptimal velocity, although they are technically very similar to each other. Even the skeletons of basic Create, Read, Update, Delete (CRUD) applications take a long time to be set up. Because Smart-Java is mainly focused on infrastructural services, it has proved to be hard to address these issues. Therefore, the decision was made to investigate the possibility of expanding the Smart-Java development infrastructure to a software product line [7]. As a first step, a multi-tier reference architecture [2] was designed based on the experiences of the leading architects over the last few years. A common, high quality reference architecture enables reuse among projects and addresses important choices regarding non-functional requirements valid for all developed applications. Other objectives and advantages were identified, such as a lower learning curve for developers, as they do not have to learn a new architecture for each project, and improved maintainability. Next, M OD 4J—Model Driven Development for Java— was founded to design and implement a MDSD environment that can support the developers in writing applications within the context of this reference architecture. 1.2 Introducing M OD 4J M OD 4J is an open source domain specific environment for developing administrative enterprise applications. It consists of a number of domain specific languages (DSLs) that are used to describe different aspects of administrative enterprise applications. Currently, there are four: A Business DSL to model the domain of the application. This consists of specifying the classes, properties, associations and business rules of the domain. A Data Contract DSL to define Data Transfer Objects (DTOs) on the domain objects. A Service DSL for defining application boundaries. It encapsulates the application’s business logic, controls transactions and coordinates responses. A Presentation DSL to define user interface components of the application2. An important attribute of M OD 4J is that it provides extension points at every layer for programmer to add Java code to specialize an otherwise fully generated application. The architecture of what M OD 4J generates is depicted in Figure 1. 2

This DSL is currently still under development.

348

V. Lussenburg et al.

Fig. 1. Architecture of M OD 4J-generated code

M OD 4J is implemented using openArchitectureWare (oAW)3, a language workbench [6] supporting activities ranging from the design of DSLs to code generation. The meta-models of the designed DSLs are used to generate rich text editors for use in the Eclipse IDE: they offer code completion, syntax highlighting and as-you-type validation. The XText module also allows validation rules to be specified for each DSL in both the (OCL-like) Checks language and plain Java. For the generation of the application code and configuration, M OD 4J employs a Model-to-Text (M2T) approach [8,12] using the XPand component. The various layers are integrated by generating the configuration for the Inversion-of-Control (IoC) framework Spring4.

2 Research Method First, we discuss how we obtained the requirements, our evaluation criteria. Then we elaborate on the case we selected for evaluation. Finally we describe how we evaluate each criterion on the selected case. 2.1 Evaluation Criteria Based on interviews and a dedicated workshop we have elicited the criteria that should make the use of M OD 4J successful [10]. This has lead to the following three evaluation criteria: 1. Conformance to the reference architecture 2. Functional requirement satisfaction 3. Reduction of hand-written code 3 4

Currently part of the Eclipse Modeling Project (http://www.eclipse.org/modeling/) http://www.springsource.org/

Mod4J: A Qualitative Case Study of Model-Driven Software Development

349

Conformance to the Reference Architecture. By definition, all products in the SmartJava family must conform to the reference architecture [2]. This means M OD 4J must support all common and variable features defined by it. This is an internal criterion, as M OD 4J was designed to fulfill it. Nevertheless, the reference architecture was developed a priori so the question remains whether M OD 4J-generated applications will meet its requirements. Functional Requirement Satisfaction. We need to determine if M OD 4J is suitable to be used to develop any product in the Smart-Java family. M OD 4J raises the abstraction to a higher level and by implication limits expressiveness which might threaten the satisfaction of the more low-level functional requirements [12]. This is an external criterion: given any Smart-Java application will M OD 4J be able to generate it? Reduction of Hand-written Code. The goal of evaluating this criterion is to understand how much M OD 4J will reduce the amount of developer effort. The amount of hand-written code is an easy-to-measure indicator of effort. If the amount of handwritten code would only be reduced marginally, this would invalidate investing in it. Note that a M OD 4J application would contain code written in the four DSLs as well as Java code (in extension points). As an aside, we are also interested in the amount and quality of the generated code. 2.2 Case Selection A representative application has to be selected and (re)built using M OD 4J. To make sure we select a case that is independent of the design of M OD 4J we have chosen an application developed a priori by Ordina ICT: J OB P ORTAL (2006). An existing application also provides us with indisputable requirements to evaluate: the M OD 4J version should simply do the same as the original J OB P ORTAL. J OB P ORTAL was built using the Smart-Java development infrastructure. It is an application to support employees of a recruitment division in their work-flow. Types of activities include assigning an applicant to a recruiter, planning a meeting with the applicant, assigning the application to a reviewer for a review of the CV, maintaining the vacancies, etc. Also, people looking for work can search through the vacancies and send in an application. J OB P ORTAL is implemented as a three-tier JEE application consisting of a data layer, a domain and service layer and two web applications. J OB P ORTAL is too big to re-implement completely (14.5k Non-Commented Source Statements (NCSS) and a total of 23 use cases). Instead, we have taken a sample of the total set of use cases this application provides. The goal of the use case sampling is to maximize the number of insights on working with M OD 4J. The sampling technique we have used to accomplish this is called snowball sampling.. It was used to select use cases one-by-one allowing new insights during the implementation to dictate the choice for a next use case. All this finally lead to the following selection: UC02. Users should be able to search for a vacancy. The use case involves various custom search queries and works with a part of the domain model that is often used in the application. A portion of the domain model had to be modeled, which could be reused in subsequent use cases.

350

V. Lussenburg et al.

UC23. Recruiters should be able to maintain her own vacancies. This might reuse a part of the domain model that was constructed for UC02. As this use case creates, reads, updates and deletes data, it was expected to other new insights into modeling data modifications using M OD 4J UC11. Recruiters should be able to maintain reference data. This use case was chosen because we wanted to work with a new part of the domain model that still had some references to the existing domain model. The rationale for this was that it would yield information on how domain model partitions could be integrated. 2.3 Criteria Evaluation Each criterion needs a method of evaluation, which we describe here. Conformance to the Reference Architecture. In order to determine if the application built with M OD 4J conforms to the reference architecture, we have first extracted the requirements from the reference architecture documentation [2]. In this document, the requirements have been laid down in an itemized, concise manner and therefore the conformance to them can be determined well in a source code walk-through session [11]. As an example, consider the following architectural requirement: Domain objects must keep their internal state consistent. Since M OD 4J allows validation rules to be specified for attributes, such as optionality, maximum length, etc., such rules are fired each time an attribute is changed, keeping the internal state of the domain object consistent. This requirement is therefore considered fulfilled. We introduce the following labels to assess to what extent a requirement is fulfilled: Complete fulfillment. The architectural requirement is completely fulfilled by the code generated by M OD 4J. Note that hand-written code or configuration can still violate the requirement. Partial fulfillment. The rationale of the requirement is present but something is missing. This may occur when a single requirement defines several architectural rules of which some are fulfilled but others are not. Violated. The architectural requirement is violated in the generated code. This label is given even when it is possible to correct or circumvent this violation by manually changing configuration code or implementing extension points. Not at all. The architectural requirement is not addressed at all in the generated code, but developers may add hand-written code at a suitable extension point to fulfill this requirement. If this is not possible the requirement is considered violated. Functional Requirement Satisfaction. Assuming the use cases we selected are representative, observations can be made regarding the fulfillment of the functional requirements relative to these use cases. We consider a use case to be implemented if the M OD 4J-generated application has the same functionality as the original J OB P ORTAL. We have used existing correctness and completeness tests from the base application to find out which functional requirements have been implemented successfully. If an implementation is impeded or made difficult by M OD 4J in any way, we collect a list of issues that cause this impediment. From this list we try to determine the root cause.

Mod4J: A Qualitative Case Study of Model-Driven Software Development

351

Reduction of Hand-written Code. Since we have not completely re-implemented J OB P ORTAL simply comparing source lines is hard. We would need to extract the exact lines of source code that implement our use cases in the original application. This is difficult if not infeasible to do. Instead we base our comparison on completeness and correctness tests. By running these tests in both the existing and the generated J OB P ORTAL we are able to collect statistics about the source code that is executed for each use case. Code coverage statistics are often used during unit testing to determine if all code is tested [16]. In our case, we use the coverage data to learn which byte code is executed for each individual correctness and completeness test, invoking both the M OD 4J implementation and the original implementation. The resulting statistics are detailed enough to distinguish between the original implementation, the manual code and generated M OD 4J code. These metrics are also used to determine the amount of hand-written code. The statistics are created by the free Eclipse plug-in EclEmma5 , a coverage tool that instruments byte code to show which code has been actually invoked by a certain execution.

3 Results In this section, we will answer the question to what degree M OD 4J meets the established criteria. The results have been obtained by completely implementing the three use cases using M OD 4J and its extension points, and then applying the evaluation methods described above on the three selected criteria. 3.1 Conformance to the Reference Architecture Research Data. The complete list of requirements consists of 72 requirements and can be found in the Appendix of [10]. In these tables we have provided the complete list of the requirements harvested from the architecture document [2]. The requirements are categorized according to must, should or may modalities. Here, we present three examples of requirements found in the architecture document: – Domain objects must keep their internal state consistent. – Data Service agents should encapsulate access to just one service. – Domain objects may broadcast events about change in state. Figure 2 provides a graphical overview of the results for all 72 requirements. Note that in this view, the requirements have not been weighted or prioritized and is therefore not suitable for drawing general quantitative conclusions. However, it does show that M OD 4J does not fulfill all architectural requirements. Evaluation. We argue that studying completely fulfilled architectural requirements and all may requirements will yield no interesting observations, unless they √ are violated. To filter out these requirements, we apply the filter in Table 1. The symbol indicates that requirements of the modality in a certain row are taken into account if it is fulfilled according to the predicate in each column. We summarized the determined causes of 5

http://www.eclemma.org/

352

V. Lussenburg et al.

Fig. 2. Requirement fulfillment statistics Table 1. Requirements filter

Must Should May

Violated √

Not at all √

Partial √

√

√

√

−

−

√

Complete − − −

requirement violations in Table 2. We have seen that M OD 4J follows the major parts of the reference architecture, but lacks modeling support for certain variable features [10]. The rows 2, 3, 5, 6, 7 from Table 2 describe the cause of this. These variable features can be implemented by hand using the aforementioned extension points, at a certain cost (see below where we evaluate hand-written code). Cause #1 shows that the terms used in the four M OD 4J DSLs do not map directly to the terms used in the architecture document. This may be expected in the business process layer, where most variability is to be expected between applications in the SmartJava family. Cause #4 we consider to be severe. Because the Business Domain DSL does not allow to define aggregate roots6 , M OD 4J can not make the distinction between a highlevel and normal domain object. Because this distinction can not be made, M OD 4J treats every domain object as a high level object. This prevents modularization of the domain model, which may complicate maintenance. In M OD 4J, this causes superfluous data access logic components which can not be removed by any means; they will always be generated even if they are never used. Other disadvantages include the inability to automatically delete all objects in the aggregate when the root is deleted. This has to be hand-coded in a Java extension. 6

An aggregate root is a cluster of associated objects that is treated as a unit for the purpose of data changes [4].

Mod4J: A Qualitative Case Study of Model-Driven Software Development

353

Table 2. Summary of causes of architecture violations by M OD 4J # Causes of architecture violations by M OD 4J 1 The business processes follow a different nomenclature 2 The reference architecture is unclear on how to implement business work-flows. 3 Service agents can only invoked by business work flows and therefore are not supported as well. Also, implementation can vary greatly and should be occasionally used in the system, making it unsuitable for generation. 4 Business Domain DSL does not allow distinguishing between high-level and lowlevel domain objects. 5 Data service agents implementations can vary greatly and should be occasionally used in the system, making it unsuitable for generation. 6 M OD 4J currently targets systems where the security concerns are addressed by the presentation layer. 7 Functional requirements for paging facilities are not clear. 8 Although a threat to conformance to the reference architecture, extension points are a necessary evil.

Severity − − −

+ − − − −

Table 3. Excerpt from [10]: functional issues with severity # Issue 1 2 4 14

Custom DAO implementation: can not disable generation of code and configuration Cannot not override boolean persistence configuration Binary data types are not supported M OD 4J generates incorrect ORM mappings if a domain object has a many-to-many association with itself. Workaround in place. 15 It is not possible to have a non-persistable domain object. Example: SearchResult. Persistence does not make sense here, yet mapping etc is generated. 17 As the original service is the contract, the amount of service methods exposed in the M OD 4J and original implementation should match up. In reality, the M OD 4J service definition exposes more functionality. 18 Cascading delete has to be hand-written for composite associations, introducing duplicate code (multiple domain services) or violating architectural requirements (calling other DAO’s in a DAO).

Severity Major Blocker Blocker Major Major Major

Major

3.2 Functional Requirement Satisfaction Research Data. We present the encountered functional issues in Table 3. They have been selected from the full record of issues [10] encountered during implementation if they satisfy the following two conditions: – The issue describes a functional limitation or inability. – Severity is major or blocker. Major means a hand-written extension was necessary. Blocker means that the issue prevents the satisfaction of a functional requirement completely.

354

V. Lussenburg et al.

Table 4. Functional requirements satisfaction summary # Observation cause

Severity

1 Persistence configuration is determined from the structural information laid down in the Business Domain DSL and application-wide properties. The offered flexibility does not suffice. 2 The Service DSL is unable to distinguish between domain service and local service. 3 The exact cause for the omission of binary data could not be determined from the research data.

+

− +

Table 5. Byte code instructions executed (normalized) (a) UC02 Select Vacancy

(b) UC23 Maintain my vacancies original M OD 4J manual M OD 4J generated

original M OD 4J manual M OD 4J generated data 346 business 0 domain 545 service 223 total 1114

115 141 4 176 436

93 31 101 533 758

(c) UC11 Maintain reference data original M OD 4J manual M OD 4J generated data business domain service total

339 0 373 70 782

116 56 0 92 264

65 53 156 627 901

data business domain service total

331 0 458 42 831

156 5 29 72 262

102 23 119 420 664

(d) All three in one run original M OD 4J manual M OD 4J generated data 787 business 0 domain 942 service 330 total 2059

387 202 29 340 958

176 107 268 1154 1705

Evaluation. In Table 4 we have summarized and grouped the causes of the issues in Table 3. This Table is the result of manually comparing source code of the original application with the M OD 4J-generated source code. Note that the number of issues encountered while implementing the three selected use cases was quite minimal. Most of the original application could be implemented without any issue. Our choice to focus on even minor violations in this paper is motivated by our research perspective: we need to try and invalidate the claims of MDSD. Still, we determined that issue causes #1 and #3 from Table 4 currently block the satisfaction of certain functional requirements in the J OB P ORTAL case. 3.3 Reduction of Hand-Written Code Research Data. The metric data of the covered code are provided in Tables 5a to 5d. This data has been normalized in order to do a fair comparison. For both the current and M OD 4J implementation the start-up executes quite some instructions (constructors, initializers), which we removed. The rationale is that our implementation is only a partial clone of the original J OB P ORTAL. Initialization code in the J OB P ORTAL may easily be related to use cases that we did not select for this case study. Naturally, the unrefined metric data is also listed in [10].

Mod4J: A Qualitative Case Study of Model-Driven Software Development

(a) Original implementation vs M OD 4J

355

(b) Hand-written vs generated code

Fig. 3. Hand-written code charts

Evaluation. The following evaluation is structured along the design differences between the original J OB P ORTAL and the M OD 4J-generated J OB P ORTAL. After that we evaluate the statistics regarding hand-written code versus generated code. Design Differences. Figure 3a represents a graphical view of Table 5d: – We see that M OD 4J requires 2663 byte code instructions where the J OB P ORTAL requires 2059 (table 5d). Based on these numbers M OD 4J requires more byte code to execute the same business functionality. To determine what the cause of this is, we will zoom in on the differences for each layer. – The original implementation requires more instructions in the data layer for the same functionality (figure 3a, data bar). The cause of the extra code in the data layer of the original implementation is that it has to adapt between behavior-less Transfer Objects used by the persistence framework and business objects used throughout the rest of the application. – The original implementation has three times as much instructions in the domain layer (Figure 3a, domain bar). This is caused by the fact that M OD 4J domain objects combine the original Business Objects and Transfer Objects resulting in a decline of code in the M OD 4J domain layer compared to the original implementation. – The original implementation has no executed instructions in the business layer at all (Figure 3a, business bar). This is caused by the fact that the original implementation has no business layer: the business process logic is coded in the service layer. – The number of instructions required in the service layer is a factor four higher compared to the original implementation (Figure 3a, service bar). In M OD 4J, domain object validation is done in the domain layer. In the original implementation, this is scattered throughout the domain model and service layer, resulting in a code shift from service layer to domain layer.

356

V. Lussenburg et al.

– M OD 4J adds local services, DTOs and DTO translators in the service layer, resulting in a great increase of code in the service layer. The original implementation does not offer a specific course-grained interface and passes the business objects directly to the presentation layer. This means the presentation layer can directly execute business logic by invoking operations on these business objects, something that is not allowed in the reference architecture as all business logic has to be invoked through the service layer. M OD 4J addresses a concern in the service layer that is not addressed by the original implementation. Based on this analysis we conclude that the DTOs in service layer of M OD 4J are the cause of the fact that M OD 4J requires more code for the same functionality. Each DTO more or less duplicates the domain object and there can be, and often are, multiple DTOs for each domain object. For each DTO except custom DTOs there is a Translator that maps between the DTO and the domain object. The resulting amount of generated code is huge, as can also be seen in Figure 3b (service bar). The fact that M OD 4J does not support modeling of aggregate roots required more CRUD methods to be generated, however, the resulting increase in code is negligible compared to the effect of DTO translators. Hand-written Code vs Generated code. Figure 3b is another view on Table 5d, now focusing on the distribution of hand-written and generated code in the M OD 4J implementation only. Based on this data, the developed application was analyzed. 1. M OD 4J requires 958 byte code instructions from hand-written Java code, where the J OB P ORTAL code is all hand-written, to a total of 2059 byte code instructions (Table 5d). Based on these numbers, we conclude that M OD 4J has succeeded in decreasing the amount of hand-written code. Note that hand-written code compared to the original implementation is reduced by more than 50%. However, we also identified in the previous section that the service layer has no real equivalent in the original implementation. The actual gain is therefore even more because more then 50% of the hand-written code is located in the service layer. The actual reduction of hand-written code might therefore be as large as 75%. While the sample we have done is not by any means large enough for this conclusion to be statistically significant, it is hard data for a real case. 2. Of all the code in the analyzed sample, 64% is generated (Table 5d). This excludes start-up and initializing code as these have been subtracted during normalization. The unnormalized amounts would indicate that 71% of the total code is generated [10]. 3. The data layer has a large amount (68%) of hand-written code (Figure 3b). Further analysis on the source code of the M OD 4J implementation shows that this is caused by hand-written data access logic methods. We have spotted several opportunities of code that might also be generated, which are discussed in [10]. 4. The domain layer is almost void (10%) of hand-written code (Figure 3b). This is caused by the fact that the J OB P ORTAL functionality required little behavior and validation to be defined. Most functionality was implemented in the data layer, just like in the original implementation. An example is retrieving the Vacancies for a certain User: it is more efficient to determine this by executing a query on

Mod4J: A Qualitative Case Study of Model-Driven Software Development

357

Table 6. Observations on reduction of hand-written code # Observation cause 1 Custom methods require a lot of boiler-plate code, causing a large portion of the handwritten code. It may be an opportunity to support more methods to reduce the amount of hand-written code. 2 When using custom DTOs in a service method, the invocation to the domain service has to be hand-written due to the fact that the custom DTO can not be mapped onto a domain object. Since we argued that custom DTOs are not required, removing them and allowing simple types to be entered in the service method definition will result in less hand-written code.

Priority +

+

the database then by traversing the entire object structure. Most validations in the domain model were quite simple (i.e., maximum length) and were automatically generated from the rules in the Business Domain DSL. 5. The business layer has a large amount (66%) of hand-written code (Figure 3b). Closer inspection of the implementation showed that some parts of this code pertained to boilerplate code that could have been generated Also, the large amount of hand-written code is to be expected, as the business logic should naturally be the most variable part of an application in the Smart-Java family. 6. The service layer has a considerate amount (23%) of hand-written code (Figure 3b). Contrary to expectation, a lot of boilerplate code to invoke the domain service had to be hand-coded. We have summarized the severity of the identified observations in Table 6. We have seen that the amount of hand-written code, for the functionality that could be fully rebuilt, has decreased compared to the original, hand-written application. Although the Java extension points provided by M OD 4J were used, they certainly did not result in a cost that would shadow the gain of code generation from abstract models. We did identify two opportunities, cause #1 and #2 in Table 6, to decrease the amount of hand-written code.

4 Discussion An in-depth qualitative evaluation of a single software product such as J OB P ORTAL does not necessarily lead to grand conclusions. Nevertheless, here we have extensively studied one application, generated for the most part by a state-of-the art MDSD tool. We have observed that a non-trivial application which existed a priori could be implemented using M OD 4J, with a number of (minor) unforeseen issues. Since we have not completely rebuilt the whole application, a threat-to-validity of the above observation is that we might have uncovered more vulnerabilities later. Our snowball sampling technique was designed to mitigate this effect. We feel confident that we have sampled a most difficult and relevant part of the application, but we must pay attention to this completeness issue nevertheless.

358

V. Lussenburg et al.

We have focused on three evaluation criteria that were elicited from a professional team at Ordina, using exploratory interviews and an in-depth workshop. We do not know whether our resulting focus on architecture, requirements and amount of handwritten source code is representative for other software development projects. Naturally, different criteria would lead to a different study of the quality of M OD 4J. We would like to observe that any software is subject to a changing environment and changing requirements [9]. We therefore believe that the existence of extension points for hand-written code, such as offered by M OD 4J, is essential. It allows the programmer to adapt to changing or unforeseen circumstances without having to directly adapt the model driven development environment. In the J OB P ORTAL case, extension points were used to implement features that were expected not to be generated, as well as features that might have been generated if M OD 4J would provide such a feature. Note that exactly these hand-written extensions are considered a bad thing from another viewpoint. We conclude that a model driven development environment should evolve with the applications that it generates. Frequent qualitative analyses such as performed in this paper, are necessary to update and refresh the model driven development environment such that the use of extension points will not start to outweigh the benefits of modeling and code generation. 4.1 Related Work Smart-Microsoft. Warmer, the project leader of M OD 4J, has designed a model driven software factory before: the Smart-Microsoft software factory. His experiences are described in [15]. In this paper, the chosen DSLs and architecture are explained in detail. Of course, Warmer’s experiences have had a great impact on M OD 4J and the DSLs are very similar to those in Smart-Microsoft. It would be interesting to compare the results from this study with the projects done in the Smart-Microsoft software factory. However, as the research assignment was primarily scoped on M OD 4J we did not have the time to gather the project data as this was not readily available in the organization. Generation of Web Applications. Visser [14] presents a case study in domain-specific language engineering. He designs and implements a number of DSLs which generate a web application for the full one hundred percent. Visser uses the SDF2 formalism to define a concrete syntax for the DSLs and term rewriting to generate code. While the case study in conducted in the same area M OD 4J focuses on, the focus of the paper is quite different. Visser explains that, in the first place, his work is intended as a case study in the development of DSLs. Although the approach of generation of web applications that Visser employs is comparable with the approach that M OD 4J follows, Visser’s conclusions do not directly overlap or contradict our own. Changeability in Model Driven Web Development. Van Dijk [3] carries out an experiment to assess the changeability of model driven development of small to medium size web applications and compares it to the changeability of classically developed projects. He concludes that the changeability of web applications developed in model driven approach is competitive with classical approaches. The experiments are not carried out on real-life projects but rather on a small application developed by Van Dijk himself. Like

Mod4J: A Qualitative Case Study of Model-Driven Software Development

359

M OD 4J, he uses the openArchitectureWare tooling to design the meta models of the DSLs and the templates used for code generation. Because our study did not focus on changeability, Van Dijk’s conclusions do neither contradict nor confirm our own conclusions. Adoption of Model Driven Software Development. Related work on evaluating model driven engineering is relatively scarce. A large case-study to evaluate model driven engineering practices at Motorola is described in [1]. The study reports that an infrastructure division at Motorola achieved 65%–80% code generation by applying model driven engineering principles, leading to overall improvements in productivity and quality. These observations seem to be consistent with the results in this paper. Staron [13] investigates the factors that influence the adoption of MDSD at two companies. One of the conclusions of this study is that modeling tools should be integrated in the software development process without completely redefining it. This is compatible with our observations as to how much M OD 4J generated applications conform to the reference architecture of J-Technologies.

5 Conclusion We have done an extensive evaluation of the suitability of M OD 4J for building applications within a domain defined by a reference architecture. By eliciting the criteria in a structured way, consulting both literature and experts, we have selected criteria for evaluating M OD 4J. Next, we have set up a research method with a strong focus on data validity to evaluate these criteria. The study resulted in a number of issues and causes thereof which may be remedied in the design of M OD 4J. We conclude that M OD 4J is suitable to be used to build applications that fall within the domain of the Ordina J-Technologies reference architecture. Since we have indications that up to 71% of the code can be generated, we think it probable that applications will be built with less effort than before. We found that the use of hand-written code using the extension points of M OD 4J was instrumental in implementing the fine details of some functional requirements. We propose that designers of model driven development environments introduce such a feature and at the same time try to prevent its usage by (incrementally) perfecting their modeling languages.

References 1. Baker, P., Loh, S., Weil, F.: Model-driven engineering in a large industrial context—Motorola case study. In: Briand, L.C., Williams, C. (eds.) MoDELS 2005. LNCS, vol. 3713, pp. 476– 491. Springer, Heidelberg (2005) 2. van Boxtel, P., Malotaux, E.J., Tjon-a-Hen, P.: Ordina Java Referentie Architectuur. Ordina J-Technologies, version 1.1 (2008) (in Dutch) 3. van Dijk, D.: Changeability in model-driven web development. Master’s thesis, University of Amsterdam (2009), http://dare.uva.nl/en/scriptie/313029 4. Evans, E.: Domain-Driven Design: Tackling Complexity In the Heart of Software. AddisonWesley Longman Publishing Co., Inc., Boston (2003)

360

V. Lussenburg et al.

5. Fagan, M.: Design and code inspections to reduce errors in program development. In: Software Pioneers: Contributions to Software Engineering, pp. 575–607. Springer, New York (2002) 6. Fowler, M.: Language workbenches: The killer-app for domain specific languages? (May 2005), http://www.martinfowler.com/articles/languageWorkbench.html 7. Greenfield, J., Short, K., Cook, S., Kent, S.: Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley, Chichester (August 2004) 8. Kleppe, A.: Software Language Engineering: Creating Domain-Specific Languages Using Metamodels. Addison-Wesley Professional, Reading (2008) 9. Lehman, M.: On understanding laws, evolution, and conservation in the large-program life cycle. Journal of Systems and Software 1, 213–221 (1979) 10. Lussenburg, V.: Mod4J: A qualitative case study of industrially applied modeldriven software development. Master’s thesis, Universiteit van Amsterdam (2009), http://dare.uva.nl/en/scriptie/321845 11. Myers, G.J.: The Art of Software Testing, 2nd edn. Wiley, Chichester (June 2004) 12. Stahl, T., Voelter, M., Czarnecki, K.: Model-Driven Software Development: Technology, Engineering, Management. John Wiley & Sons, Chichester (2006) 13. Staron, M.: Adopting model driven software development in industry—a case study at two companies. In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 57–72. Springer, Heidelberg (2006) 14. Visser, E.: WebDSL: A case study in domain-specific language engineering. In: Lämmel, R., Visser, J., Saraiva, J. (eds.) GTTSE 2007. LNCS, vol. 5235, pp. 291–373. Springer, Heidelberg (2008) 15. Warmer, J.: A model driven software factory using domain specific languages. In: Akehurst, D.H., Vogel, R., Paige, R.F. (eds.) ECMDA-FA 2007. LNCS, vol. 4530, pp. 194–203. Springer, Heidelberg (2007) 16. Zhu, H., Hall, P.A.V., May, J.H.R.: Software unit test coverage and adequacy. ACM Comput. Surv. 29(4), 366–427 (1997)

Modeling Issues: A Survival Guide for a Non-expert Modeler Emilio Rodriguez-Priego, Francisco J. García-Izquierdo, and Ángel Luis Rubio Departamento de Matemáticas y Computación Universidad de La Rioja Edificio Vives, Luis de Ulloa s/n E-26004 Logroño (La Rioja, Spain) {emilio.rodriguez,francisco.garcia,arubio}@unirioja.es

Abstract. While developing an integral security model to be used in a Service Oriented Architecture (SOA) context, we find a lot of ambiguities and inaccuracies when authors speak of models, metamodels, profiles and so on. This led us to study a great number of references in a search for precise definitions to help us to address our research. Our study and discussions were so extensive that we are convinced they will be a valuable contribution to the community. In particular, in this paper we present several Reference Concept Maps that depict graphically a large number of definitions with their associated bibliographical references. Nevertheless, we truly believe that there are still a lot of concepts to be clarified and that this clarification is essential so that basic modeling concepts can be best used by non-expert modelers. Keywords: Modeling concepts, Reference Concept Maps, Metamodeling issues, Stereotypes.

1 Introduction To be clear from the very beginning: our goal was not to write a paper like this. Our main current research interest concerns security, more specifically the development of an integral security model to be used in Service Oriented Architecture contexts [1]. As a first step of our research we began a deep revision of the literature that quickly showed us that a majority of approaches related to our field of interest define either a UML Profile or a MOF/UML metamodel. But this situation only gave rise to new questions: Which approach is best suited for our needs? How can we evaluate each of them (considering that they even provide different results)? And most important, what are the really essential concepts underlying each approach? From here we began a nearly endless journey (with a lot of branches) through a vast amount of references dealing with models, profiles, metamodels and with modeling concepts in general. Unfortunately, we came across the fact that there is no apparent consensus about the terminology, not even about what should be the minimal set of basic modeling concepts. In our opinion this is a real obstacle on the way to the development of a specific model/metamodel, especially for people like us, who have D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 361–375, 2010. © Springer-Verlag Berlin Heidelberg 2010

362

E. Rodriguez-Priego, F.J. García-Izquierdo, and Á.L. Rubio

recently arrived in the modeling world coming from the security world. We devoted a great amount of time trying to understand the usually imprecisely defined concepts, the terminology inconsistencies among several authors, the ambiguities in the official standards, and so on. When we were somewhere in the middle of this journey, we met the paper ‘Modeling Modeling’ [2], presented in the latest edition of the MODELS conference. Unlike that paper, it was not our aim to make ‘a contribution towards a theory of modeling’. However, some sentences throughout that paper (especially in the introduction: ‘a lot of people are using models […] without knowing it’, ‘there is […] neither precise description about what we do when we model, nor rigorous description of the relations among modeling artifacts’) encourage us to continue our work. The survey that we present in this paper is a summary of our walk-arounds and private discussions about modeling concepts, and we consider that it can be a valuable contribution for the modeling community. We have revised a total of 200 references regarding modeling, from ‘ancient’ references of 1956 to extremely recent (dated 2010) ones1. Obviously we are not able to include all these references in the paper because of space reasons. Therefore, we have made a selection of 66 papers which we believe are a significant sample of all the articles reviewed. The paper can be regarded as a well suited guide to find documentation related to recognized problems around modeling. More specifically, this guide is structured as follows. In the following section we deal with those we consider to be the basic modeling concepts. One of the main contributions of this section is the use of a new type of concept map [3], which summarizes the most relevant definitions of these basic concepts found in the literature. Section 3 is devoted to discussing some of the most critical issues about modeling, comparing the contributions of a broad spectrum of authors. In the last Section of the paper we present some conclusions.

2 Basic Concepts in Modeling The basic modeling concepts have been and are still under discussion in the literature. In order to clarify these terms we did an analysis of the main references using concept maps [3]. These maps, which we named Reference Concept Maps (RCM), help to identify the key concepts that appear in each of the term definitions and their relationships. A RCM shows main concepts related to other concepts displayed in different colors depending on their conceptual proximity, within a definition, to the main concepts. Links between the concepts include the numbers of the references where the term definitions are given. The use of RCM to summarize definitions can be considered as an original contribution of this paper. This section aims to enumerate aseptically modeling concepts and their definitions without critically evaluating them. We postpone this discussion to section 3. 2.1 Pure Modeling Concepts Let’s start at the beginning, the concept of Model. Surprisingly, or not, there is no generally accepted definition of model. The RCM of Fig. 1 shows that, in a first level, 1

The complete list can be consulted in Citeulike http://www.citeulike.org/group/13305 or Mendeley http://www.mendeley.com/research-papers/collections/1689661/Model-Theory/

Modeling Issues: A Survival Guide for a Non-expert Modeler

363

model can be identified as different concepts: representation [4, 5, 6, 7, 8, 9], abstraction [10, 11], statement [12], simplification [7, 13, 14], description [6, 15, 16, 17], specification [6, 15], system [18, 19], entity [14, 19, 20], set [21], replacement [12, 14, 18] or subject [22]. In a second level, model is related to terms such as system [7, 10, 11, 12, 13, 15, 16, 18, 19, 21], reality [6, 8], original [14, 19, 20], software [17] or mental construction [9]. Lack of space prevents us from developing all the definitions completely, but the reader can easily do it following each reference number throughout the RCM links.

Fig. 1. References Concept Map for model

In the RCM of Fig. 2 we summarize the definitions of other concepts related to model, definitions that seem to confirm the claim in [4] stating that “everything is a model”. Metamodel is directly related to model [11, 12, 15, 18, 23, 24], specification [4, 6, 21], definition [10, 12, 13, 24], representation [6] and description [7], and indirectly related to concept [7, 13, 24], abstraction [4], modeling [23], or abstract syntax [10, 12, 24]. Megamodel is essentially a model of models [5] or a model of MDE concepts [25]. And Ontology is generally defined as a type of model or special model [6, 26] or as a model subset [9]. Finally, the reader can also see how the concept of Modeling Language is closely related to other concepts apart from the Model concept (Fig. 1). In general, most authors, e.g. [10, 12, 24], identify the abstract syntax of a (modeling) language with the concept of metamodel (set of concepts used to create models), and its notation with its concrete syntax (textual or graphical representation of those concepts) [27, 28]. Both syntaxes have a many-to-many relation, meaning

364

E. Rodriguez-Priego, F.J. García-Izquierdo, and Á.L. Rubio

Fig. 2. References Concept Map for metamodel, megamodel, ontology and modeling language

that a model can be expressed in different notations, and that a notation can be used by different languages [12]. 2.2 Relationship Related Concepts The two main types of relationships addressed by literature are representation/specification and conformance. The former are the basic relations between a model and its modeled entity. Depending on the point of view, the Representation relationship, or the models being related by it, have different names: represented-by [4], representation-of [29, 30], descriptive models [4, 21, 31], backward-looking models [12], model as copy [26] or reverse engineering [30]. The same happens to Specification, which also has different names: prescriptive models [4], specification models [21], forward-looking models [12], model as original [26] and forward engineering [30]. On the other hand, and regarding to conformance, some authors [4, 7, 29] name the relation between a model and its metamodel conforms-to, differentiating it from the previous representation/specification relations used to relate a model and its modeled entity. 2.3 The OMG Approach to Modeling Concepts and Relationships Classes, Metaclasses and Stereotypes. UML [32] defines Class as “a type that has objects as its instances”, and type as “a named element that is used as the type for a typed element” (note that this is an ‘empty’ definition, because the definition contains the defined concept). In addition, UML defines class as “a kind of classifier whose features are attributes and operations”. There is no explicit definition of metaclass in [32], being understood that a metaclass is a class whose instances are classes. A stereotype is “a limited kind of metaclass that cannot be used by itself, but must always be used in conjunction with one of the metaclasses it extends” [32].

Modeling Issues: A Survival Guide for a Non-expert Modeler

365

Instantiation. OMG names the relationship between an instance and the class to which it belongs instance-of [32], and uses it in each one of the different levels of abstraction (instance-class, class-metaclass and metaclass-metametaclass). Inheritance/Generalization. OMG defines Generalization as “a taxonomic relationship between a more general classifier and a more specific classifier” [32]. Package. “A package is a container for types and other packages” [32]. The package concept plays a very relevant role in the modeling based on OMG standards, since “the Model construct is defined as a Package” [33]. Merge. The Merge concept is defined by OMG [32] as “a directed relationship between two packages, that indicates that the contents of the two packages are to be combined”. The Merge semantics is very similar to that of inheritance, in such a way that it can be considered as the application of inheritance to packages. Nevertheless, it is a complex concept, which requires an extensive description of ten pages [32, pages 161-170], and its application is not without problems [34, 35, 36, 37]. There are simpler proposals for the extension of models that do not use Merge [38].

3 Discussions about Modeling Some modeling concepts have generated a lot of controversy and endless discussions, whereas other concepts are not clear enough and are still difficult to apply. Next, we list what, in our opinion, are the main causes of confusion in the use of the modeling concepts and theories. They are numbered and classified into three groups: 1) issues about relations between object-oriented concepts and modeling, 2) main points of discussions related to modeling layers, and 3) metamodeling issues, mainly focusing on stereotypes. 3.1 OO Modeling Issues OOM1–Modeling as an Object Oriented Implementation. The overlapping of object orientation (hereafter OO) concepts (class, instance, object, inheritance…) and modeling concepts (model, representation, specification…) is likely to be one of the main sources of confusion when one tries to understand what the modeling is and how it is applied. The adoption by OMG, responsible for most of the more widely used modeling standards, of an OO approach for the construction of models, has only made the mess bigger. The source of such confusion stems from the fact that both OO concepts and modeling concepts are homomorphic [12]. Concepts such as class, instance, inheritance, etc can be used to unambiguously model physical systems. But, when the modeled system is at the same time a model, the use of such terms is confusing and repetitive. Note that then, the same model elements that make up the modeled system are being used to metamodel. This is what several authors call concept replication [39, 40]. Actually, as [25] points out, “object-oriented technologies are used to implement MDA standards”, instead of being the foundation of modeling. Just as an example, MOF describes its generic term ‘Element’ as an ‘Object’ specialization. This may be

366

E. Rodriguez-Priego, F.J. García-Izquierdo, and Á.L. Rubio

very confusing for a reader versed in OO, who cannot easily understand that object and model element are equivalent concepts. OOM2–Overuse of the Class Concept. Whenever the class concept is used in modeling, we have to ask ourselves “class, what class?” Depending on the specification, even on the package being used (e.g. UML-profile), UML and MOF repeatedly employ the class and instance concepts with apparently similar, but essentially different, meanings. This leads to great terminological confusion that forces the modeler to carefully consider the context in which the concept is used, to exactly understand its sense. The specifications even warn about the possibility of the same term being used with different intentions in the same section. E.g., [33] section 18.1.1 says: “Thus, in this clause, when we mention ‘Class’ in most cases we are dealing with the metametaclass ‘Class’ (used to define every meta class in the UML superstructure specification (Activity, Class, State, Use Case, etc.)” (emphasis added). The sentence seems to say that the reader must recognize in most cases the actual class to which the section refers. Specifically, as we are later presenting in the stereotypes section, this overuse has caused lively discussions about the true meaning of class in some cases [41, 42]. OOM3–Overuse of the Instance-Of Concept. The fact that, throughout the different UML versions, the term instance has been used both to denominate the M0 level instances and the “abstract metaclass” that represents them at M2 level has caused quite a few discussions about the nature of instance [4, 12, 13, 21, 40]. Actually, instance doesn’t have a double nature, but, by calling them in the same way, both concepts are being mixed up into a single one. UML version 2 tries to resolve the controversy introducing a new concept, InstanceEspecification, defined as “a model element that represents an instance in a modeled system”. Though the term instance has been clarified, the instance-of expression is frequently used [10, 32], in such a way that in the OMG approach, virtually every treated concept is instance-of something. Nevertheless, several authors [4, 7, 12, 43] specify that this approach is too restrictive because there are semantic differences among the instantiation undergone between a metamodel and a model, or a model and a modeled real object, or a predicate calculus formula that is generated-by the predicate calculus grammar [7]. E.g., a model is not always an instance of a metamodel [4], though it can be implemented using instances of model elements that, at the same time, are realized using classes. Note that a metamodel could be implemented using relational tables, and its associated models realized using tuples of these tables [6, 44]. If, on the other hand, the Entity-Relationship had been the choice for the modeling, the discussion, and the confusion, would have involved the terms entity-type, entity, association-type, association and model, model element, and so on. The homomorphism existing among these concepts is the root of the confusion. To resolve the situation, some authors propose that, to fully understand the model and metamodel concepts, the discussion should be carried to the ontological level [24]. OOM4–The Object Orientation in Modeling Does not Necessarily Lead to an Object Oriented Model. In UML, the identification of a model element with a class (of M2 level) may lead us to think that object orientation concepts are always present

Modeling Issues: A Survival Guide for a Non-expert Modeler

367

in modeling. Actually, this is not true, because UML lacks a strict object oriented approach from the modeling point of view. E.g., the static part of a model, which UML names structure, and its dynamic part, named behavior, are usually separated [45]. Though the specification introduces some relationships between both parts of a model, they are not very explicit indeed. Most diagrams focus on a certain single aspect (static or dynamic), but there doesn’t exist any diagram that clearly expresses both together, as should be expected from a full object oriented approach. The object orientation appearance of UML is mainly reflected in the class diagrams, in which a class exhibits its collection of attributes (state) and methods. However, the inclusion of methods in class models is paradoxically infrequently used when they are used to express models. Some authors [46] conclude that, even when they are building high level models, they don’t need to include methods in their models. In practice, the definition of methods in UML classes are often referred to the management of the class state (set- and get- methods), rather than to the representation of the class behavior. Summarizing, we could say that whereas UML is implemented using an OO approach, models created using UML rarely follow that approach, except when a class view is used. Moreover in the M2 level (UML specification), the behavioral part of the UML metamodel is devoted to specify the behavior of an hypothetic UML modeling tool. OOM5–A Model Shouldn’t Be More Complicated than its Modeled Entity. As we have pointed out in section 2.1 (RCM of Fig. 1), a model can be considered as a simplification of reality that can be used to handle it in a simpler way. The UML metamodel is an example in which this rule is violated. The UML metamodel is so complex that it can only be analyzed, managed and verified effectively with the aid of tools. Such complexity implies that determining the semantics of the modeling concepts defined in UML is not a simple task if it is done manually, because “the required information is scattered across the metamodel” [47]. The more complex a system is, the greater the possibility of making errors. Some authors have used different formal techniques, which are usually supported by automated tools, to study certain aspects of UML. Thanks to them, a number of errors and inconsistencies across different versions of the UML metamodel have been found, e.g.: [37] on package merge, [48] on associations, [49, 50] on general UML semantics, [51] on generalization and overriding, and [52] on UML 1.x. 3.2 Model Layers Issues ML1–Lack of a Minimal Top Level Model. UML and MOF are based on a hierarchy made up of four levels named M3 (meta-metamodel), M2 (metamodel), M1 (model) and M0 (run-time instances). This structure is closely inspired by the ANSI IRDS and by EIA/CDIF [53]. The application of these levels in UML is quite confusing. On the one hand [32] states that MOF is the meta-metamodel for UML and other metamodels, saying also that a part of UML called Core is used to specify MOF. The obvious question is then: would Core be the meta-metamodel of both? To solve the problem, the authors name that Core subset of UML Metalanguage kernel, a claim that seems to imply that that metalanguage is a constituent part of the metamodel,

368

E. Rodriguez-Priego, F.J. García-Izquierdo, and Á.L. Rubio

contributing even more to the confusion of both terms. The confusion is greater due to the same concepts (package, class…) being extensively used in the definitions of metamodel and metalanguage. Again, the (over)use of the term instance-of to relate concepts belonging to two consecutive levels is the root of the problem. The unsuitability of this approach is reflected in the various problems that arise when trying to implement this scheme without relinquishing its OO root. E.g., some proposals to resolve the problem are: to distinguish between two types of instance-of (ontological and linguistic) [54, 55]; the possibility of instantiation across levels (deep instantiation) [40, 56, 46]; to differentiate between linear hierarchies and non-linear hierarchies (the instantiation is also produced within the same level) [43]; to define relationships between levels different from instance-of, e.g., conforms-to, represented-by [4, 12] and others. The self-model character that both MOF and CDIF give to the M3 level is also subject to analysis. Without leaving the 4-levels approach, [57] proposes a somewhat simpler top self-model alternative (14 classes compared to 18 in Ecore and 24 in MOF). [21] gives the name minimal reflexive metamodel to that metamodel in which “any statement in the minimal reflexive metamodel can be represented in terms of elements of the minimal reflexive metamodel”. The paper also analyses the problems of its application. [43] discusses the pros and cons between a recursive top level metamodel and an axiomatic top level metamodel. [12] analyzes the problems driven from the fact that MOF is not minimal, concluding that “true self-model should be minimal”. To our knowledge, despite the fact that several authors [12, 37] have expressed its need, there is no proposal of minimal top model (recursive or axiomatic) that helps to avoid these problems, clarifies the modeling theory and constitutes the true kernel of modeling. It is understood that this is an open research problem that poses many difficulties. E.g. [12] suggest the use of two ontological universal concepts: “things” (nodes) and “connections between things” (arcs). However, even with this simple approach, the authors find problems, presenting an example in which a certain concept can be considered as a node or as an arc. ML2–Bidirectionality and Cardinality between Model and Modeled System. A central issue that always comes up in any discussion about the essence of modeling is the use of a model as a description or as a specification of a modeled system. As we have mentioned before (sec. 2.2), literature uses different names to denominate the description and specification of models. We must take into account that these terms are always used to characterize the way the model is used, not to label the model itself. When used as a description, the model represents (describes) an existing system, whereas, when used as a specification, the model specifies (prescribes) a system that doesn’t exist yet. This bidirectional feature of modeling has great importance for MDE, since it allows understanding and the application of the modeling to the description of existing models or to the generation of new ones. Nevertheless, the bidirectionality is lost when the OMG specifications are used, mainly due to instance-of being the only relation between modeling levels. This means, e.g., that in UML it is easy to create new instances belonging to a system specified by a model, but, in turn, UML does not provide a mechanism to check that a certain entity is described by a

Modeling Issues: A Survival Guide for a Non-expert Modeler

369

model. A conscientious revision of MOF may show this bidirectionality in certain situations, only when the instances have been previously created ([23] sec. 9.2). [58, Fig. 3] considers another type of model, called explorative, which is at the same time prescriptive and descriptive and in which “modifications are applied to the model rather than to the real system”. “When their effect seems to be positive, the modifications are applied to the original”. This approach is also addressed by [30], which calls them models at runtime. The complexity of this solution lies mainly in two aspects: 1) the model must keep up with the changes in the system and viceversa; and 2) the system needs to gain access to the model. In this scenario, the models are not necessarily represented by a set of objects. Instead, they make up a repository of modeling elements, which constitutes by itself a system that interacts with the systems that it specifies or describes. The cardinality of the relationship between elements from one level to the next (models and modeled systems) is another important aspect not addressed in UML/MOF. [12] proposes an interesting classification, distinguishing among (1) isotypical mappings, “as those that map one model entity to one system under study (SUS)” entity; (2) prototypical mappings, “that map one model entity to a set of SUS entities give by example”; and (3) metatypical mappings, that “is prototypical mappings given declaratively”. 3.3 Metamodeling Issues MM1–Stereotypes issues. OMG provides a widely used alternative to the construction of metamodels called UML Profiles [59, 60, 61], redefined in the latest revision of the standard [62]. The first problem we encounter when applying this option is to decide whether, instead of using it, it is more convenient to use an approach based directly on MOF metamodeling. The specification authors [32], after describing the mechanism, admit that “there is no simple answer for when you should create a new metamodel and when you instead should create a new profile”, deducing that there is an answer to that question, but that the answer is complicated. However, it is necessary to answer that question, since from that claim it is also deduced that the MOF and UML Profiles approaches are so significantly different that an inappropriate choice in an entire application can compromise the result. Next, we discuss the most relevant aspects of the semantics associated with the definition of a UML Profile, just as they are defined in [32, 33], aspects that give an idea of its complexity, as well as the difficulties that its application entails. MM1.1–An UML-Profile is a package. If we trace the terms involved in the package

concept definition throughout the UML specification [32, 33] we find a complex labyrinth of cross-definitions (‘packageable element’, ‘element’, ‘concept’, etc.) scattered across the modeling levels. This fact is a confirmation of the opinion stated in [47] about the understandability of the UML semantics, which can only be addressed using “query/extraction tools”. Another example of this complexity is the fact that the UML-Profile specification provides for the possibility of inheritance between profiles, a feature that is rarely used.

370

E. Rodriguez-Priego, F.J. García-Izquierdo, and Á.L. Rubio

MM1.2–In what level is UML-Profile defined? The M2 elements of a UML-Profile are defined using a M3 concept (Stereotype), which is materialized in a M2 concept [32, 33]. The problem with this approach is that stereotype is a specialization of another concept, called again ‘class’, that embraces all UML Elements (e.g., Actor, Activity, etc. of M2 level) and, therefore, it should be defined at the M3 level (actually it should be MOF::Class). To solve the problem, the authors resort to the trick of using the implementation of MOF::Class defined in the UML-InfrastructureLibrary package, establishing that Profiles::Class inherits from InfrastructureLibrary:: Core::Constructs::Class. Though it seems correct, a new problem arises, because, having forced the definition of M3 level concepts at the M2 level, it isn’t possible to perform the XMI serialization of a model. To do it, not surprisingly, the authors have to define a correspondence between Stereotype and MOF:Class and between Profile::Class and MOF::Class [33] section 13.1.6]. This non-trivial usage of an M3 concept by an element of M2 has led to many discussions and criticism of the semantics of UML-Profile (see e.g. [41, 42]). MM1.3–The extension association. [33] introduces another type of association named Extension, which links a Stereotype (M3) with a Profile::Class (M3). As expected, Extension is a specialization of InfrastructureLibrary::Core::Constructs::Association. Despite a stereotype being a Profile::Class specialization, to extend a stereotype with another stereotype is not allowed, whereas, though with some restrictions, it is allowed for a stereotype to participate in associations ([32], sec. 13.1.6). Note that this allows the definition of a stereotype that, for example, extends to both Actor and State concepts, and that, besides, is associated with another stereotype that extends to an activity. The specification [33], sec. 18.1.2] leaves in the modeler’s hands that “the specialized semantics do not contradict the semantics of the reference metamodel”. MM1.4–Interoperability, not yet. One of the main arguments for using UML Profiles is that they are supported by various UML editors, which facilitates the exchange between the different tools. Nevertheless, this theoretical interoperability is not always feasible due to: (1) there are several mutually incompatible versions of XMI and UML; (2) the XMI standard does not consider the diagram representation, and, currently, this functionality is covered by proprietary extensions; (3) usually tools do not implement the whole standard because of the complexity of the OMG specifications. In 2006, OMG issued the UMLDI [63] standard, with the purpose of supporting “storage and exchange of information pertaining to the layout of UML Models”. In practice, as admitted by OMG, “the DI standard itself is not precise enough to enable consistent exchange of diagrams between different tools” [64, pag. 21], and it is currently subject to a revision process that finally will enable its adoption by the UML tool providers. MM2–Inheritance and Metamodeling. Two types of relationships are the basis of object orientation: instance-of, between an instance and its class, and inherits-from between a subclass and its superclass [4]. Although both relationships are applied to different elements, some confusion may appear when they are described using the natural language. E.g., the integer ‘8’ can be obtained from the class ‘Integer’ and, therefore, we can say that ‘8 is an integer’. Similarly, if ‘Animal’ is the superclass of

Modeling Issues: A Survival Guide for a Non-expert Modeler

371

‘Cat’, we can say that ‘cat is an animal’. In both cases, ‘is-a’ has different meanings. In the first case, 8 is an instance of the class Integer, whereas an instance of Cat is also an instance of Animal (thanks to the transitivity, it is an instance of Animal because it is an instance of Cat). Papers such as [65, 66] analyze the consequences derived from the use of the inheritance or the instantiation across levels in modeling (metamodeling). [4] studies the use of the inheritance and the instantiation relationships in OO, comparing them to the conforms-to and represented-by relationships in the modeling theory. On the other hand, [6] defines a similarity relationship that embraces different relationships: subset-of, is-described-by, is-represented-by, instanceof and is-a. The paper concludes that ‘is-a’ is a specialization of subset-of and isdescribed-by, but not of instance-of, and that described-by and instance-of are specializations of is-represented-by. The confusion that, from a generic point of view, exists between classification (a concept close to instantiation) and generalization (inheritance) has been recently analyzed again by [67], highlighting that there still exists a conceptual problem concerning inheritance and instantiation, concepts that are still incorrectly applied. This problem arises more frequently when UML is used, especially due to two reasons: 1) the semantics of the inheritance in UML “is highly complex, scattered over many diagrams, constraints and additional operations sections and is very difficult to understand” [51]; and 2) the confusing definition of stereotypes, placed between the M2 and M3 levels, has resulted in misuses of stereotypes in M1, when the correct modeling technique should have been to use inheritance (see e.g. [42, 68]).

4 Conclusions The main conclusion that we can draw is that, despite of the many discussions (that have been widely documented in literature), there are still a lot of confusing notions in the field of model-driven engineering. Even after our journey we feel close to the authors of [2], when quoting Ludewig [58], who in turn claims that “nobody can just define what a model is […] endless discussions have proven that there is no common understanding consistent of models”. We believe that a solid foundation for a minimum set of modeling concepts is critical to the success of MDE. Here we have made a modest contribution in this sense summarizing a series of issues that we, mere model users, consider should be resolved. In addition, we propose several Reference Concept Maps, which can serve as a tool from which to continue the discussions. Much work remains to be done by model/metamodel engineers to enable ‘classical’ software engineers to use model engineering concepts and tools in an easy and reliable way. This fact can be verified very graphically since, at the time of writing, on the download page for the formal specification of UML the following discouraging note is presented: “Version 2.0 does not have XML or XSD associated files due to structural problems with the UML metamodel”. Acknowledgments. Partially supported by Comunidad Autónoma de La Rioja, project FOMENTA 2008/01, and by Ministerio de Ciencia e Innovación de España, project TIN2009-13584.

372

E. Rodriguez-Priego, F.J. García-Izquierdo, and Á.L. Rubio

References 1. Rodriguez-Priego, E., Garcia-Izquierdo, F.J.: Securing code in services oriented architecture. In: Baresi, L., Fraternali, P., Houben, G.-J. (eds.) ICWE 2007. LNCS, vol. 4607, pp. 550–555. Springer, Heidelberg (2007) 2. Muller, P.A., Fondement, F., Baudry, B.: Modeling Modeling. In: Schürr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 2–16. Springer, Heidelberg (2009) 3. Novak, J.D., Cañas, A.J.: The theory underlying concept maps and how to construct and use them. Technical report, Florida Institute for Human and Machine Cognition (2008) 4. Bézivin, J.: On the unification power of models. Software and Systems Modeling 4(2), 171–188 (2005) 5. Barbero, M., Jouault, F., Bézivin, J.: Model Driven Management of Complex Systems: Implementing the Macroscope’s Vision. In: ECBS 2008, IEEE Int. Conf. on the Engineering of Computer-Based Systems, Washington, DC, USA, pp. 277–286. IEEE Computer Society, Los Alamitos (2008) 6. Aßmann, U., Zschaler, S., Wagner, G.: Ontologies, Meta-models, and the Model-Driven Paradigm. In: Ontologies for Software Engineering and Software Technology, pp. 249– 273. Springer, Heidelberg (2006) 7. Ober, I., Prinz, A.: What do we need metamodels for? In: 4th Nordic Workshop on UML and Software Modelling, pp. 8–28 (2006) 8. Pidd, M.: Tools for Thinking: Modelling in Management Science, 3rd edn. John Wiley and Sons, Chichester (February 2009) 9. Sánchez, D.M., Cavero, J.M., Marcos, E.: On models and ontologies. In: 1st Int. Workshop on Philosophical Foundations of Information Systems Engineering, PHISE 2005 (2005) 10. Kühne, T.: Matters of (meta-) modeling. Software and Systems Modeling 5(4), 369–385 (2006) 11. OMG: MetaObject Facility (MOF) 1.4. Technical report (April 2002) 12. Gonzalez-Perez, C., Henderson-Sellers, B.: Modelling software development methodologies: A conceptual foundation. Journal of Systems and Software 80(11), 1778–1796 (2007) 13. Bézivin, J.: Towards a precise definition of the OMG/MDA framework. In: Proc. of the 16th Int. Conf. on Automated Software Engineering (ASE), pp. 273–280. IEEE Computer Society, Los Alamitos (2001) 14. Stachowiak, H.: Allgemeine Modelltheorie. Springer, Wien (1973) 15. OMG: MDA Guide Version 1.0.1. Technical report (June 2003) 16. Kleppe, A., Warmer, J., Bast, W.: MDA Explained. The Model Driven Architecture:Practice and Promise. Addison-Wesley, Reading (May 2003) 17. Jackson, D.: Software Abstractions: Logic, Language, and Analysis. The MIT Press, Cambridge (April 2006) 18. Favre, J.M.: Foundations of meta-pyramids: Languages vs. metamodels Episode II: Story of thotus the baboon. In: Language Engineering for Model-Driven Software Development, vol. 4101 (2005) 19. Klir, G.J.: Facets of Systems Science. Kluwer Academic Publishers, Dordrecht (August 2001) 20. Asikainen, T., Männistö, T.: Nivel: a metamodelling language with a formal semantics. Software and Systems Modeling 8(4), 521–549 (2009) 21. Seidewitz, E.: What Models Mean. IEEE Software 20(5), 26–32 (2003)

Modeling Issues: A Survival Guide for a Non-expert Modeler

373

22. Rensink, A.: Subjects, Models, Languages, Transformations. In: Language Engineering for Model-Driven Software Development, Dagstuhl. Dagstuhl Seminar Proceedings, Schloss Dagstuhl, Germany, Internationales Begegnungs- und Forschungszentrum fuer Informatik (IBFI), vol. 04101 (2005) 23. OMG: MetaObject Facility (MOF) 2.0 Core specification. Tech. Rep. (January 2006) 24. Kurtev, I.: Metamodels: Definitions of Structures or Ontological Commitments. In: Workshop on TOWERS of models. Collocated with TOOLS Europe (2007) 25. Favre, J.M.: Towards a basic theory to model model driven engineering. In: Proc. of the Workshop on Software Model Engineering (WISME 2004), Joint Event with UML 2004 (October 2004) 26. Sánchez, D.M., Cavero, J.M., Marcos, E.: The concepts of model in information systems engineering: a proposal for an ontology of models. The Knowledge Engineering Review 24(Special Issue 01), 5–21 (2009) 27. Kühne, T.: What is a Model? In: Dagstuhl Seminar. Dagstuhl Seminar Proceedings, Internationales Begegnungs- und Forschungszentrum für Informatik (IBFI), Schloss Dagstuhl, Germany (2005) 28. Atkinson, C., Kühne, T.: Rearchitecting the UML infrastructure. ACM Trans. Model. Comput. Simul. 12(4), 290–321 (2002) 29. Favre, J.M., Nguyen, T.: Towards a megamodel to model software evolution through transformations. In: SETRA Workshop. ENCTS, vol. 127, pp. 59–74. Elsevier, Amsterdam (2004) 30. Jouault, F., Bézivin, J., Barbero, M.: Towards an advanced model-driven engineering toolbox. Innovations in Systems and Software Engineering 5(1), 5–12 (2009) 31. Favre, J.M.: Foundations of Model (driven) (Reverse) Engineering - Episode I: Story of the Fidus Papyrus and the Solarus. In: Dagsthul Seminar on Language Engineering for Model- Driven Software Development (2004) 32. OMG: UML Infrastructure v2.2. Technical report (February 2009) 33. OMG: UML Superstructure v2.2. Technical report (February 2009) 34. Zito, A., Diskin, Z., Dingel, J.: Package Merge in UML 2: Practice vs. Theory? Model Driven Engineering Languages and Systems, 185–199 (2006) 35. Zito, A., Dingel, J.: Modeling UML2 package merge with Alloy. In: First Alloy Workshop (2006) 36. Bottoni, P., D’Antonio, F., Missikoff, M.: Towards a Unified View of Model Mapping and Transformation. In: Proceedings of the Open Interop Workshop on Enterprise Modelling and Ontologies for Interoperability (EMOI-INTEROP), co-located with CAiSE 2006 Conf. (June 2006) 37. Dingel, J., Diskin, Z., Zito, A.: Understanding and improving UML package merge. Software and Systems Modeling 7(4), 443–467 (2008) 38. Barbero, M., Jouault, F., Gray, J., Bézivin, J.: A Practical Approach to Model Extension. MDA-Foundations and Applications, 32–42 (2007) 39. Atkinson, C., Kühne, T.: Reducing accidental complexity in domain models. Software and Systems Modeling 7(3), 345–359 (2008) 40. Atkinson, C., Kühne, T.: The Essence of Multilevel Metamodeling. In: Gogolla, M., Kobryn, C. (eds.) UML 2001. LNCS, vol. 2185, pp. 19–33. Springer, Heidelberg (2001) 41. Weisemöller, I., Schürr, A.: A Comparison of Standard Compliant Ways to Define Domain Specific Languages. In: Giese, H. (ed.) MODELS 2008. LNCS, vol. 5002, pp. 47–58. Springer, Heidelberg (2008)

374

E. Rodriguez-Priego, F.J. García-Izquierdo, and Á.L. Rubio

42. Henderson-Sellers, B., Gonzalez-Perez, C.: Uses and abuses of the stereotype mechanism in uml 1.x and 2.0. In: Model Driven Engineering Languages and Systems, pp. 16–26 (2006) 43. Gitzel, R., Hildenbrand, T.: A Taxonomy of metamodel hierarchies. Technical report, Department of Information Systems. University of Mannheim (2005) 44. Thomas, D.: MDA: Revenge of the modelers or UML utopia? IEE Software 21(3), 15–17 (2004) 45. Merunka, V.: Critical Assessment of the Role of UML for Information System Development. In: Systems Integration, pp. 445–452 (2003) 46. Gitzel, R., Ott, I., Schader, M.: Ontological Extension to the MOF Metamodel as a Basis for Code Generation. The Computer Journal 50(1), 93–115 (2007) 47. France, R.B., Ghosh, S., Dinh Trong, T., Solberg, A.: Model-Driven Development Using UML2.0: Promises and Pitfalls. Computer 39(2), 59–66 (2006) 48. Milicev, D.: On the Semantics of Associations and Association Ends in UML. IEEE Transactions on Software Engineering 33(4), 238–251 (2007) 49. Shan, L., Zhu, H.: A Formal Descriptive Semantics of UML. In: Liu, S., Maibaum, T., Araki, K. (eds.) ICFEM 2008. LNCS, vol. 5256, pp. 375–396. Springer, Heidelberg (2008) 50. Akehurst, D.H., Howells, W.G.J., Bordbar, B., Mcdonald-Maier, K.D.: Maths vs (Meta) Modelling: Are we reinventing the Wheel? In: ICSOFT 2008, Porto, Portugal (2008) 51. Buttner, F., Gogolla, M.: On generalization and overriding in UML 2.0. In: Proc. UML 2004 Workshop OCL and Model Driven Engineering, pp. 69–83 (2004) 52. Fuentes, J.M., Quintana, V., Llorens, J., Genova, G., Prieto Diaz, R.: Errors in the UML metamodel? SIGSOFT Software Engineering Notes 28(6), 3 (2003) 53. Flatscher, R.G.: Metamodeling in EIA/CDIF—meta-metamodel and metamodels. ACM Transactions on Modeling and Computer Simulation (TOMACS) 12(4), 322–342 (2002) 54. Atkinson, C., Kühne, T.: Model-driven development: a metamodeling foundation. IEEE Software 20(5), 36–41 (2003) 55. Gaševic, D., Kaviani, N., Hatala, M.: Ón Metamodeling in Megamodels. Model Driven Engineering Languages and Systems, 91–105 (2007) 56. Varró, D., Pataricza, A.: A Unifying Semantic Framework for Multilevel Metamodeling. Tech. rep., Budapest Univ. of Technology and Economics (2001) 57. Jouault, F., Bézivin, J.: KM3:A DSL for Metamodel Specification. In: Gorrieri, R., Wehrheim, H. (eds.) FMOODS 2006. LNCS, vol. 4037, pp. 171–185. Springer, Heidelberg (2006) 58. Ludewig, J.: Models in software engineering - an introduction. Software and Systems Modeling 2(1), 5–14 (2003) 59. Bruni, R., Hölzl, M., Koch, N., Lluch Lafuente, A., Mayer, P., Montanari, U., Schroeder, A., Wirsing, M.: A service-oriented UML profile with formal support. In: Baresi, L., Chi, C.-H., Suzuki, J. (eds.) ICSOC-ServiceWave 2009. LNCS, vol. 5900, pp. 455–469. Springer, Heidelberg (2009) 60. Rodriguez, A., Fernandez-Medina, E., Piattini, M.: Security requirement with a uml 2.0 profile. In: Proceedings of the First Int. Conf. on Availability, Reliability and Security (ARES), pp. 670–677. IEEE Computer Society, Los Alamitos (2006) 61. Houmb, S.H., Den Braber, F., Lund, M.S., Stølen, K., Informatics, S.T.: Towards a UML profile for model-based risk assessment. In: Critical Systems Development with UMLProceedings of the UML 2002 Workshop, pp. 79–91 (2002) 62. Selic, B.: What’s new in UML 2.0. IBM rational software (2005)

Modeling Issues: A Survival Guide for a Non-expert Modeler

375

63. OMG: Diagram Interchange Specification, v1.0. Tech. rep. (2006) 64. OMG: Diagram Definition RFP-OMG Document 07-09-02. Tech. rep. (2007) 65. Atkinson, C., Henderson-Sellers, B., Kühne, T.: To Meta or Not to Meta. That Is the Question. Journal of Object-Oriented Programming 13(8), 32–35 (2000) 66. Atkinson, C., Kühne, T.: Profiles in a strict metamodeling framework. Science of Computer Programming 44(1), 5–22 (2002) 67. Kuhne, T.: Contrasting Classification with Generalisation. In: Proceedings of the Sixth Asia-Pacific Conf. on Conceptual Modelling, New Zealand (2009) 68. Atkinson, C., Kühne, T., Sellers, B.H.: Systematic stereotype usage. Software and Systems Modeling 2(3), 153–163 (2003)

Monarch: Model-Based Development of Software Architectures Hamid Bagheri and Kevin Sullivan University of Virginia, 151 Engineer’s Way, Charlottesville, VA 22903 USA {hb2j,sullivan}@virginia.edu

Abstract. In recent work we showed that it is possible to separate, and combine formal representations of, application properties and architectural styles, respectively. We do this by defining style-specific mappings from style-independent application models to architectural models in given styles. This paper shows that this separation of concerns supports a model-based development and tools approach to architecturalstyle-independent application modeling, and architecture synthesis with style as a separate design variable. In support of these claims, we present a proof-of-concept tool, Monarch, and illustrate its use.

1

Introduction

Software architecture is an essential means for managing complexity and meeting demanding requirements in developing complex software systems. Architectural styles systematize successful architectural design practices in terms of constraints on architectural elements and their composition into systems [23]. To develop architectural models effectively one must understand both the application domain in question and the discipline of software architecture. However, these bodies of knowledge are typically held by different people. Domain experts better understand requirements and specifications, while architects understand architectural styles, their implications, and techniques for mapping abstract application models to architectural models in given styles. The required communication and coordination, and the manual mapping of application models to architectures, are costly and error prone activities. The question arises, can domain expert be equipped with capabilities to model applications abstracted from architectural details in a way that subsequently allows for precisely specified and automated mappings to software architectures in given styles? Can we automate some of the important work previously done by expert software architects? This paper presents results that suggest that this question worth pursuing. In particular, we present a model-based approach to modeling application properties abstracted from architectural style decisions, and to automated mapping of such application models to architectural models in standard architecture description languages (ADLs) based on separate choices of formal architectural D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 376–390, 2010. c Springer-Verlag Berlin Heidelberg 2010 

Monarch: Model-Based Development of Software Architectures

377

style. In this paper, we leverage core transformation technology first presented in an earlier work [4] to support such a model based approach. The key idea in this paper is that our separation of application and architectural style concerns is isomorphic to the separation of models and platforms in model-based development (MBD). We view architectural styles as playing the same role as platform descriptions in a MBD approach. We claim that this observation opens a path to MBD tools that support architectural style as a separate variable in automated development of software architectures. We introduce application types as styles of application description that play the same role as application meta-models in MBD. Our application models correspond to models in MBD; our architectural maps, to MBD transformations; our architectural styles, to MBD platforms; and our synthesized software architectural models, to platform-specific models in MBD. The main technical contribution of this paper is a demonstration that this vision is valid and supports the development of a new kind of model-based tool: for synthesizing software architectural models, in a variety of styles and representations, from application models of a variety of types. Our tool, Monarch, supports meta-models for a range of of application types, the graphical development of architecture-independent models of these types, the choice of architectural style as a separate variable, formally based and automated synthesis of software architectures for modeled applications, and representation of architectural models in standard ADLs. To demonstrate the feasibility of this approach, we present a small study in which we used Monarch to synthesize software architectures following an example by Taylor et al. [24], in which an informal application description of a Lunar Lander embedded control system is informally mapped to software architectures in several styles. The remainder of the paper is organized as follows. Section 2 presents our approach for relating MBD and software architecture. In Section 3, we use Taylor’s Lunar Lander case study [24] to demonstrate the key steps in the mapping process. Section 4 surveys related work. Section 5 presents our conclusion and a discussion of future work.

2

Approach

As software systems become larger and more complex, there is an ever greater need to employ higher levels of abstraction in application development. Modelbased Development is centered around abstract, domain-specific models and transformations of abstract models into the constructs of specific underlying platforms. To be more precise, MBD is rooted in a mapping that takes a platformindependent model, p, and a platform definition model, s, to a platform-specific model, i. That is, i : P SM = map(p : P IM, s : P DM ). In our own recent work [4], we showed that application models can be mapped to software architectural models, or targets, by way of choices of a software architectural style. {ai : ArchM odel} ∈ ArchM ap(m : AppT ype, s : ArchStyle). The analogy between two approaches is clear in the equations. Figure 1 shows the correspondence

378

H. Bagheri and K. Sullivan

Model-based Development Our Theory Meta-model Application-type Platform Independent Model (PIM) Application Model Model Transformation Architectural Mapping Platform Definition Model (PDM) Architectural Style Platform Specific Model (PSM) application- and style-specific Architecture Fig. 1. Correspondence between terms of our theory and the formal structure of MBD

between terms of our theory and the formal structure of MBD. We represent the parallel more precisely by the proposed framework. Formally, the definition of a modeling language [8,7] consists of: (1) the abstract syntax (A) that defines the language concepts, and the relationships between them, (2) the concrete syntax (C) as a human-centric notation, (3) the syntactical mapping (MC : C → A) that links the concrete syntax to the abstract syntax, (4) a semantic domain (S) that specifies well-formedness rules for models as well as the meaning of the models, and finally (5) the semantic mapping (MS : A → S) that links the abstract syntax to the semantic domain, giving a modeling language a meaning.

Fig. 2. High-level overview of the approach for relating Model-based Development and Software Architecture

Figure 2 outlines the relationship we have identified between model-based development and software architecture. The proposed framework comprises (1) an approach to architecture-independent application modeling using the Generic Modeling Environment (GME) [19], with application types realized concretely as GME architecture-independent modeling language (AIML) meta-models; (2) interpreters that transform application models, viewed as concrete instances of domain-specific modeling languages into an abstract syntax based on Alloy [15]; (3) a mapping engine, based on the Alloy Analyzer, that takes such an application model and a formal specification of an architectural style and that finds architectural models that refine the application model in conformance with the given architectural style. The mapping employed is based on the combination of

Monarch: Model-Based Development of Software Architectures

379

the selected application type and the selected architectural style. The engine uses the Alloy constraint solver to compute architectures, represented as satisfying Alloy solutions; (4) a final post-processing phase, Alloy2ADL, translates the resulting Alloy instances into human-readable architectural description languages (ADLs). 2.1

Meta-model

The definition of a concrete syntax by a meta-model is supported thoroughly by many meta-modeling environments, e.g. Generic Eclipse Modeling System [27], MetaEdit+ [1] and Generic Modeling Environment [19]. We have developed Architecture-Independent Modeling Languages (AIMLs) on top of the GME to support the specification of application content at the abstract modeling level. The reasons for choosing GME for this study include its straightforward mechanisms for developing extensions, and its availability and proven success for MBD. A meta-model specification describes a particular form of model. In our earlier work [4], we identified several possible forms of architecture-independent model, including composition of functions, aspect-enabled composition-of-functions (ACF), state-driven behavior (SD) and sense-compute-control (SCC). Our metamodel for a simple sense-compute-control (SCC) application type is shown in Figure 3a. We have developed GME meta-models for several previously identified but not well elaborated application types: composition-of-functions (CF), aspect-enabled composition-of-functions(ACF) (Figure 3b), and state-driven behavior (SD) (Figure 3c). For brevity, and because it suffices to make our points, we describe only the SCC meta-model in this work. Monarch supports the others as well. We view sense-compute-control (SCC) as an application type for embedded control systems. The SCC application type is used to model applications in which a set of sensors and controllers (actuators) are connected to a computer that cycles through the steps of fetching sensor values, executing a set of functions, and emitting outputs to the actuators [24]. Figure 3a shows a UML class diagram for the SCC meta-model as represented in GME. The ApplicationDescription class, which is common among application-type meta-models, denotes the application specification diagram, which contains elements of an application model. The Controller, Sensor and Actuator classes represent three main elements of the SCC application type. The Controller’s frequency is abstracted into discrete ranges of slow and fast. The Controller can also be specified as using a periodic, aperiodic or sporadic task. Given such a meta-model specification of a modeling language for each architectural-style-independent application type, GME automatically creates an architectural-style-independent modeling environment. The designer of a system then specifies an application description as a model using the modeling environment. We believe this approach promises to allow domain experts to model their applications abstracted from details of software architectural styles.

380

H. Bagheri and K. Sullivan

Fig. 3. Meta-models in GME for application types: a) Sense-Compute-Control b) Aspect-enabled Composition-of-Functions c) State-Driven behavior

2.2

Transformation to Alloy Specification

Monarch then translates an application model specified as a concrete instance of such an architecture-independent modeling language (AIML) for a given application type into an abstract syntax based on the Alloy language. The GME provides several ways to process data from the model automatically. We used the Java version of the Builder Object Network (BON), providing us access to the internal representation of the model through Java objects. We also developed a GME interpreter for each meta-model as a syntax mapping, which elicits the model elements and transforms the constructs of the application model to formal specifications in the Alloy language. Alloy is a lightweight modeling language based on the first-order relational logic [15]. It has been applied by numerous researchers to formal work in software architecture. Kelsen and Ma [17], comparing the traditional methods of formal specifications for modeling languages with an approach based on the Alloy

Monarch: Model-Based Development of Software Architectures

381

language, argue that because of both lower notational complexity and automatic analyzability, Alloy provides more convenient facilities for defining the formal semantics of modeling languages. Essential constructs of the Alloy language include: Signatures, Facts, Predicates, Functions and Assertions. Signatures represent the basic types of elements and the relationships between them. Alloy provides Facts to be used in defining constraints that any instance of a model must satisfy. Predicates are parameterized reusable constraints that are always evaluated to be either true or false. Functions are parameterized expressions. A function can be invoked by instantiating its parameter, but what it returns is either a true/false or a relational value instead. An assertion is a formula required to be proved. It can be used to check a certain property of a model. With respect to the constraints in a given model, the Alloy Analyzer can be used either to find solutions satisfying them, or to generate counterexamples violating them. The Alloy Analyzer is a bounded checker, so a certain scope of instances needs to be specified. In the matter of architectural styles, the scope states the number of architectural elements of each type. To take advantage of partial models, its latest version uses KodKod [25] as its constraint solver so that it can support incremental analysis of models as they are constructed. The generated instances are then visualized in different formats such as graph, tree representation or XML. We use the Alloy Analyzer to compute architectural models given the conjunction of an architecture-independent model represented using a particular meta-model, and a choice of a formal specifications of an architectural style, also represented in Alloy. We discuss this approach in more detail in the next sections. 2.3

Architectural Mapping

After modeling application content, our tool uses the Alloy Analyzer, Alloy formalizations of several architectural styles, Alloy formalizations of application types, and architectural mappings we have defined, to synthesize architectural models in given styles. To represent a mapping for an application type and a given architectural style, we extend a traditional architectural style specification, in Alloy, with a predicate for mapping application models of the given type to architectural models in the given style. Using the Alloy Analyzer, the mapping engine computes architectural models represented as Alloy solutions to the mapping constraints. Our previous work provides more details [4]. As an example, Listing 1 presents part of the predicate for mapping application models in the sense-compute-control application type to architectures in the implicit invocation style. We describe it in more detail in Section 3.3.

382 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 28 29 30 31 32 33 34 35 36

H. Bagheri and K. Sullivan module SCC II open SCC open I I p r e d mapping ( ) { a l l n : n e e d H a n d l e | one o :

I I O b j e c t | o . handle = n

a l l a : A c t u a t o r | one p o r t : P o r t | ( port in ( a . ˜ handle . ports & Procedure) ) | | ( port in ( a . ˜ handle . ports & SubscribeEvent ) ) all

s : S e n s o r | one p o r t : P o r t | ( port in ( s . ˜ handle . ports & Procedure) ) | | ( port in ( s . ˜ handle . p orts & PublishEvent) )

# ( Co n t r o l l e r . ˜ handle . ports & SubscribeEvent ) = # ( Sensor . ˜ handle . p orts & PublishEvent) (#S u b s c r i b e E v e n t >0) => # ( C o n t r o l l e r . ˜ h a n d l e . p o r t s & P u b l i s h E v e n t ) = 1 (#P r o c e d u r e >0) => # ( C o n t r o l l e r . ˜ h a n d l e . p o r t s & C a l l ) = 1 all

p o r t : P r o c e d u r e | one c o n e c t o r : p r o c e d u r e C a l l | port [ attachments ] . ran = c o n e c t o r . r o l e s & Provide

C o n t r o l l e r . ˜ handle . c a l l [ attachments ] . ran . c o n n e c t o r = Actuator . ˜ handle . procedure [ attachments ] . ran . c o n n e c t o r + Sensor . ˜ handle . procedure [ attachments ] . ran . c o n n e c t o r ( C o n t r o l l e r . ˜ h a n d l e . p o r t s & S u b s c r i b e E v e n t ) [ a t t a c h m e n t s ] . r a n . ˜ r o l e s= ( Sensor . ˜ handle . p o r t s & PublishEvent) [ attachments ] . ran . ˜ r o l e s ( C o n t r o l l e r . ˜ h a n d l e . p o r t s & P u b l i s h E v e n t ) [ a t t a c h m e n t s ] . r a n . ˜ r o l e s= ( Actuator . ˜ handle . p o r t s & SubscribeEvent ) [ attachments ] . ran . ˜ r o l e s ... }

Listing 1. Part of the mapping predicate for the pair of SCC application type and II architectural style

2.4

Transformation to Architecture Description Language

Having computed satisfying solutions, our Alloy2ADL transformer component parses and transforms these solutions from low-level, XML formatted Alloy objects to high-level architecture descriptions in human-readable ADLs. During the past several years, a considerable number of general and domain-specific ADLs have been proposed [21]. We use the Acme language in our prototype [13]. Acme emerged as a generic language for describing software architectures, with particular support for architectural styles. It is also designed to work as an interchange format for mapping among other architecture description languages. In an earlier brief abstract [5], we briefly reported on the feasibility of treating architectural style as a separate variable in an aspect-oriented setting, with AspectualACME [11]—an aspect-enabled extension of Acme—as a target ADL.

3

Case Study

We have developed and demonstrated our proposed approach for a range of simple application types and established architectural styles. We have developed

Monarch: Model-Based Development of Software Architectures

383

Fig. 4. Lunar-Lander application model in: a) GME modeling Environment b) Alloy

four simple application type meta-models, and have employed three architectural style specifications and mappings. In this section, we use Monarch [2], which is available for download, to recapitulate the Lunar Lander embedded control system case study presented by Taylor et al. in their recent book on software architecture to illustrate the process described above. 3.1

Lunar Lander in SCC Application Type

In their textbook [24], Taylor et al. describe the informal mapping of a lunar lander application to architectures in a range of architectural styles. In this application, FlightControl maintains the state of a spacecraft based on the information provided by various sensors: Altimeter, Gyroscope, Fuel level indicator and the engine control switch. After processing control laws and computing values, FlightControl provides them to the various actuators: Descent engine controller, Attitude control thruster and Display. Taylor et al. describe the lunar lander as an instance of a sense-compute- control (SCC) application. The notion of application type is implicit in their account. We make it explicit and formal in our theory. Figure 4a shows the lunar lander’s application description modeled within GME using the generated modeling environment for our SCC meta-model. 3.2

The Abstract Syntax Definition for Lunar-Lander

Figure 4b shows the Alloy representation of the lunar lander application model generated directly from its concrete model by the GME-Interpreter for the SCC meta-model. A synthesized Alloy module contains the signature definitions of the elements in the concrete model and the facts corresponding to the elements’ properties. It starts by synthesizing the module name representing the name of the instance of the ApplicationDescription class within the concrete model. It then imports the Alloy specification module(s) for application type(s). For each instance of Sensor, Actuator, and Controller classes in a concrete model, it synthesizes a signature definition that represents the inheritance of a concrete

384

H. Bagheri and K. Sullivan

element from its corresponding abstract class. The element’s properties (if any) are also specified as Alloy facts for the corresponding signature of that element, e.g. FightControl has a periodic task with high frequency. 3.3

The Architectural Mapping process

The architectural mapping process takes as inputs the abstract application model (transformed directly from the concrete model to the Alloy module), an Alloy module specifying the application type (meta-model), an architectural style Alloy module that specifies the constraints to which the computed results conform, and the architectural mapping Alloy predicates that define relationships required to hold between the application model and computed architectural models. Each mapping predicate for the given application type and architectural style is responsible for confirming that the satisfying solutions refine the given application model in conformance with the given style. Overall, we have developed seven architectural mappings in our work validating our approach. Listing 1 shows such a predicate for the SCC application type and the implicit invocation architectural style. At the top, the specification imports our Alloy modules for the SCC application type and implicit invocation architectural style. The mapping predicate then, in line 7, states that for each sensor, actuator and controller there is an IIObject that handles it. According to lines 9–11, each Actuator’s IIObject has a port of type SubscribeEvent or Procedure to be called implicitly or explicitly. Likewise, each Sensor’s IIObject has a port of type PublishEvent or Procedure. The number of SubscribeEvent ports of the controller’s IIObject equals to the number of PublishEvent ports of the sensors’ IIObjects, as mentioned in lines 17–18. So, each SubscribeEvent port of the controller could be connected to a sensor’s PublishEvent port to be called implicitly. In addition, the specification, in lines 20–21, states that the controller’s IIObject has at most one PublishEvent port and one Call port so that the procedures of actuators’ IIObjects could be called explicitly or could register to be invoked when the PublishEvent port of the controller’s IIObject announces an event. The II architectural style provides two ways of invoking methods: procedure call and implicit invocation. For the purpose of the former method, lines 23–28 state that for each Procedure port, there is a PrecedureCall connector connected to it, and the Call port of the controller’s IIObject is connected to the Procedure port of the IIObjects handling sensors and actuators via a connector of type ProcedureCall. For an implicit invocation, the SubscribeEvent ports of the controller’s IIObject are connected to the PublishEvent ports of sensors’ IIObjects via an EventBus connector, as mentioned in lines 30–31. In a similar way, the SubscribeEvent ports of the actuators’ IIObjects are connected to the PublishEvent port of the controller’s IIObject through an EventBus connector. 3.4

Satisfying Architectural Models

Using the Alloy Analyzer, Monarch computes a set of architectural models satisfying the constraints implied by both the architectural style and the mapping

Monarch: Model-Based Development of Software Architectures

385

predicates with respect to the application model. In general, there is more than one satisfying solution. To make the outputs humanly readable and useful, the Alloy2ADL transformer converts the Alloy-generated abstract XML-format to a traditional architecture description language. Figure 5 represents one of the computed instances of architecture description models in Acme. These models refine the Lunar Lander application description specified using the SCC application type, in conformance with the fully formal definition of the implicit invocation architectural style. The result is a set of formally derived architectural models for the given application in the selected architectural style. According to the diagram, in this particular, arbitrarily selected case, three of the four top components, for handling sensors, are connected to FightControl through ProcedureCall connectors, i.e., using explicit invocation, except for the Altimeter component, which is called implicitly via the EventBus0 connector. The actuators’ components are also connected to the FlightControl through the EventBus1 connector.

Fig. 5. One of the computed instances of mapping SCC description of the Lunar Lander into the implicit invocation architectural style in Acme

The example illustrates the point that architectural styles, viewed as mappings to platforms, can be one-to-N. In general, there are many possible architectures, consistent with a given style, for a given application. The architecture in the diagram should thus be viewed as just one instance (and not necessarily the best) of a family of architectures, given the specification of the II style we are using. In general, mappings to families of architectures could be useful in enabling optimizing search for properties influenced by architecture but not constrained in the modeling stage. Alternatively, one could strengthen the definition of the style or the application type and instance to limit the family of conforming instances.

386

3.5

H. Bagheri and K. Sullivan

Discussion

This work and our earlier work suggest that the concept of application type is important. Our experiments show that the concept of application type leads naturally to an abstract, user-friendly approach to application modeling. Overall, we have demonstrated an approach taking fully formal specifications of application models and architectural styles as inputs and producing software architectures as outputs within the framework of MBD. Moreover, the proposed framework supports reasonable extension for new types and mappings. To that end, one specifies an application type and its corresponding GME meta-model, as well as the architectural mapping predicates for relevant styles, so that by simply swapping among architectural mappings, one can produce architectures in a range of styles for any given application model instance. The main intellectual contribution of this work is the insight that software architectural styles can serve as analogs to choices of platforms in model-based development. This idea then leads naturally to a new kind of tool: one that allow for modeling of applications independent of subsequent architectural style choices, and for the automated mapping of models to architectures once such style choices area made. Whereas traditional MBD work seeks to replace the programmer, our work points the way to a future in which MBD replaces at least some of the work of the software architect.

4

Related Work

The work presented in this paper is related to research in a number of areas. Demirezen et al. [10] apply Alloy and graph transformations to imbue domainspecific modeling languages (DSMLs) with semantics. Chen et al. [7] similarly propose an approach aimed at providing a semantic infrastructure for DSMLs. Our work exploits both DSMLs (AIMLs in our work) for specification of an application content and formalization of architectural styles, but extends such previous work by placing the notion of architectural style as a separate design variable within the formal framework of the Model-based Development. Alloy has been applied by numerous researchers to formal work in software architecture. Warren et al. [26] propose an approach to specify an intended configuration using Alloy in order to check consistency with structural architectural constraints before performing a proposed evolution. Again, our work differs in its focus on separating application description from style choices. We also use Alloy to model spaces of architectural descriptions consistent with given styles, not just to check the consistency of a given description against the rules of a style. Kim and Garlan [18] propose an approach to translating architectural styles described formally in an architecture description language to the Alloy language, and in turn, to verifying properties implied by architectural styles. Their focus is on transforming descriptions of architectural styles to a relational model that can be automatically checked, whereas we concentrate on extending the concept of the software architectural style to include mappings from abstract problem descriptions to target software architectures.

Monarch: Model-Based Development of Software Architectures

387

Georgiadis, Magee and Kramer [14] specify structural architectural styles as a set of constraints in order to control runtime reconfiguration by means of constraints evaluation. This work shares with ours an emphasis on formal characterization of architecture. However, all reconfigurations in this work are assumed to occur within a single architectural style. This work does not try to specify how a self-organizing system can transform from one architectural style to another, or how different architectures for such a system could be derived from different architectural style constraints. In the area of architecture transformation, Baresi et al. [6] argue that constraints imposed by a certain choice of platform could be considered as an architectural style. Using graph transformations, they define refinement rules for checking the consistency of an application with constraints implied by the style to which it conforms. However, we introduce new concept of application type, and define the refinement rules based not only on architectural style, but also on the application type of the system. That is, we specify an architectural mapping, which performs such a refinement, for each pair of an application type and an architectural style. Ambriola and Kmiecik [3] describe how preliminary architectural sketches can be incrementally refined into more mature architectural descriptions by the use of architectural transformations that add, remove, and move architectural elements and relationships. Their work focuses on horizontal architectural change over time: from one architectural description to another. Our work by contrast focuses on vertical mappings: how architectural style choices map structured application models to architectural models. That is, we derive style-specific architectural models from pure application models with no stylistic content. Garlan et al. [12] similarly describe an approach for the evolution of one fully developed architectural description to another, based on the idea that architectural evolution follows certain common patterns, which they identify as evolution styles. Like the work of Ambriola and Kmiecik, they focus on horizontal architectural evolution, whereas our work focuses on a formal study of the diversity of possible mappings from structured application models to architectural models. That is, we focus on architectural style as a separate design variable. Research efforts on horizontal and vertical mappings are complementary, in that success in understanding architectural style as a separate variable could, in practice, help to explain and perhaps automate horizontal evolution by treating the starting and ending points of horizontal evolution as images of a given application under different styles. The work of Jackson, Schulte and Sztipanovits on model-driven architecture and design-space exploration [16] is especially relevant. They start with an application description and a platform description and then compute a mapping, while we start with an application description and a map and then compute architecture descriptions. The parallels suggest that our approaches can inform each other. Deline’s work on Flexible Packaging (FP) [9] is perhaps the most closely related to our work. Deline’s basic idea was that a given function can be packaged

388

H. Bagheri and K. Sullivan

up in different ways to work in systems in different architectural styles. He furthermore assumed that the stylistic differences mostly involved the ways in which a core function implementation would interact with its surrounding environment. Deline’s FP method thus separates the interactive aspects of a component (packaging), from its core function (the ware). Deline focused on the embedding of a ware into systems in various architectural styles. Our work, by contrast, focuses on the transformation of an application description (the analog of a ware) into an architecture in a given style. In our work, the ware is rendered in different styles by various mappings.

5

Conclusion

In this paper we have shown that the separation of architectural style from decisions about application content gives rise to a natural mapping to model-based development, and that this mapping reveals a natural approach to providing MBD support for architecture-independent application models with the choice of an architectural style as a separate concern. This work contributes a bridge between two important areas of research: architecture, and model-based development. Such bridges are important because they allow results in one area to be leveraged in another. Evidence for the value of our bridge is in the form of a prototype software tool. This tool combines key constructs of MBD, including the GME framework, with major results in software architecture, including formalization of architectural styles, and with our own previous work, to produce a new and promising kind of application modeling and transformation tool. We identify three goals for future work. First, our architectural transformations are generally one-to-many. The more complex a system is, and the less tightly constrained the architectural style, the larger the set of architectures will be. Exploration of such design spaces to optimize for properties of interest is potentially quite important. Work by Jackson et al. [16] suggests interesting possibilities in this regard, which we intend to explore. We note that automated search could occur not only within one style but across styles—leading to a tool able automatically to find appropriate architectural styles and architectures for given applications. Second, in view of the growing size and complexity of software systems, scalability is a significant issue. As such, we plan to investigate the following issues among others: larger, structured application models with sub-models of heterogeneous application types; synthesis of multi-style architectures; targeting of styles induced by middleware platforms and production frameworks [22]; and replacing Alloy with more scalable synthesis technology. Finally, a shortcoming of current approaches to code generation from architectural models is in the lack of flexibility with respect to architectural style. The architect is forced to develop models in the particular architectural style supported by a given approach, rather than a suitable style chosen by the architect [20]. We are considering extensions of our work to include subsequent

Monarch: Model-Based Development of Software Architectures

389

mappings from architectural descriptions to code, returning the responsibility for stylistic decisions to the architect.

References 1. MetaEdit+, http://www.metacase.com/ 2. Monarch tool suite, http://www.cs.virginia.edu/~ hb2j/Downloads/Monarch-ToolSuite.zip 3. Ambriola, V., Kmiecik, A.: Architectural transformations. In: Proceedings of the 14th International Conference on Software Engineering and Knowledge Engineering, pp. 275–278 (2002) 4. Bagheri, H., Song, Y., Sullivan, K.: Architectural style as an independent variable. In: Proceedings of the 25th IEEE/ACM International Conference on Automated Software Engineering (ASE 2010) (2010) 5. Bagheri, H., Sullivan, K.: Architecture as an independent variable for AspectOriented application descriptions. In: Abstract State Machines, Alloy, B and Z (ABZ 2010) (2010) 6. Baresi, L., Heckel, R., Th¨ one, S., Var´ro, D.: Style-based modeling and refinement of service-oriented architectures. Software and Systems Modeling 5(2), 187–207 (2006) 7. Chen, K., Sztipanovits, J., Abdelwalhed, S., Jackson, E.: Semantic anchoring with model transformations. In: Hartman, A., Kreische, D. (eds.) ECMDA-FA 2005. LNCS, vol. 3748, pp. 115–129. Springer, Heidelberg (2005) 8. Clark, T., Evans, A., Kent, S., Sammut, P.: The MMF approach to engineering Object-Oriented design languages. In: Workshop on Language Descriptions, Tools and Applications (2001) 9. DeLine, R.: Avoiding packaging mismatch with flexible packaging. In: Proceedings of the 21st International Conference on Software Engineering, pp. 97–106 (1999) 10. Demirezen, Z., Mernik, M., Gray, J., Bryant, B.: Verification of DSMLs using graph transformation. In: Proceedings of the 6th International Workshop on ModelDriven Engineering, Verification and Validation. ACM International Conference Proceeding Series, vol. 413, pp. 1–10 (2009) 11. Garcia, A., Chavez, C., Batista, T., Santanna, C., Kulesza, U., Rashid, A., Lucena, C.: On the modular representation of architectural aspects. In: Gruhn, V., Oquendo, F. (eds.) EWSA 2006. LNCS, vol. 4344, pp. 82–97. Springer, Heidelberg (2006) 12. Garlan, D., Barnes, J.M., Schmerl, B., Celiku, O.: Evolution styles: Foundations and tool support for software architecture evolution. In: Joint 8th Working International Conference on Software Architecture and 3rd European Conference on Software Architecture, Cambridge, UK (September 2009) 13. Garlan, D., Monroe, R.T., Wile, D.: Acme: architectural description of componentbased systems. In: Foundations of Component-based Systems, pp. 47–67. Cambridge University Press, Cambridge (2000) 14. Georgiadis, I., Magee, J., Kramer, J.: Self-organising software architectures for distributed systems. In: Proceedings of the First Workshop on Self-healing Systems, pp. 33–38 (2002) 15. Jackson, D.: Alloy: a lightweight object modelling notation. ACM Transactions on Software Engineering and Methodology (TOSEM) 11(2), 256–290 (2002)

390

H. Bagheri and K. Sullivan

16. Jackson, E.K., Schulte, W., Sztipanovits, J.: The power of rich syntax for modelbased development - microsoft research (2008), http://research.microsoft.com/apps/pubs/default.aspx?id=77374 17. Kelsen, P., Ma, Q.: A lightweight approach for defining the formal semantics of a modeling language. In: Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., V¨ olter, M. (eds.) MODELS 2008. LNCS, vol. 5301, pp. 690–704. Springer, Heidelberg (2008) 18. Kim, J.S., Garlan, D.: Analyzing architectural styles with alloy. In: Proceedings of the ISSTA 2006 Workshop on Role of Software Architecture for Testing and Analysis (ROSATEA 2006), Portland, ME, USA, pp. 70–80 (July 2006) 19. L´edeczi, A., Bakay, A., Mar´ oti, M., V¨ olgyesi, P., Nordstrom, G., Sprinkle, J., Karsai, G.: Composing Domain-Specific design environments. Computer 34(11), 44–51 (2001) 20. Malek, S.: Effective realization of software architectural styles with aspects. In: Proceedings of the Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA 2008), pp. 313–316 (2008) 21. Medvidovic, N., Taylor, R.N.: A classification and comparison framework for software architecture description languages. IEEE Transactions on Software Engineering 26(1), 70–93 (2000) 22. Nitto, E.D., Rosenblum, D.: Exploiting ADLs to specify architectural styles induced by middleware infrastructures. In: Proceedings of the 21st International Conference on Software Engineering, Los Angeles, California, United States, pp. 13–22. ACM, New York (1999) 23. Shaw, M., Garlan, D.: Software Architecture: Perspectives on an Emerging Discipline. Prentice-Hall, Englewood Cliffs (1996) 24. Taylor, R.N., Medvidovic, N., Dashofy, E.: Software Architecture: Foundations, Theory, and Practice. Wiley, Chichester (2009) 25. Torlak, E.: A Constraint Solver for Software Engineering: Finding Models and Cores of Large Relational Specifications. PhD thesis, MIT (February 2009) 26. Warren, I., Sun, J., Krishnamohan, S., Weerasinghe, T.: An automated formal approach to managing dynamic reconfiguration. In: Proceedings of the 21st IEEE/ACM International Conference on Automated Software Engineering, pp. 37–46 (2006) 27. White, J., Schmidt, D.C., Nechypurenko, A., Wuchner, E.: Introduction to the generic eclipse modelling system. Eclipse Magazine 2007(6), 11–18 (2007)

Model-to-Metamodel Transformation for the Development of Component-Based Systems Gerd Kainz1 , Christian Buckl1 , Stephan Sommer2 , and Alois Knoll2 1

2

fortiss, Cyber-Physical Systems, Guerickestr. 25, 80805 Munich, Germany {kainz,buckl}@fortiss.org Faculty of Informatics, Technische Universit¨ at M¨ unchen Boltzmannstr. 3, 85748 Garching, Germany {sommerst,knoll}@in.tum.de

Abstract. Embedded systems are a potential application area for component-based development approaches. They can be assembled from multiple generic components that can either be application components used to realize the application logic or hardware components to provide low level hardware access. The glue code to connect these components is typically implemented using middleware or run-time systems. Nowadays great parts of the system are automatically generated and configured according to application needs by using model driven software development tools. In a model driven development process, three different kinds of developers can be identified: run-time system experts, component developers and application developers. This paper presents a multi-phase approach, which is suited to support all of these experts in an optimal way. Key idea is a multi-phase development process based on model-tometamodel transformations connecting the different phases. The advantages of this approach are demonstrated in the context of distributed sensor / actuator systems. Keywords: Model-to-Metamodel (M2MM), Model-to-Model (M2M), Model Transformation, Component-based Systems, Model-Driven Development (MDD).

1

Introduction

During the development of embedded systems, many recurrent tasks have to be implemented. To increase the development efficiency of distributed embedded systems, a component-based architecture can be used to raise the level of reuse [1]. In such systems, the underlying software architecture is based on a component / container architecture: the container in form of a middleware architecture or run-time system implements the communication between the different components. Although generic approaches, e.g. CORBA [2], are available and used in the area of distributed standard IT systems, domain specific run-time systems / middleware are dominant in the area of distributed embedded systems [3] to adapt to special requirements in this domain, e.g. resource limitations. To D.C. Petriu, N. Rouquette, Ø. Haugen (Eds.): MODELS 2010, Part II, LNCS 6395, pp. 391–405, 2010. c Springer-Verlag Berlin Heidelberg 2010 

392

G. Kainz et al.

speed up the adaptation process of these run-time systems, model-driven methods can be used to automatically generate a tailored run-time system for a specific application. Code generation can also take non-functional requirements into account. One example is to hide the heterogeneity of different communication protocols by using a specific middleware. To guarantee the required quality of service (QoS) even if the used communication protocol does not provide means to guarantee them, the middleware might require additional functionality on top of the used communication protocol. When analyzing the development process of embedded systems, three different kinds of developers can be identified: run-time system experts, component developers, and application developers. The experts for the run-time system develop generic architectures, which are later automatically tailored by the development tool according to the requirements of a concrete application. Component developers are responsible for the creation of both software and hardware components. They have to ensure that the developed components can be integrated into the run-time system, either by providing appropriate interfaces for the software components or by offering a suitable firmware for hardware components. Finally, application developers select the right components for their application and specify all non-functional requirements, which have to be satisfied by the running system, using model-based tools. Currently, model driven development has been mainly applied to support the application developers in creating new applications focusing on the application logic. In this paper, we present an approach, which consecutively assists all three developer types. This is achieved by a three-phase model-driven development approach, where every phase builds up on the input of the previous phase. In each phase the corresponding expert is able to model the relevant properties of the system and to concentrate on the aspects of the system related to his expertise. The different phases are connected via model-to-metamodel (M2MM) transformations, where objects of the previous phase become classes in the subsequent phase. This paper gives an overview of the applied approach and describes the results of a first prototype. The remainder of this paper is as follows. Section 2 shortly describes the domain used for evaluation and gives a motivation for the approach. The proposed operational sequence is outlined in section 3 and compared with corresponding related work in section 4. At the end, section 5 summarizes the contribution and gives an outlook on further steps.

2

Application Domain: Distributed Sensor / Actuator Systems

Distributed sensor / actuator networks are an interesting application area for the component-based approach, as many different generic components, e.g. for sensing, actuation or communication, can be identified. The SOA project [4] targets this application area. In the scope of the project, a model driven development tool for distributed sensor / actuator systems has been developed to simplify the development of such system.

Model-to-Metamodel Transformation for Component-Based Systems

393

One main property of sensor / actuator networks is the high level of hardware heterogeneity. In the current version Linux-based computers, wireless sensor nodes with TinyOS1 and Atmel 8 bit micro controllers without an operating system are supported. In addition, different types of sensors and actuators are available for the interaction with the environment. Figure 1 shows a demonstrator implemented within the SOA project.

Fig. 1. Model Railway Controlled by Services Running on Distributed Heterogeneous Controllers

By using a service oriented architecture (SOA) the heterogeneity can be hidden from the application developer [5]. The system is interpreted as a set of services. These services can either be hardware-related components implementing the interaction with sensors respectively actuators or components used to realize hardware-independent calculations. With the development tool created in the project, the end user is able to select all the services required for the application, assign them to concrete hardware nodes and configure them accordingly. The middleware needed for the execution is generated by a model-driven code generator. The code generator takes care that only the required functionality is integrated into the middleware and that the middleware is configured and tailored to fit the actual application requirements. Due to the high diversity of sensors, actuators and controllers, the development tool had to be extended several times. Examples are the addition of new services used to realize control algorithms or logics. Furthermore, the support of new hardware platforms caused many changes. The effort for the integration turned out to be very high and required in-depth knowledge of the whole development tool. In a concrete case, the system existing of wireless components was extended with components supporting Ethernet communication. Therefore, the metamodel had to be augmented with Ethernet components and their corresponding attributes. During this extension, a specification of the concrete component had been added to the metamodel. Due to this fact, no distinction between 1

http://www.tinyos.net/

394

G. Kainz et al.

the common Ethernet capability with its attributes (e.g. IP address, MAC address, net mask, gateway, ...) and the description of the concrete component had been done. The effect of this approach was that additional effort had to be spent when adding the description of other components with similar / equal capabilities. Moreover this procedure made it difficult to reuse the code generator templates for components with equal capabilities. The observed problem resembles the problem of application development solved by the introduction of the model-driven development tool: large parts of the component descriptions are generic and some of the code generation / configuration logics can be reused in the context of components with similar capabilities. These facts motivate the usage of the model-driven approach and code generation. Based on this observation, the idea was to introduce a multi-phase modeldriven approach: the concept of domain specific development tools to implement systems is adapted to the creation of the development of domain specific development tools themselves. This leads to a speed up in the creation of the development tools. The result is a multi-phase approach, which is elaborated in the next section.

3

Approach

The intention of our approach presented in this paper, is the optimal support of the different developers through a model-driven, multi-phase approach. The basic idea deduces from the general approach of domain specific languages (DSLs) with respect to the model hierarchy, as shown in figure 2. In each phase of the development process, the particular expert can model the relevant fragments. The metamodel of the next phase is then generated through a M2MM transformation. 

 




  

 



  

 



 

 




Fig. 2. Model Hierarchy [3]

The benefits of the model-driven approach through DSLs are particularly exploited when used to create similar systems. This is not only restricted to the actual end product shipped to the customer, but also applies for development tools, which shall be constructed. In case of component-based systems, a modeldriven approach suits not only for the creation of the end product by combining

Model-to-Metamodel Transformation for Component-Based Systems

395

the necessary components. It fits in the same way for the development of similar components. The presented approach has been implemented in the context of the SOA project. Currently altogether three phases are supported: 1. Specification of the relevant information for the run-time system by the runtime system experts 2. Description of supported components done by the component producers 3. Configuration of the application by the application developers These phases are consecutively described further in detail. Afterwards insights into the implementation and code generation steps are given. The approach is used both for hardware and software components. In the context of this paper, we predominantly focus on hardware aspects to have a consistent running example. 3.1

Modeling of the Attributes Used to Describe Components

In the first phase of the approach, run-time system experts specify the information required to describe components used to assemble future applications. Based on the models of the first phase checks, algorithms and steps for code generation are defined. Component unspecific checks can be used to specify tests for correctness of the input models of the third phase. In the example of SOA, e.g. a correct wiring of components only relates to the type of the connected ports (e.g. a temperature input must be connected to a temperature output). By implementing analysis or configuration algorithms, the run-time system experts can define how to calculate a correct schedule or channel assignment / routing. Furthermore, the models of the first phase are used to implement the code generation of the run-time system. This code comprises all the component-unspecific functionality, which normally constitutes the middleware, and serves as a kind of glue code between the different hardware and software components. Figure 3 shows the underlying metamodel for the description of hardware components. The metamodel allows the run-time system experts to define capability types, e.g. Communication, concrete capabilities such as Ethernet and associated attributes. By selecting a proper type for each attribute, the possible values can be restricted and wrong configurations can be prevented in advance. Due to this general specification of capabilities, it is possible to implement the


  



   

     

  



   

    

      

    

   

Fig. 3. Metamodel of the First Phase based on Capability Types, Capabilities and their Attributes

396

G. Kainz et al.

run-time system independently from the concrete components used only based on the capabilities and their assigned attribute values. In SOA for example, it can be checked easily, whether the available bandwidth (specified in the attribute Speed of Ethernet ) is sufficient to satisfy the application requirements or not. Since the description of component capabilities is very simple, it can be assured that the underlying metamodel will seldom be changed. This can be compared with the changes made to the metamodel of UML class diagrams. Therefore, the metamodel of the first phase constitutes a solid base for the following steps. <StringAttribute name="Type"/> <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) <EthernetCard> <EthernetCard_Ethernet MacAddress="00:00:00:00:00:01" IPAddress="192.168.0.1" NetMask="255.255.255.0" Gateway="192.168.0.1" MTU="1500" Speed="Mbps100"/>

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