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

103 downloads 989 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 Classification (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, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific 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 Scientific 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, specification 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ët 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ècnia de Catalunya, Spain Pragmadev, France ´ Ecole de Technologie Supérieure, University of Quebec, Canada University of Kaiserslautern, Germany Universit¨ at Göttingen, 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 Kristoffersen 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öttingen, 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öttingen, 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 Specification and Generation of Executable Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wafi Dahman and Jens Grabowski

91

SDL Language Profiles The SDL-UML Profile Revisited . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alexander Kraas

108

Code Generation and Model Transformations A Model Driven Approach for AMF Configuration 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é Preußner

156

X

Table of Contents

Verification and Analysis UOST: UML/OCL Aggressive Slicing Technique for Efficient Verification of Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Asadullah Shaikh, Uffe 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ébastien Gérard, Arnaud Albinet, and Fran¸cois Terrier

209

User Requirements Notation Analysing the Cognitive Effectiveness 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 Specification and Description Language, supports developing systems in a modular and hierarchical way, based on structural type definitions and their instantiations. Also, reuse is supported by the possibility to define collections of type definitions, e.g., as SDL packages, that can be used in different 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 definition 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 benefits of packages for the development of complex systems and system versioning, type definitions 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 definitions 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 different platforms and scenarios. Keywords: SDL, MDD, Modules, Components, Interfaces, Packages, Tool Support.

1

Introduction

Developing systems with SDL, ITU’s Specification 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 refined iteratively, becoming more complex with every step. During this refinement process, new structures, type definitions, and functionalities are added and encapsulated in various types of SDLs structural units on different 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 defined, 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 sufficient. 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 specifications tend to become utterly complex over time, an observation that is not limited to SDL. The effect is intensified with a growing number of structural units contained in a system, and the dependencies among these units. This renders system development difficult, 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 different units with various dependencies that have become difficult 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 different packages by hand. If MacZ is modified during further development, and packages are added or removed, all SDL systems using MacZ must be updated as well. Second, although SDL specifications are intended to be platform-independent, it can still be necessary to have different specifications for different 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 files. One possibility to overcome this problem is to keep one SDL system per configuration (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 specification whenever code for a different 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 specifications in a way that they can be exchanged against each other can be done in different 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 different MAC protocol specifications Fig. 2. Several SDL specifications 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 different exchangeable specifications that may be instantiated by the mac block from the system in Fig. 2(a). In Fig. 2(b), all MAC layer specifications 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 specified 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 specifications, the package is referenced in the system diagram (Fig. 2(a)). The currently used specification is chosen by instantiating the appropriate block type, which is myMac1 in the given example. The other possibility to organize different specifications is shown in Fig. 3. Here, we show how a system is organized and prepared for different MAC layers using one SDL package per exchangeable specification. As shown, every specification is identified 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 defined 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 definition of block type MAC. Summing up, both approaches have advantages and disadvantages: In the first approach, the SDL package gives an overview over the existing exchangeable specifications and the interface is only specified once. Also, several of the specified block types can be instantiated at the same time in one system. Here, the complete dependencies of all available specifications 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 specification. This allows SDL packages to be smaller and have a clearer structure. Even though both approaches allow multiple developers to work concurrently


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


MAC

g7

SIGNALLIST Mac2Env=(MacOutSignals);

(Env2Mac)

d (Mac2Env)

(a) Communication architecture, adapted (b) Common interface for all MAC layers to one specification 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


(c) Specification of myMac1


MAC


(d) Specification of myMacSimulation

Fig. 3. Single specification per package, basis for our SDL module concept

on different exchangeable specifications, we favor the second approach, because SDL specifications may be in a syntactically inconsistent state while developers are working on them. As a result, using the first approach means that none of the other specifications 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 specification is included in its own SDL package.

3

Related Work

According to the SDL standard [1] and a common SDL text book [2], we identified 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 specification. Both tasks require adding the intended packages to the organizer, and updating all instantiated type names to the new unit type

6


names specified 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-specific [3] keyword /*#include ...*/, it is possible to include additional PR files 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 file and thus reports non-existing errors like unfulfilled dependencies. As a side-effect, this can lead to multiple occurrences of the same package definition 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 specified 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 specific type. Although all micro protocols of the same type have a defined 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 specific versions that are needed for the build process. Maven reads its configuration file, fetches all required projects, builds them and links them together. For SDL, a tool with similar functionality as Maven regarding different projects and versions, paired with a defined interface of the subprojects conforming to the SDL standard, integrated in tools like IBM Rational Tau, and supporting splitting work to different 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 define an SDL module interface as a minimal structural SDL unit that contains SDL type definitions 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 fulfill to provide the same interface. An SDL module interface is syntactically complete and provides minimal SDL specifications for all included type definitions. A minimal specification defines a name and interface for each included type definition, 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.


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, specified 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 specification 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 defined 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 iff the SDL module contains a structural unit of the same type as the interface and this unit provides specifications for all type definitions included in the interface. As a result, different 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 figure, we have some structural unit and their dependency relations. On the right side, we have identified 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 figure, 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


Fig. 4. Exemplary dependency graph for some SDL units

Following the definition, an SDL system could be defined 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 define an SDL module to be minimal for a given SDL module interface iff 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 definition 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 definition of minimal SDL modules avoids having multiple structural units in a single SDL module that comply to different 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


9

no functionally complete SDL specifications 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 specification parts and can therefore concentrate on his part. As a positive side effect, 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


simulation environment for a single SDL module, but for the whole SDL module interface. Different 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 files as well as on all files following SDLs Common Interchange Format (CIF) specification [9], and is therefore independent of SDL development environments. Often, these development environments provide some kind of export functionality to produce PR or CIF files out of the SDL-GR specifications, 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 file, optionally with included CIF annotations, that contains a system specification and its dependent packages, together with a set of mapping instructions contained in a separate configuration file. The mapping instructions specify which modules should be replaced and in which PR files the new modules can be found. As a result, a new PR file 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 file, a recursive process begins where the dependencies of all major SDL units (system, packages) are identified 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 configuration file are applied to this graph to perform the substitution of SDL modules contained in this graph. Configuration files follow a naming convention that allows us to have a bijective mapping between SDL-PR file and configuration file. Each configuration file may include an arbitrary number of so-called mapping targets. Mapping targets are named sets of mapping instructions. They can be used to define different mappings for the same SDL system, and allow us to keep mappings for different 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


11

Listing 1.2. System configuration 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 final 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 configuration looks like and how the tool works with a given configuration. For better maintainability, we have defined three configuration levels: system-wide, user-wide and SDL module-specific. System-wide configuration is maintained by the computer system administrator and has the lowest precedence. User-wide configuration is maintained by the developer, and is located in his or her home directory. The SDL module-specific configuration is maintained by the developer of an SDL module and has the highest precedence. The configuration files are written in XML notation for ease of use and flexibility. In List. 1.2, we show a configuration file that can be used for the routing protocol example in Fig. 5. The mapping between a PR file and the respective configuration file is done by following a naming convention, where the name of the configuration file must be «pr-filename».cfg. The first line of the configuration file is for compliance to XML specifications. 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 specifies the replacement of a single SDL module.

12


Listing 1.3. MAC layer configuration 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 configuration sections, Global and Mapping: Global: Currently we support two different source types in the Global section, file and svn. Each entry must have at least three attributes: name, type and src. The name attribute identifies the source location and must be unique for the configuration file, but can override entries from user-wide or system-wide configuration files. The type attribute specifies the source type, e.g., file or svn, and src specifies the location of the files. For version control types like svn (subversion [11]), we have defined specific 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 specifies its name with the attribute target. There may be at most one unnamed mapping section in a config file, 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 specified, the default mapping is used, else the default mapping is inherited and specialized by the specified 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 specified in the Global section. Additionally, an entry can overwrite specific attributes of the src definition. An example for this is shown in line 12 of List. 1.2, where another revision and branch are specified 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.


13

The complete MAC layer configuration 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 file as shown in line 9. The substitute() method first 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 config file (line 16). All packages that will be replaced are then processed in the loop starting at line 20. Here, we first 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 file (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 file where no substitutions are necessary, e.g., because there is no config file for this PR file. 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 finished. 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 file after the substitute() call from the main() method is finished. 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 configuration given in List. 1.2, we get the system shown in Fig. 6 (b). Here, the three placeholder packages were replaced with existing, fully specified 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 configuration 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 specification. The SDL module concept allows developers to concentrate on specific 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 flexibility 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 specific 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


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 define 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 definitions as virtual to specialize or redefine them later, which could be seen as some kind of interface definition. 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 definitions with a defined interface in one package, inherit from it, and just add redefinitions 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 different design layers. Also, we consider adding an interface checker to the tool that can compare the interface specifications of different 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 specification to ensure that all required specifications 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 file 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, Specification 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 Cliffs (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/


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 Configurable 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 find 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 find that a coarse-grained description of a composition can be sufficient 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 efficient 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 find 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 specifications and is time-consuming. This makes them inadequate for runtime where discovery and assembly should be performed in a time-effective 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 defines 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 specified 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 notification services and ambient intelligence. In the rest

20

J. Floch and C. Carrez

of this paper, we simply use the term service, and we define 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 specifies 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 define which interface takes the initiative to start a co-operation: interfaces are classified 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


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 flows 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 modified 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 defines 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 benefit of modelling collaboration between interfaces in separate diagrams is that the specification 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 specified using UML state machines, with message passing semantics. Triggers and effects 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


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 specified using state machines, with message passing semantics. Ports on which messages are sent or received must be specified. 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 specification of a service (defining 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 different stakeholders can contribute to the different activities in service development. This means that service roles in a service might be designed by different parties, and components developed by independent parties. In order to provide such flexibility, 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 specifications, 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 different 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


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 simplified 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 definition of safety properties of Alpern et al. [7], i.e., “bad things that should never happen,” we define a service composition to be safe if no logical errors occur during the collaboration between service roles. We restrict

24


our validation approach to the avoidance and detection of logical interaction errors. Conflicting non-functional requirements or physical errors (e.g., signal loss, network and node failure) are not considered. We define three kinds of violation of safety properties: – An unspecified signal reception occurs when an interface receives a signal that is not specified 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 different 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. Unspecified 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 unspecified 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 confirmation, i.e., the Traveller waits for the Hotel to confirm 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 specification 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 first 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.


25

We say that two interfaces are compatible when their interactions do not lead to any unspecified 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 conflicting 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. Unspecified signal reception or improper termination might occur, as the interface behaviour is not predictable; – Conflicting 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. Conflicting behaviours

The enforcement of well-formedness rules out special cases of behaviour, allowing a simplified 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


roles if the interfaces truly represent the behaviours of the service roles. To ensure compliancy between service roles and the specified interfaces, we apply the projection technique of [9] to service roles, and check that extracted behaviours are equivalent to the specified interfaces. Checking the compliancy of service roles and the specified 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 first 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 differentiation 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 different


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 first 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 unspecified signal reception. This happens when the service roles do not sequence their interfaces consistently. The second case

28


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 first 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 first 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 exemplified 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 first message while iResPlane has not started yet. In (b), Traveller differs 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


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

configuration 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 configuration 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 specifications than the description of interface dependencies that we propose to exploit at runtime. At a first 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 different 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 confirmation of a room before confirming the seat, while the TravelAgency might want the opposite confirmation (first the seat, then the room). In (b),

30


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 finding 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 specification 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 first analysed to find 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 define three interfaces that we exploit below in different service role specifications. 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 finished), 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 specifications, they formalize collaborations using cTLA (compositional Temporal Logic of Actions) [17]. The approach allows for incremental verification of systems. The authors solely address verification at design time.

32


Proving the absence of deadlock when assembling components is a difficult 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 configurations that possibly will not deadlock. Concerning the runtime verification 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 predefined specification. 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 specification 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 differs 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 configurations. 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 flexible, 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 first 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 first 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 first concern on friendliness, some of the main conclusions from this experiment are:


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 effort 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 refine 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


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 Specification. 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 Cliffs (1991) 12. Shiaa, M.M. (ed.): SIMS Deliverable D6.5, Trial Services, final 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 - final 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: Efficient Run-Time Verification of Web Service Compositions. In: Lee, D., Lopes, A., Poetzsch-Heffter, A. (eds.) FMOODS 2009. LNCS, vol. 5522, pp. 26–40. Springer, Heidelberg (2009) 20. Dong, W., Leucker, M., Schallhart, C.: Impartial Anticipation in RuntimeVerification. 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, Verification and Automated Composition of Web Services. In: Proceedings of the 11th International Conference on World Wide Web, pp. 77–88. ACM, New York (2002)


35

22. Ding, J., Zhu, H., Zhu, H., Li, Q.: Formal Modeling and Verifications 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 definitions is well established both in the domain of embedded reactive systems and service-oriented (business) systems. The problem has been to define the global behavior with sufficient, 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 flows are localized to the roles participating in collaborations and another where the flows are not localized and thus more abstract. We propose a novel approach to map the flow-global choreography to a flow-localized choreography and further to distributed component behaviors (orchestrations) with well-defined 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 flexibility 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 define 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 define and analyze the overall service behavior, whereas the orchestration is needed to completely define 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 sufficiently 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 defining 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 define a structure of participating roles where collaborations taking place among the roles may be represented as collaboration uses referring to separately defined 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 definition 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 define 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 defined by an activity diagram connecting actions by flows 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 first step in the formalization of requirements. – Flow-localized choreography is used to define global behavior in sufficient detail to allow extensive analysis and to automatically synthesize the behavior of component types providing orchestration. The behavior is defined by an activity diagram connecting actions, that either represent the behavior of a collaboration or a local activity, by flows that are localized to the roles. – Component types define the local activity flow, the orchestration, of each component. They are derived using a projection of the flow-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 flows 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 defined separately using the “swim-lane” like notation for UML activity diagrams, put into libraries, and then composed in different ways. The Arctis tool provides extensive support on the flow-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 flow-global choreography, the mapping to a flow-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 differs from the global behavior specified in the choreography, we say there is a realizability problem. It may for instance happen that messages are received in a different order than specified or that additional messages are needed to ensure the specified 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


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, flow-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 different places of interest. They use GPS enabled hand held devices and may create profiles specifying their preferences and interests. Based on their locations and profile information, the users participate in different groups and social activities. For instance, when a user is trying to find 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 different 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 finally, the cgs role (city guide manager) that provides a guided tour to the users. A number of collaborations uses represent sub-services that are defined 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


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 finished. – Proximity detector checks if the users (using their positions) in a group are within a defined proximity of a POI and initiate Connect poi when this is the case. We assume that the behavior of each of these collaborations is defined 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 flow-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 flow-global choreography defines the desired global execution ordering of collaboration uses in a composite collaboration. For example, the flow-global choreography of the City Guide service is shown in Fig. 4 using UML activity diagrams.


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 defined separately. The called activities are either local to a role called local activities (here the prox. detector and tour manager) or defining 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 defines 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 defined 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 profiling. An action can have all the different 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 flow between two actions connected by streaming pins allows the called activities to interact without being stopped. For example, the streaming flow 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 define and use data in the normal way defined for UML activity diagrams. The particular case of initiative choices are modeled using interruptible regions (denoted by a dashed box) and interrupting flows 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 specified in Fig. 5, but in a distributed realization

42


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 reflects 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.


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 specification of Group quiz service

4

Flow Localization

At the flow-global level we define the intended ordering including streaming pins, interruptible regions and initiative choices. At the flow-localized level we need to ensure the ordering in terms of local flows. In Sect. 4.1 and 4.2, we first consider direct flows 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 final 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 flow-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 flows 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


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 flow 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 flow directly. In the city guide choreography (Fig. 4) there is a natural strong sequence between most activities. – Enforced strong sequence: the flow 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 different 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


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 finished with its role in C1, even if messages may still be in transfer so that all roles of C1 are not completely finished. 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 flows that connect to the initiating role of the next collaboration, what we call initiating flows. For the non-initiating roles, the implication of these flows 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 flow 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 specified 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 finishes its role in C1, m2 is always sent after m1. However, if the communication link between

46


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 flow-step and control node may be part of several flow-paths. The intermediate control nodes are localized according to the following rules: 1. Each flow-path from Ci to Cj is first localized to the initiating role of Cj. 2. Find all the flow-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 flow-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


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 flow 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 flow is needed. When the fork node in Fig. 6(h) is localized to A, then we may need to use an interaction flow 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 flows and intermediate control nodes are localized in the same general manner as control flows, explained above. We now classify flows 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 flow is akin to the weak sequencing discussed above and is indicated by the {stream} property on the corresponding responding flow.

48


– 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 flow causes no overlaps and is directly realizable as long as C2 is ready to accept the token from C1. For streaming flows we distinguish two main cases: – Local streaming: the flows 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 flows are local to one role. – Global streaming: a flow that implies communication. This may be problematic and needs careful consideration. As a method guideline global streaming flows should preferably be encapsulated in collaborations. 4.5

Initiative Choice Localization

Fig. 5 defines 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 difficult 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 conflicting 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 flow-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 flow-localized choreography). Fig. 11 illustrates the same using the UML swim-lane style supported by Arctis. In the cases of conflicts, 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 difference, 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


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 flow-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 conflicting 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 flow-localized choreography with all realizability problems resolved, the next step is to derive a local activity flow 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 flow-localized choreography onto the components in the following way: – For each component make a copy of the flow-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


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

– Include all the flows that are completely localized to the component type. These types of flows are called local flows (local initiating and local streaming flows). Note that local actions and control nodes will be associated with such flows. – Flows that cross the component boundary and therefore involve communication are called interaction flows. Such flows 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 flows 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 flows of the collaborations. The component models have local flows representing local control flows and responding flows (denoted by dashed lines) representing flows external to the component. A responding flow may be a simple edge or a complex flow involving external control nodes as well as no-op nodes representing collaborations and local actions where the component is not participating. Responding flows in the group component type are mostly simple responding flows. A responding flow between cp.grp and q.grp specifies 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 flow 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.


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 flows in the Leader component type in Fig. 13 representing flows involving external control nodes as well as no-op nodes that have been removed from the diagram. For example, a responding flow 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 flows 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 flows ending on a collaboration activity. This means that tokens can arrive along the different paths in different order. Each responding path may be shortened and simplified 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 define global behaviors. UML interaction overview diagrams (IOD), or high level MSC diagrams may then be used for flow-global choreography [8]. Compared to the IODs, activity diagrams allow

52


«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 specifications in [9, p. 512], IODs are specialization of activity diagram that show control flow between set of interactions. IODs can define 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, flow final 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 defined by interactions. This has been done in [5], but exactly how to combine the two forms is not fully defined in UML. The realizability problems associated with weak sequencing and initiative choices we have discussed here are the same as those identified 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 benefit 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 specific language called CoSDL to


53

define collaborations. The global behavior specified by the composition of such collaborations modules in CoSDL is at the flow-localized level. CoSDL is aligned to SDL [12]. Use Case Maps can be used for both flow-global and flow-localized choreography [13, 14]. Related work in the embedded systems and web-services domains [18–21] has concentrated on flow-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 flow 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 different 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 flows are localized to praticipating roles [6] which is supported in the Arctis tool [2]. Note that our flow-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 flow-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 classification of realizability problems and some criteria for detecting them at the flow-global level. In this paper we elaborate on localization i.e., how flow-global choreography is mapped to flowlocalized choreography and further to orchestration of distributed component types with external interfaces. We believe the concept of responding flows is novel and that {weak} responding flows provides a new way to identify potential realization problem. This will be addressed in future work.

7

Conclusion

A general approach for the definition of flow-global choreography of services is presented where the global behavior of a service is specified by linking together actions representing collaborative and local behavior. From the flow-global choreography we derive flow-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


Responding flows are introduced to represent flows 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 Cliffs (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.: Unified 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 Specifications. In: Proceedings of the 14th Asia-Pacific 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, Unified Modeling Language 2.1.1 Specification (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 Specification. In: Sherratt, E. (ed.) SAM 2002. LNCS, vol. 2599, pp. 1–20. Springer, Heidelberg (2003) 12. International Telecommunication Union: Recommendation Z.100, Specification 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)


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 Workflows 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., Charfi, 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 Cliffs (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 field-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 configuration aspects of and communication via FlexRay can be specified 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 benefits 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 configurability make FlexRay a complex protocol that has turned out to be difficult 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 Definition Language). A TDL program explicitly specifies 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 specifiy the behaviour of a FlexRay communication controller based on the SDL specifications given in the FlexRay Communication System Protocol Specification [1]. But this specification 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-specific 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 finally 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 Specification 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 specification of the platform-independent model (PIM) is done with SDL as design language and fully covers the system functionalities, still abstracting from platform-specific details. The platform-specific 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 specific supplements for the integration of FlexRay)

platform-specific abstract interfaces. One example for such an interface, called PSSI (platform-specific 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 first 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-specific 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 - RuntimeSpecific 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 field bus with two independent physical channels, especially devised for the needs of the automotive industry [11]. The FlexRay 2.1A protocol specification [1] was developed and published in 2005 by the FlexRay Consortium. Partners of the FlexRay Consortium, which finished 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).


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 different 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 filter 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 configurable, but fixed 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


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 offset, 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 configurable, but fixed 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 different payload lengths. The frame with ID i+1 has higher priority than the frame with ID i + 3 and is therefore transmitted first. 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.


61

has its own dynamic action point for the same reasons as described for static slots. Different 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 offset is chosen more aggressively than the action point offset 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 configurable message RAM that stores data, status, and configuration information of frames. The message RAM is structured into a set of message buffers of different types:4 • Send buffers are assigned to one specific static or dynamic slot, i.e. one frame ID. If the slot boundary is reached and the assigned send buffer contains data, a corresponding frame with this payload is created and transmitted. Send buffers support two different modes of operation: Single-shot and continuous mode. A buffer configured to work in single-shot mode is cleared after message transmission. In continuous mode, the message remains in the buffer and is resent until it is replaced. • As send buffers, receive buffers are assigned to one specific static or dynamic slot. Receive buffers can also be grouped to form a FIFO buffer. Frames without a corresponding receive buffer are stored in this buffer, if they pass a configurable filter decision. • It is possible to use communication cycle multiplexing for receive, send, and FIFO buffers. This means that a message buffer with configured cycle counter filter is only used if the number of the current communication cycle (i.e., the cycle counter) satisfies the filter constraints. For example, it is possible to configure message buffers for odd or even communication cycles only. This grants the option to preload a send buffer in a cycle where it is not scheduled, or to postpone the reading of a receive buffer 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


The option to preload send buffers and to delay the reading of receive and FIFO buffers 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-specific 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 different hardware platforms, high-level interaction between the PSM and virtual platforms can be specified. Following this idea, the SDL-FlexRay signal interface defines FlexRay-specific 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 defined by the SDLFlexRay interface. Fig. 3 lists a subset of the outgoing signals and a data type used for the reconfiguration of buffers. 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 first 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 reconfiguration of the message buffers (right).

allowed to participate in a startup are called non-coldstarters. When the startup has finished, 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 identifiers (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 effort. Both signals have an Integer parameter to select the associated message buffer 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 buffer 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 five parameters. The first parameter is of type Integer and holds the number of the receive buffer. The

64


second parameter contains the received payload of type Octet_string, followed by a Boolean-flag set in case of an error and the number of the cycle count of this reception. Finally, the fifth parameter gives more details in case of an error occurrence. Buffer Configuration. Since the FlexRay controller needs a set of initial working buffers to be able to integrate a node into a cluster, it is necessary to provide some static configuration parameters. This is done by specifying a so-called Controller Host Interface (CHI ) file, which is included during code generation. Our FlexRay interface also allows the reconfiguration 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 reconfiguration (see Fig. 3). This structure Buffer encapsulates information about the intended transmission mode (single-shot or continuous), buffer type (send or receive), the frame id to be used for messages sent via this buffer and several other configuration parameters. When the configuration has finished or been aborted due to an error, the driver generates the signal FLEXRAY_cfgFinished. As the aforementioned finished -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 different 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 buffered by the SDL-FlexRay Driver. Figure 4 shows the data structures of the driver. Arrays buffering data for the SDL system, such as bufferSendFinished, are colored white, while information for the CC are held in the arrays colored black (e.g. bufferSendPending). For every buffer used in the CC, we implemented a corresponding buffer in the driver. The buffered information is kept until the environment polls it for the generation of new signals or, respectively, the message buffers of the controller are ready to receive new information. This buffer 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 benefits and full operativeness of the SDL-FlexRay interface, we now present a functionally complex application scenario that we have


65

% ! " # #

" !%#

" # $#

" # ! $#

$!#

Fig. 4. The SEnF part of the SDL-FlexRay interface embedded in the runtime environment (white: buffers to hold information for the SDL-System, black: buffers 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 different 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 Specification 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 Specification [18,19].

66


On design level, we have specified 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 specification. 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 buffers are dynamically reconfigured, followed by another message exchange using static slots. This scenario is first 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 configured the CCs using Controller Host Interface (CHI) files with different buffer configurations for each node. In these files, the number of static slots is set to 40 each with a length of 44 macroticks. The length of the dynamic segment is configured 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 configured 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 buffer configuration of the sender uses buffer 4 to transmit messages with frame ID 41 in the first dynamic slot on channel A only. After 50 messages have been transmitted, the send buffer is reconfigured. 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 configuration of the payload length for the static segment. Followed by the reconfiguration, 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 first message. It waits for five 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 buffer it has been assigned to (Bnn).6 Buffer 4 (normal) and 5 (FIFO) are configured for reception. In the first run of the scenario, the 5 6

Note that this is also part of the configuration and therefore scenario-specific. Every buffer is assigned a frame ID and thus a slot number. Messages with a matching ID are stored in or sent from the corresponding buffer.


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 buffer reconfiguration

68


! "

# $ ! "

Fig. 7. Configuration of the message buffers. Buffer 4 starts sending with ID 41 (black arrow). After its reconfiguration (grey) it sends with ID 10 (dashed arrow). Receiving buffers are outlined with dashes.

node receives 50 messages with the frame ID 41. Since there is no receive buffer associated with this ID, these messages are stored in the FIFO buffer, consisting of buffers 5, 6, and 7 (see Fig. 7). After the 50th message, in cycle 39, we reconfigure the send buffer. The next message is received in cycle 43 and stored in buffer 4. This delay of four cycles corresponds to 12 ms and is a result of the reconfiguration 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 first 50 messages are not received. After reconfiguration, the send buffer 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 different oscillators driving the clocks of host and CC and the continuous 7

For example, consider data resulting from a periodic sampling.


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 defined a comprehensive abstract signal interface enabling high-level interaction with virtual FlexRay environments, which can be applied to specify the platformspecific model (PSM). At implementation level, we have extended our tool chain

70


to support the automatic interfacing of SDL systems with FlexRay hardware. A functionally complex application scenario has demonstrated the benefits 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 difficult 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 confidence in simulation results. To extend this idea to FlexRay, we are currently devising a simulation model that is sufficiently detailed to express real-time capabilities, configurations, 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 Specification 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: Specification 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 Definition 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/


71

10. Fliege, I., Grammes, R., Weber, C.: ConTraST - A Configurable 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 Specification 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 Specification 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 specification 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 difference among them is the criterion used for selecting the process to be executed. Different CPU scheduling algorithms have different 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 specification techniques, like the Specification 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 specified 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 difference 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 classified into different groups (because they have different response time requirements and so might have different 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 fixed-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]. Different CPU scheduling algorithms have different 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 definition). The criteria to be used in selecting an algorithm are often defined in terms of performance evaluation parameters. Once the selection criteria have been defined, 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 modifies the system state to reflect 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 specification 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 find 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 defined 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 specified using random values obtained from a statistical distribution. These shortcomings have lead to the development of a CPU scheduler simulator specified 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: first come first served (FCFS), shortest job first (SJF), shortest remaining time first (SRTF), round robin (RR) and priority based (priorities) – support for real-time algorithms: Rate Monotonic Scheduling (RMS) and early deadline first (EDF) – support for multilevel queue algorithms, where the number of queues, queue algorithm and queue priority are configurable – generation of Gantt chart of process events during simulation – step by step or continuous simulation


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 defined 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) identifier 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 configuration of a simulation. Interactions during the configuration of a simulation have to be synchronous because the simulator must confirm to its environment if every configuration parameter is correct or not. For example, arrival times of processes must be greater or equal to zero. If a configuration parameter is incorrect, the configuration of the simulation is aborted and the simulator returns to the initial state (no simulation is configured). 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 defined signals. The input signals of the SDL system are used for simulation configuration (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 configuration 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 fixed-number port

76


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 specification. This program runs continuously, listening for requests from the user interfaces of different 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 configuration 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 confirmation for this request (which includes the simulation identifier 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 identifier). endQueueConfig c signal is used to indicate end of queues configuration. If the algorithm is not multiqueue or if the endQueueConfig c signal is received, the simulator responds with a readySignal to confirm the configuration of queue(s). After that, context save and load times are specified (signal contextTimes c) and confirmed by the simulator. After this confirmation has been sent the queues of the system are configured 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 specified by a processData c signal (and confirmed with a readySignal one). End of process configuration is indicated with a dataEnd c signal. After the process configuration phase has been finished, 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 configuration phase) the simulator sends to the environment signals of type sendList with the contents of every queue modified by a simulation event, and a printEvent signal with event details (kind of event, process identifier and period of the process involved). Simulation end is notified 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.


MSC CPUSchedulerOverview−configSim environment

CPUScheduler

initial newScheduler (IPAddress, port, language)

schedulerReady (IP, port, simId)

alt

1

simulationConfig_c (MultiQueue, verboseMode, stepByStepMode, simId)

2

loop 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 configuration scenario

77

78


MSC CPUSchedulerOverview−configProcess environment

CPUScheduler

simulationConfigured 1

loop 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 configuration 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 specification: 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 different TCP port number and that number has to be sent to its connected GUI, using auxiliary files 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


79

MSC CPUSchedulerOverview_running environment

CPUScheduler

simulationReadyToStart

opt

1

loop

2 3

loop 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 loop

processStatistic

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

2 2 1 1

loop 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 different user interfaces to the corresponding masterScheduler processes.

80


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 identifier (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 configuration 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 configuration, inter-queues algorithm and access control of the variables shared by the slaveScheduler processes.


81

Initially this process receives signals with simulation configuration 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 finishing configuration 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 offspring slaveScheduler processes (arrival queue, terminated queue, idle CPU time, clock, etc.). Shared variables are defined in the masterScheduler process and accessed by using exported procedures (findArrivals, execProcess, interruptProcess, terminateProcess, etc.) called by slaveScheduler processes. When the simulation has finished (all the slaveScheduler processes have notified 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 finding 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 specific procedures (fcfs, sjf, srtf, rr, priorities, rms and edf ). The appropriate algorithm specific procedure is called from the slaveScheduler process depending on the simulation configuration. The genericAlgorithm Procedure. The specification 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


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 specific, and are described in the algorithm specific procedures. Algorithm Specific Procedures. Algorithm specific procedures are in charge of tasks specific to the simple algorithm selected (tasks included in the transition from the checkingExec state to the checkingArrivals or executingProc states). These procedures inherit the specification of the algorithm-independent tasks from the genericAlgorithm procedure. An example of this kind of procedures is fcfs, whose specification 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


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 find 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 different 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 configuration (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 different scenarios to students, and for studying the suitability of every algorithm for scheduling different 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 fulfillment of these requirements by the different 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. Different 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.


4

85

The CPU Scheduler Simulator Graphical User Interface

The executable program generated from the SDL specification 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 definition 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


The main tasks of the graphical user interface (GUI) are the translation of user requests for configuration 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 specific message – data file loaded: shows the name of the file 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 specific 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 file,

Fig. 8. tkCPUSched system queues window


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 file). An example of a Gantt chart plotted during the simulation can be seen in Fig. 9. This figure shows different 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 specification of the simulator instead of developing it using a programming language has several advantages. First, an SDL specification 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 specification does not have to include low-level details usually required in a programming language. Moreover, flow charts are usually used to describe algorithm or protocol behavior, and these charts can be easily translated into a high-level SDL specification that can be turned into a complete specification. In fact, a simplified version of the SDL specification 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


simplified 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 redefined types. These concepts are useful to obtain well-structured and reusable specifications, but their use produces specifications based on several diagrams, more difficult to interpret by students. In our experience, the use of SDL for the specification of scheduling algorithms helps students to understand how algorithms work internally, as the specification describes in detail the algorithm behavior in every possible scenario. This specification is formal unlike natural language based specifications (usually used in operating systems text books), and it is simpler than a programming language based equivalent specification. 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 difficult 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 difficult to understand and debug a programming language source code than the equivalent SDL specification. 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 specified 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 specification 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 specification errors in many other kinds of systems (where the signal must be sent to an specific 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 specification 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


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 first 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 specified at the process (or process type) level. If non-exported procedures are defined at an upper level, the exported procedure definition (specified 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 definition is specified 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 different 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 different 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 definition 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 definition, and the automatic generation of the parser and lexical analyzer from the new grammar definition. This way, the graphical user interface can be easily adapted to support simulators generated by different SDL case tools or based on different 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 modified 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


6. International Telecommunication Union: Recommendation Z.100, Specification 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 Cliffs (2005) 11. Tanenbaum, A.S., Woodhull, A.S.: Operating Systems: Design and Implementation. Prentice-Hall International, Englewood Cliffs (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 Wafi 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 profile for the Unified Modeling Language (UML), which allows an efficient definition of Web service models. Such Web service models allow the generation of the source code and the corresponding platform-specific configuration files necessary in order to run the modelled Web services. The code generation is realised by means of transformation and code generation rules defined 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 specific 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 offer also the possibility to generate parts of the source code from UML models [5,6]. In addition, UML offers an extension mechanism, where UML metamodels can be extended to fit the requirements of specific 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 specific models. MDSD concentrates on domain models rather than computation. It focuses on defining a metamodel for a specific 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 Specific Language (DSL), then the model transformation takes place in order to reach the executable source code. MDSD offers possibilities to different 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 define two categories of UML extensions. The first category represents the main extensions needed for any Web service application, while the second category is defined to enable the generation of executable Web services. 2. UP4WS implementation: the definition 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 profile 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 effort during the development process by the simple allocation of the UP4WS stereotypes on a UML model of the service. This finding has been observed during the development and implementation of the library service. We believe that our approach can also improve the quality of the final 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 definition of UP4WS profile, 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 figure 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 Specification 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 flexible extension mechanism. UML profiles can be defined to adapt UML for specific domains. Arlow and Neustadt [5] define a UML profile as“a collection of stereotypes, tagged values, and constraints”. The OMG has standardised many UML profiles to fit different types of systems and technologies, such as UML Profile for Common Object Request Broker Architecture (CORBA) [10]. Figure 2 illustrates a sample UML profile called WidthAndLength shown as a package with «profile» stereotype. The WidthAndLength profile 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 float, 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 five ({length <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 defined 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 define 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 file in a separate directory, but since this partial class has the same namespace as the original class in the original file, 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 first 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 different 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 sufficient 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 benefit 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#-files, three additional class files, and four files needed to setup a valid project, i.e., the C#-assembly info and C#-project XML files. The 80 generated model classes contain between 10 and 200 lines of code. The whole C#-project finally comprises 87 files containing nearly 7000 lines of code in 600kB of text files. Compared to the seven files 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 effort. 7.2

Reduced Types of Errors

Another measurable benefit 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 flaws in the original models. Those problems could usually be fixed 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 Efficiency

Repairing and improving the generator showed one of the drawbacks of our approach. Only the developers of the original template could perform template development efficiently. 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 difficult 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 conflicts in these classes manually by fixing their syntax errors. Such conflicts 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


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 effort. Our case study showed, how code generation can easily combine different 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, efficient, 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 benefits from our generator, but not all could be achieved. While we significantly reduced the lines of code to maintain, we missed to measure or at least estimate the complexity of the remaining template code. The developer efficiency, 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 fix 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 effectively. 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-file 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’ efficiency.

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é, 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


´ 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ć, 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ć, D., Gray, J. (eds.) SLE 2009. LNCS, vol. 5969, pp. 354–373. Springer, Heidelberg (2010)

UOST: UML/OCL Aggressive Slicing Technique for Efficient Verification of Models Asadullah Shaikh, Uffe 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 efficiency of the verification process is being affected. The verification of these models is each time more laborious because of their complex design and size thus prolonging the verification 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 efficiency of the verification 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 affected. We attempt to quantify the speed-up achieved by adding the slicing technique to two different 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, Verification 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 specification 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 final software system. Regrettably, verification 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 efficient verification methods able to cope with the growing difficulties is ever present, and the importance of UML models has increased significantly [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 efficiency 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 verification 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 verification in the sense that it should be possible to assess the property in the original model from the analysis of the partitions. A careful definition of the partition process is needed to ensure this. We focus our discussion on the verification of a specific property: satisfiability, 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 satisfiability [5]. Two different notions of satisfiability can be checked: either weak satisfiability or strong satisfiability. A class diagram is weakly satisfiable 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 satisfiability 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 verifiability 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 satisfiability of the model after partitioning. The technique improves the efficiency of the verification 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 satisfiability. That is, given a model ‘m’, the technique partitions m into m1 , m2 , m3 ,...mn submodels, where m is satisfiable if all m1 , m2 , m3 ,...mn submodels are satisfiable. This slicing technique is called the UML/OCL Slicing Technique (UOST). We provide an experimental evaluation of this technique using a verification 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 efficiency of the verification 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 satisfiability 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 verification 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 defined as OCL invariants. Two different notions of satisfiability will be considered for verification: strong satisfiability and weak satisfiability. A class diagram is weakly satisfiable 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 satisfiability, 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 unsatisfiable in the case of strong satisfiability. Consequently, strong satisfiability requires the existence of an object for each concrete subclass of an abstract class. The proposed approach instantiates objects for verification purposes based on a given class diagram and OCL constraints of the system. A successful verification result ensures that the model complies with the system specifications 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 verifies 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 verified more efficiently. 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 satisfiability, saying that “a class X depends on a class Y ” means that creating an object of class Y creates an obligation that must be satisfied 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


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 flowgraph. 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 defines 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 verified separately. The following procedure is used to compute the clusters: – Compute the constraint support of each invariant. – Keep each constraint in a different cluster. – Select two constraints x and y with non disjoint constraint supports and located in different clusters, and merge those clusters. – Repeat the previous step until all pairs of constraints with non disjoint constraint supports belong to the same cluster.


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 fit 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 flowgraph based on the identification of classes, associations, and generalizations as shown in Fig. 3. We use the concept of a flowgraph to capture the dependencies among model elements. This concept is also used by other slicing approaches [18,14,16]. A flowgraph 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 flowgraph 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


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 differentiate aggregation, composition, and generalized classes from associations in the flowgraph, 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 briefly summarizes the criteria to assign loosely coupled and tightly coupled relationships and Algorithm 1 shows the steps that compute a flowgraph 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 final slices for verifiability. Considering the model Coach where Model M = (Coach, Trolley, Booking Office, Passenger, Ticket, Trip, RegularTrip, VendingMachine, Manager, Employee, SalaryCategory, AdultTicket, and ChildTicket ) and Constraints C = (passengerSize, ticketNumberPositive, and NonNegativeAge). We are supposed to find the legal instances of three invariants, i.e., passengerSize, ticketNumberPositive, and NonNegativeAge.


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 satisfied from similar model elements. Meanwhile, the properties of ticketNumberPositive can be satisfied from different 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 satisfiability, otherwise, the property will not be satisfied. For the cluster of passengerSize and NonNegativeAge, we need classes Coach, Trip, RegularTrip, and Passenger while classes Ticket, BookingOffice, 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 Office, 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 final slices passed to the verification tool for strong satisfiability. The members of a slice are hence defined as follows:

180


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 satisfiability 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 verification 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 ineffective. The non disjoint solution differs from the UOST process (see Fig. 2) in that it works without clustering the model elements, hence making it still possible to improve verification time. The non disjoint solution is defined 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 defined as a tuple (C1 , C2 , m1 , M1 , m2 , M2 ) where:


(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 infinity (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 defined 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 specifies the model entity for which the OCL expression is defined. CL represents the OCL invariants while CLc are the clusters of constraints. The work list is defined as WL which is the union of the constraint support of all constraints in the cluster. – Satisfiability (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 satisfiable. – Unsatisfiability: If there are two or more constraints whose interaction is unsatisfiable, then submodel S is also unsatisfiable. 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 class diagram can be unsatisfiable 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 unsatisfiability 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 unsatisfiable model either contains an unsatisfiable textual or graphical constraint or an unsatisfiable interaction between one or more textual or graphical constraints, i.e., the constraints can be satisfied 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 satisfiable, and it will be called safe. However, cycles where the maximum label ≥ 2 can be unsatisfiable. 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 satisfiable 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-effect free expression which cannot evaluate to the undefined value in OCL (OclUndefined). This means that we do not allow divisions that can cause a division-by-zero or collection operations which are undefined on empty collections like first(). 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, find 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.


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 satisfiable however, invariant projectEmployeeSize is unsatisfiable 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 satisfiable, however, slice 2 is unsatisfiable. The definition of the slicing procedure ensures that the property under verification is unsatisfiable after partitioning because the overall interaction of the model is unsatisfiable. Initially, our non disjoint approach finds the common class in all slices of model (M), i.e., class ‘Employee’. Secondly, the method finds 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


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 satisfiable. 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 unsatisfiable.

4

UOST Implementation in UMLtoCSP

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


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 Verification Time SVT Sliced Verification 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 Verification Time

provides quick results while for larger ones, the tool takes a huge of amount of time. In order to evaluate the efficiency 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 verification time of UMLtoCSP, column TVT is the total verification time of all slices of UMLtoCSP(UOST), and column speedup shows the efficiency 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 satisfiability and Fig. 8 represents the object diagram for s2 in the case of weak satisfiability, 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


Fig. 7. Submodel 1 (s1) object diagram for strong satisfiability

Fig. 8. Submodel 2 (s2) for weak satisfiability

UML/OCL model as a single model and therefore, there will be no difference 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 specification in order to prove that our developed slicing technique is neither tool dependent nor formalism dependent. We compare the verification time of several UML/OCL class


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 Verification 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 defined scope, therefore, in order to analyze the efficiency of verification, the scope is limited to 7. The Alloy analyzer will examine all the examples with up to 7 objects, and try to find 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 efficiency 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




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





189


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

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

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


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%



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

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

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


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%


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 verifiability 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 specific property to verify [17]. The slicing approach was based on disjoint slicing, clustering and the removal of trivially satisfiable 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 verification time.

190


In contrast, this paper presents an aggressive slicing technique which can still preserve the property under verification 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 verification tools. The slicing procedure breaks the original model into submodels (slices) which can be verified independently and where irrelevant information has been abstracted. The definition of the slicing procedure ensures that the property under verification 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 verification 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 affected. 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 defines 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 different 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 specific part of a system’s architecture. The sliced part is used to view higher level specifications. Similar to this approach, a dependency analysis technique is developed which is based on the slicing criteria of an architectural specification 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].


6.3

191

Program Slicing

Program slicing [18, 6] techniques work on the code level, decomposing source code automatically. In this research, a dataflow 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 verification 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 verifiability 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 verification time in order to improve the efficiency of the verification process. The approach accepts a UML/OCL model as input and automatically breaks it into submodels where the overall model is satisfiable if all submodels are satisfiable. 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 verification process, complex models require many resources (such as memory consumption and CPU time), making verification unbearable with existing tools. UOST can help reduce the verification 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 different 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 unsatisfiability to allow the software engineer to focus her attention to the incorrect submodels while ignoring the rest of the model.

192


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 Verification 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 Unsatisfiable 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 Verification 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.: Verification 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 Configuration Management: A case study. In: Workshop of the UML-Group 7. Stafford, 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.: Verification 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 Verification. Journal of Computer Science and Technology 3, 29–39 (1988) 17. Shaikh, A., Claris´ o, R., Wiil, U.K., Memon, N.: Verification-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 effort was put into development of metrics for control flow models. In the embedded systems domain however, domain specific- and data flow languages are commonly applied for model creation. For these languages, existing metrics are not applicable. Domain and project specific quality metrics therefore are informally defined; tracking conformance to these metrics is a manual and effort consuming task. To resolve this situation, we developed INProVE. INProVE is a model-based framework that supports definition of quality metrics in an intuitive, yet formal notion. It provides automated evaluation of design models through its indicators. Applied in different industry projects to complex models, INProVE has proven its applicability for quality assessment of data flow-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 specific 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 specific 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 sufficient 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 different; it describes how a system is structured. Failing in internal quality has no direct effect 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 affect for example future portability, maintainability, and reliability of developed systems. Over time, undetected problems with internal quality will grow and have significant 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 define 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 specific standard quality metrics, such as coupling and cohesion of components are defined [1]. These metrics provide some insights into model quality, but never address company-specific 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]) define quality characteristics, and therefore provide guidelines for setting up quality goals. However, concrete attributes that measure quality are omitted in standards; these are company specific and need to be defined individually. Therefore, tools and frameworks that analyze internal quality attributes need to be customizable to support company and product specific metrics. Software architects must be able to formulate software quality indicators that match architecture guidelines. Predefined 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” fixes, 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 defined quality metrics automatically without any manual effort 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 defines 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 differences to INProVE. For this reason, we divide related approaches into two categories: The first 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 first category is the ATAM method defined by SEI [4]. Based on a systematic definition of relevant quality attributes by means of utility trees, customized scenarios are defined for checking whether or not software architectures fulfill 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-defined 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 defined 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 predefined 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 predefined 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


All of the aforementioned tools have in common that they check models against predefined or customizable guidelines. For meaningful quality evaluation, customizable combination and interpretation of measurement results is missing, which prevents efficient integration of company specific quality guidelines. In addition, we notice that guidelines and tools are language specific. As a result, there are no agreed quality metrics available for less widespread languages; a lack of configurability prevents adaptation of existing tools to new languages. Guidelines and techniques without tool support require considerable effort 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 define 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 define 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 first 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 define 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


197

conserve expert knowledge. An example anti-pattern is the following, which defines that an interface size of a component must not exceed the value of 20: Error: Component.portCount > 20 – Conditional patterns: Sometimes, counterexamples are too specific 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 define 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 difficult to find 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 predefined indicators is not as relevant to them as the ability to create their own, domain-specific set of indicators, which includes quality attributes important for one specific setting. Custom quality indicators therefore support modeling of domain-specific 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 flow 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 flow based languages are based on the concept of communicating blocks with links between them that represent data flow. Sharing quality guidelines between similar languages therefore makes sense.

198


Therefore, INProVE defines intermediate meta models that represent core features of modeling languages. Indicators operate on these meta models. A generic meta model for data flow languages defines ports, blocks, block types, flows, and composite structures. Features of concrete modeling languages map to these models to a certain degree. Storage of additional features is permitted through definition 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 specific 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 specific company or domain. Quality indicators may be used for every model, that conforms at least to their required meta model.


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 classification (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 classification transformation. Currently two types of measurement transformations are implemented: taking the value of defined model feature(s), or counting occurrences of elements into a value. Classification 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 classification 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 flow 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 classification mapping indicates that the model has a flaw based on that value. During the three stages, our framework permits different 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


Fig. 3. More complex indicator processing a model

4.2

Pattern Searching

As described before, the specification of search patterns is an intuitive way of representing expert knowledge. For this reason, INProVE provides the opportunity to define indicators based on patterns. Pattern searching is a specialized counting, and therefore a measurement operation. It counts the appearance of a specific 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 identification of pass connections, which are connections in data flow 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 different 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 flaw.


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


number of inports and outports of a model element often does not reflect 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 first step of the created inference pipeline is the fuzzification 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 difference 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 fuzzified 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 define 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, defuzzification 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 fulfilled. The information added through value-to-value transformations is the combination function itself. Thus, only one function has to be defined to design a functionally combined indicator that fulfills 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 first 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


203

Fig. 7. A complex modular indicator

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

Indicator Development

Indicators represent and formalize company specific modeling guidelines. They form a repository that contains domain specific 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 definition of pattern matching and logical inference. A graphical domain specific language front end that supports intuitive definition 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


– 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 different 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 offering any benefit. – Block Count: This indicator tracks whether the direct block count within one subsystem is within defined 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 affects 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-specific 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 confidential. INProVE is the result of experience made in various assessments targeting data flow-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 modified, extended and some have been omitted for this evaluation. As different as the models and domains were, so was the processing time of the indicators. The assessment of the largest model with


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 offered a predefined set of basic indicators, which were comparable to standard code metrics like interface size and not project or domain specific. Although delivering valuable information, these indicators were not sufficient 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 defined 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 sufficient as a basis for the definition of further indicators. Through indicator combination, domain specific quality indicators were created that provided meaningful benefits to both software developers and architects. Regarding the effectiveness of INProVE, it was an interesting observation that INProVE also found flaws 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 flaws 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


Fig. 9. INProVE runtime example

almost all flaws indicated by INProVE (>90%) were confirmed by manual checks done by the experts. Another point of interest during a model assessment is the evolution of quality over different iterations of the model. Especially for managing a project, with respect to the effort spent on different 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 defined periods of time, model quality changes can be tracked and written to files 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 different views, with different details of information, the guidance on how to find 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 flaws 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 different versions and rapidly evolves over different product versions.


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-specific 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 flow-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 modification 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 difference 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 significant value for model assessments. INProVE finds almost all flaws in a model that a manual inspection would reveal, but in less time and with less effort. 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


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 Stateflow; 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 Spezifikation von MATLAB/Simulink/Stateflow 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].


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.


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.


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.


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 Effectiveness 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, specification, and validation of requirements. Like many visual modelling languages, the concrete graphical syntax of the UCM notation has not been designed taking cognitive effectiveness 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 identified 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 effectiveness, Physics of Notations.

1

Introduction

Visual notations play a critical role in requirements, software, and systems engineering. Yet, when designing notations, most of the effort is commonly spent on defining abstract syntaxes and semantics, whereas the design of effective 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 effectiveness 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, influence on cognitive effectiveness as their content [18]. We believe that cognitive effectiveness 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, specification 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 first proposed as a high-level design notation by Buhr and others in the mid-1990’s [4]. The URN standard1 is defined 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 workflow/scenario modelling languages. Several suggestions for improvement are also highlighted. With these contributions, we hope to influence future versions of the URN standard, especially in terms of addressing current symbol deficits 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 Effectiveness 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 defines 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 field. However, it has a number of important theoretical and practical limitations for this purpose [10,26]: 1) as it is not specifically focused on visual notations, effectiveness guidelines are absent, 2) the dimensions, their empirical foundations, and their metrics are vaguely defined, often leading to misinterpretation, 3) it focuses on very high-level analyses and specific predictions are precluded, which means that it is unfalsifiable and therefore unscientific [31]. For all of these reasons, we believe the CDs framework does not provide a proper scientific 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 offers 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 different in intent and content from CDs, they share most limitations for our purpose, except that SEQUAL offers measurable criteria and effectiveness 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 efficiency’, ‘clarity’, ‘comparability’, and ‘systematic design’. Even if GoM claims to target designers and model users, the principles are defined 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 definition of the symbol types), the Seven Process Modelling Guidelines (7PMG) [23] focus on the

224


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 specifically developed for visual notations. It defines 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 scientific 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 falsifiability [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 different 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 different diagrams. 7. Semantic Transparency: use symbols whose appearance is evocative. 8. Graphic Economy: keep the number of different 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] identified 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 findings 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 definition, summarise the results obtained and give recommendations for improvement.


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 field, states that there must be a 3-way fit 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 effectiveness of the notation. Cognitive Fit theory suggests that instead of trying to design a “one size fits all” language, different representations should be used for different tasks and/or audiences. We evaluate UCM against these two aspects in the following. Expert-Novice Differences. If the audience profile 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 profile is composed of business analysts, requirements engineers and developers who are definitively notation experts. Therefore, analysis results and notation improvements should be proposed with regard to this audience. Differences 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 different 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


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 definitions” have been discarded. Indeed, scenario definition 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].


227

Table 2. Semiotic Clarity – Potential anomalies and UCM results SC Anomalies Symbol Deficit 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 Deficit 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 first 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-offs as the interactions between the principles of the Physics of Notations are complex. Regarding Symbol Excess and Symbol Redundancy, they are insignificant 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 effectively 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 defined as the ease and accuracy with which different symbols can be differentiated 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


variables (see Fig. 2) on which they differ and the size of these differences (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 first step, background differentiation, symbols are distinguished from the medium (e.g., paper or computer screen). A simple but efficient way to optimise background differentiation 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 different 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 influences discriminability. Large symbols take more space on the reader’s field of vision and focus attention. The size of UCM symbols is not specified 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


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 effective visual variables: the human visual system is highly sensitive to variations in colours and it can quickly and accurately distinguish between them [38]. Differences 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 fill a symbol. Texture participates effectively in symbol differentiation. 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, differentiating 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 differentiation is a common but cognitively inefficient way of dealing with excessive graphic complexity (Graphic Economy). Indeed, text processing relies on less efficient (sequential) cognitive processes. To maximise discriminability, symbols should be differentiated using visual variables, so that differences 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 Differentiation 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 differentiated by a “Parent:” string added as a prefix to their name, above their symbol. It could be beneficial to find 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


by redundant coding, i.e., using multiple visual variables to distinguish between them [8]. In practice, to find 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-filled triangle used to indicate traceability links is the sole symbol that benefits from Redundant Coding. This currently poor result suggests that there is room in UCM for very effective 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 different 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/efficiently 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 effective 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 definitively 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 effectively 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 filled bars that share the same analysis and comments that the ORFork and ORJoin, with the exception that the filled 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 refinement than the concept of “relationship”. On the contrary, the TimeOutPath has a specific “zigzag” shape that semantically recalls “error triggers”. Therefore, it seems that this shape is not appropriate to denote the concept of “time out”.


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 influences the (x,y) positioning on the element it connects. Illustrations are available in Fig. 67 in the URN specification 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 offloading. 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


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 defined 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 identified, 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 fits 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 sufficient. 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 effectively the case as Shape differentiates 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 differentiate between symbol types, but it is not sufficient 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%


233

– Texture: is used to distinguish between different 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 different Textures, which makes this variable completely saturated. Two major observations emerge from the analysis of the choices of variables: first, 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 effect on cognitive effectiveness as the amount of information that can be effectively 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 finer grained sub-diagrams (vertical decomposition). In practice, modularisation is achieved by including specific semantic constructs in the notation. However introducing such constructs is not enough: they have to be mapped to visual symbols and, to be effective, diagrammatic conventions for decomposing diagrams need to be defined. – Hierarchical Structuring. When applying vertical decomposition, diagrams are split into a set of finer grained sub-diagrams. This forms a hierarchical structure that is intrinsically linked to the way our mind structures information, and thus required less mental effort 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 effectively 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


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 different levels might cause difficulties). 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 benefit 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 effective 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 affect 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 effective than written in a separate document. Most of the time, visual annotations are embedded into a shape, like the “note” symbol appearing in most


235

of the main modelling languages. This is a common practice that is not supported by any specific 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 specific 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 predefined in the notation. Hence it is completely different 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 predefined 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 effectiveness 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 benefit from reducing its graphic complexity. It could make the case for introducing symbol deficit, i.e., choosing not to provide symbols for some seldom used constructs. Those can still

236


be represented separately using text as suggested in Dual Coding. However, this technique should not be used systematically, as the percentage of symbol deficit 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 effort. 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.


237

– One needs to understand trade-offs when introducing solutions. Many of the principles represent conflicting 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 identified several positive and negative influences between the principles [27], but this also needs to be done at a finer 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 defined, the Physics of Notations does provide the most accomplished theory to analyse and improve the cognitive effectiveness 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 effort 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 afford not to do a good analysis! The theory itself could also benefit from the scrutiny that comes through a standardization process. For instance, ITU-T Recommendation Z.111 [12] provides notations and guidelines for the definition 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 effectiveness 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, different actions can be envisioned. Even if changing a notation that has existed for more than fifteen years and that is now an international standard can be difficult, many of the recommendations mentioned in the above analysis can have a high impact on the cognitive effectiveness 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 deficit 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


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 benefit from an analysis based on the Physics of Notations theory. By doing so, we would optimise the cognitive effectiveness 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 conflict 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émiologie Graphique: Les Diagrammes - Les Réseaux - 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 Specification 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 Cliffs (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 Effectiveness 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)


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 Define 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 Scientific 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 Effectiveness 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 Effectiveness of the UML Family Of Diagrams. In: Proc. of the 1st International Conference on Software Language Engineering (2008)

240


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 Falsification. 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 Modification. 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., Schuff, 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 different 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 defining 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 benefits 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 difficult to localize a concern that appears in many modules of the primary decomposition. This may lead to increased complexity and difficulties 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 define 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 conflicting techniques. While the focus of this paper is on AOM, aspect-oriented development in general may benefit 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 identifies 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 different 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 different levels of abstraction by performing a static control flow analysis to find matching patterns. Patterns are expressed with state machines at the behavioral specification level and then matched against more complex implementation state machines while taking the semantics of the behavioral specification 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 effectiveness. 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 final results (composite matchers). In general, matchers can be characterized along different, 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

–

–

–

– –


extensively used include: Prefix (e.g., int and integer), Suffix (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-specific 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 define 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 specifications 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 different domains, such as the business and education domains in the above example. To enhance structural matching techniques, patterns representing structural equivalences can be identified and kept in a library. As defined in [24], different structural matching techniques have been used in the database community:


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 different 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. Different 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 find 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., coefficients 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 satisfiability (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 satisfiability 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


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] unifies goal-oriented, scenario-based, and aspect-oriented modeling in one framework to support the elicitation, specification, 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 firstclass 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 specifies 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 defined 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 defined. 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 defined 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 briefly 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 fulfill a scenario. OR-forks ( ) and OR-joins ( )


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 satisfied. 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 defined 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 first 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 first 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 classified

248


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 different syntaxes and looks at the meanings of the elements, the approach is classified as Semantics. This is a rather pragmatic differentiation, as it is contentious to classify techniques as syntactic or semantic. Whenever two elements are compared, the matching task needs to find semantic correspondences. Different 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 different 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 different 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


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 significant enough to warrant further investigation. AoURN already employs a hybrid matcher that uses multiple pattern matching techniques from the taxonomy to find 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 first 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 figures 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 differentiated 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


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 specified. E.g., an AoURN responsibility with name R[ˆ2][abc] in the pointcut matches a responsibility in the model with R as the first 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 differences 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


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 offerService 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 find 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 differentiated in AoURN simply by their positions on a path. Note that ontology-based approaches are a kind of approximation-based approach but are classified 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 refined 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 flexible expressions to be defined 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


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

>

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 differences in the match. E.g., an AoURN sequence of responsibilities (R1, R2, R3, R4) in the pointcut matches a slightly different 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.


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-off 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 specification 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


R1 [counter < limit]

initialize

increase

s1 eval( [counter == 5] )

[else]

counter = 0;

e1

counter = counter + 1;

Fig. 7. Matching of Run-time Information

five results of the AoURN trade-off 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 first 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 effort, 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 effort. 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 first need to be defined. 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”


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., Moffat, 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 Specification 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 definition, 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élouët, L., Jézéquel, J.M.: Semantic-based Weaving of Scenarios. In: Conf. on Aspect-Oriented Software Development (AOSD 2006), Bonn, Germany, pp. 27–38 (2006)

256


15. Koppen, C., Stoerzer, M.: Pcdiff: 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 Effective 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é

91

156

Rodr´ıguez-Cayetano, Manuel

144 18

Salehi, Pejman 124 Shaikh, Asadullah 173

Genon, Nicolas 221 Gérard, Sébastien 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, Wafi

156

Terrier, Fran¸cois 209 Trapp, Mario 193 124

Wiebel, Matthias 56 Wiil, Uffe Kock 173

72

System Analysis and Modeling: About Models - SAM 2010

Accelerated Life Models: Modeling and Statistical Analysis

MATLAB: An Analysis, Identification, and Modeling System

Computing System Reliability: Models and Analysis

Dynamic system modeling and control

Simulation Modeling and Analysis

Dynamic system modeling and control

Dynamic System Modeling and Control

Microsoft Excel 2010: Data Analysis and Business Modeling

Microsoft Excel 2010: Data Analysis and Business Modeling

Microsoft Excel 2010: Data Analysis and Business Modeling

Distribution System Modeling and Analysis (Electric Power Engineering Series)

Sam

Models in Software Engineering - MoDELS 2010

Sam

Practical Microsoft Office 2010 (Sam 2010 Compatible Products)

Reliability Modeling, Analysis And Optimization

Adsorption: Theory, Modeling, and Analysis

Manufacturing Systems Modeling and Analysis

Applied dimensional analysis and modeling

Applied Dimensional Analysis and Modeling

Sam

Applied Dimensional Analysis and Modeling

Reliability modeling, analysis and optimization

Precipitation Modeling and Quantitative Analysis

Sam

Sam

System Analysis and Modeling: Language Profiles: 5th International Workshop, SAM 2006, Kaiserslautern, Germany, May 31 - June 2, 2006, Revised Selected

Requirements Analysis and System Design

Analytical System Dynamics: Modeling and Simulation

Embedded System Design: Modeling, Synthesis and Verification

System Analysis and Modeling: About Models - SAM 2010

Accelerated Life Models: Modeling and Statistical Analysis

MATLAB: An Analysis, Identification, and Modeling System

Computing System Reliability: Models and Analysis

Dynamic system modeling and control

Simulation Modeling and Analysis

Dynamic system modeling and control

Dynamic System Modeling and Control

Microsoft Excel 2010: Data Analysis and Business Modeling

Microsoft Excel 2010: Data Analysis and Business Modeling

Microsoft Excel 2010: Data Analysis and Business Modeling

Distribution System Modeling and Analysis (Electric Power Engineering Series)

Sam

Models in Software Engineering - MoDELS 2010

Sam

Practical Microsoft Office 2010 (Sam 2010 Compatible Products)

Reliability Modeling, Analysis And Optimization

Adsorption: Theory, Modeling, and Analysis

Manufacturing Systems Modeling and Analysis

Applied dimensional analysis and modeling

Applied Dimensional Analysis and Modeling

Sam

Applied Dimensional Analysis and Modeling

Reliability modeling, analysis and optimization

Precipitation Modeling and Quantitative Analysis

Sam

Sam

System Analysis and Modeling: Language Profiles: 5th International Workshop, SAM 2006, Kaiserslautern, Germany, May 31 - June 2, 2006, Revised Selected

Requirements Analysis and System Design

Analytical System Dynamics: Modeling and Simulation

Embedded System Design: Modeling, Synthesis and Verification

Recommend Documents