System Analysis and Modeling: About Models - SAM 2010

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

Author: Frank Alexander Kraemer | Peter Herrmann

105 downloads 1058 Views 7MB Size Report

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

Report copyright / DMCA form

DOWNLOAD PDF

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

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

6598

Frank Alexander Kraemer Peter Herrmann (Eds.)

System Analysis and Modeling: About Models 6th International Workshop, SAM 2010 Oslo, Norway, October 4-5, 2010 Revised Selected Papers

13

Volume Editors Frank Alexander Kraemer Peter Herrmann Norwegian University of Science and Technology (NTNU) Department of Telematics O.S. Bragstads plass 2a, 7491 Trondheim, Norway E-mail: {kraemer, herrmann}@item.ntnu.no

ISSN 0302-9743 e-ISSN 1611-3349 ISBN 978-3-642-21651-0 e-ISBN 978-3-642-21652-7 DOI 10.1007/978-3-642-21652-7 Springer Heidelberg Dordrecht London New York Library of Congress Control Number: 2011929390 CR Subject Classiﬁcation (1998): C.2, D.2, D.3, F.3, C.3, H.4 LNCS Sublibrary: SL 5 – Computer Communication Networks and Telecommunications

© Springer-Verlag Berlin Heidelberg 2011 This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, speciﬁcally the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microﬁlms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply, even in the absence of a speciﬁc statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. Typesetting: Camera-ready by author, data conversion by Scientiﬁc Publishing Services, Chennai, India Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com)

Preface

These are the proceedings of the sixth edition of SAM, the Workshop on System Analysis and Modeling. The workshop provides an open arena for participants from academia and industry to present and discuss the most recent innovations, trends, experiences and concerns in modeling, speciﬁcation and analysis of distributed, communication and real-time systems. In 2010, SAM was co-located with the 13th ACM/IEEE International Conference on Model-Driven Engineering Languages and Systems (MODELS) and held in Oslo, Norway, during October 4–5. The workshop was attended by around 75 participants from 18 countries. Of the 32 manuscripts submitted initially, 16 were selected for presentation at the workshop in a thorough initial reviewing round in which most of the papers were checked by four reviewers and several were improved using shepherds. Taking the feedback from the reviewers and the workshop audience into account, revised versions of 15 manuscripts were collected in this volume after a second in-depth round of reviews. The program was completed by a keynote address on “Service High-Availability” by Ferhat Khendek from Concordia University in Montreal, Canada, and a tutorial by Rick Reed from the SDL Forum Society on SDL-2010. This workshop would of course not have been possible without the dedicated work of the Program Committee members that did a tremendous job in reviewing all submissions thoroughly and acting as shepherds. We would also like to express our gratitude to Øystein Haugen and the entire Organizing Committee of the MODELS conference for enabling the co-location of SAM and taking care of all local arrangements in the Oslo congress centre. Finally, we would like to thank all authors, keynote speakers, session chairs and sponsors, as well as the SDL Forum Society and the Department of Telematics of the Norwegian University of Science and Technology (NTNU). March 2011

Frank Alexander Kraemer Peter Herrmann

Organization

Workshop Co-chairs Frank Alexander Kraemer Peter Herrmann

Norwegian University of Science and Technology (NTNU) Norwegian University of Science and Technology (NTNU)

SDL Forum Society Chairman Secretary Treasurer

Rick Reed Reinhard Gotzhein Martin von L¨ owis

ACM/IEEE/MODELS 2010 Øystein Haugen

SINTEF, University of Oslo, Norway

Program Committee Daniel Amyot Attila Bilgic Rolv Bræk Reinhard Brocks Laurent Doldi Anders Ek Stein-Erik Ellevseth Joachim Fischer Jacqueline Floch Pau Fonseca i Casas Emmanuel Gaudin Abdelouahed Gherbi Reinhard Gotzhein Jens Grabowski Peter Graubmann Øystein Haugen Lo¨ıc Hlou¨et Peter Herrmann

University of Ottawa, Canada University of Bochum, Germany Norwegian University of Science and Technology, Norway HTW Saarland, Germany Isoscope, France IBM, Sweden ABB Corporate Research, Norway Humboldt-Universit¨ at zu Berlin, Germany SINTEF, Norway Universitat Polit`ecnia de Catalunya, Spain Pragmadev, France ´ Ecole de Technologie Sup´erieure, University of Quebec, Canada University of Kaiserslautern, Germany Universit¨ at G¨ottingen, Germany Siemens, Germany SINTEF, University of Oslo, Norway INRIA Rennes, France Norwegian University of Science and Technology, Norway

VIII

Organization

Dieter Hogrefe Clive Jervis Ferhat Khendek Hartmut K¨ onig Alexander Kraas Frank Alexander Kraemer Finn Kristoﬀersen Thomas Kuhn Anna Medve Pedro Merino Tommi Mikkonen Ostap Monkewich Gunter Mussbacher Birger Møller-Pedersen Ileana Ober Javier Poncela Gonz´ alez Andreas Prinz Rick Reed Manuel Rodr´ıguez-Cayetano Richard Sanders Amardeo Sarma Ina Schieferdecker Bran Selic Edel Sherratt Martin von L¨ owis Thomas Weigert Frank Weil Edith Werner

University of G¨ottingen, Germany Motorola, USA Concordia University, Canada BTU Cottbus, Germany Fraunhofer Institute for Communication Systems (ESK), Germany Norwegian University of Science and Technology, Norway Cinderella ApS, Denmark Fraunhofer IESE, Germany University of Pannonia, Hungary University of Malaga, Spain Tampere University of Technology, Finland OMCI, Canada University of Ottawa, Canada University of Oslo, Norway IRIT University of Toulouse, France University of Malaga, Spain University of Agder, Norway TSE, UK University of Valladolid, Spain SINTEF, Norway NEC Laboratories Europe, Germany TU Berlin/Fraunhofer FOKUS, Germany Malina Software Corp., Canada University of Wales, Aberystwyth, UK Hasso-Plattner Institute, Germany University of Missouri-Rolla, USA UniqueSoft, USA Universit¨ at G¨ottingen, Germany

Sponsoring Institutions IEEE Computer Society ACM Sigsoft SDL Forum Society amsys www.eit.uni-kl.de/amsys

Additional Organizers Norwegian University of Science and Technology (NTNU) MODELS 2010

Table of Contents

Modularity, Composition, Choreography SDL Modules – Concepts and Tool Support . . . . . . . . . . . . . . . . . . . . . . . . . Philipp Becker and Marc Kr¨ amer

1

A Developer-Friendly Approach for the Validation of Dynamic Compositions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jacqueline Floch and Cyril Carrez

18

From Flow-Global Choreography to Component Types . . . . . . . . . . . . . . . Surya Bahadur Kathayat and Rolv Bræk

36

Application of SDL and UML Integration of FlexRay into the SDL-Model-Driven Development Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tobias Braun, Reinhard Gotzhein, and Matthias Wiebel

56

Design and Development of a CPU Scheduler Simulator for Educational Purposes Using SDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manuel Rodr´ıguez-Cayetano

72

UML-Based Speciﬁcation and Generation of Executable Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Waﬁ Dahman and Jens Grabowski

91

SDL Language Proﬁles The SDL-UML Proﬁle Revisited . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alexander Kraas

108

Code Generation and Model Transformations A Model Driven Approach for AMF Conﬁguration Generation . . . . . . . . . Pejman Salehi, Pietro Colombo, Abdelwahab Hamou-Lhadj, and Ferhat Khendek

124

SDL Code Generation for Network Simulators . . . . . . . . . . . . . . . . . . . . . . . Mihal Brumbulli and Joachim Fischer

144

A Case Study on API Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Uwe Jugel and Andr´e Preußner

156

X

Table of Contents

Veriﬁcation and Analysis UOST: UML/OCL Aggressive Slicing Technique for Eﬃcient Veriﬁcation of Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Asadullah Shaikh, Uﬀe Kock Wiil, and Nasrullah Memon

173

Extensible and Automated Model-Evaluations with INProVE . . . . . . . . . . S¨ oren Kemmann, Thomas Kuhn, and Mario Trapp

193

Requirements and Solutions for Timing Analysis of Automotive Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Saoussen Anssi, S´ebastien G´erard, Arnaud Albinet, and Fran¸cois Terrier

209

User Requirements Notation Analysing the Cognitive Eﬀectiveness of the UCM Visual Notation . . . . . Nicolas Genon, Daniel Amyot, and Patrick Heymans

221

Towards a Taxonomy of Syntactic and Semantic Matching Mechanisms for Aspect-Oriented Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gunter Mussbacher, Daniele Barone, and Daniel Amyot

241

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

257

SDL Modules – Concepts and Tool Support Philipp Becker and Marc Krämer Networked Systems Group University of Kaiserslautern, Germany {pbecker,kraemer}@cs.uni-kl.de

Abstract. SDL, ITU’s Speciﬁcation and Description Language, supports developing systems in a modular and hierarchical way, based on structural type deﬁnitions and their instantiations. Also, reuse is supported by the possibility to deﬁne collections of type deﬁnitions, e.g., as SDL packages, that can be used in diﬀerent systems. Another important development task that can be supported by packages is the replacement of system parts, i.e., structural instances. This can be achieved, for instance, by replacing the type deﬁnition to which an instantiation refers by using another package containing a compatible type. However, we have found that this apparently elegant solution reveals some intricacies in practice. To fully exploit the beneﬁts of packages for the development of complex systems and system versioning, type deﬁnitions are typically collected in a considerable number of packages. Moreover, there usually are numerous dependencies among packages, which make their management an error-prone task. Finally, it is not clear which types are compatible such that they can be used as mutual replacements. In this paper, we propose a clean solution for the replacement of system parts. Therefore, we introduce a concept that we call SDL module, which we use to capture compatibility of structural type deﬁnitions and replacement rules. We illustrate the applicability of our approach by presenting an in-house development tool to automate the replacement process. This tool can be utilized to speed up the development process, and adapt SDL systems to diﬀerent platforms and scenarios. Keywords: SDL, MDD, Modules, Components, Interfaces, Packages, Tool Support.

1

Introduction

Developing systems with SDL, ITU’s Speciﬁcation and Description Language [1], has certain well-known advantages over conventional development processes. One of these advantages is SDL’s inherent feature to structure and develop systems in a modular and hierarchical way. The hierarchical structure allows us to design a system by creating only a few representative blocks in the beginning, depicting the overall system structure. Then the system can be reﬁned iteratively, becoming more complex with every step. During this reﬁnement process, new structures, type deﬁnitions, and functionalities are added and encapsulated in various types of SDLs structural units on diﬀerent layers. F.A. Kraemer and P. Herrmann (Eds.): SAM 2010, LNCS 6598, pp. 1–17, 2011. c Springer-Verlag Berlin Heidelberg 2011

2

P. Becker and M. Krämer

The encapsulation process is also supported by the way interaction is realized in an SDL system between such structural units as blocks, processes, or services. As these units normally only interact by means of signals transported over signal routes and channels, the internal structure of other connected units can remain hidden. Therefore, SDLs structural units are mostly following the black box principle, providing functionality to other parts of the system over a deﬁned, unitdependent interface (signals, gates, etc), but hiding their inner details. We say that the units are “mostly” following that principle, because they are not necessarily self-contained, for they can still have dependencies on other structural units they are using, e.g. via USE statements in SDL packages. Exchanging such structural units is simple in theory: Remove the unit from the system, and instead insert another one of the same type, ideally with the same name and interface, and a similar behavior against other connected units. In practice, however, severe problems may arise. In this paper, we address these problems and how they can be overcome. The remainder of this paper is structured as follows: Section 2 describes the problems that can occur when exchanging structural units in SDL. In Sect. 3, we take a closer look at already existing SDL language mechanisms and tool support to cope with these problems, and give reasons why they are not suﬃcient. Section 4 introduces the SDL module concept that we propose to handle these problems. In Sect. 5, we present our tool SPaSs that supports the application of our module concept. Finally, Sect. 6 concludes this paper and points out future work.

2

Motivation

During the development of complex systems with SDL, there are various reasons for replacing parts of SDL systems by other ones. In this section, we want to point out two of these reasons, and then take a close look at the problems that can arise during this process. With increasing size, SDLs speciﬁcations tend to become utterly complex over time, an observation that is not limited to SDL. The eﬀect is intensiﬁed with a growing number of structural units contained in a system, and the dependencies among these units. This renders system development diﬃcult, especially if multiple developers are working on the same system at a time. Here, complexity can be reduced by splitting up the system into parts that are developed separately. These parts can be structured as SDL packages, using the type concept of SDL. Nevertheless, the introduced packages have dependencies with other packages, and the complexity of the system rises. To illustrate the complexity that can already occur on package level, we use MacZ as an example, one of our in-house developed MAC protocols, that has grown over time by adding new functionality. Yet, it has ended up with a very large number of diﬀerent units with various dependencies that have become diﬃcult to manage, although organized in packages. Figure 1 shows the package

SDL Modules – Concepts and Tool Support

3

dependency graph of MacZ, where each of the 35 packages is represented as a box and each of the 197 edges represents a dependency relation between two packages. In system designs where MacZ is used, the system designer has to add all these packages and identify duplicates brought in by dependency relations of diﬀerent packages by hand. If MacZ is modiﬁed during further development, and packages are added or removed, all SDL systems using MacZ must be updated as well. Second, although SDL speciﬁcations are intended to be platform-independent, it can still be necessary to have diﬀerent speciﬁcations for diﬀerent platforms. Take, e.g., a system providing voice communication over arbitrary network media. Here, the choice of the MAC layer depends, amongst other things, on the target platform and whether the communication is done wired (e.g., Ethernet), wireless (e.g., WLAN), or inside a simulation environment, where debugging information is written to log ﬁles. One possibility to overcome this problem is to keep one SDL system per conﬁguration (i.e., desired combination of existing structural units). This approach is only applicable as long as there are only few units that need to be replaced. Otherwise, the number of resulting SDL systems may grow exponentially, making it harder to maintain all systems and keeping them in a consistent state of development. Another possibility is to keep only one SDL system and switch to the adequate SDL units in the system speciﬁcation whenever code for a diﬀerent platform is generated. Depending on the system structure, the necessary changes may be spread over several structural layers and units, e.g., USE statements that have to be adjusted in various SDL packages. Replacing SDLs structural units and adjusting related dependency statements currently can not be done automatically by means of SDL’s own mechanisms or any program known to us. Therefore, we propose a concept called SDL module that provides a way to replace structural units in SDL systems along with their dependencies, and also allows us to do so in an automated way. Managing multiple SDL speciﬁcations in a way that they can be exchanged against each other can be done in diﬀerent ways. Here, we want to concentrate on two of them: using a single SDL package, and using multiple packages. Figure 2 shows one possibility to organize some structural units in one SDL package. As

Fig. 1. Dependency graph of the MAC protocol MacZ

4

P. Becker and M. Krämer USE myMac1Package1; USE myMac1Package2; USE myMac2Package1; USE myMac2Package2;USE myMac2Package3; USE dummyMacPackage1; USE myMacSimulationPackageX; USE generalPackage1; USE globalPackage2; USE dataTypesMac1; USE dataTypesMac2; USE dataTypes;

USE Application; USE MiddleWare; USE Routing; USE MAC;

system main

package MAC

middleware: myMiddleware g2 a

(App2Mw)

g3

(Mw2Rt) (Rt2Mw)

b

routing: myRouting g5

g4

c

(Mw2App)

myMac1

dummyMac

myMac2

myMacSimulation

(Mac2Rt) (Rt2Mac)

g1 application: myApplication

g6 mac: myMac1 g7 (Env2Mac)

d

SIGNALLIST Env2Mac= (MacInSignals);

SIGNALLIST Mac2Env= (MacOutSignals);

(Mac2Env)

(a) Typical communication architecture (b) Package with diﬀerent MAC protocol speciﬁcations Fig. 2. Several SDL speciﬁcations organized in one package

example, we take an SDL system with a typical communication architecture as shown in Fig. 2(a), consisting of four top level blocks. Package MAC, as shown in Fig. 2(b), contains four diﬀerent exchangeable speciﬁcations that may be instantiated by the mac block from the system in Fig. 2(a). In Fig. 2(b), all MAC layer speciﬁcations are located in the same SDL package, each realized as a block type. The signals used to interact with other parts of the system are speciﬁed once in package MAC and are used by all included block types. The list of 12 USE statements is the union of all included block types’ dependencies. To use one of these MAC speciﬁcations, the package is referenced in the system diagram (Fig. 2(a)). The currently used speciﬁcation is chosen by instantiating the appropriate block type, which is myMac1 in the given example. The other possibility to organize diﬀerent speciﬁcations is shown in Fig. 3. Here, we show how a system is organized and prepared for diﬀerent MAC layers using one SDL package per exchangeable speciﬁcation. As shown, every speciﬁcation is identiﬁed by its SDL package name, and includes only its own dependencies. For the exchange of functionality in the system, only the USE statement needs to be replaced. Note that the same signal lists and block types have to be deﬁned in each MAC package, since it is not possible to inherit other packages nor is it possible for the other MAC packages to USE MACIF, because then we would have a double deﬁnition of block type MAC. Summing up, both approaches have advantages and disadvantages: In the ﬁrst approach, the SDL package gives an overview over the existing exchangeable speciﬁcations and the interface is only speciﬁed once. Also, several of the speciﬁed block types can be instantiated at the same time in one system. Here, the complete dependencies of all available speciﬁcations are included in the package and have to be met in the system. On the other hand, using the second approach, each package only includes the dependencies that are required for the particular speciﬁcation. This allows SDL packages to be smaller and have a clearer structure. Even though both approaches allow multiple developers to work concurrently

SDL Modules – Concepts and Tool Support

5

USE ApplicationIF; USE MiddleWareIF; USE RoutingIF; USE MACIF;

system main middleware: Middleware g2 a

g3

(Mw2Rt)

b

routing: Routing g5

g4

(Rt2Mw)

(App2Mw)

c

(Mw2App)

(Mac2Rt)

package MACIF

(Rt2Mac)

g6

g1 application: Application

mac: MAC

SIGNALLIST Env2Mac= (MacInSignals);

MAC

g7

SIGNALLIST Mac2Env=(MacOutSignals);

(Env2Mac)

d (Mac2Env)

(a) Communication architecture, adapted (b) Common interface for all MAC layers to one speciﬁcation per package USE myMac1Package1; USE myMac1Package2; USE generalPackage1; USE globalPackage2; USE dataTypesMac1; USE dataTypes;

USE myMacSimulationPackageX; USE generalPackage1; USE globalPackage2; USE dataTypesMac1; USE dataTypes;

package myMac1

package myMacSimulation SIGNALLIST Env2Mac= (MacInSignals);

MAC

SIGNALLIST Mac2Env=(MacOutSignals);

(c) Speciﬁcation of myMac1

SIGNALLIST Env2Mac= (MacInSignals);

MAC

SIGNALLIST Mac2Env=(MacOutSignals);

(d) Speciﬁcation of myMacSimulation

Fig. 3. Single speciﬁcation per package, basis for our SDL module concept

on diﬀerent exchangeable speciﬁcations, we favor the second approach, because SDL speciﬁcations may be in a syntactically inconsistent state while developers are working on them. As a result, using the ﬁrst approach means that none of the other speciﬁcations can be used during that time as well, as a syntax check of the complete system would fail. For our SDL module concept, we follow the second approach, where each exchangeable SDL speciﬁcation is included in its own SDL package.

3

Related Work

According to the SDL standard [1] and a common SDL text book [2], we identiﬁed a few techniques from SDL for the exchange of functionality. One technique often used in SDL is to convert blocks to block types and processes to process types, then move them to SDL packages and use instantiations in the rest of the system. Additionally, the package has to be included in the (Tau) organizer and a USE statement has to be added to the system diagram. To exchange the functionality, two strategies exist: replace the USE statement, or rename the block type to the desired speciﬁcation. Both tasks require adding the intended packages to the organizer, and updating all instantiated type names to the new unit type

6

P. Becker and M. Krämer

names speciﬁed in the included packages. For large and distributed SDL designs, the organizer view becomes confusing and the update process is error-prone. Via the IBM Rational Tau-speciﬁc [3] keyword /*#include ...*/, it is possible to include additional PR ﬁles at arbitrary places throughout the system. But this inclusion is limited, since the Tau Analyzer does not recognize PR definitions (e.g., packages, block types) in this ﬁle and thus reports non-existing errors like unfulﬁlled dependencies. As a side-eﬀect, this can lead to multiple occurrences of the same package deﬁnition in a system, which results in error messages by the Tau code generator. Another approach for the design of exchangeable structures is presented in [4]. These so-called Micro Protocols are speciﬁed in SDL, and bundled into packages. To use a micro protocol, the package is added to the organizer, as well as a matching USE statement and a block instance of the speciﬁc type. Although all micro protocols of the same type have a deﬁned interface, and a documentation of their functionality is available, the problems pointed out before still apply. For Java [5], there exists the build tool Maven [6], created by the Apache Software Foundation, which is in fact a build tool like GNU make [7]. This tool faces the fact that one project consists of other projects in speciﬁc versions that are needed for the build process. Maven reads its conﬁguration ﬁle, fetches all required projects, builds them and links them together. For SDL, a tool with similar functionality as Maven regarding diﬀerent projects and versions, paired with a deﬁned interface of the subprojects conforming to the SDL standard, integrated in tools like IBM Rational Tau, and supporting splitting work to diﬀerent persons is needed. This leads directly to our approach, consisting of the SDL module concept and the tool SPaSs, which we are presenting in this paper.

4

Exchangeable Modules in SDL

In this section, we present our concepts of SDL module and SDL module interface, along with some explanatory examples of their usage. 4.1

Concept of SDL Modules

We deﬁne an SDL module interface as a minimal structural SDL unit that contains SDL type deﬁnitions for, e.g., block types, process types, signal types, and data types. The purpose of an SDL module interface is to provide a description for the minimal requirements other SDL units of the same type have to fulﬁll to provide the same interface. An SDL module interface is syntactically complete and provides minimal SDL speciﬁcations for all included type deﬁnitions. A minimal speciﬁcation deﬁnes a name and interface for each included type deﬁnition, but omits as much functionality as possible. The interface of SDL types like, e.g., block types, includes not only the list of in- and outgoing signals, but also the names of the SDL gates and the correlation between signals and gates. An SDL module interface may also include a detailed informal description of the intended functionality in form of SDL comments.

SDL Modules – Concepts and Tool Support

7

In SDL systems, module interfaces can be used as placeholders, e.g. during the development process, to be replaced later by other SDL units of the same type that specify the same interface with full functionality. As an SDL module interface is syntactically complete and also provides the expected interface, SDL syntax checkers (e.g., IBM Rational Tau Analyzer [3]) should not trigger any additional warnings. Listing 1.1. Example of an SDL module interface in SDL-PR representation 1 2 3 4 5 6 7 8 9 10 11 12 13 14

PACKAGE MiddleWareIF ; SIGNAL i n S i g n a l ; BLOCK TYPE MiddleWare ; GATE inGate IN WITH i n S i g n a l ; SIGNALROUTE r t FROM env TO emptyProc WITH i n S i g n a l ; PROCESS emptyProc ; start ; NEXTSTATE i d l e ; STATE i d l e ; ENDPROCESS emptyProc ; ENDBLOCK TYPE MiddleWare ; ENDPACKAGE MiddleWareIF ;

An example of an SDL module interface is given in List. 1.1. Here, our SDL module interface is the SDL package MiddleWareIF, speciﬁed in SDL-PR. We specify a block type MiddleWare with a single gate inGate that only takes signals of signal type inSignal. To make this speciﬁcation syntactically complete, we also specify a process emptyProc that is connected to the gate and only contains the start state connected to an additional state idle. An SDL module is deﬁned as a set of SDLs structural units that forms a transitive closure w.r.t. the units’ dependencies. This means that all dependencies of all included units are also part of this SDL module. We say that an SDL module complies to an SDL module interface iﬀ the SDL module contains a structural unit of the same type as the interface and this unit provides speciﬁcations for all type deﬁnitions included in the interface. As a result, diﬀerent SDL modules that comply to the same SDL module interface can be exchanged against each other. An SDL module may comply to more than one SDL module interface. In Fig. 4, we give an example for a dependency graph of some structural units to explain our module concept. On the left side of the ﬁgure, we have some structural unit and their dependency relations. On the right side, we have identiﬁed all possible SDL modules in this dependency graph, along with the SDL module interfaces they comply to. Take, e.g., the set of units S1 = {B, D, E}. This set forms an SDL module, because the dependencies of all included units are also part of this set. In the ﬁgure, this is labeled as SDL module M4 . As this module includes unit B, which complies to interface Y , and unit D, which complies to interfaces V and W , the SDL module complies to SDL module interfaces Y , V , and W . On the other hand, the set of units S2 = {A, C, D} does not form an SDL module, since unit D depends on unit E that is not part of set S2 .

8

P. Becker and M. Krämer

Fig. 4. Exemplary dependency graph for some SDL units

Following the deﬁnition, an SDL system could be deﬁned as a single SDL module that complies to all used SDL module interfaces. But we want SDL modules to be exchangeable units, and exchanging the entire system is not very reasonable. Therefore, we introduce the notion of minimal SDL modules. We deﬁne an SDL module to be minimal for a given SDL module interface iﬀ there exists an SDL unit within this module that complies to the given SDL module interface, and all other SDL units included in this SDL module are direct or indirect dependencies of that unit. An equivalent deﬁnition is that there exists no strict subset of included SDL units that still forms a transitive closure w.r.t. the dependencies and also complies to the given SDL module interface. In the example of Fig. 4, module M2 is a minimal SDL module for SDL module interface X , M4 is minimal for Y , and M6 is minimal for interfaces V and W . The deﬁnition of minimal SDL modules avoids having multiple structural units in a single SDL module that comply to diﬀerent SDL module interfaces, but do not have any direct or indirect dependency relation to each other. An important point here is that minimal SDL modules for a given interface can be constructed automatically by taking the interface-compliant structural unit as starting point and recursively adding all dependencies. 4.2

Usage of SDL Modules

In the following, we will specify SDL modules only on SDL package level. This means that all following SDL modules solely consist of (sets of) SDL packages. Additionally, when speaking of SDL modules for a given SDL module interface, we always mean minimal SDL modules for this interface. Figure 5 shows an example for the development of a routing protocol for a communication system. Following good practice, the routing protocol is placed between middleware and MAC layer. By using the SDL module interfaces Mid_ dleWareIF and MACIF as placeholders and instantiating the provided block types MAC and MiddleWare, we can continue to develop our routing protocol even if

SDL Modules – Concepts and Tool Support

9

no functionally complete SDL speciﬁcations for MAC layer and middleware are present. This way, our system is kept small and reduced to what is absolutely necessary during development. The developer is not bothered with warnings or errors from other speciﬁcation parts and can therefore concentrate on his part. As a positive side eﬀect, system analysis, e.g. done by the Tau Analyzer, is sped up. Both block types provided by the interfaces MiddleWareIF and MACIF contain a single empty process, emptyProc (cf. Fig. 5), which is functionally incomplete (cf. List. 1.1, lines 7–11), but syntactically complete and connected to the block types’ gates to satisfy SDL syntax checking tools. USE ConcreteRouting1; USE MiddleWareIF; USE MACIF;

system RoutingDevelopment

myMiddleWare: MiddleWare toRT MwRt

(RTtoMW)

MiddleWareIF MiddleWare emptyProc MACIF MAC emptyProc

(MWtoRT)

toUPPER myRouting: Routing toMAC RtMac

(MACtoRT)

(RTtoMAC)

ConcreteRouting1 Routing Multiplexer RoutingStatus RouteDiscovery PacketForwarder

toUPPER myMAC: MAC toEnv MacEnv

(EnvtoMAC) (MACtoEnv)

RoutingDevelopment myMAC : MAC x:y myMiddleWare : MiddleWare x:y myRouting : Routing x:y

Fig. 5. System overview during the development of a routing protocol module

To simulate SDL modules under development, we have two options. One possibility would be to insert the module into other, functionally complete systems to perform functional simulations. But simulating a complete system when we are only interested in the behavior of a single SDL module has some disadvantages and often only complicates the validation process. This leads us to the second possibility: Setting up a dedicated simulation environment for single SDL modules. To realize this, we can develop special SDL modules solely for simulation purposes. In the example given in Fig. 5, MACIF and MiddleWareIF can be replaced by such simulation modules. These SDL modules can specify black box test environments for the connected modules under development. Of course, the simulation modules also have to comply to the appropriate SDL module interfaces. As modules should be exchangeable, this does not only provide a

10

P. Becker and M. Krämer

simulation environment for a single SDL module, but for the whole SDL module interface. Diﬀerent modules can be inserted into this environment to see if they comply to a given module interface and provide the expected behavior.

5

The SDL Package Substitution Tool

To support the process of managing and exchanging SDL modules that comply to the same module interface, we have developed the platform-independent SDL Package Substitution tool (SPaSs). SPaSs is publicly available from our homepage [8]. It works directly on regular SDL-PR ﬁles as well as on all ﬁles following SDLs Common Interchange Format (CIF) speciﬁcation [9], and is therefore independent of SDL development environments. Often, these development environments provide some kind of export functionality to produce PR or CIF ﬁles out of the SDL-GR speciﬁcations, and vice versa via CIF import. To suit our needs and simplify the task of exchanging SDL modules, we have limited their use to sets of SDL packages, i.e., each SDL module consists of one or multiple SDL packages. 5.1

Overview

As input, SPaSs takes an SDL-PR ﬁle, optionally with included CIF annotations, that contains a system speciﬁcation and its dependent packages, together with a set of mapping instructions contained in a separate conﬁguration ﬁle. The mapping instructions specify which modules should be replaced and in which PR ﬁles the new modules can be found. As a result, a new PR ﬁle is produced which can be processed by arbitrary SDL-PR processing tools, e.g., code generators. In detail, starting from the SDL system contained in the given PR ﬁle, a recursive process begins where the dependencies of all major SDL units (system, packages) are identiﬁed via their USE statements. Following these statements, we successively build a dependency graph that includes the SDL system and all related SDL packages. After that, the mapping instructions from the conﬁguration ﬁle are applied to this graph to perform the substitution of SDL modules contained in this graph. Conﬁguration ﬁles follow a naming convention that allows us to have a bijective mapping between SDL-PR ﬁle and conﬁguration ﬁle. Each conﬁguration ﬁle may include an arbitrary number of so-called mapping targets. Mapping targets are named sets of mapping instructions. They can be used to deﬁne diﬀerent mappings for the same SDL system, and allow us to keep mappings for diﬀerent purposes (e.g., simulations, platform) in one place and easily switch between them. The name of the mapping target that should be used during the substitution process can be passed to the tool on the command line. There may also exist one unnamed mapping target, which is the default target. The entries from this target will be inherited by all other mapping targets. We have currently abstained from including additional syntax checks in the tool to see whether exchanged SDL modules comply to the same SDL module

SDL Modules – Concepts and Tool Support

11

Listing 1.2. System conﬁguration 1 2 3 4 5 6 7

< ! - - D e f i n i t i o n o f g l o b a l d a t a s o u r c e s f o r t h e m a p p i n g s e c t i o n - -> <s r c name=" g l o b a l D i r " t y p e=" f i l e " s r c=" /home/ k r a e m e r/SDL" /> <s r c name="svnSDL" t y p e=" svn " s r c=" h t t p : // s v n s e r v e r / svn /SDL" b r a n c h=" dev " r e v=" 123 " u s e r=" g u e s t " pwd=" g u e s t " />

8

< ! - - D e f a u l t m a p p i n g w h e n u s i n g t h i s c o n f i g f i l e , a l w a y s a p p l i e d - -> <Mapping> <entry s e a r c h=" MiddleWareIF " r e p l a c e="WNCS_MW" f i l e ="wncs_mw . p r " s r c=" svnSDL" /> <entry s e a r c h=" R o u t i n g I F " r e p l a c e="AODV" f i l e =" R o u t i n g / aodv . p r " s r c="svnSDL" r e v=" " b r a n c h=" t r u n k " /> <entry s e a r c h="MACIF" r e p l a c e="CSMA_CA" f i l e ="MAC/ csma . p r " s r c="svnSDL" r e v=" " b r a n c h=" t r u n k " t a r g e t=" v e r b o s e " />

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

< ! - - N a m e d m a p p i n g t a r g e t - -> < ! - - E n t r i e s m a y o v e r w r i t e o t h e r e n t r i e s f r o m D e f a u l t m a p p i n g - -> <Mapping t a r g e t=" debug "> <entry s e a r c h=" A p p l i c a t i o n " r e p l a c e="WNCS_Simple" f i l e ="App/ wncs_simple_app . p r " s r c=" g l o b a l D i r " t a r g e t=" debug " />

interface. Although this should be possible, a ﬁnal syntax check will normally be done anyways during code generation, in our case by our code generator ConTraST [10]. 5.2

Configuration Files

We will now show in detail how a conﬁguration looks like and how the tool works with a given conﬁguration. For better maintainability, we have deﬁned three conﬁguration levels: system-wide, user-wide and SDL module-speciﬁc. System-wide conﬁguration is maintained by the computer system administrator and has the lowest precedence. User-wide conﬁguration is maintained by the developer, and is located in his or her home directory. The SDL module-speciﬁc conﬁguration is maintained by the developer of an SDL module and has the highest precedence. The conﬁguration ﬁles are written in XML notation for ease of use and ﬂexibility. In List. 1.2, we show a conﬁguration ﬁle that can be used for the routing protocol example in Fig. 5. The mapping between a PR ﬁle and the respective conﬁguration ﬁle is done by following a naming convention, where the name of the conﬁguration ﬁle must be «pr-filename».cfg. The ﬁrst line of the conﬁguration ﬁle is for compliance to XML speciﬁcations. Next follows a section named Config, encapsulating sections named Global and Mapping. The Global section contains src-entries, specifying multiple data sources where the required SDL modules can be found. The Mapping section consists of entry elements. Each entry element speciﬁes the replacement of a single SDL module.

12

P. Becker and M. Krämer

Listing 1.3. MAC layer conﬁguration 1 2 3 4 5

<s r c name="svnSDL" t y p e=" svn " s r c=" h t t p : // r n s 3 / svn /SDL" b r a n c h=" t r u n k " u s e r=" g u e s t " pwd=" g u e s t " />

6 7 8 9 10

<Mapping> <entry s e a r c h=" S y n c h r o n i z a t i o n " r e p l a c e="BBS" f i l e =" bbs . p r " s r c="svnSDL" /> <entry s e a r c h=" L o g g e r I F " r e p l a c e=" N u l l L o g g e r " f i l e =" l o g g e r . p r " s r c="svnSDL" />

11 12 13 14 15

<Mapping t a r g e t=" v e r b o s e "> <entry s e a r c h=" L o g g e r I F " r e p l a c e=" V e r b o s e L o g g e r " f i l e =" l o g g e r . p r " t a r g e t=" debug " s r c="svnSDL" />

Now, we will take a closer look at the two main conﬁguration sections, Global and Mapping: Global: Currently we support two diﬀerent source types in the Global section, file and svn. Each entry must have at least three attributes: name, type and src. The name attribute identiﬁes the source location and must be unique for the conﬁguration ﬁle, but can override entries from user-wide or system-wide conﬁguration ﬁles. The type attribute speciﬁes the source type, e.g., file or svn, and src speciﬁes the location of the ﬁles. For version control types like svn (subversion [11]), we have deﬁned speciﬁc attributes like rev for a version number, branch for the repository branch, as well as user and pwd, which might be needed to log into the version control system. Mapping: Each mapping section optionally speciﬁes its name with the attribute target. There may be at most one unnamed mapping section in a conﬁg ﬁle, the default mapping section. The mapping target for the main SDL system can be passed to the tool on the command line. If no target is speciﬁed, the default mapping is used, else the default mapping is inherited and specialized by the speciﬁed mapping target. Inside each Mapping section, entry entries are located. Each entry has at least the four attributes search, replace, file and src. The attributes search and replace each contain the name of a single SDL package. The minimal SDL modules for these packages are automatically determined as described in Sect. 4.1. The search module will be replaced later by the replace module. The new module is located in file, which is found in the referenced data src that was speciﬁed in the Global section. Additionally, an entry can overwrite speciﬁc attributes of the src deﬁnition. An example for this is shown in line 12 of List. 1.2, where another revision and branch are speciﬁed for the svnSDL source. Control over the replacement is gathered by the target attribute of entry (cf. line 13). This line chooses the target verbose for MacZ.

SDL Modules – Concepts and Tool Support

13

The complete MAC layer conﬁguration example is shown in List. 1.3. It can be seen that there is a target verbose in the Mapping section which resolves the requested target from List. 1.2, line 13. 5.3

SPaSs Main Substitution Algorithm

The algorithm used for the substitution of the SDL module interfaces by the concrete SDL modules is structured as shown in List. 1.4. The shown substitution algorithm consists of a main() method (lines 1–10) to start the substitution process, and a substitute() method (lines 12–43) that contains the substitution algorithm in a recursive form. Lines 2–5 initialize the variables with arguments given to the tool on the command line. These variables are used for the initial call to the substitute() method in line 7. Finally, the result from the substitution is written to an output ﬁle as shown in line 9. The substitute() method ﬁrst determines which packages from the given set need to be replaced. These packages are determined by reading the mapping entries included in the mapping target section from the given conﬁg ﬁle (line 16). All packages that will be replaced are then processed in the loop starting at line 20. Here, we ﬁrst read the mapping entry associated with the current package and target (line 24). This mapping entry is used to read and parse all SDL packages from the replacement PR ﬁle (line 27), and perform the recursive substitution process on this new set of packages (line 29). The recursion will stop as soon as the tool processes a PR ﬁle where no substitutions are necessary, e.g., because there is no conﬁg ﬁle for this PR ﬁle. In line 33 the original package is removed from the result set of packages, which is then merged with the new set of packages (line 34). As only single packages have been removed from the result set in line 33, there may still exist packages in this set that have no direct or indirect dependency relation to the main unit (which is the main SDL system in the initial method call, cf. lines 3 and 7) and thus can be removed from the set. Therefore, we use the current set of packages included in result to build a new transitive closure for the main unit in line 40 after the foreach loop has ﬁnished. Packages that are directly or indirectly referenced by the main unit are included in the new set, all other packages are left out. The resulting set of packages is returned to the caller and, as stated above, written to a ﬁle after the substitute() call from the main() method is ﬁnished. An example of using SPaSs on a given system and its result is shown in Fig. 6. In Fig. 6 (a), we have a system only consisting of three placeholders, for middleware, MAC layer, and routing protocol, together with the USE statement from the main system. After using SPaSs with the conﬁguration given in List. 1.2, we get the system shown in Fig. 6 (b). Here, the three placeholder packages were replaced with existing, fully speciﬁed packages, together with their dependencies. Additionally, the USE statement from the main system was also automatically adjusted to the new system structure.

14

P. Becker and M. Krämer Listing 1.4. Substitution algorithm in pseudo code

1 2 3 4 5

main ( ) { Pack ageSet p a c k a g e s = parsePR ( cmdLine . g e t I n p u t F i l e ( ) ) ; U n it sy stem = p a c k a g e s . getSy stem ( ) ; C o n f i g c f g = getConfigForPR ( cmdLine . g e t I n p u t F i l e ( ) ) ; Target t a r g e t = cmdLine . g e t T a r g e t ( ) ;

6

p a c k a g e s = s u b s t i t u t e ( pack ages , system , c f g , t a r g e t ) ;

7 8

cmdLine . g e t O u t p u t F i l e ( ) . w r i t e ( p a c k a g e s ) ;

9 10

}

11 12 13

s u b s t i t u t e ( Pack ageSet pack ages , Unit mainUnit , C o n f i g c f g , Target t a r g e t ) {

14

// r e a d c o n f i g t o f i n d o u t whi ch p a c k a g e s w i l l be r e p l a c e d Pack ageSet r e p l a c e = p a c k a g e s . getPack age sT o R e pl a ce ( c f g , t a r g e t ) ;

15 16

17

Pack ageSet r e s u l t = p a c k a g e s ; // don ’ t modi f y o r i g i n a l s e t

18 19

foreach ( Unit o l d : r e p l a c e ) {

20 21

// A MappingEntry c o n t a i n s a l l n e c e s s a r y i n f o r m a t i o n // a b o u t t h e e x c h a n g e o f a s i n g l e SDL p a c k a g e MappingEntry me = c f g . getMappingEntry ( old , t a r g e t ) ;

22 23 24

25

// g e t new p a c k a g e s from a s s o c i a t e d PR f i l e Pack ageSet newSet = parsePR (me . g e t F i l e ( ) ) ;

26 27

// r e c u r s i v e s u b s t i t u t i o n i n new p a c k a g e s i f n e c e s s a r y newSet = s u b s t i t u t e ( newSet , me . g e t R e p l a c e ( ) ,

28 29

me . g e t C o n f i g ( ) , me . g e t T a r g e t ( ) ) ;

30 31

33

// merge r e s u l t s from r e c u r s i v e r e s u l t . remove ( o l d ) ;

34

r e s u l t . merge ( newSet ) ;

32

call

}

35 36

// removes a l l p a c k a g e s t h a t have no d i r e c t or i n d i r e c t // dependency r e l a t i o n t o t h e main u n i t ( p a c k a g e or // s y s t e m ) r e s u l t = r e s u l t . b u i l d T r a n s i t i v e C l o s u r e ( mainUnit ) ;

37 38 39 40

41

return resu lt ;

42 43

}

SDL Modules – Concepts and Tool Support USE MiddleWareIF; USE RoutingIF; USE MACIF;

MiddleWareIF MiddleWare emptyProc MACIF MAC emptyProc RoutingIF Routing emptyProc RoutingDevelopment myMAC:MAC x:y myMiddleWare:MiddleWare x:y myRouting:Routing x:y

USE WNCS_MW; USE AODV; USE CSMA_CA; USE CC2420Signals; USE CC2420_Driver; USE SenfPhy; USE O_String;

WNCS_MW MiddleWare ReservationManager StatusManager StatusComm Multiplexer Distributor ConnectionManager RoutingInteraction RequestHook ResponseHook TimeoutHook Multiplexer CSMA_CA MAC PhyComm RTS_CTS ConflictHandling ConflictDetection StatusReaction CalcTimer Multiplexer CalcNAV

(a) System before substitution

15

AODV Routing Multiplexer RoutingStatus RouteDiscovery PacketForwarder CC2420Signals CC2420Driver GenericADTFixed O_String SenfPhy Logger LogIF RoutingDevelopment myMAC : MAC x:y myMiddleWare : MiddleWare x:y myRouting : Routing x:y

(b) System after substitution

Fig. 6. Placeholder system with system structure and main system’s USE statement before and after module substitution using the conﬁguration from List. 1.2

6

Conclusions and Future Work

We have presented a practical approach to structure SDL designs into smaller and reusable SDL modules, and realized the approach based on existing language features. For that, we came up with the concept of SDL modules as units, which are exchangeable if they comply to the same SDL module interface. Since no new language feature was introduced, we realized an SDL module interface as minimal, syntactically complete, but functionally incomplete SDL speciﬁcation. The SDL module concept allows developers to concentrate on speciﬁc small tasks. System designers, on the other hand, can use SDL modules to design structural units on a high abstraction level, independent of the current development status of each module. The introduction of minimal SDL modules allows us to automatically derive SDL modules from a given SDL package, which is then utilized in our SPaSs tool. SPaSs is publicly available for download from our home page [8]. It allows us to easily exchange SDL modules on the SDL package level and thus gives us high ﬂexibility during system development. Via the target concept, known from tools like make [7], the system designer is able to choose which module interfaces are replaced by a speciﬁc implementation for the desired target. Using this approach, we have shown a way to provide black box test environments by specifying special SDL modules for simulation purposes.

16

P. Becker and M. Krämer

SDL’s current ability to exchange its structural units could be improved further by adding new language features for the use of interfaces. Currently, there exists no possibility to natively deﬁne interfaces in SDL such that SDL units as, e.g., block types have to comply to this interface. What is possible, though, is to declare some of SDL’s type deﬁnitions as virtual to specialize or redeﬁne them later, which could be seen as some kind of interface deﬁnition. However, using virtual in practice is cumbersome without adding much to our task, so we have refrained from using it. Besides, in SDL inheritance cannot be used on package level, so it is not possible to specify all signals and empty type deﬁnitions with a deﬁned interface in one package, inherit from it, and just add redeﬁnitions of the included types. In the future, some improvements to the tool are planned. At the moment it is only capable of replacing SDL units at package level. This ability could be extended to replace other things as well, e.g. signal types. Thus, we can avoid SDL processes whose only purpose is signal type conversion, which may sometimes happen between diﬀerent design layers. Also, we consider adding an interface checker to the tool that can compare the interface speciﬁcations of diﬀerent SDL modules to check if they comply to the same interface. This could be done by means of special annotations in form of SDL comments that specify to which SDL module interface an SDL module should comply. When exchanging SDLs structural units, we can check if both comply to the same module interface, according to the comments, and also check against the SDL module interface speciﬁcation to ensure that all required speciﬁcations are present. Conditional exchange is also something we are currently considering. Here, module exchange is bound to certain conditions or limited to certain areas of the SDL system. Finally, although SPaSs is written to work with any SDL-PR ﬁle and on any (Java-supported [5]) platform, it has so far only been tested with PR code generated by IBM Rational Tau [3] and on Linux.

References 1. International Telecommunication Union: Recommendation Z.100, Speciﬁcation and Description Language (SDL) (November 2007), http://www.itu.int/rec/T-REC-Z.100/en 2. Ellsberger, J., Hogrefe, D., Sarma, A.: SDL– Formal Object-oriented Language for Communication Systems. Prentice-Hall, Englewood Cliﬀs (1997) 3. IBM: Rational SDL Suite (2011), http://www-01.ibm.com/software/awdtools/sdlsuite 4. Fliege, I., Geraldy, A., Gotzhein, R., Schaible, P.: A Flexible Micro Protocol Framework. In: Amyot, D., Williams, A.W. (eds.) SAM 2004. LNCS, vol. 3319, pp. 224– 236. Springer, Heidelberg (2005) 5. Oracle Corporation: Java (2011), http://java.sun.com 6. Apache Software Foundation: Maven (2011 ), http://maven.apache.org/ 7. Free Software Foundation, Inc.: GNU Make (2011), http://www.gnu.org/software/make/ 8. Networked Systems Group: SPaSs Tool Home Page (2011), http://vs.cs.uni-kl.de/activities/spass/

SDL Modules – Concepts and Tool Support

17

9. International Telecommunication Union: Recommendation Z.106: Common Interchange Format for SDL (August 2002), http://www.itu.int/rec/T-REC-Z.106/en 10. Fliege, I., Grammes, R., Weber, C.: ConTraST - A Conﬁgurable SDL Transpiler and Runtime Environment. In: Gotzhein, R., Reed, R. (eds.) SAM 2006. LNCS, vol. 4320, pp. 216–228. Springer, Heidelberg (2006); Revised Selected Papers 11. Apache Software Foundation: Subversion (2011), http://subversion.apache.org/

A Developer-Friendly Approach for the Validation of Dynamic Compositions Jacqueline Floch1 and Cyril Carrez1,2 1

SINTEF ICT NO-7465 Trondheim, Norway {jacqueline.floch,cyril.carrez}@sintef.no 2 Norwegian University of Science and Technology Department of Telematics NO-7491 Trondheim, Norway

Abstract. A major challenge of dynamic composition is to ﬁnd ways to model components and analyze their composition in order to guarantee that the composition is free from interaction errors and deadlocks. Existing techniques for validation typically require expert knowledge in formal modelling and reasoning, and do not lend themselves to be used at runtime. However, we ﬁnd that a coarse-grained description of a composition can be suﬃcient to ensure the consistency of compositions and to detect potential deadlocks. Our approach requires software developers to specify component models from which the properties needed for validation at runtime can be derived, and to perform some well-formedness and compliancy checks at design time. The new development tasks are integrated in a UML-based development process using concepts that developers are familiar with. The assessment of the approach indicates that developers with ordinary modelling skills are able to detect problems in composition at an early stage, and thereby design safe systems in an eﬃcient manner. Keywords: validation, service modelling, dynamic composition, safe composition.

1

Introduction

The composition of applications and services out of independent, reusable software units is no longer an activity that is solely performed at design time. Composition is increasingly applied at runtime. For example, context-awareness, ubiquitous computing and autonomic computing all require support for dynamic composition, i.e., composition at runtime. A major challenge of dynamic composition is to ﬁnd ways to model components and analyze their composition in order to guarantee that the composition is safe, i.e., that interaction errors or deadlocks will not occur. Several model checking-based approaches have been developed for the validation of the safety properties of component-based systems [1]. However, these F.A. Kraemer and P. Herrmann (Eds.): SAM 2010, LNCS 6598, pp. 18–35, 2011. c Springer-Verlag Berlin Heidelberg 2011

A Developer-Friendly Approach for the Validation of Dynamic Compositions

19

approaches typically require expert knowledge, and reasoning uses detailed behavioural speciﬁcations and is time-consuming. This makes them inadequate for runtime where discovery and assembly should be performed in a time-eﬀective way. In particular cases, e.g., mobile and ubiquitous computing, execution platforms such as handheld mobile devices also set constraints on the size of the runtime component representations and the complexity of algorithms. In this paper, we propose a validation approach for the detection of safety violations in dynamic compositions. The validation algorithms are applied on a set of external component properties: the interface behavioural description and what we call interface dependencies. No detailed component behavioural description is needed, and the complexity of the validation algorithms is either kept low, or applies to small state spaces. The approach requires the software developers to provide component models from which the properties needed for validation can be derived. It also requires the developers to perform some well-formedness and compliancy checks at design time. Therefore, beyond the constraints set by runtime, a major concern in our work has been to provide techniques that are easy to use and understand by developers. To that aim, our techniques are integrated in a UML-based development process and use concepts that developers are familiar with. Our work has been applied and assessed as part of the service engineering framework developed in the SIMS project [2]. The structure of this paper is as follows: in Section 2 we present the concepts and research challenges addressed in our approach. It also provides an overview of the modelling and validation techniques, and introduces a service example that will be revisited in the subsequent sections. Section 3 deﬁnes safe service composition. Section 4 is about the validation of pairs of interacting interfaces. It summarizes earlier work essential for the understanding of the validation approach. In particular, we explain the concept of well-formedness and emphasize how avoiding poorly designed interfaces contributes to simplifying validation. Section 5 introduces the concept of interface dependencies, which is the novelty of this paper. Interface dependencies capture the temporal relations between the interfaces of a component, and are used to validate a composition. The section also explains how dependencies are extracted from component behaviours speciﬁed by the software developers. Section 6 positions our approach to related work. Finally, Section 7 discusses our results with respect to our two main concerns: developer-friendliness and application at runtime.

2

Concepts, Assumptions and Overall Approach

The proposed validation approach was developed as part of an engineering framework for the modelling and validation of collaborative services [3]. Collaborative services entail collaborations between several autonomous entities that may behave in a proactive manner, meaning that entities may concurrently take initiatives towards each other. This is typical for telecom services, but also for a large class of services such as notiﬁcation services and ambient intelligence. In the rest

20

J. Floch and C. Carrez

of this paper, we simply use the term service, and we deﬁne dynamic composition as the runtime assembly of a set of autonomous entities that collaborate in a service. To facilitate understanding this concept of service, this section introduces a conceptual service model that describes service entities, their properties and relationships between them. We also present the communication scheme adopted in our approach and introduce a service example that illustrates how services are modelled using UML2. Finally we explain the assumptions and research challenges in our work and provide an overall description of our approach.

Composite collaboration

is modelled by

1..* is used in involves

Service

1..*

runs on

is defined in

contains 2

Service role

1..*

1..* 1..*

*

has

Elementary collaboration

is compliant with

can be played by

Computing node

2..*

is used in

2..*

2..*

performs in

references 1..*

plays

Service component

Interface 1..*

has

references

Interface dependency

Fig. 1. Service model

2.1

Conceptual Service Model

The service model adopted in our approach is described in Fig. 1. A service results from the collaboration of several distributed service roles. Service roles collaborate through interfaces. An interface speciﬁes the visible behaviour of a service role at a connection endpoint. Interface dependencies capture the temporal dependencies between the interfaces of a service role. They will be further explained in Section 5. The structure of a service is modelled by a composite collaboration that describes which service roles co-operate in the service and the relationships between them. Composite collaborations are composed of elementary collaborations that describe a co-operation between a pair of interfaces. Elementary collaborations also deﬁne which interface takes the initiative to start a co-operation: interfaces are classiﬁed as initiating, responding, or both. In [4], we have explained how interfaces and collaborations are enriched with goals and goal sequences in order to provide a high-level semantic description of the intention of the service. These concepts are not included in this paper as they are not relevant for the validation of safety properties. A service component is an implementation entity that realizes a partial service behaviour described by a service role. A service component also realizes a

A Developer-Friendly Approach for the Validation of Dynamic Compositions

21

platform dependent behaviour, e.g., support for binding service role interfaces. The validation approach proposed in this paper focuses on the service behaviour, i.e., it aims at ensuring the safe composition of service roles. 2.2

Communication Scheme

We have adopted asynchronous communication, with message passing semantics. This paradigm supports communication ﬂows in both directions and concurrently and is well suited to realize collaborative services in which service roles execute autonomous behaviours and may take initiative independently. Our validation approach assumes that communication channels maintain the order of messages and do not lose messages. Each service role is associated a set of input ports (one for each interface) with FIFO queues that may retain any number of input messages. 2.3

Service Example

A service example, a travel reservation service, is shown in Fig. 2 to illustrate the concepts introduced in the service model. This example will be modiﬁed and extended later in this article when discussing violation of safety properties. As proposed by Sanders et al. [5], our service engineering framework exploits UML2 collaborations to model services. The travel reservation service in Fig. 2 is modelled by a composite collaboration that involves three service roles: Traveller, Hotel and Plane. Elementary collaborations are two-party collaborations between exactly two interfaces. For example, the elementary collaboration ReserveHotel deﬁnes two interfaces: iResHotel and iHotel. Composite collaborations are in fact composed of UML2 collaboration uses, where each collaboration use is typed by an elementary collaboration. A service role can be bound to a number of interfaces. One beneﬁt of modelling collaboration between interfaces in separate diagrams is that the speciﬁcation of elementary collaborations and interfaces can be reused. In addition, as explained later in this paper, validation can be applied incrementally. The detailed behaviour of interfaces is speciﬁed using UML state machines, with message passing semantics. Triggers and eﬀects specify respectively a Initiating Interface

iResHotel

TravelReservation rh:ReserveHotel

t: Traveller iResPlane

Service role

rp:ReservePlane

iHotel

h: Hotel p:

iPlane Plane

Collaboration use

Fig. 2. Travel service modelled using collaborations and collaboration uses

22

J. Floch and C. Carrez

signal reception

signal sending

Reference&Dates

iHotel_statemachine VerifyOption

exit condition

/OK

/AvailableRooms /AvailableRooms

Idle

Dates

CheckRooms

ReserveRoom

/Reference

RoomReserved

WaitConfirm Dates

state

Reserve

TakeOption

MakeOpt Reservation

/Reference

Abort

OptionOnRoom

NoRoom

Fig. 3. Interface behaviour modelled using a state machine

reception or a sending of a signal, thus specifying how to interact with the interface. For example, Fig. 3 shows the state machine of the interface iHotel of the elementary collaboration ReserveHotel presented in Fig. 2. The detailed behaviour of service roles is also speciﬁed using state machines, with message passing semantics. Ports on which messages are sent or received must be speciﬁed. The use of timers and deferred messages (i.e., whose consumption is postponed to a later state) is allowed. Examples of this can be found in [6]. 2.4

Assumptions, Research Challenges and Overall Approach

We distinguish between the speciﬁcation of a service (deﬁning the service structure, interfaces and goal sequences), the design of service roles and the realization of a service in terms of deployable components. Service execution is realized through the instantiation of components and their dynamic composition. We assume that diﬀerent stakeholders can contribute to the diﬀerent activities in service development. This means that service roles in a service might be designed by diﬀerent parties, and components developed by independent parties. In order to provide such ﬂexibility, and at the same time to guarantee that services execute in a safe manner, we propose to apply a set of validation techniques for checking well-formedness of entities (to remove symptom of errors), compliancy between detailed and abstract speciﬁcations, and compatibility between interacting entities. Figure 4 illustrates these techniques and indicates whether they are applied at runtime or not. Note that when a service realisation is completely determined at design time, all techniques can be applied at design time. When components developed by diﬀerent parties are composed dynamically, validation has to be applied at runtime. The proposed runtime validation techniques are applied during component discovery, i.e., when looking for components that can interact together. When symptoms of errors in a potential composition are detected at runtime, the composition is discarded. Alternative discovered service roles, if any, might be selected. In that way, we ensure that only compatible components are bound together. As illustrated in Fig. 4, two checks are

A Developer-Friendly Approach for the Validation of Dynamic Compositions

Models

Validation

Overall service specification

Composite collaboration

NB. All runtime techniques can also be applied at design time.

Elementary collaboration √

Interface specification

Interface well- formedness √

State machine diagram

Service role specification

Compatibility between interfaces

design time

runtime

√

State machine diagram Compliancy between service role and interfaces Component

Component

role

Composition

23

role Component role

i1

i3

2

i4

Consistency of interface dependencies

design time

runtime

Fig. 4. Overall modelling and validation techniques

applied: checking the compatibility between pairs of interfaces and checking the consistency of interface dependencies in a composition. They will be presented in Section 5. Validation at runtime can be simpliﬁed if some of the checks are performed at design time. We require the interfaces to be well-formed and the service roles to be compliant with these interfaces. This will be explained in Section 4. We follow a model-driven engineering approach meaning that: a) models have to be provided by developers, and thus analysis can be naturally applied at design time, b) the runtime system is derived from the design models, and thus compliant to the models. The runtime system includes the models needed for validation at runtime. Note that when a system evolves, new models are provided or existing ones revised; further, as the approach supports modularity, evolution does not require re-modelling of the complete system. In order to simplify, the derivation of the runtime system and associated models is not represented in Fig. 4.

3

Safe Service Composition

Based on the deﬁnition of safety properties of Alpern et al. [7], i.e., “bad things that should never happen,” we deﬁne a service composition to be safe if no logical errors occur during the collaboration between service roles. We restrict

24

J. Floch and C. Carrez

our validation approach to the avoidance and detection of logical interaction errors. Conﬂicting non-functional requirements or physical errors (e.g., signal loss, network and node failure) are not considered. We deﬁne three kinds of violation of safety properties: – An unspecified signal reception occurs when an interface receives a signal that is not speciﬁed as input in the current interface state; – An improper termination occurs between two interfaces when: 1. the interfaces do not terminate in a coordinated manner, e.g., no signal should be sent to an interface that has terminated; or 2. they terminate through diﬀerent exit conditions; – A deadlock between a set of entities (either interfaces or service roles) occurs when the entities cannot proceed because they wait endlessly for signals from each other. Unspeciﬁed signal reception and deadlock are illustrated in Fig. 5. In (a), the Traveller sends a message Hello, which the Hotel cannot process. As this kind of unspeciﬁed signal reception is a symptom of error, we require that all signals sent by an interface are explicitly consumed by the complementary interface. In (b), a deadlock between three service roles occurs: they all endlessly wait for each other (possibly for a conﬁrmation, i.e., the Traveller waits for the Hotel to conﬁrm before answering to the Bank ). Such deadlocks can be detected at design time using model-checking when a detailed internal behaviour is available. At run-time where the internal behaviour speciﬁcation is not available, detecting potential deadlocks in a composition is complex, or not supported.

?? I dont know how to handle that message!

Traveller

Hello

Hotel

Traveller

waiting Hotel circular wait => deadlock

waiting

waiting Bank

a) message not understood

b) deadlock

Fig. 5. Checking for errors in compositions

4

Interface Compatibility and Well-Formedness

Ensuring the consistency of interactions between two service roles is the ﬁrst validation step when composing service roles. Validation of pairs of interfaces has been addressed in the earlier work of one of the authors [8,9], and similar theory can be found in [10]. The main points of which are repeated here, as they are fundamental for our new contribution.

A Developer-Friendly Approach for the Validation of Dynamic Compositions

25

We say that two interfaces are compatible when their interactions do not lead to any unspeciﬁed signal reception, deadlock between them, or improper termination. To check the compatibility of two interfaces, we use reachabilitybased validation algorithms for compatibility checking of state machines [11]. As analysis is applied on small state machines (∼10 states) and with the assumption that signals are not deferred on interfaces, the total number of states is kept low, avoiding state space explosion. In order to prevent poorly designed service roles, we require service roles and interfaces to be designed such that anomalous behaviours are removed. An interface is well-formed if and only if it does not exhibit ambiguous or conﬂicting behaviours: – Ambiguous behaviours occur when at some stage of the behaviour an external observer cannot detect what next behaviour might happen. Ambiguous behaviours typically result from an internal choice in a service role or behaviours triggered by interactions on other interfaces of the service role. Unspeciﬁed signal reception or improper termination might occur, as the interface behaviour is not predictable; – Conﬂicting behaviours occur in the case where two interacting state machines simultaneously take an initiative to send, and the initiated behaviours diverge. For instance in Fig. 6, the state FrequentTraveller can both send and receive an event. To be well-behaved, the successor state MakeOptReservation must be input consistent with the state FrequentTraveller, i.e., it must be able to receive the same events. Otherwise a deadlock might occur, the machine being waiting for Confirm.

iPlane_statemachine (with conflict) Idle

Reference& Dates

Frequent Traveller

/Available Flights

Confirm

MakeOpt Reservation Cancel

mixed initiative state

Cancel

CancelRoom

MakeOpt Reservation

/Reference

conflict detection

/CancelACK

conflict resolution

Fig. 6. Conﬂicting behaviours

The enforcement of well-formedness rules out special cases of behaviour, allowing a simpliﬁed algorithm for compatibility checking [8]. To support the developer, our approach includes the set of design rules and algorithms for checking well-formedness also proposed in [8]. As demonstrated by the development of case studies in SIMS [12], the design rules do not restrict the possibilities to make useful designs. While checking the well-formedness of interfaces is performed at design time, checking the compatibility of two interfaces can be applied at runtime. Interface compatibility only guarantees consistency of interactions between pairs of service

26

J. Floch and C. Carrez

roles if the interfaces truly represent the behaviours of the service roles. To ensure compliancy between service roles and the speciﬁed interfaces, we apply the projection technique of [9] to service roles, and check that extracted behaviours are equivalent to the speciﬁed interfaces. Checking the compliancy of service roles and the speciﬁed interfaces is performed at design time.

5

Interface Dependencies and Safe Composition

Interface compatibility as described in the previous section does not by itself guarantee that a service composition is safe. As service roles might collaborate through multiple interfaces with other service roles, we need to check that service roles coordinate their collaborations on interfaces consistently, and that no deadlock (as illustrated in Fig. 5b) can happen between these service roles. To that end, we introduce the concept of interface dependencies that capture the temporal relations between interfaces. 5.1

Interface Dependency Types

We distinguish between three types of dependency between interfaces provided by a service role: – Two interfaces are in sequence, noted I1 → I2 , when their behaviours are sequenced: I2 is executed just after I1 . A sequence can be annotated with an exit condition, noted I1 → I1 Exit1 I2 , meaning I2 starts only if I1 terminated with condition I1 Exit1 ; – Two interfaces are interdependent, noted I1 ↔ I2 , when one interface is, at one point of its behaviour, waiting for an action to happen on the other interface; – Two interfaces are in parallel, noted I1 I2 , when the interfaces depend neither on an action nor on the termination of the other interface. While the ﬁrst type enforces behaviour ordering, the two others support simultaneous behaviours on interfaces. These three types are illustrated in Fig. 7 for the service role Traveller that was introduced in Fig. 2. As will be explained in Section 5.3, the two kinds of check needed to validate a composition require diﬀerentiation between sequence and interdependency. Beyond interface dependencies internal to a service role, we introduce a dependency to represent the external interaction between two interfaces: an external dependency, noted I1 <−−> I2 , occurs when I1 and I2 take part in the same elementary collaboration. 5.2

Dependency Graph

In order to validate the safety of a service composition, we check the consistency of interface dependencies among the service roles involved in the composition. To do so, we build a model that represents the relations between the diﬀerent

A Developer-Friendly Approach for the Validation of Dynamic Compositions

iResHotel

iResHotel

iResHotel

iResPlane

iResPlane

iResPlane

iResHotel Travel Agency iResPlane

1. Check Room Avail. 2. Reserve Room 3. Check Seat Avail. 4. Reserve Seat

iResHotel Travel Agency iResPlane

TravelAgency first interacts with the Hotel, and then with the Plane.

a) Sequence

1. Check Room Avail. 3a. Reserve Room

iResHotel Travel Agency

2. Check Seat Avail. 3b. Reserve Seat

iResPlane

27

a. Check Room Avail. b. Reserve Room A. Check Seat Avail. B. Reserve Seat

TravelAgency pauses the interaction with Hotel to check seats with Plane.

TravelAgency interacts with the Hotel and the Plane in parallel, with no pause during the interaction.

b) Interdependency

c) Parallel

Fig. 7. Interface dependencies

interfaces. This model, the composition dependency graph, is a directed graph which represents all the dependencies between the semantic interfaces present in the composition. Figure 8 shows an example of a dependency graph for a service composition involving two service roles, Traveller and TravelAgency. These two service roles sequence their interfaces. Initiating interfaces in the dependency graph are annotated with an arrow. Note that this is a property of the interface, not a property of the external dependency (i.e., this arrow does not represent any direction in the graph).

iResHotel

ReserveHotel

Traveller ReservePlane iResPlane dependencies

iHotel Travel Agency iPlane

Dependency graph

External dependency

iResHotel

iHotel

iResPlane

iPlane

dependencies

iResHotel

iHotel

iResPlane

iPlane

a) Semantic interface dependencies

b) Dependency graph

Fig. 8. Dependency graph

5.3

Validating Service Compositions

We assume that interacting interfaces are compatible; this can be ensured using the techniques described in Section 4. Thus, there are two cases that introduce safety violations. The ﬁrst case occurs when interfaces do not start interacting in a coordinated way, e.g., one interface sends an event to an interface that is not yet active, leading to unspeciﬁed signal reception. This happens when the service roles do not sequence their interfaces consistently. The second case

28

J. Floch and C. Carrez

occurs when service roles wait for each other to send a message, hence producing a deadlock. This situation happens when an interface interaction, inside a service role, is unable to proceed because the service role is waiting for some event to happen on another interface. In the following we present techniques for detecting these two cases. When detected at runtime, symptoms of errors can hardly be corrected. Using our approach, the composition is discarded, and alternative service roles, if any were discovered, are considered. Checking Interface Sequences between Two Service Roles. When two service roles collaborate in a service, they should coordinate their interfaces such that they start consistently. Interface dependencies are used to check that semantic interfaces are sequenced in a safe manner: – Two collaborating service roles should sequence their connected interfaces in the same order, and with the same exit conditions (if there is any); – Assume a sequence A → B where B is responding: Then the connected interfaces A and B should be in the same service role and follow the same sequence; – All interfaces following a choice (i.e., an internal decision) must be initiating, and the connected interfaces must start in parallel. Indeed checking the interface sequences is similar to checking the consistency of state machines. Each interface is as a state in a state machine and thus the check applies on composite state machines. The same consistency rules apply as on “elementary” state machines [6]. The ﬁrst condition above is already illustrated in Fig. 8: Traveller and TravelAgency sequence the interfaces in the same order. Note that in this case, the termination of each interface in the ﬁrst elementary collaboration can be observed from both sides. There is no restriction on the initiating or responding property of the second interface. The second condition is exempliﬁed in Fig. 9. In (a), the service role Traveller is sequencing iResHotel and iResPlane, with iResPlane being responding; the service role is connected to two service roles Hotel and Plane. We observe that Plane is not sequencing the interfaces in the same manner as Traveller : iPlane might send the ﬁrst message while iResPlane has not started yet. In (b), Traveller diﬀers with iResPlane taking initiative, meaning that Traveller informs Plane that the interaction can start. The third condition, i.e., with the internal choice, is illustrated in Fig. 9 (c): the Traveller decides which transportation mode to use, with the corresponding interfaces iResTrain and iResPlane being initiating. The TravelAgency needs to start the complementary interfaces in parallel, to be able to honour the choice of the Traveller. Ensuring Deadlock-Freedom. Ensuring deadlock freedom is not a trivial task. We exploit the formal results developed earlier by one of the authors [13]: a

A Developer-Friendly Approach for the Validation of Dynamic Compositions

29

Internal choice: Traveller decides on transportation mode. Traveller

Hotel

Traveller

Hotel

Traveller

TravelAgency

iResHotel

iHotel

iResHotel

iHotel

iResHotel

iHotel

iResPlane

iPlane

iResPlane

iPlane

iResTrain

iResPlane

iPlane

||

iTrain

Plane

Plane iResPlane is responding, an error may occur.

iResPlane is initiating

(a) X

(b) √

TravelAgency must be able to receive any message from iTrain or iPlane

(c) √

Fig. 9. Checking sequences of interfaces

conﬁguration of components that expose non-reentrant server ports is deadlockfree if those server ports are not involved in a cycle in a (port) dependency graph. Based on this constraint, we require that: – The dependency graph of a conﬁguration of service roles should not contain cycles that involve external dependencies. As the dependency graph indicates which interface potentially waits for another, a cycle in the graph is a characterization that a deadlock may occur. However a cycle in the dependency graph of a composition does not necessarily mean that a composition has a deadlock. Our constraint might, of course, rule out service compositions that actually do not have any deadlocks, but validation of such compositions requires more detailed speciﬁcations than the description of interface dependencies that we propose to exploit at runtime. At a ﬁrst glance, as it is quite common that interfaces of a service role wait for each other, one may think that the occurrence of a cycle in a dependency graph is frequent. However one must recall that such interdependent interfaces are often connected to interfaces of diﬀerent and independent (i.e., non-interacting) service roles, meaning that the interdependency in such common cases does not lead to a cycle in the dependency graph. Note that the cycle in the dependency graph does not take into account if an interface is initiating or responding. Indeed, the deadlock might occur in the middle of the behaviour of an interface, so which side initiated the interaction has little consequence. One may argue that the interdependency relation is itself a cycle. However, as we assume that the analysis of service roles and interfaces has been applied (see Section 4), interaction between the two interdependent interfaces is deadlock free. Thus, the interdependency relation is not a cycle. Figure 10 illustrates cycles in the composition dependency graph. In (a), the Traveler and the TravelAgency have interdependent interfaces, thus resulting in a cycle when the service roles are connected; indeed the Traveler might wait for a conﬁrmation of a room before conﬁrming the seat, while the TravelAgency might want the opposite conﬁrmation (ﬁrst the seat, then the room). In (b),

30

J. Floch and C. Carrez

although the Traveler is sequencing the semantic interfaces, a cycle remains. Indeed, iHotel may wait for iPlane to receive an answer from iResPlane, which has not started yet. In both cases, the composition should be ruled out and search for other service roles should take place. For instance, in case (b) a TravelAgency that sequences the interfaces in the same order can be used, or in cases (a) and (b) two separate service roles, one realizing iHotel and the other iPlane can be used. Traveller

TravelAgency

Traveller

TravelAgency

iResHotel

iHotel

iResHotel

iHotel

iResPlane

iPlane

iResPlane

iPlane

(a)

(b)

Fig. 10. Cycle in a composition dependency graph

The size of the dependency graph is normally kept small, as its nodes represent only the interfaces of the system. Moreover, the complexity of ﬁnding a cycle in a directed graph is in linear time of O(V+E), with V the number of nodes (i.e., interfaces) and E the number of edges (i.e., dependencies) [14]. For example, the meeting place service developed in SIMS [15] has 4 service roles and 20 semantic interfaces. This is representative of a speciﬁcation of a typical service. The algorithm can however also be applied to much larger systems without introducing state explosion. 5.4

Extracting Interface Dependencies from Service Role Specifications

Interface dependencies need not be provided by the developer, but can be extracted automatically from the service role behaviour. Service roles are ﬁrst analysed to ﬁnd when they start and stop interacting through interfaces. A service role starts to interact through an interface as soon as it sends, receives or defers a signal of that interface. The following algorithm is used to extract interdependencies: /* Assume interfaces sequences have been identified */ For all interfaces I of the service role S: Between the start and the stop of I, for each state s: - if some signals from I are deferred; or - if no reception for I takes place at that state, Then I has an interdependency with all the interfaces that involve a reception at state s. For all interfaces I, J of S with I!= J: - if no dependency exists between I and J, then I and J are in parallel.

A Developer-Friendly Approach for the Validation of Dynamic Compositions iTravel

iResPlane

iResTrain

1

1

1

BookTravel / NOK

2

/ BookPlane

/OK

exit1

p_NOK

2

exitP1

exit2

31

/ BookTrain

p_OK

2

t_NOK

t_OK

exitT1

exitP2

exitT2

Fig. 11. Simple semantic interfaces used as examples to extract interface dependencies

TravelAgency1 Start of iTravel & iResPlane

Stop of iTravel & iResPlane

1 BookTravel / BookPlane

iTravel is not active, and iResPlane receives some signals: interdependency

2

p_NOK / NOK

p_OK / OK

dependencies iResPlane

iTravel

TravelAgency2 1

BookTravel / OK / BookPlane p_NOK

2

/ BookTrain t_NOK

p_OK

exitP1 exitP2 The service role stops with dependencies exit2 and chooses to start exit2 iResPlane or iResTrain iTravel (internal decision)

a)

BookTravel / NOK exit1

3

exitT1

t_OK exitT2

iResPlane iResTrain

b)

Fig. 12. Extracting interface interdependency

To illustrate this algorithm, we deﬁne three interfaces that we exploit below in diﬀerent service role speciﬁcations. The interfaces are shown on Fig. 11. Figure 12 (a) illustrates a service role with interdependent interfaces. In state 2, between the start and the stop of iTravel, no action involving iTravel is performed, and iResPlane receives some signals: we deduce that iTravel and iResPlane are interdependent. Figure 12 (b) illustrates sequences of interfaces. The service role starts with interface iTravel. After sending OK (i.e., interaction on iTravel is then ﬁnished), the service role reaches an internal choice to start iResPlane or iResTrain. The equivalent exit condition is extracted (exit2 ). This gives the dependencies shown at the bottom.

6

Related Work

Similarly to us, the authors of [16] propose a service engineering framework that exploits UML2 collaborations for specifying the service structural properties. Instead of state machines, they use UML2 activities for describing the collaborative composition behaviours. As semantic foundation to reason about the correctness of speciﬁcations, they formalize collaborations using cTLA (compositional Temporal Logic of Actions) [17]. The approach allows for incremental veriﬁcation of systems. The authors solely address veriﬁcation at design time.

32

J. Floch and C. Carrez

Proving the absence of deadlock when assembling components is a diﬃcult task. Deadlock avoidance is undecidable, as this problem is similar to the halting problem of Turing machines. Most of the approaches make use of dependency cycles and locks on resources, for instance in [18], but those approaches are often based on a deep analysis of the software, and are hard to use at runtime. In our work, we have aimed at detecting deadlock using a coarse-grained description of the composition of the service. As a consequence, our approach can be applied to any composition, even though it is at the price of ruling out conﬁgurations that possibly will not deadlock. Concerning the runtime veriﬁcation of sound compositions, the approaches of recent works are often based on runtime monitoring of properties [19,20]. The components (or Web Services, depending on the approach) are monitored at runtime according to a predeﬁned speciﬁcation. Our approach is preventive, i.e., we aim at avoiding errors and thus validate components before they are assembled, while monitoring approaches are corrective, i.e., verify that running and bound components behave according to the speciﬁcation and potentially correct detected errors. Several other approaches have also been developed for web services such as those described in [21,22]. Web services focus on consumer-provider services. Our component model diﬀers as we allow components to coordinate their behaviour in a collaborative manner. The work closest to our idea of interface dependencies is, to our knowledge, the one of [23]. The authors have the interesting approach to specify compositions using Open Petri Nets (i.e., Petri Nets extended with input and output places). They are able to detect deadlock conﬁgurations. However, their work is focused on service trees, where components may invoke other components and wait for their answer, hence producing a service tree. Our component model is more ﬂexible, as we allow components to coordinate their behaviour in a collaborative manner. This permits more complex composition patterns, and thus a larger scope of service composition.

7

Discussion and Conclusion

One ﬁrst concern has been to provide techniques that do not require knowledge of formal methods, and are easy to use and understand by ordinary developers. The assessment of our framework was undertaken through the development of a trial service by a telecom software vendor in the SIMS project [12]. None in the assessment team had prior knowledge of the theory developed in SIMS. The team was given the development guidelines developed within the project [6], in addition to a one-day introduction course and on-site support from one of the technology providers the ﬁrst two days. The members consisted of an experienced software engineer (leader), an experienced developer with strength in programming (not modelling), and two juniors in their last year of MSc study, both eager programmers. With respect to our ﬁrst concern on friendliness, some of the main conclusions from this experiment are:

A Developer-Friendly Approach for the Validation of Dynamic Compositions

33

– The proposed use of UML2 is simple; designers with some experience of using UML and state machines found it easy to use for modelling the service. – The design rules associated to the validation approach were not found restrictive and did not make the design of the service more complex. – The support provided to identify errors concerning mixed initiatives was useful. Despite the simple service design, logical errors were nonetheless made in the design. The approach makes it easy to identify such easy-to-commit design errors and to eliminate them at early design stages. Although the assessment was limited to a single organisation over a short period of time (with a total eﬀort of 835 hours), it indicates positive results regarding the usability and usefulness of the methods for modelling and validation. The second concern in our work to has been to provide validation techniques that can be applied at runtime. As the tools for extracting interface dependencies were not available at the time of assessment, the validation techniques were assessed through prototyping. However we argue that the analysis performed at design time, i.e., ensuring the well-formedness of interfaces and the compliancy between service roles and their interfaces, contributes to reduce and simplify the analysis at runtime. The risk of state explosion is avoided by 1) decomposing the system into small entities that can be checked using simple algorithms, 2) applying consistency checking on pairs of interfaces represented by state machines of small size and 3) checking the consistency of compositions using a linear algorithm for the detection of cycles in a graph. As the complexity of the analysis is kept small, the approach is well-suited for validation during the discovery of components: validation can be applied to alternative potential components in a composition, allowing the discovery mechanisms to discard components for which the composition is not safe. A drawback of the approach is that correct compositions might be ruled out. In future work, we plan to reﬁne the interdependency relation such that it is possible to express which interface is waiting for the other. If only one interface has to wait for the other, there is no need to indicate a two-way dependency between interfaces. Thus a cycle currently inferred by a two-way relation might disappear if that relation is replaced by a one-way relation. Acknowledgement. Our research has been performed in the project SIMS supported by the EU IST 6th framework programme. The Norwegian project UbiCompForAll and the EU IST project SHAPE have supported us in writing this paper. We would like to thank Dr. Richard Sanders for encouraging and thorough comments.

References 1. Baier, C., Katoen, J.-P.: Principles of Model Checking. MIT Press, Cambridge (2008) 2. Floch, J., Carrez, C., Cie´slak, P., R´ oj, M., Sanders, R.T., Shiaa, M.M.: A Comprehensive Engineering Framework for Guaranteeing Component Compatibility. Journal of Systems and Software 83(10), 1759–1779 (2010)

34

J. Floch and C. Carrez

3. Floch, J., Sanders, R.T., Bræk, R.: Compositional Service Engineering using Semantic Interfaces. In: di Nitto, E., Sassen, E., Traverso, P., Zwegers, A. (eds.) At Your Service: Service-Oriented Computing from an EU Perspective, pp. 101–128. MIT Press, Cambridge (2009) 4. Carrez, C., Floch, J., Sanders, R.T.: Describing Component Collaboration Using Goal Sequences. In: Meier, R., Terzis, S. (eds.) DAIS 2008. LNCS, vol. 5053, pp. 16–29. Springer, Heidelberg (2008) 5. Sanders, R.T., Castej´ on, H.N., Kraemer, F.A., Bræk, R.: Using UML 2.0 Collaborations for Compositional Service Speciﬁcation. In: Briand, L.C., Williams, C. (eds.) MoDELS 2005. LNCS, vol. 3713, pp. 460–475. Springer, Heidelberg (2005) 6. Carrez, C. (ed.): SIMS Deliverable D2.3, SIMS Principles and Techniques for Service Engineering (2008), www.ist-sims.org 7. Alpern, B., Schneider, F.: Recognizing Safety and Liveness. Journal of Distributed Computing 2, 117–126 (1987) 8. Floch, J.: Towards Plug-and-Play Services: Design and Validation using Roles. Dr. Ing thesis. Norwegian University of Science and Technology (2003) 9. Floch, J., Bræk, R.: Using Projections for the Detection of Anomalous Behaviours. In: Reed, R., Reed, J. (eds.) SDL 2003. LNCS, vol. 2708, pp. 251–268. Springer, Heidelberg (2003) 10. Carrez, C., Fantechi, A., Najm, E.: Assembling components with Behavioural Contracts. Annales des Telecommunications 60(7-8), 989–1022 (2005) 11. Holzmann, G.J.: Design and Validation of Computer Protocols. Prentice-Hall, Englewood Cliﬀs (1991) 12. Shiaa, M.M. (ed.): SIMS Deliverable D6.5, Trial Services, ﬁnal version (2008), www.ist-sims.org 13. Carrez, C.: Contrats Comportementaux pour Composants. Doctoral Thesis, ENST (2003) 14. Tarjan, T.: Depth-First Search and Linear Graph Algorithms. SIAM Journal on Computing 1(2), 146–160 (1972) 15. Sanders, R.T., Meland, P.H. (eds.): SIMS Deliverable D1.2, Scenarios and Requirements for Methods, Tools and Middleware - ﬁnal version (2007), www.ist-sims.org 16. Kraemer, F.A., Sl˚ atten, V., Herrmann, P.: Tool Support for Rapid Composition, Analysis and Implementation of Reactive Services. Journal of Systems and Software 82(12), 2068–2080 (2009) 17. Herrmann, P., Krumm, H.: A Framework for Modelling Transfer Protocols. Computer Networks 34(2), 317–337 (2002) 18. Nir-Buchbinder, Y., Tzoref, R., Ur, S.: Deadlocks: From Exhibiting to Healing. In: Leucker, M. (ed.) RV 2008. LNCS, vol. 5289, pp. 104–118. Springer, Heidelberg (2008) 19. Baresi, L., Bianculli, D., Guinea, S., Spoletini, P.: Keep It Small, Keep It Real: Efﬁcient Run-Time Veriﬁcation of Web Service Compositions. In: Lee, D., Lopes, A., Poetzsch-Heﬀter, A. (eds.) FMOODS 2009. LNCS, vol. 5522, pp. 26–40. Springer, Heidelberg (2009) 20. Dong, W., Leucker, M., Schallhart, C.: Impartial Anticipation in RuntimeVeriﬁcation. In: Cha, S(S.), Choi, J.-Y., Kim, M., Lee, I., Viswanathan, M. (eds.) ATVA 2008. LNCS, vol. 5311, pp. 386–396. Springer, Heidelberg (2008) 21. Narayanan, S., McIlraith, S.A.: Simulation, Veriﬁcation and Automated Composition of Web Services. In: Proceedings of the 11th International Conference on World Wide Web, pp. 77–88. ACM, New York (2002)

A Developer-Friendly Approach for the Validation of Dynamic Compositions

35

22. Ding, J., Zhu, H., Zhu, H., Li, Q.: Formal Modeling and Veriﬁcations of Deadlock Prevention Solutions in Web Service Oriented System. In: Proceedings of 17th IEEE International Conference and Workshops on the Engineering of ComputerBased Systems, pp. 335–343. IEEE, Los Alamitos (2010) 23. van der Aalst, W.M.P., van Hee, K.M., Massuthe, P., Sidorova, N., van der Werf, J.M.: Compositional Service Trees. In: Franceschinis, G., Wolf, K. (eds.) PETRI NETS 2009. LNCS, vol. 5606, pp. 283–302. Springer, Heidelberg (2009)

From Flow-Global Choreography to Component Types Surya Bahadur Kathayat and Rolv Bræk Norwegian University of Science and Technology, Department of Telematics, N-7491 Trondheim, Norway {surya,rolv.braek}@item.ntnu.no

Abstract. The need for global behavior deﬁnitions is well established both in the domain of embedded reactive systems and service-oriented (business) systems. The problem has been to deﬁne the global behavior with suﬃcient, rigor and completeness to fully cover the intended behavior and not just some scenarios, and to enable automatic synthesis of component behaviors in practical systems and service development. In this paper we build on previous work where UML collaborations are used to structure systems and services into reusable building blocks, and UML activities to model global behavior, called choreography in the following. We identify two forms of choreography: one where all ﬂows are localized to the roles participating in collaborations and another where the ﬂows are not localized and thus more abstract. We propose a novel approach to map the ﬂow-global choreography to a ﬂow-localized choreography and further to distributed component behaviors (orchestrations) with well-deﬁned interfaces from which implementation code can be generated using existing techniques. The overall approach combines the merits of global choreographies and collaborative building blocks with the ﬂexibility of component-oriented designs. The approach is illustrated using a city guiding system as case study. Keywords: Service choreography, component design, model-driven development.

1

Introduction

In reactive as well as in business systems there is a need to deﬁne global collaborative behavior as well as local component behavior. We use the term choreography to denote global collaborative behavior involving two or more participants, in contrast to orchestration that denotes the local behavior of each participant. Choreography is needed to deﬁne and analyze the overall service behavior, whereas the orchestration is needed to completely deﬁne component behaviors for implementation. These terms come from the domain of business services and SOA and are in accordance with common use in that domain, see, for instance [1]. Ideally, the choreography should be suﬃciently precise and complete that component behaviors can be automatically synthesized. This would enable the service engineer to work mainly on the level of choreography, focusing on the F.A. Kraemer and P. Herrmann (Eds.): SAM 2010, LNCS 6598, pp. 36–55, 2011. c Springer-Verlag Berlin Heidelberg 2011

From Flow-Global Choreography to Component Types

Service Library

City Guide Service act

Re-plan p ::lead :l le er

37

City guide service

st:Start tour

Start tour :grp

:usr srr

:user

:serve r

poi :poi

:grp

grp

nm:Next move

poi

grp grp

Compose

q:Quiz

pu:Position update

Analyze

Localize

Global Structure & Flow-Global Choreography

cp:Connect poi grp

grp

usr usr

:svr :sv vr

:gr :grp :g grp p

usr

Analyze Localize ARCTIS SUPPORT

act C City ity guide ide service servi rvice oup p qui quiz q z act Group user use u ser qqs:Question qs: sQ Que Qu u ue est sti s ttiion ion on g grrp grp rp leader llea le eader e der

Re-plan Re plan Start S a tour ou

::lead :l le er

{{us us u ser} errr}} e {user} sugg sugg

:serve r

:grp

:usr srr

S

:svr :sv vr

:gr :grp :g grp p

{{llle eader} d } {leader} submit s t

s.i.in s.i niit nit it s.init s.w wins ns s.wins

p iniiitt p.i p.init

MI MIS M ISS IS MISS

P

p wins s p.wins

Flow-Localized Choreography

p wins p.wi p.w ins s p.wins

Compose ssg g:Sug Sugg sg:Sugg

grrp grp g rp

user ss:Show sss:Show le eade der d e er leader su sug su ug gg sugg

grrp p grp

use user

leader lea lle ead ea de der e err sb:Submit sb: sb s b b::Submiit grp

Analyze Analyze, Resolve

Synthesize Synthesize

Component Library «system» City Guide System

«ComponentType» Group u

3.s3

g

«ComponentType» User

u u

g

4.s4

c

g

5.s5

p

c[1]: CGS

Orchestration 1:S1 2:s2

g c

Compose

u[*]: User

g[+]: g[ g [+]: G p Group

p[+]: POI

Fig. 1. Overview of the proposed approach

intended global behavior, and not the detailed component behavior. For this to be possible, one needs suitable building blocks and composition mechanisms for deﬁning the intended global behavior completely and precisely, and one needs a systematic way to go from global behavior to distributed local behaviors such that all the coordination problems of distributed realizations are properly handled. UML collaborations provide a structural framework to do this. They deﬁne a structure of participating roles where collaborations taking place among the roles may be represented as collaboration uses referring to separately deﬁned collaborations with associated behavior. We distinguish between elementary collaborations that are not further decomposed into collaboration uses, and composite collaborations. In this paper we use UML activity diagrams for the choreography of both elementary collaborations and composite collaborations as well as for orchestration. Motivation for this choice and comparison with alternatives such as sequence diagrams and interaction overview diagrams is given in Sect. 6. Notation and semantics are in accordance with the UML deﬁnition except for a small notational addition that will be explained. The overall approach we address in this paper is illustrated in Fig. 1.

38

S.B. Kathayat and R. Bræk

– Flow-global choreography is used to deﬁne the intended global behavior of composite collaborations on a high level of abstraction avoiding details of localization and resolution of coordination problems that may occur at the level of orchestration. The behavior is deﬁned by an activity diagram connecting actions by ﬂows that are not localized to any particular role. Actions may either represent the behavior of a collaboration or a local activity. This is the right level for discussing the intended behavior with end-users and other stakeholders. It is also a useful ﬁrst step in the formalization of requirements. – Flow-localized choreography is used to deﬁne global behavior in suﬃcient detail to allow extensive analysis and to automatically synthesize the behavior of component types providing orchestration. The behavior is deﬁned by an activity diagram connecting actions, that either represent the behavior of a collaboration or a local activity, by ﬂows that are localized to the roles. – Component types deﬁne the local activity ﬂow, the orchestration, of each component. They are derived using a projection of the ﬂow-localized choreography to include only local actions performed by the component. Information about the collaborations it participates in and the ordering imposed by external activity ﬂows are retained in order to support automatic realization as well as compatibility checks during subsequent composition of components into working systems. Tool support for parts of this approach is provided by Arctis [2], as indicated by the grey area in Fig. 1. It enables compositional development of reactive systems where building blocks representing collaborative behavior are deﬁned separately using the “swim-lane” like notation for UML activity diagrams, put into libraries, and then composed in diﬀerent ways. The Arctis tool provides extensive support on the ﬂow-localized choreography level. It supports model checking and can synthesize complete system behavior in the form of communicating state machines that are automatically implemented using code generation. In this paper, we elaborate on the parts not supported by Arctis, i.e., the ﬂow-global choreography, the mapping to a ﬂow-localized choreography and the derivation of component types that may be used in subsequent system composition. When deriving component types it is necessary to detect and resolve the realizability problems that may occur. When a choreography is mapped to a composition of component behaviors and the global behavior emerging from the composition diﬀers from the global behavior speciﬁed in the choreography, we say there is a realizability problem. It may for instance happen that messages are received in a diﬀerent order than speciﬁed or that additional messages are needed to ensure the speciﬁed ordering. Realizability problems have been extensively studied in the context of interaction diagrams where they sometimes are referred to as implied scenarios or races. Similar realization problems may also occur when activity diagrams are used, and are therefore discussed in this paper. In the domain of embedded, reactive systems, components will often be linked to physical objects like users with autonomous behavior that may take independent initiatives needing to be coordinated and resolved. In business systems it is more common that services are provided by passive components that only

From Flow-Global Choreography to Component Types

39

respond to requests, and never take autonomous initiatives. This is, however, gradually changing with services becoming more pro-active and “pushing.” Dealing with mixed initiatives is therefore one of the fundamental coordination problems to be addressed in distributed reactive service systems. We therefore consider the case where components in general may be active and take independent initiatives either triggered by user actions, time or other events. In our approach we seek to identify all such problems and to resolve them either in the choreography or the orchestration. The rest of the paper is structured as follows: A case study is introduced in Sect. 2 and used throughout the paper to illustrate our approach. Section 3, 4, and 5 describe our proposed approach for the choreography representation, ﬂow-localization and component design, respectively. Related work is discussed in Sect. 6. Finally, concluding remarks are given in Sect. 7.

2

Service Structure

We illustrate our approach using a city guide service example, which has been implemented in previous work [3, 4]. It is a complex and challenging example, and therefore provides a realistic basis for evaluation. The users are students that have just arrived in a city and want to learn about diﬀerent places of interest. They use GPS enabled hand held devices and may create proﬁles specifying their preferences and interests. Based on their locations and proﬁle information, the users participate in diﬀerent groups and social activities. For instance, when a user is trying to ﬁnd a particular point of interest (e.g., a historic building), the user may interact with other users having similar interests. Users may have a peer-to-peer chat, group chat and discussions. When users are in the vicinity of a point-of-interest (POI), they may participate in a group quiz provided by a particular POI. Fig. 2 shows the city guide service as a UML collaboration with four diﬀerent roles that will map to corresponding component types: the user role that represents a user of the system; the group role that represents a group of users and support group functionalities; the poi role that represents a point-of-interest and provide quizzes and ﬁnally, the cgs role (city guide manager) that provides a guided tour to the users. A number of collaborations uses represent sub-services that are deﬁned separately: – Start tour performs the tour initiation triggered by the lead user. It has two roles: leadr that is bound to user and grp bound to group. – Get plan fetches a plan which is a list of points of interests. – Re-planning is a composite activity that stores the plan and allows the lead user to re-plan for the group (details are not discussed in this paper). – Position update is used to continuously update the current position as users are moving. – Connect poi will inform the POI to initiate a Quiz session with the group. – Group quiz performs a quiz session where each group member may suggest answers and the lead user may submit an answer.

40

S.B. Kathayat and R. Bræk

Cityy Guide Service act

City guide service

st:Start tour

leaderr user,leader aderr :user[*] leader

user,leader user,leader

user,leader

gq:Group quiz nm:Next n nm m:N :Nex ex xt xt m move pu:P pu:Position on update up u pdate p e

cp:Connect cp p:Con onne nect ctt poi poi gp gr grp grp gr p grp grp

grp p

grp

:group[*] :g :gro gro oup[*] o p ] p[

poii p po grp

q:Quiz q:Qu q: Quiz iz

p i poi :poi[*] :p poi[*

grp

grp p grp gr rp

gp:Get plan

et:End tour e cgs cgs rp:Re-planning lann niing ning

:cgs[1] :cg g gs[1

Fig. 2. Roles and sub-collaborations in a City guide service

– Tour manager manages the city guide tour. It holds a plan in the form of a list of POIs. It provides the next POI to be located when a current POI is ﬁnished. – Proximity detector checks if the users (using their positions) in a group are within a deﬁned proximity of a POI and initiate Connect poi when this is the case. We assume that the behavior of each of these collaborations is deﬁned by an activity diagram having the same name as the collaboration. For example, the activity diagram for the Position update collaboration is shown in Fig. 3(a) using ﬂow-localized choreography. Such diagrams are easily derived from corresponding sequence diagrams, if one is starting from a set of sequence diagrams rather than activity diagrams. Each collaboration encapsulate interactions across an interface between two or more participating roles and is used as a collaborative building block in the following. They are referenced by the actions nodes in a choreography model (discussed in Sect. 3) according to the notation given in Fig. 3(b).

3

Flow-Global Choreography Models

The ﬂow-global choreography deﬁnes the desired global execution ordering of collaboration uses in a composite collaboration. For example, the ﬂow-global choreography of the City Guide service is shown in Fig. 4 using UML activity diagrams.

From Flow-Global Choreography to Component Types

Position Update Collaboration grp role

user role

41

notation for collaborative action

start stopUpdate

getPos :Position

stop

starting pin

streaming input pin

stopped

role t

streaming output pin

updatePos :Position position

(a)

service name

terminating pin

alternative starting pin

role alternative terminating pin

(b)

Fig. 3. Elementary service model and Service notation used in choreography

All actions in the diagram call activities deﬁned separately. The called activities are either local to a role called local activities (here the prox. detector and tour manager) or deﬁning the choreography of a collaboration (the rest). For example, the start tour action st.Start tour and the position update action pu.Position update in Fig. 4 call the activity given for the st:Start tour and pu:Position update collaborations in Fig. 2 respectively. In this way, the diagram deﬁnes the choreography of, possibly nested, collaboration behaviors. The gq.Group quiz call behavior action calls the group quiz activity represented in Fig. 5. Note that the participating roles of collaborations are indicated by partitions deﬁned by solid lines in the action symbols. The initiating and terminating roles of the collaborations are indicated using dots and squares, respectively. This (dot and square) notation is not part of UML, but may be provided by additional proﬁling. An action can have all the diﬀerent types of pins that UML allows, such as initiating, streaming and terminating pins. An initiating pin will start the called activity if it is not started yet. Terminating pins will terminate the called activity. Streaming pins can pass tokens while the called activity is active, i.e., a ﬂow between two actions connected by streaming pins allows the called activities to interact without being stopped. For example, the streaming ﬂow from quiz to group quiz in Fig. 4 means that the quiz action, without being terminated, may interact with the group quiz i.e., they overlap. A question is sent from the quiz service via the streaming pin to the group quiz service (quiz is still active and group quiz is started). Using the group quiz service, the members of the group may discuss the possible answers and agree on one solution before a leader submits the answer. Note that variables and data are omitted in Fig. 4. However, it is possible to deﬁne and use data in the normal way deﬁned for UML activity diagrams. The particular case of initiative choices are modeled using interruptible regions (denoted by a dashed box) and interrupting ﬂows as shown in Fig. 5. In a group quiz service, there may arise a situation where a user is proposing an answer at the same time as the leader is submitting an answer. What we want is to choose either one or the other as speciﬁed in Fig. 5, but in a distributed realization

42

S.B. Kathayat and R. Bræk

act

CIty Guide Service leader

cgs

st.Start tour

gp.Get plan

grp

grp

{leader}

tm.Tour manager

user leader

et.End tour

grp

user, leader

nm.Next move

replan

grp leader rp.Replan

cgs

grp user, leader

pu.Position update

grp

pd.Proximity detector

poi

poi

user, leader

cp.Connect poi

grp

q.Quiz

grp

gq.Group quiz

grp

Fig. 4. Flow-Global choreography model

they may occur nearly simultaneously and require additional coordination to resolve which initiative to select. More on this is in Sect. 4.5. Optional behavior triggered by external events may be modeled in a similar way. A leader may for example opt to re-plan while the other users are using a current plan, triggered by the replan event in Fig. 4. We note that there is a certain amount of concurrency in the choreography in Fig. 4, that follows explicitly from the parallel forks and implicitly from the streaming pins. It is important to note here that this concurrency reﬂects the nature of the problem and is not imposed by the notation as such. In simpler cases, activities have only starting and terminating pins. Connecting such pins will result in a normal sequential ordering. We use streaming pins where we want activities to interact without being stopped.

From Flow-Global Choreography to Component Types

act

43

Group quiz

user leader

qs.Question

{user} sugg

user

sg.Sugg

grp

user leader

ss.Show sugg

grp

grp

{leader} submit

leader

sb.Submit

grp

Fig. 5. Flow-global speciﬁcation of Group quiz service

4

Flow Localization

At the ﬂow-global level we deﬁne the intended ordering including streaming pins, interruptible regions and initiative choices. At the ﬂow-localized level we need to ensure the ordering in terms of local ﬂows. In Sect. 4.1 and 4.2, we ﬁrst consider direct ﬂows with no control elements between the action nodes. In Sect. 4.3, the localization of the control nodes and notion of path is introduced. Streaming and interruptions are then discussed in the following sections. 4.1

Strong Sequence Localization

In this step we ensure the strong sequencing semantics of UML activity diagram, i.e., that leaving an activity through an activity ﬁnal node terminates the entire activity. It means that there will be no overlap or concurrency among activities that follow each other sequentially according to the ﬂow-global choreography, and hence realization problems caused by overlaps are avoided. We now assume that the collaborations on the lowest level of decomposition have only one initiating role and one terminating role, with a starting input pin assigned to the initiating role and a terminating output pin to the terminating role. In the case of parameter sets, all alternative pins need to be assigned to the same role. This is summarized in Fig. 6(a). The global ﬂows are then localized in the following way: – A global edge directly from collaboration action C1 to C2 is attached to the corresponding terminating output pin or parameter output pin of C1 and the starting pin or parameter input pin of C2.

44

S.B. Kathayat and R. Bræk

A

C1

place in B

place in B

place in B B

A

C1

B

A

B

C1

place in B or C

C1

A

B

D

C2

C

place in A (a) localization of pins

ev1

A

C1

B

{B}

(b) localized join

(c) localized merge

ev2 {C}

D

(d) localized fork

place in B C2

C

A

C1

B

D

C3

B

(f) localized local choice

(e) initiative choices

A

C1

B place in A or B

place in B,C

A

C1

B

D

C1

place in B

C

D

(g) non-local choice needing resolution

C3

B

C

C4

B

C

C5

A

(h) localized cascaded control nodes

Fig. 6. Summary of the rules for localizing pins and control nodes

– Every external event is localized to a single role, as illustrated in Fig. 6(e). For example, the replan event within the interruptible region in Fig. 4 is assigned to a lead user. Two cases are possible after this: – Natural strong sequence: the ﬂow between two collaborations C1 and C2 is completely localized to one role, as shown in Fig. 7(a). This means that strong sequence is ensured by the global ﬂow directly. In the city guide choreography (Fig. 4) there is a natural strong sequence between most activities. – Enforced strong sequence: the ﬂow between two collaborations C1 and C2 is not completely localized to one role and therefore implies a coordination message being passed to enforce the strong sequence. This is shown in Fig. 7(b) where the terminating pin of service C1 is connected to the initiating pin of C2. Flows linking pins on diﬀerent roles imply interaction using send and receiving events at the terminating and initiating roles respectively. Although this ensures a strong sequence, it adds a communication overhead. 4.2

Weak Sequence Localization

Flows with enforced strong sequence require additional communication that sometimes is neither desirable for performance reasons nor necessary for realizability reasons. In such cases we consider using weak sequencing instead. Weak

From Flow-Global Choreography to Component Types

A A

C1

B

A

C1

C2

B

A

(a) natural strong sequence

C2

B

C1

B m

m

A

45

B

A

B

C2

(b) enforced strong sequence

Fig. 7. Strong sequence localization

C1

A A

C1

{weak}

A

C2

B

A

m1

B

B

B

A

(a) weak sequence

C2

{weak} B

m1

m1

m2

m2

m2

m1

A m2

B

(b) possible message re-ordering problem

Fig. 8. Weak sequence localization

sequencing is the normal semantics of Sequence diagrams, and distributed system in general. This means that a component may initiate C2 as soon as it is ﬁnished with its role in C1, even if messages may still be in transfer so that all roles of C1 are not completely ﬁnished. It means that there may be some overlaps between collaborations that potentially may cause realizability problems such as races. In order to model the weak sequencing, we attach a local terminating pin to the role in C1 that initiates C2. This is modeled as a streaming pin with the property {weak}, as indicated in Fig. 7 and 8. So far we have considered ﬂows that connect to the initiating role of the next collaboration, what we call initiating flows. For the non-initiating roles, the implication of these ﬂows is that they must be ready to respond as indicated by the dashed lines in Fig. 8(a). This represents what we call responding flows, to be elaborated in Sect. 5. Interestingly, the presence of a weak responding ﬂow implies overlap between role behaviors, and thus it serves to indicate a potential realization problem. The problem is that events in overlapping roles may interleave in ways not speciﬁed in the choreography. Whether this is possible or not depends on the underlying communication medium linking the roles. As we can see in Fig. 8(b), since A initiates C2 only after it ﬁnishes its role in C1, m2 is always sent after m1. However, if the communication link between

46

S.B. Kathayat and R. Bræk

components A and B may reorder the messages, the messages m1 and m2 may arrive in any order at B. This is a realizability problem that must be resolved. In order to resolve this kind of realizability problems we have three options: – Resolve the problem on the level of orchestration (component design), i.e., deal with overlapping behavior in the component design, or use a communication medium that conserves the sending order. – Modify the choreography to ensure, natural strong sequence. – Enforce the strong sequence by additional communication. In general, according to [5], when a composite role participates in two consecutive collaborations that are not strongly sequenced and plays a non-initiating sub-role in the second one there will be overlap and potential message ordering problems like in Fig. 8(b). If, for example, the component B in C2 in Fig. 8 is replaced with another component D, then there will be no message ordering problem due to overlapping roles in C1 and C2. In the choreography of the city guide given in Fig. 4, there is no case of weak sequence localization. 4.3

Control Nodes and Paths Localization

Flows connecting a source action node C1 and target action node C2 may contain intermediate control nodes such as decisions, merges, forks and joins. In such cases, we say that two action nodes C1 and C2 are linked by a flow-path through a number of intermediate control nodes linked by direct flow-steps. Each intermediate ﬂow-step and control node may be part of several ﬂow-paths. The intermediate control nodes are localized according to the following rules: 1. Each flow-path from Ci to Cj is ﬁrst localized to the initiating role of Cj. 2. Find all the ﬂow-paths through each intermediate control node. 3. If all paths through a node are local to the same component, localize the node to that component. 4. If some paths involve an interaction to enforce strong sequencing, the node can be localized to either the source component or the target component of the path as long as all paths through the node can be localized to the same component. 5. If the node is a choice node, it must be localized to the target component of the path and it must be possible to make the choice based on information local to that component. 6. If localization according to steps 3, 4 and 5 above is impossible, then there is a realization problem to resolve. Fig. 6(b), 6(c) and 6(f) illustrate cases where the control nodes can be localized to component B. In 6(g), there is a non-local choice which is not directly realizable and must be resolved as explained in Sect. 4.5. In the case in Fig. 6(d), the ﬂow-paths though the fork node may be localized to either B or C if the additional communication also is needed to enforce strong sequencing. The fork

From Flow-Global Choreography to Component Types

C1

A

B

{stream}

A

m1

B

m1

m2

m1

m2

m2

m1

m2

m1

{stream}

B

C2

A

A

m2

47

B

ne activity (a) service overlapping due to streaming pins when a streaming flow initiates next

A

C1

B

{stream}

from other service

{stream} A

C2

A

m1

B

m3

m2

m1

m1

m3

m2

m1

m3

m2

m2

m1

m3

m2

m1

m3

m3

m2

m1

B

A

m2 m3

B

(b) service overlapping due to streaming pins provided vided that next activity has already a started

Fig. 9. Message ordering problems due to the overlapping of services

node may either be localized to B with an interaction ﬂow to C or the other way around. In more complex cases having more than one intermediate node, as in Fig. 6(h), we can use the same approach. For example, the fork node may either be localized to A or B. However, in this case we also need to make sure that all the nodes in a path should be localized to the same component, and if that is not the case a interaction ﬂow is needed. When the fork node in Fig. 6(h) is localized to A, then we may need to use an interaction ﬂow from the fork node to the choice node. 4.4

Streaming Flow Localization

Streaming pins must be assigned to roles such that output pins are assigned to the role that generates the output token, and input pins assigned to the role that receives the input token. Once the streaming pins have been localized, the ﬂows and intermediate control nodes are localized in the same general manner as control ﬂows, explained above. We now classify ﬂows initiating from and/or ending on streaming pins as streaming flows. The following cases are possible: – Streaming output to starting input: This kind of situation exists, for example, between the quiz and group quiz services in Fig. 4. Due to the streaming pins, we may have overlapping service roles, and this may cause problems as illustrated in Fig. 9(a). This kind of ﬂow is akin to the weak sequencing discussed above and is indicated by the {stream} property on the corresponding responding ﬂow.

48

S.B. Kathayat and R. Bræk

– Streaming output to streaming input: This means that both activities will be running in parallel and that streaming inputs may interleave with other events. This may lead to overlapping roles, like in Fig. 9(b), causing realizability problem. As we can see, m1 is the last message from B to A in C1. However, B may send m3 to A before m1 provided that C2 has been already started by some service other than C1. Therefore there is a possibility that B may send messages m1, m2 and m3 in any order and eventually that A receives them in any order also. This may or may not be what the composer wants to specify. – Terminating output to streaming input: This type of ﬂow causes no overlaps and is directly realizable as long as C2 is ready to accept the token from C1. For streaming ﬂows we distinguish two main cases: – Local streaming: the ﬂows are entirely within one component (composite role). This can be coordinated within the component and will be unproblematic in most of the cases. We note here that it is desirable that streaming ﬂows are local to one role. – Global streaming: a ﬂow that implies communication. This may be problematic and needs careful consideration. As a method guideline global streaming ﬂows should preferably be encapsulated in collaborations. 4.5

Initiative Choice Localization

Fig. 5 deﬁnes the intended behavior of an initiative choice. There is no way to prevent the initiatives from happening simultaneously, so-called mixed initiatives. This requires additional resolution behavior and therefore initiative choices are not directly realizable. The resolution strategy will depend on the problem at hand and is diﬃcult to solve in a general way. Instead, one may develop a library of alternative solutions to select from. One way to handle such situations is to assign primary and secondary priorities to the conﬂicting partners and let an initiative from the primary side be accepted in all cases. For the secondary side, this means that it must be prepared to receive a primary initiative even after it has issued an initiative itself, and obey the primary one; the secondary is in this case discarded. This feature can be modeled in a ﬂow-localized choreography using a mixed initiative resolution building block, called MISS in [2]. The MISS building block is used in the group quiz service as shown in Fig. 10 (in terms of ﬂow-localized choreography). Fig. 11 illustrates the same using the UML swim-lane style supported by Arctis. In the cases of conﬂicts, a priority is given to the leader. In the Arctis-style choreography, we have chosen to represent the lead-user and ordinary users as distinct roles in order to show the diﬀerence, we have also included user interface blocks [4] where the sugg and submit events are captured. The group quiz service is started when a group receives a question via the ques starting pin. The question is then forwarded via the question service to all users (shown by multi-session in Fig. 11) and also to the leader. When users

From Flow-Global Choreography to Component Types

act

49

Group quiz

user leader

qs:Question

{user} sugg

grp

{leader} submit

s.init

p.init MISS

S s.wins

p.wins

user

sg:Sugg

grp

user leader

ss:Show sugg

grp

P p.wins

leader

sb:Submit

grp

Fig. 10. Mixed initiatives resolution in ﬂow-localized choreography

start suggesting answers to the question via the suggestion service, the group forwards the suggestions to the other users (shown by session select statement, for detail refer [6]) and to the leader. In the case of conﬂicting initiatives, i.e., the user is suggesting an answer at the same time as the leader is submitting, priority is given to the submitted answer (the group is given a primary role in the MISS service) and the user role is prevented from suggesting any further answers via the p.wins pin at the user role.

5

Deriving Components

Given a ﬂow-localized choreography with all realizability problems resolved, the next step is to derive a local activity ﬂow for each component type, the so-called orchestration, consisting of the actions and control nodes that are local to the component, i.e., the collaborative actions and local action as well as the fork, join, decisions and merge nodes. This is done by making a projection of the ﬂow-localized choreography onto the components in the following way: – For each component make a copy of the ﬂow-localized choreography. – Replace each collaboration action and local action where the component is not participating by a no-operation node, and keep all the collaborations and local actions where it participates.

50

S.B. Kathayat and R. Bræk

Fig. 11. Arctis style modeling of the Group quiz service

– Include all the ﬂows that are completely localized to the component type. These types of ﬂows are called local flows (local initiating and local streaming ﬂows). Note that local actions and control nodes will be associated with such ﬂows. – Flows that cross the component boundary and therefore involve communication are called interaction flows. Such ﬂows map to send event actions on the sending side and accept event actions on the receiving end. – Flows that are completely external to the component, are marked as responding flows. The responding ﬂows determine when the component must be ready to participate in collaborations initiated by other components, i.e., collaborations where the component plays a non-initiating role. The resulting component types for group and leader are shown in Fig. 12 and Fig. 13, respectively. Note that we have kept reference to the external collaborations for later use during composition. Inside the role actions there will be send actions and receive actions for the interaction ﬂows of the collaborations. The component models have local ﬂows representing local control ﬂows and responding ﬂows (denoted by dashed lines) representing ﬂows external to the component. A responding ﬂow may be a simple edge or a complex ﬂow involving external control nodes as well as no-op nodes representing collaborations and local actions where the component is not participating. Responding ﬂows in the group component type are mostly simple responding ﬂows. A responding ﬂow between cp.grp and q.grp speciﬁes that the group should be ready to participate in a quiz session with a POI once the group has initiated a connect poi collaboration. A responding ﬂow between nm.grp and pu.grp represents the case where the group informs the user about a next move, and then should be ready to participate in position update collaborations.

From Flow-Global Choreography to Component Types

51

«roletype» City Guide Group st. leader

st:Start tour

st.grp

et. user, leader

et:End tour

et.grp

end

tm.Tour manager

move nm. user, leader

nm:Next move nm.grp

pu. user, leader

pu:Pos. update pu.grp

gp:Get plan

gp.grp

gp.cgs

next cp.grp

cp:Connect poi cp.poi

next poi

q:Quiz

q.poi

gq:Group quiz

gq. user, leader

q.grp

pd.Prox detector pos

ques

ans

gq.grp

stop

Fig. 12. The city guide group component models

There are several responding ﬂows in the Leader component type in Fig. 13 representing ﬂows involving external control nodes as well as no-op nodes that have been removed from the diagram. For example, a responding ﬂow between pu.Pos update and gq.Group quiz involves three no-operation nodes (pd.Prox detector, cp.Connect poi and q.Quiz, c.f. Fig. 4) and one external fork. Responding ﬂows that have {weak} or {streaming} properties need special attention since they may cause activity overlaps and thus potential race situations that must be resolved. Note that there may be several possible responding ﬂows ending on a collaboration activity. This means that tokens can arrive along the diﬀerent paths in diﬀerent order. Each responding path may be shortened and simpliﬁed into the shortest and most direct path representing the earliest situations when a token may arrive. For the detailed algorithm on simplifying a responding path, see. [7]. The resulting component models may now be used to compose more composite components and systems. They may also be translated separately into equivalent UML state machines from which corresponding application code can be generated using existing tools such as Arctis.

6

Discussion and Related Work

In the domain of reactive systems it has been common to use interaction diagrams in one form or another to deﬁne global behaviors. UML interaction overview diagrams (IOD), or high level MSC diagrams may then be used for ﬂow-global choreography [8]. Compared to the IODs, activity diagrams allow

52

S.B. Kathayat and R. Bræk

«roletype» City Guide Leader

st.grp

et.grp

st:Start tour

st. leader

et:End tour

et. leader

nm. leader

nm:Next move nm.grp

pu. leader

pu:Pos update pu.grp

{stream} gq. leader

gq:Group quiz

gq.grp

Fig. 13. The city guide leader component models

the representation of roles as partitions of activities which is useful information that helps to understand and analyze the global behavior at the level of choreography. According to the UML speciﬁcations in [9, p. 512], IODs are specialization of activity diagram that show control ﬂow between set of interactions. IODs can deﬁne sequential and parallel composition of interactions, as well as loops and alternatives. However, IODs excludes many rich modeling constructs available in activity diagram such as interruptible regions, ﬂow ﬁnal nodes, and streaming nodes [10]. Interruptible regions of activities are useful for modeling initiative choices, exception handling and external priority interrupts. Note that there is an interaction operator break in UML, but it can only be applied in a sequence diagram not at the interaction overview level. Streaming pins are useful to model interactions among concurrent actions at a high level (as discussed in Sect. 3 between quiz and group quiz ). In principle it is possible to use sequence diagrams for elementary collaborations and activity diagrams for choreography, since call behavior actions can call behavior deﬁned by interactions. This has been done in [5], but exactly how to combine the two forms is not fully deﬁned in UML. The realizability problems associated with weak sequencing and initiative choices we have discussed here are the same as those identiﬁed in [5] and therefore not particular to activity diagrams. We have found activities to provide a good combination of readability, completeness, and automation potential. This combined with the beneﬁt of staying within one notation are the main reasons for our decision to use activity diagrams throughout. The authors in [11] identify the needs to encapsulate the interaction behavior of distributed components by so-called collaboration modules. They have suggested collaboration based design with a tighter integration between interaction and state diagram models, and created a speciﬁc language called CoSDL to

From Flow-Global Choreography to Component Types

53

deﬁne collaborations. The global behavior speciﬁed by the composition of such collaborations modules in CoSDL is at the ﬂow-localized level. CoSDL is aligned to SDL [12]. Use Case Maps can be used for both ﬂow-global and ﬂow-localized choreography [13, 14]. Related work in the embedded systems and web-services domains [18–21] has concentrated on ﬂow-localized choreography using interactions and activity diagrams. Most of this work assumes a manual derivation of components. Unlike most approaches [18–21], we encapsulate interactions in collaborative building blocks. Most of the approaches are only control ﬂow oriented, except [15] which considers data as well. Initiative choices, called mixed initiatives in [22], which are normal and unavoidable cases in many reactive systems are handled only by us and [15]. There are diﬀerent techniques to check the conformance between choreography and orchestration. In [18], behavioral equivalence is used. The equivalence is checked between the labeled transition system (LTS) for the parallel composition of orchestrators and the LTS of the choreography. The authors in [15, 16] use the notion of bisimulation [23] for the conformance and trace equivalence is used in [17]. Some of our previous work has been concentrated on choreography where all ﬂows are localized to praticipating roles [6] which is supported in the Arctis tool [2]. Note that our ﬂow-localized choreography is semantically equivalent to Arctis models, and therefore Arctis can provide a tool basis for further analysis and state machine synthesis. However, the Arctis tool currently generates complete systems and not component types that may be used in subsequent component based system composition at the modeling level. The ﬂow-global choreography avoids the layout restriction of the swim-lane notation by representing the participating roles inside the actions as proposed in [24]. In [5], the authors suggested a classiﬁcation of realizability problems and some criteria for detecting them at the ﬂow-global level. In this paper we elaborate on localization i.e., how ﬂow-global choreography is mapped to ﬂowlocalized choreography and further to orchestration of distributed component types with external interfaces. We believe the concept of responding ﬂows is novel and that {weak} responding ﬂows provides a new way to identify potential realization problem. This will be addressed in future work.

7

Conclusion

A general approach for the deﬁnition of ﬂow-global choreography of services is presented where the global behavior of a service is speciﬁed by linking together actions representing collaborative and local behavior. From the ﬂow-global choreography we derive ﬂow-localized choreography models that may be extensively analyzed using existing tools such as Arctis. Distributed component implementations may then be automatically generated. Our work is unique in its combination of: 1) the development trajectory it covers; 2) the use of the full power of activity diagrams; 3) the support for reusable building blocks both on the level of collaborations and on the level of components.

54

S.B. Kathayat and R. Bræk

Responding ﬂows are introduced to represent ﬂows external to a component. This makes it possible to synthesize state machines and implementations for each component separately, and also provides a key to identify a class of realization problems. Components may be stored in libraries and reused in subsequent system composition. Component types provide information about their interface collaborations that may be utilized for compatibility checks, dynamic linking and binding of component instances. In this way our approach supports reuse and composition both on the level of collaborative building blocks and on the level of components. Further work is planned to provide full tool support and to elaborate on component composition.

References 1. Erl, T.: SOA: Principles of Service Design. Prentice Hall Press, Englewood Cliﬀs (2007) 2. Kraemer, F.A., Sl˚ atten, V., Herrmann, P.: Tool Support for the Rapid Composition, Analysis and Implementation of Reactive Services. Journal of Systems and Software 82, 2068–2080 (2009) 3. Kathayat, S.B., Bræk, R.: Platform Support for Situated Collaborative Learning. In: International Conference on Mobile, Hybrid, and Online Learning, pp. 53–60. IEEE Computer Society, Los Alamitos (2009) 4. Kraemer, F.A., Kathayat, S.B., Bræk, R.: Uniﬁed Modeling of Service Logic with User Interfaces. In: Proceeding of the First International Workshop on Model Driven Service Engineering and Data Quality and Security, pp. 37–44. ACM, New York (2009) 5. Castej´ on, H.N., Bræk, R., Bochmann, G.V.: Realizability of Collaboration-Based Service Speciﬁcations. In: Proceedings of the 14th Asia-Paciﬁc Software Engineering Conference, pp. 73–80. IEEE Computer Society, Los Alamitos (2007) 6. Kraemer, F.A.: Engineering Reactive Systems: A Compositional and Model-Driven Method Based on Collaborative Building Blocks. PhD Thesis, Norwegian University of Science and Technology (2008) 7. Kathayat, S.B., Bræk, R., Le, H.N.: Automatic Derivation of Components from Choreographies - A Case Study. In: International Conference on Software Engineering, Phuket, Thailand (2010) 8. Decker, G.: Realizability of Interaction Models. In: 1st Central-European Workshop on Services and their Composition, CEUR-WS.org, pp. 55–60 (2009) 9. OMG, Uniﬁed Modeling Language 2.1.1 Speciﬁcation (Superstructure 07-02-05), http://www.omg.org 10. Whittle, J.: Extending Interaction Overview Diagrams with Activity Diagram Constructs. Software and Systems Modeling 9, 203–224 (2010) 11. R¨ oßler, F., Geppert, B., Gotzhein, R.: CoSDL - An Experimental Language for Collaboration Speciﬁcation. In: Sherratt, E. (ed.) SAM 2002. LNCS, vol. 2599, pp. 1–20. Springer, Heidelberg (2003) 12. International Telecommunication Union: Recommendation Z.100, Speciﬁcation and Description Language (SDL) (November 2007), http://www.itu.int/rec/T-REC-Z.100/en 13. Castej´ on, H.N.: Synthesizing State-Machine Behaviour from UML Collaborations and Use Case Maps. In: Prinz, A., Reed, R., Reed, J. (eds.) SDL 2005. LNCS, vol. 3530, pp. 339–359. Springer, Heidelberg (2005)

From Flow-Global Choreography to Component Types

55

14. Buhr, R.J.A.: Use Case Maps as Architectural Entities for Complex Systems. IEEE Transactions on Software Engineering 24, 1131–1155 (1998) 15. Kazhamiakin, R., Pistore, M.: Choreography Conformance Analysis: Asynchronous Communications and Information Alignment. In: Bravetti, M., N´ un ˜ez, M., Tennenholtz, M. (eds.) WS-FM 2006. LNCS, vol. 4184, pp. 227–241. Springer, Heidelberg (2006) 16. Busi, N., Gorrieri, R., Guidi, C., Lucchi, R., Zavattaro, G.: Choreography and Orchestration Conformance for System Design. In: Ciancarini, P., Wiklicky, H. (eds.) COORDINATION 2006. LNCS, vol. 4038, pp. 63–81. Springer, Heidelberg (2006) 17. Qiu, Z., Zhao, X., Cai, C., Yang, H.: Towards the Theoretical Foundation of Choreography. In: Proceedings of the 16th International Conference on World Wide Web, pp. 973–982. ACM, New York (2007) 18. Sala¨ un, G., Bultan, T.: Realizability of Choreographies Using Process Algebra Encodings. In: Leuschel, M., Wehrheim, H. (eds.) IFM 2009. LNCS, vol. 5423, pp. 167–182. Springer, Heidelberg (2009) 19. Mendling, J., Hafner, M.: From Inter-organizational Workﬂows to Process Execution: Generating BPEL from WS-CDL. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2005. LNCS, vol. 3762, pp. 506–515. Springer, Heidelberg (2005) 20. Barros, A., Dumas, M., Oaks, P.: A Critical Overview of Web Service Choreography Description Language (WS-CDL). In: BPTrends (March 2005) 21. Wieczorek, S., Roth, A., Stefanescu, A., Kozyura, V., Charﬁ, A., Kraft, F.M., Schieferdecker, I.: Viewpoints for Modeling Choreographies in Service-Oriented Architectures. In: WICSA/ECSA, pp. 11–20. IEEE Press, Los Alamitos (2009) 22. Bræk, R., Floch, J.: ICT convergence: Modeling issues. In: Amyot, D., Williams, A.W. (eds.) SAM 2004. LNCS, vol. 3319, pp. 237–256. Springer, Heidelberg (2005) 23. Milner, R.: Communication and Concurrency. Prentice-Hall, Inc., Englewood Cliﬀs (1989) 24. Castej´ on, H.N.: Collaborations in Service Engineering: Modeling, Analysis and Execution. PhD thesis, Norwegian University of Science and Technology (2008)

Integration of FlexRay into the SDL-Model-Driven Development Approach Tobias Braun, Reinhard Gotzhein, and Matthias Wiebel Networked Systems Group, University of Kaiserslautern, Germany {tbraun,gotzhein,m_wiebel}@cs.uni-kl.de

Abstract. In today’s cars, communication systems providing deterministic guarantees regarding latency and jitter are needed. For safety-critical x-by-wire applications, even physical redundancy is required. FlexRay is a recent ﬁeld-bus technology especially devised for these needs. In this paper, we present the integration of FlexRay into SDL-MDD, the SDL Model-driven Development approach. In particular, we show how certain dynamic conﬁguration aspects of and communication via FlexRay can be speciﬁed already on design level with SDL, thereby abstracting from technological details. Furthermore, we extend the SDL Environment Framework by driver components supporting the automatic interfacing of SDL systems with FlexRay hardware. Finally, we present a functionally complex application scenario with real FlexRay hardware demonstrating the beneﬁts and full operativeness of our solution. Keywords: SDL, SDL-MDD, Model-Driven Development, Automotive, FlexRay.

1

Introduction

Today, cars are equipped with a growing number of networked electronic control units (ECUs), providing functionality for chassis and power train control, security, comfort, and entertainment. Communication among ECUs has to meet high demands regarding timeliness, with deterministic guarantees for latency and jitter. With the upcoming trend towards x-by-wire-systems for safety-critical functionalities, e.g. steering or braking, physical redundancy is required, too, in order to cope with partial system failures. A protocol especially devised for these needs of the automotive domain is FlexRay [1], which is being used in vehicles since 2006. To meet hard timing constraints, FlexRay has been conceived as a deterministic, time-triggered protocol, with built-in features to support event-based communication, too. Redundancy is achieved by two independent physical channels. Yet, these real-time capabilities and its high degree of conﬁgurability make FlexRay a complex protocol that has turned out to be diﬃcult to handle in practice. Our method to cope with the complexity of FlexRay is its integration into SDL-MDD [2,3], our model-driven development approach with SDL [4] as modeling language. On design level, we provide a comprehensive abstract signal F.A. Kraemer and P. Herrmann (Eds.): SAM 2010, LNCS 6598, pp. 56–71, 2011. c Springer-Verlag Berlin Heidelberg 2011

Integration of FlexRay into the SDL-Model-Driven Development Approach

57

interface that enables high-level, SDL-style interaction with virtual FlexRay environments, thereby hiding technological details. On implementation level, we have extended the tool support of SDL-MDD such that implementations generated from SDL designs are automatically instrumented to interface with real FlexRay hardware, avoiding manual coding entirely. This is in line with the idea of model-driven development, where the model is in the center of the development activity. It furthermore relates closely to work previously done in our group [5], where we integrated other communication technologies, e.g. WLAN and Bluetooth, into the SDL-MDD. Regarding the integration of FlexRay into the model-driven development process with SDL, no other work has been done so far. However, another approach to reduce the complexity of the development for FlexRay-based systems is shown in [6]. Here, the model-driven approach is realized using a system description language called TDL (Time Deﬁnition Language). A TDL program explicitly speciﬁes the exact real-time interactions of software components with each other and the physical world. The authors focus on the improvement of systems developed with SIMULINK. They were able to measure a productivity gain by a factor of 20 and more with TDL compared to state-of-the-art FlexRay development methods and tools used in the automotive domain. Videos showing the tool that has been devised to support this approach can be found in the web [7]. In [8], SDL has been used to speciﬁy the behaviour of a FlexRay communication controller based on the SDL speciﬁcations given in the FlexRay Communication System Protocol Speciﬁcation [1]. But this speciﬁcation is just used to assist the implementation of a communication controller in Verilog HDL, and not to enable the usage of FlexRay in a model-driven development approach with SDL. The paper is organized as follows: In Sect. 2, we survey SDL-MDD including its tool chain and explain the principles of integrating FlexRay. Sect. 3 gives an overview of FlexRay and explains common hardware-speciﬁc details of a typical FlexRay communication controller. With this technological background, we introduce the SDL signal interface for FlexRay and tool support in Sect. 4. Sect. 5 presents a functionally complex application scenario, starting with an SDL design and ﬁnally running the generated implementation on real FlexRay hardware. In Sect. 6, we draw conclusions and outline future work.

2

SDL-MDD - Model-Driven Development with SDL

SDL-MDD [3] is a model-driven development approach based on a formal system model using ITU-T’s Speciﬁcation and Description Language (SDL, [4]) as design language. It is in line with the OMG MDA and starts with a computationindependent model (CIM), where message sequence charts (MSC) and informal texts are used to collect essential requirements and functionalities (see Fig. 1). The speciﬁcation of the platform-independent model (PIM) is done with SDL as design language and fully covers the system functionalities, still abstracting from platform-speciﬁc details. The platform-speciﬁc model (PSM) is derived from the PIM by selecting a concrete hardware platform and adding

58

T. Braun, R. Gotzhein, and M. Wiebel

CIM (MSC)

Specification Phase

PIM (SDL)

SVM (C-CODE)

PSM (SDL)

PSSI (SDL)

RIC (C-CODE)

SEnF (C-CODE)

RSC (machine code)

Implementation Phase

Fig. 1. SDL-MDD (grey: Platform speciﬁc supplements for the integration of FlexRay)

platform-speciﬁc abstract interfaces. One example for such an interface, called PSSI (platform-speciﬁc signal interface, see Fig. 1) is our SDL interface for using FlexRay, which is presented in Sect. 4. Executables for the chosen hardware platform are generated automatically from the PSM in two steps. In the ﬁrst step, a code generator, e.g. Tau Cadvanced [9] or ConTraST [10], is used to generate intermediate code (RIC - Runtimeindependent Code) in a language such as C or C++. Our SDL Environment Framework (SEnF) provides the necessary hardware-speciﬁc drivers for the abstract interfaces used in the PSM. Hence, a platform-dependent C or C++compiler can be used to obtain the executable machine code (RSC - RuntimeSpeciﬁc Code). The RSC is executed under the control of the SDL Virtual Machine (SVM), which is amongst others responsible for the initialization of the SDL system, selection and execution of transitions, and the signal transfer between SDL processes. SdlRE (SDL Runtime Environment) is our implementation of an SDL Virtual Machine supporting the RIC generated by ConTraST.

3

FlexRay - A Field Bus in the Automotive Domain

FlexRay is a deterministic, time-triggered ﬁeld bus with two independent physical channels, especially devised for the needs of the automotive industry [11]. The FlexRay 2.1A protocol speciﬁcation [1] was developed and published in 2005 by the FlexRay Consortium. Partners of the FlexRay Consortium, which ﬁnished its work in 2009, were leading companies in the automotive and chip design sector, such as BMW AG, DaimlerChrysler AG, Freescale and General Motors. In this section, we give an overview of the FlexRay protocol (Sect. 3.1) and the FlexRay hardware (see Sect. 3.2).

Integration of FlexRay into the SDL-Model-Driven Development Approach

3.1

59

Outline of the FlexRay Protocol

FlexRay supports redundant transmission of frames. Therefore, two independent physical channels A and B with up to 10 Mbit/s of bandwidth each are available. If this redundancy is not needed, both channels can be used to transmit diﬀerent frames at the same time to double the transfer rate. FlexRay uses TDMA (Time Division Multiple Access) as medium access control mechanism. This allows deterministic guarantees concerning frame latency and jitter as well as prioritybased transmissions of frames with dynamic bandwidth acquisition. To achieve this, the FlexRay protocol divides time into a sequence of communication cycles of constant duration. Each communication cycle consists of a mandatory static segment, an optional dynamic segment, an optional symbol window and the mandatory network idle time (NIT) as shown in Fig. 2. Every node has an 8-bit cycle counter numbering communication cycles. This counter has the same value in all synchronized cluster nodes and can be used as ﬁlter criterion. communication cycle static segment

....

static slot 1

symbol window NIT

dynamic segment

....

static slot k

....

static slot i

.... Frame k

....

slots

....

minislots

....

macroticks

dynamic slot i+1 i+2 i+3

Frame i+1

i+3

Fig. 2. Possible communication cycle with static segment, dynamic segment, symbol window and NIT

The static segment is subdivided into a conﬁgurable, but ﬁxed number of static slots. Each static slot is assigned to at most one node exclusively, which can send frames in that slot without contention with other nodes. By default, each node is assigned one static slot called key slot. Beside the transfer of data, these key slots can be used for management purposes. The slots of the static segment are sequentially numbered, starting with one. Frames to be sent in static slots have a unique frame ID, which corresponds to the slot number. Static slots have equal length, which is expressed in terms of macroticks, the smallest common, cluster-wide synchronized time unit of the FlexRay protocol. Special cluster nodes, so-called synchronization nodes, are responsible for sustaining synchronization during the entire cluster lifetime. They transmit special

60

T. Braun, R. Gotzhein, and M. Wiebel

synchronization frames1 in their key slot. Coldstart nodes are another type of cluster node, responsible for the startup process of the cluster and the joining of additional nodes. For this purpose, they transmit startup frames in their key slots. For correct operation of FlexRay, it is important that all synchronized nodes associate the start and end of a frame transmission to the same static slot. Slot boundaries are determined by each node using local clocks, which are resynchronized periodically. Due to imperfect synchronization caused by clock skew and propagation delay, there is a clock oﬀset, for which, however, an upper bound aWorstCasePrecision can be determined [1]. Each node sending a frame in a static slot has to delay the start of transmission - called action point - by this value,2 which ensures that all other nodes will detect the start of transmission in the same time slot (see Fig. 2). For the same reasons, a node has to stop its transmission aWorstCasePrecision before the end of the time slot. The dynamic segment consists of a conﬁgurable, but ﬁxed number of minislots of equal length expressed in terms of macroticks. Besides minislots, the dynamic segment is divided into dynamic slots at runtime. These slots are created according to the communication needs of the current communication cycle by the so-called minislot mechanism. A dynamic slot consists of at least one minislot. The exact number of minislots of a dynamic slot is determined at runtime and depends on the priorities of the scheduled frames and the length of their payload. Therefore, the number of dynamic slots in a communication cycle also depends on these values. Dynamic slots are sequentially numbered, starting with the number of the last static slot increased by one (see Fig. 2). A transmission of a frame is only allowed, if the slot number matches the frame ID. The frame IDs a node is allowed to transmit represent the priority of the frames, where a low frame ID corresponds to a high transmission priority. It is up to the designer to ensure that each dynamic slot on a channel is assigned to at most one node for each communication cycle. FlexRay’s minislot mechanism works in the following way. Every node uses a local slot counter, which is increased by one for every minislot3 that is not used for transmission. If the value of the slot counter is equal to the ID of the scheduled frame, the transfer of the frame is started. As long as a frame is transmitted, the slot counters of all nodes remain unchanged. A node only transmits its frame, if the transmission can be completed within the bounds of the dynamic segment. Otherwise, no further deterministic guarantee concerning the latency for transmissions in later communication cycles would be possible. Figure 2 shows an example of the minislot mechanism, used to transmit two frames with diﬀerent payload lengths. The frame with ID i+1 has higher priority than the frame with ID i + 3 and is therefore transmitted ﬁrst. Each minislot 1 2 3

A frame with a sync bit set in the frame header. The worst case precision aWorstCasePrecision is not the only quantity to be considered, but the most important, see [1] for further details. During the static segment, the same counter is used and incremented by one for every static slot.

Integration of FlexRay into the SDL-Model-Driven Development Approach

61

has its own dynamic action point for the same reasons as described for static slots. Diﬀerent from the static segment,a transmission in the dynamic segment always starts and ends at a dynamic action point (where padding is used when required). Typically, the dynamic action point oﬀset is chosen more aggressively than the action point oﬀset of the static segment in order to achieve better usage of the available bandwidth. The symbol window can be used to send and receive special symbols, such as the media access test symbol. Finally, the network idle time (NIT ) is reserved for resynchronization of clocks and related internal computations. 3.2

Outline of the FlexRay Hardware

A FlexRay node consists of host, communication controller and two bus drivers, one for each physical channel. The host comprises the hardware platform to be attached to a FlexRay cluster and executes the application code. The communication controller (CC) implements the FlexRay protocol engine [1]. There are two possible integrations of host and CC, either a single-chip solution or two separate circuits. In our demonstrator, we have realized the latter option, with host (Imote2, [12]) and CC (Fujitsu MB88121C, [13]) communicating via serial peripheral interface (SPI). The bus drivers provide interfaces between CC and physical channels, i.e., the adjustment of the electrical level on the wire for transmission or the sampling for reception of frames. The CC provides a freely conﬁgurable message RAM that stores data, status, and conﬁguration information of frames. The message RAM is structured into a set of message buﬀers of diﬀerent types:4 • Send buﬀers are assigned to one speciﬁc static or dynamic slot, i.e. one frame ID. If the slot boundary is reached and the assigned send buﬀer contains data, a corresponding frame with this payload is created and transmitted. Send buﬀers support two diﬀerent modes of operation: Single-shot and continuous mode. A buﬀer conﬁgured to work in single-shot mode is cleared after message transmission. In continuous mode, the message remains in the buﬀer and is resent until it is replaced. • As send buﬀers, receive buﬀers are assigned to one speciﬁc static or dynamic slot. Receive buﬀers can also be grouped to form a FIFO buﬀer. Frames without a corresponding receive buﬀer are stored in this buﬀer, if they pass a conﬁgurable ﬁlter decision. • It is possible to use communication cycle multiplexing for receive, send, and FIFO buﬀers. This means that a message buﬀer with conﬁgured cycle counter ﬁlter is only used if the number of the current communication cycle (i.e., the cycle counter) satisﬁes the ﬁlter constraints. For example, it is possible to conﬁgure message buﬀers for odd or even communication cycles only. This grants the option to preload a send buﬀer in a cycle where it is not scheduled, or to postpone the reading of a receive buﬀer without losing data. 4

The following description applies to CCs using the Bosch E-Ray IP-Module [14]. However, the same concepts are supported by most CCs currently available, such as the Fujitsu MB88121C [13], which we have used in our experiments.

62

T. Braun, R. Gotzhein, and M. Wiebel

The option to preload send buﬀers and to delay the reading of receive and FIFO buﬀers supports temporal decoupling between the host and the CC. Thus, a synchronization between processes running on the host and the timing of the FlexRay protocol is not stringent for successful operation.

4

The SDL-FlexRay Interface

According to SDL-MDD, the PSM is derived from the PIM by selecting a concrete hardware platform and adding platform-speciﬁc interfaces (see Sect. 2). At this point, the developer can select FlexRay as the underlying communication technology of the system. In Sect. 4.1, we provide a comprehensive abstract signal interface that enables high-level, SDL-style interaction with virtual FlexRay environments, thereby hiding technological details. In Sect. 4.2, we outline the extension of the SDL Environment Framework (SEnF) to automatically instrument implementations generated from SDL designs to interface with real FlexRay hardware. 4.1

The SDL-FlexRay Signal Interface for the PSM

With SDL-MDD, the transformation from PIM to PSM is done on design level, using SDL as modeling language. By adding dedicated SDL signals addressing individual functionalities of diﬀerent hardware platforms, high-level interaction between the PSM and virtual platforms can be speciﬁed. Following this idea, the SDL-FlexRay signal interface deﬁnes FlexRay-speciﬁc SDL signals with appropriate SDL signal parameter types. Hence, the PSM can use and control the FlexRay hardware directly with these signals. In the following, we elaborate on a subset of signals deﬁned by the SDLFlexRay interface. Fig. 3 lists a subset of the outgoing signals and a data type used for the reconﬁguration of buﬀers. Further signals can be found in Sect. 5. Startup Signals. The SDL signal FLEXRAY_startup is used to set up a node for communication, and to integrate it into a FlexRay cluster. If the system runs on a coldstart node and there is no communication under way, the signal invokes the initial startup. Otherwise, the node synchronizes itself with the other nodes and joins the running cluster. FLEXRAY_startup has three parameters of type Boolean. The ﬁrst parameter indicates whether the node should send a wakeup pattern before it proceeds with its startup sequence. Receiving this pattern grants nodes in energy-saving mode the possibility to wake up and reintegrate into the cluster. If the second parameter is set, the node remains in single-slot mode after successful startup or integration. In this mode, a node uses only its key slot to send frames. The third parameter is relevant for coldstart nodes only. It determines whether the node is permitted to initiate a startup and thus to act as a leading coldstarter. Nodes using their key slot to send startup frames are called coldstarters, whilst nodes only

Integration of FlexRay into the SDL-Model-Driven Development Approach SIGNAL /*Boolean: true−> with WAKEUP, Boolean: singleSlotMode, Boolean: allowColdstart*/ FLEXRAY_startup(Boolean, Boolean, Boolean), /*Integer: buffer number, Octet_string: data*/ FLEXRAY_send(Integer, Octet_string), /*Integer: buffer number, Octet_string: payload with preamble and data*/ FLEXRAY_ppSend(Integer, Octet_string), /*Buffer: struct with configuration data*/ FLEXRAY_cfgBuffer(Buffer),

63

NEWTYPE Buffer STRUCT tx_mode TransmissionMode; generates_interrupts Boolean; msg_type MessageType; bff_type BufferType; connected2 Channels; cyc_code Int7; fid Int11; number Int7; segment SegmentType; payload_length Int7; data_pointer Int11 ENDNEWTYPE;

/*Boolean: true −> switch directly to config state*/ FLEXRAY_freeze(Boolean), /*Invokes transition from halt to config state*/ FLEXRAY_halt2Config, FLEXRAY_getCycleCount, FLEXRAY_getPOCstate, /*Outgoing signals */ SIGNALLIST Sdl2Flexray = FLEXRAY_startup, FLEXRAY_send, FLEXRAY_ppSend, FLEXRAY_cfgBuffer, FLEXRAY_freeze, FLEXRAY_halt2Config, FLEXRAY_getPOCstate, FLEXRAY_getCycleCount;

Fig. 3. Signals sent from the SDL system to the environment (left). Structure used for the reconﬁguration of the message buﬀers (right).

allowed to participate in a startup are called non-coldstarters. When the startup has ﬁnished, the SDL system receives the signal FLEXRAY_startupFinished from the virtual FlexRay environment. Send Signals. The SDL signal interface provides two signals to send messages via FlexRay: FLEXRAY_send and FLEXRAY_ppSend. Normal messages are sent using the former signal, while the latter is used to send messages with a payload containing a special preamble like network information or CAN-like message identiﬁers (see also [1]). The send and receive signals use Octet_strings as parameter for the payload of the FlexRay frame. This allows us to use standardized techniques like ASN.1 in conjunction with SDL [15] to encode, transmit and decode complex datatypes with little eﬀort. Both signals have an Integer parameter to select the associated message buﬀer of the CC. The second parameter is of type Octet_string and contains the data to be sent. By generating the signal FLEXRAY_sendFinished, the virtual FlexRay environment indicates the completion of the transmission. Its parameters provide information about the error status of the associated buﬀer and the cycle count number of the transmission. Receive Signals. If a message is received, the virtual FlexRay environment returns a signal FLEXRAY_recv to the SDL system, with ﬁve parameters. The ﬁrst parameter is of type Integer and holds the number of the receive buﬀer. The

64

T. Braun, R. Gotzhein, and M. Wiebel

second parameter contains the received payload of type Octet_string, followed by a Boolean-ﬂag set in case of an error and the number of the cycle count of this reception. Finally, the ﬁfth parameter gives more details in case of an error occurrence. Buﬀer Conﬁguration. Since the FlexRay controller needs a set of initial working buﬀers to be able to integrate a node into a cluster, it is necessary to provide some static conﬁguration parameters. This is done by specifying a so-called Controller Host Interface (CHI ) ﬁle, which is included during code generation. Our FlexRay interface also allows the reconﬁguration during runtime, as far as supported by the used communication controller. Therefore, the SDL interface provides a signal called FLEXRAY_cfgBuffer. It has one parameter of type Buffer containing a structure that holds the information needed for reconﬁguration (see Fig. 3). This structure Buffer encapsulates information about the intended transmission mode (single-shot or continuous), buﬀer type (send or receive), the frame id to be used for messages sent via this buﬀer and several other conﬁguration parameters. When the conﬁguration has ﬁnished or been aborted due to an error, the driver generates the signal FLEXRAY_cfgFinished. As the aforementioned ﬁnished -signals, it contains parameters with information about the success or failure of the invoked driver function. 4.2

The SDL-FlexRay Driver of the SDL Environment Framework

After the transformation of the PSM to the RIC, the conversion to the RSC is performed (see Sect. 2). If the PSM uses signals of the SDL-FlexRay signal interface, the SDL-FlexRay Driver of the SDL Environment Framework (SEnF) is automatically incorporated. It consists of functions handling incoming and outgoing signals, received interrupts, and interaction with the CC. As a result of diﬀerent execution speeds of the SDL system running on the host and the processes running on the CC, incoming signals and protocol-related information have to be temporarily buﬀered by the SDL-FlexRay Driver. Figure 4 shows the data structures of the driver. Arrays buﬀering data for the SDL system, such as buﬀerSendFinished, are colored white, while information for the CC are held in the arrays colored black (e.g. buﬀerSendPending). For every buﬀer used in the CC, we implemented a corresponding buﬀer in the driver. The buﬀered information is kept until the environment polls it for the generation of new signals or, respectively, the message buﬀers of the controller are ready to receive new information. This buﬀer architecture ensures the temporal decoupling of the FlexRay hardware, which has to satisfy hard real-time constraints, from the execution of the SDL-system on the host.

5

FlexRay Application Scenario

To demonstrate the beneﬁts and full operativeness of the SDL-FlexRay interface, we now present a functionally complex application scenario that we have

Integration of FlexRay into the SDL-Model-Driven Development Approach

65

% ! " # #

" !%#

" # $#

" # ! $#

$!#

Fig. 4. The SEnF part of the SDL-FlexRay interface embedded in the runtime environment (white: buﬀers to hold information for the SDL-System, black: buﬀers to hold information for the FlexRay controller)

executed on real FlexRay hardware. For this purpose, we have developed a circuit board called FlexBoard allowing us to connect Imote2 sensor nodes to a FlexRay cluster. The FlexBoard consists of a communication controller (CC), two bus drivers and additional circuits for power supply and power adjustment. By means of diﬀerent jumpers, it is possible to use this board in a star topology as well as in a bus topology. Via these jumpers, terminating resistors can be connected in parallel to the bus lines for each channel separately, as described in [16]. Figure 5 shows a fully assembled FlexBoard. As host, we use Imote2 nodes, which are plugged into the connectors on the upper side of the FlexBoard. We are using the MB88121C communication controller by Fujitsu Semiconductor, which is based on the Bosch E-Ray IP-Module and supports the FlexRay Protocol Speciﬁcation V2.1 Rev.A [1,13]. Imote2 and MB88121C are connected via SPI and additional interrupt and Fig. 5. FlexBoard with Imote2 control lines. The circuit diagram follows the recommendations given in [17]. As bus drivers, we use the AS8221D by Austriamicrosystems, which are compliant with the current FlexRay Electrical Layer Speciﬁcation [18,19].

66

T. Braun, R. Gotzhein, and M. Wiebel

On design level, we have speciﬁed an SDL system, consisting of two SDL processes communicating via FlexRay. On SDL level, we use the SDL-FlexRay signal interface (see Sect. 4.1), triggering a substantial subset of the FlexRay functionality. Fig. 6 shows an excerpt of the SDL speciﬁcation. First, the startup of the cluster is invoked. This is followed by the exchange of 50 ping messages via FlexRay, using dynamic slots. Next, the buﬀers are dynamically reconﬁgured, followed by another message exchange using static slots. This scenario is ﬁrst executed with both channels attached, to simulate the regular FlexRay behavior, and a second time with one of the channels disconnected, to examine the failure safety of the FlexRay protocol. From the SDL design, code is generated, automatically interfaced with the hardware platform (see Sect. 4.2) and deployed. Log messages of the system under execution show the expected operation. We have conﬁgured the CCs using Controller Host Interface (CHI) ﬁles with diﬀerent buﬀer conﬁgurations for each node. In these ﬁles, the number of static slots is set to 40 each with a length of 44 macroticks. The length of the dynamic segment is conﬁgured to 176 minislots, each consisting of 6 macroticks. The total length of the communication cycle is 3000 macroticks,5 which corresponds to 3 ms. If a frame is transferred in the dynamic segment, the minimal message length is two minislots, because of the used padding of the minislot mechanism (see Sect. 3.1). Accordingly, this leads to a maximum number of 88 dynamic slots in one communication cycle. Since a FlexRay cluster needs at least two coldstart nodes, both nodes were conﬁgured as coldstarters. The startup of the system is invoked by the signal FLEXRAY_startup. When the startup is completed, the driver generates the signal FLEXRAY_startupFinished. Receiving this signal, the sender immediately starts transmitting 50 Octet_strings of the format ".|..Nnnn " over the bus, where nnn represents the running number of the message. The initial buﬀer conﬁguration of the sender uses buﬀer 4 to transmit messages with frame ID 41 in the ﬁrst dynamic slot on channel A only. After 50 messages have been transmitted, the send buﬀer is reconﬁgured. From now on, it is connected to both channels (newConfig!connected2 := AB) and used to send frames with frame ID 10 (newConfig!fid := 10) in the static segment. Furthermore, the payload length is set to 10 two-byte-words in accordance with the conﬁguration of the payload length for the static segment. Followed by the reconﬁguration, 50 messages of the format "........|.......Nnnn " are sent over the bus. Finally, a log message displaying the total number of messages sent is created. The receiving node starts an internal timer after it has received the ﬁrst message. It waits for ﬁve seconds and generates an aggregated log message after the timer has expired. This log message is shown in Figure 8 and contains information about the received messages, e.g. the cycle number of the reception (Cnn) and the number of the buﬀer it has been assigned to (Bnn).6 Buﬀer 4 (normal) and 5 (FIFO) are conﬁgured for reception. In the ﬁrst run of the scenario, the 5 6

Note that this is also part of the conﬁguration and therefore scenario-speciﬁc. Every buﬀer is assigned a frame ID and thus a slot number. Messages with a matching ID are stored in or sent from the corresponding buﬀer.

Integration of FlexRay into the SDL-Model-Driven Development Approach

67

(% ') (% $% * +,-) (% .( ') (% ./ .%0 / *) (% .'1 '1 /

) (% "% /) (% 2 )

"

! #$

!

"

'$

% &

% &

$% 3, 4 $% ! $4 7

! /"%

$% +, $% 9-)

"7$

"% 5 & $ +,2# ) "% 5 +,) "% 5&0 +, &) "% 560 +,&) "% 5 $ +,/) "% 50 $ +,) "% 5$ +,-) "% 5&6 +,7) "% 5& +,$0&) "% 5 0 $# +,-) "% 5$ +,8)

"7

"7

:

!$#$ ./ .'1 .%0

!/#$ / '1

.'1

.'1 '1

(

'$

% &

'$

'

'$

;

'$

'

Fig. 6. Excerpt of the SDL system with a cluster startup, message sending and buﬀer reconﬁguration

68

T. Braun, R. Gotzhein, and M. Wiebel

! "

# $ ! "

Fig. 7. Conﬁguration of the message buﬀers. Buﬀer 4 starts sending with ID 41 (black arrow). After its reconﬁguration (grey) it sends with ID 10 (dashed arrow). Receiving buﬀers are outlined with dashes.

node receives 50 messages with the frame ID 41. Since there is no receive buﬀer associated with this ID, these messages are stored in the FIFO buﬀer, consisting of buﬀers 5, 6, and 7 (see Fig. 7). After the 50th message, in cycle 39, we reconﬁgure the send buﬀer. The next message is received in cycle 43 and stored in buﬀer 4. This delay of four cycles corresponds to 12 ms and is a result of the reconﬁguration process started on the CC and the SDL execution model. The last message in the log output states the total number (100) of received messages. In the following part of the log message, we see the results of the second run with channel A detached. Since frames with ID 41 are sent only over channel A, the ﬁrst 50 messages are not received. After reconﬁguration, the send buﬀer is connected to both channels and uses them for redundant transfer. This leads to the reception of the second 50 messages over channel B and therefore to a total number of 50 received messages as stated in the log. The possibility of redundant sending is one of the key features of FlexRay and enables the protocol to provide a high grade of failure safety. In scenarios where the host needs to send messages periodically in the same static slot,7 it is necessary that the clocks of the Imote and the FlexRay CC are synchronized. Otherwise, the periods of host and controller could deviate in a way that messages are created too late and their dedicated slot has passed before they are available for sending. The deviation results from the usage of diﬀerent oscillators driving the clocks of host and CC and the continuous 7

For example, consider data resulting from a periodic sampling.

Integration of FlexRay into the SDL-Model-Driven Development Approach

69

Fig. 8. Log messages of the receiving node

re-synchronisation of the CCs, which is part of FlexRay. To overcome these problems, we realized a function that matches the time on the Imotes with the clocks of the communication controllers. This way, we can keep the clock of the host and the CC synchronized with respect to the FlexRay protocol.

6

Conclusions and Outlook

In this paper, we have presented our solution for the integration of FlexRay into SDL-MDD, our model-driven development approach. At design level, we have deﬁned a comprehensive abstract signal interface enabling high-level interaction with virtual FlexRay environments, which can be applied to specify the platformspeciﬁc model (PSM). At implementation level, we have extended our tool chain

70

T. Braun, R. Gotzhein, and M. Wiebel

to support the automatic interfacing of SDL systems with FlexRay hardware. A functionally complex application scenario has demonstrated the beneﬁts and full operativeness of our solution. In practice, it has turned out that the manual coding of hardware interfaces, also called environment functions in the context of the toolset TAU, is a timeconsuming and error-prone task, with code that is diﬃcult to maintain and to extend. The results reported in this paper show that based on the abstract design, interfacing can be achieved automatically even for embedded systems and complex communication technologies such as FlexRay, thereby extending the scope of model-driven development. Thus, we expect a simular productivity gain as measured in [6] using our development approach. In previous work [20], we have shown that the same SDL models from which implementations are generated can be used for performance simulations. Furthermore, the same compiler is used to generate simulation code, which increases conﬁdence in simulation results. To extend this idea to FlexRay, we are currently devising a simulation model that is suﬃciently detailed to express real-time capabilities, conﬁgurations, communication cycles, and frame schedules. This will support architectural decisions about assignment of functionalities to ECUs such that all timing constraints are met early in the development process.

References 1. FlexRay Consortium. FlexRay Communication System Protocol Speciﬁcation V2.1 Rev.A. FlexRay Consortium (December 2005) 2. Kuhn, T., Gotzhein, R., Webel, C.: Model-Driven Development with SDL – Process, Tools, and Experiences. In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 83–97. Springer, Heidelberg (2006) 3. Gotzhein, R.: Model-driven with SDL – Improving the Quality of Networked Systems Development (Invited Paper). In: Proceedings of the 7th International Conference on New Technologies of Distributed Systems (NOTERE 2007), Marrakesh, Morocco, pp. 31–46 (2007) 4. International Telecommunication Union (ITU): ITU-T Recommendation Z.100: Speciﬁcation and Description Language, SDL (August 2002) 5. Kuhn, T.: Model Driven Development of MacZ – A QoS Medium Access Control Layer for Ambient Intelligence Systems. PhD thesis, University of Kaiserslautern (2009) 6. Naderlinger, A., Pletzer, J., Pree, W., Templ, J.: Model-Driven Development of FlexRay-Based Systems with the Timing Deﬁnition Language (TDL). In: 4th International ICSE Workshop on Software Engineering for Automotive Systems (2007) 7. preeTec GmbH: Product demos for TDL: Visual creator / TDL: VisualDistributor / TDL: VisualAnalyzer (2010), http://www.preetec.com/index.php?id=2 8. Xu, Y., Kang, H., Kim, Y., Cho, K., Chung, J.: Implementation of FlexRay CC and BG Protocols with Application to a Robot System. In: Arabnia, H.R., Deligiannidis, L. (eds.) MSV, pp. 232–237. CSREA Press (2008) 9. IBM: Rational SDL Suite (2011), http://www-01.ibm.com/software/awdtools/ sdlsuite/

Integration of FlexRay into the SDL-Model-Driven Development Approach

71

10. Fliege, I., Grammes, R., Weber, C.: ConTraST - A Conﬁgurable SDL Transpiler and Runtime Environment. In: Gotzhein, R., Reed, R. (eds.) SAM 2006. LNCS, vol. 4320, pp. 216–228. Springer, Heidelberg (2006) 11. FlexRay Consortium: FlexRay Requirements Speciﬁcation V2.1. FlexRay Consortium (December 2005) 12. Crossbow: Imote 2 Datasheet (2009), http://www.xbow.com/Products/Product_ pdf_files/Wireless_pdf/Imote2_Datasheet.pdf 13. Fujitsu Limited: FlexRay ASSP MB88121C, Preliminary Hardware Manual (2007) 14. Robert Bosch GmbH: E-Ray, FlexRay IP-Module, User’s Manual (November 2007) 15. International Telecommunication Union (ITU): ITU-T Recommendation: Programming Languages - SDL Combined with ASN.1 (SDL/ASN.1) (March 1995) 16. FlexRay Consortium: FlexRay Communication System Electrical Physical Layer Application Notes V2.1 Rev. B. FlexRay Consortium (November 2006) 17. Fujitsu Semiconductor: FlexRay ASSAP MB88121/MB88121A/MB88121B/ MB88121C Preliminary Data Sheet, Revision FME-MB88121-1.45E (September 2008) 18. FlexRay Consortium: FlexRay Communication System Electrical Physical Layer Speciﬁcation V2.1 Rev.B. FlexRay Consortium (November 2006) 19. Austriamicrosystems: AS8221D FlexRay Standard Transceiver. Revision 17732005-10a, http://www.austriamicrosystems.com/eng/content/download/1214/ 7001/file/AS8221D_ObjectiveDataSheet_17732-005-10a.pdf 20. Kuhn, T., Geraldy, A., Gotzhein, R., Rothländer, F.: ns+SDL – The Network Simulator for SDL Systems. In: Prinz, A., Reed, R., Reed, J. (eds.) SDL 2005. LNCS, vol. 3530, pp. 103–116. Springer, Heidelberg (2005)

Design and Development of a CPU Scheduler Simulator for Educational Purposes Using SDL Manuel Rodr´ıguez-Cayetano Department of Signal Theory and Telematics Engineering University of Valladolid, ES-47011 Valladolid, Spain [email protected]

Abstract. This paper presents the design and development of a CPU scheduler simulator using SDL. This simulator enables us to study the behavior of one level and multilevel queue scheduling algorithms (including the real-time ones), and to obtain performance statistics for algorithm evaluation. In addition, a multi-platform graphical user interface, based on the Tcl/Tk language, has been developed to simplify the simulator use. The paper also presents our experiences in using SDL for the speciﬁcation of CPU scheduling algorithms for educational purposes. Keywords: Operating systems, CPU scheduling, simulation, GUI, Tcl/Tk.

1

Introduction

Scheduling is a fundamental operating system function. Almost all computer resources are scheduled before use, and the processor (CPU) is one of the primary computer resources. CPU scheduling is the basis of multiprogrammed operating systems. By switching the CPU among processes, the operating system can make the computer more productive, [9]. CPU scheduling deals with the problem of deciding which of the processes ready to execute is going to be executed (the CPU is allocated to it). There are several CPU scheduling algorithms. The main diﬀerence among them is the criterion used for selecting the process to be executed. Diﬀerent CPU scheduling algorithms have diﬀerent properties and may favor one class of processes over another. In choosing which algorithm to use in a particular situation, we must evaluate the behavior of the various algorithms. One of the evaluation methods is simulation. Simulations involve programming a model of the computer system. The design, coding and debugging of a simulator can be a major task. Thus, appropriate speciﬁcation techniques, like the Speciﬁcation and Description Language (SDL, [6]), should be used to simplify the development and testing of the simulator. This paper presents the main aspects of the design and development of a CPU scheduler simulator for educational purposes that has been speciﬁed using SDL. The rest of the paper is organized as follows. Section 2 gives an overview of the CPU scheduling concepts and algorithms. Section 3 is devoted to the F.A. Kraemer and P. Herrmann (Eds.): SAM 2010, LNCS 6598, pp. 72–90, 2011. c Springer-Verlag Berlin Heidelberg 2011

Design and Development of a CPU Scheduler Simulator

73

development of the CPU scheduler simulator (requirements, internal structure and behavior). In Sect. 4 we discuss some aspects of the graphical user interface developed. Finally, in Sect. 5 we discuss the conclusions of the paper.

2 2.1

CPU Scheduling Overview

CPU scheduling deals with the problem of deciding which of the processes in the ready queue (processes ready to execute) is going to be executed (the CPU is allocated to it). There are several CPU scheduling algorithms. The main diﬀerence among them is the criterion used for selecting the process to be executed: process with the smallest arrival time, smallest CPU-burst length, shortest remaining execution time, earliest deadline (for real-time processes, where schedulability should be guaranteed), etc. Algorithms using a single criterion are appropriate for situations in which processes belong to a single group (all processes are equivalent with respect to the CPU scheduling). Another class of scheduling algorithms has been created for situations in which processes are easily classiﬁed into diﬀerent groups (because they have diﬀerent response time requirements and so might have diﬀerent scheduling needs, for example). A multilevel queue scheduling algorithm partitions the ready queue into several ready queues, and each process is associated to the same ready queue during its life in the system. Each queue has its own algorithm, and the scheduling among the queues is commonly implemented as a ﬁxed-priority preemptive scheduling. A detailed description of CPU scheduling algorithms for non real-time systems can be found in [9,10,11] and for real-time systems in [2]. Diﬀerent CPU scheduling algorithms have diﬀerent properties and may favor one class of processes over another. These properties should be used for choosing the appropriate algorithm for a particular situation. Many performance evaluation parameters have been suggested for comparing CPU scheduling algorithms. These evaluation parameters include CPU utilization, throughput, turnaround time, waiting time and response time (see [9] and [2] for a detailed deﬁnition). The criteria to be used in selecting an algorithm are often deﬁned in terms of performance evaluation parameters. Once the selection criteria have been deﬁned, algorithms under study have to be evaluated. One of the evaluation methods is simulation. Simulations involve programming a model of the computer system (the resulting program is called simulator ). In this model, software data structures represent the main components of the system (CPU, arrival queue, ready queue, etc.). The simulator has a variable representing a clock; as this variable is increased, the simulator modiﬁes the system state to reﬂect the activities of the devices, the processes and the scheduler. As the simulation executes, statistics that indicate algorithm performance are gathered and printed.

74

M. Rodr´ıguez-Cayetano

The design coding and debugging of a simulator can be a major task. Thus, appropriate speciﬁcation techniques, like SDL, should be used to simplify development and testing of this software. 2.2

Existing Simulators

Several CPU scheduling simulators have been previously developed for CPU scheduling algorithm evaluation. Among them we can ﬁnd CPU Scheduling Simulator, [3], CPU Scheduler Application, [14], Process Scheduling Simulator, [8] or MOSS Scheduling Simulator, [7]. All of them (except for MOSS Scheduling Simulator ) can obtain the main per process (waiting time, response time, turnaround time, etc.) and global performance evaluation parameters (mean waiting time, maximum response time, mean turnaround time, etc.). Process Scheduling Simulator is also capable of plotting a Gantt chart showing the temporal ordering of the main simulation events. The main shortcoming of these simulators is that real-time and multilevel queue algorithms are not supported. Furthermore, in most of them the characteristics of the processes can not be deﬁned using deterministic values (used for testing special process workloads, for example loads with several arrivals at the same time or arrivals during a context switch). They have to be speciﬁed using random values obtained from a statistical distribution. These shortcomings have lead to the development of a CPU scheduler simulator speciﬁed in SDL (sdlCPUSched). The main aspects of this simulator will be described in the following sections.

3 3.1

The SDL CPU Scheduler Simulator Simulator Requirements

Considering the shortcomings of the simulators analyzed in the previous section, the main requirements for the SDL CPU scheduler simulator (sdlCPUSched) are the following: – simulator for educational purposes, mainly used for behavior and performance analysis of CPU scheduling algorithms – support for non real-time algorithms: ﬁrst come ﬁrst served (FCFS), shortest job ﬁrst (SJF), shortest remaining time ﬁrst (SRTF), round robin (RR) and priority based (priorities) – support for real-time algorithms: Rate Monotonic Scheduling (RMS) and early deadline ﬁrst (EDF) – support for multilevel queue algorithms, where the number of queues, queue algorithm and queue priority are conﬁgurable – generation of Gantt chart of process events during simulation – step by step or continuous simulation

Design and Development of a CPU Scheduler Simulator

75

Furthermore, to simplify the development of the simulator, some assumptions have been made: every process has only one CPU burst and zero input/output bursts, and all the processes are independent (process properties like arrival time and CPU burst time do not depend on properties of other processes). Considering these assumptions, a process is deﬁned by the following information: – – – – –

arrival time CPU burst duration process priority (only for priority based algorithms) process period (only for real-time algorithms for periodic processes) identiﬁer of the ready queue where the process is initially placed (0 if a single queue algorithm is used)

The simulator developed is a discrete-event simulator in which the operation of a system is represented as a chronological sequence of events. Each event occurs at an instant in time and marks a change of state in the system, represented by changes in the simulator variables. The clock always moves forward to the start time of the next event as the simulation proceeds. The simulator behavior will be explained in the following sections. 3.2

Simulator Behavior Overview

In this section the interactions between the simulator and its environment are summarized. A signal-based communication has been selected for the interactions between the SDL system and its environment, since these interactions are mainly asynchronous. Synchronous interaction is only required during conﬁguration of a simulation. Interactions during the conﬁguration of a simulation have to be synchronous because the simulator must conﬁrm to its environment if every conﬁguration parameter is correct or not. For example, arrival times of processes must be greater or equal to zero. If a conﬁguration parameter is incorrect, the conﬁguration of the simulation is aborted and the simulator returns to the initial state (no simulation is conﬁgured). Furthermore, the format of data exchanged between the SDL system and its environment does not depend on the type of communication used (signal-based or remote procedure-based) because a remote procedure call is modeled by an exchange of implicitly deﬁned signals. The input signals of the SDL system are used for simulation conﬁguration (process parameters, context switch times, algorithm to be simulated and its parameters) and for simulation control (start, stop or abort a simulation, etc.) The signals output to the environment are used for notifying conﬁguration or simulation errors, performance statistics calculated at the end of the simulation and, if verbose mode is selected, for notifying events that occur during the simulation (a new process has arrived, a process is selected for execution, etc.) and the contents of the simulator queues. These signals are exchanged between the SDL system and its environment (the Graphical User Interface, GUI) using two TCP ports: a ﬁxed-number port

76

M. Rodr´ıguez-Cayetano

created by the SDL system for the incoming signals and another one used for the outgoing signals. TCP communications are managed by the TCP/IP communications module of Telelogic SDL Suite 6.3, [4], included in the executable program generated from the SDL system speciﬁcation. This program runs continuously, listening for requests from the user interfaces of diﬀerent users. All the system output signals include as parameters the IP address and TCP listening port of the client user interface (this information is needed for the signal routing function of the program). The interactions allowed between the simulator and its environment are as follows. After starting, the simulator is waiting for new simulations to be requested. Interactions relating to conﬁguration of a new simulation can be seen in Fig. 1 for a scenario without errors (all the scenarios are described using the Message Sequence Charts notation, [5]). A new simulation is requested through newScheduler signal, which includes as parameters the IP address and TCP port where the client of sdlCPUSched is listening for responses, and the language selected for messages (currently English or Spanish). After receiving the conﬁrmation for this request (which includes the simulation identiﬁer to be used in the rest of the input signals of this simulation), the client has to select the algorithm to be simulated with the signal simulationConfig c and if the step-by-step and verbose modes have to be selected or not. If the algorithm is multiqueue, the simulator will wait for one or more queueConfig c signals for specifying the parameters of each queue: single queue algorithm and queue priority (used also as queue identiﬁer). endQueueConfig c signal is used to indicate end of queues conﬁguration. If the algorithm is not multiqueue or if the endQueueConfig c signal is received, the simulator responds with a readySignal to conﬁrm the conﬁguration of queue(s). After that, context save and load times are speciﬁed (signal contextTimes c) and conﬁrmed by the simulator. After this conﬁrmation has been sent the queues of the system are conﬁgured and the simulator is ready to receive parameters relating to the processes of the workload. This scenario is shown in Fig. 2. Each process parameter is speciﬁed by a processData c signal (and conﬁrmed with a readySignal one). End of process conﬁguration is indicated with a dataEnd c signal. After the process conﬁguration phase has been ﬁnished, the simulator is ready to start the simulation. This scenario (for a continuous simulation) is shown in Fig. 3. During simulation (and if verbose mode has been selected in the conﬁguration phase) the simulator sends to the environment signals of type sendList with the contents of every queue modiﬁed by a simulation event, and a printEvent signal with event details (kind of event, process identiﬁer and period of the process involved). Simulation end is notiﬁed by the simulationEnd signal, followed by processStatistic signals containing values of per-process statistics, globalStatistic signals with values of global statistics of the process workload and a schedulerEnd signal.

Design and Development of a CPU Scheduler Simulator

MSC CPUSchedulerOverview−configSim environment

CPUScheduler

initial newScheduler (IPAddress, port, language)

schedulerReady (IP, port, simId)

alt

1

simulationConfig_c (MultiQueue, verboseMode, stepByStepMode, simId)

2

loop <1,numberOfQueues> queueConfig_c (algorithm, queuePriority, simId)

3

opt extraAlgorithmConfig

3 2 endQueueConfig_c (simId)

1

simulationConfig_c (NonMultiqueueAlg, verboseMode, stepByStepMode, simId) 2

opt extraAlgorithmConfig

2 1 readySignal (IP, port, clock, code, msg) contextTimes_c (saveTime, loadTime, simId)

readySignal (IP, port, clock, code, msg)

simulationConfigured

Fig. 1. sdlCPUSched simulation conﬁguration scenario

77

78

M. Rodr´ıguez-Cayetano

MSC CPUSchedulerOverview−configProcess environment

CPUScheduler

simulationConfigured 1

loop <1,numberOfProcesses> processData_c (arrivalTime, CPUBurstDuration, priorityOrPeriod, QueueId, simId) readySignal (IP, port, clock, code, msg)

1

dataEnd_c (simId)

readySignal (IP, port, clock, code, msg) simulationReadyToStart

Fig. 2. sdlCPUSched process conﬁguration scenario

3.3

Simulator Structure and Detailed Behavior

The SDL system modeling the CPU scheduler consists of one block of type CPUSchedulerBlockType whose description can be seen in Fig. 4. This block consists of the processes in charge of the simulation tasks: control, masterScheduler and slaveScheduler. This structure has been selected for several reasons: – To keep intra-queue scheduling functions (responsible for selecting a process from a ready queue) apart from inter-queue scheduling functions (responsible for selecting a queue among all the ready-queues for activating it): for this reason, a MasterSchedulerType process type (for inter-queue scheduling) and a SlaveSchedulerType process type (for intra-queue scheduling) have been developed. – To minimize the amount of code not automatically generated from the SDL speciﬁcation: To satisfy the requirement of multiuser simultaneous access to the simulator, several options can be considered: 1. A simulator only runs a simulation of one user (one simulator program instance for every user): in this case, every simulator program has to use a diﬀerent TCP port number and that number has to be sent to its connected GUI, using auxiliary ﬁles or starting the GUI from the simulator with extra calling parameters (these methods require including c-language code, that could be non-portable, in SDL tasks). 2. A simulator can run several simulations: in this case, the simulator uses a well-known TCP port number for receiving input signals, that are

Design and Development of a CPU Scheduler Simulator

79

MSC CPUSchedulerOverview_running environment

CPUScheduler

simulationReadyToStart

opt

1

loop <1,numberOfEvents>

2 3

loop<0,numberOfListsModified> sendList (IP, port, clock, listyKind, list, listId)

3

printEvent (IP,port, clock, processId, processPeriodNum, enventType, msg) 2 1 simulationEnd (IP, port, clock) sendList (IP, port, clock, listyKind, list,listId) 1

loop <1, numberOfProcesses> loop <1, numberOfProcessStatistics>

processStatistic

(IP, port, processId, processPeriodNum, statisticName, statisticMsg, value)

2 2 1 1

loop <1, globalStatistics> globalStatistic (IP, port, statisticName, statisticMsg, value)

1 schedulerEnd_c (IP, port)

Fig. 3. sdlCPUSched simulation running scenario

routed by a control process to the processes in charge of simulation (masterScheduler processes, one per simultaneous running simulation). This is the selected option because it does not require extra coding. The main functions of the processes included in the CPUSchedulerBlockType block are described in the following sections. The control Process. The control process is responsible for creating the masterScheduler process in charge of a simulation requested by one user through its user interface, and for dispatching the signals coming from diﬀerent user interfaces to the corresponding masterScheduler processes.

80

M. Rodr´ıguez-Cayetano

block type CPUSchedulerBlockType

1(1)

ControlType

Control_Env_R

control: ControlType ControlType_G

(control_input_sl)

ControlType_G schedulerEnd

schedulerReady, errorSignal, clientIdSignal, schedulerEnd_c

ctrl_scheduler_G schedulerReady, errorSignal, clientIdSignal, schedulerEnd_c, (output_sl)

(control_input_sl)

control_scheduler_R (scheduler_input_sl)

Master_Env_R (output_sl)

Master_Control_G masterScheduler(0,): MasterSchedulerType Master_Env_G master_slave_G

sendList, errorSignal

algorithmEnd, deactivateQueueACK

master_slave_R

slave_env_R

MasterSchedulerType

startAlgorithm, abortAlgorithm, getList, quantumSignal, apropiative, finaltime, activateQueue, procedure updateReadyList

slave_master_G slave_env_G slaveScheduler(0,): SlaveSchedulerType

Synonym CPUSchedulerBlockType.sbt_Id charstring = ’$Id: CPUSchedulerBlockType.sbt,v 1.2 2010/03/11 18:36:02 manrod Exp $’;

Fig. 4. CPUSchedulerBlockType block type

When the control process receives a request to start a new simulation (newScheduler signal) it creates a new masterScheduler process and a new client identiﬁer (clientId ) for the new simulation. The control process also stores the IP address and port of the user interface requesting the simulation, the PId of the new masterScheduler process and the clientId in a new entry in the table of clients data (clientsData table). The request is answered with a signal (schedulerReady) which includes the clientId (used as parameter for the next input signals). Subsequent input signals, used for the conﬁguration and control of the simulation, are forwarded to the corresponding masterScheduler process using the value of the clientId signal parameter and the information of the clientsData table. The masterScheduler Process. A masterScheduler process handles the functionality associated with simulation conﬁguration, inter-queues algorithm and access control of the variables shared by the slaveScheduler processes.

Design and Development of a CPU Scheduler Simulator

81

Initially this process receives signals with simulation conﬁguration and updates simulator variables as a result. It also creates slaveScheduler processes, one for each ready queue (there will be several ready queues if multilevel queue algorithm is selected, only one otherwise). After ﬁnishing conﬁguration the process enters the simulationRunning state. In this state it executes the inter-queue algorithm (a preemptive priority based one). This algorithm selects the maximum priority non-empty ready queue and activates the corresponding slaveScheduler process. A slaveScheduler process implements a simple (non-multiqueue) scheduling algorithm on a ready queue. The inter-queue algorithm is activated when a process arrives to a ready queue or when a process terminates and its ready queue is empty. A masterScheduler process is also in charge of controlling the access to variables shared with its oﬀspring slaveScheduler processes (arrival queue, terminated queue, idle CPU time, clock, etc.). Shared variables are deﬁned in the masterScheduler process and accessed by using exported procedures (findArrivals, execProcess, interruptProcess, terminateProcess, etc.) called by slaveScheduler processes. When the simulation has ﬁnished (all the slaveScheduler processes have notiﬁed their termination to the master) the masterScheduler calculates the simulation statistics (per-process and global), sends the results to the SDL system environment (using signals processStatistic and globalStatistic) and terminates. The slaveScheduler Process. The main functionality of a slaveScheduler process is to simulate a simple (one ready queue) scheduling algorithm. This algorithm is in charge of ﬁnding process arrivals (storing every arrived process in a ready queue), selecting a process from a ready queue to be executed, interrupting a process and returning it to a ready queue (for example, if a process of greater priority arrives) and terminating a process when its CPU burst is completed (storing the process in the terminated queue). Some of these tasks are executed in an algorithm-independent way, and are described in the genericAlgorithm procedure; the others are described in algorithm speciﬁc procedures (fcfs, sjf, srtf, rr, priorities, rms and edf ). The appropriate algorithm speciﬁc procedure is called from the slaveScheduler process depending on the simulation conﬁguration. The genericAlgorithm Procedure. The speciﬁcation of the genericAlgorithm procedure can be seen in Fig. 5. This procedure starts in the deactivated state in which it only can receive requests to the updateReadyList procedure (invoked from the masterScheduler process to update the ready queue associated to this algorithm with new process arrivals) or the signal activateQueue that activates the queue managed by the algorithm. After this activation, the procedure enters a new state. This state is checkingExec if the ready queue is not empty and there is no process arrival at the current time; otherwise, the state is checkingArrivals. In the checkingArrivals state the findArrivals procedure (exported by the masterScheduler process) is called to update the ready queues with the processes

82

M. Rodr´ıguez-Cayetano procedure genericAlgorithm ;FPAR in/out readyList listType, in readyListId Integer, in/out runningProcess nodeData, in/out processInExec Boolean, in/out nextArrivalT Real, in/out clock Real, contextSaveT, contextLoadT Real, verboseMode Boolean, language languageType, clientData clientDataStruct; RETURNS endCauseType; maxPriArrivalQueueId := call findMaxPriNonEmptyQueue to PARENT

DCL aborting Boolean := False, abortCause endCauseType, auxNode nodeData, algActive Boolean := False, maxPriArrivalQueueId Integer := 0;

1(2) virtual

*(deactivated)

deactivated

procedure updateReadyList

checkingArrivals procedure updateReadyList

activateQueue( clock, nextArrivalT)

aborting = False − call emptyArrivalList to PARENT

False

False

True

algActive := True

True ENDOK

auxNode:= call getArrivalListHead to PARENT

(maxPriArrivalQueueId /= readyListId)

False

False

(not (call emptyList( readyList))) and (not (nextArrivalT = clock)) True

updateIdleCPUT (auxNode!arrivalTime −clock) to PARENT

processInExec checkingArrivals

True

checkingExec

clock := auxNode!arrivalTime *

clock := auxNode!arrivalTime findArrivals(verboseMode, aborting, readyList, readyListId, mkstring(runningProcess), clock, nextArrivalT, algActive, language, clientData) to PARENT

findArrivals(verboseMode, aborting, readyList, readyListId, Empty, clock, nextArrivalT, algActive, language, clientData) to PARENT

abortAlgorithm( abortCause)

aborting=True

abortCause

ERR

checkingActive algActive := False checkingExec

interruptProcess( verboseMode, aborting, readyList, readyListId, runningProcess, processInExec, clock, contextSaveT, nextArrivalT, algActive, False,language, clientData) to PARENT

not(aborting) and not(algActive)

not(aborting) and algActive

processInExec

checkingExec

aborting=True

true false

ERR deactivateQueueACK( clock)

deactivated

DCL genericAlgorithm.spd_Id charstring := ’ $Id: genericAlgorithm.spd,v 1.7 2010/09/07 09:32:45 manrod Exp $’;

procedure genericAlgorithm ;FPAR in/out readyList listType, in readyListId Integer, in/out runningProcess nodeData, in/out processInExec Boolean, in/out nextArrivalT Real, in/out clock Real, contextSaveT, contextLoadT Real, verboseMode Boolean, language languageType, clientData clientDataStruct; RETURNS endCauseType;

2(2) executingProc

interruptingProc

aborting = false

aborting = false

execProcess(verboseMode, aborting, readyList, readyListId, runningProcess, processInExec, clock, contextLoadT, nextArrivalT, algActive, language, clientData) to PARENT

interruptProcess(verboseMode, aborting, readyList, readyListId, runningProcess, processInExec, clock, contextSaveT, nextArrivalT, algActive, True, language, clientData) to PARENT

checkingActive

checkingActive

Fig. 5. genericAlgorithm procedure

Design and Development of a CPU Scheduler Simulator

83

arriving at the current clock time. If a process arrives at a queue of greater priority than the queue associated to the slaveScheduler process executing this genericAlgorithm procedure, this queue is deactivated (new state is deactivated ), and the running process, if any, is interrupted. The algorithm ends when the arrival and ready queues are empty. In every state of the procedure, the input of an abortAlgorithm signal or the change of the variable aborting to the true value triggers the procedure end, returning a false value (indicating that the simulation has been aborted so no statistics should be calculated). Tasks relating to the checkingExec state are algorithm speciﬁc, and are described in the algorithm speciﬁc procedures. Algorithm Specific Procedures. Algorithm speciﬁc procedures are in charge of tasks speciﬁc to the simple algorithm selected (tasks included in the transition from the checkingExec state to the checkingArrivals or executingProc states). These procedures inherit the speciﬁcation of the algorithm-independent tasks from the genericAlgorithm procedure. An example of this kind of procedures is fcfs, whose speciﬁcation can be seen in Fig. 6. If the procedure is in the checkingExec state and aborting of the simulation has not been selected, the procedure checks if a process is running in the CPU. If not, the process at the head of the ready queue is selected for execution by

procedure fcfs

1(1)

inherits genericAlgorithm;

DCL fcfs.spd_Id charstring := ’ $Id: fcfs.spd,v 1.8 2010/11/10 20:09:17 manrod Exp $’;

checkingExec

aborting=False

False processInExec True

((call precCompare( runningProcess! remainingExecT+clock, nextArrivalT)) /= LESS) AND (NOT(nextArrivalT = NOMOREPROCESSES))

True decrRemainingExecT( runningProcess, nextArrivalT−clock) to PARENT

executingProc

False

terminateProcess( verboseMode, aborting, runningProcess, processInExec, clock, language, clientData) to PARENT

True

checkingArrivals

call emptyList( readyList) False

Fig. 6. fcfs procedure

84

M. Rodr´ıguez-Cayetano

calling the execProcess procedure (exported by the masterScheduler process). After that, the procedure checks which is the next event: process termination or new process arrival. In case of a process termination, terminateProcess procedure is called (moving the terminated process from the ready queue to the terminated queue) and the algorithm tries to execute another process (if the ready queue is not empty) or to ﬁnd another arrival. In case a new arrival occurs before the termination of the running process, the remaining execution time of this process is updated (because the clock is going to be updated to the time of the next arrival) and the procedure enters the checkingArrivals state. Transitions from the checkingArrivals state are inherited from the genericAlgorithm procedure. 3.4

Simulator Testing and Implementation

For testing the correct behavior of the simulator the facilities for simulating SDL systems of Telelogic SDL suite (simulator kernel and simulator user interface) have been used. Every single queue algorithm has been tested using two workloads: One with events occurring at diﬀerent times and one with several events occurring at the same time, and with process arrivals during context switches (the more complex scenario). After all these tests have been passed, these two kinds of workloads have also been used with a two-queue and a three-queue conﬁguration (with a real-time algorithm in one queue and non real-time algorithm in the others). For the implementation of the simulator a thread based integration has been used (every process of the SDL system is mapped to a thread of the operating system). The simulator implementation with the graphical user interface explained in the next section has been tested in several practical lessons of operating systems with 20 simultaneous users. The developed application has been mainly used for showing the behavior of scheduling algorithms in diﬀerent scenarios to students, and for studying the suitability of every algorithm for scheduling diﬀerent kinds of processes. In this study we have considered scheduling requirements of every kind of processes, described by performance evaluation parameters, and the degree of fulﬁllment of these requirements by the diﬀerent algorithms. For example, CPU intensive processes do not have strict temporal requirements, but a low value for the mean waiting time of a workload of this kind of processes is desirable. Diﬀerent algorithms have been used for scheduling this type of workloads, obtaining the mean waiting time for every algorithm and workload studied, and analyzing its variation with respect to processes and simulation parameters (number of processes, arrival times, CPU-burst lengths, save and load context switch times, etc.). This way, some conclusions can be drawn: A preemptive algorithm (like SRTF) usually obtains lower values for the mean waiting time than a non-preemptive one (like SJF or FCFS), but only if save and load context times are not too high.

Design and Development of a CPU Scheduler Simulator

4

85

The CPU Scheduler Simulator Graphical User Interface

The executable program generated from the SDL speciﬁcation using Telelogic SDL suite does not include a user interface, but only an interface based on an ASCII text encoding of SDL signals exchanged with the environment, and accessible through a TCP port. A graphical interface (tkCPUSched ) has been developed to simplify the access to the simulator functionalities. This interface has been developed with Tcl/Tk [1], an interpreted language that provides rapid development of crossplatform graphical user interfaces. To simplify the design of the module in charge of communications with the SDL system, an approach based on an automatic generation of a parser (syntactical analyzer) and a lexical analyzer for received signals has been used. The basis of this approach is the deﬁnition of a grammar appropriate for the format used for representing SDL signals exchanged through the SDL system environment (Telelogic SDL suite ASCII encoding). This grammar includes the description of lexical tokens (a natural number, a string, etc.) and the rules to combine them (“a signal consists of a signal name and a list of parameters between {}”, for example). Using this grammar a parser and a lexical analyzer generator are used for obtaining signal parsing functions. fickle program, [13], has been used as the lexical analyzer generator and taccle, [12], as the parser generator. Both programs are described in Tcl and generate Tcl code.

Fig. 7. tkCPUSched main window

86

M. Rodr´ıguez-Cayetano

The main tasks of the graphical user interface (GUI) are the translation of user requests for conﬁguration and execution control of a simulation into signals sent to the SDL system, and the translation of signals coming from the SDL system relating to the simulation events into a human readable format. The main window of the GUI can be seen in Fig. 7. This window includes several frames: – simulation parameters: for specifying the algorithm to be simulated, execution mode (step-by-step or continuous) and verbose mode (if activated all simulation events are shown) – statistics: shows the global statistics for the process workload and algorithm selected – simulator control: includes the buttons to control the simulation execution (next step for a step-by-step simulation, continue simulation, break or abort a running simulation) – events: shows simulation events (only in verbose mode), which include the event time, process number, period number and event speciﬁc message – data ﬁle loaded: shows the name of the ﬁle that contains the workload process properties to be simulated. When the simulation starts, a new window with the system queues status is opened. This window can be seen in Fig. 8. Every queue contains zero or more processes. There are three types of queues: an arrival queue (containing processes of the workload that still have not arrived to the system), ready queues (containing processes ready to run and waiting for allocation of the CPU), and a terminated queue (containing processes that have completed their execution). The process running and the clock value are also shown. When a process in a queue is selected with the mouse a new window is opened, showing process speciﬁc parameters (arrival time, burst time, total waiting time, etc.) This interface also provides some useful additional functionalities, like storing the simulation events and performance statistics (global and per process) in a ﬁle,

Fig. 8. tkCPUSched system queues window

Design and Development of a CPU Scheduler Simulator

87

Fig. 9. tkCPUSched Gantt chart window

and the automatic generation of the Gantt chart of a simulation from its events (that can be saved in a encapsulated postscript ﬁle). An example of a Gantt chart plotted during the simulation can be seen in Fig. 9. This ﬁgure shows diﬀerent events: arrival, interruption (Int.) and end of processes, and process context save start (CSS), context save end (CSE), context load start (CLS) and context load end (CLE).

5

Concluding Remarks and Future Work

In this paper we have described the design and development of a CPU scheduling simulator using SDL. The use of this language for the speciﬁcation of the simulator instead of developing it using a programming language has several advantages. First, an SDL speciﬁcation of the behavior of a CPU scheduler algorithm is easier to understand than a description using a programming language: a graphical syntax is more expressive than a textual one, and an SDL speciﬁcation does not have to include low-level details usually required in a programming language. Moreover, ﬂow charts are usually used to describe algorithm or protocol behavior, and these charts can be easily translated into a high-level SDL speciﬁcation that can be turned into a complete speciﬁcation. In fact, a simpliﬁed version of the SDL speciﬁcation of the FCFS algorithm, with a simpler structure but the same behavior than the version used in the simulator, has been used to illustrate its main behavior to students, and as a starting point for them to develop more complex algorithms. The aim of this

88

M. Rodr´ıguez-Cayetano

simpliﬁed version is to show an overview of the algorithm behavior. Due to this fact, the behavior is described in one diagram, without using object-oriented concepts like inheritance or virtual and redeﬁned types. These concepts are useful to obtain well-structured and reusable speciﬁcations, but their use produces speciﬁcations based on several diagrams, more diﬃcult to interpret by students. In our experience, the use of SDL for the speciﬁcation of scheduling algorithms helps students to understand how algorithms work internally, as the speciﬁcation describes in detail the algorithm behavior in every possible scenario. This speciﬁcation is formal unlike natural language based speciﬁcations (usually used in operating systems text books), and it is simpler than a programming language based equivalent speciﬁcation. Second, development and testing of a concurrent application (like the sdlCPUScheduler simulator) is simpler using SDL than using a general-purpose programming language: – Process communication mechanisms are included in SDL (signal or remote procedures); otherwise, in general purpose programming languages we have to use ad-hoc methods that require extra coding, methods based on external libraries, or methods based on threads and shared variables (methods that are error-prone and diﬃcult to test). – Interactions allowed among processes are explicitly shown in SDL diagrams (channels connecting processes, signals that can be exchanged using each channel, etc.), but there is no explicit information about these interactions if a programming language is used (only send or receive primitives or access to shared variables, which are indistinguishable from non-shared variable access, are shown). This fact makes it more diﬃcult to understand and debug a programming language source code than the equivalent SDL speciﬁcation. With regard to the experience of using SDL, one of the problems we have found during the development with SDL is the routing of output signals when a signal destination is not speciﬁed and several destinations are possible. In this case, the signal will be received by an arbitrary instance of a process instance set. This instance set is arbitrarily chosen among instance sets which can be reached by the communication paths able to convey the signal instance. This feature is useful to simplify the speciﬁcation of a system which includes several equivalent processes (any of them can execute the tasks relating to the input of the signal) but may lead to speciﬁcation errors in many other kinds of systems (where the signal must be sent to an speciﬁc process of an instance set). We think that semantic analyzers of SDL tools should issue a warning when output without explicit destination is used and several destinations for the signal are possible. This way, some errors that otherwise have to be detected by simulation or testing, can be avoided. The other main problem was related to the correct use of exported procedures to avoid deadlocks. Exported procedures are an SDL feature useful to simplify the speciﬁcation of synchronous communication among processes. In our development, they have been mainly used to ensure mutual-exclusion in the access to shared variables: these variables are accessed by processes using procedures

Design and Development of a CPU Scheduler Simulator

89

exported by the process which owns the variables. To avoid deadlocks, an exported procedure should not call procedures exported by other processes (because these in turn can call the ﬁrst procedure). Furthermore, some rules have to be followed for calls among procedures belonging to the same process: all non-exported procedures that call an exported procedure should be speciﬁed at the process (or process type) level. If non-exported procedures are deﬁned at an upper level, the exported procedure deﬁnition (speciﬁed at process or process type level) will not be visible for them, and a call to the local exported procedure by a non-exported local procedure will be considered a remote call (assuming that the remote deﬁnition is speciﬁed at an upper level). With regard to the developed application, the simulator is capable of simulating the behavior of simple scheduling algorithms (appropriate for one class of processes) and multilevel queue algorithms (appropriate for workloads with processes of diﬀerent scheduling requirements). The simulator shows events relating to process scheduling during simulation and calculates per-process and global performance statistics. All the information is presented in a human-readable format using a graphical user interface. Concurrent access to the simulator from several user interfaces, showing results of diﬀerent simulations, is also supported. The graphical user interface has been developed with Tcl/Tk, an interpreted language that provides rapid development of cross-platform graphical user interfaces. To simplify the functions required for SDL signal parsing, parser and lexical analyzer generators have been used, based on a grammar deﬁnition of the signal encoding used. This approach has the advantage that changes in the encoding used for the signals exchanged with the SDL system environment only involve changes in the signal grammar deﬁnition, and the automatic generation of the parser and lexical analyzer from the new grammar deﬁnition. This way, the graphical user interface can be easily adapted to support simulators generated by diﬀerent SDL case tools or based on diﬀerent signal encodings. The current version of the simulator can be improved by adding more complex algorithms, like multilevel feedback queue scheduling, in which a process can move from one ready queue to another depending on the scheduling requirements during its life in the system. Another improvement will be the extension of the simulation model to support multiple-processor/multi-core scheduling. Finally, the simulator could be modiﬁed to support processes with several CPU and I/O bursts. The current version only supports one CPU burst per process.

References 1. Tcl Developer Xchange, http://www.tcl.tk 2. Burns, A., Wellings, A.: Real-Time Systems and Programming Languages. Addison-Wesley, Reading (2002) 3. CodePlex: CPU Scheduling Simulator (April 2008), http://cpuss.codeplex.com 4. IBM: Telelogic SDL Suite 6.3 User’s Manual (September 2009) 5. International Telecommunication Union: Recommendation Z.120, Message Sequence Chart (MSC) (April 2004), http://www.itu.int/rec/T-REC-Z.120/en

90

M. Rodr´ıguez-Cayetano

6. International Telecommunication Union: Recommendation Z.100, Speciﬁcation and Description Language (SDL) (November 2007), http://www.itu.int/rec/T-REC-Z.100/en 7. Ontko, R.: MOSS Scheduling Simulator User Guide (May 2001), http://www.ontko.com/moss/sched/user_guide.html 8. Robbins, S.: Using the Process Scheduling Simulator (January 2007), http://vip.cs.utsa.edu/simulators/guides/ps/ps_doc.html 9. Silberschatz, A., Galvin, P.B., Gagne, G.: Operating System Concepts. John Wiley & Sons, Chichester (2005) 10. Stallings, W.: Operating Systems: Internals and Design Principles. Prentice-Hall, Englewood Cliﬀs (2005) 11. Tanenbaum, A.S., Woodhull, A.S.: Operating Systems: Design and Implementation. Prentice-Hall International, Englewood Cliﬀs (2009) 12. Tang, J.: Taccle: Tcl LALR Parser Generator (July 2008), http://wiki.tcl.tk/11425 13. Tang, J.: Fickle: Tcl Lexical Analyzer Generator (July 2010), http://wiki.tcl.tk/3555 14. Weller, J.: CPU Scheduler Application. University of Alaska Anchorage (March 2006), http://jimweller.com/jim-weller/jim/java_proc_sched

UML-Based Specification and Generation of Executable Web Services Waﬁ Dahman and Jens Grabowski Institute for Computer Science, University of G¨ ottingen Goldschmidt Str. 7, 37077 G¨ ottingen, Germany {wdahman,grabowski}@informatik.uni-goettingen.de

Abstract. This paper presents an approach for the development of executable Web services based on model transformation techniques. The approach is based on a new Web service proﬁle for the Uniﬁed Modeling Language (UML), which allows an eﬃcient deﬁnition of Web service models. Such Web service models allow the generation of the source code and the corresponding platform-speciﬁc conﬁguration ﬁles necessary in order to run the modelled Web services. The code generation is realised by means of transformation and code generation rules deﬁned in the Xpand transformation language. The feasibility of the proposed approach for the development of executable Web services is validated by implementing a library system Web service as a case study. Keywords: Web Services, UML, Model Transformation, Code Generation, MDSD, Xpand, M2T, SOA, SoaML.

1

Introduction

Similar to other software applications, Web services have a speciﬁc structure and behaviour. The structure is the static part of Web services, which is composed of the objects and entities and their associations. The behaviour is the dynamic part, which represents how the Web service behaves in terms of sending requests, preparing responses to these requests, and how they will be sent back to the clients. Both parts are essential in the development of Web services in this paper. The UML [1,2,3] gains great acceptance among software developers due to its standardisation by the Object Management Group (OMG) [4]. Furthermore, it gets high support from tool vendors, where these tool oﬀer also the possibility to generate parts of the source code from UML models [5,6]. In addition, UML oﬀers an extension mechanism, where UML metamodels can be extended to ﬁt the requirements of speciﬁc domains (e.g., Web services). Model Driven Software Development (MDSD) [7] is a software engineering approach that targets the development of executable software systems based on domain speciﬁc models. MDSD concentrates on domain models rather than computation. It focuses on deﬁning a metamodel for a speciﬁc domain in any F.A. Kraemer and P. Herrmann (Eds.): SAM 2010, LNCS 6598, pp. 91–107, 2011. c Springer-Verlag Berlin Heidelberg 2011

92

W. Dahman and J. Grabowski

Domain Speciﬁc Language (DSL), then the model transformation takes place in order to reach the executable source code. MDSD oﬀers possibilities to diﬀerent types of model transformations such as Model-to-Model (M2M) or Model-toText (M2T). Our main goal is to enable the model-driven development of Web services though automated code generation from UML models. We are achieving this goal via two main contributions, summarized as follows: 1. UML Profile for Web Services (UP4WS): we deﬁne two categories of UML extensions. The ﬁrst category represents the main extensions needed for any Web service application, while the second category is deﬁned to enable the generation of executable Web services. 2. UP4WS implementation: the deﬁnition of Xpand transformation rules enables transforming UML models into source code. These transformation rules work at the UP4WS level in order to control the output of the code generation process. We have used our proﬁle on two case studies, a weather Web service and a library system Web service. The value of our approach is that it helps reducing time and eﬀort during the development process by the simple allocation of the UP4WS stereotypes on a UML model of the service. This ﬁnding has been observed during the development and implementation of the library service. We believe that our approach can also improve the quality of the ﬁnal product, since the iterative use of UP4WS helps detecting and avoiding certain types of anomalies. This paper is organised as follows: Section 2 describes the underlying technologies related to our approach. Section 3 presents the deﬁnition of UP4WS proﬁle, while Sect. 4 presents the implementation of the UP4WS. Section 5 shows the case study used to validate our approach. Section 6 describes the related work. In Sect. 7, a summary and outlook is provided.

2

Foundations

In this section, the underlying technologies of our approach are introduced. 2.1

Web Services

Web services are one of the methods for the implementations of the Service Oriented Architecture (SOA) [8], which is sketched in Fig. 1. The ﬁgure shows the service provider, the service client, and the service broker and their associations. This paper is mainly focusing on implementing the service provider and service client sides. The word Web in the name Web services does not mean that it is a Web application, but that it relies on technologies for the Web like the Hypertext Transfer Protocol (HTTP) [9]. The main goal of Web services is to enhance the interoperability of distributed systems over networks, especially the Internet.

UML-Based Speciﬁcation and Generation of Executable Web Services

93

Fig. 1. Roles in the Service Oriented Architecture (SOA)

2.2

Unified Modeling Language Profiles

UML is a general purpose graphical modelling language for the development of systems. Despite the fact that UML is mostly used with object oriented systems, it has the capability to model other types of systems through its ﬂexible extension mechanism. UML proﬁles can be deﬁned to adapt UML for speciﬁc domains. Arlow and Neustadt [5] deﬁne a UML proﬁle as“a collection of stereotypes, tagged values, and constraints”. The OMG has standardised many UML proﬁles to ﬁt diﬀerent types of systems and technologies, such as UML Proﬁle for Common Object Request Broker Architecture (CORBA) [10]. Figure 2 illustrates a sample UML proﬁle called WidthAndLength shown as a package with «proﬁle» stereotype. The WidthAndLength proﬁle includes two stereotypes, i.e., Length extending the Association and Class metaclasses, and Width, extending the Class metaclass. The Length stereotype includes a tagged value length of type ﬂoat, while the Width stereotype includes a tagged value width of type Integer. The Length stereotype contains a constraint limiting the length to less than or equal ﬁve ({length<=5.0}). The WidthAndLength proﬁle is applied by the MyWidthAndLengthApplication model.

Fig. 2. UML WidthAndLength proﬁle

!"

94

W. Dahman and J. Grabowski

Fig. 3. Xpand in example

2.3

Code Generation

Code generation is the other common name for Model-to-Text (M2T) or Modelto-Code (M2C) transformations, where textual code is generated from a given model. The generated code is supposed to be ready for interpretation or compilation. Therefore, it should be complete and executable from the modeller’s point of view [11]. Code Generation with Xpand. Xpand is a template-based M2T transformation language. It was initially developed by OpenArchitectureWare [12]. Since September 2009, Xpand has become part of the M2T transformation languages integrated into the Eclipse platform [13]. Figure 3 shows the Xpand transformation rules for generating a Java ﬁle that corresponds to the UML class Book. On the left, a template ﬁle that consists of diﬀerent templates is shown. Each template handles speciﬁc elements in the class, such as attribute declarations, operations, setter and getter methods.

3

UP4WS Definition

Unlike other UML proﬁles that try to represent the semantics of the technology (e.g., UML proﬁle for CORBA), the UP4WS can be considered as an implementation oriented proﬁle, since we developed it to enable the generation of executable Web services. The proﬁle captures knowledge similar to what is found in

UML-Based Speciﬁcation and Generation of Executable Web Services

95

the Service Oriented Architecture Modelling Language (SoaML) [14] by deﬁning some stereotypes. However, the SoaML is extended in a way that enables the generation of executable Web services. This includes the deﬁnition of additional stereotypes that make the generation of executable source code possible. The UP4WS represents the core of the modelling of Web services, and the basis on which the code generation process will rely, since the proposed code generation process and the transformation rules will handle directly the stereotypes of the UP4WS. The UP4WS deﬁnes two categories of UML extensions. The ﬁrst category contains the basic extensions, which must be present in any Web service application model. The second category includes the stereotypes that make Web services executable by enabling the generation of source code from the model elements applying those stereotypes. Both the service provider side and the service client side are considered in the deﬁnition of the proﬁle and its implementation. The target output from the code generation process using the UP4WS comprised of: – Source code, – Conﬁguration ﬁles for the implementation and deployment platforms, and – Documentation ﬁles. 3.1

Web Services Basic Extensions

The basic extensions are mandatory extensions, since they represent the necessary parts for Web services. These extensions are explained in the following: – Each Web service application comprises a service provider side, and a service client side. – The service provider side must have a service object representing the diﬀerent services provided by the Web service. These services can be represented in terms of operations or methods. – The methods or operations in the service object manipulate data stored in other objects, i.e., data objects. These objects provide diﬀerent data elements, i.e., data variables or attributes. – The service client side always contains a client object that invokes the services provided by the Web service and represented in the service object. The execution of the Web service is achieved by executing the client object. Therefore, it must contain an execution mechanism (e.g., main method in Java or C). Our assumption is to deﬁne two objects at the service client side: the proxy client object, which is accessed by another client object. The proxy client object implements the services from the client’s perspective, while the client object contains the execution mechanism of the Web service. Table 1 shows the main stereotypes in the UP4WS and the UML metaclasses, while Figure 4 represents a simpliﬁed weather Web service model that applies the UP4WS.

96

W. Dahman and J. Grabowski Table 1. Main web service stereotypes UP4WS main stereotypes Web Service Element Stereotype UML Metaclass Web service object «WebService» Class Services «ProxyMethod» Operation Data objects «DataContainer» Class Data variables «DataElement» Attribute Proxy client object «ProxyImplementation» Class Client object «Client» Class Client Execution mechanism «ClientMain» Operation

Fig. 4. Weather web service model

3.2

Making Web Services Executable

In order to enable the generation of source code and conﬁguration ﬁles that make Web services executable, an additional set of UML extensions is required in the UP4WS. This set enables the generator to access the stereotyped elements of the UML model and generate the output according to their speciﬁcations. The extensions in this respect are classiﬁed into two categories. The ﬁrst extensions category enables the generation of Web services behaviour from state machines. Specifying the behaviour of the Web service in detail enables its execution by generating the corresponding source code for that behaviour. State machine diagrams can be used to represent the behaviour of the Web service. Therefore, additional extensions to be applied by state machine diagrams and their elements have to be speciﬁed. We distinguish between two types of state machine diagram extensions: – The «ObjectStateMachine» stereotype is deﬁned to enable the generation of the behaviour implementation of the data objects. If one of the data

UML-Based Speciﬁcation and Generation of Executable Web Services

97

objects has a behaviour, the state machine representing this behaviour should apply the «ObjectStateMachine» stereotype. Other stereotypes that enable its implementation shall also be included. Those stereotypes are «ObjectState», «ObjectTransition» and «ObjectFinalState» stereotypes. – The «OperationStateMachine» stereotype is deﬁned to enable the generation of the implementation of the class operations. Therefore, a state machine applying this stereotype has to be assigned to the operation, for which we need to generate the implementation. As parts of the «OperationStateMachine» stereotype, the «OperationState» and «OperationTransition» stereotypes are deﬁned. The second extensions category enables the generation of speciﬁc implementation constructs in the source code (e.g., attribute declarations). For this category, we deﬁne two stereotypes as follows: – «Initializable» stereotype to generate the declaration of the attribute that have to be initialized. – «Enumerizable» stereotype to generate the declaration of the attributes of a type corresponding to an enumeration object. The complete UP4WS stereotyped are presented in the following classiﬁcation. – Basic extensions: «WebService», «DataContainer», «DataContainer», «ProxyImplementation», «ProxyMethod», «Client», and «ClientMain» stereotypes. – Making Web services executable extensions: this category is classiﬁed into two sub-categories as follows: • Executable state machines: we distinguish between two types of state machines depending to which they are assigned, i.e., assigned to an object, and assigned to an operation. For the ﬁrst type we deﬁne «ObjectStateMachine», «ObjectState», «ObjectTransition» and «ObjectFinalState» stereotypes. The second type of stereotypes includes «DataBehavior», «OperationStateMachine», «OperationState», and «OperationTransition» stereotypes. • Auxiliary extensions: in this category we deﬁne «Initializable», and «Enumerizable» stereotypes.

4

UP4WS Implementation

The proﬁle implementation represents the model transformation and code generation process, which includes deﬁning the transformation rules for transforming the model elements into the source code, and conﬁguration and documentation ﬁles. Each element in the source model applying any stereotype deﬁned in the UP4WS will be processed by the generator and thus inﬂuences the output. It is important to mention here that the communication between the service client and service provider is not part of the UP4WS implementation since it is done completely in the background by the Web service engine. In other words, we treat both sides independently of the way they communicate.

98

4.1

W. Dahman and J. Grabowski

Model Transformation and Code Generation

The model transformation and code generation process aims at producing the target output from the UML model. Figure 5 provides an overview of the entire model transformation process. It shows the UP4WS, which is applied by a UML model. The model is then exported to the generator, which applies the transformation rules on it in order to generate the relevant output. The Xpand transformation language is used for transforming the UML model into the target output ﬁles (i.e., source code and conﬁguration ﬁles for the platform). The transformation rules work on the UP4WS level, meaning that they handle only stereotyped elements in the Web service model. The Xpand transformation rules are deﬁned in terms of templates and template ﬁles. Each template ﬁle corresponds to a speciﬁc stereotype. We have organised the transformation rules in diﬀerent template ﬁles, where each one is responsible for generating the Java classes that correspond to the objects in the model. In addition, we have deﬁned a common template ﬁle, where general transformation rules exist. These rules are invoked inside other template ﬁles.

*+

!

$"

% &'#( )

! "#

Fig. 5. Model transformation and code generation process

The Xpand code inf Fig. 6 represents an example of transformation rules, which are responsible for generating setter and getter methods for any attribute applying the «DataElement» stereotype. At ﬁrst, it checks that that visibility of the attribute is private. If yes, the transformation rules are executed and the corresponding methods are generated.

5

A Case Study: Library System Web Service

For the validation of the UP4WS and the code generation process, a case study is implemented in order to demonstrate the feasibility of our approach. 5.1

Web Service Description

The library system Web service is chosen because of its well-known characteristics and the familiarity of its functionalities. Each functionality represents one of the services provided by the library system Web service.

UML-Based Speciﬁcation and Generation of Executable Web Services

99

«DEFINE gettersAndSetters FOR UP4WS::DataElement» «IF visibility.toString() == "private"» public void set«name.toFirstUpper()» («type.name» «name.toFirstLower()») this.«name»= «name.toFirstLower()»; public «type.name» get«name.toFirstUpper()» () return this.«name»; «ENDIF» «ENDDEFINE» Fig. 6. Example for transformation rules

A typical library system Web service could have the following brief description: The library Web service system manages the virtual book list of the library. Each book is distinguished via title, International Serial Book Number (ISBN), and author. The library Web service provides mechanisms for diﬀerent processes on books. The client shall be able to add books to the book list. The books become available and can be borrowed. If a book is borrowed, it becomes on loan. The borrowed book shall be returned to the book list and become available again. In order to allocate the stereotypes of the UP4WS to the model elements we have to identify the model elements that shall apply the basic stereotypes in the UP4WS. From the library Web service system description, the following objects are identiﬁed. – Library System service (Web service object). – Book, and Book List (data objects). – Client (proxy client and client object). In addition, the Web service description indicated that the Web service provides the following services: – Adding books – Lending books – Returning books 5.2

Identifying and Allocating UML Extensions to the Library Web Service

We now identify the UML extensions for the library Web service. This is the initial step for allocating the stereotypes on the elements that represent the UML extensions for Web services. UP4WS deﬁnes a set of basic extensions that must be speciﬁed in any Web service model applying it. The following is a list of the identiﬁed basic extensions for the library Web service:

100

W. Dahman and J. Grabowski

Fig. 7. Class diagram for the service provider side

– – – – –

LibrarySystemService represents the service object. addBook, lendBook, and returnBook represent the provided services. Book and BookList represent the data objects. Book name, ISBN, and author represent data variables. Client represents client object.

The allocation of the UP4WS stereotypes on the UML model elements for the library Web service is shown in Fig. 7. The ﬁgure shows the main objects at the service provider side and a speciﬁc subset of their elements to show the usage of the basic extensions of the UP4WS in the library system Web service model. In the following, the allocation of the UP4WS stereotypes on those objects is presented. – – – –

5.3

LibrarySystemService extends the «WebService» stereotype. Book and BookList extend the «DataContainer» stereotype. isbn, title, author in Book class extend the «DataElement» stereotype. getBook, and lendBook in LibrarySystemService class extend the «ProxyMethod» stereotype. Representing Library Web Service Behaviour

The description of the library Web service indicates that the Book object has diﬀerent states, e.g., available and borrowed. For the representation of the Book object behaviour, a state machine diagram is used. The state machine diagram enables the implementation of the behaviour of the corresponding object. Figure 8 represents the state machine diagram modelled to represent the behaviour of the Book object. It contains three states, i.e., NotAvailable, Available, and OnLoan. The state NotAvailable is added to represent the default state of any book instance. The BookStatus state machine diagram in Fig. 8 applies the «ObjectStateMachine» stereotype in order to enable the generation of the behavioural source code.

UML-Based Speciﬁcation and Generation of Executable Web Services

101

Fig. 8. Book Status

5.4

Generating, Deploying and Executing the Web Service

This process includes the code generation process and the deployment and execution of the library Web service on the selected platform, which is the Apache Axis2/Java [15] as a Web service engine, and the Apache Tomcat [16] as an application server. The code generation process is performed by using the Xpand transformation language on the Eclipse platform [13]. The generator receives the source UML model for the library Web service as an Eclipse Modeling Framework (EMF) [17] Uniﬁed Modeling Language v.2.x (UML2) XML Metadata Interchange (XMI) [18] ﬁle. This is the ﬁle format used in the library Web service and exported using the Magic Draw [19] UML tool. Running the Eclipse/Xpand generator requires the deﬁnition of the Modeling Workﬂow Engine (MWE) ﬁle. The MWE ﬁle speciﬁes diﬀerent parameters of the project, such as the source model, UML proﬁle, and location of output ﬁles. The MWE ﬁle includes diﬀerent components, which serve for various purposes. The following list describes brieﬂy the main components in the MWE ﬁle: – Cleaner component to clean the output folder at each run of the generator. – Generator components, which are responsible for generating the diﬀerent types of the output ﬁles. Each generator component can deﬁne an outlet to specify the exact location of output ﬁle. The conﬁguration ﬁles are platform dependent ﬁles needed to implement and deploy the library system Web service on the Apache Axis2/Java Web service engine and the Apache Tomcat application server. The ﬁles in this speciﬁc context are the build.xml and the services.xml ﬁles. The build.xml ﬁle enables the compilation of the Java ﬁles at the service provider side the generation of the archive ﬁle LibrarySystemService.aar, which enables the deployment of the Web service on the Apache Tomcat application server. The README.txt ﬁle is a documentation ﬁle that provides instructions on how to execute the Web service application.

102

W. Dahman and J. Grabowski

Based on the generated output, the Web service shall be executable on the Apache Axis2/Java Web service engine. Figure 5 has shown the code generation process for the UP4WS and the corresponding model. In the following, a description of the sequence of steps that shall be done to execute the Web service is presented. These steps are also explained in the README.txt ﬁle, which is part of the output. – Export the proﬁle and model to the Eclipse/Xpand generator where the transformation rules for generating the output reside. – Run the generator in order to get the target output. – Move the output to the Apache Axis2/Java platform for executing the Web service. – Compile the Java ﬁles at the service provider side using the ANT [20] tool. This will generate the archive ﬁle of the Web service. This ﬁle contains all information about the Web service. and should be copied in the relevant location in the Apache Tomcat [16], in order to deploy the Web service. – Compile the Java ﬁles at the service client side in order to execute the Web service. The Web service can be executed by running the client object that contains the main method. The code generation process produces the source code required for executing the Web service. The source code includes all Java classes resulting from the UML classes in the model, which apply the corresponding stereotypes in UP4WS, and the containing the behaviour expressed in state machine diagrams as described in Sect. 3.2. The source code runs successfully in Windows XP and Windows Vista environments [21].

6

Related Work

The examined work covers diﬀerent perspectives that relate to the goal of this paper. Each perspective corresponds to a sub-goal of this paper. For example, some approaches try to model Web services with UML. However, their view of Web services is constrained to Web Service Description Language (WSDL) documents [22,23,24]. Others take the composition of Web services into consideration [25,26]. Another category of the related work focuses on the generation of source code out of UML models independent of the type of the application and the implementation platform [27]. The following is a brief description for the most relevant and related work. The conversion rules between UML and Web services described by WSDL documents and Xtensible Mark-up Language (XML) Schema is provided by Grønmo et al. in [23]. They recommend the modelling of Web services by UML disregarding the WSDL constructs and present a mapping between WSDLindependent UML models and the service description in WSDL. They ﬁnd out that: 1) a WSDL-independent UML model of a web service is better than a WSDL-dependent model or pure WSDL in explaining the service, 2) WSDLindependent UML models make the building of Web services simpler, especially

UML-Based Speciﬁcation and Generation of Executable Web Services

103

if the Web service is complex, and 3) reverse and forward engineering between WSDL speciﬁcations and WSDL-independent UML models is possible for all kinds of services. Skogan et al. [25] introduce a UML-based model-driven method for Web service composition. This method shows the possibility of using model transformations to get executable models from composite Web services models. In addition, they present a UML proﬁle and guidelines for modelling composite Web services. Th¨one et al. [26] deﬁne a similar method to describe a UML-Web Service Composition (WSC) proﬁle as a replacement for the Business Process Execution Language for Web Services (BPEL4WS), which is a language for the formal speciﬁcation of business processes and business interaction protocols [28]. Lautenbacher [29] deﬁnes transformation rules in Xpand for semantic Web services. He develops a UML proﬁle for semantic Web services based on a predeﬁned metamodel. The work considers a set of World Wide Web Consortium (W3C) speciﬁcations, such as Semantic Markup for Web Services (OWL-S), Web Service Modeling Ontology (WSMO), Web Service Description Language with Semantics (WSDL-S) and Semantic Web Services Framework (SWSF). Usman and Nadeem [27] develop a code generation tool known as UJECTOR. The UJECTOR tool generates code from UML class, sequence, and activity diagrams. The structure of the code is generated from the class diagrams, while the sequence diagrams with incorporation of the activity diagrams generate the code for the methods in the classes. Since the work presented in this paper is targeting the generation of executable source code for Web services, the following comparison discusses how close the related work is to ours. Our approach introduces a comprehensive speciﬁcation for the development of executable Web services, and not only for WSDL documents [23,25,26] or speciﬁc W3C standards [29]. Furthermore, it deﬁnes a set of transformation rules in order to generate diﬀerent output ﬁles of several types from UML models based on the UP4WS [21]. The work presented in this paper concentrates on the implementation of Web services and how we can generate executable source code from UML models, which applies the proposed UP4WS. The work in [23,25,26] rather concentrates on the representation of Web services by means of WSDL and BPEL4WS without providing a mechanism for implementing the Web service. In [29], Lautenbacher deﬁnes transformation rules with Xpand, which is also used in our approach. However, it focuses on diﬀerent semantic Web services speciﬁcations (i.e., OWL-S, WSMO, WSDL-S and SWSF), which do not enable the implementation of executable Web services. A review of the work of Usman and Nadeem [27] shows that their work does not target any speciﬁc platform. It deﬁnes a mechanism for generating Java source code from UML diagrams, without targeting any domain or platform. Unlike our work, their model transformation approach is not based on a speciﬁc metamodel for the target domain. The OMG [4] standardised a modeling language for SOA based application [14]. This language expresses the semantic of such applications by deﬁning diﬀerent stereotypes for

104

W. Dahman and J. Grabowski

the elements involved in them. However, we had to deﬁne additional stereotypes to enable the generation of executable Web services, especially for generating the Web service behaviour.

7

Summary and Outlook

This section provides a summary of the paper together with a brief discussion of its main contributions. It also gives an outlook for the possible extensions of this work. 7.1

Summary

This paper introduced an approach for the code generation of executable Web services. For this purpose, a UML Proﬁle for Web Services (UP4WS) is deﬁned. The UP4WS deﬁnes two types of extensions for Web services. The ﬁrst type is the Web service speciﬁc extensions, which are mandatory and must be speciﬁed for any Web service application disregarding on which platform the Web service will be implemented and deployed. Those extensions consider the implementation of the service provider and service client sides. The second type are the extensions that enable the generation of executable source code for Web services. The paper deﬁnes the UP4WS implementation process, which includes the deﬁnition of the transformation rules for the generation of the target output. The transformation rules are deﬁned in the Xpand language. For the validation of this work, a case study where we applied our approach to a library Web service is presented. 7.2

Discussion

Our approach has shown how we can utilise model driven development approaches for deﬁning domain speciﬁc models. We shall be able to generate executable source code and conﬁguration ﬁles based on those models. In this section, we illustrate some issues that may come in question. The following is a brief discussion of some of these issues. We aim at implementing a Web service, namely service provider and service client sides. The mechanism by which both sides communicate is out of the scope of this paper since it is done completely in the background by the Web service engine. For enabling the implementation of Web services, we deﬁned a small set of stereotypes that can be easily understood, even by non-Web service developers. It is supposed that the UP4WS stereotypes can be applied by any Web service application. Another additional beneﬁt of the UP4WS is its potential reusability. Since Web services are based on the SOA architecture, the proposed UP4WS seems promising for implementing other types of applications that rely on the same architecture. For example, it should be possible to customise the UP4WS for CORBA applications.

UML-Based Speciﬁcation and Generation of Executable Web Services

105

We used the Xpand transformation language for deﬁning the transformation rules. Xpand is one of the most recent transformation languages, which has gained experience from its ancestors by avoiding their weaknesses such as a complex syntax. It follows a simple and understandable syntax, and has an interactive support from its community and developers as well. The transformation rules process the stereotyped elements in the model. This increases their usability, since they are dedicated only to the UP4WS stereotypes, and thus, do not contain the complexities imposed by some UML elements. The transformation rules are deﬁned to generate the source code in Java. Although this could be seen as a limitation, we believe that they can be reused to enable the generation of source code in other programming languages, such as C and C++, since programming languages follow a similar syntax. The Web service engine used to implement Web services in our approach is the Apache Axis2 together with the Apache Tomcat as an application server. This selection only inﬂuences the transformation rules for generating Java classes at the service client side. Therefore, the transformation rules can be reused for implementing Web services using other Web service engines by only applying the corresponding modiﬁcations for the new Web service engine. 7.3

Outlook

This paper showed how to use state machine diagrams for the representation of Web services behaviour. Using other behavioural diagrams, such as activity diagrams is promising as well and could be investigated in future work. Furthermore, this paper demonstrated how to generate Java source code for a speciﬁc platform and Web service engine. It should be possible to extend this approach to the implementation of Web services in other programming languages and on diﬀerent platforms and Web service engines. The composition of Web services is one of the most important topics related to Web services. Composite Web services enable the reuse of already existing Web services to provide more comprehensive and larger Web services. In such cases, the Web service plays the role of service provider and service client at the same time. Therefore, it should have the mechanisms for providing and invoking other Web services. The UP4WS deﬁnes a speciﬁc set of UML extensions for a single Web service. Since the composite Web services have more sophisticated architecture and behaviour, it may be necessary to deﬁne additional UML extensions for composite Web services. Our approach provides a promising starting point for investigating the required modiﬁcations of the proﬁle deﬁnition and its implementation. Additionally, we will investigate the possibility to follow the guidelines for UML proﬁle design [30] standardised by the International Telecommunication Union-Telecommunication (ITU-T). Acknowledgements. The authors are very thankful to Dr. Daniel Amyot and Philip Makedonski for their valuable suggestions and the proof reading.

106

W. Dahman and J. Grabowski

References 1. OMG: Uniﬁed Modeling Language: Infrastructure, V2.3. formal/2010-05-03 (2010) 2. OMG: Uniﬁed Modeling Language: Superstructure, V2.3. formal/2010-05-05 (2010) 3. UML: Uniﬁed Modeling Language, http://www.uml.org/ (last visited August 2010) 4. OMG: Object Management Group (OMG), http://www.omg.org/ (last visited August 2010) 5. Arlow, J., Neustadt, I.: UML 2 and the Uniﬁed Process, 2nd edn. Addison-Wesley, Reading (2005) 6. Fowler, M.: UML Distilled. Addison-Wesley, Reading (2004) 7. Stahl, T., Voelter, M.: Model-Driven Software Development. John Wiley & Sons, Ltd., Chichester (2006) 8. Erl, T.: Service-Oriented Architecture. A Field Guide to Integrating XML and Web Services. Prentice-Hall, Englewood Cliﬀs (2004) 9. Conallen, J.: Building Web Application with UML, 2nd edn. Addison-Wesley, Reading (2003) 10. O.M.G.: UML Proﬁle for CORBA, v 1.0. formal-02-04-01 (April 2002) 11. Kelly, S., Tolvanen, J.P.: Domain Speciﬁc Modeling. Wiley-Interscience Publication, Hoboken (2008) 12. OAW: OpenArchitectureWare (oAW), http://www.openarchitectureware.org (last visited August 2010) 13. Eclipse: Eclipse Platform, http://www.eclipse.org/ (last visited August 2010) 14. OMG: Service Oriented Architecture Modelling Language. ptc/2009-12-09 (December 2009) 15. Apache: Apache Axis2/Java, http://ws.apache.org/axis2/ (last visited August 2010) 16. Apache: Apache Tomcat, http://tomcat.apache.org/ (last visited August 2010) 17. Steinberg, D., Bundinsky, F., Paternostro, M., Merks, E.: EMF Eclipse Modeling Framework, 2nd edn. Addison-Wesley, Reading (2008) 18. OMG: MOF 2.0/XMI Mapping, v2.1.1. formal/2007-12-01 (December 2007) 19. MagicDraw: Magicdraw, http://www.nomagic.com (last visited August 2010) 20. Apache: The Apache ANT Project, http://ant.apache.org/ (last visited August 2010) 21. Dahman, W.: A UML Based Methodology for the Development of Web Services, An Approach to Model Transformation and Code Generation. PhD Thesis, Institute for Informatics, Georg August University of G¨ ottingen (July 2010) 22. Marcos, S., Castro, V., Vela, B.: Representing Web Services with UML: A Case Study. In: UNITN - The First International Conference on Service Oriented Computing, UNITN (2003) 23. Grønmo, R., Skogan, D., Solheim, I., Oldevik, J.: Model-Driven Web Services Development. In: Proceedings of the IEEE International Conference on e-Technology, e-Commerce and e-Service (IEEE 2004), pp. 42–45. IEEE Computer Society, Washington, DC (2004) 24. Armstrong, C.: Modeling Web Services with UML. In: OMG Web Services Workshop 2002 (2002) 25. Skogan, D., Grønmo, R., Solheim, I.: Web Service Composition in UML. In: Enterprise Distributed Object Computing Conference (EDOC 2004), pp. 47–57. IEEE Computer Society Press, Washington, DC (2004)

UML-Based Speciﬁcation and Generation of Executable Web Services

107

26. Th¨ one, S., Depke, R., Engels, G.: Process-Oriented, Flexible Composition of Web ` Yoshikawa, M., Yu, E.S.K. (eds.) ER 2003. LNCS, Services with UML. In: Oliv´e, A., vol. 2784, pp. 390–401. Springer, Heidelberg (2003) 27. Usman, M., Nadeem, A.: Automatic Generation of Java Code from UML Diagrams using UJECTOR. International Journal of Software Engineering and its Applications 3(2) (2009) 28. BPEL4WS: BPEL4WS V1.1 speciﬁcation (2003), http://download.boulder.ibm. com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel.pdf (last visited August 2010) 29. Lautenbacher, F.: A UML Proﬁle and Transformation Rules for Semantic Web Services. Technical Report 2006-2020, Institut for Informatics. Augsburg University, Germany (2006) 30. International Telecommunication Union: Recommendation Z.119, Guidelines for UML Proﬁle Design (February 2007), http://www.itu.int/rec/T-REC-Z. 109-200706-I/en

The SDL-UML Profile Revisited Alexander Kraas Poppenreuther Str. 45, D-90419 Nürnberg, Germany [email protected]

Abstract. The ITU-T has published the most recent version of a UML profile for the combined use of the Specification and Description Language (SDL) and the Unified Modelling Language (UML) in the year 2007. This SDL-UML profile encompases the specification of structural and behavioral aspects of a SDL system in terms of a UML model. In this paper, limitations of the models for data type and value specification of the current SDL-UML profile are analyzed. On this foundation, new models for both aspects are proposed in order to remedy the analysed limitations in an upcoming version of a UML profile for SDL-2010. Keywords: SDL-2010, SDL-UML Profile, Value Specification, Data Type Specification.

1

Introduction

The ﬁrst version of a UML proﬁle for the combined use of the Speciﬁcation and Description Language (SDL) and the Uniﬁed Modeling Language (UML) was published in 1999 by the ITU-T [1]. This proﬁle version had only supported the speciﬁcation of structural aspects, whereas the most recent version of the SDL-UML proﬁle [2] also includes the modelling of behavioral aspects. This also comprises a particular action language and an associated surface language, which is a subset of the concrete syntax of SDL-2000 [3]. In consequence, with the current proﬁle version it is possible to specify a SDL system in terms of a UML model. This aspect was analysed in a case study [4], which had the objective to model the same system in native SDL and with the SDL-UML proﬁle. In general, the case study proved that SDL-UML is applicable in the same way as SDL. Nevertheless, some limitation and shortcomings have been discovered on the basis of this case study. The author of this paper has reported the analyzed shortcomings to the ITU-T Study Group 17 in order to remedy them in the current version of the Z.109 Recommedation [2]. However, discovered limitations related to the current data type model and the value speciﬁcation model were not included in that report. Hence, the diﬀerent limitations are presented in the following chapters. In addition, a new data type model and a new value speciﬁcation model are proposed for the upcoming version of a UML proﬁle for SDL-2010. The rest of this paper is structured as follows. Section 2 discusses other related UML proﬁles for the modeling of communication systems. In Sect. 3, a few F.A. Kraemer and P. Herrmann (Eds.): SAM 2010, LNCS 6598, pp. 108–123, 2011. c Springer-Verlag Berlin Heidelberg 2011

The SDL-UML Profile Revisited

109

notational conventions are introduced. The limitations of the current data type model of SDL-UML and an approach for their solution are discussed in Sect. 4. In the scope of Sect. 5, the current model for value speciﬁcation is analyzed. Finally, the last section provides a brief summary.

2

Related Work

Apart from the SDL-UML proﬁle as speciﬁed in the most recent version of the Z.109 [2], also other approaches had been proposed for the UML-based speciﬁcation of communicating systems (such as [5,6]). Of these, the UML proﬁle for communicating systems (UML-CS) in [6] is the most complete. The most signiﬁcant diﬀerence between proﬁles is the manner in which the semantics are speciﬁed. The mapping rules of the SDL-UML proﬁle are speciﬁed in terms of textual rules. In contrast, for the mapping of the UML-CS proﬁle, an eXtensible Stylesheet Language Transformation (XSLT) approach is utilized. Both proﬁles specify SDL-speciﬁc action semantics, but SDL expressions are represented in a diﬀerent way. In SDL-UML, expressions are represented in terms of UML expressions, whereas in UML-CS the semantics of expressions are not speciﬁed. In addition, for the UML-CS proﬁle no model for value speciﬁcation is deﬁned. The advantage of representing SDL expressions and values in terms of dedicated UML elements is that parse trees for the textual surface language of SDL-UML can be stored in the model repository of a UML tool. Hence, transformations of shorthand notations and static syntax checks can be directly performed on UML elements. The general applicability of the SDL-UML proﬁle was analyzed in [4], but during the implementation of an appropriate editor, some limitations of the most recent version of the proﬁle have been found. In particular, this concerns the speciﬁed models for data type and value speciﬁcations. The data type model and model for value speciﬁcation in the following chapters are proposed to remedy this situation.

3

Notational Conventions

Due to the fact that in the following chapters grammar and semantics related issues of three diﬀerent standards are discussed, for the sake of clarity the subsequent notational conventions apply. These conventions comply1 with the guidelines for UML proﬁle design as speciﬁed in the ITU-T Z.119 Recommendation [7]. The same guidelines were also used for the speciﬁcation of the SDL-UML proﬁle. – A name written within guillemets («...») refers to an instance of a stereotype of the SDL-UML proﬁle [2]. Otherwise, if a name written within guillemets is followed by the word “stereotype”, the name refers to the corresponding stereotype of the SDL-UML proﬁle. 1

With the following minor refinement in this paper: both Z.119 and Z.109 use <<...>> to bracket stereotype names, whereas this paper uses guillemets («...»).

110

A. Kraas

– An underlined Name starting with a capital letter refers to a metaclass of the UML Superstructure [8]. In addition, a property of such a metaclass is represented by an underlined name starting with a lower-case character. – Nodes of the abstract syntax of SDL [3] are referred by names written in italic style starting with a capital letter. – A name written in bold letters starting with lower-case characters refers to a keyword of the concrete grammar of SDL.

4

Data Type Model

The data type model proposed for the upcoming version of the SDL-UML proﬁle for SDL-2010 in this chapter is designed to remove some limitations of the data type model of the most recent version of SDL-UML. However, only a semi-formal speciﬁcation is given within this chapter, because it is only intended to give an overview of the capabilities of the proposed model. 4.1

Actual Data Type Model

In order to make it easier to compare data type related features provided by the most recent version of SDL-UML with those proposed in this chapter, a brief overview of the data type model as speciﬁed in Z.109 [2] is given below. Irrelevant aspects (such as some metaattributes) of UML metaclasses are omitted in Fig. 1.

Fig. 1. Actual data type model of SDL-UML

In general, a distinction has to be made between «PassiveClass» and «DataType»(including stereotypes that extend sub-classes of DataType). That is because a «PassiveClass» is mapped to an Object-data-type-definition in the

The SDL-UML Profile Revisited

111

abstract syntax of SDL, whereas all DataType related elements are mapped to a Value-data-type-definition. Considering the data type model depicted in Fig. 1., the most important disadvantage of that model is that an object data type can only be speciﬁed in terms of a «PassiveClass», whereas in contrast three diﬀerent stereotypes of SDL-UML can be used for the speciﬁcation of a value data type. However, this is not the only drawback of the current data type model. In the next section, the most important issues of the actual data type model are discussed in detail. 4.2

Limitations of the Actual SDL-UML Data Type Concept

Before proposing possible data type related enhancements for a new version of the SDL-UML proﬁle in the following sections, the most important limitations of the current model are analyzed below. 1. Deletion of object data types in SDL-2010: The ITU Study Group 17 [9] has decided not to support object data types in SDL-2010, so they will no longer be required in the SDL-UML proﬁle. Consequently, the «PassiveClass» stereotype is dropped in the proposed data type model. 2. Behavior of operations: As depicted in Fig. 1, the metaclass DataType directly inherits from the metaclass Classiﬁer. Therefore, the DataType metaclass does not own an ownedBehavior property. In consequence, the method of an «Operation» owned by a DataType cannot be stored in the same namespace. Hence, an «Activity» forming the method of an «Operation» has to be stored elsewhere, instead of within the enclosing DataType. 3. Missing support for choice data type: The most recent version of the SDL-UML proﬁle does not support the speciﬁcation of choice data types, whereas this is the case in SDL. Choice types are necessary for specifying some kind of data types in the Abstract Syntax Notation One (ASN.1). This notation can be used as an alternative for data type speciﬁcation in SDL. Hence, choice data types should also be supported by SDL-UML. 4. Missing support for optional fields in a structured data type: The abstract syntax of SDL makes a distinction between a Static-operationsignature and a Dynamic-operation-signature of a Data-type-definition. In general, this diﬀerentiation is also made between operator and method operations in the concrete syntax of SDL. But in SDL-UML, no explicit distinction between the two kinds of operations can be made. 5. Missing support for syntypes: Apart from the speciﬁcation of data types and interfaces, SDL also supports the deﬁnition of syntypes. This language feature provides a mechanism to constrain the set of possible elements of an already existing data type (sort). A syntype is an alternative for specifying a data type which means that a syntype can be referenced in the same manner as a normal data type.

112

A. Kraas

6. Restricted possibility to specify literal signatures: The actual version of SDL-UML supports the speciﬁcation of literal data types by the «Enumeration» stereotype. In contrast to native SDL, the expressiveness of an UML Enumeration is rather limited. That is because the concrete grammar of SDL supports the speciﬁcation of literal signatures in terms of literal names, name class literals and named numbers, whereas the actual version of SDL-UML supports only literal names. For instance, a HTTP response includes numerical status codes, which are partitioned in diﬀerent classes of responses. Since the numbering of the status codes is not in an ascending order, this kind of numbering cannot be expressed by the «Enumeration» stereotype of the actual version of SDL-UML. 4.3

Features of the Proposed New Data Type Model

In this section, new features for the data type model of the SDL-UML proﬁle are proposed in order to address the omissions listed in Sect. 4.2. Nonetheless, the discussed model does not attempt to cover all missing data type features of SDL; only those features we consider to be essential. In particular, the proposal does not include: Renaming mechanisms: In SDL, operations or literals that are inherited from a super-type can be renamed in a specializing sub-type. This feature is not included in the proposal, because it is assumed that renaming is rarely used. Argument virtuality: Parameters of methods can be declared as virtual, making it possible to change the parameter type in a redeﬁning method. However, this feature is only applicable for parameters consisting of object data types. Since object data types shall not be supported in SDL-2010, the feature of argument virtuality is not usable any longer. Name class literals: In general, name class literals are used in order to specify the predeﬁned data types of SDL-2000 in a formal manner, but for the speciﬁcation of user-deﬁned data types they are not relevant. An overview of the proposed data type model for SDL-UML is shown in Fig. 2. The most important diﬀerence between the current data type model (see Fig. 1) and the new one is that the «PassiveClass» stereotype is not any longer present (issue 1 of Sect. 4.2). In addition, the new data type model introduces three optional stereotypes extending the DataType metaclass. The «Choice» stereotype represents a SDL choice data type and addresses the limitations of issue 3 of Sect. 4.2. The «Syntype» stereotype introduces the feature of syntype speciﬁcation in SDL-UML (issue 5 of Sect. 4.2). However, the ability to specify structured data types is already supported by the most recent version of SDL-UML, but corresponding mapping rules and constraints are speciﬁed in the context of the «DataType» stereotype. Since this stereotype is applied automatically to all instances of metaclasses inheriting from DataType, for instance PrimitiveType, this approach is considered to be inappropriate. Hence, the new data type model introduces the «Structure» stereotype, which shall be mapped to a SDL structure data type.

The SDL-UML Profile Revisited

113

Fig. 2. Enhanced data type model for SDL-UML

In addition to the before mentioned stereotypes, the new data type model also introduces the «EnumerationLiteral» stereotype in order to address issue 6 of Sect. 4.2. The optional tagged value namedNumber (which is of type UnlimitedNatural) shall be used in order to specify literals in terms of SDL named numbers. Furthermore, the «DataType» stereotype shall own the tagged value owned Behavior as a composition (issue 2 of Sect. 4.2). That is because all elements of ownedBehavior shall be directly stored in the namespace of a «DataType» element. 4.4

Stereotypes of the Proposed New Data Type Model

This section describes the stereotypes of the proposed new model. «DataType» In general, an element stereotyped with «DataType» shall be mapped to a Valuedata-type-definition in the abstract syntax of SDL. The «DataType» stereotype extends the metaclass DataType with a multiplicity of [1..1]. Since the DataType metaclass is the most general metaclass of the UML-SS for specifying data types, the «DataType» stereotype is applied automatically to all appropriate UML elements.

114

A. Kraas

Owned Behavior of Operations: In order to address issue 2 of Sect. 4.2, the «DataType» stereotype owns the tagged value ownedBehavior, which is of type Activity. The multiplicity of the tagged value is * and its aggregation kind is composite. The ownedBehavior is used in order to store each «Activity», specifying the method of an «Operation» of the enclosing data type. Appropriate mapping rules are speciﬁed in the context of the «Operation» stereotype. Specialization: A «DataType» can specialize a more general super-type by adding additional operations or attributes. A generalization is denoted by the general property of the specializing «DataType». Since SDL does not support multiple inheritance, the general property shall refer at most to only one «DataType». In addition, only the same kind of stereotype shall be applied to a super-type and its sub-type. That is because in SDL, for instance, a structure type can only be specialized by another structured type. The general property of a «DataType» shall be mapped to the Datatype-identifier in the abstract syntax of SDL. Redefinition: When an enclosing Classiﬁer CB (e.g. an «ActiveClass») specializes a more general classiﬁer CA, an enclosed «DataType» B of CB can redeﬁne another «DataType» A of CA. In this case, the redeﬁned «DataType» A shall be referenced by the redeﬁnedClassiﬁer property of the redeﬁning «DataType» B. Since multiple inheritance is not supported in SDL, the redeﬁnedClassiﬁer property of a «DataType» shall contain at most one reference to a redeﬁned data type. In addition, when the isLeaf property of a «DataType» is true, it is not permitted to redeﬁne this data type any more. This is equivalent to a SDL virtual type of kind ﬁnalized. DataType with no Additional Stereotypes: The concrete semantics and constraints are speciﬁed in the context of stereotyped metaclasses inheriting from DataType. In general, it is possible to specify a «DataType» without any further applied stereotype. Such a data type shall only contain Operations, if any. «Structure» The optional «Structure» stereotype extends the DataType metaclass with a multiplicity of [0..1]. This stereotype corresponds to a SDL structure data type of the concrete grammar of SDL. In addition to the «DataType» stereotype, this optional stereotype introduces additional constraints and mapping rules. Owned Attributes of a Structure Data Type: As in the case of the actual version of SDL-UML, also in the proposed data type model, the diﬀerent ﬁelds of a «Structure» data type are represented as ownedAttributes. The type of an ownedAttribute shall refer only to DataType speciﬁcations (including derived metaclasses). That is because in SDL-UML the type of a Property can also be an «ActiveClass» or an «Interface». An ownedAttribute of a «Structure» data type with the multiplicity of [0..1] denotes an optional data ﬁeld. In all other cases, the multiplicity of an

The SDL-UML Profile Revisited

115

ownedAttribute shall be [1], which means that it is mandatory (see the example given in Fig. 3). According to the Z.100 [3], a ﬁeld of a structure data type introduces the following set of implicit deﬁned methods for accessing and modifying the value of that ﬁeld: – virtual field-modify-operation-name ( <ﬁeld sort> ) -> this S; – virtual field-extract-operation-name -> <ﬁeld sort> ; – field-presence-operation-name -> Boolean; The field-presence-operation-name method should only be present, when the corresponding ownedAttribute has a multiplicity of [0..1]. For the mapping of an ownedAttribute of a «Structure» data type towards the abstract syntax of SDL, the model speciﬁed in Sect. 12.1.7.2 of Z.100 [3] shall be applied. «Choice» The optional «Choice» stereotype extends the metaclass DataType with a multiplicity [0..1] (see Fig. 2). The stereotype corresponds to a SDL choice data type of the concrete grammar of SDL. This stereotype introduces additional constraints and appropriate mapping rules in addition to the «DataType» stereotype. The «Choice» can comprise a set of diﬀerent data types, but only one of those types can be used as the actual type of the choice. Before a «Choice» data type can be mapped to the abstract syntax of SDL, some transformations have to be applied on the concrete syntax level. An example of a «Choice» data type is shown in Fig. 3. Owned Attributes of a Choice Data Type: An ownedAttribute of a data type «Choice» shall be used in order to represent a particular variant of a choice type. The type property of such an ownedAttribute shall refer only to instances of other DataType speciﬁcations. Before a «Choice» data type can be mapped to the abstract syntax of SDL, the model speciﬁed in Sect. 12.1.7.3 of Z.100 [3] has to be applied. As result of this process, three new data type deﬁnitions in the concrete syntax are generated. Afterwards, these data type deﬁnitions have to be transformed into the abstract grammar of SDL. But in the case of SDL-UML, it is assumed that a standard compliant tool generates these data types only internally.

Fig. 3. Structure, Enumeration and Choice data type examples

116

A. Kraas

«Enumeration» The «Enumeration» stereotype represents the Literal-signature-set of a Valuedata-type-definition of the abstract grammar of SDL. The stereotype extends the metaclass Enumeration with a multiplicity of [1], which means that this stereotype is applied automatically. The elements referred by the ownedLiteral property of an «Enumeration» shall be mapped to the Literal-signature-set of the corresponding Value-data-type-definition. In general, the same constraints and semantics as speciﬁed in the actual version of the Z.109 [2] shall be used for the «Enumeration» stereotype of the proposed data type model. In addition, the rules of the «Enumeration» stereotype are extended by those speciﬁed in the context of the «EnumerationLiteral» stereotype. «EnumerationLiteral» The new stereotype «EnumerationLiteral» extends the EnumerationLiteral metaclass with a multiplicity of [1] As mentioned in the section before, this stereotype is introduced in order to increase the expressiveness of SDL literal data type speciﬁcations in SDL-UML. An «EnumerationLiteral» shall be mapped to a Literal-signature in the abstract grammar of SDL. Literal Names and Named Numbers: The «EnumerationLiteral» stereotype owns the optional tagged value namedNumber, which is of the type UnlimitedNatural. This tagged value is intended to make an distinction between SDL named numbers and literal names that represent literal signatures of a literal list. All signatures of such a list are arranged in ascending order and are (explicitly or implicitly) associated with a unique number. A named number is associated with an explicitly deﬁned number (e.g. green = 2) that deﬁnes the position of a literal signature in a list. In contrast, a literal name (e.g. blue) is implicitly associated with a number, because it is a shorthand notation that has to be transformed to a named number (blue = 3). During the transformation process the lowest number, which is still not used in a literal list, is determined and associated with the newly created named number. When the tagged value namedNumber is present, an «EnumerationLiteral» represents a SDL named number (see Fig. 3) and can be directly mapped to a Literal-signature. If namedNumber is not present, an «EnumerationLiteral» represents a literal name and the above-mentioned transformation has to be applied before it can be mapped to a Literal-signature. The third possibility to specify a literal — the SDL name class — is not intended to be supported, because its syntax is rather complex. Hence, the implementation eﬀort is expected to be very high. «PrimitiveType» The stereotype «PrimitiveType» extends the metaclass PrimitiveType with a multiplicity of [ so that this stereotype is applied automatically. The stereotype shall be mapped to the Value-data-type-definition in the abstract syntax of SDL.

The SDL-UML Profile Revisited

117

However, in the context of SDL-UML, a «PrimitiveType» shall only be used to represent the predeﬁned data types, for instance Integer, of SDL. As in the case of the actual version of SDL-UML, the predeﬁned types shall be contained in the Predefined Package. All predeﬁned data types contained in this package own the same sets of operations and literals as deﬁned by native SDL. Specialization of Predefined Data Types: The predeﬁned SDL-UML data types may be specialized by another «PrimitiveType». Depending on the kind of a predeﬁned data type, a specializing «PrimitiveType» can add new literals and operations. For the purpose of adding new literals, the «PrimitiveType» stereotype owns the tagged value ownedLiteral which is a composition (see Fig. 2). This tagged value shall only be present, when the predeﬁned base data type is speciﬁed in terms of a literal data type, for instance Integer. Hence, the predeﬁned parameterized data types of SDL-UML, e.g. String, must not be extended with additional literals. For this kind of data types it is only allowed to add additional Operations. «Operation» The stereotype «Operation» extends the metaclass Operation with a multiplicity of [1..1] so that this stereotype is applied automatically. An «Operation» is not only used in the context of data types, but also in «ActiveClass» elements. The semantics and constraints discussed here only applies for stereotypes associated with data types. Operators and Methods: As discussed in issue 5, the actual SDL-UML proﬁle does not support the explicit distinction between an operator and a method, as it is the case in the concrete syntax of SDL. Apart from implicitly generated operations which depend on the kind of the used data type, e.g. structure data type, operations can also be speciﬁed explicitly by the user. In contrast to an operator, which must always return a result, a result is optional for a method. Furthermore, only methods are permitted to be redeﬁned. Depending on the type of an operation (operator or method), it shall be mapped to a Static-operation-signature or a Dynamic-operation-signature in the abstract syntax of SDL. As proposed in [6], the isStatic property of an «Operation» shall be used in order to make a distinction between both types of operation signatures (see SuperType in Fig. 4). If the isStatic property of an «Operation» is true, it shall be mapped to a Static-operation-signature. Otherwise, an «Operation» shall be mapped to a Dynamic-operation-signature. Redefinition of Methods: The concrete syntax of SDL provides a mechanism to redeﬁne a method which means that a method in a super-type can be redeﬁned by a method in a derived sub-type. In the context of SDL, this feature is denoted as method virtuality. In UML an element can be redeﬁned, if its metaclass inherits from RedeﬁnableElement. Since Operation is such a metaclass, also in SDL-UML an «Operation» can be redeﬁned.

118

A. Kraas

Fig. 4. Example of operators and methods

Due to that in SDL only a method is permitted to be redeﬁned, in SDL-UML only an «Operation» with an isStatic property of false shall be allowed to be redeﬁned. The redeﬁnedOperation property of a redeﬁning «Operation» in a sub-type (see SubType in Fig. 4) shall refer to an operation of a supertype. At most, the redeﬁnedOperation property shall contain one reference. In addition, an «Operation» shall not be redeﬁned in further specializations contexts, when the isLeaf property is true. «Property» The stereotype «Property» extends the metaclass Property with a multiplicity of [1..1]. A «Property» is used in the context of SDL-UML elements associated with data types, and also by an «ActiveClass». The statements and rules discussed here only apply for the ﬁrst mentioned context. Only a «Structure» or «Choice» data type is permitted to own a «Property» as an ownedAttribute. The concrete constraints and mapping rules are speciﬁed in the context of the corresponding stereotypes. «Syntype» The new «Syntype» stereotype extends the DataType metaclass with a multiplicity of [0..1]. Therefore, this stereotype is optional for appropriate UML elements. The «Syntype» data type constrains an existing data type in order to restrict the usable literals. Syntype Constraint: The mandatory tagged value constraint of the «Syntype» stereotype shall be used to specify the constraint of a syntype deﬁnition. The tagged value shall reference an Expression representing a SDL constraint. Since in native SDL a syntype deﬁnition only consists of at most one constraint, the ownedAttribute and ownedOperation properties of a

The SDL-UML Profile Revisited

119

Fig. 5. Syntype example

«Syntype» shall be empty. In the example shown in Fig. 5, the NegativeInt syntype constrains the predeﬁned Integer type in such a way so that only negative integer values can be used. Associations to Data Types: The usage of the generalization mechanism of UML in order to establish an association between a «DataType» and a «Syntype» is considered to be not syntactically correct. That is because in UML a Generalization of a Classiﬁer is a relationship which represents a specialisation between a super-type and one of its sub-types. Hence, a Dependency shall be used in order to establish an association between a «DataType» DataType and a «Syntype» DataType.

5

Model for Value Specification

Apart from the new data type model proposed in the chapter before, a more appropriate model for the speciﬁcation of concrete values is discussed in this chapter. That is because the model for the speciﬁcation of values utilized in the most recent version of the SDL-UML proﬁle [2] has some drawbacks, which are presented below. 5.1

Actual Model for Value Specification

In order to specify concrete values for data types, the SDL-UML proﬁle provides several stereotypes that extend subclasses of the ValueSpeciﬁcation metaclass. The corresponding model is shown in Fig. 6. This model contains all metaclasses as speciﬁed by the UML abstract syntax (see [8] ﬁgure 7.6). In addition, also the extending stereotypes as speciﬁed in the most recent version of SDL-UML [2] are shown. For the sake of completeness, the OpaqueExpression metaclass is depicted in that model, even though this class is not used in the current version of SDL-UML. In general, concrete values have to be speciﬁed for user-deﬁned data types as well as for the 18 predeﬁned data types of SDL-UML. However, only values of four predeﬁned data types can be speciﬁed by particular SDL-UML elements. For this purpose, four metaclasses inheriting from the LiteralSpeciﬁcation metaclass are extended with stereotypes (e.g. LiteralBoolean). For the remaining predeﬁned data types and for user-deﬁned data types, a value shall be speciﬁed in terms of an «InstanceValue». The second purpose of this SDL-UML element is

120

A. Kraas

Fig. 6. Actual model for value specification

to represent a variable access in the context of an expression. Finally, the current model for value speciﬁcation of SDL-UML also contains the «Expression» stereotype which represents an SDL expression. 5.2

Limitations of the Actual Value Specification Mechanism

The most important drawback of the model for value speciﬁcation of the current version of SDL-UML is the semantics of the «InstanceValue» stereotype which is not compliant to the semantics speciﬁed by the UML-SS [8]. As before mentioned, the «InstanceValue» stereotype is intended for diﬀerent purposes. If the «InstanceValue» represents a variable access, its qualiﬁedName shall be mapped to a Variable-access. When the «InstanceValue» represents a literal of an enumeration, its qualiﬁedName property shall be mapped to a Literal. The semantics and mapping rules of the «InstanceValue» as speciﬁed in the most recent version of the SDL-UML proﬁle [2] are insuﬃcient, because: 1. Qualified Name: The qualiﬁedName property of an «InstanceValue» cannot be used for the mapping towards a Variable-access or a Literal. That is because the qualiﬁed name of a NamedElement is always derived automatically from the containing Namespace and the name of the element. In consequence, the qualiﬁedName of an «InstanceValue» cannot refer to another element. 2. Values of predefined data types: All predeﬁned data types of SDL-UML are speciﬁed in terms of a «PrimitiveType». But only an EnumerationLiteral or InstanceSpeciﬁcation can be referenced by the instance property of an

The SDL-UML Profile Revisited

121

«InstanceValue». In consequence, with an «InstanceValue» it is not possible to specify concrete values for the predeﬁned data types. Hence, a dedicated SDL-UML element is required for this purpose. 3. Mandatory instance property: No constraints or rules are speciﬁed in which manner the mandatory instance property of an «InstanceValue» has to be handled. As shown in Fig. 6, this property must reference an InstanceSpeciﬁcation or an EnumerationLiteral. However, as mentioned in the section before, four predeﬁned data types have to be represented by particular LiteralSpeciﬁcations, whereas values for the remaining data types should be represented by an «InstanceValue». This circumstance leads to a rather complex model for value speciﬁcation. In order to reduce this complexity, it should be considered to utilize only one kind of element which can represent values for every kind of predeﬁned or user-deﬁned data types. 5.3

New Model for Value Specification

One main objective of the new model for value speciﬁcation proposed here is to reduce the complexity. Hence, the number of stereotypes utilized for value speciﬁcation is reduced in contrast to the current version of SDL-UML. The second objective of the new model is to remedy the already discussed shortcomings of the «InstanceValue» stereotype. For an overview see Fig. 7.

Fig. 7. Enhanced value specification model

In order to achieve the ﬁrst objective, only the «LiteralValue» stereotype shall be used to represent values for each kind of predeﬁned and user-deﬁned data type. Hence, the four stereotypes extending the metaclasses which inherits from LiteralSpeciﬁcation, e.g. «LiteralInteger», are not any longer present. This applies also for the «InstanceValue» stereotype. The second objective can

122

A. Kraas

be achieved by making a distinction between a particular stereotype for value speciﬁcations and another one for representing a variable access. For the last mentioned purpose the stereotype «VariableAccess» shall be utilized. For the stereotypes «Expression» and «LiteralNull», the semantics and constraints as speciﬁed in the most recent version of the SDL-UML proﬁle [2] shall apply. «LiteralValue» The «LiteralValue» stereotype extends the metaclass OpaqueExpression with a multiplicity of [0..1] which means that this stereotype has to be applied manually. That is because the metaclass OpaqueExpression is extended with the second stereotype «VariableAccess» which shall not be applied at the same time. Each kind of literal value for predeﬁned and user-deﬁned data types shall be represented by the body property of an «VariableAccess». The type property shall refer to the data type for which the value is speciﬁed. The qualiﬁedName of the referenced data type shall be mapped to the Qualifier part of the Literal. The Name part of the Literal is derived from the body property of the «VariableAccess». Values for parameterized types (e.g. Array), «Structure» and «Choice» data types must not be speciﬁed in terms of a «LiteralValue». That is because values for these kinds of data types have to be assigned or accessed by an indexed variable assignment or an indexed primary expression. Both constructs are shorthand notations for an invocation of the Extract or Modify operator of the corresponding data type. «VariableAccess» The «VariableAccess» stereotype extends the metaclass OpaqueExpression with a multiplicity of [0..1]. In addition, the stereotype owns the tagged value variable which is of type TypedElement. That is because in SDL-UML, variables can be speciﬁed in two diﬀerent ways. On the one hand, an ownedAttribute of an «ActiveClass» or a «StateMachine» represents a variable. On the other hand, local variables can be deﬁned in the context of an «Activity». Since both elements inherit from the metaclass TypedElement, the tagged value variable shall also be of this type. A «VariableAccess» shall be mapped to a Variable-access in the abstract grammar of SDL. The qualiﬁedName of the element, which is referenced by the tagged value variable, maps to the Variable-identifier of the Variable-access. The body and the language properties of a «VariableAccess» shall be empty, because these properties are not used in the context of a variable access.

6

Conclusion

In this paper, the limitations of the data type model and value speciﬁcation model of the most recent version of the SDL-UML proﬁle are analyzed. Most of the discussed limitations are not a drawback of the current version of SDL-UML.

The SDL-UML Profile Revisited

123

That is because the limitations rest upon language features which are supported by SDL, but not by the current SDL-UML proﬁle. Hence, for both aspects a new model is proposed in this paper which could be used as a foundation for further discussions concerning the upcoming UML proﬁle for SDL-2010. However, if it is considered to adopt both models in a new standard version, additional eﬀort will be required in order to specify precise mapping rules and constraints. That is because in this paper only a semi-formal approach is used for the speciﬁcation of both models. In general, the Object Constraint Language (OCL) [10] could be used for the speciﬁcation of required constraints. Furthermore, also the mapping rules towards the abstract syntax of SDL should be deﬁned in a more formal approach, instead of using only a textual speciﬁcation. In addition, stereotypes of the proﬁle and their relations to the extended metaclasses of the UML-SS could be depicted in a graphical manner as it is the case for the abstract syntax of UML. This would improve the comprehensibility of the entire SDL-UML proﬁle.

References 1. International Telecommunication Union: Recommendation Z.109, SDL combined with UML (November 1999), http://www.itu.int/rec/T-REC-Z.109-199911-S/en 2. International Telecommunication Union: Recommendation Z.109, SDL–2000 combined with UML (June 2007), http://www.itu.int/rec/T-REC-Z.109-200706-I/en 3. International Telecommunication Union: Recommendation Z.100, Specification and Description Language (SDL) (November 2007), http://www.itu.int/rec/T-REC-Z.100/en 4. Kraas, A., Rehm, P.: Results in Using the New Version of the SDL-UML Profile. In: Joint ITU-T and SDL Forum Society Workshop on ITU System Design Languages, Geneva, Switzerland (2008) 5. European Telecommunication Standardization Institute: The UML Profile for Communicating Systems – DRAFT (2004), http://docbox.etsi.org/MTS/MTS/ 05-CONTRIBUTIONS/2004/200410-MTS39/39TD28%20UMLCS%20book.pdf 6. Kraatz, S., Hogrefe, D., Werner, C.: A UML Profile for Communicating Systems. In: Gotzhein, R., Reed, R. (eds.) SAM 2006. LNCS, vol. 4320, pp. 1–18. Springer, Heidelberg (2006) 7. International Telecommunication Union: Recommendation Z.119, Guidelines for UML Profile Design (February 2007), http://www.itu.int/rec/T-REC-Z. 109-200706-I/en 8. Object Management Group: OMG Unified Modeling Language (UML), Superstructure, V2.3 (2010), http://www.omg.org/spec/UML/2.3/Superstructure/PDF 9. International Telecommunication Union — ITU-T Study Group 17: Report on Question 13/17 (TAH03). Temporary Document TD 0867 Rev. 3 Geneva (April 7–16, 2010) 10. Object Management Group: Object Constraint Language, OMG Available Specification, Version_2.2 (2010), http://www.omg.org/spec/OCL/2.2/PDF

A Model Driven Approach for AMF Configuration Generation Pejman Salehi, Pietro Colombo, Abdelwahab Hamou-Lhadj, and Ferhat Khendek Department of Electrical and Computer Engineering, Concordia University 1455, de Maisonneuve W., Montreal, Canada H3G 1M8 {pe_saleh,colombo,abdelw,khendek}@ece.concordia.ca

Abstract. High availability of services is an important requirement for mission critical systems. The Service Availability Forum deﬁnes standards like the Availability Management Framework (AMF) to support the realization of high available systems. AMF is a middleware service that coordinates redundant application components to ensure the high availability of the provided services. In order to provide and protect services, AMF requires a conﬁguration that captures the organization of logical entities and their relations. It describes the service providers, the provided services, their types, and the deployment infrastructure. The process of generating an AMF conﬁguration requires the description of the software characteristics as well as the conﬁguration requirements that specify the services to be provided. Due to the large number of parameters to be taken into account, the generation of an AMF conﬁguration can be a diﬃcult and error prone task. This paper proposes a new approach for the automatic generation of AMF conﬁgurations. The proposed solution is model driven and is based on UML proﬁles which capture the concepts related to conﬁguration requirements, software description, and AMF conﬁgurations. AMF conﬁgurations are generated using ATL based transformations deﬁned between these diﬀerent proﬁles. Keywords: High Availability, Availability Management Framework, UML Proﬁle, Model Driven Approach, Conﬁguration Generation, Model Transformation, ATL.

1

Introduction

High availability of a software system is achieved when its services are accessible (or available) to its users 99.999% of the time [6]. The demand for highly available services is continuously growing in diﬀerent domains, such as banking and air traﬃc monitoring. Service outage in such systems may lead to important ﬁnancial loss or life injuries. The Service Availability Forum (SA Forum, [9]) is a consortium of telecommunications and computing companies that has deﬁned several standard interfaces to support the development of Highly Available (HA) systems. Such standards aim at reducing the application development time and cost by shifting the availability management from applications to a dedicated F.A. Kraemer and P. Herrmann (Eds.): SAM 2010, LNCS 6598, pp. 124–143, 2011. c Springer-Verlag Berlin Heidelberg 2011

A Model Driven Approach for AMF Conﬁguration Generation

125

middleware and hence enabling portability. Among the SA Forum standards, the Application Interface Speciﬁcation (AIS, [12]) supports the development of HA application by abstracting hardware and software resources. AIS deﬁnes the Availability Management Framework (AMF, [10]), which is the middleware service that manages the high availability of applications’ services by coordinating their redundant components. In order to provide and protect the services, AMF requires a conﬁguration that speciﬁes the characteristics of the entities and their organization. These entities describe the service providers, the provided services, their types, and the deployment infrastructure. The management of AMF conﬁgurations consists of diﬀerent activities, namely design, validation, analysis and upgrade from time to time. These activities require proper tool support. The goal of the MAGIC1 project is the deﬁnition of a model driven framework for the development, validation and upgrade of AMF conﬁgurations. This framework required a modeling language to support the speciﬁcation and validation of AMF conﬁgurations, which we deﬁned in previous work as UML proﬁles [8]. One key application of the framework is the design of AMF conﬁgurations. This design consists of generating AMF conﬁgurations from 1) the descriptions of the software resources to be used and the description of the deployment infrastructure, and 2) the requirements that specify the AMF services to be provided. The objective of this paper is to present a model based approach for generating AMF conﬁgurations using the previously deﬁned UML proﬁles. Compared to a code-centric approach such as the one proposed by Kanso et al. in [3,4], a model based method increases the level of abstraction, and therefore reduces the complexity of the generation process as well as potential errors and inconsistencies. Our approach consists of a set of transformation rules expressed in a declarative style and deﬁned among diﬀerent elements of our proﬁles. AMF conﬁgurations are generated through the application of the transformation rules to the model elements representing software entities and conﬁguration requirements. These rules abstract from the operational steps to be performed in order to generate the target elements. Transformation rules are illustrated using the ATLAS Transformation Language (ATL, [2]). The rest of the paper is organized as follows. Section 2 brieﬂy introduces the modeling framework composed of the UML proﬁles used to enable the modelbased generation of AMF conﬁgurations. In Sect. 3, we describe the model driven approach for generating AMF conﬁgurations. Section 4 discusses the related work, followed by our conclusion in Sect. 5.

2

The Modeling Framework

The modeling framework covers three diﬀerent domains: The AMF domain [10], Entity Type Files (ETF, [11]), and conﬁguration requirements. The rest of this 1

MAGIC (Modeling and Automatic Generation of Information and upgrade Campaigns for Service Availability) project is a joint project between Concordia University and Ericsson Software Research. http://encs.concordia.ca/~magic/

126

P. Salehi et al.

section describes these domains and introduces the UML proﬁles for them. These proﬁles contain the complete and comprehensive deﬁnitions of all the domain concepts, their relationships, as well as the constraints that exist among them. 2.1

The AMF Profile

An AMF conﬁguration for a given application is a logical organization of resources for providing and protecting services. The AMF conﬁguration proﬁle models both the resources and the services. In an AMF conﬁguration, resources and services are represented through a logical structure that allows AMF to manage resources in order to provide service availability. An AMF conﬁguration consists of two diﬀerent set of concepts: AMF entities and AMF entity types. AMF entities are categorized into diﬀerent logical entities representing services and software/hardware service provider’s resources. All these logical entities are modeled in terms of UML stereotypes. The basic entities are called Components. Components represent HW and/or SW resources capable of supporting the workload imposed by service functionalities. Such a workload is referred to as Component Service Instance (CSI). Components are aggregated into Service Units (SU), logical entities representing the basic redundancy unit for AMF. The aggregation of components favors the combination of their functionalities into higher level services. More speciﬁcally, the workloads of the components contained in an SU are aggregated into a Service Instance (SI), which represents the workload assigned to the SU. SUs are further grouped into Service Groups (SG) to protect a set of SIs by means of redundancy. SGs are classiﬁed according to the redundancy models used by AMF to protect the services. AMF supports the ’No redundancy’, 2N, N+M, N-Way and N-Way-Active redundancy models. These redundancy models vary depending on the number of SUs that can be active and on standby for the SIs and how these assignments are distributed among the SUs. In the 2N redundancy model one SU is active for all the SIs protected by the SG and one is on standby for all the SIs. In the N + M model, N SUs share the active assignments and M share the standby assignments. N+M allows at most one active and one standby assignment for each particular SI. An SG with the N-Way redundancy model contains N SUs. Each SU can have a combination of active and standby assignments. However, each SI can be assigned as active to only one service unit and as standby to several service units. An SG with the N-Way-Active redundancy model has N SUs, which are assigned only as active. It has no SU assigned as standby. Furthermore, each of the SIs protected by this SG can be assigned to more than one SU. An AMF application combines diﬀerent SGs in order to provide the SIs protected by these SGs. Each SU is deployed on an AMF node and the set of all AMF nodes forms the AMF cluster. AMF entity types deﬁne the common characteristics among multiple instances of the previously deﬁned logical entities. In AMF, all entities except the deployment entities (i.e., node and cluster) have a type. Figure 1 shows an example of an AMF conﬁguration. In this example, a cluster is composed of two nodes (Node1 and Node2). It hosts an application consisting

A Model Driven Approach for AMF Conﬁguration Generation

App1

Active Standby

SG1

Node 1

Node2

SU1

SU2

Component1

Component3

Component2

Component4

SI1

CSI1 CSI2

SI2

127

APT-A SGT-A

CSI3 CSI4

SUT-A CT-A

CT-B

CST-A

CST-B

SVCT-A

Fig. 1. An example of AMF conﬁguration

of one service group protecting two service instances in a 2N redundancy model. The service group consists of two service units, SU1 and SU2, each composed of two components. The distribution of the active and standby assignments is shown in this ﬁgure. However it is not part of the conﬁguration as deﬁned by AMF as this is decided by AMF at runtime. The entities presented in the conﬁguration are described by means of the following AMF types: Component1 and Component3 are from the ComponentType CT-A, while Component2 and Component 4 from CT-B. Both the SUs are represented by the same SUType called SUT-A. SG1 and App1 are from the type SGT-A and APT-A, respectively. At the service level, both SIs are from the type SVCT-A while the CSIs are from two diﬀerent types. More speciﬁcally, CSI1 and CSI3 are of the type CST-A while CSI2 and CSI4 are from the type CST-B. 2.2

The Entity Type Files (ETF) Profile

Vendors provide a description of their software in terms of implemented entity types by means of XML ﬁles called ETF [11]. These ETF types specify intrinsic characteristics of the software as well as its capabilities and limitations. Moreover, they describe how the software entities can be combined by providing information regarding their dependencies and compatibility options. ETF entity types and AMF entity types describe the same logical entities from two diﬀerent perspectives. AMF deals with types from a conﬁguration and runtime management point of view, while ETF projects the description of the software from the vendor’s point of view. As a result, the UML proﬁle that models the ETF types has a structure similar to the AMF Entity Type package. An ETF model must provide at least two types: the Component Types and the Component Service Types (CSTypes). Other entity types such as Service Type (SvcType), Service Unit Type (SUType), Service Group Type (SGType),

128

P. Salehi et al.

SUT-AA CT-AA CT-BB CST-AA

CT-CC

CST-BB

SVCT-AA

CST-CC

SVCT-BB

SVCT-CC

Fig. 2. An example of ETF model

and the Application Type (AppType) may also be used in order to capture limitations and constraints of the application. However, they do not have to be provided in ETF. For instance, Fig. 2 describes the ETF types that have been used to generate the AMF conﬁguration shown in Fig. 1. The ETF model speciﬁes the Component Types CT-AA, CT-BB and CT-CC. CT-AA provides CST-AA, while CT-BB provides CST-BB and CT-CC provides CST-CC. CST-AA and CST-BB are grouped in the service type SVCT-AA. CST-BB and CST-CC in the service type SVCT-BB while the service type SVCT-CC aggregates CST-CC. Moreover, CTAA in providing CST-AA requires CT-BB to provide CST-BB. Finally, there exists an SUType (SUT-AA) aggregating CT-AA and CT-BB which provides SVCT-AA. 2.3

The Configuration Requirements (CR) Profile

Conﬁguration requirements specify the set of services to be provided by a given software system through the target AMF conﬁguration. More speciﬁcally, they deﬁne diﬀerent characteristics of the services such as their types, the number of instances of a certain service type, the relationships between services, and the level of protection, expressed, in the context of AMF, in the form of redundancy models. The speciﬁcation of the conﬁguration requirements is deﬁned as templates to help the conﬁguration designer specify common characteristics shared by multiple SIs (using SITemplates) and CSIs (by means of CSITemplates). The CSITemplate deﬁnes the CSType with the required number of CSIs. The SITemplate speciﬁes the SIs with the associated SvcType, the required redundancy model to protect them, and the associated CSITemplates. Figure 3 shows an example of conﬁguration requirements model for which the conﬁguration in Fig. 1 is generated from the ETF model in Fig. 2. This conﬁguration requirement model speciﬁes an SITemplate named SITemp1 that aggregates two CSTemplates called CSITemp1 and CSITemp2. SITemp1 speciﬁes the requirements for two SIs of type SVCT-AA and the protection level of 2N redundancy model. CSITemp1 and CSITemp2 require one CSI from the type CST-AA and CST-BB, respectively. The model also speciﬁes a dependency

A Model Driven Approach for AMF Conﬁguration Generation

SITemp1 #Sis = 2 Svct = SVCT-AA RM = 2N

CSITemp2 #CSIs = 1 CST = CST-BB

129

Cluster1

CSITemp1

#CSIs = 1

CST = CST-AA

NodeTemp1 #Nodes = 2

Fig. 3. An example of CR model

requirement between CSITemp1 and CSITemp2. This implies that the services which will be created based on CSITemp1 will be dependent on the services based on CSITemp2. Finally, the required deployment infrastructure is speciﬁed in terms of NodeTemplate and the properties of the cluster are modeled using an element called Cluster.

3

A Model Driven Approach for AMF Configuration Generation

In this section, we describe our model based approach for AMF conﬁguration generation. It is based on the UML proﬁles described in the previous section. It consists of a set of transformations among models that are instances of the previously described proﬁles. Figure 4 illustrates the diﬀerent artifacts involved in the generation. The input for the transformation consists of conﬁguration requirements and the description of software to be protected, while the output of the transformation is an AMF conﬁguration for the software that satisﬁes the conﬁguration requirements. The inputs and output are modeled as instances of diﬀerent proﬁles. The transformation process consists of three distinct phases, namely, 1) the selection of the software to be used to satisfy the requirements, 2) the creation of proper AMF entity types based on the selected ETF types, and 3) the instantiations of AMF entities related to each AMF entity types (see Fig. 5). More speciﬁcally, the conﬁguration generation method proceeds with selecting the appropriate ETF types for each service speciﬁed by the requirements. Therefore, the selected software is used to derive the AMF types and to instantiate the AMF entities that will compose the conﬁguration. The transformation phases described in Fig. 5 are composed of several steps. In the rest of this section we discuss the details of each transformation phase. A running example is used throughout the rest of the paper in order to present the eﬀects of each transformation phase. Using this example, we incrementally generate an AMF conﬁguration starting from the software described with the ETF model in Fig. 2 and considering the conﬁguration requirements presented in Fig. 3.

130

P. Salehi et al.

<>

<>

<>

Fig. 4. The overall process of model based AMF conﬁguration generation

<>

<> <>

<>

ETF Type Selection

AMF Entity Creation

AMF Type Creation

Fig. 5. The detailed phases of model based AMF conﬁguration generation

3.1

ETF Type Selection

This phase consists of selecting the appropriate entity types from the ETF descriptions, pruning the ones that do not satisfy the conﬁguration requirements. As presented in Fig. 5 the input and output artifacts of this transformation phase are instances of the same meta-models. Therefore, the transformation phase generates an output model which is mainly the reﬁned input model. This phase bridges the gap between conﬁguration requirements and software descriptions by selecting appropriate ETF types to provide the required services. As illustrated in Fig. 6 the type selection is articulated into four distinct steps. The ﬁrst two steps bridge the gap between conﬁguration requirements and software descriptions elements. More speciﬁcally, they establish the link between the

A Model Driven Approach for AMF Conﬁguration Generation

CSITemplate Refinement

SITemplate Refinement

Dependency driven Refinement

131

Refinement Completion

Fig. 6. The transformation steps for ETF Type Selection phase

CSITemplates and SITemplates on one end, and the appropriate ETF types to be used for the service provision on the other side. The third step reﬁnes the previously selected ETF types based on the dependency relationships deﬁned at the level of conﬁguration requirements. Finally, the fourth step discards useless elements from the analyzed ETF model. Component Type Selection. The ﬁrst step of this phase consists of selecting the Component Types capable of providing the required services described in terms of CSITemplates in the conﬁguration requirements. This activity requires visiting both input models (see Fig. 4), with the aim to identify the proper model elements. r u l e CompTypeSelection { from s : M a g i c C o n f i g R e q P r o f i l e ! CSITemplate to t : M a g i c C o n f i g R e q P r o f i l e ! CSITemplate ( t . p r o p e r C t <− p r o p e r C t F i n d e r ( ) ) }

(1)

The ATL Code 1 describes the transformation rule that ﬁnds the proper Component Types for each CSITemplate. The rule uses the properCtFinder helper function which selects types according to diﬀerent criteria. Each CSITemplate speciﬁes the CSType that identiﬁes the type of the CSI that needs to be provided, as well as the number of CSIs. For each Component Type properCtFinder evaluates whether the Component Type can provide the required CSType. More speciﬁcally, each required CSType is compared with the list of CSTypes that can be provided by the Component Type. Code 2 shows the part of the helper function that selects the proper Component Types based on the supported CSTypes. properCtFinder uses OCL syntax to deﬁne the selectedCompType data structure where it collects the selected types. h e l p e r c o n t e x t M a g i c C o n f i g R e q P r o f i l e ! CSITemplate def : properCtFinder () : Set ( M a g i c E t f P r o f i l e ! MagicEtfComptype ) =l e t selectedCompType : Set ( M a g i c E t f P r o f i l e ! MagicEtfComptype ) = MagicEtfCtCSType . a l l I n s t a n c e s −>s e l e c t ( c t c s t | c t c s t . m a g i c E t f S u p p o r t e d C s T y p e = s e l f . csiCSType . . .

(2)

132

P. Salehi et al.

In addition, we need to consider if the component capability model of the type conforms to the required redundancy model. The capability model speciﬁes the capacity of the Component Type in terms of the number of active and/or standby CSI assignments (of the given CSType) that a component of that type can support. As speciﬁed in AMF sub-proﬁle, applying diﬀerent redundancy models imposes diﬀerent constraints on the capability model. The redundancy model is speciﬁed by the SITemplate. Continuing with the deﬁnition of the helper function, Code 3 expresses the constraint imposed by N-Way redundancy model. and i f s e l f . c s i T e m p l a t e B e l o n g s T o . magicCRSITempRedundancyModel = ’SA_AMF_N_WAY_REDUNDANCY_MODEL’ then c t c s t . magicEtfCompCapabilityModel = ’MAGIC_ETF_COMP_X_ACTIVE_AND_Y_STANDBY’

(3)

If the selected Component Types has a parent SUType the function takes into consideration the number of components of the Component Type that can be included in an SU. Consequently, the number of Components of this Component Type in an SU has to be capable of supporting the load of CSIs of the particular CSType. The load of active/standby assignments required by the CSITemplate is related to the one of the parent SITemplate. The number of SI assignments that should be supported by a SU that aggregates Components of the selected Component Types depends on the redundancy model speciﬁed in the Conﬁguration Requirements model. The maximum load of CSI that should be supported by such an SU is the product of the SI load and the number of CSIs speciﬁed by the current CSITemplate. The required services need to be provided by the software entities. Therefore, properCtFinder has to check the capacity of Component Types and SUTypes with respect to the number of possible active/standby assignments they can provide. More speciﬁcally, we need to ﬁnd the maximum number CSIs of a CSType that can be provided by the Components aggregated in an SU. The ETF speciﬁes the maximum number of components of a particular Component Type that can be aggregated into the SUs of a given SUType (magicEtfMaxNumInstances). Besides, for each Component Type, the ETF speciﬁes also the maximum number of CSIs active/standby assignments of each supported CSType (magicEtfMaxNumActiveCsi and magicEtfMaxNumStandbyCsi). As a result, the active/standby capacity of SUs of a given SUType in handling assignments of CSIs of a given CSType is the product of magicEtfMaxNumInstances and magicEtfMaxNumActiveCsi/ magicEtfMaxNumStandbyCsi. As a result, a Component Type aggregated into a given SUType can be selected only if it provides the capacity to handle the load required by a CSITemplate. ATL Code 4 selects Component Type capable of supporting the required active load for the case of N-Way redundancy model.

A Model Driven Approach for AMF Conﬁguration Generation

133

and i f c t c s t . m a g i c E t f S u p p o r t e d b y . MagicEtfCtSut −>notEmpty ( ) t h e n (4) c t c s t . magicEtfSupportedby . MagicEtfCtSut −>s e l e c t ( c t s u t | c t s u t . magicEtfGroupedB y . m a g i c E t f S v c t S u t −> e x i s t s ( s v c s u t | s v c s u t . m a g i c E t f P r o v i d e s S v c T y p e = s e l f . c s i T e m p l a t e B e l o n g s T o . s i S v c T y p e ))−> f o r A l l ( ctsutTemp | ctsutTemp . m a g i c E t f M i n N u m I n s t a n c e s∗ c t c s t . magicEtfMaxNumActiveCsi >= s e l f . magicCRCSITempNumCSIs ∗ s e l f . c s i T e m p l a t e B e l o n g s T o . magicCRSITempNumSIs / s e l f . c s i T e m p l a t e B e l o n g s T o . magicCRSITempNumActiveSus . . .

Moreover, if the SUType has a parent SGType, the redundancy model of the SGType has to match the one speciﬁed in the SITemplate which contains the current CSITemplate. ATL Code 5 complements the properCtFinder function by verifying the compliance of the redundancy models. (5) and i f ctsutTemp . magicEtfGroupedB y . magicEtfGroupedBy −>notEmpty ( ) t h e n ctsutTemp . magicEtfGroupedB y . magicEtfGroupedBy−>e x i s t s ( s g t | s g t . magicEtfSgtRed u nd an cyM o d el = ’SA_AMF_N_WAY_REDUNDANCY_MODEL’ ) The eﬀects of this step on the running example are illustrated in Fig. 7. CSITemp1 speciﬁes the requirements for a CSI of type CST-AA. The transformation consists of ﬁnding in the ETF model the CompTypes capable of providing such a CSType. The analysis of the model results in only one CompType, namely CT-AA. Such element, once identiﬁed, is connected to the CSITemplate updating the list of proper component types for the CSType. The same process is applied to CSITemp2 resulting in the selection of CT-BB based on the capability of providing CST-BB. If the set of Component Types selected by the properCtFinder is empty, the analysed ETF model cannot satisfy the conﬁguration requirements and therefore the conﬁguration cannot be designed. Otherwise, the reﬁnement process moves the focus from the level of selecting Component Types for CSITemplates, to ﬁnding the proper SUTypes for SITemplates. SU Type Selection. The second step of reﬁnement process consists of selecting the SUTypes of the ETF model capable of providing the services required by the SITemplates speciﬁed in the Conﬁguration Requirements model. The selection operated in this phase uses ATL rules and helper functions similar to the ones deﬁned in the previous section. Although the implemented criteria are similar, the selection is operated at a diﬀerent level of granularity. More speciﬁcally, in this phase the ETF model is further reﬁned with respect to the properties required by the SITemplates.

134

P. Salehi et al.

(6)

r u l e SUTypeSelection { from s : M a g i c C R P r o f i l e ! S I T e m p l a t e to t : MagicCRProfile ! SITemplate ( t . properSUT<− p r o p e r S U T F i n d e r ( ) ) }

ATL Code 6 presents the rule which deﬁnes the link between the SITemplates and the selected SUTypes by using the properSUTFinder helper function. As the ﬁrst step, this function identiﬁes the set of SUTypes capable of providing the SvcType associated with a given SITemplate. Then, it extracts from this set, those SUTypes capable of supporting the load of SIs according to the required redundancy model. Figure 7 shows the eﬀect of this transformation step on the running example. The reﬁnement results in the identiﬁcation of a proper SUType, namely SUT-AA, capable of providing the SvcType SVCT-AA speciﬁed by the SITemplate SITemp1. Therefore, as illustrated with the dash-dot-dotted connection, the identiﬁed types are connected to the SITemplate SITemp1.

SUT-AA SITemp1 #Sis = 2 Svct = SVCT-AA RM = 2N

CT-AA CT-BB CST-AA

CSITemp2 CSITemp1 #CSIs = 1 #CSIs = 1 CST = CST-BB CST = CST-AA

CSITemplate Refinement SITemplate Refinement

CT-CC

CST-BB

SVCT-AA

CST-CC SVCT-BB

SVCT-CC

Dependency driven Refinement Refinement Completion

Fig. 7. The result of ETF Type Selection phase

Dependency Analysis. In this step, we take into account the dependency relationships that exist both at the level of conﬁguration requirements elements and at ETF model elements level. In the conﬁguration requirements model the dependency relationships are deﬁned between CSITemplates and between SITemplates. In the ETF model, the dependency relationships are speciﬁed between the Component Types in providing CSTypes and between SUTypes in providing SvcTypes. The objective of this step is to reﬁne the previously selected ETF types based on the dependency relationships deﬁned at the level of conﬁguration requirements. More speciﬁcally, all ETF types that do not respect the dependency requirements need to be pruned out from the set of selected types. This

A Model Driven Approach for AMF Conﬁguration Generation

135

step consists of the reﬁnement of the set of proper Component Types for each CSITemplate, and the reﬁnement of the set of appropriate SUTypes for each SITemplate. In case the CSITemplate speciﬁes at least one dependency relationship to another CSITemplate, the proper Component Types should specify a dependency relationship in providing the CSType which is compliant with the relationship deﬁned at the level of CSITemplate. For instance, let us consider a scenario in which a dependency relationship is deﬁned between two CSITemplates named CSITemplateA and CSITemplateB. CSITemplateA is associated with the CSTypeA, while CSITemplateB with CSTypeB. Moreover, CSITemplateA is associated with a set of Component Types capable of providing CSTypeA, and CSITemplateB with a set of Component Types capable of providing CSTypeB. The reﬁning consists in selecting from the set of Component Types associated with CSITemplateA those types that speciﬁes a dependency in providing CSTypeA to at least one Component Type associated with CSITemplateB in providing CSTypeB. The reﬁnement updates the set of properCt by selecting all the Component Types that specify at least one dependency in providing the CSType associated with the CSITemplate. This reﬁnement takes into account the dependency relationship in both directions. More speciﬁcally, it considers both the case in which a CompType depends on other CompTypes in providing a CSType, and the case in which a given CompType in providing a CSType depend by other CompTypes. Both cases are supported using similar ATL reﬁnement rules. ATL Code 7 presents the dependency based reﬁnement for the ﬁrst case. (7) r u l e CSITempDependOnRefinement { from s : M a g i c C R P r o f i l e ! CSITemplate ( s . csiTemplateDependsOn −>notEmpty ( ) ) t o t : M a g i c C R P r o f i l e ! CSITemplate ( p r o p e r C t <−s . c s i C s T y p e . MagicEtfCtCSType−>s e l e c t ( s o u r c e c t c s t | s . p r o p e r C t −>i n c l u d e s ( s o u r c e c t c s t . magicEtfSupportedby )) −>s e l e c t ( t a r g e t c t c s t | s . csiTemplateDependsO n −>f o r A l l ( c s i t e m p | t a r g e t c t c s t . m a g i c E t f R e q u i r e s −>i n t e r s e c t i o n ( c s i t e m p . c s i C s T y p e . MagicEtfCtCSType −>s e l e c t ( r e q u i r e d c t c s t | c s i t e m p . p r o p e r C t −>i n c l u d e s ( r e q u i r e d c t c s t . m a g i c E t f S u p p o r t e d b y ) ) ) −>notEmpty ())) −> c o l l e c t ( c t c s t | c t c s t . m a g i c E t f S u p p o r t e d b y ) ) } In case the SITemplate speciﬁes at least one dependency relationship to another SITemplates, the proper SUTypes should specify a dependency relationship in providing the SvcType which is compliant with the relationship deﬁned at the level of SITemplate. This case is handled by a reﬁnement rule which updates the

136

P. Salehi et al.

set of properSUT by selecting all the SUTypes that specify at least one dependency in providing the SvcType associated with the SITemplate. This rule is also implemented using ATL code similar to the one speciﬁed above. Continuing with the running example in Fig. 7, since the dependency relationship between CSITemp1 and CSITemp2 complies with the CompType-CSType dependency between CT-AA in providing CST-AA and CT-BB in providing CST-BB, this step does not further reﬁne the already selected CompType. For the case of SITemplate, since no dependency relationships is speciﬁed in the CR model, no further reﬁnement has been applied. Completing the refinement. The previously selected ETF types represent the essential software resources that can be used to design an AMF conﬁguration which satisﬁes the conﬁguration requirements. In order to complete this transformation phase it is required to prune out the unselected and irrelevant types from the ETF model. In the rest of this section we present some of the ATL rules to transform the current ETF model into a model which contains only the selected types. Code 8 focuses on the Component Type by transforming the set that has been previously linked to the CSITemplates. The transformation is creating into the target model, Component Types elements with the same set of attributes of the selected ones. r u l e CompTypePruning { from s : M a g i c E T F P r o f i l e ! MagicEtfCompType ( MagicConfigReq : : CSITemplate . a l l I n s t a n c e s −>e x i s t s ( c s i t e m p | c s i t e m p . p r o p e r C t −>i n c l u d e s ( s ) ) ) t o t : M a g i c E T F P r o f i l e ! MagicEtfCompType ( t . m a g i c E t f C t V e r s i o n <− s . m a g i c E t f C t V e r s i o n . . .

(8)

A similar rule (see Code 9) is applied for the pruning out the SUTypes. However this pruning also requires identifying the SGTypes capable of supporting at least one of the previously selected SUTypes. r u l e SGTypePruning { from s : M a g i c E T F P r o f i l e ! MagicEtfSGType ( MagicConfigReq : : S I T e m p l a t e . a l l I n s t a n c e s −>e x i s t s ( s i t e m p | s i t e m p . properSUT −> i n t e r s e c t i o n ( s . m a g i c E t f G r o u p s )−>notEmpty ( ) ) ) t o t : M a g i c E T F P r o f i l e ! MagicEtfSGType ( t . m a g i c E t f S g t A u t o A d j u s t P e r i o d <−s . m a g i c E t f S g t A u t o A d j u s t P e r i o d ...

(9)

The SvcTypes pruning is easily realized by operating on the SvcTypes which are linked by SITemplates. As previously mentioned, the only mandatory elements in ETF model are Component Types and CSTypes. Therefore, SUTypes, SGType, ApplicationType and Service Types might not exist in the ETF model.

A Model Driven Approach for AMF Conﬁguration Generation

137

The reﬁnement phase does not aim at modifying the ETF model by completing the deﬁnition of the missing types. This issue is addressed in the second phase of the transformation process by creating AMF types as the combination of the types of reﬁned ETF model. The Conﬁguration Requirements model is transformed by copying all its elements without any further change. The CSITemplates and SITemplates elements and their previously deﬁned links to the ETF types are preserved for the following phase of the transformation. Back to our running example, the eﬀects of this step are presented in Fig. 7. It is shown in terms of the cross marks on the irrelevant elements that need to be pruned out from the model. More speciﬁcally, since CT-CC has not been selected for any of the CSITemplates, it cannot be used for the generation and thus is pruned out of the model. CST-CC is not required by any CSITemplates and therefore is left out from the model. Similarly, SVCT-CC and SVCT-BB are pruned out since they are not required by any SITemplates. 3.2

AMF Entity Type Creation

This phase mainly consists of generating the AMF entity types to be used for the AMF conﬁguration design. As shown in Fig. 5, this transformation phase takes as input the ETF model reﬁned by the transformation phase described in Sect. 3.1. This phase creates and conﬁgures AMF entity types based on the selected ETF types. It also creates the links between AMF entity types and Conﬁguration Requirements considering the possible relationships that exists between the ETF types and CSITemplates or SITemplates. For example, an AMF Component Type can be created based on a selected ETF Component type in the reﬁned ETF model. In addition the generated AMF Component Type has to be linked to the CSITemplates connected to the ETF type. It is possible to have ETF types that are not aggregated into other ETF types according to the hierarchical structure in the ETF model. For example, Component Types may not be aggregated by any SUType, similarly CSTypes may not be aggregated into a SvcType. Although missing ETF types are tolerated in ETF models, in order to generate an AMF conﬁguration it is required to have the complete hierarchy of types. Therefore, to complete the hierarchy, the transformation process builds AMF entity types based on a set of existing ETF types. For the previously mentioned example, we need to create an AMF SUType based on the existing Component Types as well as the AMF SvcTypes based on the existing CSTypes. In rest of this section, we discuss the details of the AMF entity type creation step and present some of the transformation rules. AMF Component Types are generated starting from the selected ETF Component Types. The generated AMF Component Type captures all the characteristics of the according ETF type, such as the dependencies and capability model speciﬁed for each provided CSTypes as well as the link to the proper CSITemplate.

138

P. Salehi et al.

The generation is operated by the AMFCompTypeCreation transformation rule (see Code 10). This ATL rule transforms an ETF Component Type into an AMF Component Type based on the properties deﬁned by the ETF type. r u l e AMFCompTypeCreation { from s : M a g i c E T F P r o f i l e ! MagicEtfCompType t o t : MagicA MFProfile ! MagicSaAmfCompType ( t . CSITemp<− s . CSITemp ,−−C r e a t i n g t h e l i n k t o CSITemplate t . magicSaAmfCtRelPathAmStartCmd <−s . magicEtfCtAmStartCmd

(10)

The selected ETF Component Type may be aggregated into an SUType or it may be “orphan”, i.e. does not have a parent SUType. For the former case the AMF SUType generation is based on the selected ETF SUTypes aiming at generating a new AMF type which captures all the characteristics of the ETF types. In case of missing SUTypes, it is required to generate a new AMF SUType which aggregates the newly created AMF Component Types. The creation of missing SUType is supported by the ATL rule presented in Code 11. The rule identiﬁes a missing SUTypes from the set of selected ETF SUType for a given SITemplate. Whenever this set is empty a new AMF SUType is created by grouping the selected Component Types of the CSITemplates of the current SITemplate. The generation also considers the higher levels of the AMF type hierarchy by generating SGType and ApplicationType on top of the newly created SUType. r u l e TypeCreationFr om Mi s si n gS UT yp e { from s : M a g i c C o n f i g R e q P r o f i l e ! S I T e m p l a t e ( s . properSUT−>i s E m p t y ( ) ) to t1 : Ma g ic Conf igR e qPr of ile ! SITemplate ( t 1 . properSUT<−t 2 ) , t 2 : MagicAMF ! MagicSaAmfSUType ( t 2 . magicSafMemberCompType <−(s . siTempGroups −> c o l l e c t ( c s i t | c s i t . p r o p e r C t −>a t ( 1 ) ) ) ), t 3 : MagicAMF ! MagicSaAmfSGType ( t 3 . saAmfSgtValidSuT yp es <− t 2 ), t 4 : MagicAMF ! MagicSaAmfAppType ( t 4 . magicAmfApptSGTypes<− t 3 ) }

(11)

The creation of the other AMF entity types is deﬁned using similar ATL rules and thus, it is not presented here. Continuing with our running example, Fig. 8 presents the eﬀect of this phase. The AMF component types CT-A and CT-B are created based on the ETF types CT-AA and CT-BB satisfying the requirements of CSITemp1 and CSITemp2, respectively, by providing CST-A and CST-B. CST-A and CST-B are created based on the ETF types CST-AA and CST-BB. Similarly, starting from the

A Model Driven Approach for AMF Conﬁguration Generation

139

APT-A SUT-AA SGT-A

SITemp1 #Sis = 2 Svct = SVCT-AA RM = 2N

SUT-A

CT-AA CT-BB ĚĞƉĞŶĚƐ CST-AA

CT-A

CT-B

CST-A

CST-B

SVCT-A

CSITemp2 #CSIs = 1 CST = CST-BB

CST-BB

ĚĞƉĞŶĚƐ CSITemp1

#CSIs = 1 CST = CST-AA

SVCT-AA

AMF CompType/CST Creation AMF SUT/SvcT/SGT/AppT Creation

Fig. 8. The result of AMF Type Creation phase

selected ETF types connected to the SITemp1, SUT-A is created capable of providing the created SVCT-A. Moreover, since the selected ETF model does not have any appropriate SGTypes and AppTypes, SGT-A and APT-A AMF types are created from scratch. Finally, the created AMF types are connected to the conﬁguration requirements model by specifying the link between SITemp1, CSITemp2, and CSITemp2 on one side, and created AMF types on the other side. 3.3

AMF Entity Instantiation

After creating the AMF entity types, the ﬁnal phase of the transformation concerns creating the AMF entities for each previously deﬁned AMF entity type based on the information captured by the Conﬁguration Requirements. Such entities are the basic elements of the AMF conﬁguration. As shown in Fig. 4, this phase takes as input the reﬁned CR model and the AMF model consisting of the generated AMF entities types. As a result of the previous transformation step, these models are connected by means of links deﬁned among the AMF entity types on one side and the SITemplates and CSITemplates on the other side. The main issue of this step is determining the number of entities that need to be generated for each identiﬁed entity type. The ﬁrst objective is to identify the number of Components capable of supporting required load of the SIs that will be assigned to each SU. This load is based on the required redundancy model and the preferred number of SI assignments. For a given CSITemplate, the number of components capable of supporting the required number of CSIs is based on the capacity of the Component in providing these CSIs and the load that will be assigned to the SU. The following ATL rule generates the suﬃcient number of AMF Components for a given CSITemplate. In this rule the active load of an SU is calculated based on the required redundancy model. Afterward, the number of required components

140

P. Salehi et al.

to support the load is calculated, and the suﬃcient number of components of the proper type is created using the CreateComponent helper function presented in Code 12. (12)

r u l e CompCreation { from s : M a g i c C o n f i g R e q P r o f i l e ! CSITemplate using { SuA c tive load : I n t e g e r = i f s . csiTemplateBelongsTo . magicCRSITempRedundancyModel= ’SA_AMF_N_WAY_REDUNDANCY_MODEL’ t h e n s . c s i T e m p l a t e B e l o n g s T o . magicCRSITempNumSIs / s . c s i T e m p l a t e B e l o n g s T o . magicCRSITempNumActiveSus . . .

NumOfComp : I n t e g e r = S u A c t i v e l o a d ∗ s e l f . magicCRCSITempNumCSIs / ( MagicSaAmfCtCsType . a l l I n s t a n c e s −>s e l e c t ( c t c s t | c t c s t . magicA mfSupportedby=s . p r o p e r C t −>a t ( 1 ) and c t c s t . m a g i c S a f S u p p o r t e d C s T y p e=s . csiCSType )−>a t ( 1 ) . MagicEtfMaxNumActiveCsi ) ; } t o t : M a g i c C o n f i g R e q P r o f i l e ! CSITemplate ( CreateComponent (NumOfComp , s . p r o p e r C t −>a t ( 1 ) )

For a given SITemplate the required number of SUs in the SG is explicitly deﬁned in the same template. Therefore, the generation of SUs is a straightforward activity similar to the creation of Components. One SG is created in order to protect the SIs of a certain SITemplate aggregating all the SUs generated to provide these SIs. Moreover, for the sake of simplicity, we group all the SGs of the whole conﬁguration in one Application. After creating service provider and service entities based on the previously generated entity types, this step generates the deployment entities (a single Cluster composed of multiple Nodes) and deploys the SUs on the Nodes. Our approach assumes that all the nodes are identical and thus the SUs are distributed among nodes evenly. The number of nodes and their attributes are explicitly speciﬁed in the CR model by means of the NodeTemplate. Since the creation of the SGs, Application, Nodes, and Cluster is rather straightforward, the required transformation rules are not presented here. Back to the running example, Fig. 9 presents the result of this generation phase. Based on the previously generated AMF types and on the conﬁguration requirements, this step generates all the AMF entities contained in the ﬁnal conﬁguration. More speciﬁcally, in terms of entities, the conﬁguration consists of an application App1, of type APT-A which aggregates a single Service Group, SG1, of type SGT-A. SG1 aggregates two service units SU1 and SU2, both of type SUT-A. SG1 protects two SIs called SI1 and SI2, both of type SVCT-A by means of the 2N redundancy model. SU1 aggregates two components Component1 and Component2 of type CT-A and CT-B, respectively, while SU2 groups Component3 and Component4 from the type CT-A and CT-B. SI1 groups CSI1 and CSI2 of type CST-A and CST-B, respectively, while CSI3 and CSI4 from

A Model Driven Approach for AMF Conﬁguration Generation

App1

APT-A

(APT-A)

CT-A

CT-B

CST-A

CST-B

CSITemp2 #CSIs = 1 CST = CST-BB

Node2

SU1(SUT-A)

SU2(SUT-A)

Component1

SITemp1 #Sis = 2 Svct = SVCT-AA RM = 2N

SUT-A

Node 1 SG1 (SGT-A)

SGT-A

ĚĞƉĞŶĚƐ

CSITemp1 #CSIs = 1 CST = CST-AA

Component3

(CT-A)

(CT-A)

Component2

Component4

(CT-B)

(CT-B)

SI1 (SVCT-A)

SVCT-A

141

CSI1

SI2

CSI3

(CST-A)

(SVCT-A)

(CST-A)

CSI2

CSI4

(CST-B)

(CST-B)

Fig. 9. The result of AMF Entity Creation phase

the type CST-A and CST-B are aggregated by SI2. Moreover, at deployment level two identical Nodes, Node1 and Node2, are created to host SU1 and SU2, respectively. A single Cluster is generated to group these nodes.

4

Related Work

In our previous work [4,3] we proposed pure algorithmic solutions for the generation of AMF conﬁgurations. Both approaches have been implemented in a prototype tool capable of generating AMF conﬁgurations as well as validating third party conﬁgurations. The proposed solutions are fully imperative, code centric and speciﬁed at a level of abstraction that does not support changes easily. Our experience proved that small changes in the domain models often resulted in large modiﬁcations of the code. The model based generation approach described in this paper overcomes these weaknesses and takes all the beneﬁts that come with a full model based approach. In [5,13], authors present a Model Driven Approach (MDA) for the design of AIS conﬁgurations. Their goal is mainly to move from an abstract conﬁguration to a platform speciﬁc conﬁguration. More speciﬁcally, they have applied MDA concepts to develop applications that can run on an AIS implementation rather than generating AMF conﬁgurations. There is more work on conﬁguration generation in the general context of software management, particularly using constraint satisfaction techniques and policies [1,7]. The authors in [7], for instance, propose an approach for generating a conﬁguration based on the set of user requirements, operator and technical constraints. Taking into account the constraints, the process of generating a conﬁguration is formulated as a resource composition problem. Despite the fact this work shares common features with our method, there are major differences between these two approaches. Our focus is on the availability and AMF

142

P. Salehi et al.

domain instead of general utility computing environments. Moreover, in [7] the approach is based on constraint satisfaction techniques while our focus is on model transformation.

5

Conclusion

This paper proposes a model based transformation approach for the generation of AMF conﬁgurations. The approach is based on three proﬁles that capture elements that represent diﬀerent artifacts involved in the generation process. The proposed technique is deﬁned in terms of these artifacts and abstracts away any speciﬁc code and implementation details. This reduces the likelihood of potential errors and improves the maintainability of the solution, compared to a code-centric approach. More speciﬁcally, using a model transformation technique and a declarative implementation style, future modiﬁcations of the proﬁles will have less impact on the implementation compared to a code-centric approach. Furthermore, the domain knowledge that has been modeled in proﬁles is reused directly in the model-driven approach. For instance, the well-formedness rules described in the proﬁles in terms of OCL constraints are used to derive the deﬁnition of the transformation rules. Our model-driven conﬁguration generation process has been implemented using ATL, a well known toolkit for model transformation, and is based on previously deﬁned UML proﬁles. The usage of these de-facto standard technologies favors the diﬀusion and usability of the solution. Moreover, the proposed transformation rules can be easily integrated and executed in any UML CASE tool. The presented approach considers the redundancy model that should be used to protect the services. This property allows for generating AMF conﬁgurations that can support the required SIs protection level associated with the redundancy model. This represents a ﬁrst step towards the deﬁnition of a generation process that consider both functional and non-functional (NF) requirements. The proposed process could be reﬁned considering additional NF properties belonging to availability category, such as the level of availability, the mean time to failure, and so on. Moreover, also properties belonging to other categories could be used to reﬁne the generation. For instance, knowing the budget that the customer is allowed to invest, and the cost associated with the SW bundle elements, one could generate AMF conﬁgurations whose cost complies with the budget. Another reﬁnement could be enabled by performance properties such as the desired response time or throughput, and the corresponding aspects of the SW bundle. The enhancement appears a rather challenging task due to the complexity of the domain and the consistency issues associated with diﬀerent complementary properties. Right now we have just started to analyze the relationships that are deﬁned among NF properties and between NF properties and structural aspects of AMF conﬁgurations. As future work we will use the potentially identiﬁed relationships either to reﬁne the transformation rules by specifying additional constraints, or to identify AMF conﬁguration patterns associated with given sets of NF properties.

A Model Driven Approach for AMF Conﬁguration Generation

143

Acknowledgements. This work has been partially supported by the Natural Sciences and Engineering Research Council (NSERC) of Canada and Ericsson Software Research. We are very thankful to Dr. Maria Toeroe from Ericsson for her insightful comments on the paper.

References 1. Hinrich, T., Love, N., Petrie, C., Ramshaw, L., Sahai, A., Singhal, S.: Using ObjectOriented Constraint Satisfaction for Automated Conﬁguration Generation. In: Sahai, A., Wu, F. (eds.) DSOM 2004. LNCS, vol. 3278, pp. 159–170. Springer, Heidelberg (2004) 2. Jouault, F., Allilaire, F., Bezivin, J., Kurtev, I.: ATL: A Model Transformation Tool. Science of Computer Programming 72(1-2), 31–39 (2008) 3. Kanso, A., Toeroe, M., Hamou-Lhadj, A., Khendek, F.: Generating AMF Conﬁgurations from Software Vendor Constraints and User Requirements. In: Proceedings of the 4th International Conference on Availability, Reliability and Security (ARES 2009), pp. 454–461. IEEE, Los Alamitos (2009) 4. Kanso, A.A., Toeroe, M., Khendek, F., Hamou-Lhadj, A.: Automatic Generation of AMF Compliant Conﬁgurations. In: Nanya, T., Maruyama, F., Pataricza, A., Malek, M. (eds.) ISAS 2008. LNCS, vol. 5017, pp. 155–170. Springer, Heidelberg (2008) 5. Kövi, A., Varró, D.: An Eclipse-Based Framework for AIS Service Conﬁgurations. In: Malek, M., Reitenspieß, M., van Moorsel, A. (eds.) ISAS 2007. LNCS, vol. 4526, pp. 110–126. Springer, Heidelberg (2007) 6. Oggerino, C.: High availability network fundamentals: a practical guide to predicting network availability. Cisco Press (2001) 7. Sahai, A., Singhal, S., Machiraju, V., Joshi, R.: Automated Generation of Resource Conﬁgurations through Policies. In: Proceedings of the 5th IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY 2004), pp. 107–110. IEEE, Los Alamitos (2004) 8. Salehi, P., Hamoud-Lhadj, A., Colombo, P., Khendek, F., Toeroe, M.: A UMLBased Domain Speciﬁc Modeling Language for the Availability Management Framework. In: Proceedings of the 12th IEEE International Symposium on High Assurance Systems Engineering (HASE 2010), pp. 35–44. IEEE, Los Alamitos (2010) 9. Service Availability Forum, http://www.saforum.org 10. Service Availability Forum: Application Interface Speciﬁcation, Availability Management Framework, SAIAIS-AMF-B.04.01, http://www.saforum.org/ specification 11. Service Availability Forum: Application Interface Speciﬁcation, Software Management Framework, SAIAIS-SMF- A.01.02, http://www.saforum.org/ specification 12. Service Availability Forum: SA Forum Overview, SAI-Overview-B.05.01, http:// www.saforum.org/specification 13. Szatmári, Z., Kövi, A., Reitenspiess, M.: Applying MDA Approach for the SA Forum platform. In: Proceedings of the 2nd Workshop on Middleware Application Interaction (MAI 2008), pp. 19–24. ACM, New York (2008)

SDL Code Generation for Network Simulators Mihal Brumbulli and Joachim Fischer Humboldt Universit¨ at zu Berlin, Institut f¨ ur Informatik, Unter den Linden 6, 10099 Berlin, Germany {brumbull,fischer}@informatik.hu-berlin.de

Abstract. Network simulators are a very popular tool for behavior assessment of distributed and networked systems. Despite this fact, the lack of integration with existing system design tools leads to a diﬃcult and error-prone development of these systems for simulation purposes. Even if the system is correctly implemented, its maintenance becomes a tedious task especially with the increasing complexity. This paper introduces a new approach for addressing these issues through the combination of SDL with code generation and transformation techniques. The goal is automatic C++ code generation resulting in a new module for the network simulator ns-3. The simulator is not subject to any modiﬁcations because the new module is integrated within it. This way no external mechanism for bridging system implementation with the simulator is required and the simulation performance is not aﬀected. Keywords: SDL, code generation, ns-3.

1

Introduction

Network simulators are considered a good tool for behavior and performance assessment of distributed and networked systems. Although the set of implemented features is increasing [3], the implementation and simulation of speciﬁc systems remain a user task. This task is usually time consuming and prone to errors due to the lack of integration with existing system design tools. Even if the system is correctly implemented (mostly hand-coded), its maintenance becomes a tedious task especially with the increasing complexity. The system development process makes use of existing design languages like SDL [1] and tools like RTDS [5], which provide an integrated environment for creation, validation, maintenance, and automatic implementation of system designs. Nevertheless, these tools cannot assess the functional behavior of the system in a distributed and networked environment. Network simulators like ns-3 [3] can provide such an environment with the drawback of hand-coded system implementation. The approach described in [15] utilizes a socket based interface for bridging the system implementation with the network environment provided by the simulator. Although this scheme does oﬀer a solution to the problem, it does not support any synchronization mechanism, thus it can only be used in real-time scheduling F.A. Kraemer and P. Herrmann (Eds.): SAM 2010, LNCS 6598, pp. 144–155, 2011. c Springer-Verlag Berlin Heidelberg 2011

SDL Code Generation for Network Simulators

145

simulations. Scalability issues may arise due to possible bottlenecks in large simulated networks, which imply a high number of system instances. An improved solution is proposed in [14]. The authors provide an extension to the ns-2 simulator, which oﬀers both real-time and simulation-time scheduling. The system implementation interacts with the simulator through named pipes, which can also set some limitations for large scale network simulations. The HUB Transcompiler [9,12] developed at Humboldt University generates C++ code for ODEMx (a general purpose simulation framework) [4] and for the target platform. This approach makes no use of external communication mechanism (i.e. sockets, pipes) because the system implementation is integrated within the simulator; this ensures no added overhead for large scale simulations. The approach introduced in this paper is an extension to the HUB Transcompiler that aims at C++ code generation for the ns-3 simulator. Code generation provided by RTDS in combination with code transformation are used to obtain application layer protocol implementation in ns-3 from SDL-RT [6] speciﬁcation. The result is a new integrated module for the simulator that does not use any external mechanism and is very suitable for large scale simulations [16]. Assessment of real system implementation may also be done with the emulation framework provided by ns-3 [2]. The rest of this paper is organized as follows. In Sect. 2, the basics of the network simulator ns-3 are brieﬂy described. In Sect. 3, the architecture and operation of the code generator are introduced. An example of practical use is described in Sect. 4, and some conclusions are presented in Sect. 5.

2

The Network Simulator ns-3

Ns-3 is a discrete-event network simulator for internet systems, targeted primarily for research and educational use. It is entirely written in C++; simulations are also C++ executables. This makes it a perfect candidate for integration with system design tools like Pragmadev’s RTDS, which generate C/C++ code from SDL-RT speciﬁcations. Ns-3 is composed of several modules (Table 1) that provide all the necessary components used in simulation scenarios (nodes, mobility models, applications, protocols, devices, and channels). A simulation scenario is usually organized based on the model shown in Fig. 1. The node is the core component of this model and acts as a container for applications, protocol stacks, and devices. Remote network devices are interconnected through channels of the same type. Applications are usually traﬃc generators: they create and send packets to the lower layers using a socket-like API. Simulation of a new application layer protocol in ns-3 usually follows these steps: – – – –

a new protocol is implemented as a set of applications, a set of network nodes is created, a mobility model is applied to the nodes, protocol stacks and network devices are installed,

146

M. Brumbulli and J. Fischer

Table 1. The ns-3 modules Module

Description

core

Callbacks, debugging facilities, random variable distributions, objects, smart pointers.

simulator

Time management, scheduler, simulator.

common

Packet class to create and manipulate simulation packets.

mobility

Mobility models, traces for course changes of a mobility model.

node

Network node, MAC-layer, application-layer API.

devices

Bridge, CSMA, Emulated device, Mesh, Point-to-Point, Tap Bridge, Wiﬁ, WiMAX.

internet-stack Ipv4 stack, ARP, UDP and TCP. routing

AODV, Global Routing, List Routing, Nix-vector Routing, OLSR, Static Routing.

helper

High-level API wrappers for everything else.

Node

Node

Application

Application Socket-like API

Protocol Stack

Protocol Stack

NetDevice

Channel Channel Packet

Fig. 1. The basic ns-3 data ﬂow model

NetDevice

SDL Code Generation for Network Simulators

147

– channels are created for connecting the devices, – the new applications are installed, – compile and run simulation. The implementation of a new protocol is usually time consuming and error prone. There exist some implemented applications which can be used as templates, but still a lot of hand coding from scratch has to be done. Usually each application layer protocol is implemented as a set of ns-3 applications, which can be used afterwards in simulation scenarios.

3

Code Generation

PragmaDev RTDS is a modeling tool for real time and embedded software suited for any communicating system or any application running on top of a Real Time Operating System [5]. A general model of PragmaDev approach to system development is illustrated in Fig. 2. The output is composed of generated and static parts. The static parts are interleaved with the generated code, which is parametrized by using macro

RTDS Patterns

SDL-RT SDL UML C++

RTDS Transcompiler

...

C++ Artefact

C code

C++ Compiler/Linker

Binary for target OS

C++ Artefact

System Block A

Block B

Process 1

Process 4

Process 2

Process 3

Thread 1

Thread 4

Thread 2

Thread 3

Fig. 2. System development with PragmaDev RTDS

148

M. Brumbulli and J. Fischer

functions. Each framework provided by PragmaDev or any third party developer needs to deﬁne the macros as well as the static parts. These components are represented by RTDS patterns. During the transformation into C code, RTDS discards any information connected to the composition of processes into blocks. This implies no hierarchy among blocks and processes. Processes are always mapped to threads of the corresponding operating system, procedures map to functions and messages are represented as C structures. The generated code is process based,1 which is suitable for target operating systems or process based simulators like ODEMx. Unfortunately this cannot be stated in case of ns-3, which is an event-based simulator. This can be solved by customizing the RTDS patterns: modiﬁcations are applied in order to adapt the code for event-based simulation. Although these changes are a good starting point, they are not suﬃcient due to several problems that arise. Section 3.2 lists these problems and describes a method for addressing them. The extended model, which provides C++ code for the network simulator ns-3, is shown in Fig. 3. 3.1

The HUB Transcompiler

The HUB Transcompiler maps blocks to C++ classes that are populated with other blocks or processes, and processes become C++ classes that have procedures as their methods.2 In order to allow the sending of messages among different processes, all processes derive from a common base class that implements an interface for resolving process type IDs. Base classes are also provided for the other core components of a SDL-RT model. Table 2 lists some implementation details of these base classes. Table 2. Implementation details in ns-3 of SDL-RT model core components Component

Implementation in ns-3

RTDS system

ns3::ApplicationContainer which encapsulates all building blocks and contained processes. It provides also installation functionalities.

RTDS block

ns3::ApplicationContainer which encapsulates all sub-blocks and contained processes. It provides also installation functionalities.

RTDS process

ns3::Application with custom attributes and functions for providing a process like behavior.

RTDS procedure No speciﬁc implementation provided. Procedures are implemented as RTDS process member functions.

1 2

Parallel (pseudo parallel) execution of state machines. This mapping is achieved through the ns-3 patterns (Fig. 3).

SDL Code Generation for Network Simulators

HUB Transcompiler Architecture

Customized RTDS Patterns

ns-3 Patterns

SDL-RT SDL UML C++

RTDS Transcompiler

...

C++ Artefact

C code

HUB Transcompiler

C++ Artefact

System

TXL

Block A

Intermediate ns-3 C++ code

Transformation Rules

Block B Process 4

Process 1

Final ns-3 C++ code

Process 2

Process 3 ns-3 Sources waf build

ns-3 module ns-3 Build Script

ApplicationContainer (System) ApplicationContainer (Block A)

ApplicationContainer (Block B)

Application 1

Application 4 ns-3 Library

Application 2

Application 3

Fig. 3. The architecture of the code generator

149

150

M. Brumbulli and J. Fischer

The HUB Transcompiler reconstructs the hierarchy among blocks and processes as follows: 1. It determines the lists of processes using the information generated by Pragmadev’s RTDS.3 2. It parses the header ﬁles of each process looking for #include directives. 3. It analyses whether the included ﬁle name starts with “block ”.4 4. If it does, the include is considered to be the containing block of the process.5 5. Steps 2 to 4 are repeated also for each identiﬁed block (block header ﬁle). 3.2

Code Transformation

The C++ code generated by the HUB Transcompiler can be compiled and used with ns-3 but it will not behave correctly. This happens because of the modiﬁcations introduced in the RTDS patterns, which transform the code from processbased to event-based.

RTDS Declarations

RTDS Declarations

User Declarations

User Declarations

RTDS Initializations

RTDS Initializations

Initial Transition

init

else

1 1

else

Initial Transition

1 Read Message from Queue s1 m1 do action

Message

Read Message from Queue

init = 0

s2

Current_State m2

m1

do action

do action

Message

s1 m2

m1

do action

do action

Message

s2

Current_State m2

m1

do action

do action

Message

m2 do action

Fig. 4. Process-based (left) vs event-based (right) implementation of a SDL-RT Process

This transformation consists mainly in the substitution of the inﬁnite loop present in a process-based implementation. The absence of this loop in the eventbased implementation is handled by the callback mechanism of ns-3. The member 3 4 5

This information is contained in the generated ﬁle “RTDS gen.inf”. Note that this method imposes a naming convention to the developer: each block name has to start with the “block ” preﬁx. If the condition in step 3 was never met, the process is considered to be contained in the system block.

SDL Code Generation for Network Simulators

151

function containing the event-based implementation is called each time an event has occurred (i.e. message is received). Although this transformation addresses the inﬁnite loop problem, another issue emerges due to its removal. As illustrated in Fig. 4, user declared variables6 together with RTDS declarations are positioned outside the loop. Some of these variables are responsible for saving state of the process, while others may be required to “remember” their previous values so that the process can behave as required. As a result, the removal of the loop causes an incorrect behavior due to these variables. A possible solution is to transform these from local declarations to member declarations. Although this solution seems quite straightforward, it cannot be accomplished by editing the RTDS patterns. Also, the HUB Transcompiler cannot handle this situation due to its set of available transformations. Code transformation techniques and tools may be useful in this case. The TXL Language. TXL [10,11] is a programming language speciﬁcally designed for manipulating and experimenting with programming language notations and features using source to source transformation. The idea behind the TXL paradigm is depicted in Fig. 5.

Input Text

Parse

Grammar

Parse Tree

Transform

Transformation Rules

Transformed Parse Tree Unparse

Transformation Rules

Output Text

Fig. 5. The TXL paradigm

TXL programs are self-contained, in the sense that they depend on no other tools or technologies, and environment independent, so they can be easily run on many modern platforms. They normally contain a base grammar, which speciﬁes the syntactic forms of the input structure, an optional set of grammar overrides, which modify the grammar to include new forms to be used or output by the 6

These refer to C/C++ declarations present in the SDL-RT model that are deﬁned by the user. They are copied from the model to the generated code.

152

M. Brumbulli and J. Fischer

transformation, and a rooted set of transformation rules, that specify how input structures are to be transformed to the intended output [10]. Due to its popularity, a wide set of resources is available [7] including a C++ grammar implementation. Transformation Rules. The proposed solution was implemented through a set of transformation rules deﬁned in TXL. The available C++ grammar7 was used for this purpose. The transformation rules8 are as follows: – a new assignment statement is added for each initialization in line with a declaration statement, – inline initializations with declaration statements are removed, – variables in declarations are renamed, – a copy of the renamed local declarations is created as member declarations, – local declarations are removed. Renaming is necessary because the same name can appear in local variables present in diﬀerent functions (recall that SDL-RT procedures are implemented as member functions). These transformations produce a fully adapted C++ code for the ns-3 simulator. 3.3

Integration with ns-3

For a completely automated code generation and compilation process, an integration of the generated code with the ns-3 build is necessary. Ns-3 uses a python-based build system called waf [8]. A ns-3 build script (wscript) is automatically generated after the code generation and transformation phase is ﬁnished and the build command is issued. The resulting ns-3 library generated will contain a new module which encapsulates the desired implementation. This module can be used afterwards in any simulation scenario; the system or its composing blocks containing ns-3 applications (Table 2) can be installed in any node present in the scenario.

4

First Practice

The HUB Transcompiler has been used for the development of the Self-organizing Seismic Early Warning Information Network (SOSEWIN) [12,13]. This infrastructure (Fig. 6) enables the same SDL-RT model description to be used for producing code for diﬀerent platforms.9 The results obtained from a real implementation in Istanbul (Turkey) and small scale simulations have contributed in the planning of further developments

7 8 9

The grammar is not validated but tests has shown that it serves the purpose. The rules apply to local declarations that appear before the inﬁnite loop (Fig. 4). Linux OS, ODEMx, and ns-3 (Fig. 6).

SDL Code Generation for Network Simulators

153

RTDS Patterns

SDL-RT SDL UML C++

C code RTDS Transcompiler

RTDS Simulator C++ Compiler/Linker

HUB Transcompiler

Boost Patterns

SDL-RT Boost C++ code

C++ Compiler/ Linker

ODEMx Patterns

SDL-RT ns-3 Intermediate C++ code

SDL-RT ODEMx C++ code

Boost Library

ODEMx Library

C++ Compiler/ Linker Binary Code Linux

ns-3 Patterns

Simulation Script

TXL

Transformation Rules

SDL-RT ns-3 Final C++ code

ns-3 Library

Binary Code ODEMx C++ Compiler/ Linker

Binary Code ns-3

Fig. 6. The extended transcompiler architecture

Simulation Script

154

M. Brumbulli and J. Fischer

of SOSEWIN, with large scale implementations being one of the primary goals. For this reason, simulation results for large scale networks become a crucial part in the planning of real implementations. The existing infrastructure provides support for large scale simulations, but it is not complete due to the lack of network models. The approach presented in this paper integrates the network models provided by ns-3 with the existing infrastructure (Fig. 6).

5

Conclusions

This paper presented a new approach for combining SDL-RT design speciﬁcations with ns-3 network models. This solution enables the developer to use SDL-RT design speciﬁcations as a common code base for the automatic generation of simulation code. This reduces the eﬀort required for simulations of distributed and networked systems, as hand-coding for simulation purposes is substantially reduced. This approach does not require the use of any external mechanism to bridge system implementation with the simulator, instead it generates a fully integrated new module for the simulator, thus having no eﬀect on the simulation performance. This is especially important for the simulation of highly distributed and large scale networked systems.

References 1. ITU: Recommendation Z.100, Speciﬁcation and Description Language (SDL) (November 2007), http://www.itu.int/rec/T-REC-Z.100/en 2. ns-3 manual, http://www.nsnam.org/docs/release/manual.html 3. The ns-3 network simulator, http://www.nsnam.org/ 4. ODEMx, http://sourceforge.net/projects/odemx 5. PragmaDev - real time developement tools, http://www.pragmadev.com/ 6. Speciﬁcation and Description Language - Real Time, http://www.sdl-rt.org/ 7. TXL World, http://www.txl.ca/nresources.html 8. waf, http://code.google.com/p/waf 9. Ahrens, K., Eveslage, I., Fischer, J., K¨ uhnlenz, F., Weber, D.: The Challenges of Using SDL for the Development of Wireless Sensor Networks. In: Reed, R., Bilgic, A., Gotzhein, R. (eds.) SDL 2009. LNCS, vol. 5719, pp. 200–221. Springer, Heidelberg (2009) 10. Cordy, J.R.: Source Transformation, Analysis and Generation in TXL. In: Proceedings of the 2006 ACM SIGPLAN Symposium on Partial Evaluation and Semanticsbased Program Manipulation, PEPM 2006, pp. 1–11. ACM, New York (2006) 11. Cordy, J.R.: The TXL Source Transformation Language. Sci. Comput. Program 61, 190–210 (2006) 12. Fischer, J., K¨ uhnlenz, F., Ahrens, K., Eveslage, I.: Model-based Development of Self-organizing Earthquake Early Warning Systems. In: Troch, I., Breitenecker, F. (eds.) Proceedings MATHMOD 2009 Vienna (2009) 13. Fleming, K., Picozzi, M., Milkereit, C., Kuhnlenz, F., Lichtblau, B., Fischer, J., Zulﬁkar, C., Ozel, O., et al.: The Self-organizing Seismic Early Warning Information Network (SOSEWIN). Seismological Research Letters 80(5), 755 (2009)

SDL Code Generation for Network Simulators

155

14. Kuhn, T., Geraldy, A., Gotzhein, R., Rothl¨ ander, F.: ns+SDL – The Network Simulator for SDL Systems. In: Prinz, A., Reed, R., Reed, J. (eds.) SDL 2005. LNCS, vol. 3530, pp. 103–116. Springer, Heidelberg (2005) 15. Latkoski, P., Rakovic, V., Ognenoski, O., Atanasovski, V., Gavrilovska, L.: SDL+QualNet: A Novel Simulation Environment for Wireless Heterogeneous Networks. In: Proceedings of the 3rd International ICST Conference on Simulation Tools and Techniques, SIMUTools 2010, ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering), ICST, Brussels, Belgium, pp. 25:1–25:10 (2010) 16. Weing¨ artner, E., Vom Lehn, H., Wehrle, K.: A Performance Comparison of Recent Network Simulators. In: Proceedings of the 2009 IEEE International Conference on Communications, ICC 2009, pp. 1287–1291. IEEE Press, Piscataway (2009)

A Case Study on API Generation Uwe Jugel and Andr´e Preußner SAP Research Center Dresden, Chemnitzer Str. 48, 01187 Dresden, Germany {uwe.jugel,andre.preussner}@sap.com

Abstract. Model-driven software development (MDSD) is gaining access to the software development market, even if some of our colleagues are still reluctant to techniques like code generation from models and model transformations. Convincing the skeptics can be done by showing how and when to apply MDSD in the right way. This paper is a case study on applied MDSD, with a focus on code generation. We describe in detail how to generate code for a large model base, and how this increases flexibility and reduces development time. We explain in detail several templates for generating a C#-API from Ecore models, including event propagation and serialization code. Additionally, we show how to model additional features for existing models, and how to combine models using the C#-feature of partial classes for the generation of code, allowing us to merge stable models with ad-hoc extensions. Keywords: code generation, model-driven software development, serialization, persistence, case study.

1

Introduction

Model-driven software development (MDSD, [1]) is an important paradigm, since it raises the level of abstraction in which software systems are designed, and enables diﬀerent stakeholders to exchange their ideas of how such a system should work via models. These models can either be interpreted directly at runtime, or they are transformed to compilable code using model-to-code generation techniques. While code generation has been done for over ﬁfteen to twenty years, it has never been particularly easy to apply. In the last decade, a lot of techniques and tools have been developed to simplify MDSD aspects such as code generation, and make the transition from traditional software development to model-driven development a lot easier; a message that slowly settles in industry. According to Gartner’s Hype Cycle for Application Development for 2009 [2], Model-Driven Architecture is beyond the hype peak, but has not yet experienced a wide adoption in the industry. Better tools have lowered the barriers for the common developer to apply modeling and code generation techniques, and thus, we are able to focus this paper on the problems of the transformation domain rather than on problems of tools and techniques. F.A. Kraemer and P. Herrmann (Eds.): SAM 2010, LNCS 6598, pp. 156–172, 2011. c Springer-Verlag Berlin Heidelberg 2011

A Case Study on API Generation

1.1

157

Contributions and Overview

Our code transformation project is motivated by the need to consume and adapt several Ecore models [3] in a web-based tool, developed in C#. Our transformation technology of choice for the code generation project is the MDD framework openArchitectureWare (oAW) including the templating language Xpand and the scripting language Xtend [4], both now part of the Eclipse Modeling Project [5]. This paper describes the particular details for transforming Ecore models to C#-classes. We make the following contributions. 1. By describing a detailed case study on API-generation, we want to motivate developers to pick up MDSD principles for their industry projects, and we show that modern code generation approaches are ready for the industry. 2. Especially regarding C# as target language, we provide extensive Xtend and Xpand examples, covering all aspects needed to generate basic C#-classes. 3. In addition, we demonstrate a pragmatic and eﬃcient way for seamlessly adding extension features to Ecore models without changing the original models. In Sect. 2, we provide more details about the related research project and in Sect. 3 the motivation to generate an API for the models used in the project. In Sect. 4, we present alternative approaches applicable for model-to-code generation, and justify our choice for Xpand. Afterwards, in Sect. 5, we present selected examples of C#, Xpand, and Xtend snippets, demonstrating how to transform an Ecore model into C#-classes, and we discuss the problems of our generator. In Sect. 6, we introduce a modeling technique for non-intrusively extending the generated model code with new features. The validity of the used MDSD principles and the beneﬁt of the code generator are discussed in Sect. 7, followed by a conclusion and outlook in the Sect. 8.

2

Project Background

The presented code generation project has been developed in the course of the EU-funded research project ServFace [6,7], which aims for enhancing the automatic generation of user interfaces (UIs), and simplifying the development of web service-based applications. The project provides several models that are described using Ecore. Ecore is a meta-model for describing Ecore models. These Ecore models are ususally used again as meta-models for XMI instance data. Ecore is provided by the Eclipse Modeling Framework (EMF, [3]), together with many tools, as part of the Eclipse Modeling Project [5]. In our project we have three main Ecore models. 1. An Annotation Model with over twenty web service annotations that are used to describe important UI aspects not covered in typical service description languages, such as WSDL. The model allows to describe visual aspects, such as human readable labels, and additional grouping of data structures, but also functional aspects, such as the deﬁnition of a suggestion service for an input parameter [8].

158

U. Jugel and A. Preußner

Ecore decribes itself

ServFace Builder

Ecore

(generated)

meta-model

C# Model API

Ecore decribes our ServFace models

Service Model (Ecore model)

Annotation Model

conforms to includes

Instance Data

CAM

(Ecore model)

(Ecore model)

Partner Tool

Fig. 1. ServFace model hierarchy and their relation to the ServFace tools

2. A Composite Application Model (CAM) containing over ﬁfty classes to describe an application composed of web service front ends, including layout, navigation, and data ﬂow [9]. 3. A separate part of the CAM is the Service Model, a generic description of all aspects of a web service that are relevant in our tools for generating the UI, such as establishing data bindings and building SOAP requests for calling a speciﬁc service operation. A web service description and an associated Annotation Model instance make up an Annotated Service. The annotations are added to a service using a Javabased graphical editor, developed by one of our project partners. The annotated services are consumed in the ServFace Builder, a web-based, graphical service composition tool that reads and transforms such services to groups of UI elements described using the CAM. After the user has ﬁnished modeling the application in the ServFace Builder, the resulting CAM instances are transferred to a model transformation service. This service, also developed by a project partner, can transform the application description (CAM instance) to an executable web/mobile application and takes care of proper deployment.1 An overview of the model hierarchy and the models’ relation to the project’s tools is displayed in Fig. 1.

3

Requirements and Assumptions

All ServFace tools rely on and beneﬁt from the consistency of the three models. The models are research prototypes and, especially in the beginning of the project, were subject to frequent changes impacting all implemented tools. All tools are required to support the newest models, and their APIs for handling the 1

Note that this paper does not provide details on our partner’s MDSD and code generation approach. It only covers the C#-API generation for the ServFace Builder. See http://servface.eu for further reading.

A Case Study on API Generation

159

models need to support serialization and deserialization for exchanging model data between the diﬀerent tools. The project requires the composition tool to be a web application developed in Silverlight using the C# programming language. This excludes the Java-based APIs of EMF from the possible integration approaches. After taking several fruitless attempts to integrate our Ecore models into the C#-code of the ServFace Builder (see Sect. 4), we decided to create our own code generator using openArchitectureWare. The decision was based on the following assumptions. Development Speed. The development speed for the C#-based ServFace Builder would increase noticeably. As mentioned above, Ecore models are used to describe the data to be exchanged between the diﬀerent tools. We assumed, that writing and maintaining the needed API for the model access by hand was no feasible solution, because of the size and the frequent changes in the models. Flaws in Generated Code. The Microsoft .NET Development Framework provides a code generator for generating API code from an XSD model, but the generated code has several ﬂaws (see Sect. 4) that need to be ﬁxed manually. Given the frequently changing models, we assumed that writing our own generator would be more eﬃcient than regularly performing the manual ﬁxes. Missing Serialization Support. The model code from the XSD-based generator mentioned above did not provide a satisfying serialization of references between model elements. In our generator we integrated auxiliary code for the serialization of such models. We also realized that not using a generator would lead to a lot of lines of model handling code that had to be maintained. This code would be very repetitive over dozens of classes, and changes in the behavior of the model API would have to be implemented in every class. By using code generation, we expected to produce a model API for our Ecore models similar to the Java APIs of EMF. We assumed the code generation templates to have much less code, and that they would be our single point of entry for ﬁxing bugs and adding features. Instead of having to touch dozens of C#-classes, we could focus on a few templates having entire control over the way the resulting C#-classes would look like and work.

4

Related Work and Alternative Approaches

In this section we discuss two alternative approaches for generating C#-code from Ecore models that we tried before using oAW. Afterwards, we list a series of other transformation languages that could be used as a substitute for Xpand. 4.1

EMF4NET

The ﬁrst approach was to take an existing .NET project providing us with the desired model API. A project that aims at providing the same functionality for

160

U. Jugel and A. Preußner

C#/.NET, as EMF does for Java, is EMF4Net [10]. It was the most promising possibility at the beginning of our investigation, but turned out to be in an immature state. Especially, the serialization and deserialization were not ﬁnished at that point in time. Another issue is that the code generated by EMF4Net aims at pure .NET as target platform and uses some features that are not available in Silverlight, which would result in the need for repetitive manual ﬁxing. 4.2

.NET SDK Code Generator for XSD

Another code generation approach using existing tools is to take the detour over XSD. The idea is to export the Ecore-model as an XSD, and then use xsd.exe provided by the .NET SDK to generate the model code for C#. We tried the two kinds of XSD export that EMF can produce from an Ecore model. The ﬁrst kind, an Ecore-speciﬁc XSD, is not supported by the xsd.exe generator. The second XSD conforms to XMI XML-schema. When used with xsd.exe, this XSD produces C#-code that has two ﬂaws that need to be ﬁxed manually. Silverlight Incompatibility. Some of the generated C#-attributes are not available in Silverlight. Some incompatible attributes like System.SerializableAttribute can simply be deleted, without inﬂuencing the usability of the model code. For other attributes that can not be ignored, such as System.Xml.Serialization.XmlAnyAttributeAttribute, or C#-types such as System.Xml.XmlElement, a proper substitution could not be found. Unordered References. Several references of a class that have the same reference type are represented in the generated code as one unordered items array. If a class has two references with the same type, it is not possible to distinguish which elements belongs to which reference. This is a problem of the XSD produced by EMF. We would have to repetitively and manually change this XSD to ﬁx this problem. 4.3

Model-to-Text Alternatives

For model-to-code transformation there exist a whole series of transformation languages. The Eclipse Model To Text Project (M2T, [11]) alone provides three sub-projects that can be used for code generation: the two template language projects Xpand and Java Emitter Templates (JET), and an implementation of the MOF Model To Text OMG standard called Acceleo. Other transformation languages, like the Velocity Template Language (VTL, [12]), or MOFScript [13], which is part of the Eclipse Generative Modeling Technologies project (GMT), also provide the necessary features to transform models into C#-code. A case study that describes the transformation of UML models into C#-code using MOFScript can be found in [14]. Also a common approach is to use the Extensible Stylesheet Language Transformation (XSLT) for code generation, although XSLT is actually intended for XML-to-XML transformations. For our project we are using Xpand and Xtend in openArchitectureWare, since we already knew this tool chain. Xpand, Xtend and oAW provide the following features.

A Case Study on API Generation

(FRUH (3DFNDJH ((QXP (7\SH! GHIDXOWYDOXH (&ODVV ($WWULEXWH

&1HW 3DFNDJH)ROGHU (QXP 1HW7\SH GHIDXOWYDOXH &ODVV)LOH )LHOG

161

)LHOG3URSHUW\3DLU (5HIHUHQFH FRQWDLQPHQWW\SH UHIHUHQFHW\SH (2SHUDWLRQ (3DUDPHWHU UHWXUQW\SH

3URSHUW\

2EVHUYDEOH&ROOHFWLRQ

$QQRWDWLRQ JHQHULFOLVWW\SH &ODVV0HWKRG 0HWKRG3DUDPWHU UHWXUQW\SH GHIDXOWUHWXUQ

Fig. 2. Ecore to C# mapping rules

1. Xpand is a simple to use and easy to learn template language for producing generic text. 2. Xpand templates can include Xtend functions that simplify the template creation. 3. Xpand has native support for Ecore. 4. Eclipse provides excellent tool support for Xpand and Xtend, including editors with syntax highlighting and code-completion. 5. Xpand templates can be executed directly from within Eclipse. 6. The associated workﬂow engine allows the execution of templates for multiple models with just one run command. 7. The execution of the code generation can be integrated in continuous integration servers, such as Hudson.

5

Applied Model-to-Code Generation

In this section we show in detail how our code generation templates are deﬁned, and we discuss the integration of the generator in our build server. We ﬁnish this section by illustrating several problems we had to overcome. Since we are using openArchitectureWare, we deﬁne our templates using Xpand and Xtend. When generating code in oAW, the developer has to specify a meta-model, address the concepts of this meta-model in the code generation templates, and apply these templates to the models (i.e., instances of the metamodels). The typical scenario for oAW-based code generation is to use an Ecore model as meta-model, and XMI-instances of this meta-model as models. Our approach diﬀers from the default scenario, since we want to generate an API for an Ecore model. Therefore, we are using the Ecore meta-model (and not an Ecore model) as meta-model, which is easily accomplished by using the statement «IMPORT ecore» in the Xpand template. Afterwards, we have to address all Ecore features, such as packages, classes, attributes, etc., within our templates. These templates are ﬁnally applied to the Ecore models (e.g., our Composite Application Model and the Annotation Model), which are used as instance models and not as the meta-model, as it is done in the default scenario.

162

U. Jugel and A. Preußner

We are importing Ecore as meta-model, and extend it using several Xtend scripts. «IMPORT ecore» «EXTENSION template::GeneratorExtensions» We need to define templates for all possible EPackage.eContent types: «DEFINE netClass FOR EPackage» «EXPAND netClass FOREACH this.eContents» «ENDDEFINE» 1. recursive template for the EPackage hierarchy 2. an empty template for emf::EObject «DEFINE netClass FOR emf::EObject»«ENDDEFINE» 3. the actual template for EEnums and EClasses «DEFINE netClass FOR EEnum» «ENDDEFINE» «DEFINE netClass FOR EClass» «ENDDEFINE» The main template is defined «DEFINE main FOR List[EPackage]» «FILE "ServFaceModels.csproj"-» for List[EPackage], thus we can easily pass all our models using ... only one workflow statement. «EXPAND netClass FOREACH eContents» ... «ENDFILE» «ENDDEFINE»

Filenames and namespaces are generated by transforming the package hierarchy (using a chosen separator)

For all classes and enums we generate import statements into one single C#-project file.

Fig. 3. Xpand template for project file generation

Figure 2 shows the basic rules that we implemented in the Xpand templates. The basic package structure of Ecore models and a class hierarchy in C# are quite similar and there is a one-to-one mapping between most of the concepts. In the following we will explain these mappings in detail.23 The templates are used to produce one or several C#-class ﬁles for each EClass or EEnum, and also to produce the project ﬁle, for seamlessly using the generated code within MS Visual Studio or other tools supporting C#-project (*.csproj) ﬁles. We are traversing the hierarchy of the model by iterating over all elements in a package (EPackage.eContents). Since Ecore allows not only EClasses and further EPackages, but also plain EObjects to reside in an EPackage, we needed to deﬁne an empty template for EObjects: «DEFINE netClass FOR emf::EObject»«ENDDEFINE»

Figure 3 shows the most relevant parts of our Xpand template for generating the C#-project ﬁle. The template is applied to all classes in the model-hierarchy, and produces import statements for the project ﬁle. To generate valid C#-code we have to replace all C#-reserved keywords that might occur as names within the Ecore models. Currently, we are adding an underscore instead of a longer, more robust keyword preﬁx, since the generated API should be readable by the C#-programmers in the end. Figure 4 shows all regarded keywords in the replacement method removeKeyword, and an extension 2 3

This section requires you to be familiar with the basic Ecore meta-model. Please take care to read the comments in the figures to get a full understanding of the mapping.

A Case Study on API Generation

163

String removeKeyword(String this) : {"abstract","event","new","struct","as","explicit","null","switch","base", "extern","object","this","bool","false","operator","throw","break","finally", "out","true","byte","fixed","override","try","case","float","params","typeof", "catch","for","private","uint","char","foreach","protected","ulong","checked, "goto","public","unchecked","class","if","readonly","unsafe","const","implicit", "ref","ushort","continue","in","return","using","decimal","int","sbyte","virtual", "default","interface","sealed","volatile","delegate","internal","short","void", "do","is","sizeof","while","double","lock","stackalloc","else","long","static", "enum","namespace","string"}.contains(this) ? "_"+this : this; String name(ENamedElement this) : removeKeyword(this.name);

Fig. 4. Xtend scripts for replacing C#-keywords String cType(EClassifier this) : String cDefaultValue(EClassifier this) : switch(name){ switch(name){ case "EBigDecimal" : "System.Decimal" case "EBigDecimal" : "0" case "EBigInteger" : "System.Decimal" case "EBigInteger" : "0" case "EBoolean" : "false" case "EBoolean" : "bool" case "EBooleanObject" : "System.Boolean" case "EBooleanObject" : "false" case "EByte" : "0x00" case "EByte" : "sbyte" case "EByteArray" : "null" case "EByteArray" : "sbyte[]" case "EByteObject" : "0x00" case "EByteObject" : "System.SByte" case "EChar" : "char" case "EChar" : "\u0000" case "ECharacterObject" : "\u0000" case "ECharacterObject" : "System.Char" case "EDate" : " 01.01.0001 00:00:00" case "EDate" : "System.DateTime" case "EDouble" : "double" case "EDouble" : "0.0D" case "EDoubleObject" : "System.Double" case "EDoubleObject" : "0.0D" case "EFloat" : "float" case "EFloat" : "0.0F" case "EFloatObject" : "System.Single" case "EFloatObject" : "0.0F" case "EInt" : "int" case "EInt" : "0" case "EIntegerObject" : "System.Int32" case "EIntegerObject" : "0" case "EJavaClass" : "System.Type" case "EJavaClass" : "null" case "EJavaObject" : "System.Object" case "EJavaObject" : "null" case "ELong" : "long" case "ELong" : "0L" case "ELongObject" : "System.Int64" case "ELongObject" : "0L" case "EMap" : "System.Collections. case "EMap" : "null" case "EShort" : "0" Generic.IDictionary" case "EShortObject" : "0" case "EShort" : "short" case "EString" : "null" case "EShortObject" : "System.Int16" default: name case "EString" : "System.String" }; default: name };

Fig. 5. Xtend scripts for mapping Ecore types to .NET types

method name() for ENamedElement, which uses the keyword-replacement method to convert the default name attribute of named elements in Ecore. Besides removing keywords, we also have to map all Ecore types to C# types. Therefore, we extend the EClassiﬁer with a cType attribute realizing this mapping (see Fig. 5 left). Additionally, we deﬁne default values that can, for example, be used when generating the constructors for the desired .NET classes (see Fig. 5 right). After the generation of the project ﬁle we need to generate .cs ﬁles for each class in the Ecore model. Figure 6 shows the ﬁrst part of the template that generates the C#-classes. Within this template we handle: – Package hierarchy traversal, – Generation of using statements, – Generation of C#-supported types variants, i.e., class, abstract class, and enum.

164

U. Jugel and A. Preußner

The netClass template in Fig. 6 calls the netClass template in Fig. 7, which handles the internals of a C#-class, i.e., constructors, ﬁelds, properties (incl. getters and setters), and references (incl. distinction between associations and containments). There are netClass templates for EEnum and EClass. For producing C#-enums, the basic Xpand template statement is: «EXPAND metaClassName FOR this»«name()»{«eLiterals.toString(", ")»}

It calls the metaClassName template (see Fig. 6), uses the name() extension function (see Fig. 4), and expands the enum literals list to a comma-separated list of strings. The core of the netClass template for EClasses (see Fig. 7) generates code for contained instances of EAttribute, EReference, and EOperation. At this point, we are leveraging several C#-features. 1. Usage of ObservableCollection (instead of a simple List) allows easy data binding and change handling. 2. Generation of partial classes allows the generation of multiple ﬁles for the same class, which are “mixed” by the C#-compiler later on. This is especially important for our extension mechanism, described in Sect. 6. 3. Usage of generics for collections provides type safety. 4. Usage of annotations for not losing the type of a reference (association or containment). This feature is needed for serialization, because XMI instances of our models present containments as XML elements and associations using EMF Fragment Path statements [15] pointing to existing XML elements, which have to be contained in the XMI instance. Currently, our generator is already able to transform many features of Ecore into C#-code. It supports packages, classes, abstract classes, and enums. It can also handle references (containment and non-containment) of all cardinalities, and attributes of all cardinalities. We are still missing a working support for interfaces and interface-based inheritance, and for Ecore annotations. 5.1

Continuous Integration of Models and Code

To use a code generator eﬃciently, it has to be integrated into the build process. To avoid cumbersome manual steps, all changes to the project’s models in the versioning system should trigger the generation of the API code. Afterwards, the generated code has to be validated by the build process. The code should be compiled and tested automatically. Our project uses the Hudson [16] build server to continuously build and test our models and tools. To add the Ecore models and the API generation components to the build server, we are leveraging the fact that openArchitectureWare work ﬂows can be executed externally, triggered by an Ant-script. This can be easily integrated into the build server, which accesses the versioning system, triggers the transformation, and starts the .NET build process for the generated code.

A Case Study on API Generation

165

!

! " #$ %&&'( )

"

# !

$ %

$ * %+' % ' % ' * & & ,- %. ,- ' .%' & ' %/00 &&' " ( $ %&&'") "

" # #)

#) " 1. ,- %' . ,- ,- %'.%&2&'" " #) $ $

Fig. 6. Xpand template for class file generation (class-surrounding statements)

! " #" $ %

" $ & $ ' ( )$#*+ + %%

' #, ++ - ). / 0)

- ). / "

#" && " $ & 1 - ). / % $ %%

! " #

- 2 !33!2 4 - 0

!&& *

!0 ( !4! 5+!+5!#+6!+! " !

$

!2& 7 8

# % % % &

Fig. 7. Xpand template for class file generation (class internals)

166

5.2

U. Jugel and A. Preußner

Problems of the API Generator

During the development of the generator, we were confronted with several problems. One issue was that we did not deﬁne our own meta-model, but used Ecore instead, which sometimes made it diﬃcult to explain the approach to our developers, who should do some of the templating work. Especially, the diﬀerence between Ecore models used as instances (with Ecore itself as meta-model) versus Ecore models used as meta-models (with XML ﬁles as instance) led to a lot of confusion, since the existing oAW-learning material [17] does not address the second possibility. The comprehensibility is also reduced by the complexity of the code in the main template ﬁle, which makes up the major part of our generator project. For a new developer it requires some time to read and understand the templates. We had less troubles with the transformation domain itself (Ecore to C#), but recognized several minor problems with the oAW tools. For example, Xpand allows for an aspect-oriented deﬁnition of templates, using several statements for surrounding other template-code. We believe that this could have saved some repetition within the templates, and would avoid multiple traversal of the class hierarchy, as we are currently doing it to generate diﬀerent types of ﬁles, such as class-ﬁles, project ﬁles, and additional ﬁles. When we wrote the major parts of the templates in version 4.3 of oAW, we had troubles executing our oAWwork-ﬂows, when using these aspect-oriented features. Therefore, adding aspect orientation had to be postponed to future refactorings. Another minor problem results from the way comments are speciﬁed in Xpand using the «REM»«ENDREM» statement. This statement also uses the double arrows notation «», which leads to a reduced usability of the templates. Although REM comments can be beneﬁting in the long term, templates with many REMcomments look very crowded, and increase the time to ﬁnd the desired sections in the code signiﬁcantly.

6

Handling Additional API Feature Requests

After our models were subject to several phases of reﬁnement, we had to stabilize them, to work eﬃciently with our project partners, and also for the sake of the tool developers not having to permanently adapt those parts of the code that make use of the generated API. We appreciated the beneﬁt of stability, but were also reduced in terms of ﬂexibility, since we were no longer able to do short term changes, without having to maintain several versions of the models. Especially, our tool developers ﬁled many requests for additional references and attributes in the models to ease their usage of the model API. At ﬁrst, they started to write their own manual extensions of the API by deﬁning new partial classes that would be merged with the generated classes by the C#-compiler. But since we wanted to keep track of such model extensions, and also to use them as potential refactorings for the next long term model reﬁnement, we came

A Case Study on API Generation

CAM class

UIElement (from view)

relatedUIElement 0..1 new upward reference

ServiceElement (from servicemodel)

ServiceElement

167

ServiceModel class

Extension class annotated with: ExtensionClass

Fig. 8. Extension of the ServiceElement class with an upward reference <eClassifiers xsi:type="ecore:EClass" name="ServiceElement" eSuperTypes="ServiceModel.ecore#//ServiceElement"> <eAnnotations source="ExtensionClass"/> <eStructuralFeatures xsi:type="ecore:EReference" name="relatedUIElement" eType="ecore:EClass CAM.ecore#//view/UIElement"/>

Fig. 9. Excerpt from the extension model file showing the an extension class

up with a solution that would not change the original stable models, but still allow us to model all feature requests using the default Ecore editors, and using the additional models as compatible input for the generator. One example feature request for the application model was to “get all UIElements of one Page.” Such a reference from the root element (Page) of the model to the leaves did not exist in the model. The model stores the UI as tree structure, and we did not want to introduce such a redundant reference into our clean model. Another example request is the connection of two independent models. In particular, the Annotation Model and the Service Model are used by other partners independently of our application model (CAM). But our tool is using all three models together, and the developers often requested to have additional relations from elements of one model to the elements of another one. We could not add these changes to the original models, since this would introduce dependencies between all models and bloat the packages for the other partners. For developing such model extensions in Ecore we are adding an additional Ecore model containing these extensions. Figure 8 shows a part of such a model. The UIElement in the diagram is a referenced class from the CAM, the upper ServiceElement is a class from the Service Model, and the lower ServiceElement class is a new class in this extension model. To extend an existing class, we create a new class inheriting from the original class, and add an ExtensionClass Ecore Annotation to the new class. Ecore Annotations are deﬁned in the properties view of the Ecore editor, and thus, are not visible in the diagram view that is shown in Fig. 8. They are simple additional tags to an entity in the Ecore model. They have a name (source), and can have additional key-value pairs. Figure 9 shows an XML excerpt from our extension model. It contains the new ServiceElement class with an ExtensionClass

168

U. Jugel and A. Preußner

annotation. The class contains a reference named relatedUIElement. The types of the new class and the new reference are pointing to the upper models (ServiceModel.ecore and CAM.ecore). Using this technique, we can add new attributes and upward relations to the new classes in such extension models. An upward relation is an EReference towards the stable models. The model developer should not deﬁne a reference from an existing class to an extending class, since this would change the local copy of the original models. Changes are only permitted in the new classes. Finally, the extension model can also contain new classes that do not extend existing classes. Those can be used for more complex types of feature requests. During the generation of the code, the generator can now check if a class contains an annotation named ExtensionClass. Such classes are treated by the generator as mixins for the original class, using the partial class feature of C#. In this case, the generator will ignore the package and classname of the extending class, and use the package and class name of the original class (super class) instead. All other features of this class, such as the new reference, can be treated by the default C# class template. It produces a standard .cs ﬁle in a separate directory, but since this partial class has the same namespace as the original class in the original ﬁle, the C# compiler is able to merge them. We are currently able to produce valid code for extending classes, new classes, new enums, additional attributes, and upwards references.

7

Validation of the Results

We already stated in our introduction that Model-Driven Software Development and code generation from models are no novelty, especially for the academia, but they have not reached major adoption in the industry. Our ﬁrst goal “to motivate developers to pick up MDSD“ cannot be validated at this point, but we hope that this paper can help developers to solve the problems that occur when generating C#-code from Ecore models. The second goal was to provide all particularities related to the combination of the two diﬀerent technologies. This can be validated by using this paper as a tutorial for building a similar code generator. We could not perform such an experiment for a lack of resources, and we also expect that the paper alone is not suﬃcient for learning all aspects of the related technologies. Additional material will be needed, such as documentation for openArchitectureWare [17] and documentation for Ecore [18]. 7.1

Feasibility of Code Generation

We also wanted to demonstrate the feasibility of code generation in our project. While this is hard to measure, since we did not have the resources for a comparative study, we still see a good beneﬁt from our approach. The most measurable metric is the reduction of lines of code (LOC). In the end, we came up with 200 lines of XML text, and 600 lines of C#-code, woven into nearly 400 lines of Xpand-code. All code in the oAW project makes up 66kB of text. Based on

A Case Study on API Generation

169

this template code, and 80 classes and enums in our models, we are generating 80 C#-ﬁles, three additional class ﬁles, and four ﬁles needed to setup a valid project, i.e., the C#-assembly info and C#-project XML ﬁles. The 80 generated model classes contain between 10 and 200 lines of code. The whole C#-project ﬁnally comprises 87 ﬁles containing nearly 7000 lines of code in 600kB of text ﬁles. Compared to the seven ﬁles within our oAW project, making up 1200 lines of code, we achieve a ratio of 1 to 5.8 between template code and generated code. Over 400 lines of the C#-code in the templates are “boilerplate code” of a single generic class that is not intersected with Xpand statements. Subtracting those lines from the oAW project’s LOC count would give us an even higher ratio of 1 to 8.8. Unfortunately, we did not measure the development time spent for the generator, but since the LOC count is much lower, and since all API classes for our model will behave and look similar, we are convinced that we saved a lot of eﬀort. 7.2

Reduced Types of Errors

Another measurable beneﬁt is the reduced number of error types. Whenever changes occur to the models, which happened a lot during our project’s life cycle, our generator spares us from doing many error-prone, manual changes to the API classes. Since we are using our generator, we have no issues that are related to generated classes. All problems and bugs could be directly associated with ﬂaws in the original models. Those problems could usually be ﬁxed by directly changing the models. In some cases, we perceived general problems that were common for all generated classes. In those cases we repaired or improved the generator. 7.3

Developer Eﬃciency

Repairing and improving the generator showed one of the drawbacks of our approach. Only the developers of the original template could perform template development eﬃciently. There is no gentle learning slope. In one case, we spent some time on educating an inexperienced developer on oAW, Ecore, and the other related technologies. We expected him to add additional features to the code generation templates. In the end, this took much longer than expected, and we had to spend additional resources ourselves. We realized that the meta-model vs. model problem is really diﬃcult for developers to pick up. 7.4

Validity of the Proposed Model Extension Technique

The proposed approach for non-intrusively extending the original classes was not used by the tool developers as often as we expected. They still wrote their own partial classes for extending the models and resolved all resulting conﬂicts in these classes manually by ﬁxing their syntax errors. Such conﬂicts could occur when a new model API was available. In addition to this, when presenting the initial extension model to our project partners, we received very negative feedback. They were very concerned that such an additional model would threaten

170

U. Jugel and A. Preußner

the consistency of the ServFace models, and that all such model changes should be done directly in the original models, after being discussed with the project consortium. The extension mechanism itself was not criticized, and we still regard it as a valid approach for easily adding new features to 3rd party models.

8

Conclusion and Outlook

In this paper we presented a case study on generating model classes and an access API from a set of Ecore models. We included a detailed description of the code generation templates, supported by many code-samples. The paper should motivate developers in applying MDSD principles, such as model transformation and code generation, to reduce their overall development eﬀort. Our case study showed, how code generation can easily combine diﬀerent platforms and tool chains. Using our generator, we can easily design our Ecore models in Eclipse, while developing our tools in C#/.NET. The case study gives the most important details4 on the particularities that developers have to respect when generating C#-code. In addition to the overall case study, we presented a pragmatic, eﬃcient, and non-intrusive way of adding features to an existing (Ecore) model. This extension mechanism allows us to leave the models, shared among our project partners, unchanged, while still being able to react to feature requests from our tool developers, transparently adding ad-hoc, “virtual” changes to the models. Our project requirements deviate from the default code generation scenarios, since we use Ecore as meta-model and Ecore models as instances. Nevertheless, we observed the existing MDSD tools, i.e., openArchitectureWare, to be mature enough and well suited for this scenario. We expected several beneﬁts from our generator, but not all could be achieved. While we signiﬁcantly reduced the lines of code to maintain, we missed to measure or at least estimate the complexity of the remaining template code. The developer eﬃciency, regarding template development, depends to a greater extent on the knowledge and experience of the developer than we expected. Nevertheless, we experienced a reduction of errors, and our models were usually the preferred place to ﬁx them. Using code generation saved us from any modelrelated error that would have been caused by a typo in the code of the model API. We could also successfully apply MDSD practices. The usage of models encouraged all developers to actively take part in discussions about problems and changes in the models. We were able to use and test the models eﬀectively. The proposed extension technique was an attempt to furthermore rely our development on real models. But, unfortunately, we could not achieve this. We missed to evaluate the social aspects of this step. Our developers were reluctant to use it, and the project partners feared for the stability of the models. This shows that the social and educational aspects of MDSD are not to be underestimated. 4

Unfortunately, we cannot release our complete transformation code for legal reasons.

A Case Study on API Generation

171

In the future, we want to further develop our generator to support interfaces, interface-inheritance, and other missing features, that one would expect from a mature class-ﬁle generator. In addition, we are also exploring techniques for enhancing the usability of the generated APIs. Therefore, we have already developed a wrapper library generator [19] that could be combined with the generator presented in this paper. From this combination we expect to improve our model APIs, and thus, increase our tool developers’ eﬃciency.

References 1. Kleppe, A.G., Warmer, J., Bast, W.: MDA Explained: The Model Driven Architecture: Practice and Promise. Addison-Wesley, Boston (2007) 2. Norton, D., Feiman, J., MacDonald, N., Pezzini, M., Natis, Y.V., Sholler, D., van der Heiden, G., Karamouzis, F., Young, A., James, G.A., Knipp, E., Duggan, J., Murphy, T.E., Valdes, R., Blechar, M., Driver, M., Young, G., Vining, J., Knox, R.E., Feinberg, D., Hart, T.J., Patrick, C., Forsman, J., Basso, M., Simpson, R., Adachi, Y., Clark, W., King, M.J., Hill, J.B., Gootzit, D., Bradley, A., Kenney, L.F., Stang, D.B.: Hype Cycle for Application Development, 2009. Technical report, Gartner, Inc. (2009) 3. Steinberg, D., Budinsky, F., Paternosto, M., Merks, E.: EMF: Eclipse Modeling Framework, 2nd edn. Addison-Wesley Professional, Reading (2008) 4. openArchitectureWare.org: oAW Homepage. Website (2009), http://www.openarchitectureware.org 5. The Eclipse Foundation: Eclipse Modeling Project. Website (2010), http://www.eclipse.org/modeling 6. ServFace Consortium: ServFace Project Website (2010), http://www.servface.eu 7. Feldmann, M., Janeiro, J., Nestler, T., H¨ ubsch, G., Jugel, U., Preußner, A., Schill, A.: An Integrated Approach for Creating Service-Based Interactive Applications. In: Gross, T., Gulliksen, J., Kotz´e, P., Oestreicher, L., Palanque, P., Prates, R.O., Winckler, M. (eds.) INTERACT 2009. LNCS, vol. 5727, pp. 896–899. Springer, Heidelberg (2009) 8. Janeiro, J., Preußner, A., Springer, T., Schill, A., Wauer, M.: Improving the development of service-based applications through service annotations. In: Proceedings of IADIS WWW/Internet 2009 (2009) 9. Feldmann, M., Nestler, T., H¨ ubsch, G., Muthmann, K., Jugel, U., Schill, A.: Overview of an End user enabled Model-driven Development Approach for Interactive Applications based on Annotated Services. In: IEEE ECOWS Workshop on Emerging Web Services Technology, WEWST 2009 (2009) 10. Bihler, R., Sch¨ ottle, J.: Eclipse Modeling Framework for.Net (EMF4Net). Website (2009), http://www.emf4net.org 11. The Eclipse Foundation: Eclipse Modeling - M2T. Website (2009), http://www.eclipse.org/modeling/m2t 12. The Apache Software Foundation: Apache Velocity Site. Website (2009), http://velocity.apache.org 13. The Eclipse Foundation: MOFScript Home page. Website (2010), http://www.eclipse.org/gmt/mofscript

172

U. Jugel and A. Preußner

´ Model to Text Transformation 14. Albert, M., Mu˜ noz, J., Pelechano, V., Pastor, O.: in Practice: Generating Code from Rich Associations Specifications. 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. 63–72. Springer, Heidelberg (2006) 15. IBM Corporation and others: Eclipse SDK Help: InternalEObject.eURIFragmentSegment. Website (2006), http://help.eclipse.org/galileo/topic/org.eclipse.emf.doc/references/ javadoc/org/eclipse/emf/ecore/InternalEObject.html 16. Sun Microsystems, Inc.: Hudson-CI. Website (2009), http://hudson-ci.org 17. openArchitectureWare.org: oAW Screencasts. Website (2008), http://www.openarchitectureware.org/staticpages/index.php/oaw_ screencasts 18. IBM Corporation and others: EMF Javadoc: Package org.eclipse.emf.ecore. Website (2006), http://download.eclipse.org/modeling/emf/emf/javadoc/2.5.0/ org/eclipse/emf/ecore/package-summary.html 19. Jugel, U.: Generating Smart Wrapper Libraries for Arbitrary APIs. In: van den Brand, M., Gaˇsevi´c, D., Gray, J. (eds.) SLE 2009. LNCS, vol. 5969, pp. 354–373. Springer, Heidelberg (2010)

UOST: UML/OCL Aggressive Slicing Technique for Eﬃcient Veriﬁcation of Models Asadullah Shaikh, Uﬀe Kock Wiil, and Nasrullah Memon The Maersk Mc-Kinney Moller Institute University of Southern Denmark {ashaikh,ukwiil,memon}@mmmi.sdu.dk

Abstract. In Model Driven Development (MDD), model errors are a primary concern in development methodology. UML/OCL models have increased both in size and complexity due to its popularity in model design and development. Consequently, the eﬃciency of the veriﬁcation process is being aﬀected. The veriﬁcation of these models is each time more laborious because of their complex design and size thus prolonging the veriﬁcation process. In this paper, we propose an algorithm of an aggressive slicing technique that works on UML/OCL models (a collection of classes, associations, inheritance hierarchies, and OCL constraints) which improves the eﬃciency of the veriﬁcation process. With this technique, the submodels of an original model are computed through partitioning those classes and multiplicities that are not used in written constraints and at the same time, ensuring that the model behavior is not aﬀected. We attempt to quantify the speed-up achieved by adding the slicing technique to two diﬀerent tools (1) UMLtoCSP and (2) Alloy. The purpose behind showing the results in UMLToCSP and Alloy is to demonstrate that the developed slicing technique is neither tool dependent nor formalism dependent. Keywords: Non Disjoint UML/OCL Slicing, Model Slicing, Veriﬁcation of UML/OCL Models, Non Disjoint Slicing of UML/OCL Class Diagrams.

1

Introduction

UML/OCL models are designed in order to provide a high-level description of a software system which can be used as a piece of documentation or as an intermediate step in the software development process. In the context of Model Driven Development (MDD) and Model Driven Architecture (MDA), a correct speciﬁcation is required because all the technology is based on model transformation. Therefore, if the original model is wrong, this clearly causes a failure of the ﬁnal software system. Regrettably, veriﬁcation of a software product is a complex and time consuming task [6] and that also applies to the analysis of the software models. With increasing model size and complexity, the need for eﬃcient veriﬁcation methods able to cope with the growing diﬃculties is ever present, and the importance of UML models has increased signiﬁcantly [2]. F.A. Kraemer and P. Herrmann (Eds.): SAM 2010, LNCS 6598, pp. 173–192, 2011. c Springer-Verlag Berlin Heidelberg 2011

174

A. Shaikh, U.K. Wiil, and N. Memon

At present, we are facing eﬃciency problems when verifying OCL constraints of complex UML class diagrams. As the complexity of a model can be exponential in terms of model size (i.e., the number of classes, associations, and inheritance hierarchies), reducing the size of a model can cause a drastic speed-up in the veriﬁcation process. One possible approach is slicing; which is partitioning the class diagram and OCL constraints into smaller fragments according to certain criteria. This partition should preserve the property under veriﬁcation in the sense that it should be possible to assess the property in the original model from the analysis of the partitions. A careful deﬁnition of the partition process is needed to ensure this. We focus our discussion on the veriﬁcation of a speciﬁc property: satisﬁability, i.e., “is it possible to create objects without violating any constraint?” The property is relevant in the sense that many interesting properties, e.g., redundancy of an integrity constraint, can be expressed in terms of satisﬁability [5]. Two diﬀerent notions of satisﬁability can be checked: either weak satisﬁability or strong satisﬁability. A class diagram is weakly satisﬁable if it is possible to create a legal instance/object of a class diagram which is non-empty, i.e., it contains at least one object from some class. Alternatively, strong satisﬁability is a more restrictive condition requiring that the legal instance has at least one object from each class and a link from each association [4]. A few slicing techniques exist that break large models into smaller segments, however, those techniques do not address the veriﬁability of UML/OCL models. Previous research on slicing has focused on slicing methods of UML architectural models and verifying invariants in pieces [1, 13, 10, 15, 11]. In this paper, we propose an aggressive slicing technique which preserves the satisﬁability of the model after partitioning. The technique improves the eﬃciency of the veriﬁcation process for large and complex UML/OCL models. The technique includes a set of heuristics that are used to partition a model when determining its satisﬁability. That is, given a model ‘m’, the technique partitions m into m1 , m2 , m3 ,...mn submodels, where m is satisﬁable if all m1 , m2 , m3 ,...mn submodels are satisﬁable. This slicing technique is called the UML/OCL Slicing Technique (UOST). We provide an experimental evaluation of this technique using a veriﬁcation tool for UML to CSP which is called UMLtoCSP [4] and Alloy [8]. We examine both small and large UML/OCL models with 2, 15, 50, 100, 500, and 1000 UML/OCL class diagrams and several OCL invariants to measure the eﬃciency of the veriﬁcation process through our proposed UOST. The original explanation of the slicing technique can be found in [17]. However, this paper presents a solution for a non disjoint set of submodels using a more aggressive slicing technique that can still preserve the satisﬁability of the model after partitioning. It also provides extensive results achieved by adding the slicing technique to an external tool (Alloy). The primary reason for showing the results in both Alloy and UMLtoCSP is to demonstrate that the developed slicing technique is neither tool dependent nor formalism dependent. It can be applied into any formal veriﬁcation tool for UML/OCL models.

UML/OCL Aggressive Slicing Technique

175

The rest of the paper is structured as follows. Section 2 describes the concepts of UML/OCL model slicing. Section 3 presents the solution for non disjoint submodels. Sections 4 and 5 present the results obtained from model slicing. Section 6 reviews some previous work related to slicing. Finally, Sect. 7 presents conclusions and future work.

2

UML/OCL Model Slicing

The input of our method is a UML class diagram annotated with OCL invariants. Figure 1 introduces a class diagram that will be used as an example; the diagram models the information system of a bus company. Several integrity constraints are deﬁned as OCL invariants. Two diﬀerent notions of satisﬁability will be considered for veriﬁcation: strong satisﬁability and weak satisﬁability. A class diagram is weakly satisﬁable if it is possible to create at least one instance of at least one class out of all classes in the class diagram. Alternatively, in the case of strong satisﬁability, it is an obligation that at least one object of all classes must be instantiated [4]. For example, it is possible that objects of all classes are not instantiated due to multiple inheritance, composition, and aggregation. In this case, the model will be considered as unsatisﬁable in the case of strong satisﬁability. Consequently, strong satisﬁability requires the existence of an object for each concrete subclass of an abstract class. The proposed approach instantiates objects for veriﬁcation purposes based on a given class diagram and OCL constraints of the system. A successful veriﬁcation result ensures that the model complies with the system speciﬁcations imposed at the start of the development phase and therefore, the developers may continue with transforming the model into software code. The algorithm takes a UML/OCL model as an input, breaks it into several submodels with respect to invariants and veriﬁes the properties of each constraint to determine whether the input class diagram has legal instances which satisfy all integrity constraints of class attributes. The slicing algorithm can be applied over a large model to reduce the size and complexity of the UML/OCL model, so that it can be veriﬁed more eﬃciently. Slicing of UML class diagrams is dependent on the OCL constraints. Thus, if there are 3 constraints in the model, slicing might result in three submodels. A slice S of a UML class diagram D is another valid UML class diagram where any element (class, association, inheritance, aggregation, . . . ) appearing in S also appears in D, but the reverse does not necessarily hold. In the context of satisﬁability, saying that “a class X depends on a class Y ” means that creating an object of class Y creates an obligation that must be satisﬁed by class X, e.g., the existence of n corresponding objects in class X. Relationships like associations, aggregations, and inheritance hierarchies can create these types of dependencies. For instance, in associations the dependency is typically bidirectional, as the multiplicity of each association end imposes a dependency on the other class.

176

A. Shaikh, U.K. Wiil, and N. Memon

context Coach inv passengerSize : self.trips−>select(r|r.oclIsTypeOf(RegularTrip))−>forAll(t|t.passengers −>size() ≤ noOfSeats) context Ticket inv ticketNumberPositive: self.number > 0 context Passenger inv NonNegativeAge: self.age ≥ 0 Fig. 1. UML/OCL class diagram used as running example (model Coach)

2.1

The UOST Process

The method introduced for computing UML/OCL slicing is shown in Fig. 2. The process begins in step 1 by identifying the classes, associations, and generalizations created in model M and subsequently, drawing a ﬂowgraph. In step 2, we identify OCL invariants and group them if they restrict the same model elements. We call this “clustering of constraints” (Constraint Support). The constraint support deﬁnes the scope of a constraint. The support information can be used to partition a set of OCL invariants into a set of independent clusters of constraints, where each cluster can be veriﬁed separately. The following procedure is used to compute the clusters: – Compute the constraint support of each invariant. – Keep each constraint in a diﬀerent cluster. – Select two constraints x and y with non disjoint constraint supports and located in diﬀerent clusters, and merge those clusters. – Repeat the previous step until all pairs of constraints with non disjoint constraint supports belong to the same cluster.

UML/OCL Aggressive Slicing Technique

177

Fig. 2. UOST Process Steps

In step 3, for each cluster of constraints in model M, the partition P is determined that holds all those classes and relationships restricted by the constraints in the cluster. In this step, we can capture the possible number of slices with the consideration of OCL invariants. Each partition will be a subset of the original model. In step 4, tightly coupled classes are added to each partition in accordance with the lower bound ≥ 1 association. It means that if the constraint is restricted from class X, it is necessary to check the lower bound ≥ 1 associated classes with X. In this step, all the associated classes are added to a partition, which results in a model slice. 2.2

Flowgraph: Step 1

In this section, we illustrate the UOST Slicing Algorithm (2) through an example. Consider the ‘model Coach’ scenario whose UML class diagram and OCL constraints are shown in Fig. 1. There are three constraints that restrict the classes and out of them two are local invariants and one is global. An invariant is called local to a class C if it can be evaluated by examining only the values of the attributes in one object of class C. However, expressions that do not ﬁt into this category, because they need to examine multiple objects of the same class or some objects from another class, are called global. By applying step 1 (Fig. 2), we build a ﬂowgraph based on the identiﬁcation of classes, associations, and generalizations as shown in Fig. 3. We use the concept of a ﬂowgraph to capture the dependencies among model elements. This concept is also used by other slicing approaches [18,14,16]. A ﬂowgraph is a set of vertices and directed arcs where the vertices represent classes from a class diagram and the arcs model relationships between these classes. In our approach, a ﬂowgraph contains vertices and arcs for each pair of classes connected by associations, generalizations, aggregations, or compositions. We consider two types of relationships among classes; tightly associated and loosely associated classes. These relationships attempt to capture the necessity of creating instances of one class when an instance of the other exists. Loosely coupled classes have an association with a lower bound of 0 (e.g., 0..3); this

178

A. Shaikh, U.K. Wiil, and N. Memon

Fig. 3. Flowgraph of model Coach Table 1. Loosely and tightly coupled classes UML relationship Association: Lower bound ≥ 1 (e.g., 1..*) Association: Lower bound = 0 (e.g., 0..3) Generalization, Aggregation, and Composition

Loosely/Tightly Coupled Tightly Coupled Loosely Coupled Tightly Coupled

Arc/Edge −→ —–

means if an object of class A is instantiated, then it is not necessary that an object of class B must be instantiated. Tightly coupled classes are the inverse of loosely coupled classes, i.e., they have an association with a lower bound greater than 1 (e.g., 1..*). In the case of aggregation, composition, and generalized classes, we count them as tightly coupled classes. To diﬀerentiate aggregation, composition, and generalized classes from associations in the ﬂowgraph, we use a solid undirected edge (—–) as a shortcut for two directed arcs between the two classes. A tightly coupled association between two classes is shown as a solid arc (−→), while a loosely coupled association is shown as a dashed arc (). Table 1 brieﬂy summarizes the criteria to assign loosely coupled and tightly coupled relationships and Algorithm 1 shows the steps that compute a ﬂowgraph for a given class diagram. 2.3

Applying UOST: Step 2, Step 3, and Step 4

In this section, we compute constraint support, partitions and form the ﬁnal slices for veriﬁability. Considering the model Coach where Model M = (Coach, Trolley, Booking Ofﬁce, Passenger, Ticket, Trip, RegularTrip, VendingMachine, Manager, Employee, SalaryCategory, AdultTicket, and ChildTicket ) and Constraints C = (passengerSize, ticketNumberPositive, and NonNegativeAge). We are supposed to ﬁnd the legal instances of three invariants, i.e., passengerSize, ticketNumberPositive, and NonNegativeAge.

UML/OCL Aggressive Slicing Technique

179

Algorithm 1. Flowgraph creation Input: A model M Output: A labeled directed graph G = V, E {Start with the empty graph} Let V ← ∅ and E ← ∅ {Add all classes of the model to the flowgraph} for class c in model M do V ← V ∪ {c} end for {Create incoming and outgoing arcs in the flowgraph} for each association end A in model M do E ← (x, y) where x is the type of the association end and y is the type of the other class in the association 10: if the lower bound of the multiplicity of A is ≥ 1 then 11: Label the arc (x, y) as tightly coupled 12: else if the lower bound of the multiplicity of A = 0 then 13: Label the arc (x, y) as loosely coupled 14: end if 15: end for 16: for each generalization, aggregation and composition G between classes x and y do 17: E ← E ∪ {(x, y)} ∪ {(y, x)} 18: Label the arcs (x, y) and (y, x) as tightly coupled 19: end for

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

Applying step 2, we identify and cluster the OCL constraints. It is necessary to cluster the invariants beforehand, as the set of model elements constrained by each invariant may have an interaction. Considering Fig. 1, there are three invariants that restrict class Coach, Ticket, and Passenger. In this case, constraint NonNegativeAge will be merged with passengerSize because the properties of these constraints can be satisﬁed from similar model elements. Meanwhile, the properties of ticketNumberPositive can be satisﬁed from diﬀerent model elements. In step 3, for each constraint and group of constraints in model M, the partition P will be determined that holds all those classes and multiplicities from which the cluster of invariants are constrained. In this step, we can capture the possible number of slices with the consideration of OCL invariants. Each partition will be a subset of the original model. In step 4, all the tightly coupled classes are added into formed partitions in order to preserve the property of an invariant because it is necessary that the object of each class must be instantiated in case there is strong satisﬁability, otherwise, the property will not be satisﬁed. For the cluster of passengerSize and NonNegativeAge, we need classes Coach, Trip, RegularTrip, and Passenger while classes Ticket, BookingOﬃce, Trolley, VendingMachine, Manager, Employee, SalaryCategory, AdultTicket, and ChildTicket can safely be removed from the slice (i.e., s1). Similarly, to satisfy the properties of ticketNumberPositive, we require classes Booking Oﬃce, Coach, Trip, RegularTrip, Passenger, VendingMachine, Ticket, AdultTicket, and ChildTicket, while classes Trolley, Manager, Employee, and SalaryCategory can be deleted from the slice (i.e., s2). Figure 4(a) and 4(b) highlight the ﬁnal slices passed to the veriﬁcation tool for strong satisﬁability. The members of a slice are hence deﬁned as follows:

180

A. Shaikh, U.K. Wiil, and N. Memon

Algorithm 2. Slicing Algorithm Input: Property being verified Output: A partition P of the model M into non-necessarily disjoint submodels

1: G ← BuildF lowGraph(M ) {Creating the flowgraph} 2: {Cluster the OCL constraints} 3: for each pair of constraints c1, c2 in M do 4: if ConstraintSupport(M, c1) ∩ ConstraintSupport(M, c2) = ∅ then 5: MergeInSameCluster(c1, c2) 6: end if 7: end for 8: {Work on each cluster of constraints separately} 9: for each cluster of constraints Cl do 10: subModel ← empty model {Initialize the subModel to be empty} 11: {Initialize worklist} 12: workList ← Union of the ConstraintSupport of all constraints in the cluster 13: while workList not empty do 14: node ← first(workList) {Take first element from workList and remove it} 15: workList ← workList \ node 16: for each subclass or superclass c of node do 17: subModel ← subModel ∪{c} 18: if c was not before in the subModel then 19: workList ← workList ∪{c} 20: end if 21: end for 22: for each class c tightly coupled to node do 23: if P roperty = weak SAT then 24: subModel ← subModel ∪{c} 25: else if P roperty = strong SAT then 26: workList ← workList ∪{c} 27: end if 28: end for 29: end while 30: end for

– The classes and relationships in the cluster of constraint supports are part of the slice. – Any class with a tightly coupled relationship to a class in the slice is also a part of the slice, as is the relationship.

3

Non Disjoint Solution

In this section, we present the solution that still preserves the satisﬁability in case of non disjoint submodels. Non disjoint submodels may occur if a common class is used in several constraints. In the worst case, the clustering technique in Sect. 2 may result in the whole UML model and consequently no improvements in veriﬁcation time. The non disjoint solution can be selected by the designer in the tool (UMLtoCSP) if the model is constrained by several invariants in a way which makes clustering ineﬀective. The non disjoint solution diﬀers from the UOST process (see Fig. 2) in that it works without clustering the model elements, hence making it still possible to improve veriﬁcation time. The non disjoint solution is deﬁned as follows: Let C be a set of classes and let A = c∈C Ac be the set of attributes. M = C is the model consisting of these classes. Let R be the set of binary associations among two classes. Each association R is deﬁned as a tuple (C1 , C2 , m1 , M1 , m2 , M2 ) where:

UML/OCL Aggressive Slicing Technique

(a) Slice for passengerSize and NonNegativeAge

181

(b) Slice for ticketNumberPositive

Fig. 4. Slices of s1 and s2

– C1 ∈ C is a class. – C2 ∈ C is a class. – m1 and m2 are non-negative integers ∈ Z + where m1 and m2 correspond to the lower bound of the multiplicity of each association end for C1 and C2 , respectively. – M1 and M2 are non-negative integers or inﬁnity (M1 ∈ (Z + {∞})) where M1 and M2 corresponds to the upper bound of the multiplicity of each association end for C1 and C2 , respectively, and Mi ≥ mi . A Model M can be deﬁned as a tuple: (C, A, R). A submodel S of model M = (C, A, R) is another model (C , A , R ) such that: – – – – –

C ∈ C R ∈ R A ∈ A c ∈ C → Ac ⊆ A (C1 , C2 , m1 , M1 , m2 , M2 ) ∈ R → C1 , C2 ∈ C

An OCL expression speciﬁes the model entity for which the OCL expression is deﬁned. CL represents the OCL invariants while CLc are the clusters of constraints. The work list is deﬁned as WL which is the union of the constraint support of all constraints in the cluster. – Satisﬁability (Strong/Weak): If the objects of a given class C in a submodel S are instantiated as per given expression in the cluster of OCL constraints CLc , then submodel S is satisﬁable. – Unsatisﬁability: If there are two or more constraints whose interaction is unsatisﬁable, then submodel S is also unsatisﬁable. It indicates that some expression in the OCL invariant is violated and that the objects of the classes cannot be instantiated according to the given OCL expression.

182

A. Shaikh, U.K. Wiil, and N. Memon

A class diagram can be unsatisﬁable due to several reasons. First, it is possible that the model provides inconsistent conditions on the number of objects of a given type. Inheritance hierarchies, multiplicities of association/aggregation ends, and textual integrity constraints (e.g., Type::allInstances() → size() = 7) can restrict the possible number of objects of a class. Second, it is possible that there are no valid values for one or more attributes of an object in the diagram. Within a model, textual constraints provide the only source of restrictions on the values of an attribute, e.g., self.x = 7. Finally, it is possible that the unsatisﬁability arises from a combination of both factors, e.g., the values of some attributes require a certain number of objects to be created which contradicts other restrictions. To sum up, an unsatisﬁable model either contains an unsatisﬁable textual or graphical constraint or an unsatisﬁable interaction between one or more textual or graphical constraints, i.e., the constraints can be satisﬁed on their own but not simultaneously. In a class diagram, there could be a possibility to have one or more relationships between two classes, i.e., a class may have a relationship with itself and there may be multiple relationships between two classes. Multiple links between two classes or a link from one class to itself is called a ‘cycle’. For example, a cycle exists between ‘Researcher’ and ‘Paper’ in Fig. 5. The ‘maximum label’ is the highest upper bound multiplicity of the associations in a cycle. For example, the maximum label is 1 for constraints restricting papers and 3 for constraints restricting researchers. Any cycle in the class diagram where the maximum label is 1 is inherently satisﬁable, and it will be called safe. However, cycles where the maximum label ≥ 2 can be unsatisﬁable. Such cycles will be called unsafe. By “safe” we mean any cycle where the maximum label is 1 and imposing a single constraint is inherently satisﬁable where the OCL expression is self.attrib op expression where attrib is an attribute of a basic type (Boolean, Integer, Float, String) not constrained by any other constraint, op is a relational operator (=, =, <, >, ≤, ≥) and expression is a “safe” OCL expression which does not include any reference to attrib. The safe expression is a side-eﬀect free expression which cannot evaluate to the undeﬁned value in OCL (OclUndefined). This means that we do not allow divisions that can cause a division-by-zero or collection operations which are undeﬁned on empty collections like ﬁrst(). We present the non disjoint solution if slicing is applied over a UML model without clustering the constraints (i.e., without step 2 in the UOST process). There are three major steps that need to be considered as a solution: – Find the common class in all slices of the Model (M). – For each constraint, ﬁnd the maximum of the lower bound (m1 ) multiplicities relevant to the constraint from all associations of the common class. Set this maximum as the base value. Basec = max(m1 ) where (c, C2 , m1 , M1 , m2 , M2 ) ∈ R. – Compare the base value using the expression given in each constraint.

UML/OCL Aggressive Slicing Technique

183

context Researcher inv NoSelfReviews: : self.submission −>excludes(self.manuscript) context Paper inv AuthorsOfStudentPaper: self.studentPaper = self.author −>exists(x | x.isStudent) context Paper inv NoStudentReviewers: self.referee −>forAll(r | not r.isStudent) context Paper inv LimitsOnStudentPapers: Paper::allInstances()−>exists(p | p.studentPaper) and Paper::allInstances()−>select(p | p.studentPaper) −>size() < 5 Fig. 5. UML/OCL class diagram of ‘Paper-Researcher’ [3]

The OCL constraints can be either textual OCL invariants or graphical restrictions like multiplicities of association ends. This property is important not only because it can point out inconsistent models, but also because it can be used to check other interesting properties like the redundancy of an integrity constraint. For example, there could be a case where the invariants are constrained from the same class of the model. Figure 6 introduces a class diagram of ‘model Company’ used to exemplify our non disjoint solution. There are two constraints departmentEmployeeSize and projectEmployeeSize whose properties need to be checked. Invariant departmentEmployeeSize is satisﬁable however, invariant projectEmployeeSize is unsatisﬁable due to a violation of multiplicity. After applying the slicing technique without clustering the invariants, we will receive two submodels i.e., two non disjoint slices. Slice 1 will consist of class ‘Department’ and class ‘Employee’ for constraint departmentEmployeeSize. Similarly, class ‘Project’ and class ‘Employee’ for invariant projectEmployeeSize will be part of slice 2. In this case, slice 1 is satisﬁable, however, slice 2 is unsatisﬁable. The definition of the slicing procedure ensures that the property under veriﬁcation is unsatisﬁable after partitioning because the overall interaction of the model is unsatisﬁable. Initially, our non disjoint approach ﬁnds the common class in all slices of model (M), i.e., class ‘Employee’. Secondly, the method ﬁnds the maximum of minimum (max min) multiplicities from the common class (Employee) for each constraint considering its navigation. For example, the navigation of invariant “departmentEmployeeSize” is class ‘Department’ navigating to class ‘Employee’. Therefore, the approach considers the multiplicity between the navigation of

184

A. Shaikh, U.K. Wiil, and N. Memon

context Department inv departmentEmployeeSize : self.employee()−>size() = 10 context Project inv projectEmployeeSize: self.employee()−>size() ≥ 15

Fig. 6. UML/OCL class diagram used as non disjoint solution (model Company)

class department and class employee, i.e., ‘10’ and ‘1..2’. As the constraint restricts class employee, ‘10’ is the base value for the “departmentEmployeeSize” invariant. Similarly, ‘14’ is the base value for the navigation of class ‘Project’ and class ‘Employee’. Finally, the method compares the base value (i.e., 10) for invariant “departmentEmployeeSize” using the expression given in a constraint self.employee()→ size() = 10 whose interaction is satisﬁable. However, invariant “projectEmployeeSize” is violating the condition, i.e., using the expression self.employee()→ size() ≥ 15 where 14 is not ≥ 15. Hence, the overall interaction of the model is unsatisﬁable.

4

UOST Implementation in UMLtoCSP

We have implemented our proposed slicing technique (UOST) in UMLtoCSP [4] in order to show the improvement of the eﬃciency in the veriﬁcation process. After developing UOST, we named our tool as UMLtoCSP(UOST). The execution time of veriﬁcation of an original UMLtoCSP depends mainly on the number of classes/attributes and the parameters oﬀered during the transformation to the Constraint Satisfaction Problem (CSP). In case of small models, UMLtoCSP

UML/OCL Aggressive Slicing Technique

185

Table 2. Description of the examples

Example Classes Associations Attributes Invariants Paper-Researcher 2 2 6 1 Coach 15 12 2 2 Tracking System 50 60 72 5 Script 1 100 110 122 2 Script 2 500 510 522 5 Script 3 1000 1010 1022 5 Table 3. Description of experimental results (UMLtoCSP) Before Slicing (UMLtoCSP) After Slicing (UMLtoCSP UOST) Classess Attributes OVT Attributes ST SVT 2 6 2506.55s 3 0.00s 0.421s 15 2 5008.76s 0 0.00s 0.178s 50 72 3605.35s 55 0.016s 0.031s 100 122 Time out 117 0.016s 0.032s 500 522 Time out 502 0.062s 0.028s 1000 1022 Time out 1012 0.282s 0.339s

OVT Original Veriﬁcation Time SVT Sliced Veriﬁcation Time

TVT Speedup % 0.421s 99.98% 0.178s 99.99% 0.047s 99.99% 0.048s 99.99% 0.090s 99.99% 0.621s 99.98%

ST Slicing Time TVT Total Veriﬁcation Time

provides quick results while for larger ones, the tool takes a huge of amount of time. In order to evaluate the eﬃciency of our developed UOST approach in UMLtoCSP, several models have been used (Table 2). UMLtoCSP takes a lot of time to verify the instances of large examples, therefore, we set a time out to 1 hour 30 minutes which is equal to 5400 seconds. If UMLtoCSP does not verify the model in the prescribed time, we will count this situation as Time out. Table 3 summarizes the experimental results obtained by UMLtoCSP and UMLtoCSP(UOST) running on an Intel Core 2 Duo 2.10 Ghz with 2Gb of RAM where, the column OVT is the original veriﬁcation time of UMLtoCSP, column TVT is the total veriﬁcation time of all slices of UMLtoCSP(UOST), and column speedup shows the eﬃciency obtained after the implementation of the slicing approach. We have used the following parameters for the experiments: each class may have at most 4 instances, associations may have at most 1010 links and attributes may range from 0 to 1022. The speedup is calculated using the equation {1 − (T V T /OV T )} ∗ 100. Figure 7 shows the object diagram for s1 in the case of strong satisﬁability and Fig. 8 represents the object diagram for s2 in the case of weak satisﬁability, where there is no need to instantiate unused subclasses (i.e., AdultTicket and ChildTicket). The object diagrams are generated using UMLtoCSP (UOST). 4.1

Limitations

Our proposed technique is limited and cannot partition the UML/OCL model and abstract the attributes if the constraints are restricted from all classes using all attributes of the class diagram. In this case, the technique will consider a

186

A. Shaikh, U.K. Wiil, and N. Memon

Fig. 7. Submodel 1 (s1) object diagram for strong satisﬁability

Fig. 8. Submodel 2 (s2) for weak satisﬁability

UML/OCL model as a single model and therefore, there will be no diﬀerence between UMLtoCSP and UMLtoCSP(UOST). Table 4 describes the worst case examples that cannot be sliced using UOST. The example Paper-Researcher is a real world-example created manually which contains 2 classes, 6 attributes, 2 associations, and 4 invariants while example Company is script-generated and has 100 classes, 100 attributes, 100 associations, and 100 invariants. In these examples, partitioning cannot be done by the proposed UOST technique because each instance of a class is restricted by an invariant.

5

UOST Implementation in Alloy

In this section, we present several examples in the Alloy speciﬁcation in order to prove that our developed slicing technique is neither tool dependent nor formalism dependent. We compare the veriﬁcation time of several UML/OCL class

UML/OCL Aggressive Slicing Technique

187

Table 4. Worst case examples Tool & Example Classes Associations Attr Inv NOS OVT UMLtoCSP 2 2 5 4 0 0.040 s (Paper-Researcher) UMLtoCSP(UOST) 2 2 5 4 0 0.036 s (Paper-Researcher) UMLtoCSP 100 100 100 100 0 0.070 s (Company) UMLtoCSP(UOST) 100 100 100 100 0 0.078 s (Company)

Attr Associatons NOS Number of Slices

Inv Invariants OVT Original Veriﬁcation Time

Table 5. Description of the examples Example Classes Associations Attributes Invariants Atom-Molecule 2 2 3 2 University 4 3 8 5 ATM Machine 50 51 51 7 Script 1 100 110 122 2 Script 2 500 510 522 5 Script 3 1000 1010 1022 5

diagrams using the Alloy analyzer with and without the UOST technique. Table 5 describes the set of benchmarks used for our comparison: the number of classes, associations, invariants, and attributes. The benchmarks “Script” was programmatically generated, in order to test large input models. Of these models, we consider the “Script” models to be the best possible scenarios for slicing (large models with many attributes and very few constraints). Tables 6, 7, 8, 9, 10, and 11 summarize the experimental results obtained using the Alloy analyzer before and after slicing, running on an Intel Core 2 Duo Processor 2.1Ghz with 2Gb of RAM. Each table represents the results as described in the benchmark (Table 5). The execution time is largely dependent on the deﬁned scope, therefore, in order to analyze the eﬃciency of veriﬁcation, the scope is limited to 7. The Alloy analyzer will examine all the examples with up to 7 objects, and try to ﬁnd one that violates the property. For example, saying scope 7 means that the Alloy analyzer will check models whose top level signatures have up to 7 instances. All times are measured in milliseconds (ms). For each scope (before slicing), the translation time (TT), solving time (ST), and the summation of the TT and ST, which is the total execution time, are described. Similarly, for each scope (after slicing) we measure the sliced translation time (STT), sliced solving time (SST), and the summation of STT and SST. Similarly, the column speed up shows the eﬃciency obtained after the implementation of the slicing approach. Previously with no slicing, it took 820 ms (scope 7) for the execution of the “ATM Machine” and 282161 ms (scope 7) for “Script 3”. Using the UOST

188

A. Shaikh, U.K. Wiil, and N. Memon Table 6. Slicing results in Alloy for the Atom-Molecule example Before Slicing After Slicing Scope TT ST TT+ST STT SST STT+SST Speedup % 2 3ms 9ms 12ms 3ms 5ms 8ms 34% 3 7ms 8ms 15ms 3ms 6ms 9ms 40% 4 12ms 8ms 20ms 4ms 6ms 10ms 50% 5 17ms 10ms 27ms 4ms 9ms 13ms 52% 6 16ms 15ms 31ms 5ms 9ms 14ms 55% 7 19ms 15ms 34ms 6ms 9ms 15ms 56% TT Translation Time ST Solving Time STT Sliced Translation Time SST Sliced Solving Time

Table 7. Slicing results in Alloy for the University example Before Slicing Scope 2 3 4 5 6 7

TT 7ms 14ms 28ms 36ms 45ms 81ms

After Slicing ST TT+ST STT SST STT+SST Speedup % 10ms 17ms 3ms 5ms 8ms 53% 19ms 33ms 5ms 8ms 13ms 61% 20ms 48ms 7ms 10ms 17ms 62% 31ms 67ms 12ms 15ms 27ms 65% 50ms 95ms 17ms 15ms 32ms 67% 77ms 158ms 34ms 17ms 51ms 68%

TT Translation Time STT Sliced Translation Time

ST Solving Time SST Sliced Solving Time

Table 8. Slicing results in Alloy for the ATM Machine Before Slicing Scope 2 3 4 5 6 7

TT 20ms 83ms 96ms 158ms 233ms 325ms

After Slicing ST TT+ST STT SST STT+SST Speedup % 46ms 66ms 5ms 8ms 13ms 81% 91ms 174ms 9ms 11ms 20ms 89% 185ms 254ms 13ms 11ms 24ms 90% 173ms 332ms 20ms 12ms 32ms 90% 367ms 600ms 25ms 23ms 48ms 92% 495ms 820ms 30ms 28ms 58ms 93%

TT Translation Time STT Sliced Translation Time

ST Solving Time SST Sliced Solving Time

Table 9. Slicing results in Alloy for script 1 Before Slicing Scope 2 3 4 5 6 7

TT 110ms 161ms 224ms 349ms 589ms 799ms

After Slicing ST TT+ST STT SST STT+SST Speedup % 133ms 243ms 7ms 9ms 16ms 93% 290ms 451ms 9ms 9ms 18ms 96% 591ms 815ms 14ms 12ms 26ms 97% 606ms 955ms 17ms 16ms 33ms 97% 1077ms 1666ms 27ms 25ms 52ms 97% 1392ms 2191ms 38ms 25ms 63ms 97%

TT Translation Time STT Sliced Translation Time

ST Solving Time SST Sliced Solving Time

UML/OCL Aggressive Slicing Technique

189

Table 10. Slicing results in Alloy for script 2 Before Slicing Scope 2 3 4 5 6 7

TT 1839ms 2567ms 3374ms 4326ms 5231ms 6477ms

ST 3021ms 7489ms 8320ms 21837ms 32939ms 59704ms

TT+ST 4860ms 10056ms 11694ms 26163ms 38170ms 66181ms

TT Translation Time STT Sliced Translation Time

After Slicing STT SST STT+SST Speedup % 6ms 7ms 13ms 99.7% 11ms 8ms 19ms 99.8% 14ms 9ms 23ms 99.8% 18ms 14ms 32ms 99.8% 25ms 14ms 39ms 99.8% 35ms 16ms 51ms 99.9%

ST Solving Time SST Sliced Solving Time

Table 11. Slicing results in Alloy for script 3 Before Slicing Scope 2 3 4 5 6 7

TT 9548ms 9734ms 12496ms 15702ms 19496ms 23089ms

ST 12941ms 30041ms 66861ms 85001ms 185118ms 259072ms

TT+ST 22489ms 39775ms 79357ms 100703ms 204614ms 282161ms

TT Translation Time STT Sliced Translation Time

After Slicing STT SST STT+SST Speedup % 6ms 8ms 14ms 99.93% 13ms 10ms 23ms 99.94% 19ms 10ms 29ms 99.96% 22ms 13ms 35ms 99.96% 29ms 16ms 45ms 99.97% 35ms 17ms 52ms 99.98%

ST Solving Time SST Sliced Solving Time

approach, it takes only 58 ms (scope 7) for “ATM Machine” and 52 ms (scope 7) for “Script 3”. It is an improvement of 93% and 99.98%, respectively. In addition, the improvement can also be achieved for larger scopes as well. For instance, results for up to scope 50 can be achieved for the “ATM Machine” and scope 35 for “Script”. However, without slicing we could only run the analysis for limited scopes.

6

Related Work

In this section, we discuss existing work on model partitioning or slicing. Most of the work in this area is done for UML Architectural Models, Model Slicing, and Program Slicing which is limited to slicing only. Their goal of slicing is to break larger programs or models into small submodels to reuse the required segments. However, research work on partitioning of UML/OCL models in terms of veriﬁability is not found in the literature. Previously, we proposed a slicing technique for models considering a UML class diagrams annotated with unrestricted OCL constraints and a speciﬁc property to verify [17]. The slicing approach was based on disjoint slicing, clustering and the removal of trivially satisﬁable constraints. An implementation of the slicing technique has been developed in a UMLtoCSP tool. Experimental results demonstrate that slicing can verify complex UML/OCL models and speed-up the veriﬁcation time.

190

A. Shaikh, U.K. Wiil, and N. Memon

In contrast, this paper presents an aggressive slicing technique which can still preserve the property under veriﬁcation for non disjoint set of submodels. We attempt to achieve the results in an external tool ‘Alloy’ in order to prove that the proposed slicing technique is not limited to a single tool (i.e., UMLtoCSP) but can also be used for other formal veriﬁcation tools. The slicing procedure breaks the original model into submodels (slices) which can be veriﬁed independently and where irrelevant information has been abstracted. The deﬁnition of the slicing procedure ensures that the property under veriﬁcation is preserved after partitioning. 6.1

UML Model Slicing

A theory of model slicing to support and maintain large UML models is mostly discussed. Current approaches of model veriﬁcation have an exponential worstcase runtime. Context free slicing of the model summarizes static and structural characteristics of a UML model. The term context points towards the location of a particular object. It takes into account static and structural aspects of a UML model and excludes the enclosure of interaction information [10]. Similarly, to compute a slice of a class hierarchy of a program, it is necessary to eliminate those slices that are unnecessary thereby ensuring that the behavior of the programs would not be aﬀected. This approach represents the criteria of model abstraction [9]. One possible approach to manage the complexity of the UML metamodel is to divide the metamodel into a set of small metamodels for each discussed UML diagram type [1]. The proposed method deﬁnes a metamodel of a directed multi-graph for a UML Metamodel Slicer. The slicer builds submetamodels for a diagram with model elements. Another slicing technique for static and dynamic UML models presents the transformation of a UML architectural model into a Model Dependency Graph (MDG). It also merges a diﬀerent sequence of diagrams with relevant information available in a class diagram [13]. 6.2

Architectural Slicing

The concept of architectural slicing is used to remove irrelevant components and connectors, so that the behavior of the slice is preserved [19]. This research introduces a new way of slicing. Architectural slicing is used to slice a speciﬁc part of a system’s architecture. The sliced part is used to view higher level speciﬁcations. Similar to this approach, a dependency analysis technique is developed which is based on the slicing criteria of an architectural speciﬁcation as a set of component parts [7]. The technique is named chaining. It supports the development of software architecture by eliminating unnecessary parts of the system. Furthermore, the notion of dynamic software architecture slicing (DSAS) supports software architecture analysis. This work is useful when a huge amount of components is available. DSAS extracts the useful components of the software architecture [12].

UML/OCL Aggressive Slicing Technique

6.3

191

Program Slicing

Program slicing [18, 6] techniques work on the code level, decomposing source code automatically. In this research, a dataﬂow algorithm is presented for program slices. A recursive program written in the Pascal language is used to compute the slices. A comparable algorithm is developed to slice the hierarchies of C++ programs. It takes C++ class and inheritance relations as an input and eliminates all those data members, member functions, classes, and relationships that are irrelevant ensuring that the program behavior is maintained. This work gave us the motivation to reduce and eliminate those classes and relationships which do not have any relation to the UML/OCL model [6]. However, to the best of our knowledge, none of the previous approaches consider OCL constrains and none is oriented towards veriﬁcation of UML/OCL models. All the related work presented so far is not similar to our approach because it is based on the slicing of UML models while our proposed slicing techniques also cover veriﬁability of UML/OCL models. In contrast, we compute a slice that includes only those classes which are necessary to preserve in order to satisfy the OCL constraints that restrict the classes.

7

Conclusion and Future Work

In this paper, we have presented a slicing technique (UOST) to reduce the veriﬁcation time in order to improve the eﬃciency of the veriﬁcation process. The approach accepts a UML/OCL model as input and automatically breaks it into submodels where the overall model is satisﬁable if all submodels are satisﬁable. We propose to (1) discard those classes from the model that do not restrict any constraints and are not tightly coupled and (2) eliminate all irrelevant attributes. The presented approach of model slicing can ease model analysis by automatically identifying the parts of the model that are useful to satisfy the properties in the model. During the veriﬁcation process, complex models require many resources (such as memory consumption and CPU time), making veriﬁcation unbearable with existing tools. UOST can help reduce the veriﬁcation time. We have implemented this approach in our developed tool UMLtoCSP and in an external tool Alloy to provide a proof of concept. As part of our future work, we plan to explore three research directions. First, we plan to optimize our slicing approach by eliminating loosely coupled superclasses and subclasses. Second, we optimize our UOST by discarding aggregations and compositions with optional multiplicities. On the other hand, we also plan to explore diﬀerent sets of values for multiplicities such as a bus may have [45, 55, 65] seats instead of 1..* seats. Third, we will investigate a feedback technique that provides useful directions to a software engineer in case of unsatisﬁability to allow the software engineer to focus her attention to the incorrect submodels while ignoring the rest of the model.

192

A. Shaikh, U.K. Wiil, and N. Memon

References 1. Bae, J.H., Lee, K., Chae, H.S.: Modularization of the UML Metamodel Using Model Slicing. In: ITNG, pp. 1253–1254. IEEE Computer Society, Los Alamitos (2008) 2. Cabot, J., Claris´ o, R.: UML/OCL Veriﬁcation in Practice. In: MoDELS 2008. Workshop on Challenges in MDE, ChaMDE 2008 (2008) 3. Cabot, J., Clariso, R., Riera, D.: Papers and Researchers: An Example of an Unsatisﬁable UML/OCL Model, http://gres.uoc.edu/UMLtoCSP/examples/Papers-Researchers.pdf 4. Cabot, J., Claris´ o, R., Riera, D.: UMLtoCSP: A Tool for the Formal Veriﬁcation of UML/OCL Models Using Constraint Programming. In: ASE 2007, pp. 547–548. ACM, New York (2007) 5. Cabot, J., Claris´ o, R., Riera, D.: Veriﬁcation of UML/OCL Class Diagrams Using Constraint Programming. In: ICSTW 2008, pp. 73–80. IEEE Computer Society, Los Alamitos (2008) 6. Georg, G., Bieman, J., France, R.B.: Using Alloy and UML/OCL to Specify Runtime Conﬁguration Management: A case study. In: Workshop of the UML-Group 7. Staﬀord, D.J.R.J.A., Wolf, A.L.: Chaining: A Software Architecture Dependence Analysis Technique. Technical Report, University of Colorado, Department of Computer Science (1997) 8. Jackson, D.: Alloy: A Lightweight Object Modelling Notation. ACM Transactions on Software Engineering and Methodology 11(2), 256–290 (2002) 9. Choi, J.-D., Field, J.H., Ramalingam, G., Tip, F.: Method and Apparatus for Slicing Class Hierarchies, http://www.patentstorm.us/patents/6179491.html 10. Kagdi, H.H., Maletic, J.I., Sutton, A.: Context-free Slicing of UML Class Models. In: ICSM 2005, pp. 635–638. IEEE Computer Society, Los Alamitos (2005) 11. Kellom¨ aki, P.: Veriﬁcation of Reactive Systems Using DisCo and PVS. In: Fitzgerald, J.S., Jones, C.B., Lucas, P. (eds.) FME 1997. LNCS, vol. 1313, pp. 589–604. Springer, Heidelberg (1997) 12. Kim, T., Song, Y.-T., Chung, L., Huynh, D.T.: Dynamic Software Architecture Slicing. In: COMPSAC, pp. 61–66. IEEE Computer Society, Los Alamitos (1999) 13. Lallchandani, J.T., Mall, R.: Slicing UML Architectural Models. In: ACM / SIGSOFT SEN, vol. 33, pp. 1–9 (2008) 14. Lanubile, F., Visaggio, G.: Extracting Reusable Functions by Flow Graph-based Program Slicing. IEEE Trans. Softw. Eng. 23(4), 246–259 (1997) 15. Ojala, V.: A Slicer for UML State Machines. Technical Report 25, Helsinki University of Technology (2007) 16. Qi Lu, J.Q., Zhang, F.: Program Slicing: Its Improved Algorithm and Application in Veriﬁcation. Journal of Computer Science and Technology 3, 29–39 (1988) 17. Shaikh, A., Claris´ o, R., Wiil, U.K., Memon, N.: Veriﬁcation-driven Slicing of UML/OCL Models. In: ASE, pp. 185–194 (2010) 18. Weiser.sk, M.: Program Slicing. IEEE Trans. Software Eng., 352–357 (1984) 19. Zhao, J.: Applying Alicing Technique to Software Architectures. CoRR, cs.SE/0105008 (2001)

Extensible and Automated Model-Evaluations with INProVE S¨ oren Kemmann, Thomas Kuhn, and Mario Trapp Fraunhofer IESE {soeren.kemmann,thomas.kuhn,mario.trapp}@iese.fraunhofer.de http://www.iese.fraunhofer.de

Abstract. Model-based development is gaining more and more importance for the creation of software-intensive embedded systems. One important aspect of software models is model quality. This does not imply functional correctness, but non-functional properties, such as maintainability, scalability, extensibility. Lots of eﬀort was put into development of metrics for control ﬂow models. In the embedded systems domain however, domain speciﬁc- and data ﬂow languages are commonly applied for model creation. For these languages, existing metrics are not applicable. Domain and project speciﬁc quality metrics therefore are informally deﬁned; tracking conformance to these metrics is a manual and eﬀort consuming task. To resolve this situation, we developed INProVE. INProVE is a model-based framework that supports deﬁnition of quality metrics in an intuitive, yet formal notion. It provides automated evaluation of design models through its indicators. Applied in diﬀerent industry projects to complex models, INProVE has proven its applicability for quality assessment of data ﬂow-oriented design models not only in research, but also in practice. Keywords: Quality Modeling, Quality Assurance, Automated Quality Evaluation, Quality Evolution, Simulink, Model Quality.

1

Introduction

Embedded software is an integral part of our daily life. Being very speciﬁc to applications, software development in embedded system domains is often done by domain experts, not by software developers. Model driven development (MDD) strengthens this trend because modern graphical modeling languages, e.g. Simulink, resemble the concepts of application domains, not those of software engineering. Domain speciﬁc languages are even tighter tailored to needs of domain experts, enabling non software developers to rapidly generate software systems of considerable complexity. Explicit software engineering and programming skills are not necessary when developing software models with these languages. Naturally, domain experts focus on the functionality of their developed systems. Ambient pressure due to project deadlines enforces rapid development and F.A. Kraemer and P. Herrmann (Eds.): SAM 2010, LNCS 6598, pp. 193–208, 2011. c Springer-Verlag Berlin Heidelberg 2011

194

S. Kemmann, T. Kuhn, and M. Trapp

testing of software solutions. Customers perceive directly system functionality; for them, quality is equivalent with correctness, timeliness, and a suﬃcient number of features. These quality characteristics are external characteristics, which become visible once a system is executed, and may be validated during testing. Internal quality is diﬀerent; it describes how a system is structured. Failing in internal quality has no direct eﬀect to system behavior; therefore, there is no direct penalty to developers. Therefore, quality assurance often focuses primarily on measuring of external quality and assesses product quality based on these metrics only. This omits a large set of quality attributes that aﬀect for example future portability, maintainability, and reliability of developed systems. Over time, undetected problems with internal quality will grow and have signiﬁcant impact on external quality characteristics. It leads to an increasing number of unexpected defects with growing system complexity, yielding product lines that become very hard to maintain, leading to increasing resource requirements and unpredictable timing behavior. Therefore, consideration of internal quality is imperative. Measuring internal software quality characteristics is tricky. It is not possible to deﬁne test-cases whose success and fail ratios are measured. It is also not possible to measure the number of model elements, lines of code and comments to provide meaningful numbers. For some modeling languages, e.g. for the UML, language speciﬁc standard quality metrics, such as coupling and cohesion of components are deﬁned [1]. These metrics provide some insights into model quality, but never address company-speciﬁc needs. For example, coupling between a subset of components may not be relevant for one company. In another company however, these components may be part of a product line, and therefore coupling and cohesion is of high importance. Therefore, existing standards (cf. [2,3]) deﬁne quality characteristics, and therefore provide guidelines for setting up quality goals. However, concrete attributes that measure quality are omitted in standards; these are company speciﬁc and need to be deﬁned individually. Therefore, tools and frameworks that analyze internal quality attributes need to be customizable to support company and product speciﬁc metrics. Software architects must be able to formulate software quality indicators that match architecture guidelines. Predeﬁned indicators, such as coupling and cohesion, may be helpful, but cannot replace customization. Customized indicators and automated quality measuring of models enable evaluation, visualization, and monitoring of internal quality of big software systems. This prevents uncontrolled growing and “quick and dirty” ﬁxes, and therefore ensures high software quality in the long term. INProVE (Indicator-based Non-functional Property-oriented eValuation and Evolution of software design models), our extensible quality modeling and assurance framework, supports formalization of internal quality attributes as well as their measurement and control. It may be adapted to modeling languages, which is important due to the high number of languages that are used for embedded

Extensible and Automated Model-Evaluations with INProVE

195

systems development. By monitoring deﬁned quality metrics automatically without any manual eﬀort from developers, INProVE is able to provide quality metrics of a project at any time. In the following, we describe INProVE, its concepts, and implementation. The remainder of this paper is therefore structured as follows: In Sect. 2, we survey and discuss relevant state of the art with respect to quality evaluation of models. Section 3 describes the rationale of INProVE which yielded from interviews with software architects and quality managers. Section 4 deﬁnes indicators as the core concept of our INProVE framework. In Sect. 5, we describe the implementation of INProVE and practical applications. Section 6 draws conclusions any lays out future work.

2

Related Work

Quality evaluation of software models is not a new research area. Numerous academic and practical approaches already exist besides of INProVE. In this section, we survey important related approaches and discuss their relevance, similarities, and diﬀerences to INProVE. For this reason, we divide related approaches into two categories: The ﬁrst category contains architecture-centric assessments, including reviews and inspections, while the second category contains metric suites, which mostly focus on automated checking of modeling guidelines. The most prominent representative of the ﬁrst category is the ATAM method deﬁned by SEI [4]. Based on a systematic deﬁnition of relevant quality attributes by means of utility trees, customized scenarios are deﬁned for checking whether or not software architectures fulﬁll required qualities. The ATAM approach is a manual approach, which may be applied to code and model centric projects. It requires skilled software engineers. While ATAM supports the formalization of knowledge regarding model quality, its manual nature requires a very skilled and disciplined team to apply this approach in practice. For code-centric projects, there exist numerous pre-deﬁned metrics, which emerged to quasi-standards for measuring software quality on code level. They cover coupling, cohesion and the cyclomatic complexity [5]. Furthermore, “bad smells” have been deﬁned by Fowler [6], which are a collection of lessons learned for detecting bad code-design. The lifting from “bad smells” to “bad UML smells” [7] enables also basic quality evaluation of model-centric projects that are based on the UML. Similar guildelines regarding model quality have been published through the MAAB guidelines [8] for Matlab/Simulink. Automated model quality evaluation is already supported by existing tools. First commercial tools that automatically check modeling guidelines are the Simulink Model Advisor [9] and the MINT tool [10]. These tools check predeﬁned guidelines to assess quality of software and system models. Both support the Matlab/Simulink tool-chain. Another tool implementation yielded from the MATE project that does not only support checking of predeﬁned modeling guidelines, but enables also designing of new guidelines. Furthermore, MATE pursues the goal of providing a means to specify modeling guidelines and semi-automatic repair functionalities in a graphical manner [11].

196

S. Kemmann, T. Kuhn, and M. Trapp

All of the aforementioned tools have in common that they check models against predeﬁned or customizable guidelines. For meaningful quality evaluation, customizable combination and interpretation of measurement results is missing, which prevents eﬃcient integration of company speciﬁc quality guidelines. In addition, we notice that guidelines and tools are language speciﬁc. As a result, there are no agreed quality metrics available for less widespread languages; a lack of conﬁgurability prevents adaptation of existing tools to new languages. Guidelines and techniques without tool support require considerable eﬀort and recurring meetings for gathering quality data, and are therefore impractical in most scenarios.

3

Rationale of INProVE

The rationale of INProVE is to support automated model quality evaluation, monitoring and to support and track model quality improvements. To deﬁne the overall concepts of INProVE, we interviewed experts to elicit basic requirements and to obtain their native formalization schemes for model quality metrics. 3.1

Quality Indicators

When reasoning about model quality, the ability to quantify model quality through metrics is imperative. We apply the concept of indicators to measure internal quality attributes that enable assessment of quality characteristics. This includes maintainability and portability, but may also include internal attributes of additional quality characteristics such as reliability. INProVE indicators specify and assess individual quality attributes that measure conformance to quality attributes. An indicator therefore provides one output metric for one quality attribute, which is calculated out of one or multiple inputs. These may be model features, which represent basic properties of the model, e.g. the number of input ports of a block, or advanced quality attributes that yield from other indicators. To learn about feasibly and accepted approaches to deﬁne indicators that measure quality attributes, we did interview experts to collect their native formalization schemes. During this process, we obtained the following insights: – Patterns and anti-patterns: The ﬁrst observation that we made when asking experts for information about quality properties is that these questions often result in examples. Experts sketch an example of a good and a bad property by omitting all unimportant aspects and concentrate on a part of the model. Thus, examples are a preferred notation for experts to express their understanding of quality for a given project or product. These examples are subdivided into patterns that deﬁne examples for good modeling approaches and for bad modeling approaches. Bad modeling approaches are formalized as anti-patterns. These are especially useful because they may be detected very fast by developers and tools. Formalizing examples in the form of antipatterns is therefore one of the most intuitive, traceable and fastest ways to

Extensible and Automated Model-Evaluations with INProVE

197

conserve expert knowledge. An example anti-pattern is the following, which deﬁnes that an interface size of a component must not exceed the value of 20: Error: Component.portCount > 20 – Conditional patterns: Sometimes, counterexamples are too speciﬁc and narrow and therefore do not completely express the experts’ understanding of quality. In this case, one either gets conditioned examples, or the experts generally talk about logical dependencies of measurable model properties, e.g. the size of an interface or the number of input ports. Thus, an expert naturally has a logical net in mind, which expresses conditions, properties, and their interdependencies. Asking an expert for measurements of quality attributes results in "If... then..." clauses like: “If property x1 is given and additionally condition A holds then the model quality in question is weak. If property x1 is not given and property x2 holds then the model quality in question is strong.” – Fuzzy characterization: In most cases, experts use logical classes for expressing model quality like “interface size is high.” From time to time it is not possible to deﬁne sharp criteria as to whether a value belongs to a class or not. If, for example, the threshold of for an acceptable interface size is set to 20, it is certainly not in the intention of an expert that an interface size of 19 is ok and does not need any consideration. Sharp thresholds are usually diﬃcult to ﬁnd and hardly meet the experts’ intention. – Combination of metrics: A last observation that we made is about the combination of existing quality metrics. Taking, for example, the results of standard indicators, such as FanIn, FanOut, Cohesion, and Coupling, into account, only general quality information is evaluated. By combining this information through operators, e.g. logical operators, these basic pieces of information may be combined into more complex indicators, which yield valuable knowledge. While talking to experts, it also became evident that an extensive library of predeﬁned indicators is not as relevant to them as the ability to create their own, domain-speciﬁc set of indicators, which includes quality attributes important for one speciﬁc setting. Custom quality indicators therefore support modeling of domain-speciﬁc quality information. 3.2

Concept of the INProVE Framework

Numerous modeling languages are applied in the embedded systems domain. Prominent examples include Simulink, ASCET, Modelica, and Labview just for design of data ﬂow behavior. Supporting all of these languages and associated tool chains natively is impractical. Most of these languages share common modeling features, however. For example, data ﬂow based languages are based on the concept of communicating blocks with links between them that represent data ﬂow. Sharing quality guidelines between similar languages therefore makes sense.

198

S. Kemmann, T. Kuhn, and M. Trapp

Therefore, INProVE deﬁnes intermediate meta models that represent core features of modeling languages. Indicators operate on these meta models. A generic meta model for data ﬂow languages deﬁnes ports, blocks, block types, ﬂows, and composite structures. Features of concrete modeling languages map to these models to a certain degree. Storage of additional features is permitted through deﬁnition of additional meta models. Meta models may be based on each other. This enables inheritance hierarchies, which enables re-use of indicators and permits integration of language speciﬁc features at the same time. New modeling languages are integrated through adapters into INProVE. Adapters parse native inputs and convert them into a model that conforms to INProVE meta models. They are realized either as model-to-model, or text-to-model transformations.

Developer Project Manager Software Architect C

C

V

V

M

M

Simulink model

Dataflow model

Indicator

Design model

Model adapter

Simulink model

Dataflow model

Fig. 1. INProVE Framework structure

Based on the aforementioned concepts, the basic structure of the INProVE framework was devised as shown in Fig. 1. Model adapters transform native model representations into common intermediate models that conform to meta models. Quality indicators operate on these intermediate models. They build the quality data base of a speciﬁc company or domain. Quality indicators may be used for every model, that conforms at least to their required meta model.

Extensible and Automated Model-Evaluations with INProVE

4

199

INProVE Indicators

In this section, we provide in-depth information regarding INProVE indicators and describe their development and principles in detail. Quality indicators support modeling of custom quality attributes and conserve quality knowledge. Therefore, they are the most important part of the INProVE framework. 4.1

The Anatomy of Indicators

The basic outline of an indicator is presented in Fig. 2. Every indicator consists of three sequential steps, which are realized as one pipeline with optional subpipelines: operations on model level (M), operations on value level (V), check of classiﬁcation (C). Operations on model level are model-to-model transformations; operations on V level are value-to-value transformations. Transition between M and V is through a measurement transformation, transition between V and C is through a classiﬁcation transformation. Currently two types of measurement transformations are implemented: taking the value of deﬁned model feature(s), or counting occurrences of elements into a value. Classiﬁcation transformations map the values to one of the classes {UNKNOWN, OK, WARNING, CRITICAL}. Fig. 2 shows a very basic example for an indicator: On model level, only a single feature is selected (the number of output ports). The numeric value of this property is taken during the measurement step. The classiﬁcation transformation assigns one equivalence class “green” to that value. This value is deemed to be okay. By combining operations on each step, more complex indicators may be developed. A more sophisticated example illustrating this is given by the question of whether there are independent data paths in the subsystem or not. Independent data-paths are considered bad design. Fig. 3 shows the indicator pipeline for this example. In the example, a data ﬂow model is transformed (“M2M” transformation) into a graph representation. The measurement transformation is used to query information about the graph representation of the input model, here by counting independent paths. For the example presented in Fig. 2, the algorithm counts two independent sub-graphs and returns the value “2”. Afterwards, the classiﬁcation mapping indicates that the model has a ﬂaw based on that value. During the three stages, our framework permits diﬀerent operations, which combine into more or less complex indicators. In the following sections, these operations are laid out.

Fig. 2. Outline of an indicator processing a model

200

S. Kemmann, T. Kuhn, and M. Trapp

Fig. 3. More complex indicator processing a model

4.2

Pattern Searching

As described before, the speciﬁcation of search patterns is an intuitive way of representing expert knowledge. For this reason, INProVE provides the opportunity to deﬁne indicators based on patterns. Pattern searching is a specialized counting, and therefore a measurement operation. It counts the appearance of a speciﬁc sub-pattern in its input model. The input model to pattern searching may either be the design model, or an intermediate model that yielded from a model to model transformation. Pattern searching is realized by graph-matching algorithms that operate on the internal meta model. Search-patterns may be modeled in the same language that was used for creating the input model. Pattern searching is realized through attributed graph grammars (AGG, [12]). They yield two AGG graphs: one describing the design model and one describing the pattern. The result of the pattern search is the amount of occurrences found in the model, which is a value. This value may be further processed in stage V. One example for pattern searching is the identiﬁcation of pass connections, which are connections in data ﬂow models that directly link input ports to output ports without any additional behavior between them. They are therefore considered to be bad design. Locating and counting this type of connection can easily be done with the pattern searching. Fig. 4 illustrates this. Once an occurrence has been found, the matching part of the AGG graph of the input model is transformed into a diﬀerent representation, which is provided by the user as well. Here, this is the input graph with the pass connection removed. This prevents duplicate counting of the same ﬂaw.

Extensible and Automated Model-Evaluations with INProVE

201

Fig. 4. Graph matching example

4.3

Logical Inference

The second requirement for conserving expert knowledge is the logical combination of already existing information. In the value stage, this is done by combining basic metrics that were derived from the model, e.g. during pattern searching with each other to generate more complex metrics using value-to-value (V2V) transformations. Inference is given by reusing value stages from other indicator pipelines. Afterwards, the new value is channeled into a new pipeline backend. One example for such an indicator pipeline is shown in Fig. 5. Quality attributes that are applied to model metrics are often blurry, therefore, logical inference transformations support application of fuzzy logic [14,13]. Internally, each V2V transformation is a pipeline that transforms values from and to the fuzzy domain and performs the logic transformation. One suitable example for a fuzzy quality attribute is the interface-size indicator. The bare

Fig. 5. Indicator pipeline

202

S. Kemmann, T. Kuhn, and M. Trapp

number of inports and outports of a model element often does not reﬂect its real complexity; therefore, we make the interface-size dependent on the amount of independent paths and the amount of subsystems contained in components. We use values of three existing indicators: InferfaceSize, Islands, and SubsystemCount. The ﬁrst step of the created inference pipeline is the fuzziﬁcation through membership functions, which map values to logical classes. The fuzzy character of the membership functions is expressed by the overlapping of multiple membership functions. The value 19, for example, belongs to both classes, “medium” and “high”. The diﬀerence is the degree of membership. 90% of the value belongs to the class “high” and 10% to the class “medium”. The Islands input and the InterfaceSize inputs are fuzziﬁed in a similar manner. Values in fuzzy logic are combined by inference rules that operate on fuzzy variables. Inference rules consist of an if part that describes to which fuzzy values of variables the rule applies, then clauses deﬁne output values of the inference rule. The output of a Fuzzy Logic combination is a fuzzy variable with membership classes, too. Therefore, for the output domain, defuzziﬁcation is applied, which transform the fuzzy variable back into a value. 4.4

Functional Combination

The last and simplest pipeline extension is the usage of a functional combination building block. Again, this pipeline extension uses already existing value stages of other indicators and combines their values. The combination stays in the (numerical) value domain. In contrast to the Inference Indicator extension, we do not need a sub-pipeline. This results in the extended pipeline shown in Fig. 6. With the simple application of a value-to-value transformation, the requirement for entropy enrichment through mathematical combination is fulﬁlled. The information added through value-to-value transformations is the combination function itself. Thus, only one function has to be deﬁned to design a functionally combined indicator that fulﬁlls the need to be a fast and easy-to-use “playground”. An example for functional combination is the calculation of the InterfaceSize, which is based on the combination of two values FanIn and FanOut. Combination of basic operations provides the possibility to design complex indicators by reusing simpler blocks. An example of a complex modular indicator is shown in Fig. 7. In this example, the ﬁrst stage uses the pattern extension. Afterwards, the entropy of the pattern data is enriched by combining the resulting

Fig. 6. Example for functional combination of indicators

Extensible and Automated Model-Evaluations with INProVE

203

Fig. 7. A complex modular indicator

value functionally. This improved pattern value is channeled into a logical combination stage. Afterwards, the usual classiﬁcation stage is applied. This makes it easy possible to deﬁne expressive indicators and reuse already formalized expert knowledge. 4.5

Indicator Development

Indicators represent and formalize company speciﬁc modeling guidelines. They form a repository that contains domain speciﬁc modeling best practices, which otherwise would not have been formalized. Formal modeling best practices can be checked, their impact on model quality may be evaluated by measurements, and adherence to important guidelines can even be enforced, e.g. by preventing committing of models that fail INProVE checks. Construction of indicators is currently performed manually. Specialized front ends exist for deﬁnition of pattern matching and logical inference. A graphical domain speciﬁc language front end that supports intuitive deﬁnition of indicators and live feedback is currently under development, and therefore considered future work.

5

INProVE Implementation and Application

We did implement the INProVE framework as Eclipse RCP application based on the eclipse modeling framework (EMF) and the eclipse modeling. This enabled us to re-use existing technology for graph grammar processing (cf. [12]), model to model transformations, and for the parsing of native models, which are both part of the eclipse modeling framework. Furthermore, numerous SWT widgets (SWT refers to the standard widgets toolkit, a toolkit supporting the construction of graphical user interfaces) are available for visualization of measurement results. While developing INProVE, we created a set of standard indicators. These are the following:

204

S. Kemmann, T. Kuhn, and M. Trapp

– Inputs: This indicator checks whether the number of input ports to a block is within acceptable borders. – Outputs: This indicator checks whether the number of output ports of a block is within acceptable borders. – Islands: This indicator checks for the presence of islands within subsystems, e.g. unconnected and independent functionalities, which should be realized through diﬀerent subsystems instead for reusability reasons. – Pass Connections: This indicator tracks the presence of connections that connect input to output ports without providing meaningful behavior. These connections increase structural complexity of models without oﬀering any beneﬁt. – Block Count: This indicator tracks whether the direct block count within one subsystem is within deﬁned limits. Indirectly contained blocks, e.g. those blocks that belong to nested subsystems are not counted. The block count indicator provides a metric regarding complexity and maintainability. – Level: Tracks the number of nesting levels used in the model and checks whether the nesting depth is within permitted constraints. – Missing connections: Checks if blocks have non-connected values, which could lead to problems during code or HDL generation, or which could yield unexpected behavior. – Bad parameters: Checks whether blocks are initialized with parameter values that are known to be bad. Gain blocks with a gain value of 1 indicate bad usage of this block type for example. – Mixing of types: This indicator checks whether subsystems and blocks are mixed in the same hierarchy level, which aﬀects maintainability. – Non-discrete block usage: This indicator tracks whether blocks that are implement continuous behavior are used in the system. These blocks limit code and HDL generation. Most of these indicators fall into the category of basic indicators. Derived, customer-speciﬁc and complex indicators, which combine, for example input and output complexity with levels and block counts unveil the whole power of INProVE. These indicators are often tailored to the needs of systems under development, and therefore deemed conﬁdential. INProVE is the result of experience made in various assessments targeting data ﬂow-oriented software design models like Matlab, Simulink or ASCET. In these projects, we encountered the problem how to assess large-scale design models with respect to elusive non-functional properties. Due to the size of the targeted models, manual approaches were not applicable and appropriate analysis tools were not available. Therefore, out of necessity, we started to develop INProVE. Until now, the approach has been used for the analysis of large-scale, complex software design models in industry projects. In an industrial case-study from the embedded systems domain, we assessed a software model that consisted of 3000 hierarchical subsystems. The aforementioned standard indicators were modiﬁed, extended and some have been omitted for this evaluation. As diﬀerent as the models and domains were, so was the processing time of the indicators. The assessment of the largest model with

Extensible and Automated Model-Evaluations with INProVE

205

Change model

Evaluate model

Interprete evaluation results Developer

Project manager

Fig. 8. INProVE usage scenarios

the full set of indicators took about two hours. In comparison to the manual effort it would have taken, this is negligible, particularly since all indicators were applied to the complete model, which is usually not necessary. INProVE initially oﬀered a predeﬁned set of basic indicators, which were comparable to standard code metrics like interface size and not project or domain speciﬁc. Although delivering valuable information, these indicators were not suﬃcient for evaluating the targeted elusive non-functional properties such as maintainability, extendibility and reusability. To support these aspects adequately, INProVE had to be tailored to the respective domain and project. Therefore, we deﬁned two usage scenarios for INProVE (see Fig. 8). Developers did use INProVE to evaluate those models that they are working on during development; project managers used INProVE to evaluate the quality of models within running and past projects. During our evaluation, it turned out that a set of more sophisticated measurements including pass connections, cyclic dependencies of subsystems, coupling and cohesion, and islands, i.e., independent paths, is suﬃcient as a basis for the deﬁnition of further indicators. Through indicator combination, domain speciﬁc quality indicators were created that provided meaningful beneﬁts to both software developers and architects. Regarding the eﬀectiveness of INProVE, it was an interesting observation that INProVE also found ﬂaws in models that had been refactored several times before and that were considered to be of a very high quality by experts. INProVE therefore was able to locate ﬂaws that slipped through manual quality assurance techniques. INProVE therefore bridged the gap between customizable yet manual quality assurance techniques, which were already applied, and automated tools, which were not customizable to the necessary level of extend. Thus, INProVE detects weak points that were not found by expensive and time consuming manual assessments (see Fig. 9). Moreover, it turned out that

206

S. Kemmann, T. Kuhn, and M. Trapp

Fig. 9. INProVE runtime example

almost all ﬂaws indicated by INProVE (>90%) were conﬁrmed by manual checks done by the experts. Another point of interest during a model assessment is the evolution of quality over diﬀerent iterations of the model. Especially for managing a project, with respect to the eﬀort spent on diﬀerent development steps, this is valuable information to judge whether another iteration for improving model quality is necessary or at least expedient. To support this, INProVE is able to record changes between several runs, compare values from previous runs to the current project state, and to plot trend indicators regarding changes of quality attributes over time. By executing INProVE automated, e.g. on a model repository within deﬁned periods of time, model quality changes can be tracked and written to ﬁles for further analysis. Feedback from developers regarding the applicability of INProVE was very positive. They extolled the fast applicability of INProVE and the representation of the quality information. The diﬀerent views, with diﬀerent details of information, the guidance on how to ﬁnd weak model parts were perceived as extremely helpful means for understanding and correspondingly improving the model. Furthermore, the tracking of quality helps the developers to learn from previous design ﬂaws and therefore improve not only the targeted model, but also their skills, existing modeling guidelines, and therefore future work.

6

Summary and Outlook

Non-functional properties like maintainability, reusability, and extendibility are of crucial importance for embedded software development. This is especially true since embedded software usually has high variability over diﬀerent versions and rapidly evolves over diﬀerent product versions.

Extensible and Automated Model-Evaluations with INProVE

207

With the growing importance of model-based design of embedded software systems, appropriate means are required for assessing these models with respect to non-functional properties. In order to evaluate/assess a model with respect to these properties, the essential domain- and project-speciﬁc expert knowledge has to be formalized in order to be usable in automatic model analysis techniques. INProVE meets this challenge by providing an environment to conserve the available expert knowledge in indicators and to automatically apply the latter to data ﬂow-oriented design models. The anatomy of indicators itself is designed to be modular and model-based. This enables the fast adaption of INProVE to new contexts, supports fast modiﬁcation of indicators, and the seamless design and integration of new indicators. On this basis, we have built several sophisticated indicator modeling techniques for conserving expert knowledge. The Functional Combination Indicator and the Inference Indicator are both based on the idea of building a new indicator by assembling existing ones. The diﬀerence between both is the kind of conserved knowledge. The FC Indicators combine information by evaluating mathematical equations. The Inference Indicator supports fuzzy logic combinations. Both are born from the observation of how experts handle available knowledge and how they intuitively describe their own notion of quality. The third kind of presented indicators is the Pattern Indicator. This indicator is built upon the idea that searching for patterns is a valuable and natural way of obtaining model quality information. In industrial evaluations, it turned out to be a very good means for capturing “examples” that experts often give as their description of quality. In its application in industry projects, INProVE has already shown signiﬁcant value for model assessments. INProVE ﬁnds almost all ﬂaws in a model that a manual inspection would reveal, but in less time and with less eﬀort. Additionally, problems that were not detected by manual inspections could be revealed using INProVE. Despite this success in practical application, a sound empirical evaluation of INProVE still needs to be done as one of the next steps. So far, INProVE has focused on the assessment of models with respect to model properties. In the future we are going to evaluate to which extent the available means for conserving and automatically applying expert knowledge can be used for assessments with respect to non-functional system properties. Particularly, the application of INProVE as part of safety engineering activities is the subject of ongoing feasibility studies.

References 1. Genero, M., Piattini, M., Calero, C.: A Survey of Metrics for UML Class Diagrams. Journal of Object Technology 4(9), 59–92 (2005) 2. The ISO/IEC. Software Engineering: Software Product Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE. Standard document 25000:2005 (2005) 3. The ISO/IEC. Software engineering Product quality, part 1. Standard document 9126-1 (2001) 4. Kazman, R., Klein, M., Clemens, P.: ATAM: Method for Architecture Evaluation. CMU/SEI Technical Report ESC-TR-2000-004 (2000)

208

S. Kemmann, T. Kuhn, and M. Trapp

5. McCabe, T.J.: A Complexity measure. IEEE Transactions on Software Engineering SE-2, 308–320 (1976) 6. Fowler, M., Beck, K., Brant, J., Opdyke, W., Roberts, D.: Refactoring: Improving the Design of Existing Code. Addison-Wesley, Reading (1999) 7. Marticorena, R., L´ opez, C., Crespo, Y.: Extending a Taxonomy of Bad Code Smells with Metrics. WOOR (2006) 8. The Mathworks. Control Algorithm Modeling Guidelines Using Matlab, Simulink, and Stateﬂow; The MathWorks, http://www.mathworks.com/industries/auto/ maab.html (last time visited: September 2009) 9. The Mathworks. Simulink Model Advisor (part of Simulink), The MathWorks, http://www.mathworks.com/products/simulink (last time visited: 2010) 10. Ricardo Inc., http://www.ricardo.com/engineeringservices/controlelectronics.aspx? page=mint (last time visited: 2010) 11. St¨ urmer, I., D¨ orr, H., Giese, H., Kelter, U., Sch¨ urr, A., Z¨ undorf, A.: Das MATE Projekt - Visuelle Speziﬁkation von MATLAB/Simulink/Stateﬂow Analysen und Transformationen. Dagstuhl Seminar Modellbasierte Entwicklung eingebetteter Systeme (2007) 12. The Attributed Graph Grammar System, http://tfs.cs.tu-berlin.de/agg/ (last time visited: September 2010) 13. Klir, G., Yuan, B.: Fuzzy Sets and Fuzzy Logic (1995) 14. Dr¨ osser, C.: Fuzzy Logic. In: Methodische Einf¨ uhrung in krauses Denken. Rowohlt, Reinbek bei Hamburg (1996)

Requirements and Solutions for Timing Analysis of Automotive Systems Saoussen Anssi, Sébastien Gérard, Arnaud Albinet, and François Terrier Continental Automotive France SAS, PowerTrain E IPP 1 Avenue Paul Ourliac - BP 83649, 31036 France {saoussen.ansi,arnaud.albinet}@continental-corporation.com CEA LIST, Laboratory of model driven engineering for embedded systems, Point Courrier 94, Gif-sur-Yvette, F-91191 France {sebastien.gerard,francois.terrier}@cea.fr

Abstract. Automotive software systems are characterized by increasing complexity, tougher safety requirements and ever-tighter timing constraints. Recent industrial experience has indicated that timing verification and validation can help improving overall system quality and avoid costly design errors. In this paper, we discuss some crucial capabilities that need to be pro-vided by scheduling analysis tools to enable accurate timing analysis for automotive applications. We evaluate the extent to which two open-source analysis tools, MAST and Cheddar, meet these needs. Keywords: Automotive applications, scheduling analysis, scheduling analysis tool requirements, scheduling analysis tool capabilities.

1 Introduction Today, embedded automotive systems often involve hard real-time constraints intended to ensure full system correctness [1]. Power train and chassis applications, for example, include complex (multi-variable) control laws, with different sampling periods, for use in conveying real-time information to distributed devices. One hard real-time constraint controlled in power train applications is ignition timing, which varies with engine position. The latter is defined by a sporadic event characterizing the flywheel zero position. End-to-end response times must also be bounded, since a too long control loop response time may not only degrade performance, but also cause vehicle instability. These constraints have to be met in every possible situation. Automotive software development costs are sharply impacted by wrong design choices made in the early stages of development but often detected after implementtation. Most timing-related failures are detected very late in the development process, during implementation or in the system integration phase. Timing verification is usually addressed by means of measuring and testing rather than through formal and systematic analysis. For this reason, innovative and complex functionalities are not implemented in a cost-efficient way. The benefits of defining an approach that F.A. Kraemer and P. Herrmann (Eds.): SAM 2010, LNCS 6598, pp. 209–220, 2011. © Springer-Verlag Berlin Heidelberg 2011

210

S. Anssi et al.

permits early timing verification for automotive systems are thus obvious. Such an approach would enable early prediction of system timing behavior and allow potential weak points in design to be corrected as early as possible. One verification approach to ensure that a system meets its timing requirements is scheduling analysis. This type of analysis allows designers to detect timing faults and hence avoid costly design mistakes. In this context, a variety of scheduling analysis tools was developed in the last decade. In this paper, we aim to verify to what extent two particular tools for scheduling analysis: MAST (Modeling and Analysis Suite for Real-Time Applications) [2], and Cheddar [3] allow performing accurate timing analysis for automotive systems. The paper is organized as follows: In Section 2, related work is presented as a general overview about schedulability tests and scheduling analysis tools developed in the context of real time verification. Section 3 is dedicated to the characterization of various aspects of automotive applications and inventorying their scheduling needs. This inventory serves for determining the requirements that scheduling analysis tools should meet. Section 4 gives a brief presentation of the two studied tools. Section 5 highlights the capabilities and limitations of the analysis tools with regard to the determined requirements. Section 6 tests the use of these tools on a real-life automotive use case. The conclusion summarizes the study and examines perspectives for use of MAST and Cheddar tools in the automotive domain.

2 Related Work: Schedulability Tests and Scheduling Analysis Tools The first exact schedulability test for the preemptive monoprocessor scheduling of a set of periodic tasks, each with its deadline equal to its period, was introduced by Lehoczky et al. [4]. The test determines whether a set of tasks is schedulable using the rate monotonic algorithm of Liu and Layland [5]. The response time of each task is calculated, and checked against its deadline. Later, other tests were developed relaxing a number of assumptions: Audsley et al. [6] developed a feasibility test for sets of tasks in which deadlines can be less than periods, and which are scheduled using the deadline monotonic algorithm [7]. Lehoczky [8] provided a feasibility test for periodic tasks with arbitrary deadlines. For distributed systems a number of tests have also been developed, e.g. [9], [10] and [11]. In [9] authors extended existing tests to special heterogeneous architectures: fixed priority-scheduled CPU connected via a TDMA-scheduled bus. However, the analysis proposed in [9] is not an exact analysis, because it makes the assumption that tasks are independent. To take into account dependencies between tasks, Tindell proposed in [10] a test for fixed priorities in which offsets among release times of dependent tasks can be taken into account. The test has been later extended to distributed systems by Palencia and González [11] greatly reducing the pessimism of the approach presented in [9]. The development of scheduling analysis tools lies at the very core of the schedulability analysis issue. While the number of such tools is constantly increasing, they also vary widely in terms of analysis capabilities and supported features. MAST [2] and Cheddar [3], two open source tools, are based on some of the above-mentioned

Requirements and Solutions for Timing Analysis of Automotive Systems

211

classical feasibility tests allowing schedulability analysis of fixed-priority and EDFbased monoprocessor and distributed systems. Rapid-RMA [12] and SymTA/S [13] are commercial tools also performing scheduling analysis for monoprocessor and distributed systems. Rapid-RMA is based on rate monotonic and deadline monotonic algorithms assuming tasks to be independent. SymTA/S enhances classical schedulability tests to allow analysis for automotive systems. For example, this tool extends the technique developed by Tindell in [10] to take into account OSEK cooperative tasks (a cooperative task can be preempted by a higher priority cooperative task only in predefined points). Unfortunately, this tool is not freely available. As mentioned previously, in this paper, we aim to verify to which extent MAST and Cheddar allow performing accurate scheduling analysis for automotive systems. These two tools were chosen based on the following facts: 1) Both MAST and Cheddar are open source. This aspect is important for us: it indicates that there is potential for enriching them to support more automotive oriented features. 2) Both tools rely on open formalisms that ensure good interoperability with other tools and platforms. For example, Cheddar is able to analyze systems described with AADL [14] and can be run as a TOPCASED plug-in. MAST itself is able to analyze systems described with MARTE [15] models and can be connected to UML graphical editors like Papyrus [16]. Our paper evaluates both of the proposed tools according to the following two criteria: 1) system-description: this refers to the capability of a tool to support the architecture description of an automotive application. 2) fitness-for-purpose: this measures the extent to which results provided by the analysis tool can improve the decision-making capability of a system designer. These two Criteria raise a crucial question: what are the specific requirements for scheduling analysis in the automotive domain? This paper provides some answers, while also evaluating the selected analysis tools against these specific requirements.

3 Scheduling Needs for Automotive Applications and Scheduling Analysis Tools Requirements This section characterizes the architecture of automotive applications. Such characterization suffices for the purpose of the present paper, which is to identify the timing analysis needs of automotive systems and hence the requirements that should be met by analysis tools. It serves, finally, to provide an informal, comparative review of capabilities provided by the selected tools. For a better understandability, we will assign an identifier to each requirement that we denote REQx where x is the requirement number. Today's automotive systems have evolved constantly and now offer ever more challenging features that can be summed up as follows: Limited hardware resources: Today, CPU load, has become day-to-day issue and is the very basis for the design of automotive systems. Such feature is sometimes in direct opposition to other features: reducing CPU load, for example, may require more RAM and ROM.

212

S. Anssi et al.

For these reasons, scheduling analysis is required to determine, or at least estimate, the processor performance needed for a given design. Hence, Analysis tools should have techniques to determine the processor utilization [REQ1]. Timing Constraints: In addition to limited hardware resources, automotive applications must deal with many kinds of timing constraints. These may concern task or function deadlines or maximum jitters on task activation instants. Automotive tasks may have hard deadlines (e.g. for safety functions) or soft deadlines (for body comfort functions). In addition, the end-to-end delay after data is read by a sensor and the output generated from it and passed to an actuator (known as “data age”) is crucial to control model stability. Scheduling analysis is hence needed to verify if those constraints are met or not. To enable this verification, scheduling analysis tools have to meet certain requirements that we summarize as follows.When describing the system under analysis: • Analysis tools should allow specifying task or function deadlines [REQ2] • Analysis tools should allow specifying jitters related to the function or task activation instants [REQ3] • Analysis tools should allow specifying end-to-end timing constraints [REQ4] • When analysing the system • Analysis tools should have techniques to verify if a deadline is respected [REQ5] • Analysis tools should have techniques to verify if end-to-end constraints are respected [REQ6] Triggering paradigms: Automotive applications often involve event-triggered and Time-triggered tasks. Event-triggered means that tasks are executed or messages are transmitted by the occurrence of significant events. Time-triggered means that tasks are executed or messages transmitted at predetermined points in time. In automotive, the arrival pattern of an event may be periodic, sporadic or singular (arrives only once). Periodic tasks may involve timing recurrence (e.g. 10ms time base), angle recurrence (e.g. each 50 degree crank based on the crankshaft position) or external activation (e .g. can message). By angle recurrence, we mean the activation of some tasks that depend on the crankshaft and camshaft position. (The camshaft is the element of the engine that allows the opening and the closure of intake and exhaust valves. The crankshaft is the part of the engine that translates reciprocating linear piston motion into rotation). For a good analysis, it is thus necessary that analysis tools account for this diversity in triggering of automotive systems. We formalize this capability by the following requirements: • Analysis tools should allow specifying periodic, sporadic and singular events/tasks [REQ7] • For periodic events/tasks, analysis tools should allow specifying angular recurrences [REQ8] Distributed architecture: In conventional automotive system design, externally supplied software is integrated by the car manufacturer into ECUs (Electronic Control Units). Its functionality is then distributed over many ECUs into a network that may even use multiple protocols. Most used protocols are CAN, LIN and FlexRay [17].

Requirements and Solutions for Timing Analysis of Automotive Systems

213

For such distributed functions, it is important to guarantee end-to-end response times. In addition, in such complex architectures, optimization of network resource consumption and message scheduling requires knowledge of the impact of network properties such as network overheads and driver overheads, and of different communication protocols. Consequently, scheduling analysis tools have to satisfy the following requirements: • Analysis tools should allow easy description of distributed systems with multiple ECUs and communication buses [REQ9] • Analysis tools should have techniques to analyze multiprocessor systems [REQ10] • Analysis tools should have techniques for CAN, LIN and FlexRay [REQ11] • Analysis tools should allow taking into account processors overheads (basically context switch overhead) and network overhead (network driver overheads) [REQ12] Task concurrency and dependency: In automotive systems, tasks may be dependent. This dependency results basically from task chaining which means that a task is activated by the termination of its predecessor. Concerning the concurrency issue, in automotive design, although tasks are concurrent, different tasks may have the same priority level. As automotive applications are based on OSEK, these tasks are scheduled using the FIFO algorithm (First In First out) as a second scheduling protocol. Moreover, automotive tasks are of three kinds: preemptive tasks, cooperative tasks and interrupts. Cooperative tasks may be interrupted by higher priority cooperative tasks only in predefined points called schedule points. The non-preemptible sections of a cooperative task are used to ensure data consistency in case of shared data. To enable an accurate scheduling analysis, analysis tools have to support the description and analysis of such a task model and hence: • Analysis tools should allow describing task dependency resulting from task chaining [REQ13] • Analysis tools should allow using FIFO as second scheduling algorithm for tasks having the same priority level [REQ14] • Analysis tools should allow specifying preemptive, cooperative tasks and interrupts [REQ15]

4 Analysis Tools Presentation This section gives a brief presentation of the two studied analysis tools, MAST and Cheddar. MAST [2] is an open source tool developed by the University of Cantabria in Spain. MAST is still under development and is intended to allow modeling real time applications and performing scheduling analysis for them. The tool offers a suite of scheduling analysis tests, ranging from classic RMA for fixed priority monoprocessor systems to more sophisticated analyses for EDF schedulers and distributed systems. In MAST, each real time situation is described through a set of concurrent transactions. A transaction represents the execution of a set of activities triggered by an external event. An activity is an instance of an operation. The output of each

214

S. Anssi et al.

activity is an internal event that may in turn activate other activities. Events may have timing requirements associated with them. Activities follow a predecessor/successor relationship with the possibility for an activity to have multiple successors or multiple predecessors. Each activity is bound to a single schedulable resource (task) and a schedulable resource refers to one processing resource. This way the concept of activity encapsulates the allocation of the operation on a single schedulable resource and the allocation of the schedulable resource on a single processing resource. Cheddar [3] is also open source and is developed and maintained by the University of Brest in France. This tool is designed for checking task temporal constraints of a real time application. Cheddar is based on an analysis framework that includes most of classical real time schedulability tests such as rate monotonic and EDF. In Cheddar, an application is defined by a set of processors, buffers, shared resources, messages and tasks. In the most simple task model, each task periodically performs a treatment. This “periodic” task is defined by three parameters: its deadline, its period and its capacity that represents a bound on the execution time of the job performed by this task.

5 Analysis Tools Capabilities In this section, we consider two scheduling analysis tools: MAST and Cheddar. Table 1 summarizes the coverage provided by these tools with regard to the requirements described above. Full explanations are given in subsequent paragraphs. REQ1: MAST allows the designer evaluating his processor or network performance by calculating either its global utilization or a more limited scenario such as utilization by context and interrupt switch activities. The tool likewise enables him to see to what extent operations executed on the processing resource are schedulable. This entails calculation of processor or network slack, i.e. the percentage increase in execution times that is compatible with keeping the system schedulable. Cheddar allows performing certain feasibility tests based on calculation of the processor utilization factor [5]. Depending on the resulting factor, the tool tells the user whether a task set will be schedulable or not. Cheddar does not calculate processor or network slack. REQ2: MAST defines the concept of operation that represents a piece of code or the sending of a message. The tool allows specifying timing constraints on operations through the concept of timing requirement. The latter can be specified on the output event of an activity (represents the execution of an operation). A timing requirement may be a deadline or a maximum jitter imposed on the generation instant of the output event of an activity. MAST supports both hard and soft deadlines. Cheddar supports this feature differently by allowing specification of deadlines on tasks themselves. REQ3: MAST defines the concept of external event that serves to trigger the execution of a flow of activities (transaction). The tool allows specifying a maximum jitter on the arrival time of an external event but this is only possible for periodic events. Cheddar supports this feature by allowing specifying a maximum lateness on task wake up time through the concept jitter.

Requirements and Solutions for Timing Analysis of Automotive Systems

215

Table 1. Analysis capabilities of MAST and Cheddar

Automotive features and tool requirements Tool Requirements Automotive Features REQ1 Limited hardware resources

MAST

Cheddar

Yes

Yes

Yes Yes

REQ6

Yes Yes(only for periodic pattern) Yes Yes Yes

REQ7

Yes

REQ8

No

No(singular events are not supported) No

REQ9 REQ10 REQ11 REQ12

Yes Yes No Yes

REQ13 REQ14 REQ15

No No No (no cooperative tasks)

REQ2 REQ3

Various timing constraints Various triggering patterns Distributed architecture

Task concurrency and dependency

The requirement is satisfied by the tool

REQ4 REQ5

No Yes Yes

Yes Yes No No (no network overheads) Yes Yes No (no cooperative tasks)

REQ4: MAST meets this requirement by allowing the specification of a deadline on the generation instant of the output event of an execution flow of activities (transaction) with reference to the external triggering event. Contrarily to MAST, specifying end-to-end constraints is not supported in Cheddar. REQ5: MAST allows verifying deadlines imposed on output events by calculating and comparing their response times with the deadlines imposed on them. If the response time is less than the deadline, this means that the deadline is respected. The tool allows calculating worst, best or average response times. Through feasibility tests, Cheddar calculates response time bounds for each task to predict whether it will meet its deadline. When computing a scheduling with Cheddar, response times are calculated according to this scheduling and then compared against deadlines. REQ6: MAST allows calculating the response time of the output event of a transaction and compares this with end-to-end constraints imposed on the system. Cheddar allows calculating end-to-end response times based on the holistic approach defined by Tindell for distributed systems in [9]. These end-to-end response times include message transmission delay and buffer memorization delay.

216

S. Anssi et al.

REQ7 & REQ8: Triggering patterns are captured in MAST through external events that activate transaction execution. MAST external events may be periodic, singular, sporadic, unbounded or bursty. In Cheddar, there is no distinction between a task and its triggering. Cheddar does not, in fact, consider triggering events but rather focus on tasks themselves. In Cheddar tasks may be periodic, aperiodic, sporadic, etc [18]. This approach is fairly similar to the definition of scheduling theory and is thus easier to understand than the MAST approach. MAST itself, however, is closer to the description of concrete real time systems. Cheddar also makes it possible for the designer to specify new activation patterns (User-defined activation pattern) without modifying the implementation of the tool [18]. This same facility is provided by MAST, but only after modifying its implementation (As it is an open-source tool) The duality of time bases in automotive applications (timing & angular) is supported neither by MAST nor by Cheddar. Both of them use the notion of physical time as measured by a unique time base, meaning that an angular time base cannot be described. REQ9 & REQ10: Both MAST and Cheddar allow describing and analyzing distributed systems. In fact, both of them implement analysis techniques for multiprocessor systems. MAST enables description of the networks involved in a system being analyzed through the concept of Packet Based Network. It represents a network that uses some kind of real time protocol based on non-preemptible packets for sending messages [19]. MAST supports the following transmission kinds: Simplex, Half duplex and Full duplex (see [19] for more details about these transmission kinds). Cheddar is designed to perform scheduling simulation of message-sharing applications distributed on several processors. It allows specifying networks with three kinds of communication protocols (bounded delay, jitter delay and parametric delay) [3]. REQ11: Although both MAST and Cheddar allow specifying and analyzing distributed systems with communication buses, neither MAST nor Cheddar have analysis techniques dedicated for CAN, LIN or FlexRay. Both of them use a sort of generic communication bus description. REQ12: MAST has means for independent description of overheads for both processor and network. In fact, it allows specifying either worst, best or average context switch overhead when describing system processors. For networks, MAST allows specifying packet overheads that represent the overheads associated with sending each packet because of the protocol messages or headers that need to be sent before or after each packet. Cheddar, on the other hand, allows specifying the context switch overhead value associated to the activation of each task, but no network overheads may be described in this tool. REQ13: Cheddar allows specifying task chaining. This feature is not supported by MAST. REQ14: Both MAST and Cheddar allow specifying tasks with the same priority level. However, when analyzing the system, Only Cheddar allows using the FIFO algorithm for these tasks. This feature is not supported by MAST.

Requirements and Solutions for Timing Analysis of Automotive Systems

217

REQ15: When describing the scheduling parameters for fixed priority tasks (tasks are called Scheduling Servers in MAST), MAST allows specifying three types of fixed priority policies: “preemtible”, “non-preemptible” and “interrupt” priority policy. In Cheddar, when describing the system processor, it is possible to specify either the scheduler is preemptive or not. Cooperative task description is supported neither in MAST nor in Cheddar.

6 Scheduling Analysis for a Concrete Automotive Application with MAST and Cheddar The aim of this section is to evaluate concrete use of MAST and Cheddar on an automotive application. The questions to be answered are: 1) To what extent can the tool support the description of the architecture used for such application. 2) How useful are analysis results in improving designer decision-making capability (fitnessfor-purpose). The use case studied in this section is a "knock" control system, which is designed to prevent engine knock during the combustion phase by applying a correction to the ignition angle. 6.1 Use Case Presentation The case presented here is typical of automotive system architecture with timing constraints and different triggering paradigms along with different concurrent functions. The knock control system has three basic functions, whose characteristics are shown in Table 2 (to facilitate understanding, its architecture has been simplified): Table 2. Timing properties fort he knock functions Functions Knk_kw

WCET (µs)1 200

Knk_seg

250

Knk_100ms

85

Triggering event Sporadic: Knock window event (Event_KW_END) Sporadic: Segment event (Event_SEG) Periodic: 100ms (Event_100ms)

Deadli ne (µs) 500

Allocated to TASK_knk_kw

Task priority 6

600

TASK_E1_SEG

5

600

TASK_T1_100ms

2

TASK_E1_SEG and TASK_T1_100MS are predefined tasks that allocate functions other than knock. All these tasks are executed on the same processor (here a fixed priority processor) and use the DMA channel concurrently as a shared resource.Event_SEG is an angle-based event. 1

The WCETs used in this example were measured using internal methods and tools that for confidentiality reasons cannot be presented here.

218

S. Anssi et al.

6.2 MAST and Cheddar System Model for Knock In the MAST model, each elementary function (e.g. knk_seg) was modeled by an operation for which we specified the worst-case execution time and the shared resource. To model tasks, we defined three scheduling servers for which we specified the priorities. (e.g. scheduling server TASK_E1_SEG) A transaction must be defined for each execution case. The event handlers of each transaction allocate operations triggered by input events to scheduling servers. In our case, three transactions were defined to model execution of the three knock functions. For example, one transaction is triggered by the external angular segment event, Event_SEG, and has as an event handler the operation knk_seg which is allocated to the scheduling server TASK_E1_SEG. Unfortunately, Cheddar does not model function allocation to tasks, but instead deals only with tasks. In our case, as each task allocates one function, it was possible to model only tasks and the function deadlines were assigned to them. For example, we modeled a task called TASK_E1_SEG, which has a priority of 5 and a deadline of 600 µs. Again, neither MAST nor Cheddar can represent an angular base scale. The only way to represent the angular segment event was thus to type it as “sporadic” and to specify its minimum inter-arrival time. 6.3 Analysis Results We saw above that Cheddar performs feasibility tests (without computing a scheduling) by calculating bounds for the response time of tasks based on the processor utilization factor. In our case, such feasibility tests could not be performed; since the tool only does so for periodic tasks, (our system also contains sporadic tasks). It was, however, possible to run a scheduling simulation and give results based on this simulation. Table 3 shows the worst response times obtained by the two tools. These results show that the system is schedulable (response times are lower than deadlines). In addition to quantitative scheduling results, Cheddar provides a graphical display of task execution that is not available with MAST. This allows the designer monitoring system execution and identifying any missed deadlines, blocking times, etc. Table 3. MAST and Cheddar response and blocking time results

Knock functions

MAST results (µs) Worst Best response response

Knk_seg Knk_kw Knk_100ms

547 456 550

230 200 160

Worst blocking time 85 250 0

Worst response 535 200 520

Cheddar results (µs) Best Worst response blocking time 535 0 200 0 285 0

MAST calculated a schedulability slack of 1.56 % for the whole system. This means that all execution times of all system operations could be increased by 1.56% without jeopardizing system schedulability. The slack value tells the designer how much freedom he still has and how much he can modify the existing architecture.

Requirements and Solutions for Timing Analysis of Automotive Systems

219

With MAST, we could also calculate slack for one operation which was knk_kw (slack: 20.31%). Such results are useful when new functions are planned for a system and their execution time bounds need to be determined to keep the system schedulable. As Table 3 shows, while the tools provided close results, MAST results were more precise than those of Cheddar. This may be attributed to the fact that, in MAST, the exact architecture of the knock system (allocation of functions to tasks) was taken into account. According to Cheddar, task blocking times were null, which was not consistent with the display of system execution on the graphical interface. MAST results for this property were more relevant, thus confirming that Cheddar is not yet as "mature" as MAST. Concerning the processor load, MAST shows 97.66% as processor utilization. Unfortunately, we could not compare this value with Cheddar result as Cheddar allows calculating utilization only for periodic task set.

7 Conclusion In this paper, we discussed crucial capabilities that need to be available in tools for timing analysis in automotive applications. We evaluated the extent to which two open source tools, MAST and Cheddar, satisfy such requirements. Our aim was to raise questions and encourage discussion, rather than to argue that any particular analysis tool is the perfect answer. We think that a good verification process could benefit from a coherent combination of many analysis tools. For example, since MAST seems more mature and precise than Cheddar, it could be used for detailed system analysis at the implementation phase. Cheddar could then be employed for abstract timing analysis in early design phases, where assumptions must be made for allocation of functions to tasks, etc. The MAST model seems closer in form to existing real-time automotive systems. In contrast, Cheddar more closely reflects scheduling theory.Both tools are attractive for their open-source aspect giving the ability to define new automotive schedulers or activation patterns. MAST and Cheddar are both still under development, and can thus be further adapted to meet the challenges of automotive system design.

References 1. Navet, N., Simonot-Lion, F. (eds.): The Automotive Embedded Systems Handbook. Industrial Information Technology series. CRC Press / Taylor and Francis (December 2008) ISBN 978-0849380266 2. MAST website, http://mast.unican.es 3. Cheddar website, http://beru.univ-brest.fr 4. Lehoczky, J., Sha, L., Ding, Y.: The Rate Monotonic Scheduling Algorithm: Exact Characterisation and Average Case Behaviour. In: Proceedings of the Real-Time Systems Symposium (1989) 5. Liu, C.L., Layland, J.W.: Scheduling Algorithms for Multiprogramming in a Hard Real Time Environment. Journal of the Association for Computing Machinery (January 1973)

220

S. Anssi et al.

6. Audsley, N., Burns, A., Richardson, M., Tindell, K., Wellings, A.: Applying New Scheduling Theory to Static Priority Preemptive Scheduling. Software Engineering Journal 8(5), 285–292 (1993) 7. Leung, J., Whitehead, J.: On the Complexity of Fixed-priority Scheduling of Periodic, Real-time Tasks. Performance Evaluation 2, 237–250 (1982) 8. Lehoczky, J.: Fixed Priority Scheduling of Periodic Task Sets with Arbitrary Deadlines. In: Proceedings of 11th IEEE Real-Time Systems Symposium, December 5-7, pp. 201– 209 (1990) 9. Tindell, K., Clark, J.: Holistic Schedulability Analysis for Distributed Real-time Systems. Microprocessing and Microprogramming - Euromicro Journal (Special Issue on Parallel Embedded Real-Time Systems) 40, 117–134 (1994) 10. Tindell, K.: Adding Time-Offsets to Schedulability Analysis. Technical Report YCS 221, Dept. of Computer Science, University of York, England (January 1994) 11. Palencia Gutiérrez, J.C., González Harbour, M.: Schedulability Analysis for Tasks with Static and Dynamic Offsets. In: Proceedings of the 18th IEEE Real-Time Systems Symposium, Madrid, Spain (December 1998) 12. Rapid-RMA website, http://tripac.com/html/prod-fact-rrm.html 13. SymTA/S website, http://www.symtavision.com/symtas.html 14. AADL website, http://www.aadl.info 15. MARTE website, http://www.omgmarte.org 16. Papyrus website, http://www.papyrusuml.org 17. Traub, M., Lauer, V., Becker, J., Jersak, M., Richter, K., Kuhl, M.: Using timing analysis for evaluating communication behaviour network topologies in an early design phase of automotive electric/electronic architectures. In: SAE World Congress, Detriot, MI, USA (April 2009) 18. Singhoff, F., Legrand, J., Nana, L., Marcé, L.: Cheddar: a Flexible Real Time Scheduling Framework. ACM SIGAda Ada Letters 24(4), 1–8 (2004) ISSN:1094-3641 19. Drake, J.M., Harbour, M.G., Gutiérrez, J.J., Martinez, P.L., Medina, J.L., Palencia, J.C.: Modelling and Analysis Suite for Real Time Applications (MAST 1.3.7), Description of the MAST Model. Report, Universidad De Cantabria, SPAIN (2008)

Analysing the Cognitive Eﬀectiveness of the UCM Visual Notation Nicolas Genon1 , Daniel Amyot2 , and Patrick Heymans1 1

PReCISE, University of Namur, Belgium {nge,phe}@info.fundp.ac.be 2 University of Ottawa, Canada [email protected]

Abstract. The Use Case Map (UCM) notation is a scenario modelling language part of ITU-T’s User Requirements Notation and intended for the elicitation, analysis, speciﬁcation, and validation of requirements. Like many visual modelling languages, the concrete graphical syntax of the UCM notation has not been designed taking cognitive eﬀectiveness formally into consideration. This paper conducts a systematic analysis of the UCM notation through an evaluation against a set of evidencebased principles for visual notation design. Several common weaknesses are identiﬁed and some improvements suggested. A broader goal of the paper is to raise the awareness of the modelling, language design, and standardization communities about the need for such evaluations and the maturity of the techniques to perform them. Keywords: Use Case Map, language design and evaluation, visual notation, concrete syntax, cognitive eﬀectiveness, Physics of Notations.

1

Introduction

Visual notations play a critical role in requirements, software, and systems engineering. Yet, when designing notations, most of the eﬀort is commonly spent on deﬁning abstract syntaxes and semantics, whereas the design of eﬀective graphical syntaxes tends to be made in an ad hoc and subjective way, without proper guidance from theoretical frameworks based on empirical evidence. This lack of attention and rigour negatively impacts the cognitive eﬀectiveness of notations, i.e., the speed, accuracy, and ease with which information can be understood via notations. Indeed, research in diagrammatic reasoning shows that the form of representations has an equal, if not greater, inﬂuence on cognitive eﬀectiveness as their content [18]. We believe that cognitive eﬀectiveness is not an intrinsic property of diagrams. It needs to be assessed for particular notations, and ideally be designed into them. Several language evaluation frameworks have been proposed to support such tasks. Moody’s Physics of Notations theory [25] is particularly interesting as it provides evidence-based principles focusing on visual notations. In this paper, we use the Physics of Notations theory to conduct a systematic analysis of the Use Case Map (UCM) notation. UCM is part of ITU-T’s User F.A. Kraemer and P. Herrmann (Eds.): SAM 2010, LNCS 6598, pp. 221–240, 2011. c Springer-Verlag Berlin Heidelberg 2011

222

N. Genon, D. Amyot, and P. Heymans

Fig. 1. Overview of the UCM concrete graphical syntax [13]

Requirements Notation (URN) [13]. URN models are used for the elicitation, analysis, speciﬁcation and validation of reactive systems requirements and of business processes. URN combines two complementary types of views: one for goals provided by the Goal-oriented Requirement Language (GRL) and one for scenarios provided by UCM. GRL is not addressed in this paper because it substantially overlaps with i* [39], which has already been investigated in [27]. The UCM notation was ﬁrst proposed as a high-level design notation by Buhr and others in the mid-1990’s [4]. The URN standard1 is deﬁned with a metamodelbased abstract syntax (where some concepts are common to both GRL and UCM) together with a concrete graphical syntax, summarized in Fig. 1. After a short introduction to language evaluation frameworks and the Physics of Notations theory, we discuss several weaknesses of the UCM notation in terms of its principles. We suspect many of these weaknesses to be common in workﬂow/scenario modelling languages. Several suggestions for improvement are also highlighted. With these contributions, we hope to inﬂuence future versions of the URN standard, especially in terms of addressing current symbol deﬁcits in the UCM language as well as future extensions. A broader goal of the paper is 1

The URN standard is available at http://jucmnav.softwareengineering.ca/ucm/ bin/view/UCM/DraftZ151Metamodel.

Analysing the Cognitive Eﬀectiveness of the UCM Visual Notation

223

to show novel perspectives and stimulate discussion in the language design and standardization communities about visual representations, which may eventually lead to a standard for designing and evaluating graphical modelling languages.

2

Language Evaluation Frameworks

Many frameworks have been proposed to evaluate modelling languages. In this section, we present popular frameworks that address the concrete syntax of languages, with a particular emphasis on the Physics of Notations theory. 2.1

Popular Frameworks

The Cognitive Dimensions of Notations (CDs) framework deﬁnes a set of 13 dimensions that provide a vocabulary for describing the structure of cognitive artefacts [10]. This has become the predominant paradigm for analysing visual languages in the IT ﬁeld. However, it has a number of important theoretical and practical limitations for this purpose [10,26]: 1) as it is not speciﬁcally focused on visual notations, eﬀectiveness guidelines are absent, 2) the dimensions, their empirical foundations, and their metrics are vaguely deﬁned, often leading to misinterpretation, 3) it focuses on very high-level analyses and speciﬁc predictions are precluded, which means that it is unfalsiﬁable and therefore unscientiﬁc [31]. For all of these reasons, we believe the CDs framework does not provide a proper scientiﬁc basis for evaluating and designing visual notations. Also popular is the semiotic quality (SEQUAL) framework [15]. It proposes a list of general qualities for models and modelling languages, that it organises along the semiotic ladder (i.e., the scale ‘physical’, ‘empirical’, ‘syntactic’, ‘semantic’, ‘pragmatic’ and ‘social’). SEQUAL also distinguishes quality goals from the means to achieve them, and sees modelling activities as socially situated (constructivistic worldview ). Essentially, SEQUAL oﬀers a comprehensive ontology of model and modelling language quality concepts. It provides a precise vocabulary and checklist when engaging in a comprehensive analysis. The part of the SEQUAL framework closely related to the notation quality is termed ‘comprehensibility appropriateness’ [16]. Although SEQUAL is very diﬀerent in intent and content from CDs, they share most limitations for our purpose, except that SEQUAL oﬀers measurable criteria and eﬀectiveness guidelines. The Guidelines of Modeling (GoM) [32] is a language quality framework whose main objective is to increase the quality of a model through the execution of syntactic rules. The framework is based on six principles: ‘correctness’, ‘relevance’, ‘economic eﬃciency’, ‘clarity’, ‘comparability’, and ‘systematic design’. Even if GoM claims to target designers and model users, the principles are deﬁned without references to human capabilities and look much like rules of thumb. Moreover, the framework has to be tailored to any language where it is applied. Visual notation qualities can be evaluated at two levels: while the Physics of Notations theory (next section) targets the language level (the deﬁnition of the symbol types), the Seven Process Modelling Guidelines (7PMG) [23] focus on the

224

N. Genon, D. Amyot, and P. Heymans

instance level, i.e., the symbol occurrences in the model. 7PMG guide modellers when they design diagrams: for instance, they deal with diagram layout, replication of symbol instances to improve readability (by avoiding line crossings), decomposition of large diagrams, node labelling style and other recommendations. This research takes place at a level distinct from the Physics of Notations, and hence these two frameworks should be regarded as complementary. 2.2

The Physics of Notations

The Physics of Notations theory [25] provides a framework that is speciﬁcally developed for visual notations. It deﬁnes a set of 9 evidence-based principles to evaluate and improve the visual notation of modelling languages. The principles are synthesised from knowledge and empirical evidence stemming from various scientiﬁc disciplines such as cognitive and perceptual psychology, cartography, graphic design, human computer interface, linguistics, and communication. Relying on knowledge and evidence that have been used for a long time with success in these other disciplines is one of the key characteristics of this theory. Another one is its falsiﬁability [31], i.e., the principles can be used to generate predictions, which are empirically testable. In a nutshell, the 9 principles are: 1. Cognitive Fit : use diﬀerent visual dialects when required. 2. Semiotic Clarity: there should be a one-to-one correspondence between semantic constructs and graphical symbols. 3. Perceptual Discriminability: symbols should be clearly distinguishable. 4. Visual Expressiveness: use the full range and capacities of visual variables. 5. Complexity Management : include mechanisms for handling complexity. 6. Cognitive Integration: include explicit mechanisms to support the integration of information from diﬀerent diagrams. 7. Semantic Transparency: use symbols whose appearance is evocative. 8. Graphic Economy: keep the number of diﬀerent graphical symbols cognitively manageable. 9. Dual Coding: enrich diagrams with textual descriptions. Evaluations of notations against these principles often rely on values of visual variables, i.e., the elementary characteristics forming the visual alphabet of diagrammatic notations. The seminal work of Bertin [1] identiﬁed eight visual variables divided into two categories: planar and retinal variables (see Fig. 2). Essentially, symbols are obtained by combining visual variable values. Henceforth, we take the convention of underlining their names. Up to now, the Physics of Notations theory has been used successfully to evaluate the visual notations of UML [28], i* [27], and BPMN 2.0 [7].

3

Analysis of Use Case Maps

In this work, we report the main ﬁndings of the systematic symbol-by-symbol analysis we performed on the UCM notation [13]. The complete analysis can be found in [6]. For each principle, we provide a deﬁnition, summarise the results obtained and give recommendations for improvement.

Analysing the Cognitive Eﬀectiveness of the UCM Visual Notation

225

Fig. 2. The eight visual variables from Bertin [1]

3.1

Cognitive Fit

The Cognitive Fit theory [33], widely accepted in the information systems ﬁeld, states that there must be a 3-way ﬁt between the audience, the task characteristics, and the medium on which the information is represented. However, many current modelling languages use a single visual representation for all purposes, even if this undermines the cognitive eﬀectiveness of the notation. Cognitive Fit theory suggests that instead of trying to design a “one size ﬁts all” language, diﬀerent representations should be used for diﬀerent tasks and/or audiences. We evaluate UCM against these two aspects in the following. Expert-Novice Diﬀerences. If the audience proﬁle focuses on non-technical stakeholders (e.g., domain experts) and if the purpose of the diagram is to reach a shared high-level understanding of a process, then it is especially important to have a language with few symbols (Graphic Economy) that are mnemonic (Perceptual Transparency) and quickly distinguishable (Perceptual Discriminability), and where diagrams are kept simple through Complexity Management and Cognitive Integration. On the contrary, if a language is to support in-depth technical discussions between notation experts, or if it is to be fed into some transformation or execution engine, it is more important to have a comprehensive set of symbols with clear semantics (Semiotic Clarity), to be able to represent all required extra details through text (Dual Coding) and to be able to structure large models through Complexity Management and Cognitive Integration. According to ITU-T experts who lead the evolution of URN, the UCM audience proﬁle is composed of business analysts, requirements engineers and developers who are deﬁnitively notation experts. Therefore, analysis results and notation improvements should be proposed with regard to this audience. Diﬀerences in Representational Media. Rendering diagrams in a computerbased editing tool or drawing them on a whiteboard call for distinct skills from modellers. These are two usual practices with modelling languages and they call for diﬀerent visual dialects. For instance, elaborate icons and complex shapes should be avoided when sketching, but are easily supported by tools. For expert notation users, the UCM notation appears rather appropriate. This audience makes a dominating utilisation of computer-based tools (but sketching

226

N. Genon, D. Amyot, and P. Heymans

is not excluded) and hence, icons must not be seen as notation issues. Moreover, the UCM notation is monochromatic, which reveals adequate for printing (no need of colour printer) and sketching (no need for colours pens). 3.2

Semiotic Clarity

Semiotic Clarity analysis starts with inventorying all semantic constructs and all visual symbols of the language. According to the Physics of Notations, the list of semantic constructs can be approximated by the list of concrete metaclasses in the metamodel. However, this is not 100% reliable due to variations in metamodelling styles. For instance, in UCM, the semantic concept of Responsibility is modelled with two metaclasses RespRef and Responsibility. Another example: UCM counts two types of paths (normal and timeout) that are respectively modelled as (i) one metaclass NodeConnection and (ii) the same metaclass plus a metarelationship to the Timer metaclass. To overcome this issue, we set up six metaclasses categories (Table 1). Table 1. Number of semantic constructs (SC) metaclasses by categories Category Abstract

Description Abstract metaclasses are usually not mapped to any symbol. Their specialisation metaclasses have a visual representation. Structural Metaclasses that exist for structuring the metamodel. They do not represent semantic constructs. Enumeration Metaclasses with «enumeration» stereotype. They, or their values, can be semantic constructs, depending on the context. Graphical Metaclasses whose purpose is to store graphical information such as line thickness, spatial location of symbols and font. They do not refer to any semantic construct Out of Scope All metaclasses that are by nature or considered as out of scope for the notation analysis. For example, UCM metaclasses related to the notion of “scenario deﬁnitions” have been discarded. Indeed, scenario deﬁnition metaclasses are only used to provide an initial context for the execution/simulation of a UCM model (in a way similar to a test case). To consider Metaclasses to consider in the Semiotic Clarity analysis. This set is composed of concrete metaclasses, other combinations of metaclasses/attributes/relationships and elements from other categories assessed as semantic constructs.

#SC 7 6 5 8

5

55

The Semiotic Clarity analysis of UCM resulted in 55 semantic constructs to consider and 28 symbols (see details in [6]). Once these numbers are established, Semiotic Clarity can be assessed. Goodman’s theory of symbols (which the Physics of Notations theory refers to) requires a one-to-one match between semantic constructs and visual symbols so as to satisfy the requirements for a notational system [9].

Analysing the Cognitive Eﬀectiveness of the UCM Visual Notation

227

Table 2. Semiotic Clarity – Potential anomalies and UCM results SC Anomalies Symbol Deﬁcit Symbol Overload Symbol Excess Symbol Redundancy

Descriptions UCM % Construct not represented by any symbol 23 42% Single symbol representing multiple constructs 3 7% Symbol not representing any construct 2 4% Single construct represented by multiple symbols 1 2%

Table 2 illustrates the four symbol anomalies that can occur in practice. Symbol Deﬁcit is the main problem of the UCM notation, with a lack of 42% of symbols. In other words, 23 of the 55 UCM semantic constructs have no visual representation (not even textual). These constructs are related to performance annotations and to hierarchical binding relationships (in stubs). However, we would recommend not to dive head ﬁrst in the resolution of this problem: adding 23 new symbols in the notation is only one of the available options. It might be more appropriate to represent these semantic constructs textually or, conscientiously thought, even not at all! Actions to be taken should be considered keeping in mind that they usually result from trade-oﬀs as the interactions between the principles of the Physics of Notations are complex. Regarding Symbol Excess and Symbol Redundancy, they are insigniﬁcant with respectively 4% (2 symbols) and 2% (1 symbol). We argue these percentages can be considered negligible because a) these two principles do not prevent expressing model information; b) the “guilty” EmptyPoint construct has only one representation but it is optional (i.e., the modeller can use it or not) and this problem can be easily resolved by making the visual symbol mandatory. With 7%, Symbol Overload is another issue in the UCM notation. However, a closer look at the incriminated semantic constructs shows that the StartPoint and WaitingPlace constructs eﬀectively share the same symbol (although they are semantically distinct) but the way they are connected to the other nodes of the diagram discriminates between them (1 in and out paths for WaitingPlace whereas only 1 out path for StartPoint). The two semantic constructs called Component Team Protected, with and without Context, also have a common symbol. But, once again, their discriminability is improved by a label placed above the symbol when the Boolean Context attribute is True. However, textual discrimination is not ideal as discussed in Sect. 3.3. This observation also applies for the two semantic constructs Component Team NotProtected, with and without Context. 3.3

Perceptual Discriminability

Perceptual Discriminability is deﬁned as the ease and accuracy with which different symbols can be diﬀerentiated from each other. This is a prerequisite for accurate interpretation of diagrams [38]. Discriminability is determined by the visual distance between symbols, which is measured by the number of visual

228

N. Genon, D. Amyot, and P. Heymans

variables (see Fig. 2) on which they diﬀer and the size of these diﬀerences (number of perceptible steps between the values of a visual variable). The greater the visual distance between symbols, the faster and more accurately they will be recognised [38]. Discriminability also depends on user expertise regarding the notation: novices have higher requirements for discriminability than experts. Discriminability is a two-step mental process. In the ﬁrst step, background differentiation, symbols are distinguished from the medium (e.g., paper or computer screen). A simple but eﬃcient way to optimise background diﬀerentiation is to increase the contrast between symbols and the background, e.g., by replacing the default white background with a slightly darker background (e.g., lightgray) [6]. In the second step, symbol discriminability, symbols are discriminated from each other. Shape is the most important variable for discriminating between symbols (and hence between semantic constructs) as it represents the primary basis on which humans identify objects in the real world [2]. Moreover, it has the largest range of values (capacity) amongst the visual variables. We elicited 12 Shape values in UCM, summarised in Table 3 (we do not consider relationship representations as they are 1-D symbols). These values split into iconic shapes and conventional shapes. We can observe that about 50% of UCM symbols are icons. The remaining symbols are conventional shapes that belong to one of these three families: ellipses, triangles and quadrilaterals. Circles and triangles are unique values of their families and hence they do not compete with other Shapes values. On the contrary, rectangle, diamond, parallelogram and roundtangle are visually close Shapes stemming from the quadrilateral family. For rectangle, parallelogram and roundtangle, which are the shapes of symbols mapped to diﬀerent ComponentKinds, this is actually a good choice as their constructs are semantically close. An improvement would consist in stating clearly this rationale in the standard. The diamond Shape is more problematic because it represents a semantically distinct construct (Stub). The visual distance between this symbol and the other quadrilateral shapes should be increased. Hence, its shape should belong to another family of conventional shapes. Size is another factor that inﬂuences discriminability. Large symbols take more space on the reader’s ﬁeld of vision and focus attention. The size of UCM symbols is not speciﬁed in the URN standard. In practice, the size depends on the amount of text inside the symbol and, for Component, which allows containment relationships, it also depends on the size of the contained elements. This results in Table 3. Values and families for the Shape variable

Shape families icon ellipse triangle quadrilateral

Shape values cross, open arrow head, fork, reversed fork, clock, rectangle with in/out branches circle triangle rectangle, roundtangle, diamond, parallelogram

Analysing the Cognitive Eﬀectiveness of the UCM Visual Notation

229

UCM diagrams where the majority of symbols share almost the same size, except for Component symbols that are more variable (and generally larger). Even if this representation is appropriate for containment relationships, this could be seen also as a source of visual noise: the Size of the Component symbol carries no semantics. Colour is one of the most cognitively eﬀective visual variables: the human visual system is highly sensitive to variations in colours and it can quickly and accurately distinguish between them [38]. Diﬀerences in Colour are detected three times faster than Shape and are also more easily remembered [19]. However, if not used carefully, Colour can undermine communication. UCM does not specify the use of Colour in the URN standard. Actually, the part of the URN metamodel presenting the metaclasses for the concrete UCM syntax provides attributes for storing information related to Colour. However, it neither constrains its usage nor elicits a rationale supporting its utilisation. Texture (also called Grain) determines the style and thickness of the stroke used to draw shapes, as well as the motif used to ﬁll a symbol. Texture participates eﬀectively in symbol diﬀerentiation. In UCM, it allows distinct border strokes that vary according to the semantic constructs: Dynamic Stubs have a dashed border whereas Static Stubs use a solid one. In addition, Components with Protected attribute set to True have a double line border (versus a single line for Non Protected Components). In that way, UCM makes a real utilisation of the visual variable. Nevertheless, Texture selection should be done carefully as tools often render Texture badly when zooming out on a diagram. In other words, diﬀerentiating symbol types with various border Textures should be supported with redundant coding. There is also another way for distinguishing symbols that does not rely on visual variables: textual diﬀerentiation is a common but cognitively ineﬃcient way of dealing with excessive graphic complexity (Graphic Economy). Indeed, text processing relies on less eﬃcient (sequential) cognitive processes. To maximise discriminability, symbols should be diﬀerentiated using visual variables, so that diﬀerences can be detected automatically and in parallel by the human perceptual system. Text is more appropriately used to distinguish between symbol instances, rather than between symbol types. There are at least two usages of Textual Diﬀerentiation in UCM (see Fig. 1): – The Synchronizing and the Blocking attributes of a Stub are respectively rendered as an “S” inside the symbol and a “B” in subscript (while the “X” denotes a ReplicationFactor greater than 1). Unfortunately, they are used to distinguish between symbol types rather than symbol instances. – Team Components that require a binding to a parent Component are diﬀerentiated by a “Parent:” string added as a preﬁx to their name, above their symbol. It could be beneﬁcial to ﬁnd iconic alternatives to eliminate the use of that text, but such changes require validation and discussions with UCM practitioners. Redundancy is an important technique in communication theory to reduce errors and counteract noise. The visual distance between symbols can be increased

230

N. Genon, D. Amyot, and P. Heymans

by redundant coding, i.e., using multiple visual variables to distinguish between them [8]. In practice, to ﬁnd Redundant Coding cases, one has to look for visual variable values that are used only by a single symbol type. In UCM, the small black-ﬁlled triangle used to indicate traceability links is the sole symbol that beneﬁts from Redundant Coding. This currently poor result suggests that there is room in UCM for very eﬀective and cheap discriminability improvements. 3.4

Semantic Transparency

Visually direct representations help reduce the cognitive load as the meaning (also known as the referent concept) of the symbols is perceived more immediately. The degree of directness is measured by the Semantic Transparency principle. It ranges from semantically immediate – the referent concept is understood straight – to semantically perverse – the symbol suggests a diﬀerent meaning. Direct representations speed up recognition and improve intelligibility, especially to notation novices [3,21]. Semantic Transparency relies on built-in mnemonics that associate the symbols to previously-learned information or to a meaning learned and easily/eﬃciently remembered [30]. In UCM, all symbols but 7 are depicted with conventional shapes. This type of shapes are by nature semantically opaque, i.e., they do not convey any particular meaning. This may be a barrier to a cognitively eﬀective integration of UCM notation by novices because they have to learn and memorise the meaning of 21 symbols. Regarding the 7 other symbols (see Fig. 3), they are depicted with non conventional shapes. The Timer concept has an iconic representation – a clock symbol, which is deﬁnitively suitable. The visualisation of a Direction Arrow is a open arrow head. This is obviously not a conventional shape but it can hardly be considered an icon. Anyways, the symbol on its own is potentially misleading: it could be interpreted as a “greater” sign when it is seen out of its context. On the contrary, once it is drawn on a Path, then its referent concept becomes immediate. The cross is used to represent Responsibility. Similar to the observations on the representation of the Direction Arrow, the cross does not carry any particular semantics, except that it could related to the “X” drawn on maps pointing out the location of some artefact, and this is somehow the way it is used in UCM diagram (for more details on Responsibility, see [13]). The ORFork and ORJoin symbols are fork icons that eﬀectively conveys the notion of “path transformation” but that does not make clear if they stand for a split or a join and if they are AND or OR transformations. The ANDFork and ANDJoin concepts symbols are ﬁlled bars that share the same analysis and comments that the ORFork and ORJoin, with the exception that the ﬁlled bar is also the representation of Forks and Joins in the UML Activity Diagram notation. Regarding 1D symbols (the links between 2D symbols), the NodeConnection representation gives no further semantic reﬁnement than the concept of “relationship”. On the contrary, the TimeOutPath has a speciﬁc “zigzag” shape that semantically recalls “error triggers”. Therefore, it seems that this shape is not appropriate to denote the concept of “time out”.

Analysing the Cognitive Eﬀectiveness of the UCM Visual Notation

231

Fig. 3. The 7 UCM symbols not using conventional shapes

Semantic Transparency also applies when representing relationships. As stated by Moody, “[...] certain spatial arrangements of visual elements predispose people towards a particular interpretation of the relationship among them even before the meaning of the elements is known” [25]. In UCM, there are 2 metaRelationships that are visualised as spatial enclosure. These metaRelationships are denoted by the role they play with the ComponentRef metaclass: ContRef and Parent. The Location (x,y) visual variable is thus semantically meaningful and well appropriate to the nature of the semantic construct:“[...] ComponentRef may contain path nodes [...]” and “[...] ComponentRef may include component references [...]”. Moreover, the semantic construct Connect is also represented via spatial location. Indeed, Connect is not mapped to a visual symbol but it inﬂuences the (x,y) positioning on the element it connects. Illustrations are available in Fig. 67 in the URN speciﬁcation document [13]. 3.5

Visual Expressiveness

Visual Expressiveness measures the utilisation of the graphic design space, i.e., the number of visual variables and their range of values. Whereas Perceptual Discriminability focuses on pair-wise visual variation between symbols, Visual Expressiveness measures visual variations across the entire visual vocabulary. Variables that encode information are called information-carrying variables and form the primary notation. The others are the free variables and form the secondary notation [30], which are available for modellers to reinforce or clarify the meaning of diagram elements. Using a range of visual variables results in a perceptually enriched representation that optimises the exploitation of the human perceptual capabilities and maximises computational oﬄoading. Primary and Secondary Notations. UCM has a visual expressiveness of 6 as it uses 6 visual variables to distinguish between the semantic constructs. Location (which subsumes “x” and “y” variables), Shape, Colour, Size and Texture form the primary notation. Hence the secondary notation is logically composed of the Brightness and Orientation. This means that if modellers want to add information graphically, then they are theoretically limited to variations in values of

232

N. Genon, D. Amyot, and P. Heymans

these two visual variables. One could argue that textual comments could also be added on the diagram, which is actually right, but text is not deﬁned as a visual variable in the seminal work by the Physics of Notations theory nor in Bertin’s [1] original work. For these reasons, the (analysis of) utilisation of text in the notation should be delegated to the application of the Dual Coding principle (not discussed in this paper for brevity). Choices of Visual Variables. Once the primary notation is identiﬁed, we check “if form follows content” [25], i.e, if the information-carrying variables are adequate to the nature of the information they convey. The evaluation is summarised in Table 4. – Location: the nature of the information conveyed by the Location ﬁts the power of this variable. Indeed, Location in UCM is just meant for positioning UCM nodes on (or close to) the corresponding UCM paths. This is, in fact, hardly considered as interval values. The variable power is hence suﬃcient. Regarding capacity, only two semantically relevant values are attributed to this variable. The third is “variable” and means that the Location is not pertinent for a certain semantic construct. This leads to a theoretical saturation between 20% and 30%. In practice, we prefer to say that the saturation is almost negligible for the reasons previously mentioned. – Shape: the power of Shape is nominal, which means that its values are not comparable. This is eﬀectively the case as Shape diﬀerentiates between most UCM symbol types, which represent incomparable semantic constructs. Its capacity being unlimited, there is no saturation level. – Colour: the power of Colour is nominal and its capacity is around 7 to 10. The UCM notation uses black and white symbols. The information carried by this variable contributes to diﬀerentiate between symbol types, but it is not suﬃcient on its own. Therefore, the visual variable should either have a wider range (use more colours) or be used in conjunction with other variables. – Size: the power of Size is interval and its capacity is evaluated to 20. The analysis of UCM reveals a set of three values (see [6]). In fact, Size is only used in UCM in a comparative manner: to state that some symbols have to be smaller than others. This means that we could consider only a value of one for this variable. In any case, one or three choices do not saturate the Size variable. Table 4. Design space covered by the UCM notation

Visual variables Location (x,y) Shape Colour Size Texture

Power Interval Nominal Nominal Interval Nominal

Capacity 10 – 15 Unlimited 7 – 10 20 2–5

UCM values 3 15 1 3 5

Saturation 20 – 30% – 10 – 14% 15% 100%

Analysing the Cognitive Eﬀectiveness of the UCM Visual Notation

233

– Texture: is used to distinguish between diﬀerent sub-types or property values of semantic constructs. The power of Texture is nominal which corresponds to the nature of the conveyed information. The UCM notation uses 5 diﬀerent Textures, which makes this variable completely saturated. Two major observations emerge from the analysis of the choices of variables: ﬁrst, Location and Size, which have a power of type interval, convey information that does not require this type of power. Nevertheless, this is not an issue as the power and capacity of these variables are larger than the real need. Second, except for Texture, all variables of the primary notation have a low level of saturation, which leaves room for future improvements. 3.6

Complexity Management

Diagrammatic complexity, measured by the number of elements displayed on a diagram, is one of the major problems with visual notations, mainly because of their poor scaling capability [5]. Complexity has a huge eﬀect on cognitive eﬀectiveness as the amount of information that can be eﬀectively conveyed by a single diagram is limited by human perceptual abilities (e.g., discriminability) and cognitive capabilities (the working memory has a limited capacity and diagram understanding decreases rapidly when this capacity is exceeded). Like Weber [36], we believe that complexity management mechanisms are essential elements of modelling notations, and should thus be explicitly included in the primary notation. There are two main solutions here: – Modularisation is a key technique that consists in dividing complex diagrams into manageable chunks or sub-systems. The decomposition can take place at the same level of abstraction (horizontal decomposition) or produce ﬁner grained sub-diagrams (vertical decomposition). In practice, modularisation is achieved by including speciﬁc semantic constructs in the notation. However introducing such constructs is not enough: they have to be mapped to visual symbols and, to be eﬀective, diagrammatic conventions for decomposing diagrams need to be deﬁned. – Hierarchical Structuring. When applying vertical decomposition, diagrams are split into a set of ﬁner grained sub-diagrams. This forms a hierarchical structure that is intrinsically linked to the way our mind structures information, and thus required less mental eﬀort to recompose the split information. UCM scores rather badly on Complexity Management. Although systems modelled in UCM often count dozens of diagrams that are themselves composed of dozens of visual symbols (and sometimes over a hundred symbols), the notation does not provide any means for horizontal decomposition: neither symbol nor recommendations. We argue this is a high-priority issue as such an amount of information is humanly unmanageable, even by notation experts. Regarding hierarchical structuring, there can eﬀectively be logical structures in UCM models thanks to (a) the containment relationships between components and (b) Stub and PlugingBinding (to submaps). If we consider containment relationships

234

N. Genon, D. Amyot, and P. Heymans

between three Components A, B and C such that C is a child of B and B is a child of A, it is possible to visually represent the C Component inside its grandparent A while omitting B (its direct parent). But in this case, UCM does not clearly indicate that a “level” of information is actually missing on the diagram. A similar observation concerns Stub and PluginBinding: as stated in the UCM standard: “[...] Stub is a path node that indicates the presence of hierarchically structured UCM maps.” [13](page 96). Stub is a visual representation for vertical decomposition. However, this symbol fails to indicate what are the sub-level UCM maps, and such information is left for tools to present. 3.7

Cognitive Integration

Cognitive Integration helps to mentally integrate the information spread across several diagrams. Indeed, using several diagrams places additional cognitive demand on the readers to mentally integrate these pieces of information and to keep track of where they come from [34]. This principle is important, especially when large diagrams are decomposed according to the Complexity Management principle. Cognitive Integration takes place at two levels: perceptual integration, which refers to cues that simplify navigation and transitions between diagrams, and conceptual integration, which concerns the assembly of information from separate diagrams into a coherent mental representation. UCM is lacking support for Cognitive Integration. Practically, mechanisms such as diagram level numbering, signposting and navigation maps [20] could improve the perceptual integration. Contextualisation information [17,35] and summary diagrams [14] enhance the conceptual integration. The notation should ensure that modellers could name their diagrams and number them according to their level in the hierarchical structure (although the reuse of diagrams in multiple stubs at diﬀerent levels might cause diﬃculties). A navigation map could be created once symbols are provided for horizontal decomposition. 3.8

Dual Coding

Dual Coding is about complementing a visual notation with textual descriptions in order to beneﬁt from their respective advantages. The Dual Coding principle is built upon the Dual Coding theory [29], which states that using text and graphics together to convey information is more eﬀective than using either on their own. This is due to the fact that verbal and visual representations are addressed by distinct perceptual systems in working memory and referential connections between the two are strengthened. Dual Coding does not aﬀect Perceptual Discriminability because text is not a visual variable. Annotation is one of the most widespread forms of Dual Coding. It carries textual explanations for improving understanding of diagrams, which makes it the graphical equivalent of comments in programming languages. According to the concept of spatial contiguity [22], annotations included on the diagram are much more eﬀective than written in a separate document. Most of the time, visual annotations are embedded into a shape, like the “note” symbol appearing in most

Analysing the Cognitive Eﬀectiveness of the UCM Visual Notation

235

of the main modelling languages. This is a common practice that is not supported by any speciﬁc rationale and that encourages the “boxitis” phenomenon [37]. In UCM, annotations appear in the metamodel via the Comment metaclass and they are depicted as a “note”. This is exactly contradictory to the theoretical recommendation discussed above. However, one should pay attention to the fact that the Comment metaclass belongs to a speciﬁc type of metaclass used to store graphical information needed by computer-based tools. Usually, this type of metaclass is not considered as a part of the language metamodel. This also explains why Comment was not considered a semantic construct in the analysis of Semiotic Clarity (see Sect. 3.2). Hybrid symbols are symbols composed of visual artefacts (e.g., shapes or icons) and text at the language level. By language level, we mean text that is predeﬁned in the notation. Hence it is completely diﬀerent from text at the diagram level, where textual values of a symbol are given to properties of the corresponding semantic construct (e.g., the name of a class in a UML Class diagram). In UCM, there are three cases of hybrid symbols: – Synchronizing Stub is a diamond marked with a bold “S”. – Synchronizing Stub with blocking attribute to True and replicated a certain number of times is marked with the “S”, a lower “B” and an upper “X”. These three letters are occurrences of Dual Coding, even if they are only letters and not words. – When a Team ComponentType is included into another Team ComponentType, its symbol is adorned with “Parent:” label. We do not consider textual information placed on fork branches because this information is not chosen among a set of predeﬁned values. On the contrary, it is at the diagram level. 3.9

Graphic Economy

While Semiotic Clarity requires one visual symbol per semantic construct, the Graphic Economy principle tries to keep the amount of symbols cognitively manageable. The number of symbols in a notation is called “graphic complexity” and it is measured by the number of legend entries required. Preserving Graphic Economy is a key factor for cognitive eﬀectiveness since humans’ span of absolute judgement when discriminating visual alternatives is around 6 [24] (it can be higher for experts though). UCM has a graphic complexity of 28, which exceeds the limit by almost an order of magnitude beyond novices’ capabilities (more than 4 times the aforementioned limit). However, as we have stated in the analysis of the Cognitive Fit principle, UCM targets an expert audience. One may expect that these experts have greater visual discrimination abilities in comparison with novices and hence that their span of absolute judgement rise to an higher threshold. Nevertheless, “28” remains indubitably questionable and UCM would beneﬁt from reducing its graphic complexity. It could make the case for introducing symbol deﬁcit, i.e., choosing not to provide symbols for some seldom used constructs. Those can still

236

N. Genon, D. Amyot, and P. Heymans

be represented separately using text as suggested in Dual Coding. However, this technique should not be used systematically, as the percentage of symbol deﬁcit is actually more than 40% in the current notation. Another solution is to check the language for semantic redundancies that could be factored out. Based on the experience of one of the authors, no clear candidate for factorisation emerged. Finally, it is still possible to improve, at the notation level, Perceptual Discriminability, Perceptual Transparency and Visual Expressiveness as discussed in the previous sections.

4

Discussion

In this paper, we repeatedly stressed the importance of the notation when designing and using a visual modelling language. However, performing the analysis of a notation against the Physics of Notations theory is not without eﬀort. In fact, there are many factors that have to be emphasized: – It is a time-consuming endeavour: depending on the number of diagram types and semantic constructs, and on the maturity of the language, one could spend from a few weeks to several months on an evaluation. From our own experience analysing the UCM notation as well as OMG’s Business Process Modeling Notation [7], about two persons-month seem to be required for evaluating a mature language with analysts who already have basic knowledge of the language and an in-depth understanding of each principle of the theory. – Doing such analyses requires a deep understanding of the theory and of the rationale behind its principles, and so training becomes essential. – One of the most challenging tasks is to elicit the semantic constructs of the language itself. This task is not as straightforward as claimed by the Physics of Notations (see Sect. 3.2) and it is even harder when no metamodel is available (e.g., for the evaluation of the i* notation [27]).2 Simplifying this task and making it more systematic is important as the list of semantic constructs is a key input for the analysis of most of the principles. Lessons learned from the use of ITU-T Z.601 [11] related to mappings between layout schemata and concept schemata, where similar problems are faced, could also be exploited for the evaluation of Semiotic Clarity. In fact, Z.601 also stresses that, ideally, there should be a one-to-one mapping between a concept schema (i.e., the language metamodel) and its layout schema (i.e., the concrete syntax). – The availability of metrics or clear criteria for evaluating some of the principles is uneven. For instance, at the current stage, Perceptual Discriminability states that the visual distance between symbols should be “large enough” to facilitate discriminability, but no concrete metrics or criteria are provided to measure the distance between perceptual steps, although such information is available in secondary sources such as [1]. 2

It is unclear for now whether the use of abstract grammars such as those found in the SDL and Message Sequence Chart languages helps or hurts this elicitation task.

Analysing the Cognitive Eﬀectiveness of the UCM Visual Notation

237

– One needs to understand trade-oﬀs when introducing solutions. Many of the principles represent conﬂicting goals, and solving an issue related to one principle may create issues with other principles along the way, hence the need to understand how and by whom the notation is intended to be used (see Sect. 3.1). Moody et al. have already identiﬁed several positive and negative inﬂuences between the principles [27], but this also needs to be done at a ﬁner level of details, i.e., for individual solutions that aim to improve the language according to one particular principle. However, once the set of symbols and the set of semantic constructs are deﬁned, the Physics of Notations does provide the most accomplished theory to analyse and improve the cognitive eﬀectiveness of visual modelling languages. We argue that analysing a notation with the Physics of Notations is a valuable exercise for languages that are being standardized. Although the eﬀort required by the rigorous application of principles such as those illustrated here may sound important, it is still negligible compared to the tremendous costs associated with the development and evolution of a standard visual modelling language. Actually, the real question is whether we can aﬀord not to do a good analysis! The theory itself could also beneﬁt from the scrutiny that comes through a standardization process. For instance, ITU-T Recommendation Z.111 [12] provides notations and guidelines for the deﬁnition of (ITU-T) graphical languages, especially in terms of abstract and concrete grammars and metamodels. However, it does not include any guideline related to the cognitive eﬀectiveness of the notations being designed. Therefore, the Physics of Notations theory could be integrated to this standard, or become a companion standard (as ISO, OMG and other standardization bodies face similar issues with their own languages).

5

Conclusion

We presented the main elements of a systematic analysis of the UCM modelling notation based on the Physics of Notations theory. Here, we focused on issues [6] that are relevant for notation experts, who are the main practitioners of this language (Sect. 3.1). At this point, diﬀerent actions can be envisioned. Even if changing a notation that has existed for more than ﬁfteen years and that is now an international standard can be diﬃcult, many of the recommendations mentioned in the above analysis can have a high impact on the cognitive eﬀectiveness of the UCM notation while, at the same time, being simple to integrate to the URN standard. For instance, suitable symbols for the concepts related to performance annotations and stub bindings can be integrated immediately in the notation. This would help address the major symbol deﬁcit observed in Sect. 3.2. Providing support for horizontal decomposition with continuation symbols would improve Modularity. Introducing visual artefacts to show that intermediate levels of UCM Component containment exist in the model but are not represented on the diagram would improve vertical decomposition (Sect. 3.6). Documenting rationales for symbols (e.g., based on visual variables) would also enhance the overall

238

N. Genon, D. Amyot, and P. Heymans

quality of the standard. All of these improvements do not require any change to legacy symbols in the notation, hence preserving backward compatibility and investments in existing tools, models, and modellers training. Future extensions of the UCM notation for exception handling, for time representation, and for aspect-oriented modelling, which are currently suggested in the URN research literature but are not yet part of the standard, could also beneﬁt from an analysis based on the Physics of Notations theory. By doing so, we would optimise the cognitive eﬀectiveness of the new notation elements by design, in line with our global objective. In the long term, it might be envisioned to carry on an in-depth re-engineering of the URN notation in order to improve compliance with each principle of the theory. The results of the assessment of i* [27] could also be taken into consideration (and adapted) along the way because UCM’s companion notation in URN, namely GRL, overlaps substantially with i*. However, we must acknowledge that changing existing notations will be met with resistance (as it would be with UML and other standard languages). In addition, notation changes that comply with the Physics of Notations still require some validation, e.g., using experiments involving groups of individuals representative of the practitioners’ community. Finally, as several principles actually conﬂict with each other, notation re-engineering should target the “best compromise” between the principles rather than high scores on all of them, which is an elusive target. Acknowledgement. NSERC provided funding to D. Amyot in support of this collaboration. This work was also supported by the Interuniversity Attraction Poles Programme — Belgian State — Belgian Science Policy (MoVES), and the BNB.

References 1. Bertin, J.: S´emiologie Graphique: Les Diagrammes - Les R´eseaux - Les Cartes. Gauthier-VillarsMouton & Cie (1973) 2. Biederman, I.: Recognition-by-Components: A Theory of Human Image Understanding. Psychological Review 94(2), 115–147 (1987) 3. Britton, C., Jones, S.: The Untrained Eye: How Languages for Software Speciﬁcation Support Understanding by Untrained Users. Human Computer Interaction 14, 191–244 (1999) 4. Buhr, R.J., Casselman, R.S.: Use Case Maps for Object-Oriented Systems. Prentice Hall, Englewood Cliﬀs (1996) 5. Citrin, W.: Strategic Directions in Visual Languages Research. ACM Computing Surveys 24(4) (1996) 6. Genon, N., Amyot, D., Heymans, P., Moody, D.L.: Applying the “Physics” of Notations to (URN) Use Case Maps. Tech. Rep., PReCISE - University of Namur (2010), http://www.info.fundp.ac.be/~nge/AnalysingUCMagainstPoN.pdf 7. Genon, N., Heymans, P., Amyot, D.: Analysing the Cognitive Eﬀectiveness of the BPMN 2.0 Visual Notation. In: Malloy, B., Staab, S., van den Brand, M. (eds.) SLE 2010. LNCS, vol. 6563, pp. 377–396. Springer, Heidelberg (2011)

Analysing the Cognitive Eﬀectiveness of the UCM Visual Notation

239

8. Lohse, G.L.: The Role of Working Memory in Graphical Information Processing. Behaviour & Information Technology, 297–308 (1997) 9. Goodman, N.: Languages of Art: An Approach to a Theory of Symbols. BobbsMerrill Co., Indianapolis (1968) 10. Green, T., Blandford, A., Church, L., Roast, C., Clarke, S.: Cognitive Dimensions: Achievements, New Directions, and Open Questions. Journal of Visual Languages and Computing 17, 328–365 (2006) 11. ITU-T: Recommendation Z.601 Data Architecture of One Software System. International Telecommunication Union (February 2007) 12. ITU-T: Recommendation Z.111 Notations to Deﬁne ITU-T Languages. International Telecommunication Union (November 2008) 13. ITU-T: Recommendation Z.151 User Requirements Notation (URN) Language Definition. International Telecommunication Union (November 2008) 14. Kim, J., Hahn, J., Hahn, H.: How Do We Understand a Systeme with (So) Many Diagrams? Cognitive Integration Processes in Diagrammatic Reasoning. Information Systems Research 11(3), 284–303 (2000) 15. Krogstie, J., Sindre, G., Jorgensen, H.: Process Models Representing Knowledge for Action: a Revised Quality Framework. European Journal of Information Systems 15, 91–102 (2006) 16. Krogstie, J., Solvberg, A.: Information Systems Engineering - Conceptual Modeling in a Quality Perspective, Kompendiumforlaget. Kompendiumforlaget, Trondheim, Norway (2003) 17. Lamping, J., Rao, R.: The Hyperbolic Browser: a Focus + Context Technique for Visualizing Large Hierarchies. Journal of Visual Languages and Computing 7, 33–55 (1999) 18. Larkin, J., Simon, H.: Why a Diagram Is (Sometimes) Worth Ten Thousand Words. Cognitive Science 11, 65–99 (1987) 19. Lohse, G.: A Cognitive Model for Understanding Graphical Perception. Human Computer Interaction 8(4), 353–388 (1993) 20. Lynch, K.: The Image of the City. MIT Press, Cambridge (1960) 21. Masri, K., Parker, D., Gemino, A.: Using Iconic Graphics in Entity Relationship Diagrams: The Impact on Understanding. Journal of Database Management 19(3), 22–41 (2008) 22. Mayer, R.E., Moreno, R.: Nine Ways to Reduce Cognitive Load in Multimedia Learning. Educational Psychologist 38(1), 43–52 (2003) 23. Mendling, J., Reijers, H., van der Aalst, W.: Seven Process Modelling Guidelines (7PMG). Information and Software Technology 52(2), 127–136 (2010) 24. Miller, G.A.: The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. Psycological Review, 81–97 (1956) 25. Moody, D.L.: The “Physics” of Notations: Towards a Scientiﬁc Basis for Constructing Visual Notations in Software Engineering. IEEE Transactions on Software Engineering 35, 756–779 (2009) 26. Moody, D.L.: Theory Development in Visual Language Research: Beyond the Cognitive Dimensions of Notations. In: Proc. of the IEEE Symposium on Visual Languages and Human-Centric Computing (VLHCC 2009), pp. 151–154 (2009) 27. Moody, D.L., Heymans, P., Matuleviˇcius, R.: Visual Syntax Does Matter: Improving the Cognitive Eﬀectiveness of the i* Visual Notation. Requirements Engineering 15(2), 141–175 (2010) 28. Moody, D.L., van Hillegersberg, J.: Evaluating the Visual Syntax of UML: An analysis of the Cognitive Eﬀectiveness of the UML Family Of Diagrams. In: Proc. of the 1st International Conference on Software Language Engineering (2008)

240

N. Genon, D. Amyot, and P. Heymans

29. Paivio, A.: Mental Representations: A Dual Coding Approach. Oxford University Press, Oxford (1986) 30. Petre, M.: Why Looking Isn’t Always Seeing: Readership Skills and Graphical Programming. Communications of ACM 38(6), 33–44 (1995) 31. Popper, K.R.: Science as Falsiﬁcation. In: Routledge, Keagan, P. (eds.) Conjectures and Refutations, London, pp. 30–39 (1963) 32. Schuette, R., Rotthowe, T.: The Guidelines of Modeling - An Approach to Enhance the Quality in Information Models. In: Ling, T.-W., Ram, S., Li Lee, M. (eds.) ER 1998. LNCS, vol. 1507, pp. 240–254. Springer, Heidelberg (1998) 33. Shaft, T., Vessey, I.: The Role of Cognitive Fit in the Relationship between Software Comprehension and Modiﬁcation. MIS Quarterly 30(1), 29–55 (2006) 34. Siau, K.: Informational and Computational Equivalence in Comparing Information Modelling Methods. Journal of Database Management 15(1), 73–86 (2004) 35. Turetken, O., Schuﬀ, D., Sharda, R., Ow, T.: Supporting Systems Analysis and Design Through Fisheye Views. Communications of ACM 47(9), 72–77 (2004) 36. Weber, R.: Ontological Foundations Of Information Systems (Coopers And Lybrand Accounting Research Methodology Monograph No. 4). Coopers And Lybrand (1997) 37. White, A.W.: The Elements of Graphic Design: Space, Unity (2002) 38. Winn, W.: An Account of How Readers Search for Information in Diagrams. Contemporary Educational Psychology 18, 162–185 (1993) 39. Yu, E.: Towards Modeling and Reasoning Support for Early-Phase Requirements Engineering. In: Proc. of the 3rd IEEE International Symposium on Requirements Engineering (RE 1997), pp. 226–235. IEEE Computer Society, USA (1997)

Towards a Taxonomy of Syntactic and Semantic Matching Mechanisms for Aspect-Oriented Modeling Gunter Mussbacher1 , Daniele Barone2 , and Daniel Amyot1 1 2

SITE, University of Ottawa, 800 King Edward, Ottawa, ON, K1N 6N5, Canada {gunterm,damyot}@site.uottawa.ca Department of Computer Science, University of Toronto, 40 George St., Toronto, ON M5S 2E4, Canada [email protected]

Abstract. Aspect-oriented modeling (AOM) techniques have become increasingly popular over the last decade, as they enable improved modularity, separation of concerns, and reusability over conventional requirements and design modeling techniques. However, AOM notations typically employ pointcut matching mechanisms based solely on syntactic elements. In order to make aspects more generic and more robust to changes and to diﬀerent modeling styles, semantic matching must be better exploited. We present a taxonomy that aims to classify matching mechanisms based on how syntactic or semantic information is used during the matching process, thus deﬁning levels of sophistication for matching mechanisms from simple syntactic approaches to complex semantic approaches. We are particularly investigating how schema matching techniques developed in the database research community are applicable in this context. We illustrate the feasibility and potential beneﬁts through examples based on the Aspect-oriented User Requirements Notation (AoURN). Keywords: Aspect-oriented modeling, aspect composition, AoURN, Aspect-oriented User Requirements Notation, schema matching.

1

Introduction

Many modeling languages provide support for separation of concerns, a key software engineering principle, through modules or similar constructs. However, restricting modularization to a single dimension makes it diﬃcult to localize a concern that appears in many modules of the primary decomposition. This may lead to increased complexity and diﬃculties in maintenance and reuse. Aspect-oriented modeling (AOM) techniques allows modelers to modularize their descriptions along more than one dimension [25], thus alleviating the aforementioned problems. Over the last decade, AOM techniques have been developed for many requirements and design notations in order to better address separation of concern issues found in complex models [23]. Aspects typically must deﬁne their aspectual F.A. Kraemer and P. Herrmann (Eds.): SAM 2010, LNCS 6598, pp. 241–256, 2011. c Springer-Verlag Berlin Heidelberg 2011

242

G. Mussbacher, D. Barone, and D. Amyot

properties specifying what the aspect wants to achieve, patterns called pointcuts specifying where the aspect is to be applied, and composition rules specifying how the aspect is to be applied. Pattern matching is a key ingredient for AOM techniques as the pointcuts have to be matched against the model to determine where the aspect is to be integrated with the model. Most AOM techniques use pattern matching techniques that work on a syntactic level only. Some AOM techniques have explored pattern matching techniques based on semantics [4,7,14,17], but further research is required to investigate how semantics can be better exploited in the matching process. To that end, we are interested in schema matching techniques that have been developed in the database research community and their applicability in the context of aspect-oriented modeling. The problem of matching database schemas (and instances) is akin to the issue of matching model structures (and elements), hence there is an opportunity to exploit the experience and knowledge already available in that community. We present a taxonomy of pattern matching techniques that can be used to i) assess and classify existing AOM techniques and ii) guide future research initiatives. Wherever possible, we demonstrate already existing and future pattern matching techniques with the help of the Aspect-oriented User Requirements Notation (AoURN) [16], an aspect-oriented requirements modeling technique based on ITU-T Recommendation Z.151 [1,11]. The taxonomy is meant to name and categorize various pattern matching techniques, so that language designers can i) become aware of their existence, ii) name them, and iii) assess, compare, and potentially complete pattern matching mechanisms in an aspect-oriented modeling language. This paper, however, is not directly about choosing the most appropriate technique or about identifying conﬂicting techniques. While the focus of this paper is on AOM, aspect-oriented development in general may beneﬁt from this taxonomy as the pattern matching techniques are also applicable to, e.g., aspect-oriented programming. In the remainder of this paper, Sect. 2.1 gives a brief overview of related work on semantic matching in the AOM context, Sect. 2.2 a summary of schema matching techniques from the database research community, and Sect. 2.3 a basic overview of AoURN. Section 3 introduces our proposed taxonomy of pattern matching techniques, classifying and discussing various syntactic and semantic approaches. Section 4 concludes the paper and identiﬁes future work.

2 2.1

Background Semantic Matching of Aspect-Oriented Models

Semantics-based matching and composition of aspect-oriented modeling have been explored in the following related work. Chitchyan et al. [4] use natural language processing to take into account the semantics of the English language when composing natural language requirements documents. For aspect-oriented modeling, Klein et al. [14] compose UML sequence diagrams by matching semantically equivalent but syntactically diﬀerent sequences, giving a thorough

Syntactic and Semantic Matching Mechanisms for Aspect-Oriented Modeling

243

explanation on how to deal with loops and loop unrolling. Mussbacher et al. [17] also propose a matching approach for AoURN and aspect-oriented sequence diagrams where semantically-equivalent sequences are matched, but they also handle hierarchical decomposition and replacement of scenarios. Cottenier et al. [7] match state machines at diﬀerent levels of abstraction by performing a static control ﬂow analysis to ﬁnd matching patterns. Patterns are expressed with state machines at the behavioral speciﬁcation level and then matched against more complex implementation state machines while taking the semantics of the behavioral speciﬁcation into account. 2.2

Schema Matching Techniques from the Database Research Community

Schema matching is a critical task in many database application areas, such as data integration, data warehousing, and semantic query processing. A matching task takes as input two schemas and returns as output semantic correspondences (i.e., the match result) between elements of such schemas. Auxiliary information such as dictionaries and thesauri may also be involved in such a task to improve its eﬀectiveness. This information does not have to be static but may also be learned over time [3]. In the past decade, various systems and approaches have been developed to determine schema (but also ontology) matching [5,8,20,24]. In particular, referring to the taxonomies described in [20,24], individual or combinational matchers can be used for the implementation of a matching task. The former use a single criterion to perform the match, while the latter use multiple criteria (hybrid matchers) or run independent matchers and then combine their ﬁnal results (composite matchers). In general, matchers can be characterized along diﬀerent, orthogonal criteria (see [20] for a detailed survey). For example, matching approaches can consider instance data or only schema-level information (instance vs. schema). The match can be performed for individual schema elements, such as attributes, or for combinations of elements, such as complex schema structures (element vs. structure). A matcher can use a linguistic approach, e.g., based on names and textual descriptions of schema elements, or a constraint-based approach, e.g., based on types, keys, and relationships. The overall match result may also relate one or more elements of one schema to one or more elements of another (cardinality matching). Element-Level Techniques. Common examples of element-level techniques (see [24] for details) include the following: – String-based techniques are often used to match names, name descriptions, comments, etc. These techniques consider strings as sequences of symbols in an alphabet and are based on the intuition that the more similar the strings, the more likely they represent the same concept. Some of the techniques

244

–

–

–

– –

G. Mussbacher, D. Barone, and D. Amyot

extensively used include: Preﬁx (e.g., int and integer), Suﬃx (e.g., phone and telephone), Edit distance (e.g., distance among NKN and Nikon is 2/5), and N-gram (e.g., distance between nkon and nikon is 1/3). Cohen et al. provide an interesting comparison of such techniques in [6]. Language-based techniques consider names in some natural language (e.g., English). They are based on Natural Language Processing techniques which exploit morphological properties of the input words. Such techniques are: Tokenization (e.g., Hands-Free Kits → ), Lemmatization (e.g., Kits → kit), and Elimination (e.g., The Kits → Kits). Linguistic resources such as common knowledge or domain-speciﬁc thesauri are used to match words based on linguistic relationships such as synonyms (Car vs. Automobile) or hyponyms / hypernyms (Digital Camera vs. Camera). Constraint-based techniques exploit constraints in schemas often used to deﬁne data types, value ranges, uniqueness, optionality, relationship types, and cardinalities. For example, a matcher may evaluate the similarity among schema elements by checking their i) data types and data domains (e.g., a gender attribute with a String data type and a [M, F] data domain), ii) characteristics of keys (e.g., unique, primary, foreign), iii) relationship cardinalities (e.g., 1:1, 1:*) or iv) is-a relationships (e.g., manager is-a employee). Alignment reuse techniques are based on the use of particular external resources which contain alignments of previously matched schemas/ontologies. Upper level formal ontologies techniques exploit “upper ontologies” (i.e., ontologies that describe very general concepts that are the same across all knowledge domains), such as DOLCE [9], to interpret the information input to the matching activity. In fact, since ontologies are formal, explicit speciﬁcations of shared conceptualizations, matching techniques that exploit them attempt to infer the semantics behind input elements, thus resulting in a (semantically) improved matching activity.

Structure-Level Techniques. Structure-level techniques, on the other hand, consider elements that appear together in a structure to evaluate the matching in the two input schemas. Depending on how precise and complete the match must be, it is possible to have i) a full structural match, when all components of the structures must match in the two schemas, and ii) a partial structural match, where only some of the components are required to match. For example, we have a full match in the two schemas Address (ACity, AState, AZIP) and EmployeeAddress (ECity, EState, EZIP), and a partial match in the two schemas Employee (IName, ISurname, IBirthDate) and Student (SName, SSurname, SPhone). In particular, partial matches can be useful when schemas belong to diﬀerent domains, such as the business and education domains in the above example. To enhance structural matching techniques, patterns representing structural equivalences can be identiﬁed and kept in a library. As deﬁned in [24], diﬀerent structural matching techniques have been used in the database community:

Syntactic and Semantic Matching Mechanisms for Aspect-Oriented Modeling

245

– Graph-based techniques are graph algorithms that take as input labelled graphs. These graphs are database schemas, taxonomies, or ontologies that are transformed into graph-like structures containing terms and their interrelationships. A common approach for the evaluation of the matching for two nodes in diﬀerent schemas/ontologies is to analyze their positions within the graphs. The idea behind that is that if two nodes are similar, then there is also a degree of similarity in their surrounding neighbours. Diﬀerent algorithms may be adopted for the matching activity, e.g., Graph-matching or Children. The Graph-matching algorithm relies on the work on graph (tree) matching in graph theory, where the matching of graphs is a combinatorial problem that can be computationally expensive; therefore, approximated methods are used as a solution. An example of such an algorithm, encoded as an optimization problem, is to ﬁnd the matching (part of a) graph which minimizes some similarity distance between matched elements that belong to the two input graphs. The Children algorithm evaluates the structural similarity among inner nodes by relying on the similarity of their children nodes, i.e., non-leaf elements match if their children sets are highly similar. – Taxonomy-based techniques are particular graph algorithms that take into account only the specialization relation during the matching activity. The idea behind that is that is-a links connect terms that are similar and therefore their neighbours may also have a degree of similarity. – Repository of structures techniques store schemas/ontologies and their fragments together with pair-wise similarities between them (e.g., coeﬃcients in the [0..1] range). – Model-based techniques handle the input based on its interpretation with respect to some formal semantics, such as model-theoretic semantics. In particular, such techniques are designed on well grounded deductive methods, e.g., propositional satisﬁability (SAT) or description logics (DL). In the former, the graph (tree) matching problem is decomposed into a matching problem for a set of nodes, i.e., pairs of nodes with possible relationships between them. Each node matching problem is then represented as a propositional formula and checked for validity with respect to background knowledge described by axioms. In the latter, a similar approach is used but the limited expressivity of propositional satisﬁability is overcome by allowing not just unary predicates but also, for example, binary predicates to represent properties or roles. For the interested reader, further details of the above techniques and others can be found in [24]. Measures. In addition to the provision of matchers, some measures have been established so far by the database community to evaluate the quality and effectiveness of matchers [8]. These measures, namely F-Measure and Overall, are based on the Precision and Recall functions well known in the Information Retrieval research community. Precision indicates the fraction of all found matches that are correct, while Recall expresses the percentage of all possible matches

246

G. Mussbacher, D. Barone, and D. Amyot

in the schemas that are correctly found. Therefore, Precision can be seen as a measure of exactness, while Recall can be seen as a measure of completeness. 2.3

Aspect-oriented User Requirements Notation (AoURN)

AoURN [16] uniﬁes goal-oriented, scenario-based, and aspect-oriented modeling in one framework to support the elicitation, speciﬁcation, analysis, and validation of requirements. AoURN extends ITU-T’s User Requirements Notation with aspect concepts for its two sublanguages, namely the Goal-oriented Requirement Language (GRL) and Use Case Maps (UCM). AoURN treats concerns as ﬁrstclass modeling elements to which scenario models and goal models are assigned regardless of whether a concern is crosscutting (i.e., an aspect) or not. Typical concerns in the AoURN context are stakeholders’ intentions, non-functional requirements, and use cases. AoURN groups together all relevant properties of a concern such as goals, behavior, and structure, as well as pointcut expressions needed to apply new goal and scenario elements or to modify existing elements in an AoURN model. AoURN speciﬁes pointcuts with the URN notation itself and hence allows any partial URN scenario or goal model to be used as a pattern. The pattern can be parameterized with wildcards and may contain logical expressions for namebased matching. Variations in a match are accommodated by the anytype and anything pointcut elements which may be matched against a goal model element of any type and an arbitrary sequence of scenario elements, respectively. In addition, AoURN employs a pattern matching technique that exploits semantic equivalences of hierarchical models in the URN modeling language [17]. AoURN consists of the two sub-languages, the Aspect-oriented Use Case Maps (AoUCM) notation for scenario modeling and the Aspect-oriented and Goaloriented Requirement Language (AoGRL) for goal modeling. The basic structure of an AoUCM model is shown in Fig. 1. Aspectual properties are deﬁned on an aspect map, using standard UCM models. A pointcut stub acts as a placeholder for the matched base model elements, thus allowing composition rules to be visually deﬁned. For example, Behavior.before is shown before the pointcut stub and thus occurs before the matched base model elements in the composed system. The actual pattern to be matched is deﬁned on a separate map called the pointcut map which is plugged into the pointcut stub. In this case, an OR-fork followed by a responsibility on one branch is matched. Fig. 1 indicates the matched pattern in the base model. Composition of the aspect with the base model is achieved by placing aspect markers in the base model. Aspect markers link the base model with the aspectual properties, hence inserting the aspect at the appropriate locations in the base model. The basic elements of the standard UCM notation are brieﬂy described in this paragraph. A map (e.g., the base model in Fig. 1) contains any number of paths and components. Paths express causal sequences and may contain several types of path nodes. Paths start at start points ( , e.g., start) and end at end points ( , e.g., endSuccess). Responsibilities ( , e.g., Behavior.before) describe required actions or steps to fulﬁll a scenario. OR-forks ( ) and OR-joins ( )

Syntactic and Semantic Matching Mechanisms for Aspect-Oriented Modeling

247

are used to show alternatives, while AND-forks ( ) and AND-joins ( ) depict concurrency. Waiting places ( ) and timers ( ) denote locations on the path where the scenario stops until a condition is satisﬁed. UCM models can be decomposed hierarchically with the help of a static stub ( ) which contains one sub-map called plug-in map. A component ( ) is used to specify the structural aspects of a system. Map elements which reside inside a component are said to be bound to the component. Components may contain sub-components and have various types and characteristics. Aspect Map

Base Model Pointcut

start

P

Behavior.before

endSuccess

start

1

matched pointcut expression fail

2

R0

Behavior.after_success

Behavior.after_fail

3

endFail

Pointcut Map

success

R1 Pointcut stub:

P

*

Aspect marker:

(plug-in bindings (dashed and long-dash-dot-dotted arrows) and matched pointcut expression only shown for illustration purposes – not part of concrete syntax of the AoUCM notation)

Fig. 1. AoUCM in a Nutshell

AoGRL models are deﬁned similarly to AoUCM models, while taking the highly interconnected nature of goal models into account. For more information on AoURN, the interested reader is referred to the URN Virtual Library [26].

3

Taxonomy of Syntactic and Semantic Matching

AOM (including AoURN) can take advantage of the implementation of matchers in the database community to address the fragile pointcut problem [15]. Pointcuts are often very susceptible to rather small changes in the model. A small change may be enough for a pattern to no longer match and the aspect not being applied as desired. Our proposed taxonomy of pattern matching techniques for the AOM context is presented as a feature model [13] in Fig. 2. Pattern matching techniques can be characterized along two major dimensions. The ﬁrst dimension describes what kind of model information is being matched: Individual model Elements (mandatory), a Structure of model elements (mandatory), or optionally Runtime Information, i.e., dynamic information from the ﬁrst two categories that is only available when the model is being executed. The second dimension expresses whether the pattern matching technique is based on Syntax or Semantics. The intuitive distinction here is that if a matcher is comparing elements with the same syntax, then the approach is classiﬁed

248

G. Mussbacher, D. Barone, and D. Amyot

Pattern Matching Techniques for the AOM Context Run-time Information

Individual Element

Syntax (IE)

Exact Match (IE)

Structure

Semantics (IE)

Syntax (ST)

Sub-typing

Wildcards (ST)

Type Wildcards

Approximation (RT)

Approximation (ST-SE)

Translation-based Approaches

Approximation (IE-SY)

Semantic Inter-Equivalences

Historical Information

Boolean Operators (ST)

Synonym

Regular Expressions

Semantics (RT)

Semantic Intra-Equivalences

Exact Match (ST)

Wildcards (IE)

Boolean Operators (IE)

Semantics (ST)

Queries

Ontology-based Approaches

Approximation (ST-SY)

Approximation (IE-SE)

Supported by AoURN

IE…Individual Element ST…Structure RT…Run-time Information SY…Syntax SE…Semantics

AND-group IOR-group mandatory optional

Fig. 2. Taxonomy of Pattern Matching Techniques for the AOM Context

as Syntax. If, however, the matcher compares elements with diﬀerent syntaxes and looks at the meanings of the elements, the approach is classiﬁed as Semantics. This is a rather pragmatic diﬀerentiation, as it is contentious to classify techniques as syntactic or semantic. Whenever two elements are compared, the matching task needs to ﬁnd semantic correspondences. Diﬀerent matching techniques are hence used to approximate the ideal semantic function that is needed to determine whether two elements are the same. The ideal function is one for which both Precision and Recall are equal to 1 for any input. In a sense, semantics as often used in the context of software engineering is just another way of describing elements and therefore not that much diﬀerent than syntax when it comes to matching tasks. The leaves of the feature model then identify a number of pattern matching techniques which are discussed in more detail in the following sub-sections. Furthermore, the leaves are arranged generally from simpler to more sophisticated techniques with the simpler ones being shown above the more sophisticated ones. For example, the Exact Match (IE) technique is less sophisticated than the Approximation (IE-SY) approach. In general, approximation-based approaches decide with the help of a similarity metric and a threshold whether patterns match or not. This is quite diﬀerent to the prevailing approaches for AOM, since elements may be matched by approximation-based techniques that should not necessarily be matched. In contrast, existing AOM techniques for pattern matching generally assume that the matching is very clear and that there cannot be a discussion about whether

Syntactic and Semantic Matching Mechanisms for Aspect-Oriented Modeling

249

a match exists or not. Furthermore, approximation-based approaches may be applied to all categories as shown in Fig. 2, highlighting that they are signiﬁcant enough to warrant further investigation. AoURN already employs a hybrid matcher that uses multiple pattern matching techniques from the taxonomy to ﬁnd syntactic and semantic correspondences in the model and pointcuts. AoURN supports Exact Match (IE), Wildcards (IE), Boolean Operators (IE), Sub-typing, Exact Match (ST), Wildcards (ST), and Semantic Intra-Equivalences (see techniques with dashed, bold border in Fig. 2). A ﬁrst step to improve the actual AoURN matching algorithm (and the matching algorithms of other AOM techniques) could be to adopt one or more element-level techniques as described in Sect. 2.2 to compare model elements and their properties, e.g., element names, metadata, etc. These techniques fall into the Regular Expressions, Approximation (IE-SY), and Synonym categories of the taxonomy. 3.1

Syntax-Based Matching of Individual Elements

This group of techniques matches the properties of individual elements. Exact Match (IE) requires a pattern to be exactly the same. E.g., Fig. 3 shows an AoURN responsibility with name R1 in the pointcut that matches a responsibility with name R1 in the model. The pointcut is shown on the left for each technique in Fig. 3 and the following ﬁgures while the model to be matched is shown on the right. Note how grey start and end points indicate the beginning and end of the pointcut, respectively. See also [21] for a non-AoURN example that matches multiple properties of an individual element, allowing operations with the same name to be diﬀerentiated by their return types or classes with the same name by whether they are abstract or concrete. R1

R1 s1

R*

e1

Resp s1

a) Exact Match

R1 || R2

e1

b) Wildcards

R2 s1

R[^2][abc]

e1

Rab s1

c) Boolean Operators

e1

d) Regular Expressions

Resp1

Rsp1 s1

e1

e) Approximation

Fig. 3. Syntax-based Matching of Individual Elements

Wildcards (IE) allow for portions of a pattern to be arbitrary. E.g., an AoURN responsibility with name R* in the pointcut matches a responsibility with a name starting with R in the model.

250

G. Mussbacher, D. Barone, and D. Amyot

Boolean Operators (IE) allow for logical operators (AND, OR, NOT) to be used in the pattern description. E.g., an AoURN responsibility with name R1 || R2 in the pointcut matches a responsibility with name R1 or a responsibility with name R2 in the model. Regular Expressions allow much more complicated patterns to be speciﬁed. E.g., an AoURN responsibility with name R[ˆ2][abc] in the pointcut matches a responsibility in the model with R as the ﬁrst character of its name, any character except 2 as the second one, and a, b, or c as the third one. Approximation (IE-SY)–based approaches are tolerant of small diﬀerences in the match. E.g., an AoURN responsibility with name Resp1 in the pointcut matches a responsibility with name Rsp1 in the model. AoURN currently supports Wildcards (IE) and Boolean Operators (IE), and also indirectly Exact Match (IE). The following constraints exist for the pattern matching techniques in this group. Exact Match (IE) is subsumed by all other pattern matching techniques in the Individual Element sub-tree (as it is a special case of all the others). In addition, Regular Expressions subsumes Wildcards (IE) and Boolean Operators (IE). 3.2

Semantics-Based Matching of Individual Elements

This group of semantic techniques also matches the properties of individual elements. Sub-typing allows elements from the same type hierarchy to be matched. E.g. in Fig. 4, an AoURN responsibility that is bound to a generic component in the pointcut matches a responsibility bound to a component of type process (parallelogram) in the model. Furthermore, an AoURN intentional element (in GRL, not shown here) that is marked with the anytype tag matches any type of intentional element. R1

R1 s1 a) Sub-typing

provideService

offerService

e1

provideService

e1

e1

d) Translation rentDVD

e) Ontology

fournirService

s1

c) Synonym

s1

s1 b) Type Wildcards

s1

rentMovie

R

?

e1

e1

sn sn

s1

e1

f) Approximation

Fig. 4. Semantics-based Matching of Individual Elements

Type Wildcards allow for elements of any type to be matched regardless of the type hierarchy. E.g., an AoURN wildcard element matches any AoURN model path element (i.e., a responsibility, an OR-fork, an AND-join, etc.). Note

Syntactic and Semantic Matching Mechanisms for Aspect-Oriented Modeling

251

that the AoURN wildcard model element depicted with a ? does not currently exist in the AoURN language (neither in AoURN’s abstract nor concrete syntax). Synonym uses the semantics of natural language to improve the matching results. E.g., an AoURN responsibility with name provideService in the pointcut matches a responsibility with name oﬀerService in the model. See also [4] for non-AoURN examples. Translation-based Approaches allow for matches across languages. E.g., an AoURN responsibility with the English name provideService in the pointcut matches a responsibility with the French name fournirService in the model. Ontology-based Approaches make use of ontological information to ﬁnd reasonable matches. E.g., an AoURN responsibility with name rentMovie in the pointcut matches a responsibility with name rentDVD in the model when the ontology states that a DVD is a movie. Approximation (IE-SE)-based approaches allow for similar elements to be matched. E.g., an AoURN start point in the pointcut matches a waiting place in the model because both have conditions and could model the start of a new scenario. Interestingly, the notational symbol for start points and waiting places is the same in AoURN, hinting at the similarity of the concepts. Start points and waiting places are diﬀerentiated in AoURN simply by their positions on a path. Note that ontology-based approaches are a kind of approximation-based approach but are classiﬁed separately due to the popularity of ontologies. AoURN currently supports only Sub-typing. In terms of constraints, Type Wildcards subsumes Sub-typing. 3.3

Syntax-Based Matching of Structure

This group of techniques matches the structure of several modeling elements. Exact Match (ST) requires the structure to be exactly the same. E.g. in Fig. 5, an AoURN responsibility followed by an OR-fork in the pointcut matches a responsibility followed by an OR-fork in the model. Wildcards (ST) allow for variations as a portion of the structure may be arbitrary. E.g., an AoURN responsibility R1 followed by the anything pointcut element (. . . ) and then by another responsibility R2 in the pointcut matches a responsibility R1 followed by any sequence of model path elements (including none) before another responsibility R2 in the model. The sequence of model elements in the example in Fig. 5.b is an OR-fork followed by responsibility R3. Boolean Operators (ST) allow for logical operators (AND, OR, NOT) and thus place additional constraints on structures that are to be matched. E.g., an AoURN anything pointcut element is further reﬁned by two alternatives for the model elements matched by the anything pointcut element. Note that the syntax required for this category is currently not supported by AoURN. Queries allow more ﬂexible expressions to be deﬁned for the pattern description. This is similar to the Regular Expressions category in the group of syntactic techniques for individual elements. QVT or OCL queries and path-based approaches for describing patterns fall into this category. E.g., a query restricts

252

G. Mussbacher, D. Barone, and D. Amyot

R1

R1

e1

s1

R1

R2

R1

R3 R2

s1

e2

e1

e2

a) Exact Match

b) Wildcards

R1

R2

R1

R3 R2

e1

s1 e2 R*

R*

||

c) Boolean Operators

R1

R2

R1 s1

<< PathNode p | e2 p.oclIsTypeOf(RespRef)>>

R3 R2

e1 R1

R3

R2

d) Queries

R1 R2 R4

R4

s1

e1

e) Approximation

Fig. 5. Syntax-based Matching of Structure

the AoURN anything pointcut element to those sequences in the model that contain at least one responsibility. Again note that the syntax required for this category is currently not supported by AoURN. Approximation (ST-SY)-based approaches are tolerant of small diﬀerences in the match. E.g., an AoURN sequence of responsibilities (R1, R2, R3, R4) in the pointcut matches a slightly diﬀerent sequence (R1, R2, R4) in the model. AoURN currently supports Wildcards (ST), and also indirectly Exact Match (ST). In terms of constraints, Exact Match (ST) is subsumed by all other pattern matching techniques in the Structure sub-tree. In addition, Boolean Operators (ST) and Queries subsume Wildcards (ST). 3.4

Semantics-Based Matching of Structure

These semantic techniques also match the structure of several modeling elements. Semantic Intra-Equivalences exploit semantic equivalences of a single language to improve the matching results. This is similar to the Synonym category in the group of semantic techniques for individual elements. E.g. in Fig. 6, a sequence of two AoURN responsibilities in the pointcut matches one responsibility followed by a static stub with a plug-in map with one responsibility in the model (this category is the topic of [17] and hence discussed in more detail there; in short, equivalences for hierarchical decomposition are considered). See also [7,14] for non-AoURN examples.

Syntactic and Semantic Matching Mechanisms for Aspect-Oriented Modeling

R1 R2

R1

R1 R2

e1

s1 R2 s2

R1

253

R2

e2

a) Semantic Intra-Equivalences

b) Semantic Inter-Equivalences

R1 s1

e1

e2 c) Approximation

Fig. 6. Semantics-based Matching of Structure

Semantic Inter-Equivalences exploit semantic equivalence across modeling language barriers. This is similar to the category of Translation-based Approaches in the group of semantic techniques for individual elements. E.g., an AoURN responsibility in the pointcut matches a step in a use case or an activity in an activity diagram in a UML model. Approximation (ST-SE)-based approaches allow for patterns to be matched that could but not necessarily have to match. E.g., an AoURN OR-fork in the pointcut matches an OR-fork with a preceding responsibility in the model as, often but not always, a responsibility before an OR-fork evaluates the condition for the branches of the OR-fork. On the other hand, such responsibilities are also omitted at times. AoURN currently supports Semantic Intra-Equivalences for some constructs. 3.5

Matching of Run-Time Information

All syntax-based and semantics-based techniques applicable to individual elements and structure can also be applied at run-time, for supporting in-context, dynamic aspect composition. AoURN pointcut expressions that include results of trade-oﬀ analyses for AoURN’s goal models or that include UCM variables are an example for the use of run-time information in pointcuts [19]. E.g. in Fig. 7, an AoURN responsibility in the model increases a counter variable by one – as shown by AoURN’s action language – to keep track of the number of times the loop is traversed. The counter variable is used in the speciﬁcation of the branch conditions of the OR-fork shown in brackets. The pointcut expression then stipulates that a match only occurs if the counter variable equals the value 5. Note that the syntax required for this pointcut expression is currently not supported by AoURN. In addition, further semantics-based techniques include Historical Information and Approximation (RT). E.g., the former may consider trends in the last

254

G. Mussbacher, D. Barone, and D. Amyot

R1 [counter < limit]

initialize

increase

s1 eval( [counter == 5] )

[else]

counter = 0;

e1

counter = counter + 1;

Fig. 7. Matching of Run-time Information

ﬁve results of the AoURN trade-oﬀ analyses when matching pointcuts, while the latter may determine a value range for a successful match. A non-AoURN example in this category is HiLA [10] and trace-based matching techniques. HiLA tracks the execution history of state machines to decide whether a match exists. AoURN currently supports neither Historical Information nor Approximation (RT).

4

Conclusion and Future Work

This paper presented a ﬁrst attempt at establishing a taxonomy of pattern matching techniques in the AOM context. While several of these techniques are already in use in various AOM approaches, there are many that have not been applied to AOM. Most notably, this is the group of approximation-based techniques that have been extensively used in the database research community. We argue that the use of such techniques in the AOM context should be investigated more thoroughly. In future work, we plan to validate our taxonomy by classifying further AOM techniques with it and by implementing some of the new techniques for AoURN. With little eﬀort, Regular Expressions as well as Type Wildcards could be supported by the jUCMNav AoURN tool [12]. Synonym, Translation-based Approaches, Ontology-based Approaches, Boolean Operators (ST), and Queries are techniques that require medium eﬀort. Finally, Semantic Inter-Equivalences, Historical Information, and all Approximation-based techniques require the most resources to be implemented in the AoURN tool. Whether a particular matching technique is actually practical for a given AOM language in a particular context also needs to be validated. To that end, appropriate metrics based on Precision and Recall ﬁrst need to be deﬁned. This will help determine which techniques actually lead to unacceptable numbers of incorrect matches or missed matches. We also expect that contributions from the model comparison and merging research area [18] will enable us to expand and consolidate our taxonomy. Furthermore, the same issues with respect to pattern matching are faced by search engines on the Web [2,22], where machine-learning approaches dominate ontology-based approaches for natural-language processing. Finally, we will investigate a framework to evaluate various matching techniques based on dimensions and metrics. For example, one dimension could be “Refactoring Resistance”

Syntactic and Semantic Matching Mechanisms for Aspect-Oriented Modeling

255

and the associated metrics could evaluate as input the kind of activities the user is interested in, giving an indication of how sensitive a matching technique is with respect to refactoring activities. Acknowledgments. This research was supported by NSERC’s Discovery Grants program as well as the Ontario Graduate Scholarship Program.

References 1. Amyot, D., Mussbacher, G.: Development of Telecommunications Standards and Services with the User Requirements Notation. In: Workshop on ITU System Design Languages 2008, Geneva, Switzerland (2008) 2. Armstrong, T.G., Moﬀat, A., Webber, W., Zobel, J.: Improvements That Don’t Add Up: Ad Hoc Retrieval Results Since 1998. In: 18th ACM Conf. on Information and Knowledge Management (CIKM 2009), pp. 601–609. ACM, New York (2009) 3. Berlin, J., Motro, A.: Database Schema Matching Using Machine Learning with Feature Selection. In: Pidduck, A.B., Mylopoulos, J., Woo, C.C., Ozsu, M.T. (eds.) CAiSE 2002. LNCS, vol. 2348, pp. 452–466. Springer, Heidelberg (2002) 4. Chitchyan, R., Rashid, A., Rayson, P., Waters, R.: Semantics-Based Composition for Aspect-Oriented Requirements Engineering. In: Aspect-Oriented Software Development (AOSD 2007), Vancouver, Canada, pp. 36–48 (2007) 5. Choi, N., Song, I., Han, H.: A Survey on Ontology Mapping. SIGMOD Rec. 35(3), 34–41 (2006) 6. Cohen, W., Ravikumar, P., Fienberg, S.: A Comparison of String Metrics for Matching Names and Records. In: Workshop on Data Cleaning and Object Consolidation at the Int. Conf. on Knowledge Discovery and Data Mining (KDD), Washington, USA (2003) 7. Cottenier, T., van den Berg, A., Elrad, T.: Joinpoint Inference from Behavioral Speciﬁcation to Implementation. In: Ernst, E. (ed.) ECOOP 2007. LNCS, vol. 4609, pp. 476–500. Springer, Heidelberg (2007) 8. Do, H.H., Melnik, S., Rahm, E.: Comparison of Schema Matching Evaluations. In: Chaudhri, A.B., Jeckle, M., Rahm, E., Unland, R. (eds.) NODe-WS 2002. LNCS, vol. 2593, pp. 221–237. Springer, Heidelberg (2003) 9. DOLCE, http://www.loa-cnr.it/DOLCE.html 10. H¨ olzl, M., Knapp, A., Zhang, G.: Modeling the Car Crash Crisis Management System Using HiLA. In: Katz, S., Mezini, M., Kienzle, J. (eds.) Transactions on Aspect-Oriented Software Development VII. LNCS, vol. 6210, pp. 234–271. Springer, Heidelberg (2010) 11. ITU-T – International Telecommunication Union: Recommendation Z.151, User Requirements Notation (URN) – Language deﬁnition, Geneva, Switzerland (November 2008), http://www.itu.int/rec/T-REC-Z.151/en 12. jUCMNav, version 4.3.0 (2010), http://jucmnav.softwareengineering.ca/jucmnav/ 13. Kang, K.C., Cohen, S.G., Hess, J.A., Novak, W.E., Peterson, A.S.: Feature-oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR021, SEI, Carnegie-Mellon University, USA (November 1990) 14. Klein, J., H´elou¨et, L., J´ez´equel, J.M.: Semantic-based Weaving of Scenarios. In: Conf. on Aspect-Oriented Software Development (AOSD 2006), Bonn, Germany, pp. 27–38 (2006)

256

G. Mussbacher, D. Barone, and D. Amyot

15. Koppen, C., Stoerzer, M.: Pcdiﬀ: Attacking the Fragile Pointcut Problem. In: First European Interactive Work. on Aspects in Software (EIWAS 2004), Berlin, Germany (2004) 16. Mussbacher, G., Amyot, D.: Extending the user requirements notation with aspectoriented concepts. In: Reed, R., Bilgic, A., Gotzhein, R. (eds.) SDL 2009. LNCS, vol. 5719, pp. 115–132. Springer, Heidelberg (2009) 17. Mussbacher, G., Amyot, D., Whittle, J.: Refactoring-Safe Modeling of AspectOriented Scenarios. In: Sch¨ urr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 286–300. Springer, Heidelberg (2009) 18. Oliveira, K., Breitman, K., Oliveira, T.: A Flexible Strategy-Based Model Comparison Approach: Bridging the Syntactic and Semantic Gap. Journal of Universal Computer Science 15(11), 2225–2253 (2009) 19. Pourshahid, A., Mussbacher, G., Amyot, D., Weiss, M.: Toward an Aspect-Oriented Framework for Business Process Improvement. International Journal of Electronic Business (IJEB) 8(3), 233–259 (2010) 20. Rahm, E., Bernstein, P.: A Survey of Approaches to Automatic Schema Matching. The VLDB Journal 10(4), 334–350 (2001) 21. Reddy, Y.R., Ghosh, S., France, R.B., Straw, G., Bieman, J.M., McEachen, N., Song, E., Georg, G.: Directives for Composing Aspect-Oriented Design Class Models. In: Rashid, A., Liu, Y. (eds.) Transactions on Aspect-Oriented Software Development I. LNCS, vol. 3880, pp. 75–105. Springer, Heidelberg (2006) 22. Savoy, J., Dolamic, L.: How Eﬀective is Google’s Translation Service in Search? Communications of the ACM 52(10), 139–143 (2009) 23. Schauerhuber, A., Schwinger, W., Kapsammer, E., Retschitzegger, W., Wimmer, M., Kappel, G.: A Survey on Aspect-Oriented Modeling Approaches, Technical Report, Vienna University of Technology, Austria (October 2007) 24. Shvaiko, P., Euzenat, J.: A Survey of Schema-based Matching Approaches. Journal on Data Semantics IV, 146–171 (2005) 25. Tarr, P., Ossher, H., Harrison, W., Sutton Jr., S.M.: N Degrees of Separation: Multidimensional Separation of Concerns. In: 21st International Conference on Software Engineering (ICSE 1999), Los Angeles, California, USA, pp. 107–119 (1999) 26. URN Virtual Library, http://www.usecasemaps.org/pub

Author Index

Jugel, Uwe

Albinet, Arnaud 209 Amyot, Daniel 221, 241 Anssi, Saoussen 209

Kathayat, Surya Bahadur Kemmann, S¨ oren 193 Khendek, Ferhat 124 Kraas, Alexander 108 Kr¨ amer, Marc 1 Kuhn, Thomas 193

Barone, Daniele 241 Becker, Philipp 1 Bræk, Rolv 36 Braun, Tobias 56 Brumbulli, Mihal 144

Fischer, Joachim Floch, Jacqueline

Preußner, Andr´e

91

156

Rodr´ıguez-Cayetano, Manuel

144 18

Salehi, Pejman 124 Shaikh, Asadullah 173

Genon, Nicolas 221 G´erard, S´ebastien 209 Gotzhein, Reinhard 56 Grabowski, Jens 91 Hamou-Lhadj, Abdelwahab Heymans, Patrick 221

36

Memon, Nasrullah 173 Mussbacher, Gunter 241

Carrez, Cyril 18 Colombo, Pietro 124 Dahman, Waﬁ

156

Terrier, Fran¸cois 209 Trapp, Mario 193 124

Wiebel, Matthias 56 Wiil, Uﬀe Kock 173

72