Transactions on Aspect-Oriented Software Development VII: A Common Case Study for Aspect-Oriented Modeling (Lecture Notes in Computer Science Transactions on Aspect-Oriented Software Development)

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 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 Moshe Y. Vardi Rice University, Houston, TX, USA Gerhard Weikum Max Planck Institute for Informatics, Saarbruecken, Germany

6210

Shmuel Katz Mira Mezini Jörg Kienzle (Eds.)

Transactions on Aspect-Oriented Software DevelopmentVII A Common Case Study for Aspect-Oriented Modeling

13

Editors-in-Chief Shmuel Katz The Technion Department of Computer Science Haifa 32000, Israel E-mail: [email protected] Mira Mezini Darmstadt University of Technology Department of Computer Science 64289 Darmstadt, Germany E-mail: [email protected]

Guest Editor Jörg Kienzle McGill University School of Computer Science H3A 2A7 Montreal, QC, Canada E-mail: [email protected]

Library of Congress Control Number: 2010934940 CR Subject Classification (1998): D.2, F.3, D.3, C.2, K.6, D.1

ISSN ISSN ISBN-10 ISBN-13

0302-9743 (Lecture Notes in Computer Science) 1864-3027 (Transactions on Aspect-Oriented Software Development) 3-642-16085-9 Springer Berlin Heidelberg New York 978-3-642-16085-1 Springer Berlin Heidelberg New York

This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. springer.com © Springer-Verlag Berlin Heidelberg 2010 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper 06/3180

Editorial

Welcome to Volume VII of the Transactions on Aspect-Oriented Software Development. This volume is a special issue on A Common Case Study for Aspect-Oriented Modeling with guest editor Jörg Kienzle, under the management of one of the coeditors-in-chief, Shmuel Katz. This issue has an unusual format. The first paper presents the case study, a relatively complex crisis management system, and the subsequent ones each apply different modeling techniques to it. In this way, a wide variety of notations and abstraction techniques for modeling aspect systems are demonstrated and evaluated for the same case study. This should allow readers to understand the relative strengths of each approach, and encourage cross-fertilization among the techniques. The background and the approaches in the special issue are described in the guest editor’s foreword. We thank him for his effort and commitment in producing such a high-quality special issue. The next issue of TAOSD will also focus on a special topic: industrial applications of aspect technology, with guest editors Wouter Joosen and Christa Schwanninger. One of the major impediments to broader industrial adoption of AOSD is the lack of accessible experience reports on the application of AOSD in commercial software projects. This special issue will offer a collection of such examples, experience reports, and success stories, and will present insights gained that should be of value to potential and existing industrial users, as well as of interest to researchers concerned with overcoming the practical obstacles to using aspects. A new special issue on Modularity Concepts in Programming Languages is also scheduled for 2011, and will be edited by Gary Leavens and Klaus Ostermann. This issue will highlight original and innovative modularity concepts. Of course, we continue to encourage regular submissions on all topics connected to modularity and the development of aspect-oriented software, especially when a single system decomposition does not adequately address all concerns. We are happy to welcome five new editorial board members: Wouter Joosen, Gary Leavens, Klaus Ostermann, Mario Südholt, and Eric Tanter. They all are outstanding researchers in software engineering and AOSD, and we look forward to benefiting from their insights and experience. We thank the editorial board for their continued guidance and input on the policies of the journal, the choice of special issues, and associate-editorship of regular submissions. Thanks are also due to the reviewers, who volunteered significant time, despite their busy schedules, to ensure the quality of articles published in the journal. Most importantly, we wish to thank the authors who have submitted papers to the journal so far. This issue also marks a change in the editors-in-chief of the journal. In accordance with journal policy, Harold Ossher has finished his term, and will continue as a regular associate editor. We would like to thank him personally for his advice, and especially for providing an outstanding example of how to edit a journal. We close with two short messages:

VI

Editorial

Note from Harold Ossher, the outgoing editor-in-chief: I would like to thank the authors, reviewers, editorial board members and co-editor-in-chief, all of whom contributed so much to the journal during my term, and who were always a pleasure to work with. I am excited by this special issue and those currently in the works, and am confident that, under the leadership of world-renowned experts Shmuel Katz and Mira Mezini, the journal will grow and flourish. Note from the editorial board: The entire editorial board thanks Harold for his exceptional leadership and service as editor-in-chief. His guidance has been invaluable over the last years. We also welcome Mira Mezini as the new co-editor-in-chief, along with Shmuel Katz. Mira, Professor of Computer Science at the Darmstadt University of Technology, is well known to the research community, and has made numerous fundamental contributions to AOSD, including the CeasarJ language, innovative implementation techniques for aspect languages, and new language constructs to improve modularity and separation of concerns. We look forward to future development of the journal under her leadership.

June 2010

Shmuel Katz Mira Mezini Co-Editors-in-Chief

A Common Case Study for Aspect-Oriented Modeling Guest Editor’s Foreword

Aspect-oriented modeling (AOM) focuses on modularizing and composing crosscutting concerns within software models — models that can be used to describe or analyze properties of a system under development.This can be done within different modeling notations, at different levels of abstraction, and at different moments during the software development process. To date, there exist many AOM techniques for different modeling notations (e.g., for class diagrams, sequence diagrams, state diagrams, protocol machines, component diagrams, live sequence charts, SDL, use cases, etc..) and many AOM approaches that can be applied at different phases of software development (requirements, analysis, architecture, design, implementation) or to different domains (e.g., to software product lines, modeling security, modeling fault tolerance, etc...). A considerable number of papers in journals and high-quality conference proceedings have been published on AOM. Fourteen successful workshops on AOM have been organized at the AOSD conference and the MoDELS conference in the last 8 years [1]. There is also the series of workshops entitled Early Aspects that falls within the context of AOM [2]. Finally, two special issues of the journal Transactions on Aspect-Oriented Software Development have already been published in related areas: Vol. III on “early aspects — analysis, visualization, conflicts and composition", in 2007 [3] and Vol. VI on “aspects and model-driven engineering", in 2009 [4]. Despite the many sources of information on AOM, it is not easy for people who want to use AOM to choose an appropriate technique. Comparing different AOM approaches with each other to highlight the advantages and disadvantages of each one is not trivial, because each research team applies their AOM approach within a different context. Finally, it is not clear nowadays how several AOM approaches that apply to different phases of software development could be combined to produce a coherent aspect-oriented software development process. To remedy this situation, this special issue assembles 9 papers that apply AOM techniques and approaches to the same case study. Due to the specific nature of the special issue, the selection criteria for the papers was not, as it is in general the case for journal papers, novelty. Rather, the papers gathered here were chosen based on how well they describe how a particular, mature AOM approach is applied to the case study. As a result, all papers cover a significant part of the case study, presenting in-depth models that modularize functional as well as non-functional concerns, followed by an analysis of the strengths and weaknesses of the presented approach. Thanks to the effort of the reviewers, the resulting collection of papers provides a valuable resource for many researchers and practitioners:

VIII

Guest Editor’s Foreword

– Those who want to learn about AOM find in this special issue a concise collection of descriptions of solid and mature AOM approaches. They only have to take the time to understand one case study in order to appreciate the sample models shown in all papers. – Those who want to apply AOM for a particular purpose and are looking for the most appropriate AOM technique can use the papers presented in this special issue to identify the most promising approach(es). By identifying similarities between their problem and the case study they should be able to determine candidate AOM approaches easily. – Those working on their own AOM approach can readily identify approaches that were able to handle concerns that their own approach is not able to handle elegantly. This stimulates cross-fertilization between approaches and collaborative research. – Those engineering researchers that are working on enhancing software development processes can use the example models presented in this special issue to understand the potential benefits of using AOM techniques at different phases of the software development life-cycle. Case Study The broad domain of the case study is crisis management systems (CMS), i.e., software that facilitates coordination of activities and information flow between all stakeholders and parties that need to work together to handle a crisis. CMSs can be used to handle many types of crises (e.g., natural disasters, epidemics, accidents, attacks, etc...) and may have to interface and interoperate with different types of external services (e.g., military systems, police systems, government, medical services, etc...). CMSs also exhibit many non-functional properties, e.g., they must be highly available, dependable and secure. A detailed, non-aspectoriented description of the case study is presented in the first paper of this special issue. The research papers that follow are therefore not self-contained, i.e., they do not describe the case study again, but simply refer the reader to the case study document for details if needed. Overview of Papers The order in which the papers in this special issue are presented roughly corresponds to the software development phases in which the AOM approaches are applied. Requirements Modeling with the Aspect-Oriented User Requirements Notation (AoURN): A Case Study The approach presented in this paper focuses on the requirements elicitation and engineering phase. The authors, Gunter Mussbacher, Daniel Amyot, João Araújo, and Ana Moreira, show how they applied the Aspect-Oriented User Requirements Notation (AoURN) to model all use cases, non-functional requirements and stakeholders of the crisis management system as individual concerns. The models presented are very abstract, in the sense that they do not model

Guest Editor’s Foreword

IX

detailed data nor message exchanges. However, AoURN scenario definitions can be analyzed, enabling regression-testing of the scenario model. The paper demonstrates how concern dependencies and conflicts among concerns can be captured, as well as how conflict resolutions and trade-offs are documented. In addition, the paper presents a qualitative comparison of aspect-oriented techniques for scenario-based and goal-oriented requirements engineering. Relating Feature Models to Other Models of a Software Product Line: A Comparative Study of FeatureMapper and VML* This paper concentrates on aspect-oriented modeling in the context of software product line development. The authors, Florian Heidenreich, Pablo Sánchez, João Santos, Steffen Zschaler, Mauricio Alférez, João Araújo, Lidia Fuentes, Uirá Kulesza, Ana Moreira, and Awais Rashid, investigate the problem of establishing a relationship between concerns expressed at a high level of abstraction in a feature model to other models that describe the details of a product line. To better understand the different approaches that can be used to accomplish this task, the paper applies two different approaches to the crisis management system case study: FeatureMapper as a representative of declarative approaches and VML* as a representative of operational approaches. The paper illustrates how to express product derivation and mapping of features to models using both approaches in the context of a car crash crisis management system and a flood crisis management system. Aspect-Oriented Development Using Protocol Modeling In this paper, the authors, Ashley McNeile and Ella Roubtsova, describe how they use the Protocol Modeling approach to perform formal specification of the event-based interaction between the crisis management system and the environment. The interactions specified in the requirements of the crisis management system are decomposed into multiple protocol machines that specify the behavior of different concerns. The global system model is obtained by composing the protocol machines using CSP parallel composition. The paper illustrates how the system model can be simulated, and finally validated against the use cases defined in the requirements document. Using VCL as an Aspect-Oriented Approach to Requirements Modeling As the title suggests, this paper, authored by Nuno Amálio, Pierre Kelsen, Qin Ma, and Christian Glodt, presents the Visual Contract Language (VCL), an approach that uses aspect-oriented techniques to produce a modular, concise requirements specification. VCL’s primary goal is to enable abstract visual modeling of software systems, where resulting models have an underlying formal semantics rooted in the Z specification language. VCL’s models are based on data with an object-oriented structure; behavior is described by explaning how data is transformed using operation specifications comprised of pre- and post-conditions. VCL is well-suited for building abstract models of systems that can describe detailed requirements models or high-level designs. The approach is illustrated on a considerable part of the crisis management system’s functional

X

Guest Editor’s Foreword

requirements, as well as on non-functional concerns such as authentication, access control, and session management. Workflow Design Using Fragment Composition: Crisis Management System Design through ADORE Adore, presented in the paper authored by Sébastien Mosser, Mireille BlayFornarino, and Robert France, is an AOM approach that aims at facilitating business process design. Adore allows Service-Oriented Architecture (SOA) developers to model complex orchestrations of services by composing models of smaller orchestrations called orchestration fragments. Adore can also be used to weave fragments that address new concerns into existing application models. Finally, consistency checks can be used to identify problematic interactions between fragments and base models. The approach is illustrated on the crisis management system by modeling several of the car crash crisis management system use cases, including the effects of non-functional requirements such as persistence, security, and statistical logging. Modeling the Car Crash Crisis Management System Using HiLA In this paper, the authors Matthias Hölzl, Alexander Knapp, and Gefei Zhang, present the HiLA approach, whose primary goal is to improve the modularity of UML state machines by extending the notation with aspect-oriented features. Especially when modeling history-dependent and synchronization concerns, HiLA helps reduce the model complexity by being highly declarative. Since the weaving result is also a state machine, it can be validated by formal methods, such as model checking and theorem proving. HiLA can be used for requirements analysis as well as for design. In the paper, the usefulness of HiLA is illustrated by applying it to methodologically turn use case descriptions of the crisis management system into state machines: for each main success scenario a base state machine is developed; all extensions to this main success scenario are covered by aspects. Aspect-Oriented Design with Reusable Aspect Models The Reusable Aspect Models (RAM) approach, presented in this paper by Jörg Kienzle, Wisam Al Abed, Franck Fleurey, Jean-Marc Jézéquel, and Jacques Klein, allows a modeler to express the structure and behavior of the design of a system under development using class, state, and sequence diagrams encapsulated in several aspect models. RAM supports aspect hierarchies, where aspects at a high level of abstraction reuse structure and behavior defined by lower-level aspects. Design decisions, such as deciding on interaction patterns, concrete data structures and algorithms, guide the decomposition of high-level aspects into lower-level ones. The lowest level aspects model the system in such detail that mapping the model to source code is straightforward. The usefulness of RAM is illustrated by presenting 23 high-level and detailed design aspect models of the “create mission” functionality of the server backend of the car crash crisis management system.

Guest Editor’s Foreword

XI

A Graph-Based Aspect Interference Detection Approach for UMLBased Aspect-Oriented Models This paper, authored by Selim Ciraci, Wilke Havinga, Mehmet Aksit, Christoph Bockisch, and Pim van den Broek, describes a technique and tool called GrACE that can be used for automatic detection of conflicts between aspect models. Execution constraints of aspect models, expressed in Computation Tree Logic (CTL), can be verified using model checking on the composed model. As GrACE accepts UML 2.2 sequence diagrams as input, it is usable by approaches at different levels of abstraction employing these diagrams. However, GrACE’s execution semantics makes the approach most suitable for analyzing detailed OO design models. The approach is presented by modeling several of the mission scenarios defined for the car crash crisis management system, as well as a monitoring non-functional requirement. Discovery of Stable Abstractions for Aspect-Oriented Composition in the Car Crash Management Domain This paper is slightly different from the others, since it covers several phases of software development. The authors, Dimitri Van Landuyt, Eddy Truyen, and Wouter Joosen, describe an approach that aids developers in discovering stable domain abstractions when developing a system. Based on use case engineering and domain modeling techniques, their method provides a systematic approach for discovering domain abstractions that are suitable for aspectual composition in requirements, software architecture, detailed design models, and finally in the implementation. Furthermore, the approach described provides architectural guidelines on how to design pointcut interfaces that are based on these stable domain abstractions. The approach is illustrated on the car crash crisis management system, starting with the use cases, presenting an architecture model, and then showing the design and implementation details of employee assignment and strategy selection. May 2010

Jörg Kienzle

References 1. Aspect-Oriented Modeling Workshop Series. http://www.aspect-modeling.org/ 2. Early Aspects Workshop Series. http://www.early-aspects.net/ 3. Rashid, A., Aksit, M. (eds.) Transactions on Aspect-Oriented Software Development III - Special Issue on Early Aspects, LNCS, vol. 4620. Springer, Heidelberg (2007) 4. Katz, S., Osher, H. (eds.): Transactions on Aspect-Oriented Software Development VI - Special Issue on Aspects and Model-Driven Engineering, LNCS, vol. 5560. Springer, Heidelberg (2009)

Editorial Board

Mehmet Akúit Shigeru Chiba Siobhán Clarke Theo D‘Hondt Robert Filman Bill Harrison Wouter Joosen Shmuel Katz Gregor Kiczales Shriram Krishnamurthi Gary T. Leavens Karl Lieberherr Mira Mezini Oege de Moor Ana Moreira Harold Ossher Klaus Ostermann Awais Rashid Douglas Schmidt Mario Südholt Eric Tanter

University of Twente, The Netherlands Tokyo Institute of Technology, Japan Trinity College Dublin, Ireland Vrije Universiteit Brussel, Belgium Google, USA Trinity College Dublin, Ireland Katholieke Universiteit Leuven, Belgium Technion-Israel Institute of Technology, Israel University of British Columbia, Canada Brown University, USA University of Central Florida, USA Northeastern University, USA Darmstadt University of Technology, Germany University of Oxford, UK New University of Lisbon, Portugal IBM Research, USA University of Marburg, Germany Lancaster University, UK Vanderbilt University, USA Ecole des Mines des Nantes, France University of Chile, Chile

List of Reviewers Mehmet Aksit Omar Aldawud João Araújo Olivier Barais Aswin van den Berg Christoph Bockisch Ruzanna Chitchyan Thomas Cottentier Kendra Cooper Krzysztof Czarnecki Johan Fabry Frank Fleurey Robert France Lidia Fuentes Jeff Gray Phil Greenwood Iris Groher Nicolas Guelfi

Stefan Hanenberg Øystein Haugen Wouter Joosen Jacques Klein Gunter Mussbacher Ana Moreira Clémentine Nebut Carlos Parra Hridesh Rajan Ella Roubtsova Americo Sampaio Pablo Sánchez Christa Schwanninger Lionel Seinturier Dominik Stein Bedir Tekinerdogan Hans Vangheluwe Robert Walker

Table of Contents

Crisis Management Systems: A Case Study for Aspect-Oriented Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . J¨ org Kienzle, Nicolas Guelfi, and Sadaf Mustafiz

1

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN): A Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gunter Mussbacher, Daniel Amyot, Jo˜ ao Ara´ ujo, and Ana Moreira

23

Relating Feature Models to Other Models of a Software Product Line: A Comparative Study of FeatureMapper and VML* . . . . . . . . . . . . . . . . . . Florian Heidenreich, Pablo S´ anchez, Jo˜ ao Santos, Steffen Zschaler, Mauricio Alf´erez, Jo˜ ao Ara´ ujo, Lidia Fuentes, Uir´ a Kulesza, Ana Moreira, and Awais Rashid Aspect-Oriented Development Using Protocol Modeling . . . . . . . . . . . . . . . Ashley McNeile and Ella Roubtsova

69

115

Using VCL as an Aspect-Oriented Approach to Requirements Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nuno Am´ alio, Pierre Kelsen, Qin Ma, and Christian Glodt

151

Workflow Design Using Fragment Composition: Crisis Management System Design through ADORE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . S´ebastien Mosser, Mireille Blay-Fornarino, and Robert France

200

Modeling the Car Crash Crisis Management System Using HiLA . . . . . . . Matthias H¨ olzl, Alexander Knapp, and Gefei Zhang

234

Aspect-Oriented Design with Reusable Aspect Models . . . . . . . . . . . . . . . . J¨ org Kienzle, Wisam Al Abed, Franck Fleurey, Jean-Marc J´ez´equel, and Jacques Klein

272

A Graph-Based Aspect Interference Detection Approach for UML-Based Aspect-Oriented Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selim Ciraci, Wilke Havinga, Mehmet Aksit, Christoph Bockisch, and Pim van den Broek

321

Discovery of Stable Abstractions for Aspect-Oriented Composition in the Car Crash Management Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dimitri Van Landuyt, Eddy Truyen, and Wouter Joosen

375

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

423

Crisis Management Systems: A Case Study for Aspect-Oriented Modeling J¨org Kienzle1 , Nicolas Guelfi2 , and Sadaf Mustafiz1 1

2

School of Computer Science, McGill University, Montreal, Canada [email protected], [email protected] Laboratory of Advanced Software Systems, University of Luxembourg, Luxembourg [email protected]

Abstract. The intent of this document is to define a common case study for the aspect-oriented modeling research community. The domain of the case study is crisis management systems, i.e., systems that help in identifying, assessing, and handling a crisis situation by orchestrating the communication between all parties involved in handling the crisis, by allocating and managing resources, and by providing access to relevant crisis-related information to authorized users. This document contains informal requirements of crisis management systems (CMSs) in general, a feature model for a CMS product line, use case models for a car crash CMS (CCCMS), a domain model for the CCCMS, an informal physical architecture description of the CCCMS, as well as some design models of a possible object-oriented implementation of parts of the CCCMS backend. AOM researchers who want to demonstrate the power of their AOM approach or technique can hence apply the approach at the most appropriate level of abstraction.

1 Introduction The need for crisis management systems has grown significantly over time. A crisis can range from major to catastrophic affecting many segments of society. Natural disasters (e.g. earthquakes, tsunamis, twisters, fire, floods, etc...), terrorist attacks or sabotage (explosions, kidnapping, etc...), accidents (plant explosion, pollution emergency, a car crash, etc...), and technological disruptions are all examples of emergency situations that are unpredictable and can lead to severe after effects unless handled immediately. Crisis management involves identifying, assessing, and handling the crisis situation. A crisis management system facilitates this process by orchestrating the communication between all parties involved in handling the crisis. The CMS allocates and manages resources, and provides access to relevant crisis-related information to authorized users of the CMS. Different existing AOM approaches and techniques are meant to be used during different phases of software development. As a result, different AOM approaches work with different kinds of models and modeling notations. To make sure that all AOM approaches and techniques are somehow applicable to this case study, we present a collection of models that describe the CMS at different levels of abstraction: 1. Short, informal requirements text describing the domain of crisis management systems in more detail. It also mentions some non-functional requirements of a CMS, S. Katz et al. (Eds.): Transactions on AOSD VII, LNCS 6210, pp. 1–22, 2010. c Springer-Verlag Berlin Heidelberg 2010 

2

J. Kienzle, N. Guelfi, and S. Mustafiz

2.

3.

4.

5. 6.

e.g. security and dependability. This text, presented in Section 2 on page 2, probably contains information that is important to everyone who wants to work on this case study. Feature diagrams highlighting the software product line aspect of crisis management systems. Crisis management systems can be used to handle many types of crises (e.g., natural disasters, epidemics, accidents, attacks, etc...) and may have to interface and interoperate with different types of external services (e.g., military systems, police systems, government, medical services, etc...). The feature diagram models are presented in Section 3 on page 6. Use cases describing a particular CMS suitable for dealing with car crash crises. The Car Crash CMS (CCCMS) use case model description can be found in Section 4 on page 8. A domain model of the car crash crisis management system that documents the key concepts, and the domain vocabulary of the CCCMS is presented in Section 5 on page 16. An informal description of a possible physical architecture for the car crash crisis management system is presented in Section 6 on page 18. Some detailed design models for the car crash crisis management system backend are given in Section 7 on page 19.

2 Crisis Management System: Requirements The user requirements outlined in this section are based on a draft of a real requirements document for crisis management systems created by the company Optimal Security [1]. The general objectives of a crisis management system (CMS) include the following: – – – – – –

To help in the coordination and handling of a crisis; to ensure that an abnormal or catastrophic situation does not get out of hand; to minimize the crisis by handling the situation using limited resources; to allocate and manage resources in an effective manner; to identify, create, and execute missions in order to manage the crisis; to archive the crisis information to allow future analysis.

2.1 Crisis Scenario of a Car Crash Crisis Management System A crisis management scenario is usually triggered by a crisis report from a witness at the scene. A coordinator, who is in-charge of organizing all required resources and tasks initiates the crisis management process. The coordinator has access to the camera surveillance system. The surveillance system is an external system used to monitor traffic on highways or other busy routes. The cameras are installed only in specific locations. If a crisis occurs in locations under surveillance, the crisis management system can request video feed that allows the coordinator to verify the witness information. A super observer, an expert in the field (depending on the kind of crisis), is assigned to the scene to observe the emergency situation and identify the tasks necessary to cope with the situation. The tasks are crisis missions defined by the observer. The coordinator is then required to process the missions by allocating suitable resources to each task.

Crisis Management Systems: A Case Study for Aspect-Oriented Modeling

3

Depending on the type of crisis, human resources could include firemen, doctors, nurses, policemen, and technicians, and hardware resources could include transportation systems, computing resources, communication means (such as PDAs or mobile phones), or other necessities such as food or clothes. Animals, for instance police dogs, are also used as resources in some situations. The human and animal resources act as first-aid workers. Each first-aid worker is assigned a specific task that needs to be executed to recover from the abnormal situation. The workers are expected to report on the success or failure in carrying out the missions. The completion of all missions would allow the crisis to be concluded. 2.2 Scope of the CMS A crisis management system (CMS) should include the following functionalities: – initiating a crisis based on the external input from a witness, – processing a crisis by executing the missions defined by a super observer and then assigning internal and/or external resources, – wrapping up and archiving crisis, – authenticating users, – handling communication between coordinator/system and resources. A CMS replaces existing crisis management systems that a) still manually keep track of important crisis-related information and that b) operate largely without automated support for crisis resolution strategies to respond to a crisis. 2.3 Non-functional Requirements of the CMS The crisis management system shall exhibit the following non-functional properties: – Availability • The system shall be in operation 24 hours a day, everyday, without break, throughout the year except for a maximum downtime of 2 hours every 30 days for maintenance. • The system shall recover in a maximum of 30 seconds upon failure. • Maintenance shall be postponed or interrupted when a crisis is imminent without affecting the systems capabilities. – Reliability • The system shall not exceed a maximum failure rate of 0.001%. • The mobile units shall be able to communicate with other units on the crisis site and the control centre regardless of location, terrain, and weather conditions. – Persistence • The system shall provide support for storing, updating, and accessing the following information on both resolved and on-going crises: type of crisis, location of crisis, witness report, witness location, witness data, time reported, duration of resolution, resources deployed, civilian casualties, crisis management personnel casualties, strategies used, missions used, location of super observer, crisis perimeter, location of rescue teams on crisis site, level of emissions from crisis site, log of communications, log of decisions, log of problems encountered.

4

J. Kienzle, N. Guelfi, and S. Mustafiz

–

–

–

–

–

• The system shall provide support for storing, updating, and accessing the following information on available and deployed resources (both internal and external): type of resource (human or equipment), capability, rescue team, location, estimated time of arrival (ETA) on crisis site. • The system shall provide support for storing, updating and accessing the following information on crisis resolution strategies: type of crisis, step-by-step guide to resolve crisis, configuration of missions required, links to alternate strategies, applications to previous crises, and success rate. Real time • The control centre shall receive and update the following information on an on going crisis at intervals not exceeding 30 seconds: resources deployed, civilian casualties, crisis management personnel casualties, location of super observer, crisis perimeter, location of rescue teams on crisis site, level of emissions from crisis site, estimated time of arrival (ETA) of rescue teams on crisis site. • The delay in communication of information between control centre and rescue personnel as well as amongst rescue personnel shall not exceed 500 milliseconds. • The system shall be able to retrieve any stored information with a maximum delay of 500 milliseconds. Security • The system shall define access policies for various classes of users. The access policy shall describe the components and information each class may add, access, and update. • The system shall authenticate users based on the access policies when they first access any components or information. If a user remains idle for 30 minutes or longer, the system shall require them to re-authenticate. • All communications in the system shall use secure channels compliant with AES-128 standard encryption. Mobility • Rescue resources shall be able to access information on the move. • The system shall provide location-sensitive information to rescue resources. • Rescue resources shall communicate their location to the control centre. • The system shall have access to detailed maps, terrain data, and weather conditions for the crisis location and the routes leading to it. Statistic Logging • The system shall record the following statistical information on both on-going and resolved crises: rate of progression, average response time of rescue teams, individual response time of each rescue team, success rate of each rescue team, rate of casualties, and success rate of missions. • The system shall provide statistical analysis tools to analyse individual crisis data and data on multiple crises. Multi-Access • The system shall support at least 1000 witnesses calling in at a time. • The system shall support communication, coordination, and information access for at least 20000 rescue resources in deployment at a time. • The system shall support management of at least 100 crises at a time. • The system shall support management of at least 200 missions per crisis at a time.

Crisis Management Systems: A Case Study for Aspect-Oriented Modeling

5

– Safety • The system shall monitor emissions from the crisis site to determine safe operating distances for rescue resources. • The system shall monitor weather and terrain conditions at crisis site to ensure safe operation and withdrawal of rescue resources, and removal of civilians, and casualties. • The system shall determine a perimeter for the crisis site to ensure safety of civilians and removal of casualties to a safe distance. • The system shall monitor criminal activity to ensure safety of rescue resources, civilians and casualties. • The safety of rescue personnel shall take top priority for the system. – Adaptability • The system shall recommend alternate strategies for dealing with a crisis as the crisis conditions (e.g., weather conditions, terrain conditions, civilian, or criminal activity) change. • The system shall recommend or enlist alternate resources in case of unavailability or shortage of suitable resources. • The system shall be able to use alternate communication channels in case of unavailability or shortage of existing channels. • The system shall be able to maintain effective communication in areas of high disruption or noise at the crisis site. – Accuracy • The system shall have access to map, terrain, and weather data with a 99% accuracy. • The system shall provide up-to-date information to rescue resources. • The system shall record data on receipt without modifications. • The communication between the system and rescue resources shall have a maximum deterioration factor of 0.0001 per 1000 kilometres. 2.4 Car Crash Crisis Management System Some of the models presented in this paper focus on one particular CMS: the car crash crisis management system (CCCMS). The CCCMS includes all the functionalities of general crisis management systems, and some additional features specific to car crashes such as facilitating the rescuing of victims at the crisis scene and the use of tow trucks to remove damaged vehicles. Scope of the CCCMS. A car accident or car crash is an incident in which an automobile collides with anything that causes damage to the automobile, including other automobiles, telephone poles, buildings or trees, or in which the driver loses control of the vehicle and damages it in some other way, such as driving into a ditch or rolling over [2]. Sometimes, a car accident may also refer to an automobile striking a human or animal. Our CCCMS addresses car crashes involving single or multiple vehicles, humans, or other objects. This case study is, however, limited to management of human victims

6

J. Kienzle, N. Guelfi, and S. Mustafiz

only and does not provide rescue missions specifically for animals. First-aid animal workers are not included in the scope of this case study either. Car crash-specific functionalities include the following: – facilitating the rescue mission carried out by the police by providing them with detailed information on the location of the crash; – managing the dispatch of ambulances or other alternate emergency vehicles to transport victims from the crisis scene to hospitals; – facilitating the first-aid missions by providing relevant medical history of identified victims to the first-aid workers by querying databases of local hospitals; – facilitating the medical treatment process of victims by providing important information about the crash to the concerned workers, i.e. paramedics, doctors, upon arrival at the hospital; – managing the use of tow trucks to remove obstacles and damaged vehicles from the crisis scene. CCCMS Actors. The actors involved in the CCCMS are defined in this section. – Coordinator oversees management of the crisis by coordinating the resources and communicating with all the CMS employees and external workers. – Super Observer is dispatched to the crisis scene to evaluate the situation and define the necessary missions to cope with the crisis. – CMS Employee is an internal human resource who is qualified and capable of performing missions related to his field of expertise. The worker acts as a facilitator actor when he is in-charge of or operating local resources (e.g. tow trucks or ambulances). – External Worker is an external resource who is specialized and capable of performing missions related to his field of expertise. The worker acts as a facilitator actor when he is in charge of or operating external resources (e.g. police trucks or fire trucks). – System Admin is the specialist who maintains the system and creates all profiles of workers and resources to feed the crisis management database. – Witness is the person who reports the crisis by calling the crisis management center. – Phone Company is an external entity contacted for verification of witness purposes. – Surveillance System is an external entity which monitors traffic in highways and cities with the use of cameras.

3 Crisis Management System: Feature Models Because there are so many different kinds of crises, the domain of crisis management systems is very broad. However, any crisis management system has a common set of responsibilities and functionalities. It is, therefore, natural to build a framework or product line of crisis management systems, which can be specialized to create crisis management systems for a particular kind of crisis and a particular context. A feature diagram

Crisis Management Systems: A Case Study for Aspect-Oriented Modeling

Fig. 1. Crisis Management Systems Feature Diagram – Part 1

Fig. 2. Crisis Management Systems Feature Diagram – Part 2

7

8

J. Kienzle, N. Guelfi, and S. Mustafiz

Fig. 3. Crisis Management Systems Feature Diagram – Part 3

listing many possible features of a crisis management system is given in Figs. 1 to 3. It has been taken from [3]. Selection of some features requires the selection of other features. Examples of such dependencies are: – Natural Disasters requires Fire Department and External Company – Terrorist Attack requires Army Special Unit and Police and Police Special Unit and Public Hospital – Major Accident requires Police and Fire Department and Public Hospital and Private Hospital and Independent First-Aid Doctor and Private Ambulance Company – Plant Explosion requires Police and Fire Department and Public Hospital – Nuclear Plant Explosion requires The Army and Army Special Unit Fig. 4 presents a possible set of features selected for the car crash CMS.

4 Car Crash Crisis Management System: Use Cases Use cases [4,5] are a widely used formalism for discovering and recording behavioral requirements of software systems, since they can be effectively used as a communication means between technical because as well as non-technical stakeholders of the software under development. In short, use cases are stories of using a system to meet goals. They are in general text-based, but their strength is that they both scale up or scale down in terms of sophistication and formality, depending on the need and context.

Crisis Management Systems: A Case Study for Aspect-Oriented Modeling

Fig. 4. Car Crash Crisis Management Systems Feature Diagram

9

10

J. Kienzle, N. Guelfi, and S. Mustafiz

Crisis Management System: Car Crash Case Study

1

Surveillance System

> inc

lud e lud

>>




lude>



Statistics

1


numberOfCandidates(int)

Map
Time travelTime


(Location, Location)

Fig. 9. CCCMS: Partial Design Class Diagram based on CreateMission Design

22

J. Kienzle, N. Guelfi, and S. Mustafiz

Acknowledgments The authors would like to thank Christian Fischer, Damien Garot, Laurent Vuillermoz, Jacques Klein, and Alfredo Capozucca for sharing requirements documents and models of crisis management systems with us. Their contributions led to the creation of the first draft of this document. Our thanks also extend to Mehmet Aksit, Wisam Al Abed, Jo˜ao Ara´ujo, Florencia Balbastro, Franck Fleurey, Jean-Marc J´ez´equel, Gunter Mussbacher, Awais Rachid, Pablo S´anchez, and Jon Whittle, the participants of the first 1-week aspect-oriented modeling workshop held at the Bellairs Research Institute of McGill University from April 5th to April 12th 2009. Their valuable input and suggestions significantly enhanced the quality of the requirements and use cases descriptions.

References 1. 2. 3. 4.

Optimal Security: Requirements document: Version 0.8 (March 2009) Wikicars.org: http://wikicars.org/en/Car_accidents Optimal Security: Product line document: Version 0.7 (March 2009) Jacobson, I., Christerson, M., Jonsson, P., Overgaard, G.: Object-Oriented Software Engineering: A Use Case Driven Approach. Addison–Wesley, Reading (1992) 5. Cockburn, A.: Writing Effective Use Cases. Addison–Wesley, Reading (2000) 6. Mustafiz, S., Kienzle, J.: DREP: A Requirements Engineering Process for Dependable Reactive Systems. In: Romanovsky, A., Jones, C., Knudsen, J.L., Tripathi, A. (eds.) Methods, Models and Tools for Fault Tolerance, vol. 5454, pp. 220–250. Springer, Heidelberg (2009)

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN): A Case Study Gunter Mussbacher1, Daniel Amyot1, João Araújo2, and Ana Moreira2 1

SITE, University of Ottawa, 800 King Edward, Ottawa, ON, K1N 6N5, Canada {gunterm,damyot}@site.uottawa.ca 2 CITI/FCT, Universidade Nova de Lisboa, 2829-516 Caparica, Portugal {ja,amm}@di.fct.unl.pt

Abstract. The User Requirements Notation (URN) is a recent ITU-T standard that supports requirements engineering activities. The Aspect-oriented URN (AoURN) adds aspect-oriented concepts to URN, creating a unified framework that allows for scenario-based, goal-oriented, and aspect-oriented modeling. AoURN is applied to the car crash crisis management system (CCCMS), modeling its functional and non-functional requirements (NFRs). AoURN generally models all use cases, NFRs, and stakeholders as individual concerns and provides general guidelines for concern identification. AoURN handles interactions between concerns, capturing their dependencies and conflicts as well as the resolutions. We present a qualitative comparison of aspect-oriented techniques for scenario-based and goal-oriented requirements engineering. An evaluation carried out based on the metrics adapted from literature and a task-based evaluation suggest that AoURN models are more scalable than URN models and exhibit better modularity, reusability, and maintainability. Keywords: Aspect-Oriented Requirements Engineering, Aspect-oriented User Requirements Notation, Scenario-based Modeling, Goal-oriented Modeling.

1 Introduction The User Requirements Notation (URN) [1] is a visual language standardized by the International Telecommunications Union that combines goal-oriented modeling with the Goal-oriented Requirement Language (GRL) and scenario-based modeling with Use Case Maps (UCM). GRL is a technique to capture and evaluate alternatives for reaching stakeholder goals. UCM are used to model causal scenarios. URN is the first and only standard that combines goal-oriented and scenario-based modeling. Nevertheless, URN, like any other modeling language, is reexamined and updated from time to time in light of new, promising developments in software engineering. One such examination of developments in Aspect-oriented Modeling [2, 3, 4, 5, 6, 7, 8] led to research into the Aspect-oriented User Requirements Notation (AoURN). AoURN further combines URN concepts with aspect-oriented concepts into a unified framework to improve modeling support for crosscutting concerns during requirements activities. AoURN consists of two sub-notations called Aspect-oriented GRL (AoGRL) and Aspect-oriented UCM (AoUCM). S. Katz et al. (Eds.): Transactions on AOSD VII, LNCS 6210, pp. 23–68, 2010. © Springer-Verlag Berlin Heidelberg 2010

24

G. Mussbacher et al.

The purpose of this paper is to demonstrate the capabilities of AoURN [9] for requirements engineering activities, giving: a) a detailed introduction to the language with the help of the Car Crash Crisis Management System (CCCMS) case study [10], b) a thorough analysis of AoURN’s capabilities compared with traditional URN models, and c) a qualitative comparison of AoURN to other aspect-oriented techniques. The evaluation of AoURN’s capabilities vs. traditional URN is based on the assessment of the structure of the models built with AoURN and URN. This is, therefore, an experiment that must compare equivalent models, i.e., the content of the models must be the same. The evaluation looks at the structure of two equivalent AoURN and URN models and determines characteristics of these models with the help of metrics from literature that have been used before to assess modularity, reusability, and maintainability [11], although in a somewhat different, but still similar enough context. In addition, a task-based evaluation assesses the impact of common update tasks on the AoURN and URN models. Regarding the scope of this study, note that the experiment does not attempt to determine which technique may define a more complete model (note that there is anecdotal evidence that focusing on concerns helps in this regard [12]). The setup of the CCCMS case study does not easily allow such an experiment because the content of the case study is deemed to be complete and must not be substantially altered. Furthermore, this is also not a usability study, which would require groups of users trying to independently model the CCCMS with AoURN and URN. Undeniably, such an experiment will have to contend with several issues in addition to the core URN and AoURN language features. Issues, such as available tool support and sufficient user training, have to be considered and influence the experiment’s result to a certain degree. Although these experiments also answer important questions about URN and AoURN and hence are worthwhile endeavors that should be undertaken in the future, they are out of scope for this paper as we are, for now, more interested in presenting the language features and in assessing the core language features of URN and AoURN. The remainder of the paper first presents the AoURN modeling process in section 2 and then gives a brief overview of AoURN in section 3. Section 4 presents a selection of the models for the CCCMS and discusses the process phases in greater detail. In section 5, URN and AoURN are compared with each other. Section 6 presents the qualitative comparison of AO techniques for scenario-based and goal-oriented requirements engineering. The paper ends with a conclusion and a discussion of future work in section 7.

2 Overview of the AoURN Modeling Process The modeling process described in the paragraphs below resulted in more than 20 nonorthogonal concerns of the CCCMS being modeled with AoURN. The highly iterative process consists of seven process modules and is supported by extensions to the jUCMNav tool [13], the most comprehensive URN tool available. Other URN tools

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

25

include UCMNav [14] which focuses only on scenario modeling, OpenOME [15] which focuses only on goal modeling, and the Sandrila SDL stencil set [16] for Microsoft Office Visio which offers a template for GRL models. Although some figures in this paper have been visually enhanced for didactic purposes, all of them can be and have been created with the jUCMNav tool. P1) Identify concerns. Concerns are identified using the guidelines AoURN provides for concern identification, i.e., it is a more symmetric approach as it treats all use cases, NFRs, and stakeholders as concerns. P2) Build scenario model with AoUCM. Behavioral aspects of the available system documentation is assessed against the identified concerns and structured into an AoUCM model. P3) Test scenario model. AoURN’s built-in testing capabilities are used to test the scenario model and gain greater confidence in its validity and consistency. P4) Describe NFRs with AoUCM. Non-functional concerns are layered over the functional concerns, by modeling NFRs described in the available system documentation with AoUCM. P5) Model stakeholder dependencies and impact with AoGRL. The dependencies between stakeholders are modeled in a goal model with AoGRL. Furthermore, the impact of the functional and non-functional concerns on the stakeholder goals is modeled with AoGRL. P6) Evaluate the AoGRL goal model. The goal model is evaluated with AoURN’s built-in analysis capabilities to indicate how well various potential solutions address the high-level goals of the stakeholders. P7) Capture concern dependencies and conflicts. Whenever a new concern is being modeled, the dependencies and conflicts with other concerns are captured in AoURN’s Concern Interaction Graph (CIG), a specialized GRL graph. These seven process modules may be executed in a flexible way as long as the following constraints are not violated as shown in Fig. 1. P1 must occur before the other process modules, P3 and P4 must occur after P2, and P6 must occur after P5.

P7 P1

P2 P5

P4 P3 P6

Fig. 1. Dependencies in the AoURN Modeling Process

Adaptations to the Process for the Case Study. Given the fact that the evaluation of AoURN conducted in this paper also requires a non-aspect-oriented URN model to be sufficiently defined for comparison purposes, the above process is slightly adapted. In P2, the use cases described in the case study document are modeled in a non-aspectoriented way with UCM, URN’s scenario notation. The UCM model is then assessed

26

G. Mussbacher et al.

against the identified concerns and restructured into an AoUCM model. This is equivalent to assessing the use cases against the identified concerns as there is a straightforward, almost one-to-one mapping between the use cases and the UCM model. However, assessing the UCM model directly ensures that the resulting UCM and AoUCM models are consistent. In P4, the UCM model for the NFR concerns is derived from the AoUCM model. Again, this is due to consistency reasons and will be motivated in more detail in section 4.6 and the beginning of section 5. In P5, the stakeholders are also modeled with GRL, URN’s goal notation. This is necessary for a comparison of standard URN and AoURN models in a new process module P8 performed after the completion of all other process modules. P8 bases the comparison on metrics adapted from literature [11] and a task-based evaluation. Therefore, the URN and AoURN models have to be consistent and cover the exact same content to avoid skewed results of the applied metrics. Any chosen modeling process for this comparison has to ensure that the two models are equivalent, either through a separate process step that balances out the two models after both have been built or by taking both models into account right away during their construction. The process presented here chooses the latter. In addition, a qualitative comparison of AO techniques for scenario-based and goal-oriented requirements engineering is undertaken.

3 Overview of Aspect-oriented User Requirements Notation This section presents a brief background on URN and AoURN. The specifics of these notations will be explained in more detail as needed in the following sections with the help of the case study. In November 2008, URN [1, 17] was approved as Recommendation Z.151 by the Standardization Sector of the International Telecommunication Union (ITU-T). URN is the first and currently only standard that supports both goaloriented and scenario-based modeling for requirements engineering activities, i.e., the elicitation, analysis, specification, and validation of requirements. URN’s goal modeling notation, called GRL, is used to describe and reason mainly about non-functional requirements (NFRs), quality attributes, and the intentions of system stakeholders, whereas URN’s scenario notation, called UCM, is used to model operational and functional requirements, and for performance and architectural reasoning. While GRL identifies at a very high level of abstraction possible solutions to be considered for a proposed system, UCM models describe these solutions in more detail. In summary, URN has concepts for the specification of stakeholders, goals, non-functional requirements, rationales, behavior, actors, scenarios, and structuring. For more information about anything related to URN, the reader is referred to the URN Virtual Library [18] which contains more than 250 publications. AoURN [9, 19, 20, 21] is a recent extension of URN that combines goals, scenarios, and aspects in one framework to better encapsulate crosscutting concerns which are hard or impossible to encapsulate with URN models alone. AoURN introduces the concept of a concern as a first class model element to which other URN model elements may be assigned. A concern is, therefore, defined by its constituent model elements, typically use case maps and goal graphs.

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

27

The possible inclusion of AoURN into the next version of URN was discussed for the first time by ITU-T in September 2009. However, it was suggested that it is too early to decide on its inclusion because URN itself is still a rather new standard and more experience with AoURN is first required. This paper represents an important step in demonstrating AoURN’s potential in that context.

4 Car Crash Crisis Management System (CCCMS) Because URN targets requirements engineering activities, the sections of the CCCMS case study document [10] that were consulted most frequently are those related to requirements, i.e., section 2 (Crisis Management System: Requirements) and section 4 (Use Cases). All CCCMS models were created by URN experts who have more than a decade of experience with URN both in academic and industrial settings, who have been responsible for editing the URN standard for the International Telecommunication Union, who have researched AoURN over the last years also in both academic and industrial settings, and who have been responsible for the development of the jUCMNav tool since its first release. 4.1 Identification of Concerns (P1) AoURN provides only rough guidelines for identifying concerns as its strengths lie in describing and analyzing concerns. Therefore, AoURN is ideally to be combined with other concern identification methods, such as EAMiner [22], which automatically identifies concerns. As the purpose of this paper is to focus on AoURN alone, AoURN’s guidelines are followed. Therefore, use cases, NFRs, as well as stakeholders are considered as concerns and iteratively refined. The following 14 nonorthogonal concerns are modeled with AoURN. These concerns are further broken down into sub-concerns, resulting in a total of 25 individual sub-concerns [23]. The four major functional concerns that are identified are Recommend Strategies (recommend strategies based on the crisis and resource availabilities), Resource Management (assignment and release of resources, such as first aid workers, ambulances, and fire trucks), Coordination (execution, adaptation, and monitoring of missions), and Communication (flow of crisis/mission information between actors and the system as well as communication infrastructure). Nine of the ten use cases in the case study document are sub-concerns of these four major functional concerns: • Coordination: Resolve Crisis, Execute Mission, Execute Super Observer Mission, Execute Rescue Mission, Execute Helicopter Transport Mission, and Execute Remove Obstacle Mission • Communication: Capture Witness Report • Resource Management: Assign Internal Resource, Request External Resource Note that each use case is only assigned to one concern in the above list, i.e., its main concern. Other concerns may still crosscut a use case (e.g., the Communication concern appears frequently in use cases assigned to the Coordination concern). Of the eleven NFRs listed in the case study document, six were modeled as concerns. These are Persistence, Statistical Logging, Availability, Security (with its three

28

G. Mussbacher et al.

sub-concerns Authentication, Access Control, and Encryption), Mobility (with its three sub-concerns Mobile Infrastructure, Location Status, and Map Information System), and Safety (with its three sub-concerns Weather Information System, Emissions Monitoring System, and Criminal Activity Monitoring System). Note that the tenth use case in the case study document belongs to the Security NFR concern. Finally, a large number of stakeholders is mentioned in the case study document (Coordinator, Super Observer, CMS Employee, External Worker, Phone Company, Surveillance System, System Admin, Witness, Police, Fire Department, Hospital, Doctor, Ambulance, Victim, First Aid Worker, Helicopter Pilot, and Tow Truck Driver) and many more are not mentioned (e.g., Funding Agency, Government, as well as the General Public). Out of these, the following four stakeholder concerns are modeled: the Coordinator, the General Public, the Resource (representing all resources, such as Super Observer, Police, Fire Department, etc.), and the Government (representing the customer of the CCCMS). Owing to the lack of details relevant to URN/AoURN goal modeling in the available documentation about the proposed CCCMS, we limit ourselves to four stakeholders. GRL is a technique to capture and evaluate alternatives for reaching stakeholder goals. The case study document does not describe well such alternatives and their rationale nor does the document describe well stakeholders and their goals. Four stakeholders are (a) a large enough number to demonstrate the capabilities of GRL and AoGRL and (b) small enough to minimize the amount of information required for goal modeling that is not explicitly stated in the case study document, but must be derived implicitly from the case study document with the help of common knowledge. For example, the case study document does not specifically state which NFRs are of interest to which stakeholders, what the dependencies are between stakeholders, and what the priorities of a stakeholder’s goals are. Instead, the general objectives listed at the beginning of section 2 of the case study document, the goals mentioned in the description of the non-functional requirements, as well as the goals of the use cases must be correlated with the stakeholders and further refined based on common knowledge. Similarly, because the case study document does not provide information about the advantages and disadvantages of possible solutions, the existing crisis management system is considered as a sole alternative to the CCCMS. According to the case study document, the existing, non-computerized system manually keeps track of crisis information and does not recommend strategies for dealing with the crisis. Given the concerns identified in this section, crosscutting is expected to manifest itself in general between the following concerns. The Coordination concern is crosscut by the three other main functional concerns and their use case concerns. The Coordination concern, on the other hand, slightly crosscuts the Communication concern. Furthermore, the Coordination concern represents the core functionality of the CCCMS. It is an essential requirement, while the other functional concerns could be reduced or removed from the CCCMS. The Coordination concern is hence identified as the base concern. The NFR concerns crosscut several use case concerns and thus the four major functional concerns. In addition, the NFR concerns may crosscut each other. The use cases and thus the four major functional concerns crosscut the stakeholder models as a single use case may impact the goals of several stakeholders.

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

29

Finally, the NFR concerns also crosscut stakeholders and use cases as an NFR may be of interest to many stakeholders in the context of many use cases. Note that AoURN allows for the definition of concerns and the assignment of model elements to concerns. As a concern is also a model element, concerns may be hierarchically structured as described in this section. Because the content of the CCCMS models that are to be built is given by the case study document, the most influential decision made by the modeler is the choice of concerns. A different choice of concern could lead to vastly different and diverse models. However, once the concerns have been defined, the creation of the AoURN and URN models given a static case study document becomes rather mechanical. The biggest challenge is to comply with the description of the problem in the case study document and to consistently assign modeling elements to the correct concerns. Therefore, major design decisions are not expected for the remaining process steps. 4.2 Model Functional Concerns with UCM (P2 – Modified) The textual use cases in the case study document were first translated into a UCM model. Figures 2 and 3 show the Resolve Crisis use case as an example of the UCM model derived from the use cases in the case study document. A UCM model consists of a path that begins at a start point (z, e.g., resolve) and ends with an end point (▌, e.g., resolved). A path may contain responsibilities (±, e.g., recommendMission(s)), identifying the steps in a scenario, and notational symbols for alternative ( ) and concurrent ( ) branches. Path elements may be assigned to a component (†, e.g., Coordinator). Stubs are containers for sub-models called plug-in maps. Drilling into a stub leads to a submap that provides more details, thus allowing for hierarchical structuring of UCM models. A binding between the stub and elements on the plug-in map precisely defines how the scenario continues from the parent map to the submap and back to the parent map. A static stub (‘, e.g., CaptureWitnessReport) may have only one plug-in map, while dynamic stubs ( , e.g., ExecuteMission) may have several different plug-in maps. The UCM model of the Resolve Crisis use case shows that after capturing a witness report, the system recommends missions to be selected by the coordinator. The selected missions are executed, which is shown in more detail on the ExecuteMission plugin map. Once a mission has finished, the mission file is updated and if all missions have been executed, the crisis is resolved. The second out-path of the ExecuteMission stub leading back to recommendMission(s) indicates that if there are problems with the current mission, the use case continues with the system recommending missions based on the current crisis information. In addition, the AND-fork after selectMission(s) shows parallel activity. The waiting place (z, looks like a start point but in the middle of a path) denotes a location in the use case where the system waits for something to happen. If new information is available at the newCrisisAndMissionInfoAvailable start point, the waiting place is triggered and the coordinator assesses the new information. If it is deemed that changes are required to the current missions, then the use case continues with the system recommending missions. If not, the system continues to wait for new information.

30

G. Mussbacher et al.

Fig. 2. UCM Model for the Resolve Crisis Use Case

A replication factor is defined for the plug-in map (see Fig. 3) of the ExecuteMission stub in Fig. 2, indicating that as many missions (i.e., instances of the plug-in map) are started as selected by the coordinator. According to the semantics of a dynamic stub with replicated plug-in maps, these instances run in parallel and do not need to be synchronized. For better readability, the replication factor is also shown in parenthesis in the name of the ExecuteMission stub. A binding formally describes the continuation of the use case from Figs. 2 to 3 in the UCM model (stub’s in-path Ù execute start point; stub’s top out-path Ù resource not available/more missions required/mission failed end point; stub’s bottom out-path Ù executed end point). Therefore, when the path enters the stub in Fig. 2, the use case continues at the execute start point of Fig. 3. It ends either at the executed end point of Fig. 3, exits the stub at its bottom out-path, and hence continues on to updateMissionFile in Fig. 2, or it ends at the resource not available/more missions required/mission failed end point of Fig. 3, exits the stub at its top out-path, and hence loops back to recommendMission(s) in Fig. 2. In Fig. 3, internal and external resources are first requested which may fail (RequestResource(s) stub; again, replication factors define the number of internal and external resources that are requested). If an internal resource request fails, it may be substituted by an external resource request (substituteInternalWithExternalResource responsibility). Upon successful resource allocation, the system assesses whether the resource needs to be transported by helicopter to the crisis location (TransportWithHelicopter stub). If yes, a new mission for

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

31

the helicopter pilot is initiated. In any case, the resource confirms arrival at the crisis location (ConfirmArrival stub), then performs its mission (ExecuteResourceMission stub), before confirming departure (ConfirmDeparture stub). In parallel to this, the resource may receive updated mission information (UpdateMissionInfo stub). The ExecuteResourceMission stub is a dynamic stub because each resource’s mission may be very different from other missions and therefore requires its own plug-in map (e.g., the super observer, rescue, helicopter transport, and the remove obstacle missions). Finally, a mission report may or may not be submitted by the resource before the resource is released.

Fig. 3. UCM Model for the Resolve Crisis Use Case – ExecuteMission Plugin Map

In addition, if the mission was initiated by the super observer, then the super observer is notified about the creation, success, and failure of the mission. The UCM (and AoUCM) models are equivalent to the use case descriptions in the case study document, except for a few corrections due to small errors [23]. For example, it was assumed, for efficiency reasons, that internal and external resources can be assigned in parallel instead of first internal resources and then external resources afterwards. Furthermore, there exists a number of subtle differences due to the nature of use cases and UCM models. While use cases are largely described individually and independently, UCM models capture a complete system view in addition to the individual scenario view. It is certainly possible to visualize use cases with UCMs with a simple one-to-one mapping without considering the interactions between use case descriptions. For example, the status updates for missions initiated by the super observer (steps 7, 8, and 8a.1 of the Execute Super Observer Mission use case in the case study document) could be shown on the map for the super observer mission.

32

G. Mussbacher et al.

However, these notifications can logically only happen once the resources of the desired mission have been assigned, the desired mission was completed, or the desired mission failed, respectively. Therefore, these steps should be and are shown on the ExecuteMission map, ensuring a more consistent model. In such a model, URN’s built-in testing capabilities may verify that these notifications are performed at the right time. 4.3 Model Functional Concerns with AoUCM (P2) For consistency reasons, the UCM model is restructured into an AoUCM model based on the assessment of the whole UCM model against the functional and non-functional concerns identified in section 4.1. Table 1 shows which map elements of the two UCMs from Figs. 2 and 3 belong to which concerns. Although the Coordination concern is identified as the main concern for the two UCMs, large portions of the UCMs can be attributed to five other concerns. Table 1. Assessment of Resolve Crisis UCM Model Against Identified Concerns

Concern Recommend Strategies

Use Case (UCM) Resolve Crisis Resolve Crisis (ResolveCrisis map) (ExecuteMission map) recommendMission(s)

Resource Management Coordination Communication

Super Observer Mission Helicopter Transport Mission

9 CaptureWitnessReport, assessNewCrisisAndMissionInfo (including the AND-fork, waiting place, and starting point)

RequestResource(s), substituteInternalWithExternalResource, releaseResource 9 ConfirmArrival, ConfirmDeparture, Update Mission Info, submitFinalMissionReport receiveMissionCreated, receiveMissionSuccessful, receiveMissionFailed TransportWithHelicopter

9 A checkmark indicates that the map belongs to the concern, including all map elements except for those listed in the same column under a different concern.

The Communication concern has been deemed to deal with the flow of crisis/mission information among the actors and, therefore, includes ConfirmArrival and ConfirmDeparture, which indicate that an assigned resource has arrived or departed, respectively. The Resource Management concern, on the other hand, just deals with the assignment and release of resources. For similar reasons, assessNewCrisisAndMissionInfo belongs to the Communication concern instead of the Coordination concern. The Coordination concern only deals with execution, adaptation, and monitoring of missions, but not with the flow of information.

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

33

A restructuring of the UCM model for the Resolve Crisis use case according to aspect-oriented principles is expected to better encapsulate the four major functional concerns, as well as the Execute Super Observer Mission and Helicopter Transport Mission sub-concerns. Figs. 4 and 5 show the AoUCM model of the Resolve Crisis use case with all tangled concerns removed, leaving only the Coordination concern. The responsibilities assignEmergencyLevel and setCrisisStatusActive have been moved from the CaptureWitnessReport map to Fig. 4, as these two responsibilities do not belong to the Communication concern to which the CaptureWitnessReport map was assigned. The AoUCM model of the Resolve Crisis use case now focuses on the most fundamental elements of the crisis management system, i.e., the coordinator selecting missions, the missions being executed by resources either successfully or not, the mission file being updated accordingly, and the crisis file being closed when the crisis is resolved.

Fig. 4. AoUCM Model for the Coordination Concern – Resolve Crisis Use Case

Fig. 5. AoUCM Model for the Resolve Crisis Use Case – ExecuteMission Plugin Map

34

G. Mussbacher et al.

The remaining concerns described in this section extend the Resolve Crisis use case to define an AoUCM model that is equivalent to the UCM model from Figs. 2 and 3. 4.3.1 Recommend Strategies Concern The Recommend Strategies concern is a rather straightforward concern that is required in two locations in the AoUCM model (i.e., in the Resolve Crisis use case and in the Execute Super Observer Mission use case). AoUCM represents the properties of a concern in a map called aspect map. In the case of scenario models, the properties are behavior and structure and are shown for the Recommend Strategies concern in the top map of Fig. 6 with the system’s recommendMission(s) responsibility. In the aspect map, a pointcut stub ( P , e.g., SelectIndicateMission(s)) represents the matched locations in the AoUCM model to which the concern is to be applied. The causal relationship of the pointcut stub and the concern properties visually defines the composition rule for the concern, indicating how the concern is inserted in the AoUCM model (e.g., before, after, optionally, in parallel, interleaved, or anything else that can be expressed with UCM). In the case of the Recommend Strategies concern, the concern properties are applied before the matched locations because the concern properties appear before the pointcut stub on the aspect map. This can be understood very quickly by simply looking at the aspect map without needing to know where exactly the concern is applied or having to understand the concern’s pointcut expression. The pointcut expression (i.e., the actual pattern to be matched in the AoUCM model in order for the concern to be applied to the AoUCM model) is described on a separate map called the pointcut map. This allows the same pointcut map to be reused for different concerns. A pattern is assigned to a concern simply by plugging the pointcut map into the pointcut stub of the concern. This approach also makes it easier to specify several very different pointcut expressions for the same aspect. The pointcut expressions are defined on different pointcut maps, making each of them simpler to understand. In the case of the Recommend Strategies concern, the pattern indicates that all responsibilities called selectMission(s) or indicateDesiredMission(s) are matched (see bottom map of Fig. 6). Note that grey start and end points only denote the beginning and end of the pattern, but are not part of the pattern itself.

Fig. 6. AoUCM Model for the Recommend Strategies Concern

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

35

Hence, the Recommend Strategies concern adds the system’s recommendMission(s) responsibility before all responsibilities called selectMission(s) or indicateDesiredMission(s). Note that selectMission(s) appears in Fig. 4 while indicateDesiredMission(s) appears on the Execute Super Observer Mission map available in the complete model posted online. When the Recommend Strategies concern is applied to the AoUCM model, aspect markers (¡) are added automatically to the AoUCM model to indicate where the concern is applied. An aspect marker is a type of stub that is linked to a plug-in map called the AoView of a concern. The bindings of the AoView to the aspect marker are also established automatically.

Fig. 7. Aspect Marker and AoView for the Recommend Strategies Concern

The AoView is identical to the aspect map of the concern except that only those elements are highlighted that are relevant for the aspect marker. For example, the AoView of the Recommend Strategies concern shown in Fig. 7 indicates that the part of the map from the recommend start point to the pointcut stub is inserted at the location of the added aspect marker. Because the AoView is based on the aspect map, it is always possible to visualize the properties of a concern that are added at a particular location in the AoUCM model without having to resolve complex layout issues.

36

G. Mussbacher et al.

4.3.2 New Crisis and Mission Info Concern The New Crisis and Mission Info sub-concern of the Communication concern highlights a more complex composition rule involving loops and concurrency. The subconcern matches against the selectMission(s) responsibility of the Resolve Crisis use case. As visualized by the pointcut stub, an AND-fork is added after the selectMission(s) responsibility. This AND-fork spawns the handling of new information described earlier for Fig. 2 while the base behavior continues. If changes are required, the spawned branch loops back to the pointcut stub (i.e., the coordinator selects missions again). Note that the newCrisisAndMissionInfoAvailable start point must be indicated as a start point local to the concern (crossed out start point symbol), since otherwise bindings between the aspect marker and the AoView of this concern cannot be established automatically. If a local start point is not indicated, it becomes ambiguous which of the two start points of the aspect map should be used for the binding with the aspect marker.

Fig. 8. AoUCM Model for the Communication Concern – New Crisis and Mission Info

Although the pointcut expression of the sub-concern in Fig. 8 only identifies one location and thus does not exhibit strong crosscutting, the sub-concern has to be viewed in the context of its parent concern Communication. The Communication concern crosscuts other concerns several times as shown in Table 1 (the complete version of Table 1 that shows all concerns affected by the Communication concern is also posted online with the complete model).

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

37

4.3.3 Resource Management Concern The Resource Management concern requires a pointcut stub with more than one outpath. This is because the pattern that needs to be matched is the complete ExecuteMission map shown in Fig. 5. Therefore, the ExecuteMission map is reused as is for the pointcut map of the Resource Management concern which is only possible because AoURN clearly separates aspectual properties (i.e., the aspect maps) from the pointcut expressions (i.e., pointcut maps). The start point of the ExecuteMission map is connected to the in-path of the ExecuteMission pointcut stub, the executed end point is connected to the out-path exiting the pointcut stub on the right, and the more missions required/mission failed end point is connected to the out-path exiting the stub at the bottom.

(Pointcut map not shown here since it is the same as Fig. 5) Fig. 9. AoUCM Model for the Resource Management Concern

When the concern is applied, aspect markers are added before the start point and after the end points of the ExecuteMission map and bindings to the Resource Management concern are established (see Fig. 10 — note that the bindings are only shown for illustrative purposes and are not part of AoURN’s concrete syntax; the jUCMNav tool maintains bindings much more effectively). The aspect markers clearly visualize how much the Resource Management concern crosscuts the ExecuteMission map. The insertion of aspect markers results in the following effect. Before the execute start point is reached, the scenario follows the binding to continue on the concern map with requesting resources, possibly substituting internal resources with external resources. If the resource request is successful, the scenario returns to the ExecuteMission map by following the binding. Upon successful execution of the mission, the aspect marker after the executed end point is reached and the scenario follows the binding to continue on the concern map with releasing the resource. If, however, the resource request is not successful, the scenario ends with the failed end point on the concern map which is

38

G. Mussbacher et al.

linked by a binding with the aspect marker after the more missions required/mission failed end point. The scenario, therefore, continues at this aspect marker, skipping the ExecuteResoureMission stub on the ExecuteMission map as desired.

Fig. 10. Aspect Markers and Bindings for the Resource Management Concern

The model in Fig. 10 highlights an omission in the case study document: the handling of failed missions (e.g., when should resources be released). The case study document was treated as a snapshot of the current understanding of the system, rather than a final, contractually binding requirements document. In that sense, the models were built based on the document, reflecting the document as is with all its omissions with the understanding that the models would be reviewed again by the stakeholders. However, care was taken to ensure that the resulting models are consistent and major omissions were documented. Four major issues that should be addressed are a) the system currently assumes that only one witness report is captured per crisis, b) internal and external resources are treated differently, c) helicopter transport missions are only mentioned for transporting resources to the crisis location, but not from the crisis location, and d) it is not specified in detail what happens when missions fail and the resource is already at the crisis location. Issue (a) possibly requires additional steps in Capture Witness Report to connect additional witness reports to an already existing crisis (and possibly take no action if no new information is received). Issue (b) possibly requires external resources to be treated more like internal resources instead of assuming that external resources will always respond to a request within an appropriate time frame. Issue (c) possibly requires another helicopter transport mission to be

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

39

created after a resource finished executing its mission and before confirming departure from the crisis location. Issue (d) possibly requires the behavior of each resource to be defined in more detail for the fail case. 4.3.4 Helicopter Transport Mission Concern The Helicopter Transport Mission sub-concern (Fig. 11) of the Coordination concern showcases a) the anything pointcut element and b) composition rules that can interleave two scenarios with each other. The purpose of this sub-concern is to check whether the resource must be transported to the crisis location by helicopter. The check must occur right after the execute start point of the ExecuteMission map. If the helicopter is not required, the scenario simply continues with the ExecuteMission map. If a helicopter is required, then the current mission is put on hold (see wait for helicopter waiting place in Fig. 11) and a helicopter mission is started. The start of the new helicopter mission, however, must be connected to the more missions required/mission failed end point of the ExecuteMission map to fit into the overall flow of the Resolve Crisis use case. Therefore, the Resolve Crisis use case and the Helicopter Transport Mission use case must be interleaved.

Fig. 11. AoUCM Model for the Coordination Concern – Helicopter Transport Mission

This is achieved by matching against the complete path from the execute start point to the more missions required/mission failed end point with anything in between as indicated by the anything pointcut element (.....). The more missions* end point is then connected to the out-path exiting the pointcut stub at the bottom which connects to the start helicopter mission end point, ensuring that these two end points merge into one path. By placing a pair of grey end and start points on the pointcut map, the modeler indicates that the concern may transform elements within the matched pattern at

40

G. Mussbacher et al.

the location indicated by the pair. In the Helicopter Transport Mission case, the grey end point is connected to the out-path exiting the pointcut stub on the right. Therefore, whatever follows on this out-path will occur right after the execute start point and before anything matching against the anything pointcut element. Interleaved composition rules are useful to maintain an overall understanding of the concern. Without interleaved composition, the only alternative is often to split the concern into several smaller, disjoint concerns that add behavior at the various places as required. This makes it difficult to understand what the concern generally wants to achieve. The anything pointcut element, on the other hand, is useful to safeguard against changes to the base model. For example, other concerns could add behavior after the execute start point making it difficult to maintain correct matches if the pointcut expression has to explicitly state the exact match. The remaining concerns required to describe an AoUCM model that is equivalent to the UCM model from Figs. 2 and 3 are rather straightforward and, therefore, only briefly summarized here. The Capture Witness Report sub-concern of the Communication concern ensures that witness reports are captured before the Resolve Crisis use case starts. The Communicate with Resource at Location sub-concern of the Communication concern ensures that a resource confirms arrival at and departure from the crisis location, receives updates while at the crisis location, and submits a final report. Finally, the Super Observer Status Updates sub-concern of the Execute Super Observer Mission use case ensures that the super observer is informed of the creation, successful completion, or failure of a mission initiated by the super observer. 4.4 The Concern Interaction Graph (P7) Whenever several concerns are applied to a model, the possibility exists that concerns may interact with each other in undesired ways. The CCCMS is not an exception. AoURN models the dependencies and conflicts of concerns as well as their resolutions in a specialized GRL goal graph called Concern Interaction Graph (CIG) [24]. The CIG uses GRL links to model dependencies ( ) and conflicts ( ) of concerns. The direction of the link indicates the resolution in terms of a precedence rule, i.e., the target of the link has a higher precedence than the source of the link. Therefore, link targets are applied earlier than link sources to the AoURN model. For example, the CIG in Fig. 12 shows a contribution link between the Recommend Strategies concern and the New Crisis and Mission Info concern. This indicates that there is a conflict between these two concerns and that the resolution of the conflict is to apply the Recommend Strategies concern second. The root of the conflict is that the pointcut maps of both concerns match against the selectMission(s) responsibility (see Figs. 6 and 8). The Recommend Strategies concern adds the recommendMission(s) responsibility before the selectMission(s) responsibility (see Fig. 6), while the New Crisis and Mission Info concern adds (among other elements) an OR-join before the selectMission(s) responsibility (see Fig. 8). If the Recommend Strategies concern is applied first and the New Crisis and Mission Info concern second, the ORjoin will be closer to the selectMission(s) responsibility than the recommendMission(s) responsibility. In this case, the system will not recommend missions when new information becomes available because the OR-join merges into the path after the

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

41

recommendMission(s) responsibility. Therefore, the resolution defines that the New Crisis and Mission Info concern must be applied before the Recommend Strategies concern.

Fig. 12. Concern Interaction Graph for the Concerns Mentioned in Section 4.3

Some conflicts of concerns cannot be resolved with an ordering of the concerns, but require changes to one or more concerns. The CIG can model these situations if the changes to the concerns are defined in a separate concern, i.e., a feature interaction concern. In this case, the CIG would show dependencies between the feature interaction concern and the conflicting concerns. If the required changes are made directly in the conflicting concerns, the CIG would not be able to indicate the conflict. In any case, the CIG does not show the constraint that the feature interaction concern has to be applied if the conflicting concerns are applied, since this is best modeled with established feature modeling techniques. Given the ordering of the concerns specified by the CIG, all concerns may now be applied to the AoUCM model. Fig. 13 shows the complete AoUCM model for the Resolve Crisis use case with the automatically added aspect markers for all concerns mentioned in this section. Label CRL of an aspect marker stands for the Communicate with Resource at Location sub-concern, CWR for the Capture Witness Report subconcern, HTM for the Helicopter Transport Mission sub-concern, NCM for the New Crisis and Mission Info sub-concern, RSM for the Resource Management concern, RST for the Recommend Strategies concern, and finally SOS for the Super Observer Status Updates sub-concern.

42

G. Mussbacher et al.

RST NCM

CWR

HTM RSM

NCM

SOS CRL

HTM SOS RSM RSM SOS CRL

Fig. 13. The Resolve Crisis Use Case with the Aspect Markers of All Mentioned Concerns

4.5 Build a Test Suite for the UCM and AoUCM Models (P3) The capability to establish a test suite for the scenario model is one of the analysis features of URN. The test suite consists of a set of standardized scenario definitions [1] organized into scenario groups. Given a scenario definition, the traversal mechanism of the jUCMNav tool highlights the path of the scenario through the UCM model (i.e., the scenario is traversed or executed). Transformations of executed scenarios to message sequence charts are also supported, hence providing a complementary end-to-end visualization of the execution. A prerequisite for this feature is URN’s global data model. For each choice point in the UCM model (including OR-forks and dynamic stubs), Boolean expressions are defined for all alternatives. Boolean expressions may also be defined for start points, thus defining path preconditions. The expressions may contain global Boolean, Integer, and Enumeration scenario variables. A simple action language allows responsibilities to change the value of variables during the traversal of the scenario. Each scenario definition specifies its pre- and postconditions, its start points and expected end points, as well as initial values for the global variables as required. As an example, consider a scenario for the Resource Management concern defined in Fig. 9. The scenario describes the situation where an internal resource is requested

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

43

first, but does not accept the request. An external resource is then requested as a substitute, but this request is also denied. The choice points for this scenario are the selection policies of the plug-in maps of the RequestResource(s) stub. Therefore, two Integer variables, NrInternalResources and NrExternalResources are defined, indicating how many resources are requested. The selection policy of the Assign Internal Resource plug-in map is, therefore, NrInternalResources > 0, while the selection policy of the Request External Resource plug-in map is NrExternalResources > 0. In addition, the substituteInternalWithExternalResource responsibility is further formalized with the following code: NrInternalResources = NrInternalResources - 1; NrExternalResources = NrExternalResources + 1;

Two further Boolean variables are required to capture the decisions of the internal and external resources: InternalResourceAccepts and ExternalResourceAccepts. Table 2. Scenario Definition for Resource Management Concern Scenario Definition 1) Start Point Request Resources: request Precondition n/a End Point Request Resources: failed Postcondition NrInternalResources == 0 && NrExternalResources == 1; Initialization NrInternalResources == 1; NrExternalResources == 0; InternalResourceAccepts == false; ExternalResourceAccepts == false; 1)

Note that this scenario definition is a simplified version of the one created for the CCCMS model.

When the scenario definition in Table 2 is executed, the traversal mechanism will traverse the path from the start point request to the dynamic stub and then execute the Assign Internal Resource plug-in map where the request is not accepted. The scenario exits the stub along the out-path with the substituteInternalWithExternalResource responsibility, loops back to the dynamic stub, and now chooses the Request External Resource plug-in map because the substituteInternalWithExternalResource responsibility changed the values of the NrInternalResources and NrExternalResources variables. On the Request External Resource plug-in map, the request is also not accepted and the stub is exited along the out-path leading to the failed end point. The scenario finishes successfully at this end point as its required end points were reached and its postcondition is fulfilled. Scenario definitions can be executed as regression tests whenever there are changes to the model, ensuring greater confidence in the validity and consistency of the scenario models. Recently, scenario definitions have been extended with aspect-oriented concepts [25], allowing not only the specification model, but also the validation model to be organized according to aspect-oriented principles. Current tool support does not yet allow end-to-end scenarios to be defined that involve several concerns in an AoUCM model. However, it is possible to test concerns individually in an AoUCM model as shown in the above example. As proof of concept, about 20 scenario definitions were created for the CCCMS UCM and AoUCM models.

44

G. Mussbacher et al.

4.6 Model Non-functional Concerns with UCM and AoUCM (P4 – Modified) While the functional concerns discussed so far do crosscut each other to a certain extent, non-functional concerns tend to crosscut other concerns on a much larger scale. This is also true for the CCCMS case study. NFR concerns can be thought of as layers that are added to the functional concerns, similar in fashion to placing transparencies with the layout of electrical wiring or plumbing on top of a floor plan of a house. The impact of NFR concerns is often widespread throughout the AoUCM model and often extremely time-consuming and error-prone to model with standard UCM models due to the large number of affected locations that have to be explicitly defined in the UCM models. To ensure consistency between the AoURN and URN models, the UCM models for the non-functional concerns are, therefore, created with the help of the AoUCM models which already identify the affected locations. In some cases, the description of an NFR concern (e.g., in section 2.3 of the case study document) hints at further functionality that is not covered by the use cases later in the document. For example, managing resource and strategy information is mentioned in the Persistence NFR concern. In such cases, the NFR concern is only applied to the functionality described by the existing use cases as no new requirements are to be added to the case study. Therefore, no new base use cases were added based on the NFR descriptions. However, the requirements for an NFR concern do introduce new functionalities for the concern itself (e.g., statistical data needs to be analyzed in the Statistical Logging NFR concern). AoUCM models these functionalities of NFR concerns. To be more precise, AoUCM models the operationalization of NFR concerns, i.e., a particular behavior that ensures the desired characteristics of the NFR concern. The description may be as detailed or abstract as required, reflecting how much is known about the NFR concern at the time the model is built. As the case study document does not address the behavioral aspect of NFR concerns at all, the AoUCM description of the NFR concerns is kept as abstract as possible to minimize the introduction of new requirements. Furthermore, the goal models discussed in section 4.7 make it even clearer that an operationalization described with AoUCM models is only one option out of many. The Availability NFR concern in Fig. 14 describes, in a very abstract way, redundancy as a means to achieve availability. Each responsibility of the system is shadowed in parallel by the backup system. The Availability NFR concern makes use of a variable (indicated by a $, e.g., $Task). Variables are defined on the pointcut map and can then be reused on the aspect map, thus allowing existing model elements that are matched by the pointcut map to be reused in aspects. As usual, aspect markers are added to the AoUCM model for each match of the pointcut map in the AoUCM model and then linked to the AoView of the Availability NFR concern. In this AoView, the variable $Task is replaced by the actual match. For example, when the responsibility assignEmergencyLevel from Fig. 4 is matched, the AoView of this match shows the assignEmergencyLevel responsibility instead of the $Task responsibility in the Backup System. Note that the pointcut map matches against any system responsibility. Clearly, this is an NFR concern with a very significant impact on the AoUCM model.

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

45

Fig. 14. AoUCM Model for the Availability Concern

In addition to the path with the pointcut stub, the aspect map of the Availability NFR concern also defines with a separate path what happens if the primary system fails. This is concern-specific behavior that is described at a very high level of abstraction. It could have also been described on a separate map without changing the meaning of the AoUCM model.

P

Fig. 15. AoUCM Model for the Mobility Concern – Infrastructure

46

G. Mussbacher et al.

The Infrastructure sub-concern of the Mobility NFR concern in Fig. 15 is another example of a concern with wide-reaching impact. In addition, this NFR concern demonstrates the usage of the replacement pointcut stub ( P ), a special kind of pointcut stub indicating that the concern is replacing the matched base elements. Furthermore, two patterns are described for the Infrastructure concern with the help of two pointcut maps that are both plugged into the pointcut stub on the aspect map. The first pattern captures all interactions between the system and a number of mobile actors where the system is the sender. The second pattern captures a similar situation but with the system as the receiver. The NFR concern then replaces the matched pattern (i.e., the sender and receiver components) with the behavior specified on the aspect (i.e., the sender and receiver are added back again but this time with the GSM Antenna functionality in the middle). When the Infrastructure concern is applied, aspect markers are again added to the AoUCM model. However, different symbols are used for aspect markers to immediately indicate the replacement to the modeler. The tunnel entrance aspect marker ( ) denotes the beginning of a replacement and the tunnel exit aspect marker ( ) denotes the end of a replacement (the concern may be thought of as a tunnel through the AoUCM model that circumvents the original behavior). In terms of the bindings to AoViews that are established for these markers, tunnel entrance aspect markers only have bindings to AoViews, while tunnel exit aspect markers only have bindings from AoViews (see Fig. 16). The pointcut expression of the Infrastructure concern is matched three times on the ExecuteMission map shown in Fig. 16 as indicated by the three pairs of tunnel entrance and exit aspect markers. For the top pair, the System and Resource were matched against $Sender and $Receiver, respectively, by the first pointcut map in Fig. 15. The AoView at the bottom of Fig. 16 clearly indicates this by replacing $Sender with System and $Receiver with Resource in the aspect map. For the other two pairs of aspect markers, Resource was matched against $Sender and System was matched against $Receiver.

System

Resource

P Fig. 16. Aspect Markers and Bindings for the Mobility Concern – Infrastructure

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

47

The last NFR concern to be discussed for AoUCM in this paper is the Weather Information System sub-concern of the Safety NFR concern in Fig. 17. Its purpose is to monitor the weather and determine if a safety perimeter is required for the crisis location. This is an ongoing activity throughout the crisis. Therefore, the monitoring starts at the time the crisis status is set to active. It ends when the crisis has been resolved. Similar to the Helicopter Transport Mission concern from Fig. 11, a path from the setCrisisStatusActive responsibility to the resolved end point is matched with the help of the anything pointcut element. An AND-fork before the pointcut stub on the aspect map spawns the parallel behavior of the NFR concern (i.e., just before the setCrisisStatusActive responsibility at the beginning of a crisis). A second AND-fork provides new weather information on one branch and on the second branch sets a timer which ensures that the weather is checked periodically. When a timeout occurs, the scenario loops back, thus providing more weather information and setting the timer again. This continues until the timer is deactivated by the out-path of the pointcut stub which is connected to the resolved end point (i.e., it is deactivated after the resolved end point is reached at the end of the crisis).

Fig. 17. AoUCM Model for the Safety Concern – Weather Information System

4.7 Model Stakeholder Concerns with GRL and AoGRL (P5 – Modified) The objectives of the CCCMS and the high-level goals associated with the NFRs in the case study document were first modeled in GRL and AoGRL models that focus on the dependencies between stakeholders. The result of this analysis is shown for GRL in Fig. 18. A GRL model consists of intentional elements (e.g., softgoals ( , e.g., Handle incident efficiently), hard goals ( , e.g., Report incident), and tasks ( , e.g., Resolve Crisis in Fig. 19)) connected together with different types of links (note that not all link types are discussed here since they are not needed for the examples presented in this section). Intentional elements may be assigned to stakeholders called , e.g., Coordinator). Contribution links (→) indicate positive (+) or negaactors ( tive (–) impact of intentional elements on each other. A dot above a + or – indicates that the contribution is sufficient whereas a dot below a + or – indicates that it is not. Dependency links ( ) describe how a source element depends on a target element. Often, a modeler will use two consecutive dependency links to indicate that the initial source element (depender) depends on the second target element (dependee) for the middle element (dependum).

48

G. Mussbacher et al.

In addition to the dependencies, Fig. 18 shows the goal model of the Coordinator stakeholder in more detail. In general, the Government, the Resource, and the General Public depend on the Coordinator for improving customer QoS metrics, for mission requests that allow a resource to handle an incident efficiently, and for receiving appropriate help in a timely fashion, respectively. The General Public also depends on the Resource to do its job, while the Coordinator depends on the Resource to provide updates about its status and location and on the General Public to report the incident in the first place.

Fig. 18. GRL Model for Stakeholder Dependencies

The AoGRL version of the GRL model in Fig. 18 simply separates each stakeholder into its own goal graph, repeating each dependum as required. This is a case where aspect-oriented thinking provides guidance on how to structure the views of the goal model, even though aspect-oriented techniques are not required to achieve this. Standard separation of concerns with basic GRL modeling is sufficient. The GRL goal model in Fig. 19 illustrates the impact of all functional concerns (i.e., use cases) on the stakeholder goal graphs. Typically, tasks model solutions that impact positively or negatively some of the goals specified for one or more stakeholders. The solutions may then be described in more detail with UCM models as is the case here (e.g., the general Resolve Crisis task corresponds to the detailed Resolve Crisis use case map). Similar to before, the AoGRL model splits the single goal graph into individual AoGRL goal graphs — one for each functional concern. However, this is not a oneto-one transformation, because the tangling that exists in the UCM model has been carried over into the GRL model. For example, the Resolve Crisis task has an impact on the Select the right missions based on past experience goal only because the

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

49

recommendMission(s) responsibility is part of the Resolve Crisis use case map in the

UCM model. In the AoUCM model, however, this has been factored out into the Recommend Strategies concern. Therefore, the impact on the Select the right missions based on past experience goal is shown on the Recommend Strategies AoGRL goal graph, but not on the Resolve Crisis AoGRL goal graph.

Fig. 19. GRL Model for Impact of Use Cases on Stakeholders

Finally, the NFR concerns are also modeled with GRL and AoGRL. As an example, the Availability NFR concern is shown in Fig. 20 for GRL and in Fig. 21 for AoGRL. The two models are equivalent in terms of content, but are structured very differently. In both cases, the availability requirement 2hrs of downtime every 30 days, failure recovery within 30sec must first be discovered in the case study document. Then, it was decided which goals of which stakeholders are affected by this requirement. Fig. 20 shows that the Government and the General Public have an interest in this requirement and therefore the Availability NFR concern. Because the Government and the General Public depend on the Coordinator and the Resource (see Fig. 18), the availability requirements also depend on the Availability softgoals of the Coordinator and the Resource. This is modeled by the dependencies between the availability requirement and the Availability softgoals. Last but not least, one has to consider not only the stakeholders, but also the functional concerns. Any functional concern that has an impact on the Coordinator or the Resource now also depends on the Availability softgoal. In other words, a functional concern cannot be considered achieved, if availability for the functional concern is not provided for the stakeholder. Therefore, the dependency links are established between the tasks and the Availability softgoals.

50

G. Mussbacher et al.

Fig. 20. GRL Model for Availability NFR Concern

P

P

P P P

P P

P

P

P

Fig. 21. AoGRL Model for Availability NFR Concern

AoGRL uses a different approach than AoUCM in terms of modeling the properties of a concern, the pattern that needs to be matched, and the composition rules. Owing to the highly interconnected nature of goal models, everything is modeled on one goal graph called the pointcut graph. AoGRL makes use of pointcut markers ( P ) and pointcut deletion markers (±) to indicate the pattern to be matched. All elements

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

51

without pointcut markers are added to the matched location in the GRL base model, while elements with a pointcut deletion marker are removed. The composition rule is, therefore, defined by the set of links between elements without markers and elements with markers. The AoGRL version of the Availability NFR concern rather describes the reasons behind the dependencies that were established explicitly in Fig. 20 by the standard GRL approach. The pattern in Fig. 21 states that dependencies (the ones without markers) should be added to the model as long as there exists a dependency from a stakeholder interested in the availability requirement (shown on the right of Fig. 21) to another stakeholder (shown on the left in Fig. 21). In this case, the Availability softgoal is added to the stakeholder on the left and dependencies are established to the stakeholder on the right and any tasks that impact the stakeholder on the left. The top part of the pointcut expression in Fig. 21 therefore matches against the Government stakeholder with the Improved customer QoS metrics goal and the General Public stakeholder with the Receive appropriate help in case of an incident in a timely fashion softgoal, because dependencies exist from these two intentional elements to other stakeholders (i.e., to Coordinator and Resource). Hence, the 2hrs of downtime every 30 days, failure recovery within 30sec softgoal is added to the Government and General Public stakeholders, the Availability softgoal is added to Coordinator and Resource stakeholders, and dependencies are added between these two softgoals. Furthermore, all tasks contributing to an intentional element in the Coordinator and Resource stakeholders now also depend on the Availability softgoal (e.g., the Capture Witness Report task and the Super Observer Mission task). Note that the keyword indicates that the pattern may match against any type of intentional element and not only the one shown on the goal graph. While the pointcut expression shown in Fig. 21 is very general as it uses several pointcut elements with a *, it may be further restricted as needed by replacing the * with more specific expressions. For example, the pointcut expression could be restricted to specific tasks or to specific intentional elements in the left actor in Fig. 21 or to a specific dependum. If required, the Availability goal of the concern can be further refined on one or more separate goal graphs of the concern. These goal graphs are called aspect graphs and may show alternative, ideally generic solutions for achieving availability. For example, the redundancy solution described in the AoUCM model is shown on such an aspect graph (see complete models posted online). 4.8 Evaluate Stakeholder Concerns (P6) Two strategies were created, one for the existing system and one for the new system, in order to evaluate the GRL and AoGRL models. Because the case study document lacked detailed information regarding the existing system and the alternatives for a new system, this exercise proved to be rather arbitrary and is, consequently, not further reported on. The reader interested in more information about strategies is referred to [1, 17]. It should also be pointed out that there is no tool support available for evaluations of AoGRL models. AoGRL models have to be first composed into a standard GRL model and then evaluated with the standard evaluation mechanism.

52

G. Mussbacher et al.

5 Comparison of URN and AoURN The comparison of URN and AoURN is based on the models described in section 4. For the AoUCM model, the models described in section 4.3 and section 4.6 are used. For the UCM model, the original model for the functional concerns described in section 4.2 is used. In addition, the UCM model for NFR concerns is derived by transforming the AoUCM model of the NFR concerns into a standard UCM model as motivated in section 4.6. Technically, this is achieved by a two-step transformation process. First, stubs are explicitly placed at each location where an aspect marker would be added by the AoUCM approach. The aspect maps are also transformed into standard UCMs by removing all pointcut stubs. New start points have to be added at the beginning of the pointcut stubs’ out-paths and new end points at the end of the pointcut stubs’ in-paths — creating several, possibly disjoint paths on the transformed aspect maps. Bindings are then established between the explicitly added stubs and the start and end points on the transformed aspect maps. If an NFR concern makes use of variables on the aspect map, the aspect map is different for each aspect marker as the variable is replaced by the matched base elements. It is not pragmatic considering the effort required to create different plug-in maps in the UCM model — one for each stub that was added for an aspect marker — because some NFR concerns with variables add more than 50 aspect markers to the model. Instead, parameters are defined for each stub replacing an aspect marker. The parameters are then passed into the stub’s plug-in map and determine the actual values of the variables. This approach is supported by URN’s extensions mechanism based on metadata. Therefore, a single plug-in map can still be used, avoiding an explosion of model elements and maps in the UCM model. Second, to further ensure the correctness and consistency of the AoUCM and UCM models, the UCM model is then carefully inspected for any locations that should not have been affected by NFR concerns and for locations that are affected, but were missed in the UCM models. The transformation explained above ensures minimum impact on the maps in the UCM model that are affected by an NFR concern, while also ensuring maximum modularity/reusability as the maps for the NFR concerns are reused by several stubs. In addition, the size of the model remains minimal. It is thus a very appropriate candidate model to be compared with AoUCM. The resulting UCM model is consistent with the AoUCM model in terms of content, but it is also the most efficient model that could have been created by a modeler even without any aspect-oriented knowledge. The alternative approach is to explicitly add the behavior of an NFR concerns into the maps affected by the NFR concern. Again, this is not feasible given that the NFR concerns Availability, Mobility, Persistence, and Security together are applied more than 250 times in the model. The comparison of GRL and AoGRL is based on the models described in section 4.7. 5.1 Metrics-Based Evaluation The evaluation of the AoURN and URN models is carried out based on metrics for modularity, reusability, and maintainability of aspect-oriented software available in

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

53

literature [11]. The metrics are adapted for the use in URN and AoURN models by mapping the notion of component, operation, and line of code in [11] to URN and AoURN model elements as explained in Table 3. As the metrics are merely adapted, the quality model still applies to this evaluation. The quality model links the metrics to the qualities of interest and is established in [11] with the help of Basili’s GoalQuestion-Metric (GQM) methodology [26]. Although the metrics in [11] were established to assess aspect-oriented implementations at the programming level, they do also apply to the modeling level as the difference is mainly a matter of abstraction. The concepts used for the original metrics are components, operations, and lines of code (LOC) and hence rather programmingcentric. However, these programming-centric concepts relate to much larger concepts generally applicable to all modeling levels: containers, behavioral units, and elementary units. The mapping from the original programming-centric concepts to AoURN and URN concepts retains these generally applicable concepts. Goal graphs and use case maps are containers of goals trees and scenario paths, the behavioral units of GRL and UCM models are described by intentional elements and responsibilities/stubs, respectively, and any modeling element may be considered an elementary unit. Therefore, the general structure that is assessed by the metrics from [11] at the programming level also exists in AoURN and URN models, allowing us to apply the metrics at a different abstraction level. Table 3. Mapping for the Adapted Metrics Notion from [11] Component Operation LOC 1)

URN/AoURN Model Elements Model Unit (MU) goal graph, use case map Key Model Element intentional element, responsibility, stub (KME) (including references) any visual URN/AoURN model element Model Element (ME) (including references and concerns) 1)

Direction arrows and empty points are not counted.

The definition of each metric is summarized in Table 4. In general, the lower the result of a metric, the better it is. The metrics in group A measure the identified concerns, the metrics in groups B and C measure the model units (i.e., goal graphs and use case maps), while the metrics in group D measure the whole model. As an example for the metrics calculation and illustration of the advantages of AoUCM over UCM, the Resolve Crisis UCM model is presented in Fig. 22. The corresponding AoUCM model is shown in Fig. 4. The stubs in the Resolve Crisis UCM model address all modeled NFR concerns. Label AV of a stub stands for Availability, PE for Persistence, CAM for Criminal Activity Monitoring System, EM for Emission Monitoring System, WI for Weather Information System, AU for Authentication, EE for Encryption (Encrypt), ED for Encryption (Decrypt), and finally ST for Statistic Logging.

54

G. Mussbacher et al. Table 4. Definition of Metrics

A) Separation of concerns metrics [Measures concerns] CDMU (Concern Diffusion over Model Units) Count the number of MUs whose main purpose is to contribute to a concern plus all other MUs that reference them. CDKME (Concern Diffusion over Key Model Elements) Count the number of KMEs whose main purpose is to contribute to a concern. CDME (Concern Diffusion over Model Elements) Count the number of concern switches from a concern to other concerns in each MU. B) Coupling metrics [Measures model units] CBMU (Coupling between Model Units) Count the number of other MUs on which an MU depends. C) Cohesion metrics [Measures model units] LCOKME (Lack of Cohesion in Key Model Elements) Count the number of KMEs in an MU that do not contribute to the MU’s main concern. D) Size metrics [Measures the model] VS (Vocabulary Size) Count the number of MUs and concerns in the model. NME (Number of Model Elements) Count the number of MEs in the model. AvNME (Average Number of Model Elements) Calculate the average number of MEs per goal graph and UCM in the model.

For the CDMU metric, the UCM model in Fig. 22 counts towards the Resolve Crisis concern and also towards each of the eight NFR concerns represented by stubs, because the stubs reference the main maps of these concerns. The AoUCM model in Fig. 4 only counts towards the Resolve Crisis concern. Therefore, the score is 1 for AoUCM and 9 for UCM. For the CDKME metric, the UCM model must count all 34 stubs that are added because of the NFR concerns. Therefore, the score is 0 for AoUCM and 34 for UCM. For the CDME metric, 75 concern switches exist in the UCM model while no concern switch exists for the AoUCM model. Therefore, the score is 0 for AoUCM and 75 for UCM. For the CBMU metric, all plug-in maps have to be counted. For UCM, there is one in CaptureWitnessReport, two in ExecuteMission, plus the eight NFR concerns. For AoUCM, there are the two in ExecuteMission. Therefore, the score is 2 for AoUCM and 11 for UCM. For the LCOKME metric, all 34 stubs of the NFR concerns, the CaptureWitnessReport stub, the recommendMission(s) responsibility, and the assessNewCrisisAndMissionInfo responsibility must be counted. For AoUCM, the count is zero. Therefore, the score is 0 for AoUCM and 37 for UCM. For the VS metric, all concerns as well as the pointcut maps must be counted for the AoUCM model, but do not have to be counted for the UCM model since they do not exist in the latter model. The use case map must be counted in both cases. Therefore, the score is 2 for AoUCM and 1 for UCM. Note that the Resolve Crisis concern does not have a pointcut map because it is deemed to be the base. The other concerns in the complete AoUCM model, however, have at least one and as many as four pointcut maps.

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

55

For the NME metric, the concerns have to be counted for the AoUCM model while the stubs added by the NFR concerns have to be counted for the UCM model. In addition, all other N model elements shown in Figs. 4 and 22 also have to be counted. However, the counts of these model elements even out because all model elements are used on some map in both complete models. Therefore, the score is 1+N for AoUCM and 34+N for UCM. Finally, the AvNME metric divides the NME metric by the number of goal graphs and use case maps in the system. It is, therefore, meaningless to compute this metric for only one use case map.

CaptureWitnessReport

EE

ST AV

PE

ED

PE

ST

AU ED

EE AU

AU EE ED PE

EE

AU

ED ExecuteMission (repFactor=#Missions)

ED

EE AU

AV PE

AV PE AV

PE

EE

ED

ST CAM EM WI

AU

Fig. 22. UCM Model for the Resolve Crisis Use Case with All NFR Concerns Considered

The assessment of the GRL and AoGRL models is done in an analogous way to the above example. The overall results of the metrics assessment are shown in Tables 5 and 6 with the better result shown with a grey background. The coupling and cohesion metrics (CBMU, LCOKME) are significantly better for AoURN than for URN as are the separation of concern metrics (CDMU, CDKME, CDME). In short, AoURN outperforms URN for all metrics except the Vocabulary Size (VS).

56

G. Mussbacher et al.

The AoURN-based approach introduces new modeling elements (i.e., concerns, pointcut maps, and pointcut graphs), into the model, explaining the difference in the results of the VS metric. The concerns, however, are used to group the AoURN model into more manageable sub-models, which each contain a very small number of diagrams. Furthermore, the VS metric result is offset by the better results of AoURN for the Number of Model Elements (NME) metric and the Average Number of Model Elements (AvNME) metric. Essentially, the AoURN model is generally smaller, with less complex diagrams than the URN model. AvNME has been reduced by a factor of three for AoURN models as compared to URN models. Moreover, concerns are encapsulated in AoURN models to a greater extent than in URN models as demonstrated by the separation of concerns, coupling, and cohesion metrics. Therefore, the results of VS do not allow concluding that URN is a better approach than AoURN. Table 5. Results of the Separation of Concerns Metrics

Functional Concerns NFR Concerns Stakeholder Concerns Total

CDMU

UCM CDKME

CDME

CDMU

AoUCM CDKME

CDME

25

123

179

41

125

29

112

316

691

31

58

9

n/a

n/a

n/a

n/a

n/a

n/a

137

439

870

72

183

38

CDMU

GRL CDKME

CDME

CDMU

AoGRL CDKME

CDME

0

28

20

21

20

10

11

46

6

6

40

0

13

4

45

11

Functional Concerns NFR Concerns Stakeholder Concerns Total

3

58

14

132

39

31

105

21

Grand Total

151

571

909

103

288

59

Table 6. Results of the Coupling, Cohesion, and Size Metrics

UCM GRL Total – URN AoUCM AoGRL Total – AoURN

CBMU 110 8 118

LCOKME 378 34 412

VS 29 7 36

NME 749 187 936

AvNME 26 27 27

45 13 58

6 14 20

90 39 129

594 206 800

9 11 9

AoURN clearly outperforms URN for NFR concerns. Interestingly, when focusing on the functional concerns alone (Table 5), the Separation of Concern metrics CDMU and CDKME are slightly better for UCM models than for AoUCM models. The

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

57

difference for the CDKME metric is insignificant. The results of the CDMU metrics can be explained by the fact that the CDMU metric for a model with only one model unit (i.e., only one huge goal graph or one huge use case map) has the lowest possible score. It has to be considered in conjunction with the CDME metric which measures tangling. Because the CDME metric is significantly higher for URN models than for AoURN models, it can be concluded that AoURN still performs better than URN. The same reasoning applies to the CDMU metrics that are better for GRL as compared to AoGRL and the slightly lower CBMU value for GRL as compared to AoGRL. AoGRL splits the single GRL graph which describes the impact of the functional concerns on the stakeholder goals into individual graphs — one for each functional concern. This introduces coupling to the stakeholder concerns from many functional concern graphs. However, a single goal graph for capturing this impact is not feasible for larger systems, as demonstrated again by the CDME metric. The slightly lower count for NME can also be explained by the single GRL goal graph being split into many for the AoGRL model. This introduces many duplicated modeling elements. However, the resulting goal graphs are much smaller as evidenced by the AvNME metric. Therefore, the difference in the NME metric is not significant. 5.2 Task-Based Evaluation In addition to the metrics, the most common update tasks were considered for URN and AoURN models. These update tasks cover adding, removing, or changing a use case, NFR, or stakeholder. As examples for such update tasks, consider the omissions stated at the end of section 4.3.3. Each use case, NFR, and stakeholder defined in the URN model and AoURN model is considered individually and a worst-case analysis is performed, i.e., those use case maps and goal graphs in the model are counted that may have to be updated due to changes in the requirements document. Finally, the counts are averaged over the number of use cases, NFRs, and stakeholders to be able to compare all three categories and the models with each other. Note that the set of use cases is slightly different for URN and AoURN models, because the aspect-oriented analysis of the use cases in the case study document resulted in a restructuring of the use cases. Therefore, updates to the original use cases are investigated for the URN model, while updates to the restructured use cases are investigated for the AoURN model. In contrast to the use cases, NFRs and stakeholders remain the same for both models. There is a section for each NFR in the nonaspect-oriented case study document and a concern for each NFR in the AoURN model (the URN model reflects the case study document). Similarly, each stakeholder is described in the non-aspect-oriented case study document and a concern exists for each stakeholder in the AoURN model. Table 7 shows the results of the task-based evaluation with the better result shown with a grey background. In general, the difference for updates to use cases is insignificant. Furthermore, there is a difference for updates to stakeholders which can be explained by the huge goal graphs in the URN model. The URN model contains one huge goal graph for all stakeholders and another one for all use cases, while the AoURN model breaks these two goal graphs into several individual ones for each stakeholder and each use case. Consequently, an update of a stakeholder in the

58

G. Mussbacher et al.

AoURN model may affect more goal graphs than an update in the URN model. This is a trade-off against huge goal graphs which are difficult to maintain and very quickly become unwieldy. Table 7. Results of the Task-Based Evaluation of URN and AoURN Models (Average Number of Diagrams Needing Modifications per Update Task)

URN AoURN

Use Cases 4.11 3.85

NFRs 9.83 3.33

Stakeholders 3.50 6.00

Total 6.76 3.93

Finally, there is a significant difference for the updates of NFRs. The results of the task-based evaluation nicely indicate the amount of crosscutting that occurs for the use cases and NFRs. The results for use cases are not very different because only some crosscutting occurs for use cases. In this situation, the traditional URN model and the AoURN model with its strict encapsulation of anything related to a particular use case (or feature) perform similarly. NFRs, however, crosscut other concerns very broadly and are, therefore, prime candidates for aspect-oriented modeling. The results of the task-based evaluation reflect this. When updating an NFR in the URN model, the goal graphs and use case maps for the NFR require updating. Then, all locations requiring changes in the stakeholder goal graphs, as well as the goal graphs and use case maps of other use cases and NFRs must be found and also changed. For use cases and stakeholders, the updates are more localized than for NFRs, but generally the changes are distributed over many different goal graphs and use case maps. For AoURN models, on the other hand, the update tasks require changes in the aspect graphs, aspect maps, pointcut graphs, and pointcut maps of one single concern (either the one encapsulating the use case, the NFR, or the stakeholder). Even though these updates may affect several use case maps and goal graphs, they are all generally localized to one group of use case maps and goal graphs contained in one concern. There is, however, one notable exception. Changes in the AoURN model may impact the matches of the pointcut expressions defined for concerns in the AoURN model. Hence, the pointcut expressions may also have to be changed. With tool support, the changes in the matches may be monitored and reviewed, ensuring that the desired locations in the AoURN model are stilled matched correctly. It is difficult to quantify the importance of the updates required for pointcut models due to changes in requirements. Good tool support is certainly required. The trade-off here is between changing crosscutting concerns in non-aspect-oriented models and keeping pointcut expressions up-to-date when aspect-oriented models change. We argue that the latter provides greater overall benefits. First, the non-aspect-oriented model does not indicate where the crosscutting occurs, therefore requiring the locations to be found before they can be changed. This is a very error-prone task. Second, the aspect-oriented model allows one to reason about the composition of a crosscutting concern as it is explicitly modeled. This enables, for example, changes in the number and location of pointcut matches to be brought to the attention of the modeler.

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

59

5.3 Summary Overall, the results suggest that the case study’s AoURN model exhibits better modularity, reusability, and maintainability than the URN models. In general, the complexity of stakeholder goal graphs in GRL models is traded against the complexity of pointcut graphs in AoGRL. Similarly, the complexity of use case maps for use cases or NFRs is also traded against the complexity of pointcut maps. Although pointcut expressions may be complex, they allow the complexity to be localized and are, therefore, more maintainable without hindering reusability. The larger the impact of a concern, i.e., the more crosscutting a concern is, the more pronounced are the positive results of the metrics assessment for AoURN models as compared to URN models. This can be clearly observed for NFR concerns. The more a concern crosscuts the URN model, the more AoURN can reduce the complexity of model units without necessarily requiring increasingly complex pointcut expressions. For scalability, we argue that the following five points suggest that AoURN models are more scalable than URN models: a) the reduced complexity of goal graphs and use case maps (see NME and AvNME results), b) the ability to group goal graphs and use case maps with concerns, c) the encapsulation provided by concerns, d) the ability to use parameterized pointcut expressions and variables in AoURN, and e) the simpler update tasks for AoURN. The results of the assessment of the CCCMS models confirm an earlier validation effort [12] which, even though much smaller in scope, exhibited the same characteristics and trends as seen in this assessment. In general, it proved to be possible to model all use cases, NFRs, and stakeholders in an aspect-oriented way with AoURN. As long as behavior can be specified for a concern, it can be modeled and encapsulated with AoUCM and applied to the rest of the model with aspect-oriented techniques. Even if behavior cannot be specified for a concern, it is still possible to capture the reasoning about the concern with AoGRL, encapsulate it in a concern, and apply it to the overall goal model. At some later stage when more of the behavior is known for the concern, the AoGRL goal model of the concern may then be refined into an AoUCM scenario model. In terms of threats to the validity of the performed assessment, a threat to internal validity is how the concerns were derived from the case study document. AoURN is not a technique that focuses on the detection of concerns. The decision to follow the general guidelines of considering use cases, NFRs, and stakeholders as concerns may have introduced bias into the assessment. However, the most pronounced results were observed for the various NFR concerns and those highly crosscutting concerns were already identified by distinct sections in the case study document. Furthermore, bias may have been introduced due to the highly experienced URN and AoURN modelers. The experience level combined with the facts that a) URN and AoURN models had to be consistent and b) the content of the case study document and hence the content of the models were not to be altered make it almost certain that the best possible URN and AoURN models were created. However, the resulting

60

G. Mussbacher et al.

models may not reflect what less experienced modelers may have produced. Because AoURN arguably requires more training than URN, there is a greater possibility that less-experienced modelers may produce AoURN models of lesser quality than URN models. This may cause the results to be less pronounced. The risk that highly experienced modelers may inadvertently introduce bias into the assessment is balanced to a certain extent by the exhaustive approach to the taskbased evaluation, since changes in each concern were investigated. In terms of external validity, the CCCMS is a safety-critical application and it could be argued that the obtained results do not apply to other types of systems such as enterprise information systems. This threat is somewhat mitigated by an earlier validation effort [12] which targeted a different system type. Nevertheless, a case study with less detailed and less well-specified information may lead to more divergent URN and AoURN models and possibly to different results. In terms of the actual techniques for AoURN, the case study highlighted the need for tailored, individual techniques for AoGRL and AoUCM. The fundamental differences in the structure of goal models and scenario models do not allow the same technique to be used effectively for both types of models. The highly interconnected nature of goal models makes it more amendable to a graph-transformation-like approach, where aspectual properties and pointcut expressions are specified on the same diagram. On the other hand, AoUCM separates aspectual properties and pointcut expressions into two distinct diagrams for reusability reasons. In the CCCMS case study, pointcut expressions were indeed reused by different concerns. This separation is possible for AoUCM, because scenario models are much more structured than goal models. It remains to be seen whether aspect-oriented techniques in general are applicable to goal models at the very early stages of requirements engineering. During this stage, the needs and dependencies of stakeholders are typically captured in a highly unstructured, inconsistent model. For these cases, a simple tagging mechanism (which is supported by the AoURN metamodel) may be more effective to identify and track concerns. In later stages, however, it is useful to organize goal models in an aspectoriented manner, as the impact of solutions (i.e., scenarios) should be clearly separated from the rationale and decisions captured in the goal graphs of the stakeholders. In these stages, aspect-oriented thinking provides important guidance in how to structure goal models. In some cases, the pointcut expressions required to encapsulate a concern with AoUCM can become quite complex. This is particularly true for concerns that require data-centric pointcut expressions, such as the persistence NFR concern. Because the URN and AoURN frameworks do not contain sophisticated domain modeling capabilities, it is not possible to exploit type information of domain concepts or domain concept hierarchies when specifying pointcut expressions. Instead, concepts often have to be matched explicitly by enumerating all options. This quickly becomes quite cumbersome as experienced by modeling the persistence NFR concern with AoURN in the case study. While it is possible to model data-centric concerns with AoURN, they are better served by techniques that have access to proper domain modeling facilities. On the other hand, many concerns have very generic pointcut expressions that can be reused across application domains and are very resistant against changes to the base model. Many NFR concerns fall into this category (see Figs. 14 and 15).

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

61

Finally, a crucial piece of the aspect-oriented modeling puzzle is the ability to deal with interactions between concerns. An aspect-oriented CCCMS model cannot be fully specified with techniques that cannot specify resolutions to concern dependencies and conflicts. AoURN’s Concern Interaction Graph (CIG) deals with such interactions.

6 Comparison of Aspect-Oriented Techniques for Scenario-Based and Goal-Oriented Requirements Engineering The qualitative comparison of aspect-oriented techniques for scenario-based and goaloriented requirements engineering builds on earlier assessments [12, 27]. As qualitative factors are available for the scenario part, they are being used to support the assessment in section 6.1, whereas section 6.2 includes a simpler discussion of work related to the goal part. 6.1 Comparison with Other Scenario-Based Techniques for AORE The assessment of scenario-based modeling techniques for aspect-oriented requirements engineering is based on a set of qualitative factors: • Exhaustive Composition: the ability of the AO-technique to express all required concern compositions, i.e., how limited is the usage of all modeling language constructs for composition purposes? • Scalability: the AO technique should scale to large industrial models. • Familiarity: the AO technique should employ a modeling notation that is familiar to requirements engineers to ease adoption of the technique; extensive switches should be avoided (e.g., between graphical and purely textual representations). • Formality: the AO technique should be as formal as possible without becoming a barrier in practice. • At the right abstraction level: the AO technique should be at the right abstraction level for requirements engineering, i.e., message or data details of interactions are not yet relevant. • Semantics vs. syntax: the AO technique should take semantics of the modeling notation into account when composing concern models. • Handling of interactions: the AO technique should be able to specify dependencies and conflicts between concerns and their resolutions. • Visualization of composition: the AO technique should not require complex layout issues to be resolved to visualize the composed model. • Obliviousness: a composition technique should allow concerns to be defined without changes to other concerns. Obliviousness is one of the original tenants of aspect-orientation, but has since come under scrutiny as annotation-based or interface-based techniques have become popular. However, in general, a concern must not be heavily polluted by non-concern-specific information. Several popular AORE approaches have been proposed for scenarios. In AspectOriented Software Development (AOSD) with Use Cases [28], Jacobson and Ng view

62

G. Mussbacher et al.

a well written use case as a concern. They add the notion of pointcuts to the traditional use case approach. Pointcuts in one use case reference extension points in other use cases in a textual way. In addition to the traditional application use cases, they introduce new kinds of use cases, the infrastructure use case, to describe scenarios required to address non-functional requirements, and the perform transaction use case, to describe all possible types of interactions an actor may have with the system. Infrastructure use cases reference pointcuts in the perform transaction use case which is eventually mapped to application use cases. This composition of concerns, however, is limited to extension use cases during use case modeling and to AspectJ-like constructs (before/after/around) in later phases. In Scenario Modeling with Aspects [29], Whittle and Araújo use UML sequence diagrams to describe non-aspectual scenarios and sequence-diagram-like interaction pattern specifications (IPS) to describe aspectual scenarios. IPS define roles for classifiers, messages, and parameters which can be bound to elements in other sequence diagrams to create a composed system, which is then translated into state machines for validation. Alternatively, the sequence diagrams and IPS are first both translated into state machine representations (finite state machines and state machine pattern specifications (SMPS), respectively) and then composed together at the state machine level [30]. In both cases, the binding is specified textually and identifies explicitly elements to be bound. On one hand, this allows for a very flexible composition that is as expressive as the modeling language itself. On the other hand however, explicit bindings do not scale as well as parameterized bindings since each binding must be specified individually. In the Aspectual Use Case Driven Approach, Moreira et al. [31, 32] propose to add extensions to UML use case and sequence diagrams to visualize how crosscutting nonfunctional requirements (captured with templates) are linked to functional requirements expressed by use case diagrams or sequence diagrams. In [33], they extend the set of use case relationships to include “constrain”, “collaborate”, and “damage” while making use of activity pattern specifications (APS). The new relationships describe how one use case impacts another (restricting it, contributing positively to it, or contributing negatively to it). APS extend UML activity diagrams by allowing the specification of roles similar to IPS [29] and SMPS [30]. Various activity diagrams are composed by composition rules which are similar to the binding in [29, 30]. Barros and Gomes [34] apply aspect orientation to UML activity diagrams. The approach is based on an additional composition operation called activity addition which allows the fusing of stereotyped nodes in one activity diagram with nodes in another. Stereotyping is effectively used as a pointcut expression, identifying explicitly nodes in another activity diagram for behavior merging. Whittle et al. [35] propose a metamodel-based aspect composition technique (MATA) that uses graph transformation formalisms. This approach can be applied to any model for which a metamodel has been defined, including UML state diagrams and sequence diagrams, for which tools and examples have been developed. Other generic weaving techniques that function on any metamodel are GeKo [36] and Kompose [37]. de Bruin and van Vliet [38] describe a UCM-based approach that allows behavior and structure to be refined with additional pre/post-processing in a top-down approach. Stubs are added either before or after the location to be changed to achieve the desired effect.

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

63

The above techniques successfully address only some, but not all of the properties listed above and are summarized in Table 8.

9

9

9

9

9

Oblivious

9 9

1) 9

1)

9

Composition Visualization

9

Handling Interactions

1)

Semantics vs. Syntax

Abstraction Level

Familiar

9

Formal

Jacobson and Ng [28] (AOSD with Use Cases) Whittle and Araújo [30, 29] (Scenario Modeling with Aspects) Moreira et al. [31, 33, 32] (Aspectual Use Case Driv. Appr.) Barros and Gomes [34] (UML Activity Diagram) Whittle et al. [35] (Graph Transformation – MATA) de Bruin and van Vliet [38] (Quality-Driven Sw. Arch. Comp.) Aspect-oriented Use Case Maps (AoUCM) [9, 19]

Scalable

Exhaustive

Table 8. Comparing Scenario-Based Approaches to AORE

9

1)

9

9

9

9

9

1)

9

9

1)

9

9 9

9

9 9

9

9

9

9

1) Only qualifies as a semi-formal composition technique compared to graph transformations.

Only Whittle and Araújo, Whittle et al., and AoUCM employ exhaustive composition mechanisms that can handle loops, concurrency, and interleaving. Jacobson and Ng as well as Moreira et al. do not address concurrency, loops, and interleaving, while Barros and Gomes as well as de Bruin and van Vliet only support before and after composition. Jacobson and Ng add the new concept of pointcut to use case modeling and change the meaning of extension points. Moreira et al. require several extensions to UML diagrams to visualize aspects. All other techniques, however, use familiar modeling languages. None of the techniques handle interactions of concerns well except for AoUCM and Whittle et al.’s MATA. AoUCM specifies concern interaction graphs that capture dependencies, conflicts, and resolutions based on precedence rules. MATA also allows the definition of precedence rules. When compared to the rigor and formal foundation of graph transformations, all other techniques qualify at the most as semi-formal notations. Most approaches are problematic in terms of scalability because composition rules identify targets of the composition only explicitly: Moreira et al. represent composition rules in an explicit and textual way without allowing parameterized expressions. Whittle and Araújo use textual and non-parameterized binding rules. Barros and Gomes also use a textual representation of pointcuts and also explicitly link nodes in UML activity diagrams, not allowing parameterized expressions. de Bruin and van

64

G. Mussbacher et al.

Vliet require the explicit addition of “Pre” and “Post” stubs for each location on a UCM that requires a change. Jacobson and Ng, however, address scalability to a certain degree by modeling perform transaction use cases that capture generic interactions between an actor and the system. In terms of abstraction levels, AoUCM are at a higher level of abstraction than the work by Whittle and Araújo which is at the message/state machine level. Moreira et al. make use of some models that are at the same and some models that are at a lower level of abstraction than AoUCM. All other approaches are at the same abstraction level as AoUCM. None of the approaches except for AoUCM takes the semantics of the modeling notation into account when composing concerns. AoUCM defines semantic equivalences classes that contain syntactic constructs that have the same meaning. AoUCM’s composition mechanism [39] then takes these equivalence classes into account. Therefore, refactoring operations can be safely performed on the AoUCM model without the risk of breaking some of the pointcut expressions. Approaches based on use cases (Jacobson and Ng and Moreira et al.) do not face complex layout issues when visualizing the composed model, since use case diagram do not tend to be overly complex. However, techniques based on sequence diagrams (Whittle and Araújo), activity diagrams (Barros and Gomes), or graph-based transformations (Whittle et al.) do have to deal with such issues. The addition of stubs, however, is manageable in de Bruin and van Vliet’s approach. AoUCM’s usage of AoViews circumvents the whole problem altogether using views for the visualization that have already been provided by the modeler. While most techniques are oblivious, Jacobson and Ng and de Bruin and van Vliet add extensions points and stubs, respectively, directly to the base model, causing it to be polluted with concern-specific information. 6.2 Comparison with Other Goal-Oriented Techniques for AORE Yu et al. [40] identify aspects in goal models based on the relationships between functional and non-functional goals, propose goal aspects as a way to address scalability issues in goal models, and point out that the syntax of goal aspects requires further research. An example shows a textual definition of a goal aspect. AoGRL uses a visual syntax for aspect-oriented goal models including pointcut expressions. Alencar et al. [41] identify aspects in i* models and extend the notation to represent aspect-oriented concepts. The extensions, however, do not allow crosscutting elements to be fully separated from other concerns, and pointcut expressions are again defined in a textual way. AoGRL fully encapsulates crosscutting concerns in an aspect. Furthermore, Alencar et al. do not identify scenarios as aspects or concerns in i* models, whereas AoGRL does model scenarios as concerns because AoGRL is part of the larger AoURN context. Kaiya and Saeki [42] propose a pattern-based technique to compose viewpoints. Like AoURN, [42] investigates goal and scenario models at the same time, but limits the composition technique to a simple combinatorial approach instead of more powerful pointcut expressions as in AoURN. Furthermore, it is not clear whether the approach specifies all required information for the composition of goal graphs and use cases.

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

65

7 Conclusion We applied the Aspect-oriented User Requirements Notation (AoURN) to the CCCMS case study, following a process defined at the beginning of this paper. We discussed in detail how AoURN is applied to the CCCMS case study, giving an example-based introduction to AoURN’s capabilities. AoURN is a visual framework that adds aspect-oriented extensions to the User Requirements Notation (URN) standard for goal-oriented and scenario-based modeling. With this framework, we modeled stakeholder concerns, functional concerns (use cases), and non-functional concerns of the CCCMS with AoURN. AoURN can effectively deal with most types of concerns as required by the CCCMS case study. Heavily data-centric concerns such as persistence, however, are more cumbersome to model with AoURN. For those concerns, techniques based on domain models may be the better choice. On the other hand, AoURN captures well concern interactions including dependencies and conflicts with their resolutions in the Concern Interaction Graph (CIG). We assessed AoURN models of the CCCMS against standard URN models of the CCCMS based on the metrics adapted from literature and a task-based evaluation. The results suggest that AoURN models are more scalable than URN models and exhibit better modularity, reusability, and maintainability. The results are the most pronounced for NFR concerns. Further empirical studies in the form of usability studies are required to confirm the results obtained through the presented assessment. A qualitative assessment of six other aspect-oriented techniques for scenario-based requirements engineering concludes that AoUCM and the graph-transformation-based approach MATA perform best according to nine predefined criteria. AoGRL was also compared to three other goal-oriented techniques to aspect-oriented modeling, indicating that AoGRL also has advantages over these techniques. In future work, AoURN could benefit from tighter integration with domain model-oriented approaches. Furthermore, better language and tool support is required for URN’s analysis features to be applied in a fully aspect-oriented mode. URN’s analysis features consist of the testing of UCM models based on scenario definitions and the evaluation of GRL goal models. Current tool support through the jUCMNav tool allows modeler to fully define AoURN goal and scenario models. Furthermore, aspect markers may be added manually. Prototypes for the matching and composition algorithms required for the automatic insertion of aspect markers in AoURN models have been developed, but have not yet been made available in the official tool. AoViews are not yet supported by the jUCMNav tool. Finally, better tool support should also help modelers in assessing changes to pattern matches when an AoURN model is updated. Acknowledgments. This research was supported by the Natural Sciences and Engineering Research Council of Canada, through its programs of Discovery Grants and Postgraduate Scholarships, as well as the Ontario Graduate Scholarship Program. We also want to thank FCT MCTES for partially funding this work.

66

G. Mussbacher et al.

References 1. International Telecommunication Union: Recommendation Z.151 (11/08), User Requirements Notation (URN) – Language definition (2008), http://www.itu.int/rec/T-REC-Z.151/en 2. Chitchyan, R., Rashid, A., Sawyer, P., Garcia, A., Pinto Alarcon, M., Bakker, J., Tekinerdogan, B., Clarke, S., Jackson, A.: Survey of Analysis and Design Approaches. AOSDEurope Report ULANC-9 (2005), http://www.aosd-europe.net/deliverables/d11.pdf 3. Clarke, S., Baniassad, E.: Aspect-Oriented Analysis and Design: The Theme Approach. Professional. Addison-Wesley Professional, Reading (2005) 4. Cottenier, T., van den Berg, A., Elrad, T.: Motorola WEAVR: Model Weaving in a Large Industrial Context. In: 6th International Conference on Aspect-Oriented Software Development (AOSD 2007), Vancouver (2007) 5. France, R., Ray, I., Georg, G., Ghosh, S.: Aspect-oriented Approach to Early Design Modeling. IEE Proceedings–Software 151(4), 173–186 (2004) 6. Kienzle, J., Al Abed, W., Klein, J.: Aspect-Oriented Multi-View Modeling. In: 8th International Conference on Aspect-Oriented Software Development (AOSD 2009), Charlottesville, pp. 87–98. ACM Press, New York (2009) 7. Rashid, A., Moreira, A., Araújo, J.: Modularization and composition of aspectual requirements. In: Proceedings of the 2nd International Conference on Aspect-Oriented Software Development, Boston, pp. 11–20. ACM, New York (2003) 8. Tarr, P., Ossher, H., Harrison, W., Sutton, S.M.: N degrees of separation: Multidimensional separation of concerns. In: Proceedings of the 21st International Conference on Software Engineering (ICSE 1999), Los Angeles, pp. 107–119. ACM, New York (1999) 9. Mussbacher, G., Amyot, D.: Extending the User Requirements Notation with Aspectoriented Concepts. In: Reed, R., Bilgic, A., Gotzhein, R. (eds.) SDL 2009: Design for Motes and Mobiles. LNCS, vol. 5719, pp. 115–132. Springer, Heidelberg (2009) 10. Kienzle, J., Guelfi, N., Mustafiz, S.: Crisis Management Systems: A Case Study for AspectOriented Modeling. Transactions on Aspect-Oriented Software Development 7, 1–22 (2010) 11. Sant’Anna, C., Garcia, A., Chavez, C., Lucena, C., von Staa, A.: On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework. In: Brazilian Symposium on Software Engineering (SBES 2003), Manaus, pp. 19–34 (2003) 12. Mussbacher, G., Amyot, D., Araújo, J., Moreira, A., Weiss, M.: Visualizing AspectOriented Goal Models with AoGRL. In: Proceedings of the Second International Workshop on Requirements Engineering Visualization (REV 2007), New Delhi, IEEE Computer Society, Washington (2007) 13. jUCMNav, Version 4.2.1, University of Ottawa (2010), http://softwareengineering.ca/jucmnav 14. UCMNav website, http://jucmnav.softwareengineering.ca/twiki/bin/ view/UCM/UcmNav 15. OpenOME website. University of Toronto, http://www.cs.toronto.edu/km/openome/ 16. Sandrila SDL website. SanDriLa Ltd., http://www.sdl.sandrila.co.uk/ 17. Amyot, D., Mussbacher, G.: Development of Telecommunications Standards and Services with the User Requirements Notation. In: Workshop on ITU System Design Languages, Geneva (2008), http://www.itu.int/dms_pub/itu-t/oth/06/ 18/T06180000010012PDFE.pdf

Requirements Modeling with the Aspect-oriented User Requirements Notation (AoURN)

67

18. URN Virtual Library, http://www.usecasemaps.org/pub 19. Mussbacher, G., Amyot, D., Weiss, M.: Visualizing Early Aspects with Use Case Maps. In: Rashid, A., Aksit, M. (eds.) Transactions on AOSD III. LNCS, vol. 4620, pp. 105–143. Springer, Heidelberg (2007) 20. Mussbacher, G.: Aspect-Oriented User Requirements Notation: Aspects in Goal and Scenario Models. In: Giese, H. (ed.) MODELS 2007. LNCS, vol. 5002, pp. 305–316. Springer, Heidelberg (2008) 21. 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), pp. 233–259 (2010) 22. Sampaio, A., Chitchyan, R., Rashid, A., Rayson, P.: EAMiner: a Tool for Automating Aspect-Oriented Requirements Identification. In: Proceedings of the 20th IEEE/ACM International Conference on Automated Software Engineering (ASE), Long Beach, pp. 352–355. ACM, New York (2005) 23. CCCMS: Complete URN Model and AoURN Model Files (2009), http://www.site.uottawa.ca/~damyot/pub/CCCMS-TAOSD 24. Mussbacher, G., Amyot, D.: On Modeling Interactions of Early Aspects with Goals. In: Proceedings of the 2009 ICSE Workshop on Aspect-Oriented Requirements Engineering and Architecture Design, Vancouver, pp. 14–19. IEEE Computer Society, Washington (2009) 25. Mussbacher, G., Amyot, D., Weigert, T., Cottenier, T.: Feature Interactions in AspectOriented Scenario Models. In: Nakamura, M., Reiff-Marganiec, S. (eds.) Feature Interactions in Software and Communication Systems X, pp. 75–90. IOS Press, Amsterdam (2009) 26. Basili, V., Caldiera, G., Rombach, H.: The Goal Question Metric Approach. Encyclopedia of Software Engineering 2, 528–532 (1994) 27. Mussbacher, G., Amyot, D., Whittle, J., Weiss, M.: Flexible and Expressive Composition Rules with Aspect-oriented Use Case Maps (AoUCM). In: Moreira, A., Grundy, J. (eds.) Early Aspects: Current Challenges and Future Directions. LNCS, vol. 4765, pp. 19–38. Springer, Heidelberg (2007) 28. Jacobson, I., Ng, P.-W.: Aspect-Oriented Software Development with Use Cases. Addison-Wesley Professional, Reading (2005) 29. Whittle, J., Araújo, J.: Scenario Modelling with Aspects. IEE Proceedings – Software 151(4), 157–172 (2004) 30. Araújo, J., Whittle, J., Kim, D.: Modeling and Composing Scenario-Based Requirements with Aspects. In: Proceedings of the 12th IEEE International Requirements Engineering Conference (RE 2004), Kyoto, pp. 58–67. IEEE Computer Society, Washington (2004) 31. Araújo, J., Moreira, A.: An Aspectual Use Case Driven Approach. In: Pimentel, E., Brisaboa, N.R., Gómez, J. (eds.) VIII Jornadas de Ingeniería de Software y Bases de Datos (JISBD 2003), Alicante, pp. 463–468 (2003) 32. Moreira, A., Araújo, J., Brito, I.: Crosscutting Quality Attributes for Requirements Engineering. In: Proceedings of the 14th International Conference on Software Engineering and Knowledge Engineering (SEKE), Ischia, pp. 167–174. ACM Press, New York (2002) 33. Moreira, A., Araújo, J.: Handling Unanticipated Requirements Change with Aspects. In: Proceedings of the 16th International Conference on Software Engineering and Knowledge Engineering (SEKE), Banff, pp. 411–415 (2004) 34. Barros, J.-P., Gomes, L.: Toward the Support for Crosscutting Concerns in Activity Diagrams: a Graphical Approach. In: Fourth Workshop on Aspect-Oriented Modelling (held with UML 2003), San Francisco (2003)

68

G. Mussbacher et al.

35. Whittle, J., Jayaraman, P.: MATA: A Tool for Aspect-Oriented Modeling Based on Graph Transformation. In: Giese, H. (ed.) MODELS 2007. LNCS, vol. 5002, pp. 16–27. Springer, Heidelberg (2008) 36. Morin, B., Klein, J., Barais, O., Jézéquel, J.-M.: A Generic Weaver for Supporting Product Lines. In: Proceedings of the 13th International Workshop on Early Aspects, Leipzig, pp. 11–18. ACM, New York (2008) 37. France, R., Fleurey, F., Reddy, R., Baudry, B., Ghosh, S.: Providing Support for Model Composition in Metamodels. In: 11th IEEE International Enterprise Computing Conference (EDOC 2007), Annapolis, pp. 253–266. IEEE Computer Society, Washington (2007) 38. de Bruin, H., van Vliet, H.: Quality-Driven Software Architecture Composition. J. Syst. Softw. 66(3), 269–284 (2003) 39. Mussbacher, G., Amyot, D., Whittle, J.: Refactoring-Safe Modeling of Aspect-Oriented Scenarios. In: Schürr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 286–300. Springer, Heidelberg (2009) 40. Yu, Y., Leite, J.C.S.d.P., Mylopoulos, J.: From Goals to Aspects: Discovering Aspects from Requirements Goal Models. In: Proceedings of the 12th IEEE International Requirements Engineering Conference (RE 2004), Kyoto, pp. 38–47. IEEE Computer Society, Washington (2004) 41. Alencar, F., Castro, J., Moreira, A., Araújo, J., Silva, C., Monteiro, C., Ramos, R., Mylopoulos, J.: Simplifying i* Models. In: 17th International Workshop on AgentOriented Information Systems (AOIS 2007), Trondheim, pp. 635–649. Tapir Academic Press, London (2007) 42. Kaiya, H., Saeki, M.: Weaving Multiple Viewpoint Specifications in Goal-Oriented Requirements Analysis. In: 11th Asia-Pacific Software Engineering Conference (APSEC 2004), Busan, pp. 418–427. IEEE Computer Society, Washington (2004)

Relating Feature Models to Other Models of a Software Product Line A Comparative Study of FeatureMapper and VML* Florian Heidenreich1, Pablo S´anchez2 , Jo˜ao Santos3 , Steffen Zschaler4 , Mauricio Alf´erez3 , Jo˜ao Ara´ujo3 , Lidia Fuentes5 , Uir´a Kulesza3 , Ana Moreira3, and Awais Rashid4 1 Technische Universit¨at Dresden, Germany [email protected] 2 Universidad de Cantabria, Santander, Spain [email protected] 3 Universidade Nova de Lisboa, Portugal {mauricio.alferez,ja,amm}@di.fct.unl.pt, {jpgpsantos,uirakulesza}@gmail.com 4 Lancaster University, UK {zschaler,awais}@comp.lancs.ac.uk 5 University of Malaga, Spain [email protected]

Abstract. Software product lines using feature models often require the relation between feature models in problem space and the models used to describe the details of the product line to be expressed explicitly. This is particularly important, where automatic product derivation is required. Different approaches for modelling this mapping have been proposed in the literature. However, a discussion of their relative benefits and drawbacks is currently missing. As a first step towards a better understanding of this field, this paper applies two of these approaches— FeatureMapper as a representative of declarative approaches and VML* as a representative of operational approaches—to the case study. We show in detail how the case study can be expressed using these approaches and discuss strengths and weaknesses of the two approaches with regard to the case study.

1 Introduction A software product line (SPL)—such as the case study under discussion [1]—is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way [2, 3]. Apart from sharing a common set of features, every system also has features that are specific to this system and not shared with other systems in the SPL. For the purposes of this paper, we are using the following definition of feature: “A prominent or distinctive user-visible aspect, quality, or characteristic of a software system or systems.” [4] as cited in [5] S. Katz et al. (Eds.): Transactions on AOSD VII, LNCS 6210, pp. 69–114, 2010. c Springer-Verlag Berlin Heidelberg 2010 

70

F. Heidenreich et al.

An important part of managing the features of a product line and the individual systems (often called products) is to model the available features and their dependencies (e.g., if feature A is selected, feature B also must be selected) in an abstract form. In particular, it is essential to produce models for the variable features. Often, this is done using socalled feature models (e.g., [5]). The case study under discussion is an example of such a product line. In this paper, we focus solely on the product lines modelled using feature models. Although these models express what features there are and what products can be formed from them, they do not express how a specific feature is realized, and, thus, how any specific product is realized. Typically, there also need to be models that describe how the SPL is realized; that is, models of the solution space for the SPL. This is particularly relevant in a modeldriven setting, where product code is generated from product models. For instance, let us consider a simple SPL for a chess game for mobile phones, where the product can be delivered with three levels of expertise: beginner, medium and master. A feature model would only specify that there are three levels, and that the user must select one, but it does not specify how these alternatives are supported at the software level. This might be by means of different techniques, such as using a strategy pattern or conditional compilation, among others. Thus, we also need software models that specify which particular kind of technique we have selected for realising the variations at the softwaredesign level. In SPL terminology, feature models are said to be problem-space models, and software models, such as architectural design models, are said to be solution-space models. To automate product derivation, we also need to know what actions or manipulations should be applied to the software models as a certain feature is included or excluded in/from a specific product. For instance, if we have opted for using the strategy pattern for designing a set of alternative features, we need to know which strategies correspond to each feature. Because it is not always possible to establish a clear one-to-one mapping between features and model elements, this is not a trivial task. This leads to a mapping problem: For each feature in a feature model, we need to identify and specify the solution-space models and model elements associated with it to be able to systematically construct products given a selection of features. In this paper, we will use the term variability mapping to refer to the activity of expressing explicitly the relationship between features and model elements. Note that this does not imply that the relation between features and their realization must be ’discovered after the fact’. Variability will be designed into solution-space models because there is a corresponding variation point in the feature model. However, to enable automation of product derivation, this relationship (or mapping) must be made explicit in some form. Depending on how we choose to model the SPLs architecture, this mapping may be very simple or very complex. For example, where aspect-oriented or feature-oriented techniques are used for the SPL models, we can attempt to align every feature with one module of these models. Using more standard object-oriented modelling techniques, some features will have to be mapped to a number of model elements across the entire SPL; that is, they will be cross-cutting features.

Relating Feature Models to Other Models of a Software Product Line

71

Aspect-oriented modelling (AOM) is about the separation of different concerns in different (partial) models that can then be composed into a representation of the complete system. Variability modelling fits well into this description: A key principle is to separate the model elements related to different features (’concerns’). This is done by either physically separating them in separate models or virtually separating them using different tags to associate model elements to features. A first step in product derivation is then the composition of these separate concerns into models of a complete product. Variability models address the mapping problem mentioned above to provide both separation of concerns and composition of the separated models into product models. A number of different approaches to variability mapping have been proposed [6–11]. These proposals take different approaches to the mapping problem. Some approaches use a declarative model of the mapping between features and model elements (e.g., [6, 7, 9]), while others use a more operational approach based on model transformations (e.g., [8, 10, 11]). This paper applies two of these approaches—FeatureMapper [9] and VML* [11]—to the case study and discusses their respective advantages and drawbacks. FeatureMapper is a generic tool that can be used directly with any EMFbased model [12] and GMF, Ecore, or EMFText-based [13] editor. It directly relates features and model elements and derives product models by removing all model elements associated with features not selected for that product. In contrast, VML* uses languages customized for each target model. For instance, for target models of components and connectors, VML* can be customized to provide constructs in terms of components and connectors. It is still generic, because it is based on a customisable infrastructure that can be easily adapted for any new target model using a generativeprogramming approach. Each language consists of a set of actions corresponding to simple model transformations that are executed depending on the features selected for a product. The two approaches have been selected because they are good representatives of declarative and operational approaches, respectively. Therefore, we believe the results from a comparison of these two approaches can also provide some insights into the relative benefits and drawbacks of declarative and operational approaches to the mapping problem.1 Furthermore, each of the approaches has been developed by some of the co-authors of this paper. This gives us full access to the approaches and their accompanying tooling, which is key to an evaluation against the common case study. A more detailed discussion of the spectrum of different approaches and our selection can be found in Sect. 2.2. We have defined a set of comparison criteria to support a systematic comparison of the two approaches. These criteria have been defined to cover a broad spectrum of characteristics relevant when using a variability-modelling approach. In particular, they can be grouped into criteria on the expressiveness of the approach (i.e., what types of variability and what artefacts does the approach support), criteria on the useability and analysis support (i.e., what kinds of evaluations and analyses does the approach support), and criteria on the approaches’ applicability to real-word product lines (i.e., 1

As also pointed out by the anonymous reviewers, this does not imply that the comparison results can be directly generalised to other tools. However, as we will see, a number of the comparison results really reflect the fact that one of the approaches is declarative and the other one is operational, so there are some tentative grounds for careful generalisation.

72

F. Heidenreich et al.

does it scale, does it support evolution of artefacts). Although it is always possible to add additional criteria, we believe that this selection enables systematic and broad comparison of the two approaches. The remainder of this paper is structured as follows: Section 2 briefly discusses different variability mechanisms before giving an overview of approaches to the mapping problem that can be found in the literature and attempting a classification of these approaches on the basis for motivating our specific selection from this space. Section 3 presents some more detail on the case study and, in particular, refines it to provide detail of a second specific crisis management system—a flood crisis management system. The detailed models from Sect. 3 are then used in Sects. 4 and 5 to show how the two approaches are applied to the case study. Based on this, Sect. 6 compares the two approaches and discusses their benefits and drawbacks along a number of dimensions. Finally, Sect. 7 concludes the paper.

2 Background The mapping problem, i.e. how to specify the links between features and variation points plus variants in software models, was already identified by Pohl et al. [3], who originally proposed the Orthogonal Variability Model (OVM). The idea of the OVM is that variability specification, e.g. a feature model, and variability realization, e.g. a flexible reference architecture comprises component and connectors, should be separated, contrarily to other approaches, such as Ziadi et al. [14], where software models are augmented with information regarding which model elements are optional, which are alternatives and so forth. This should contribute to a better scalability [15]. The OVM concepts have been implemented in the VarMod tool 2 , which allows us: (1) to create variability models in problem space according to Pohl et al’s notation [3]; (2) check the well formedness of these models; and (2) specify trace links between these variability models and solution-space artifacts. The OVM largely inspired the family of VML languages, which extend the OVM approach with information about what specific actions must be carried out in a software model when a certain feature is selected or unselected. In this section, we first discuss different mechanisms for achieving variability between models for different products of an SPL, i.e. how variability can be realized. Next, we discuss a range of approaches for variability mapping (that is, different solutions to the mapping problem described above) available in the literature and motivate our selection of approaches for the purposes of the comparison reported on in this paper. 2.1 Variability Mechanisms The first step in modelling variability in the solution space is to create a reference model for the family of products that the software product line covers. This reference model must incorporate certain variability mechanisms for supporting the variations specified in the feature model. In general, we can choose from the following types of variability mechanisms:3 2 3

http://sse.uni-due.de/wms/en/?go=256 See, for example, [16] for a deeper discussion of positive and negative variability.

Relating Feature Models to Other Models of a Software Product Line

73

1. Negative Variability. Here, selecting a feature for a product implies removing all model elements associated with the other, unselected, features from the SPL model. We create a reference model that contains all the elements used for all variants of the software product line. During the product derivation, those elements that are not required according to a selection of features are removed. 2. Positive Variability. In contrast to negative variability, here, selecting a feature for a product implies adding all model elements associated with this product to the SPL model. We create a minimal reference model which contains the common elements, or core elements, for any product in the software product line. Then, we specify which new elements must be added as a consequence of selecting a certain set of features. A special case of positive variability is positive variability with aspect models. Here, we encapsulate variants into aspects, using an AOM technique [17] (such as Reuseware [18], MATA [19], or TENTE [20]). Then, the mapping model is used to indicate which aspects must be woven according to a certain selection of features. 3. Parameterization of Model Elements. Here, variability is achieved by modifying existing model elements in the reference model depending on the feature selection. An example of this variability mechanism is component parametrization, where variability of a software architecture is enabled through parameterized components. The mapping model is used for generating the values for the parameters of these components corresponding to a certain selection of features. Each one of these mechanisms has advantages and disadvantages. For instance, when the selection of one feature implies the addition of a considerable number of new components, interfaces and so forth scattered throughout the reference model, it makes sense to encapsulate these elements into one aspect, separately from the core of the application. This kind of decomposition improves modularization, easing maintenance and evolution [21]. Nevertheless, the selection of a variant might only require to remove an operation from an interface; or change the value of a certain attribute. If we try to encapsulate this kind of fine-grained variation into aspects, the result will be a software architecture decomposed into a large number of small aspects with complex dependencies among them. This quickly leads to scalability problems. 2.2 Variability Mapping Approaches Figure 1 gives an overview of the space of variability mapping for SPLs as we see it. It should be noted that for this paper, we are interested only in static SPLs. Dynamic SPLs, where variability is resolved at runtime and is used to adapt the system to changing contexts, are out of the scope of our paper. Consequently, Fig. 1 only includes approaches to variability mapping that support static variability resolution. All of the approaches covered by this figure aim to support product derivation based on a selection of features from a feature model. To this end, they each provide some way to model the modifications of the target required if a particular feature has been selected or unselected. Based on how this is done, we distinguish a number of types of variability-mapping approaches:

74

F. Heidenreich et al. Variability Mapping Declarave Posive Variability

Negave Variability

AHEAD [6]

Operaonal

Generic Model Transformaons

Aspect-Oriented Modelling

Customised Model Transformaons

Ziadi et al. [24] Boerweck et al. [25]

CVL [8]

VML* [11, 26] Gears [27]

Direct Annotaon

Separate Annotaon Model

Model Templates [7] Morin et al. [10]

FeatureMapper [9] pure:variants [23]

Fig. 1. Overview of approaches to variability mapping

1. Declarative variability mapping. In this category, we group approaches that model what changes are needed, but do not provide means of modelling how these changes should be achieved. Instead, the precise mechanism of change is encoded in the semantics of the models, to different degrees of formality, but typically encapsulated in a tool. The approaches discussed in the literature typically support either positive or negative variability: (a) Support for positive variability. Batory et al. [6] present A HEAD, an approach that views features as incremental modifications of base systems. Effectively, this leads to positive variability, where the addition of features leads to additions to the base system.4 (b) Support for negative variability. Negative variability uses models of the complete product line, removing elements associated with unselected features during product derivation. To specify which model elements are associated with which features, model elements are often tagged with feature names or feature expressions. These tags can either be embedded directly into the target model or they can be represented in a separate annotation model: i. Using direct annotations of the target model. Czarnecki and Antkiewicz [7] propose the use of a template model, which models all products in the product line. Elements of this model are annotated with so-called presence conditions. Given a specific configuration, each presence condition evaluates to true or false. If a presence condition evaluates to false, its associated model elements are removed from the model. Thus, such a templatebased approach is specific to negative variability, which might be critical when a large number of variations affect a single model. Moreover, presence conditions imply introducing annotations into the SPL model. Therefore, the actions associated with a feature selection are scattered across the model, which could also lead to scalability problems. An implication of using annotations is that the modelling languages used for modelling an 4

[6] in principle also allows features to represent non-monotonic modifications, which would lead to negative variability.

Relating Feature Models to Other Models of a Software Product Line

75

SPL need to provide means for annotating model elements (such as UML stereotypes). Other modelling languages cannot easily be supported. Morin et al. [10] provide an alternative approach to represent variability in models of a product line. Their approach is effectively based on the tagging target model elements with variability information, similarly to [7] and FeatureMapper. However, instead of tagging with features or feature expressions, [10] tags model elements with whether they are optional, alternatives, mandatory, etc., as well as with inclusion constraints between different model elements. These concepts are expressed in a separate metamodel, which is woven into the target metamodel using their SmartAdapters approach to AOM [22]. Although Morin et al. use feature models to simplify the configuration of the variability expressed in their models, these feature models are derived directly from the target model assuming a simple 1-to-1 relation between features and model elements. Thus, their feature models are much closer to the solution space of a product line than the feature models we are discussing for the common case study. ii. Using a separate annotation model. FeatureMapper [9] is an approach very similar to the template-model approach of [7]. However, it uses an annotation model that is separate from the target model to store feature expressions and their associations with target-model elements. Because the annotations are not embedded directly into the target model, the target modelling language does not need to be changed and existing tools can be used directly. In addition, by separating the target model and the variability specification, the target model can more easily be reused in another context. pure::variants [23] is an industrial-strength variant management tool that uses a separate model, a so-called family model, to store mappings between feature expressions and symbolic names to solution-space artefacts (such as file names, preprocessor definitions or URI to model elements). By default, the tool has no direct understanding of models and model elements. However, FeatureMapper was integrated into pure::variants recently, so that pure::variants feature models, variant models, and mapping models can be used in combination with FeatureMapper. pure::variants supports the configuration and derivation of variants of an SPL. 2. Operational variability mapping. In contrast to declarative approaches, operational approaches provide language constructs for specifying how target models must be modified when specific features are selected or deselected. We distinguish the following three categories of approaches from the literature: (a) Using generic model transformation languages. Ziadi et al. [24] and Botterweck et al. [25] both propose the implementation of product derivation processes as model transformations. Their proposals rely on the realization of product derivations via a model transformation language. This strategy requires SPL engineers to deal with low-level details of model transformation languages. (b) Using aspect-oriented modelling techniques. Haugen et al. [8] define the common variability language (CVL), which is a generic extension to DSLs

76

F. Heidenreich et al.

for expressing variability. It provides three generic operators, such as value substitution, reference substitution, and fragment substitution, all of which are based on aspect-oriented notions of model weaving, but using these to express variability can lead to comparatively complex models. CVL is also based on model transformation, but proposes to extend the target modelling language with generic concepts for variability modelling. CVL distinguishes between socalled variation models and resolution models. A variation model is based on a modelling language extended with CVL concepts and describes all possible variations using the three standard CVL variability mechanisms. The resolution model is then used to select the variations to be included in a product model. (c) Using customized model transformation languages. VML* [11, 26] is a family of languages for variability mapping. A particular VML* language is effectively a model transformation language. However, different from the approaches in the first category, this model-transformation language has been customized both to the domain of SPLs and to the target modelling language. Thereby, SPL developers do not need additional knowledge about model-transformation languages or target-model metamodels. Instead, they can express required modifications using the same concepts and terminology and they would use for producing the models in the first place. Gears [27] is an SPL framework that also supports product derivation. It started at the code level, and it has recently adapted for working at the requirements and/or model level with some specific tools [28], such as DOORS or Rhapsody. This tool has its own feature model, where each feature is seen as a variable with its own basic type (e.g. boolean or string). It also contains a mechanism to define variation points in software assets and a language for specifying how these variation points must be bound to produce a concrete product. For instance, we can declare a file containing a license agreement for a software product as a variation point, and associated different files containing different license agreements to that variation point. Then, using the language for variability binding provided with Gears, we can specify what specific license agreement must be included in a specific product depending on the feature configuration. Gears, allows to specify what actions should be carried out when a certain variants is selected or unselected, similarly to VML*, through a specific Gears capability called actuator. However, these actuators are based on the manipulations of textual files, with no specific support for models, which implies that models need to me manipulated directly in their serialised form (such as in XMI format). This can make the implementation of actions very costly and time-consuming. There are other aspect-oriented modelling approaches, such as MATA [19], XWeave [29], Reuseware [18], or RAM (Reusable Aspect Models) [30], which can also be used for software product line engineering and are not included in this classification. All these techniques provide mechanisms to encapsulate features in individual modules. In these cases, features are considered as enhancements to an already existing core. MATA, for instance, provides mechanisms for encapsulating enhancements to an existing core as

Relating Feature Models to Other Models of a Software Product Line

77

aspects, which are later composed, in case the corresponding feature is selected, with the core based on the graph-transformation techniques. Nevertheless, these languages and tools focus on separating and encapsulating features as enhancements to an existing core, but they do not provide support to automate the product derivation process (i.e., aspects corresponding to selected features must be composed manually). Moreover, it is difficult to encapsulate fine-grained variations, such as changing attribute values. From the spectrum of approaches presented in this section, we have chosen two, namely FeatureMapper and VML*, which we apply to the common case study and compare with respect to a number of comparison criteria. To provide a full understanding of the spectrum, it would, of course, have been preferable to compare all approaches by applying them to the common case study. However, unfortunately this is not feasible. A key criterion for our selection was the fact that we know these two approaches and have full access to the tools and the original developers. Thus, we can ensure that we do not accidentally misuse or misrepresent the approaches, which could easily have happened with some of the other approaches. However, apart from this, we also selected the two approaches because they represent quite different categories from our classification in Fig. 1: FeatureMapper is a declarative approach for negative variability, while VML* is an approach for operational variability mapping. Thus, the results of our comparison should allow at least some initial conclusions about the relative benefits and drawbacks of these two broad categories.

3 Zooming in on the Case Study: Car Crises vs Flood Crises To be able to demonstrate the approaches, we needed to refine the case study [1] for at least one additional product. The main motivation to model the additional product was to create models that contain significant differences between both instances of the product line and to evaluate the chosen approaches based on how they perform at modelling the variability that needed to be expressed in the different models. Therefore, we aimed to add two types of models and model elements: 1) such that would only occur in one of the two alternate products, and 2) such that would require some modifications (e.g., a different structure or different values) in each product. This section presents these refinements as a preparation for the rest of the paper.5 3.1 Flood Crisis Management System In addition to the car crisis management system (CCMS) from the case study, we have chosen to model a Flood Crisis Management System (FCMS). Figure 2 shows the configuration model (i.e., the selected features) for the FCMS. It can be seen that FCMSs have a feature set that is substantially different from CCMSs, but that they also share a number of features. Features unique to the FCMS are underlined in the figure. Thus, features related with the use of the Navy, the pumping and repair missions, and the fact that the crisis may cover a large area are some examples of this uniqueness. We can 5

Since not all models created for the case study can be presented in this paper, we provide the models on-line at http://featuremapper.org/files/TAOSD-AOM-2009/

Fig. 2. Configuration model for a Flood Crisis Management System

78 F. Heidenreich et al.

Relating Feature Models to Other Models of a Software Product Line

79

also observe that there were features present in the CCMS which are not included in this configuration. Features related to investigation, nursing the wounded, sorting the wounded, police intervention, and the type of crisis (which is a major accident of type car crash) differ from the FCMS configuration. Figure 3 shows the use case model for an FCMS. A number of use cases have been added in comparison to the CCMS. For example, there are now the use cases ‘Execute Pumping Mission’ and ‘Execute Repair Mission’. These use cases only make sense for FCMSs, but not for CCMSs. As each use case is associated with at least one activity diagram detailing the concrete usage scenario, the FCMS model also contains additional activity diagrams. Note that even though some use cases are present for both products, they may still differ in the concrete underlying scenarios. This will be discussed in more detail for the ‘Execute Rescue Mission’ use case in the next subsection. Of course, the different products also require different designs and architectures. For example, the basic data structures required for both products are quite different, Figure 4 shows the data structures defined for FCMSs. In comparison, Fig. 5 shows the data structures defined for CCMSs. Furthermore, the FCMS makes use of a number of components that are not used by the CCMS and vice versa. For example, the FCMS uses the following components: ElectricityCompany, Navy, Army, ArmyVehicle, TelecommunicationCompany, and NavyBoat. The next subsection discusses the Rescue Mission as an especially interesting case, because although both products support this mission, they differ very much in their implementations of it.

Fig. 3. Use-Case Model for a Flood Crisis Management System

80

F. Heidenreich et al.

Fig. 4. Data structures for Flood Crisis Management Systems

Fig. 5. Data structures for Car Crisis Management Systems

3.2 Detailed Models of the Rescue Mission The purpose of the rescue mission is to locate victims and remove them from the site of the crisis. This requires a quite different set of steps in the case of a car crash and a flood crisis. Figures 6 and 7 show two activity diagrams with the different scenarios. Notice that there is a common core, but that each product has some steps specific to it. In both cases, the rescue mission begins by transmitting injury information and attempting, where possible, to identify the victim(s). Next, additional conditions are checked. These are contingent on the type of crisis: In the car-crash scenario, it makes sense to check whether the victim is locked in the car so that special actions need to be taken to remove him/her from the car. In the flood-crisis scenario, rescue is mostly about taking people out of the flood area. However, some victims, for example, elderly or handicapped people, may require special assistance for this. In both cases, if the additional condition is true, the rescue mission is terminated after requesting another mission to be undertaken in response to the additional condition. If the additional condition is false, the rescue mission proceeds as normal, by administering first aid and deciding if the victim needs to be taken to a hospital. If no hospital is needed, no further action is required in the case of the car-crash scenario. For the flood-crisis system, however, all victims need to be taken to a safe place. We consider these are reasonable assumptions, based on the real-life scenarios, on the original case study.

Relating Feature Models to Other Models of a Software Product Line

81

Fig. 6. Scenario for the rescue mission for the CCMS

The two products also require a different set of realization classes and data structures to appropriately represent the respective crisis, although they also share some common classes, which are depicted in Fig. 8. Although for a car crisis the location of a victim is the same as the location of the crisis (apart, possibly from the exact vehicle in which the victim may be located), a flood crisis occupies a much larger area, so that victim location becomes a much more relevant information. Consequently, the Victim class provides a location attribute for storing the victim’s location. Furthermore, different types of victims may require different treatment (cf. also Fig. 6 and Fig. 7). Which types of victims need to be distinguished depends on the type of crisis. Finally, while some types of resources will be useful for both types of crises (e.g., Blankets), others are only relevant for one or the other (e.g., LifeJackets are only useful in a flood crisis). Consequently, different design models are required for the two different products. Figure 9 shows the models we will be using.

82

F. Heidenreich et al.

Fig. 7. Scenario for the rescue mission for the FCMS

Fig. 8. Design models for accomplishing abstract missions

Relating Feature Models to Other Models of a Software Product Line

83

Fig. 9. Design models for the rescue mission for the CCMS (top) and the FCMS (bottom)

In addition, we consider these are reasonable assumptions, based on real-life scenarios, on the original case study. 3.3 Units of Measurement To show a specific type of variability mechanisms, we add a set of features dealing with units of measurement. The reason for this addition was that the case study can be completely modelled using positive and negative variability (cf. Sec. 2.1), and this change allows us in illustrating better how FeatureMapper and VML* can deal with model modifications. In particular, we add the MeasurementUnit feature group, which allows in choosing between the alternatives ImperialSystem and MetricSystem. This feature allows our product line to be used in different countries using different units of distance measurements. Both the FCMS and the CCMS need to deal with geographical locations for identifying the places where the crisis take place and personal data of the victims. Fig. 10 shows the design classes for managing geographical locations. This design is shared by both the FCMS and the CCMS. These data structures include the class RoadwayLocation, which need to specify a length measurement. Depending on the country where this system is deployed, this length would be measured in kilometers or miles. An attribute called distanceUnit is added to the RoadwayLocation for configuring in which system units this class must work. Therefore, depending on which country the system is deployed, this attribute must be changed.

84

F. Heidenreich et al.

Fig. 10. Data structures for dealing with geographical locations

The following two sections show how two different approaches to variability mapping can be applied to this case study, followed by a discussion of the two approaches in Sect. 6.

4 Application of FeatureMapper to the Case Study FeatureMapper [9, 31, 32] is an Eclipse-based tool that allows for mapping features to arbitrary modelling artefacts that are expressed by means of an Ecore-based language [12]. These languages include UML2, domain-specific modelling languages defined using the Eclipse Modelling Framework (EMF), and textual languages that are described using EMFText [13]. The mappings can be used to steer the product-instantiation process by allowing the automatic removal of modelling artefacts that are not part of a selected variant. To associate features or logical combinations of features (feature expressions) with modelling artefacts, the developer first selects the feature expression in FeatureMapper and the modelling artefacts in her favourite modelling editor (e.g., TOPCASED [33]). Next, she applies the feature expression to the modelling artefacts via the FeatureMapper user interface. This mapping is later interpreted by a FeatureMapper derivation component. Depending on the result of evaluating the feature expression against the set of features selected in the variant, the modelling elements are preserved or removed from the model. Model elements that are not mapped to a specific feature expression are considered to be part of the core of the product line and are always preserved. This implies that the solution-space models contain all model elements that are used in any product of the product line. In Fig. 11, we show that we can model variants or product-specific variations in one model. The separation of concerns is realized by the actual mapping and various visualization techniques that help the product-line developer in understanding the mapping between features and model artefacts. One such visualization is depicted in Fig. 11 where the colouring of model elements according to their associated feature expression is shown.6 Another visualization is shown in Fig. 12 where only modelling artefacts mapped to the current feature expression are drawn normally, whereas all model elements that are not realized by this feature expression are shaded in grey. Because FeatureMapper implements these visualizations on a 6

Since the colours used in this figure and others are likely not to be visible in a printout copy of the paper, we also provide the figures on-line at http://featuremapper.org/files/TAOSD-AOM-2009/

Relating Feature Models to Other Models of a Software Product Line

85


      

  

  


 


  


   




   

  

    

!

Fig. 11. Use-Case Model of the CMS displayed in FeatureMapper with enabled colouring of model elements and the legend depicting the corresponding feature expressions

sufficiently generic layer to become independent of the concrete editor7 , using them does not require changing the editors and works on all GMF-based, tree-based EMF, and textual EMFText editors. This enabled us to map features of the CMS to requirements, architectural, and design models without changing or adapting FeatureMapper itself or any of the used modelling editors. 4.1 Modelling the Mapping for Requirements Models As shown in Fig. 11, the use case model contains all actors and use cases of both the CCMS and the FCMS. We used the mapping facility of FeatureMapper to map specific feature expressions to the elements of the use case model. The feature expression have been identified by analyzing the textual description of the different use cases and taking the different actors participating in a use case into account. In addition to the use cases included in the case study description, we extended the models as described in Sect. 3. 7

FeatureMapper uses the Graphical Editing Framework (GEF) for graphical editors, the SWT TreeViewer for tree-based EMF editors, and the EMFText Editor, respectively.

86

F. Heidenreich et al.

Fig. 12. Use-Case Model of the CMS displayed in FeatureMapper with enabled Realization Visualization that highlights the model elements associated with the current feature expression

For example, the feature expression Repair AND Electric Line was assigned to the actor Electrician, the use case Execute Electric Line Repair Mission, and the association between those two artefacts. The use case Execute Repair Mission was in turn only mapped to the feature Repair because it is also used when we include repairing of telecommunication lines in our product. Another possibility to create the mapping for the use case Execute Repair Mission is to include it only if Repair AND (Execute Electric Line Repair Mission OR Execute Telecomm Line Repair Mission) evaluates to true. We decided against this because it limits the extensibility of our mapping. In case we would decide to include another specialised repair mission in our product line, we would also need to update this mapping. The mapping of the various identified feature expressions to the use-case model artefacts exposed no problems. However, modelling all variants in one model can result in large models which might become hard to understand for some modellers. To address this, using other modularisation techniques (e.g., the decomposition of all use cases specialising Execute Mission into a separate package) is possible. Likewise to the mapping shown in Fig. 11, one would then map the appropriate feature expressions to the model artefacts in the decomposed models which are later on composed using a compositional approach, i.e., UML package merge or model weaving. Similarly to the use case model we also mapped the features to activity models that contain inter-model variability. One example is the RescueMission (cf. Sect. 3.2). As can be seen in Fig. 13, inter-model variability is addressed in the FeatureMapper by modelling the variations in the model and mapping the corresponding feature

Relating Feature Models to Other Models of a Software Product Line

87

Fig. 13. Activity Model of the RescueMission where elements are coloured according to their feature mapping (Flood is blue whereas CarCrash is red)

expressions to the appropriate model artefacts. In the example, the feature expression Rescue AND CarCrash is mapped to the parts drawn in red colour and Rescue AND Flood is mapped to the blue parts. Since Flood and CarCrash are mutually exclusive, it is ensured that the model tailored to a specific variant forms a syntactically and semantically correct model. In case a specific combination of features requires the inclusion of a complete model, e.g., the activity model for the Execute Pumping Mission use case which is only included if the feature expression Pumping AND Firemen (cf. Fig. 11) evaluates to true, FeatureMapper can be used to assign the respective feature expression to the complete model. 4.2 Modelling the Mapping for Architecture and Design Models Similarly to the RescueMission activity model, the design model for the parts of the system relevant for the RescueMission contains modelling artefacts that are relevant

88

F. Heidenreich et al.


  

 

  

0

  ,*-

0

&''(

 4 * 0




&''(


 

 

 

   !  "     #  !  $%&''() &''( &''(  ", !  $%&''() &''( (''0  * !  $%&''()    " ./ !  $%&''()  + !  $%&''()  + "*#

 5 "   **$  !  $%0)  * "  !  " %&''()   , *, !  $%&''()

&''( &''(  

  .  

  1+ ". ! 2+ ".3 +%(''0)

 * #"-

         

  * "-+ ! 

*

 

0



        

(   +$ ! $

(      ! 1 "*



       2

2

Fig. 14. Class Model of the RescueMission where elements are coloured according to their feature mapping (Flood is blue whereas CarCrash is red)

for the CCMS and the FCMS (where some modelling artefacts only apply to one of the respective products). As can be seen in Fig. 14, variability also occurs at the granularity of attributes of classes, namely the attributes location and mobileNumber of the Victim class. Besides addressing inter-model variability by modelling all variants of a specific subsystem in one model, FeatureMapper also allows to use compositional approaches for addressing variability. An example where cross-cutting changes to models are realized by model weaving based on graph rewriting has been presented in [34]. Another possibility is mapping feature expressions to compositional operators that are directly available in UML, i.e., the UML PackageMerge relationship [35]. Using FeatureMapper, one can directly associate feature expressions to both the merged package (i.e., the package that contains variant-specific refinements to the receiving core package) and the merge relationship. In this case study, we used this way of addressing variability for the realization of the various ExternalServices. Instead of modelling all external services in one model (which might get too large and difficult to manage), we modelled the ExternalServices in dedicated UML Packages that are combined with the core of the CMS using UML PackageMerge relationships. Figure 15 depicts the realization of the various ExternalServices in separate packages that are only merged to the core depending on the evaluation of the assigned feature expression. In this figure, we also show FeatureMapper’s Variant Visualization that gives an overview about the inclusion and exclusion status of different modelling artefacts depending on the selected set of features from the feature model. In this example, we included all external services except for Army and ExternalCompany which is why those packages are coloured different from the other ones. As described in Sect. 3.3, we have extended the product line with a MeasurementUnit feature which consists of the two alternatives MetricSystem and ImperialSystem. Depending on the feature selection, the respective measurement kind should

Relating Feature Models to Other Models of a Software Product Line

89


  

      

  

    

   

  

   

    
 

   

Fig. 15. Package Model of the ExternalServices using merge relationships between packages to increase modularisation




  

  

 

 



      !"#$$% "$



   

  





   

    

   

  

 

   !"#$$%

Fig. 16. Class Model for different types of Location including property-level variability at the distanceUnit attribute of RoadwayLocation depicted in FeatureMapper’s Property Changes View that highlights parts of models with property-level variability

be used in the design models of the CMS product line. Figure 16 shows the part of the design models which is concerned with describing different kinds of Location. Depending on the selected feature expression, the attribute distanceUnit of the RoadwayLocation class should have a default value according to the feature selection. In Fig. 16 we show the variant for MeasurementUnit AND MetricSystem. To actually assign such changes of model properties to feature expressions, FeatureMapper has a recording mode, where the developer first selects the appropriate feature expression and then performs the actual change to the property (e.g., changing element names, cardinalities, or default values) in the model. This change is recorded internally and assigned to the feature expression in FeatureMapper’s mapping model. For these changes, only one version can be shown directly in the diagrams at any one time. FeatureMapper’s Property Changes View highlights the model elements where property changes occur in the model (cf. Fig. 16) in red. The different alternatives can then be inspected in a dedicated dialog as shown in Fig. 17.

90

F. Heidenreich et al.

Fig. 17. Dedicated dialog in FeatureMapper to inspect property-level variability

5 Application of VML* to the Case Study This section shows how the Variability Modelling Languages from the VML* language family [11] can be applied to the case study. VML* is a family of languages for modelling the mapping between feature models and other models of an SPL (called target models). Each language is customized for the specific target modelling language for which it is to be used. For instance, if in a SPL we are using UML activity diagrams, using VML* we can create a language specifically designed for managing variability in UML activity diagrams. VML* provides a generative infrastructure for efficiently developing such customized languages. To apply VML* to the case study, we must first develop the specific customized VML languages we need. Notice that this step must only be taken once; the languages created can be reused for other SPLs as long as the feature and target modelling languages remain the same. In Sect. 5.1, we will briefly discuss how to create the languages required for this case study. We then discuss the application of each individual language. 5.1 Creating VML Languages VML languages are defined using a so-called language-instance descriptor [11]. A complete support infrastructure can then be generated from the language-instance descriptor. The language-instance descriptor is a domain-specific metamodelling language [36] that allows language developers to model only those parts of a new VML language that need to be customized. All other parts of the language and its support infrastructure are generated and, thus, reused for each language. Figure 18 shows an excerpt from a language instance descriptor for one of the customized languages we will need for this case study: VML4RE, a language for mapping from feature models to requirements models, specifically UML Use Case and Activity diagrams [37]. The full language will be used in Sect. 5.2. The language-instance descriptor makes use of an openArchitectureWare Xtend [38] extension file defining a number of model-transformation operations. For example, in the first section called ‘features’ (Lines 4–8), the language–instance descriptor defines the metamodel for feature models that can be used with VML4RE and also provides the name of an Xtend operation that can extract all defined features from such a feature model. The next section (Lines 11–16) similarly defines the metamodel for target models and a function for finding a set of model elements based on some textual description called a designator.

Relating Feature Models to Other Models of a Software Product Line

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

91

// Define a new language called vml4req vml instance vml4req { // This section defines the type of variability model and how to access it features { metamodel "/bin/fmp.ecore" // Extracts all variability units from a variability model function "getAllFeatures" } // This section defines the type of target model and how to access it target model { metamodel "UML2" type "uml::Package" // Metamodel type of a model // Function to interpret pointcut designators function "dereferenceElement" } // Importing plugins and external specifications ... // Syntactical definition of available actions actions: createInclude { params "List[uml::UseCase]" "List[uml::UseCase]" } insertUseCase { params "String" "uml::Package" } ... // Definition of available evaluation aspects aspects: transformation { // Evaluation for product derivation // Defines adapter for product-configuration access features { type "String" function "getAllSelectedFeatures" } // Definition of the semantics of actions as model transformations createInclude { function "createIncludes" } insertUseCase { function "createUseCase" } ... } tracing { createOps “create* (*)” removeOps “remove* (*)” } }

Fig. 18. Excerpt from a VML* language-instance descriptor for a VML language for mapping feature models to requirements models

VML languages use a notion of pointcuts for referencing points in target models that need to be manipulated when a certain feature has been selected. Thus, the designators to be interpreted by this function may contain wildcards. The ‘actions’ section (Lines 22–29) syntactically defines what actions are available in VML4RE. It can be seen that these actions are specific to the manipulation of use cases and activities. Their semantics is further specified in the final ‘aspects’ section,

92

F. Heidenreich et al.

that allows to define a number of different semantics for different evaluation aspects, such as product derivation (specified in the ‘transformation’ aspect) or tracing. For the product-derivation semantics, we need to specify another adapter (Lines 35–38) that is able to interpret product configurations and extract the selected features. Next, we provide an Xtend implementation function for each action. For the tracing semantics (Lines 48–51), we define pointcuts into our transformation implementation identifying places where new model elements are created or existing ones deleted. On the basis the above approach, we have defined two languages: VML4RE for mapping features to requirements models and VML4Arch for mapping features to architectural and design models. Once we have thus defined the necessary languages, we can apply them to our case study, as will be demonstrated in the following subsections. 5.2 Modelling the Mapping for Requirements Models In this section, we show the mapping for requirements models; that is, the set of core requirements models and how VML4RE can be used to derive product requirement models. Before using VML4RE to manage variability, it is necessary to decide which models are going to be considered as core; i.e., the models which will be manipulated according to the different variants and combinations between them to obtain the product models. Figure 19 shows the considered core use case model for the CMS. Here, we followed a positive variability approach, so this use case model contains use case model elements related with mandatory functionalities only. For example, the model contains the use case Execute Mission. However, at this stage, it does not contain any details about which type of missions are supported by the system, since specific missions are all optional in the feature model of CMS. Since requesting external resources and assigning internal resources are mandatory functionalities across the SPL, they are also present in this figure. We have also specified the variability for more fine grained models, such as scenarios associated with each use case, represented through activity diagrams. For activity diagrams, we have considered as core models several scenarios represented with activity diagrams, such as Assign Internal Resource, Execute Pumping Mission, and Execute Super Observer Mission. For Execute Pumping Mission

Fig. 19. Core use case model for the Crisis management System

Relating Feature Models to Other Models of a Software Product Line

93

and Execute Super Observer Mission we adopted a negative variability approach, so if any of the related features are not selected in a configuration, these model elements are removed from the model. We adopted this strategy since we believe that in some situations, it is preferable to model visually than constructing the same model using a set of textual descriptions. Another observation is that the behaviour included in this scenario is not shared between the two considered configurations, so we haven’t identified too fine grained variability for this scenario. For the rescue mission, we identified some variation points for each of the different configurations (car and flood crisis) but also some common parts. Figure 20 shows the considered core activity model for the rescue mission. This core model contains all behavioural elements which are shared by both car and flood crisis configurations. Figure 21 shows an excerpt of the VML4RE specification for the crisis management system SPL. Lines 6–10 show the variability management when the Rescue feature is selected in a configuration. Given a configuration, if the feature expression in Line 6 evaluates to true, a use case with name Execute Rescue Mission is created (Line 7) and an inherits relationship from this use case to the use case ExecuteMission (which was considered as core) is created (Line 8–9). VML4RE can generate trace links from features to requirements model elements based on actions, since there is implicit trace information in VML4RE specifications. However, VML4RE also offers a specialized operator which allows to explicitly trace features to requirements model elements. In this VML4RE specification, we can see that Lines 11-15 define explicitly a set of trace links from the feature Rescue and activity model elements. In this piece of VML4RE code, we are defining trace links from the feature Rescue to the core actions of Rescue activity model depicted in Fig. 20. Line 18–23 show the variability management for the Public Hospital feature. If this feature is selected, actors, such as Hospital

Fig. 20. Core Activity Diagram for the Rescue Mission Scenario

94 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66

F. Heidenreich et al. import features ; import core ; concern CrisisSystem { variant rescue for Rescue { insertUseCase ("ExecuteRescueMission", "CrisisManagementSystem"); createInherits ("CrisisManagementSystem::ExecuteRescueMission", "CrisisManagementSystem::ExecuteMission"); trace trace trace trace trace }

("ExecuteRescueMission::TransmitInjuryInformation"); ("ExecuteRescueMission::IdentifyVictim"); ("ExecuteRescueMission::RetriveMedicalRecord"); ("ExecuteRescueMission::AdministerFirstAid"); ("ExecuteRescueMission::BringToHospital");

variant public_hospital for PublicHospital { insertActor ("HospitalResourceSystem", ""); insertActor ("FirstAidWorker", ""); createAssociation (or( "HospitalResourceSystem", "FirstAidWorker"), "CrisisManagementSystem::ExecuteRescueMission"); } variant for and ( CarCrash,Rescue) { createAction ("RemoveVictimFromCar", "ExecuteRescueMission"); connectActivityElements("ExecuteRescueMission::dn2", "ExecuteRescueMission::RemoveVictimFromCar", "[isVictimLockedInCar]"); connectActivityElements("ExecuteRescueMission::RemoveVictimFromCar", "ExecuteRescueMission::FinalNode", ""); connectActivityElements("ExecuteRescueMission::dn3", "ExecuteRescueMission::FinalNode", "[false]"); } variant for not Rescue { removeElement("ExecuteRescueMission");//removes the core activity model } variant for and (Rescue ,Flood) { createAction ("RequestSpecialAssistance", "ExecuteRescueMission"); connectActivityElements("ExecuteRescueMission::dn2", "ExecuteRescueMission::RequestSpecialAssistance", "[isVictimHandicapped]"); connectActivityElements("ExecuteRescueMission::RequestSpecialAssistance", "ExecuteRescueMission::FinalNode", ""); createAction ("RecoverVictim", "ExecuteRescueMission"); connectActivityElements("ExecuteRescueMission::dn3", "ExecuteRescueMission::RecoverVictim", "[false]"); connectActivityElements("ExecuteRescueMission::RecoverVictim", "ExecuteRescueMission::FinalNode", ""); } variant for Observe { insertUseCase ("ExecuteSuperObserverMission", "CrisisManagementSystem"); createInherits ("CrisisManagementSystem::ExecuteSuperObserverMission", "CrisisManagementSystem::ExecuteMission"); insertActor ("SuperObserver", ""); createAssociation ("SuperObserver", "CrisisManagementSystem::ExecuteSuperObserverMission"); } variant for not (Observe){ removeElement("ExecuteSuperObserverMission"); } } order (rescue, public_hospital );

Fig. 21. Excerpt from the VML4RE specification for crisis management systems

Resource System and First Aid Worker and respective relationships are also created. Notice that VML4RE’s pointcut expressions allow us to connect all of these actors to their appropriate use cases in one action invocation (Lines 21–22). For this variation point, we use a positive variability approach. The creation of the use case model elements for the feature Public Hospital depends on the previous execution of the

Relating Feature Models to Other Models of a Software Product Line

95

actions related with the variant Rescue (the action depicted in Lines 6–16), so an order of execution must be specified here. VML supports the definition of order of execution between feature expressions. To define an order for this situation, we have named each of the features expressions (rescue and public hospital). The specification of the order of execution can be found in Line 66. Lines 25–33 show the set of actions to be executed if both Rescue and CarCrash features are selected. These actions construct the scenario for the rescue mission in the context of a car crisis (one of the products available for this SPL). The resulting scenario from executing this set of actions is the activity diagram shown in Fig. 6. Variability has also been defined for the rescue scenario in the context of a flood crisis system. Lines 39–50 show the set of actions to execute in the core rescue mission activity model, if both features Rescue and Flood are selected. One important note is that to use connect actions, the elements to connect should be named so that they can be referenced. One example of this is in Line 41, where dn2 indicates one specific decision node of the activity diagram. Because Rescue is an optional feature, it is also possible to have configurations in which the feature is not selected. For these configurations, the core activity mode for Rescue Mission should be removed. Lines 35–37 show the application of the action removeElement (modelElement) for these cases. Figure 21 also contains the variability management specification for the Observe Mission. When the feature Observe is selected, use case model elements related with this feature are constructed for the product model. As we said previously, for the Execute Super Observer Mission scenario (Activity Diagram) we adopted a negative approach. This means that the corresponding activity diagram was included in the core model, and in the case of unselection of this feature (Line 61) in a configuration, we remove this activity diagram (Line 62). The trace links generated by VML* (and thus by VML4RE) can be used to visualize the mapping between features and model elements. Figure 22 depicts part of the generated trace links for the Rescue feature, considering the flood crisis product. The AMPLE Traceability Framework (ATF) [39] offers several visualizations to show trace links. The left part of Fig. 22 shows a tree-based view and the right part shows a graphbased view. In the tree-based view, we can see the trace link between Rescue and Identify Victim. This trace link was created because of the explicit use of the action trace in the VML4RE specification (Line 12 of Fig. 21). On the other hand, a trace link has been generated from Rescue to the use case Execute Rescue Mission, because of the action present in Line 7. The graph-based figure on the right, shows several links created for the flood crisis product. In this view, the elements such as use cases, packages, actors, activity diagrams, actions and features are represented as nodes. Edges are used to represent a link between two elements. For each visual element (a node or an edge), we can also see the properties (type and name) of that element. For example, in Fig. 22 (graph-based view) we can see the properties for the feature Rescue at the top of the window. In this figure, we have also emphasized the set of trace links for this feature using a red rectangle. This view is useful to see how elements are linked—for example to see which requirements elements are shared between different features. We can see that there are two requirements elements (RecoverVictim and RequestSpecialAssistance actions) which are shared between the Flood

96

F. Heidenreich et al.

Fig. 22. Visualization of generated trace links from the feature Rescue to requirements model elements for the flood product using a tree-based view (left) and a graph-based view (right)

and Rescue features. These requirements elements were inserted when generating the product model, because the feature expression in Line 39 of Fig. 21 was true according to the flood crisis feature model configuration. 5.3 Modelling the Mapping for Architecture and Design Models This section describes the results of applying VML4Arch [26, 40] to the Crisis Management System. VML4Arch is a language for specifying the connection between feature models and UML 2.0 architectural models. Figures 23 and 24 show the aspect-oriented decomposition of the software architecture. The Core package contains the elements that are common to all the products. The elements for interacting with a specific external service, such as the Police, are encapsulated into a separate UML package (cf. Fig. 23). The same applies to the elements for managing each particular kind of crisis (cf. Fig. 24).

Fig. 23. Aspect-oriented decomposition of the Crisis Management System (I)

Relating Feature Models to Other Models of a Software Product Line

97

Fig. 24. Aspect-oriented decomposition of the Crisis Management System (II)

Thus, the elements that are common to the data structures for accomplishing any kind of mission (cf. Fig. 8) would be placed in the Core, specifying these data structures must be included in any kind of product derived from this reference architecture. This design is then refined in the CarCrisis and FloodCrisis packages. Each particular kind of crisis adds its own kind of missions and the specific data structures that are required for each kind of mission. For instance, the CarCrisis aspect adds the classes and relationships that are specific for accomplishing CarRescueMissions, i.e. the data structures shown in Fig. 5. Similarly, the data structures depicted in Fig. 5 would be added to the FloodCrisis package. Thus, depending on which features are selected, we need to combine a different set of packages. What packages need to be combined with the core to create a concrete product is specified using VML4Arch (cf. Fig. 25). The product derivation process determined by this VML4Arch specification is as follows: First of all, a new UML package representing the final product being derived is created. This package is called MyCrisisManagementSystem and it is initially empty. This empty package will merge those packages that correspond to selected features, e.g. CarCrisis or Police. The piece of code for creating this package (Fig. 25, line 06) is associated to the root feature of the feature model. Moreover, the MyCrisisManagementSystem package merges the Core package (Fig. 25, line 07), which represents the minimum and core functionality that any Crisis Management System must have. Since the root feature is always selected, this piece of code is always executed and the MyCrisisManagementSystem package is always created and a merge relationship is initially created between this package and the Core package. Merging packages are expressed in VML4Arch using the merge action. UML merge dependencies in the UML model are used to express dependencies between coarsegrained variants. These dependencies represent architectural information about the product line as a whole and are provided by the SPL architect. They must be maintained under any circumstances. The UML merge dependencies introduced through merge actions express which coarse-grained variants should be included in the architecture for a specific product. The merge action will only add its corresponding dependency if this is not already given by transitivity. Hence, given the following merge dependencies in the model: A --merge--> B, B --merge--> C, calling merge (A, C) will not have any effect since that dependency is already in the model by transitivity. In addition, if any other direct dependency becomes redundant, it is removed, for example, given additionally D --merge--> B, calling merge (A, D) will lead to

98

F. Heidenreich et al.

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

import features ; import core ; concern CrisisManagementSystem { variant for CrisisManagementSystem { createPackage ("MyCrisisManagementSystem", ""); merge ("MyCrisisManagementSystem", "Core"); } variant for CarCrash { merge ("MyCrisisManagementSystem", "CarCrash"); } variant for Flood { merge ("MyCrisisManagementSystem", "FloodCrisis"); } variant for SurveillanceSystem { merge ("MyCrisisManagementSystem", "SurveillanceSystem"); } variant for not SurveillanceSystem { remove ("SurveillanceSystem"); } variant for MetricSystem { setDefaultAttribute ( "Core::Datatypes::BasicDatatypes::RoadwayLocation.distanceUnit", "Core::Datatypes::BasicDatatypes::RoadwayLocation::KILOMETRES"); } variant for ImperialSystem { setDefaultAttribute ( "Core::Datatypes::BasicDatatypes::RoadwayLocation.distanceUnit", "Core::Datatypes::BasicDatatypes::RoadwayLocation::MILES"); } } // CrisisManagementSystem

Fig. 25. VML4Arch specification for the Crisis Management System

the final situation of A --merge--> D, D --merge-->B, B --merge--> C. Thus, the merge dependencies introduced in the VML4Arch specification are effectively those shown in Fig. 15, where CrisisManagementSystem corresponds to MyCrisisManagementSystem. Figure 23 may give the impression that all types from the Core package are duplicated throughout the product-line model. However, because a product is eventually represented by a single package merging all coarsegrained variants, these redundant copies of Core concepts will be merged into one again, removing all duplication and redundancy.8 8

Note that this implementation of merge is specific to VML4Arch. Other VML* languages may also need a similar action. They are free to use any implementation needed, so they could, for example, be based on [41].

Relating Feature Models to Other Models of a Software Product Line

01 02 03 04

99

variant for and (CarCrash, not (FirstAidMaterial)) { remove ("CarCrash::Datatypes::WaterBottles"); remove ("CarCrash::Datatypes::Blankets"); }

Fig. 26. VML4Arch specification for removing FirstAidMaterial

Fine-grained variations are managed through different VML4Arch operators, which allows, basically, to modified elements from an architectural design model, or remove them. We illustrate two different cases for this. In the first case, the Core package contains a set of data structures for identifying geographical locations (cf. Fig. 10), which must measure distances in different units depending on the country, where the system is deployed. It is decided that, by default, the system is configured for working with the metric system units, so KILOMETERS is specified as default value for the distanceUnit attribute (cf. Fig. 10). In case the Imperial system was selected, this value should be changed. This is made through the VML4Arch code contained in lines 32–36 of Fig 25, which basically says the default value for this attribute must be set to MILES. In the second case, let us suppose the first-aid material is an optional feature, instead of mandatory, inside this product line. WaterBottles and Blankets are considered first-aid material. We can think on separating WaterBottles and Blankets in a separate UML package and merging this package with the CarCrisis package. Nevertheless, as previously commented, this technique would quickly lead to the creation of a large number of small and practically meaningless aspects, with, in most of cases, a complex set of dependencies among them, which would make the design unmanageable. Instead of following this positive strategy, we follow a negative strategy. Thus, we simply leave the WaterBottle and Blanket resource in the design model, and in case the first-aid material feature were not selected, these classes are simply removed from this design model. It should be noticed that this removal should only happen if the CarCrisis option has been selected. Otherwise, if the CarCrisis option is not selected, the package containing this design would be not selected and the removal of these classes would not have any effect, as we can consider they were already removed as the package is not included in the final product. This is specified using the feature expression shown in Fig. 26, line 01. It establishes that, if CarCrisis has been selected, but FirstAidMaterial has not been selected, the classes representing WaterBottles and Blankets would also be removed.

6 Discussion and Comparative Analysis of the Two Approaches In the previous sections, we have shown how two approaches to variability mapping can be successfully applied to the case study. Both approaches were able to produce product models for the two products described in Sect. 3. In this section, we provide a comparative analysis of the two approaches. Table 1 gives an overview of the comparison criteria we have used and how they are met by the two approaches. In the following,

100

F. Heidenreich et al. Table 1. Overview of the comparison between FeatureMapper and VML*

Criterion Expressiveness Modelling Languages Supported

FeatureMapper Fully Generic

VML* Generic through customization Modification All

Variability Mechanisms Supported Negative and Only Support for Feature Expressions Supported Support for Feature Cardinality and No Support Cloned Features Useability and Analysis Support for Automatic product Supported derivation Analysis Support Feature Model, Mapping Model, Multiple Visualizations Accessibility of the Mapping Separate model maintained by Model tool Real-World Models Scalability Direct Annotation Support for Model Evolution Detection of Broken Mappings

Supported No Support

Supported Trace Links Separate model maintained by SPL engineer Pointcut Expressions No Dedicated Support

we first give a more detailed description and motivation of each criterion, followed by a detailed discussion of how two approaches meet each criterion. 6.1 Comparison Criteria Our comparison of VML* and FeatureMapper is mainly based on the application of the two approaches to the common case study, as discussed earlier in this paper, but also on our previous experience with these approaches in other case studies and application scenarios. We have selected nine comparison criteria. These criteria were chosen because they represent general concerns for variability mapping. In particular, the nine criteria can be grouped into three groups based on the general variability-modelling concern they are related to: 1. Expressiveness. This group assembles criteria that describe the variability space that can be covered by a particular approach. These criteria are (a) Modelling Languages supported; (b) Variability Mechanisms supported; (c) Support for Feature Expressions; and (d) Support for Feature Cardinality and Cloned Features. 2. Useability and Analysis. This group assembles criteria that describe the kinds of analyses and evaluations that can be performed and the useability benefits and drawbacks of a particular approach. These criteria are: (a) Support for Automatic Product Derivation; (b) Analysis Support; and (c) Accessibility of the Mapping Model.

Relating Feature Models to Other Models of a Software Product Line

101

3. Real-World Models This group assembles criteria that describe how the approaches deal with properties of real-world models. In particular, these criteria are: (a) Scalability; and (b) Support for Model Evolution. In the following, we briefly discuss each criterion in more detail before Sect. 6.2 applies them to a comparison of VML* and FeatureMapper. Modelling languages supported. With the advent of domain-specific modelling languages, a variability-modelling approach that only supports one modelling language is almost not usable. Some level of genericity in such an approach is, therefore, highly important. This is, especially true with regard to the target modelling language; that is, the language in which the SPL reference model is expressed. However, because to date there is no commonly agreed standard for feature modelling and a range of different types of feature models and tool realizations is available, a variability mapping approach should also have some genericity with regards to the feature-modelling approach used. Consequently, for this criterion, we compare if and how FeatureMapper and VML* can support different modelling languages both for feature modelling and for the target models. Variability mechanisms supported. As discussed in Sect. 2.1, we can distinguish three major variability mechanisms: 1. Negative Variability. 2. Positive Variability. 3. Modification of Model Elements. Both, negative and positive variability, have benefits and drawbacks: Negative variability uses one model of the complete product line, this model can become very complex, as it has to contain model elements for any product in the product line. Some parts of such a model may even contradict each other, making the model potentially very difficult to analyze and understand. Positive variability avoids this problem by separating model elements for each different product into different models. At the same time, this means that there can potentially be a large number of model fragments describing the SPL as a whole, making it difficult to get an easy overview of the SPL. This can potentially make it more difficult to spot feature interactions in the models. In contrast, with a negative variability approach many feature interactions can be identified directly, as all model elements are added to the same model. Therefore, it would be beneficial for a variability-modelling approach to support all forms of variability modelling, possibly even within the same specification, leaving the choice to the SPL designer based on what is best for each situation. Consequently, for this criterion we compare which variability mechanisms FeatureMapper and VML* support. Support for Feature Expressions. The relationship between features and model elements is typically not one-to-one. Instead, a particular combination of features may be realized by a single model element or a single model element may be required for a set of different features (regardless of combination), but not by other features in the SPL. A

102

F. Heidenreich et al.

typical technique enable expression of such more complex mappings is the use of feature expressions; that is, boolean expressions over feature names. Feature expressions are evaluated over product configurations; that is, concrete selections of features from a feature model. A simple feature expression consisting of a feature name only evaluates to true if the named feature is selected in the product configuration. Based on this, more complex feature expressions follow the standard rules for logical combinators. Consequently, for this criterion we compare if and how FeatureMapper and VML* support feature expressions in their variability models. Support for Feature Cardinality and Cloned Features. Feature models in their original form [5] are very good at representing configurative variability, but less good at more structural forms of variability. This issue has been addressed, at least partially, by more advanced forms of feature models, such as, for example, cardinality-based feature models [42]. Even though there are still many situations were it is better to use a domain-specific language for expressing structural variability (for example, where variations in workflows need to be expressed), cardinality-based feature models take an interesting step towards structural variability by allowing features to be selected more than once and with different configurations of their sub-trees. Mapping such so-called cloned features to target model elements poses a number of interesting challenges to variability mapping, which go beyond what is required for the criteria above. Therefore, we introduce a separate criterion for this capability. Consequently, for this criterion, we compare if and how FeatureMapper and VML* provide support for mapping cloned features onto target-model elements. Support for Automatic Product Derivation. Product derivation refers to the creation of models and implementations for a particular product in an SPL based on a selection of a subset of the features from the SPLs feature model. A central goal of all variability mapping is to automate product derivation as much as possible based on an explicit description of features, variant models and implementations, and the mapping between these. Consequently, for this criterion we compare if and how FeatureMapper and VML* automate product derivation. Analysis Support. Another good reason for making the relation between features and target model elements explicit is that it enables analysis. Variability models can be analysed in many different forms ranging from visualizations of different products or feature expressions or the generation of tracing information for example for changeimpact analysis all the way to formal consistency analysis (e.g., [43, 44]). Consequently, for this criterion we compare the types of analyses enabled by FeatureMapper and VML*, respectively. Accessibility of the Mapping Model. Variability modelling means to make the relationships between features and target models explicitly. However, this can be done in a variety of ways and these have an effect on the useability of a variability-modelling approach in particular scenarios. Here, we focus on two dimensions: 1) How is the mapping expressed, and 2) How is the mapping model managed.

Relating Feature Models to Other Models of a Software Product Line

103

Consequently, for this criterion we compare how FeatureMapper and VML* express the mapping as well as how they each manage the variability model and allow SPL developers access to it. Scalability. Real-life SPLs can have large feature sets and very large models. Thus, scalability of any approach to modelling variability becomes an important issue. Although the case study discussed in this paper is not elaborate and detailed enough to obtain precise data on scalability, and some qualitative arguments can be extracted. Our experience with this and a number of other case studies indicates that while some properties of the variability modelling approach can have an impact on scalability, the structure of the SPL model has by far the greater impact. This is so because effectively with SPLs, it is inevitable to make explicit every connection between any feature and its corresponding model variations; that is, the amount of information to be represented is determined mainly by the size of the feature and SPL models and the inherent complexity of their relationship. The simpler the relationship between the two, the more easily can be represented and the larger the SPLs that can still be handled. At one extreme, feature-oriented software development [45] proposes a direct one-to-one mapping between features and implementation modules, making explicit mapping representations virtually unnecessary. However, in practice, this cannot always be achieved perfectly and may lead to unnecessarily many unnecessarily small implementation modules, so an explicit mapping representation is still needed. In our discussion above, we have seen how the choice between variability mechanisms can influence the scalability of our variability models. For example, in the VML4Arch example, we saw how using UML packages and UML merge dependencies could significantly reduce the amount of VML4Arch code to be written for a variability specification. If we were to describe the necessary elements of the CarRescueMission design model as part of the variability model, we would need to create 9 elements (7 classes plus 2 enumerations). Moreover, we would also need to create 11 relationships among these elements. Therefore, we would need approx. 20 lines of VML4Arch code for creating the design model depicted in Fig. 9. Using UML packages and merge relationships, we can reduce the number of VML4Arch lines of code to just one. Moreover, we need only one line of code independently of the size of the model placed in a UML package, as the only thing we need to express is that this package needs to be included in the final product. Each new type of crisis management system only requires adding another package and one line of VML4Arch code. However, at the same time, it is not sensible to represent every variation in its own package. If we were to do so even for, for example, such small variations as the difference between using the imperial and the metric measurement system, we could easily end up with a large number of packages with not much meaningful contents, fragmenting the SPL model to the point of incomprehensibility. Although this discussion applies equally to both approaches discussed, there are some differences between the approaches that may affect scalability. Consequently, for this criterion, we provide a qualitative discussion of different capabilities FeatureMapper and VML* provide for dealing with large models and feature sets. Support for Model Evolution. SPLs are not static and, consequently, variability models cannot be static artefacts. Therefore, it is interesting to discuss what, if any, support

104

F. Heidenreich et al.

for evolution a variability-modelling approach provides. There is a number of dimensions to this criterion. It includes evolution of the metamodels for features or target modelling language. It also includes, however, evolution of the actual feature and target models and the need to co-evolve the variability models along with them. The common case study does not provide any evolution scenarios. Therefore, we cannot directly use the experience from our application of FeatureMapper and VML* to the common case study to provide insights in how the two approaches cope with evolution. However, because we feel this criterion is essential in any variability mapping approach, we decided to include at least some analytical discussion of how FeatureMapper and VML* could deal with model evolution. 6.2 Comparative Analysis of VML* and FeatureMapper In this subsection, we use the criteria from the previous subsection to compare FeatureMapper and VML*. Modelling Languages Supported. While both FeatureMapper and VML* are generic and work for arbitrary modelling languages, there are some differences that are worth discussing in more detail. FeatureMapper is a tool that can work with arbitrary EMF models and supports a range of different editors for these models, including arbitrary GMF-based editors, the standard EMF tree editors, and EMFText-based text editors. In contrast, VML* produces mapping languages for specific modelling languages. Thus, it is, also generically applicable for any EMF model, but only if an appropriate VML language has previously been defined. Consequently, there is an added initial cost to using VML* in a project, in particular if a large number of project-specific or domain-specific languages are used. On the other hand, because VML languages are customized for each modelling language used, they can take into consideration the semantics of these modelling languages, providing much more powerful actions than generic direct mappings between features (or feature expressions) and model elements. As an example, consider VML4Arch’s connect (C1, C2, I) action, that connects components C1 and C2 via interface I. To express the same in FeatureMapper, we would have to produce mappings to the appropriate ports in C1 and C2 as well as to the dependencies between these ports and the interface I. Although connect does not currently support this, it could even easily be extended to create interface I if it does not exist yet. The cost of customising VML* to a particular target language can be decomposed into two parts: (i) the effort needed to implement adapters for dealing with different meta-models and (ii) the effort needed to implement the actions required. With respect to the former, both VML* languages we have discussed (VML4RE and VML4Arch) use feature models based on the FMP plugin for Eclipse and UML Models using the UML plugin for Eclipse, so we were easily able to reuse this code between the two languages. It should be noted, though, that even so the code needed is relatively compact and easily understood (at about 20 lines of recursive navigation code for accessing the UML models; accessing FMP models is more complex due to some special particularities of the FMP metamodel, which hinders its navigation when Xtend is used as model transformation language.)

Relating Feature Models to Other Models of a Software Product Line

105

Table 2. Qualitative and Quantitative Estimated Effort for the VML4RE and VML4Arch languages Criterion Average number of code lines per action Difficult action implementations Action implementations medium difficulty Easy action implementations

VML4RE 5

VML4Arch 14.54

None None

2 2

All

9

In terms of the effort needed to implement the actions in a VML* language, Table 2 provides an overview of some data on the VML4Arch and VML4RE implementations. In particular, it shows the number of lines of transformation code required, on average, per action implementation as well as a subjective judgment of how many of these action implementations were difficult or easy to understand, code and test. More substantive empirical studies are required to provide more robust knowledge about the cost involved in customising VML* to a particular target language, overall because the effort involved in the development of a new VML* language starts to be cost-effective when this language is applied to the development of several SPLs or a same SPL evolves and the VML* language helps to reduce the maintenance cost. This task goes beyond the scope of this paper. However, already from Table 2, it can be inferred that all actions for VML4RE could be implemented with reasonable effort. In the case of VML4Arch, there are some actions, such as merge, which required a bigger effort. It should be taken into account this action must carry out several checks to avoid redundancies, which increases its complexity. However, at the same time, it encapsulates more work than more simple actions, such as, for instance, createPackage. Although more complex, actions such as merge it is expected helps in saving more work each time it is used, because it makes the VML* language more powerful. Other actions, such as connectPorts, becomes complex due to the complexity of the UML metamodel [46]. In this case, the effort required for implementing this action would be similar to the effort required, if we implemented the product-derivation process using a low-level model transformation language, because the complexity is on the target metamodel itself, not in the approach used to manipulate this target metamodel. Therefore, it can be only avoided changing the target metamodel. It should also be noted that the effort required depends heavily on the transformation language used (in the case of VML* this is Xtend). Therefore, these data would not easily generalize other tools using a similar approach, but different transformation language. An important drawback of VML* is that it currently does not support textual modelling languages (where they are not backed by an Ecore-based abstract syntax) and produces no diagram files for visual modelling languages. While FeatureMapper supports any Ecore-based target language, it must be customized with regard to the used feature metamodel. Besides its own feature metamodel, those of pure::variants and FMP are supported and further metamodels can be added via a dedicated extension point. VML* languages can be easily customized for both target and feature modelling language, as

106

F. Heidenreich et al.

long as the feature modelling language provides some notion of selected features in a configuration. Variability Mechanisms Supported. FeatureMapper associates model elements with features (or feature expressions) directly. This makes it difficult to support positive variability, as the model elements to map to must effectively already exist in the core model. When using negative variability only, all different variants must be expressed in the models. This also implies that in some cases, models are created that are not well-formed w.r.t. the corresponding metamodel simply because two alternatives are expressed in one model using a language that was initially not designed for dealing with variability. However, many current modelling editors do not prohibit the violation of certain constraints (especially semantic constraints), which should then be checked and enforced by the respective SPL tool [47]. Having multiple variants in one model can also introduce difficulties in understanding the model and the variability. However, FeatureMapper offers multiple visualizations which can in turn increase understandability by explicitly highlighting parts where variability occurs (e.g., the Colouring View cf. Fig. 11). Using colour coding to distinguish between different feature expressions scales only up to a limited number of colours. Hence, FeatureMapper does not assign colours automatically, but gives the SPL developer the choice on which feature expressions and related modelling elements are of particular interest. In our experience, using up to twelve different colours is still feasible. Although FeatureMapper allows negative variability only, positive variability can be supported indirectly. If the SPL architecture is expressed using some compositional approach (e.g., model weaving or UML package merge) and the composition is available as a model in its own right, FeatureMapper can be used to map feature expressions to parts of the composition model. This negative variability on the composition model effectively implies positive variability using aspects (cf. Sect. 2.1) for the actual SPL model. In contrast to FeatureMapper, in VML* every action is effectively a small transformation of the core model. This means that an action is free to inspect, modify, and add model elements of the core model. VML* can, thus, easily support positive variability and negative variability, as well as any combination thereof. However, there are, a number of remarks to be made: 1. A concrete VML language may restrict the set of variability mapping approaches supported because it only defines actions for some approaches and not for others. We have seen a concrete example in the comparison of VML4RE and VML4Arch above. 2. Mixing negative and positive variability mapping in the same specification may cause problems in product derivation, as the order in which the model transformations are executed becomes important. For example, when negative variability is used to remove a model element from a larger model fragment that is added to the core model using positive variability, it is important that the model fragment is added before the negative-variability remove actions are executed. VML* allows developers to specify the order in which variants are evaluated, but this still places

Relating Feature Models to Other Models of a Software Product Line

107

an additional burden on SPL developers. Using only positive or negative variability throughout simplifies this issue substantially. 3. The richer semantics of VML* actions means that a much richer combination of variability mapping techniques can be used with VML*. At the same time, however, such complex operators (e.g., createAction or createDecisionNode) move the definition and creation of modelling artefacts from the modelling language into the VML* script. Part of the SPL model is, thus, not immediately available in the appropriate modelling notation, but can only be properly inspected after product derivation. This may increase the cognitive load of the SPL designer. Using positive variability with aspects (cf. Sect. 2.1) can help here, as it allows to move most of the model elements back into the original modelling language. Both approaches can cater for modification of model elements. Support for Feature Expressions. Both FeatureMapper and VML* support the use of feature expressions in mapping models. FeatureMapper associates model elements in the SPL models with feature expressions indicating when a particular model element should be present. Users can then also inspect the SPL models using feature expressions to provide an indication of a product configuration to be highlighted in the SPL models. VML* specifications associate feature expressions with descriptions of the modifications of the target model necessary for a configuration satisfying the feature expression. Support for Feature Cardinality and Cloned Features. Neither of the two approaches provide special support for cloned features. This is also true for all other approaches known to us. Support for cloned features is, thus, an important area of future research. Support for Automatic Product Derivation. Both VML* and FeatureMapper support automatic product derivation. VML* provides this support as one possible evaluation semantics of a VML* specification, parameterised with a product configuration. FeatureMapper takes a mapping model and a product configuration as input and transforms the referenced solution-space models accordingly. In case transformation semantics need to be adjusted or refined for a specific modelling language, FeatureMapper offers an extension point where SPL developers can provide their own implementation of the product derivation semantics. Analysis Support. In [47], we have described the necessity to ensure well formedness on all input models, i.e., feature models, mapping models, and solution-space models. FeatureMapper ensures this on feature models by enforcing several constraints (including cross-tree relationships like requiresFeature and conflictsWithFeature). While VML* currently does not support any analysis on feature models, it is certainly possible to implement. For mapping models, FeatureMapper checks whether all referenced features and modelling elements actually exist and informs the SPL developer in case the mapping model is broken. This kind of analysis can also be implemented in VML* (and has been implemented for the feature-model side), where the dedicated editors could inform the SPL developer via problem markers of such problems. Checking all possible variants of solution-space models is not a feasible way to

108

F. Heidenreich et al.

ensure well formedness [43, 44]. In [47], we outline our current and future plans for analysis of solution-space models with FeatureMapper that are based on the ideas of Czarnecki and Pietroszek [48]. Generally speaking, we would expect the formal consistency analysis to be achievable more easily with a declarative approach like FeatureMapper than an operational approach like VML*, because the semantics of the mapping are simpler in the declarative case. Recently, visualization techniques have come into the research focus as an interesting helper in understanding how the selection or unselection of features may affect the diverse models used in the design of the product line [49]. In the case of VML*, the only support provided is in the structure of a VML specification, where all actions are grouped by the feature expression to which they apply. Furthermore, trace links can be extracted from a product-derivation run based on a VML specification. These trace links relate features and created or removed model elements directly and can subsequently be used for visualization purposes. However, because the VML actions are small model transformations instead of direct mappings between features and model elements, a VML specification cannot directly be used for creating a visualization. Furthermore, a VML specification transforms models at the level of their abstract syntax, it does not produce a concrete-syntax representation (e.g., a diagram file or a textual representation of the model). This can make inspecting the result of product derivation difficult. In contrast, one of the key features of FeatureMapper is the rich set of visualizations available. An SPL designer can choose to view only model elements associated with an arbitrary feature expression, or with a product configuration. She can also view all model elements, but have them coloured according to the feature expression to which they have been allocated. All of these visualizations are made possible because FeatureMapper uses a much more generic semantics of the relation between features and model elements. In effect, there seems to be a trade-off between richness of the modelling concepts for variability mapping and ease of visualization creation. Accessibility of the Mapping Model. As mentioned previously, there are two dimensions to this criterion: 1) How is the mapping expressed, and 2) How is the mapping model managed. How is the mapping expressed? VML* is an operational approach (see Fig. 1). It expresses the mapping between features and model elements indirectly by specifying modifications of the target model in response to the selection or deselection of particular features (or feature expressions). The mapping model is expressed in textual form using terminology that has been customized to be close to the terminology SPL designers use when constructing the original target model. FeatureMapper, on the other hand, is a declarative approach using a separate annotation model (see Fig. 1). This has the benefit of making the mapping model much easier to comprehend as well as more amenable to analysis and visualization. At the same time, however, it limits the range of variability mechanisms that can be easily modelled in FeatureMapper (cf. the discussion on variability mechanisms earlier in this section). How is the mapping model managed? VML* leaves the creation and maintenance of the mapping model completely to the SPL developer. The tool only reads the model when it is asked to perform a specific action, such as product derivation. In contrast, with FeatureMapper the tool manages the mapping model and creates it from particular

Relating Feature Models to Other Models of a Software Product Line

109

gestures SPL developers make using the tool’s graphical user interface. The model is stored and maintained as an Ecore-based model that can be easily processed by FeatureMapper or any other tool that supports EMF. It is more difficult to read and maintain for SPL developers, who instead use FeatureMapper’s Associated Elements View to inspect the mapping model. Creation and update is intended (but not limited) to involve the FeatureMapper tooling. Scalability. As we have already mentioned in the introduction of the scalability criterion above, the biggest impact on scalability is in the structure of the SPL models. However, the variability-modelling approach can have some impact on scalability as well. FeatureMapper requires a single mapping relation to be constructed for every model element to be associated with a feature expression. In contrast, VML* allows pointcuts to be used to construct a set of mapping relations between model elements in one go (see Lines 15–16 in Fig. 21 for a simple example; in addition, VML* pointcuts also support the use of wildcards). This may reduce the number of lines of VML specification required for expressing the same variability and may, thus, contribute to overall scalability of the approach. Of course, because pointcuts come with their own wellknown issues such as pointcut fragility and potential increased complexity, the question of how much this really contributes to scalability cannot be answered easily. More detailed and quantitative studies of more complex systems are required to obtain a better answer to this question. Although FeatureMapper does not provide a dedicated pointcut language, it can utilise arbitrary Ecore-based AOM approaches, e.g., Reuseware [50] or XWeave [16], by mapping feature expressions to the respective composition programs. Eventually, this removes or keeps the composition program depending on the evaluation result of the assigned feature expression. Support for Model Evolution. As mentioned above, model evolution can be discussed both at the model and the metamodel level. Furthermore, we can discuss evolution of feature models (and metamodels), target models (and metamodels), and the mapping metamodel itself. Evolution of the mapping model corresponds to normal editing of this model, so no separate discussion is required for this case. FeatureMapper has a stable mapping metamodel which did not change since its initial design. It is very unlikely that it will be extended or changed in the near future, but if so, existing mapping models would need to be updated. This can be done automatically using model transformations. However, updating existing mapping models is only needed when existing metamodel elements are renamed, deleted or otherwise restructured in an evolution step. EMF handles additions to metamodels quite gracefully [12]. In contrast, VML* supports mapping-language evolution in the sense that it allows defining new or deleting existing operators when needed. Evolving the VML language by adding new operators is expected during an SPL’s life cycle, since its variations and the way the models must be manipulated changes over time according to new requirements, needs and products. In case the feature model changes in the sense that features referenced in a mapping model are renamed or removed, all mappings that reference this feature need to be updated accordingly, potentially all related target model elements must be removed

110

F. Heidenreich et al.

as well. Of course, this is not an automated task, but FeatureMapper helps the developer to identify the relevant mappings by highlighting them in the Associated Elements View where a warning symbol and an explanatory message are displayed next to the broken mapping. Similarly, VML* checks whether features referenced in a feature expression actually exist in the feature model and marks places in the specification that reference non-existent features. When a new feature is added to the feature model no problems will arise when generating products, however, modelling the corresponding model elements and managing its variability is necessary. No particular support for this is required or offered by FeatureMapper or VML*. Of course adding and removing features or model elements can cause impact on other model elements, and some restructuring of the model and VML script can be necessary. However, this is part of the SPL process, which is creative with small iterative improvements that can impact the overall SPL structure. Where the feature metamodel changes, a new adapter is required for both VML* and FeatureMapper. Because both tools can be configured with such adapters for feature models, changes in the feature metamodel should not cause major problems. Of course, any feature models will need to be adjusted to the new feature metamodel, but this task is independent of the use of FeatureMapper, VML*, or any other variability-modelling approach. When a target model changes, if only elements are added, no problems will arise in the VML* script during product derivation, because all model elements referenced by the script are already there. However, the VML* script may need to be updated to manage the variability of the newly added elements to get the expected product when deriving products. If a negative variability approach is being used to manage variability of these new functionalities, the VML* operators should be used to remove these elements when the correspondent features are not selected. If elements of the domain model are deleted or renamed and those elements are referenced by the VML* script, the script must be updated accordingly, otherwise problems will arise when deriving products. The removal of elements in the domain model can occur because functionalities represented by the removed elements are not needed anymore in the SPL context, or when migrating from a negative approach to a positive approach. In the latter case, the elements deleted from the domain model must be created through VML* operators. Currently, VML* does not support SPL developers in identifying broken links to target model elements. However, this is due to the prototype nature of the tooling rather than to any unsolved technical or conceptual issues. In contrast, FeatureMapper again uses the Associated Elements View to provide error messages where referenced model elements have been deleted or renamed. When the target metamodel changes, FeatureMapper mapping models do not require additional adaptations (apart from adaptations required by changes to the target model as a result of the changes to the target metamodel). In the VML* case, it may become necessary to define new operators or modify the definitions of the existing operators. This in turn may require adaptations to the mapping model itself. An interesting research area worth investigating is the synchronized refactoring of feature models, mapping models, and solution-space models. Initial work in this direction has been presented in [51].

Relating Feature Models to Other Models of a Software Product Line

111

Table 3. Overall comparison of FeatureMapper and VML* FeatureMapper + + + +

Multiple visualizations Fully generic Automatic product generation Support for feature expressions

– Positive variability not directly supported – No support for cloned features

VML* + + + +

Support for all variability mechanisms Generic Automatic product generation Support for feature expressions

– Very limited visualization support – Cost of language customization – No support for cloned features

7 Conclusions We have compared two approaches to modelling the relationship between features and SPL models—FeatureMapper (cf. Sect. 4) and VML* (cf. Sect. 5). Table 3 summarizes the comparison giving an alternative view in Table 1. On balance, both approaches were very well suited for the variability in the case study, but with slightly different objectives. FeatureMapper is especially good for visualizing the variability in a product line and is based on a generic approach, meaning their is no initial overhead in applying it to any EMF-based modelling language. VML* is based on customising a language for each target modelling language, potentially incurring some setup cost at the beginning of a project, but this also allows for much richer semantics in the mapping specification. In terms of scalability, the key factor appears to be not the specific approach to variability mapping, but the way in which the solution-space models are structured. Thus, we argue that both approaches can be expected to scale approximately equally well. While a number of these points are specific to the two approaches compared and cannot be easily generalized, some points appear to be of a more general nature. In particular, it seems that the simpler semantics of declarative approaches makes it easier to provide analysis and visualization capabilities, while at the same time limiting the variability mechanisms that can be supported.

Acknowledgements The work presented has been supported by the European Commission through the FP6 STREP AMPLE (Aspect-Oriented and Model-Driven Product-Line Engineering), by the German BMBF through the FeasiPLE project and by the Spanish Ministry of Science and Innovation Project TIN2008-01942/TIN.

References 1. Kienzle, J., Guelfi, N., Mustafiz, S.: Crisis management systems: A case study for aspectoriented modeling. Transactions on Aspect-Oriented Software Development 7, 1–22 (2010) 2. Clements, P., Northrop, L.: Software Product Lines: Practices and Patterns. Addison-Wesley, Reading (2002)

112

F. Heidenreich et al.

3. Pohl, K., B¨ockle, G., van der Linden, F.J.: Software Product Line Engineering: Foundations, Principles and Techniques. Springer, Heidelberg (September 2005) 4. American Heritage: The American Heritage Dictionary. Houghton Mifflin, Boston, MA (1985) 5. Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, S.: Feature-oriented domain analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR-0211990, Software Engineering Institute (1990) 6. Batory, D., Sarvela, J.N., Rauschmayer, A.: Scaling step-wise refinement. IEEE Transactions on Software Engineering 30(6), 355–371 (2004) 7. Czarnecki, K., Antkiewicz, M.: Mapping features to models: A template approach based on superimposed variants. In: Gl¨uck, R., Lowry, M. (eds.) GPCE 2005. LNCS, vol. 3676, pp. 422–437. Springer, Heidelberg (2005) 8. Haugen, Ø., Møller-Pedersen, B., Oldevik, J., Olsen, G., Svendsen, A.: Adding standardized variability to domain specific languages. In: Proceedings of the 12th International Software Product Line Conference (SPLC 2008), pp. 139–148. IEEE, Los Alamitos (2008) 9. Heidenreich, F., Kopcsek, J., Wende, C.: FeatureMapper: Mapping Features to Models. In: Companion Proceedings of the 30th International Conference on Software Engineering (ICSE 2008), pp. 943–944. ACM, New York (May 2008) 10. Morin, B., Perrouin, G., Lahire, P., Barais, O., Vanwormhoudt, G., J´ez´equel, J.M.: Weaving variability into domain metamodels. In: Sch¨urr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 690–705. Springer, Heidelberg (2009) 11. Zschaler, S., S´anchez, P., Santos, J., Alf´erez, M., Rashid, A., Fuentes, L., Moreira, A., Ara´ujo, J., Kulesza, U.: VML* – a family of languages for variability management in software product lines [52] 12. Steinberg, D., Budinsky, F., Paternostro, M., Merks, E.: Eclipse Modeling Framework, 2nd edn. Pearson Education (2008) 13. Heidenreich, F., Johannes, J., Karol, S., Seifert, M., Wende, C.: Derivation and Refinement of Textual Syntax for Models. In: Paige, R.F., Hartman, A., Rensink, A. (eds.) ECMDA-FA 2009. LNCS, vol. 5562, pp. 114–129. Springer, Heidelberg (2009) 14. Ziadi, T., H´elou¨et, L., J´ez´equel, J.M.: Towards a UML Profile for Software Product Lines. In: van der Linden, F.J. (ed.) PFE 2003. LNCS, vol. 3014, pp. 129–139. Springer, Heidelberg (2004) 15. Loughran, N., S´anchez, P., G´amez, N., Garcia, A., Fuentes, L., Schwanninger, C., Kovacevic, J.: Survey on State-of-the-Art in Product Line Architecture Design. Technical Report Deliverable D2.1 (March 2007), AMPLE project http://www.ample-project.net 16. Groher, I., Voelter, M.: XWeave: Models and aspects in concert. In: Proceedings of the 10th International Workshop on Aspect-Oriented Modeling (AOM 2007), pp. 35–40. ACM, New York (2007) 17. 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 (2007) 18. Heidenreich, F., Henriksson, J., Johannes, J., Zschaler, S.: On language-independent model modularisation [53] pp. 39–82 19. Whittle, J., Jayaraman, P., Elkhodary, A., Moreira, A., Ara´ujo, J. (eds.): MATA: A Unified Approach for Composing UML Aspect Models Based on Graph Transformation [53], pp. 191–237 20. Fuentes, L., Nebrera, C., S´anchez, P.: Feature-oriented model-driven software product lines: The TENTE approach. In: Yu, E., Eder, J., Rolland, C. (eds.) CAiSE 2009, pp. 67–72 (2009)

Relating Feature Models to Other Models of a Software Product Line

113

21. Greenwood, P., Bartolomei, T.T., Figueiredo, E., D´osea, M., Garcia, A.F., Cacho, N., Sant’Anna, C., Soares, S., Borba, P., Kulesza, U., Rashid, A.: On the impact of aspectual decompositions on design stability: An empirical study. In: Ernst, E. (ed.) ECOOP 2007. LNCS, vol. 4609, pp. 176–200. Springer, Heidelberg (2007) 22. Lahire, P., Morin, B., Vanwormhoudt, G., Gaignard, A., Barais, O., J´ez´equel, J.M.: Introducing variability into aspect-oriented modeling approaches. In: Engels, G., Opdyke, B., Schmidt, D.C., Weil, F. (eds.) MODELS 2007. LNCS, vol. 4735, pp. 498–513. Springer, Heidelberg (2007) 23. Beuche, D., Papajewski, H., Schr¨oder-Preikschat, W.: Variability Management with Feature Models. Science of Computer Programming 53(3), 333–352 (2004) 24. Ziadi, T., J´ez´equel, J.M.: Software product line engineering with the UML: Deriving products. In: Proceedings of the 10th International Software Product Line Conference (SPLC 2006), pp. 557–588 (2006) 25. Botterweck, G., O’Brien, L., Thiel, S.: Model-driven derivation of product architectures. In: Proceedings of the 22nd International Conference on Automated Software Engineering (ASE 2007), pp. 469–472 (2007) 26. S´anchez, P., Loughran, N., Fuentes, L., Garcia, A.: Engineering languages for specifying product-derivation processes in software product lines. In: Gaˇsevi´c, D., L¨ammel, R., Van Wyk, E. (eds.) SLE 2008. LNCS, vol. 5452, pp. 188–207. Springer, Heidelberg (2009) 27. Krueger, C.W.: Gears white papers (2006), http://www.biglever.com/learn/whitepapers.html 28. Bakal, M., Krueger, C.W.: The rhapsody/gears bridge - spl for mdd. In: Proc. of the 11th Int. Conference on Software Product Lines (SPLC) - Workshops, Kyoto, Japan, pp. 139–140 (September 2007) 29. Groher, I., Voelter, M.: Aspect-Oriented Model-Driven Software Product Line Engineering [53], pp. 111–152 30. Kienzle, J., Abed, W.A., Klein, J.: Aspect-Oriented Multi-View Modelling. In: Proc. of the 8th Int. Conference on Aspect-Oriented Software Development (AOSD), Charlottesville, Virginia, USA, March 2009, pp. 87–98 (2009) 31. Heidenreich, F., S¸avga, I., Wende, C.: On Controlled Visualisations in Software Product Line Engineering. In: Proceedings of the 2nd International Workshop on Visualisation in Software Product Line Engineering (ViSPLE 2008), collocated with the 12th International Software Product Line Conference (SPLC 2008) (September 2008) 32. The FeatureMapper Project Team: FeatureMapper (July 2009), http://www.featuremapper.org 33. The Topcased Project Team: TOPCASED (July 2009), http://www.topcased.org 34. Heidenreich, F., Wende, C.: Bridging the gap between features and models. In: 2nd Workshop on Aspect-Oriented Product Line Engineering (AOPLE 2007) co-located with the 6th International Conference on Generative Programming and Component Engineering, GPCE 2007 (2007), http://www.softeng.ox.ac.uk/aople/ 35. Object Management Group: UML 2.2 infrastructure specification. OMG Document (February 2009), http://www.omg.org/spec/UML/2.2/ 36. Zschaler, S., Kolovos, D.S., Drivalos, N., Paige, R.F., Rashid, A.: Domain-specific metamodelling languages for software language engineering. [52] 37. Alf´erez, M., Kulesza, U., Weston, N., Araujo, J., Amaral, V., Moreira, A., Rashid, A., Jaeger, M.C.: A metamodel for aspectual requirements modelling and composition. AMPLE Deliverable D1.3 (2007), http://ample.holos.pt/gest_cnt_upload/editor/File/public/ AMPLE_WP1_D13.pdf

114

F. Heidenreich et al.

38. Efftinge, S.: openArchitectureWare 4.1 Xtend language reference (August 2006), http://www.openarchitectureware.org/pub/documentation/4.1/ r25_extendReference.pdf 39. Anquetil, N., Kulesza, U., Mitschke, R., Moreira, A., Royer, J.C., Rummler, A., Sousa, A.: A model-driven traceability framework for software product lines. Journal Software and Systems Modeling (2009) (Published on-line first, June 29, 2009) 40. Loughran, N., S´anchez, P., Garcia, A., Fuentes, L.: Language support for managing variabil´ (eds.) SC 2008. LNCS, vol. 4954, pp. ity in architectural models. In: Pautasso, C., Tanter, E. 36–51. Springer, Heidelberg (2008) 41. Fleurey, F., Baudry, B., Ghosh, S., France, R.: A generic approach for automatic model composition. In: Aspect Oriented Modeling (AOM) Workshop colocated with MoDELS 2007 (2007) 42. Czarnecki, K., Helsen, S., Eisenecker, U.: Staged configuration using feature models. In: Nord, R.L. (ed.) SPLC 2004. LNCS, vol. 3154, pp. 266–283. Springer, Heidelberg (2004) 43. Janota, M., Botterweck, G.: Formal approach to integrating feature and architecture models. In: Fiadeiro, J.L., Inverardi, P. (eds.) FASE 2008. LNCS, vol. 4961, pp. 31–45. Springer, Heidelberg (2008) 44. Thaker, S., Batory, D., Kitchin, D., Cook, W.: Safe composition of product lines. In: Proc. 6th Int’l Conf. Generative Programming and Component Engineering (GPCE 2007), pp. 95–104 (2007) 45. Apel, S., K¨astner, C.: An overview of feature-oriented software development. Journal of Object Technology (JOT) 8(5), 49–84 (2009) 46. France, R.B., Ghosh, S., Dinh-Trong, T.T., Solberg, A.: Model-Driven Development Using UML 2.0: Promises and Pitfalls. IEEE Computer 39(2), 59–66 (2006) 47. Heidenreich, F.: Towards systematic ensuring well-formedness of software product lines. In: Proc. 1st Workshop on Feature-Oriented Software Development. ACM Press, New York (October 2009) 48. Czarnecki, K., Pietroszek, K.: Verifying Feature-Based Model Templates Against WellFormedness OCL Constraints. In: Jarzabek, S., Schmidt, D.C., Veldhuizen, T.L. (eds.) Proc. 5th Int’l Conf. Generative Programming and Component Engineering (GPCE 2006), pp. 211–220. ACM, New York (2006) 49. ViSPLE organisers: International Workshop Series on Visualisation in Software Product Line Engineering (ViSPLE) (2008–2009) 50. Heidenreich, F., Johannes, J., Zschaler, S.: Aspect orientation for your language of choice. In: Proceedings of the 11th International Workshop on Aspect-Oriented Modeling (AOM at MoDELS 2007) co-located with the 10th International Conference on Model Driven Engineering Languages and Systems (MoDELS 2007) (October 2007) 51. S¸avga, I., Heidenreich, F.: Refactoring in feature-oriented programming: Open issues. In: Proc. Workshop on Modularization, Composition, and Generative Techniques for Product Line Engineering, Department of Informatics and Mathematics, University of Passau, pp. 41–46 Technical Report MIP-0802 (October 2008) 52. Gray, J., van den Brand, M. (eds.): Proc. 2nd Int’l Conf. on Software Language Engineering (SLE 2009). Springer, Heidelberg (2009) 53. Katz, S., Ossher, H. (eds.): Transactions on Aspect-Oriented Software Development VI. LNCS, vol. 5560. Springer, Heidelberg (2009)

Aspect-Oriented Development Using Protocol Modeling Ashley McNeile1 and Ella Roubtsova2 1

Metamaxim Ltd, 48 Brunswick Gardens, London W8 4AN, UK [email protected] 2 Open University of the Netherlands, Postbus 2960, 6401DL Heerlen, The Netherlands [email protected]

Abstract. The aim of this paper is to explore the modeling of crosscutting behavioral abstractions. We argue that behavioral aspects can be seen as a particular kind of more general behavioral abstraction called a “mixin”. Mixins support a compositional style of modeling, whereby a complete class definition is constructed by composing one or more mixins each of which represents a partial definition of the class. If used as the replacement for inheritance, mixins can provide an expressive power equivalent to multiple inheritance. In this paper we use a modeling semantics called Protocol Modeling to illustrate how mixins can be used to represent behavioral aspects. We use the Crisis Management System case to illustrate the Protocol Modeling approach, and describe how the model can be executed to give early validation of its behavior. We discuss the extent to which the Protocol Modeling approach is scalable to large problems, is suitable for evolutionary development and supports correctness analysis and testing.

1

Introduction

Behavioral modeling languages can be seen as the next generation of abstract programming languages. This suggests that they are executable and capable of representing all the abstractions that have to be implemented in a final system. Objects, Services, Aspects, Components and Agents have to find their place and be distinguished in models. But a unified framework that supports all of these different types of abstraction using a common semantic base has yet to be found, perhaps because the behavioral semantic constructs currently used in modeling are not appropriate to this challenge. The Protocol Modeling approach [7] experiments with new semantic constructs for describing system behavior in terms of event protocols. The approach supports a highly compositional style of modeling, whereby a complete class definition is constructed by composing one or more partial definitions called mixins. If used as the replacement for inheritance, mixins can provide an expressive power equivalent to multiple inheritance [15]. But while mixins have S. Katz et al. (Eds.): Transactions on AOSD VII, LNCS 6210, pp. 115–150, 2010. c Springer-Verlag Berlin Heidelberg 2010 

116

A. McNeile and E. Roubtsova

been supported as constructs in programming languages1 they have not generally been seen as a construct in modeling languages, which have tended to employ hierarchical inheritance structures. However, as we demonstrate, mixinbased modeling is a viable alternative with the potential for wider expressive power. In Protocol Modeling, behavioral mixins are used as the building blocks of a model. They are used both to construct inheritance-like relationships (A is a “kind of” B) and also to separate out common behavior that is shared by a number of different entity classes. The modeling constructs of Protocol Modeling allow one mixin to abstract over the events, states and data of others, so that a single element of one mixin matches, or joins to, a number of different elements in other mixins. This gives the compositional calculus a flavor of “weaving” that is a feature of aspectual styles of software design. We suggest, therefore, that mixins composed in this way can be seen as a technique of aspectual modeling. In this paper we illustrate and justify this claim using a protocol model of a Crisis Management System [20], a case study developed by J¨ org Kienzle, Nicolas Guelfi and Sadaf Mustafiz for the comparative study of aspect-oriented modeling techniques. This paper is organized as follows: Section 2 provides an overview of the semantics of Protocol Modeling. Section 3 describes how Protocol Modeling is used to describe the classes of a system, their behavior and associated business process. Section 4 describes how a protocol model is built in stages using the information provided in a typical requirements specification. Section 5 describes our protocol model of the Crisis Managements System case and shows how Protocol Modeling embodies an aspectual style of modeling. Section 6 describes briefly how, in general, a complete protocol model is converted into a final, deployable, system. Section 7 classifies Protocol Modeling among other aspect-oriented approaches and emphasizes the features of Protocol Modeling that make it aspect-oriented. Section 8 discusses some practical considerations in Protocol Modeling, including some barriers to its use and the support it gives for model execution and testability, evolutionary development, scalability and determination of correctness. Section 9 contains related work and conclusions.

2

Protocol Modeling

In this section we provide an overview of the semantics of Protocol Modeling, sufficient to enable understanding of our solution to the Crisis Management System (CMS) case. A complete account of Protocol Modeling can be found in McNeile and Simons [7]. 1

For example: Lisp, Simula, Python and Smalltalk.

Aspect-Oriented Development Using Protocol Modeling

2.1

117

Events

In Protocol Modeling, the basis of behavior specification is identification of occurrences of interest in the environment (or domain). These occurrences are taken to be atomic and instantaneous. An “event” (more properly “event instance”) is the data representation of an occurrence in the environment as a set of data attributes. Every event is an instance of an event type. The type of an event determines its metadata (or attribute schema), this being the set of data attributes that completely define an instance of the event type. This approach to modeling occurrences in the domain as events is identical to that used in other event-based modeling approaches, such as those described by Jackson and Cook et al. [21,30]. 2.2

Protocol Machine

A Protocol Machine (hereafter referred to as just “machine”) is a reusable behavioral component of the model. A machine has a defined alphabet of event types that it understands. When a machine is presented with an event it will either ignore it, accept it or refuse it as follows: – If the event is not in its alphabet, the machine ignores it. – If the event that is in its alphabet, it will either accept it or refuse it. – Acceptance or refusal of an event by the machine is determined by protocol rules that are owned by the machine and that the machine evaluates both before and after the event. The protocol rules of a machine are normally depicted using a state transition diagram, where the transitions exiting a state show the event types that the machine accepts in that state. It is important to understand that “refusal” means that the machine is unable to handle the event at all in its current state, and this normally means that some kind of error message is generated back to the environment. How or where such an error message is generated is not of concern for modeling purposes. Between handling events, a machine has a well-defined quiescent state, meaning that it can undergo no further change of state unless and until presented with a new event. 2.3

Local Storage

A machine has local storage which only it can alter, and only when moving to a new state in response to an event. The local storage of a machine is represented as a set of attributes associated with the machine. A machine may read, but not alter, the local storage of other machines with which it is composed. A machine may use its accessible storage (its own local storage and the local storage of other machines composed with it) to compute

118

A. McNeile and E. Roubtsova

updated values of its own attributes when processing an event, and to compute the value of derived attributes. In addition, a machine may use its accessible storage to compute its own state, as we describe next. 2.4

Derived States

A protocol machine may have its state derived on-the-fly rather than being stored as part of the machine’s local storage. This is exactly analogous to the concept of a derived attribute, as defined in modeling approaches such as UML [24]. The states of a derived state machine determine what events it accepts and what events it refuses and in this sense the fact that states are derived makes no difference to their use as determinants of the machine’s behavior. For clarity of semantics, we do not mix derived and stored states in the definition of the same machine (although it is possible to compose derived and stored state machines using CSP parallel composition as described later in Section 2.6). Note that machines with derived state are not “topologically connected” as the new state that results from a transition firing is not determined as the end point of a transition. Further discussion can be found in the literature on Protocol Modeling [7]. 2.5

Modal Semantics

We shall see later when discussing Use Cases in Section 4 that derived states enable the definition of machines that have modal semantics, describing what is desired rather than simply what is possible. These machines are used to model the fact that the system may decide that a particular event is required and may solicit or prompt the event from the actor responsible for performing it. This gives protocols the expressive power to express workflow. The idea of using modal machines to describe workflow rules has been described by McNeile and Simons [8]. 2.6

Composition

A protocol model of a system is a non-empty finite set of protocol machines. Each machine presents a partial behavior and these partial behaviors work together to create the behavior of the system. The machines of a model are composed using a parallel composition operator (PQ)2 essentially the same as that defined by Hoare in his process algebra, Communicating Sequential Processes [10]: – The alphabet of the composed machine is the union of the alphabets of the constituent machines; and the local storage of the composed machine is the union of the local storages of the constituent machines. 2

Protocol Modeling approach also supports other composition forms [5,14] for composition of distributed abstractions. However, these composition forms are beyond the scope of this paper and we do not discuss them.

Aspect-Oriented Development Using Protocol Modeling

119

– When presented with an event the composed machine behaves as follows: 1. If both machines ignore the event, the composed machine ignores it; 2. If either machine refuses the event, the composed machine refuses it; 3. Otherwise the composed machine accepts the event. It is clear from this definition that the concept of event refusal 3 is critical to composition. 2.7

Concurrency and Determinism

Protocol machines are deterministic in the sense that executions of a protocol model are repeatable. If a given sequence of events is presented to a model twice starting from the same initial state, the final state of the model will be the same, as will be the set of events that it could accept next. The reason for requiring determinism is the ability that gives to argue about behavior based on traces4 . There is, however, no assumption that non-determinism may not be introduced at physical design time if it is decided to distribute the model across multiple (real or virtual) processors; but this must be done in such a way that the behavior of the model is not broken by such a distribution. Worker

Person

Want Log In created

Create Worker

log in not wanted

Delete Worker

Victim

log in wanted

Log In

deleted added

Employee Log In

Add Victim

CMS Employee Coordinator Create Crisis

Create Worker created

Create Worker

Set Login Create Worker Create Worker

See also Figure 3. Log In

logged out

logged in Log Out

created

Fig. 1. Graphical Representation (Fragment of CMS)

3

Representation of a Protocol Model

In this section we illustrate how models are described in ModelScope, the tool that we have used for developing and testing our model of the CMS case study. Using examples from the CMS case study, we illustrate how the various features of Protocol Modeling are used to address the requirements of the CMS system. Later, in Section 8.2, we discuss how ModelScope is used to explore and validate models. 3 4

Note that event refusal is not supported by the conventional semantics of UML statecharts [12]. Note that determinism is not guaranteed by the conventional semantics of UML statecharts [12].

120

3.1

A. McNeile and E. Roubtsova

Events and Machines

The event Create Worker is described as follows: EVENT Create Worker # Brings a new worker into existence ATTRIBUTES Worker: Worker, Person Name: String, Address: String, Date of Birth: Date, Expertise: Mission Type

This lists the ATTRIBUTES for this event type and describes each using attribute name: attribute type. The protocol machine Worker is described as follows: BEHAVIOUR Worker # A worker, either Internal or External INCLUDES Person STATES created, deleted TRANSITIONS @new*Create Worker=created, created*Delete Worker=deleted

This description gives the possible states, {created, deleted}, for a Worker and describes the behavior rules as a set of TRANSITIONS. Each transition is represented as starting state*event type=resulting state. The state @new represents the initial state of the machine, the “black dot”. It can be seen that this textual representation describes the state transition diagram shown in the central box at the top of Figure 1 (this diagram is a part of the overall protocol model of CMS that we describe later in the paper). Note that the graphical representation is partial, in that it does not show the attributes. The INCLUDES entry specifies that whenever the Worker machine is instantiated, an instance of the Person machine must be created too and composed with it. The Person machine is: BEHAVIOUR Person # Attributes shared by all types of Person ATTRIBUTES Person Name: String, Address: String, Date of Birth: Date

In this case, the included machine defines local storage attributes but does not define any behavior (transitions). The result of the composition is that a Worker will include the attributes defined in Person. The INCLUDES is the Protocol Modeling analogue of inheritance, but is a composition operator and to emphasize this difference we use a semi-hatched arrow (as opposed to the open arrow used for inheritance in UML Class Diagrams). The Person machine can be seen as more abstract than Worker as it is used by other machines: for instance, it is also used by Victim: OBJECT Victim # A Victim of a Crisis NAME Person Name INCLUDES Person

Aspect-Oriented Development Using Protocol Modeling

121

ATTRIBUTES Crisis: Crisis, Medical Condition: String STATES added TRANSITIONS @new*Add Victim=added

As can been seen here, a machine can be defined with both ATTRIBUTES and TRANSITIONS. When a Victim is instantiated, its local storage is the union of the set of attributes in the Victim and Person machines, following the semantics of composition in Section 2.6. The Victim machine is concrete (instantiable) and this is indicated by the use of the keyword OBJECT instead of BEHAVIOUR, and the inclusion of the NAME entry which specifies which attribute to use to identify instances of Victim in the ModelScope user interface. In the graphical view, as in Figure 1, we use the double outline for the enclosing box to indicate that a machine is concrete. 3.2

Structure of a Model

The INCLUDES structure of the mixins forms a partially ordered set5 (or “poset”). This is normal structure for model elements that represents multiple inheritance, as a given element may include more than one child and may be included in more than one parent. Note that this structuring is not apparent from the diagrams (Figures 1, 5 and 6) which have been drawn to fit in the limited space of a page. Given more space, these diagrams could be refactored to show the semi-hierarchical form of a partially ordered set, with all of the INCLUDE arrows pointing upwards. As an example, consider Coordinator. This is instantiatable (it uses the keyword OBJECT) and creation of its instance entails instantiation of one of each of machines{Coordinator, CMS Employee, Worker, Person, Employee Log In, Want Log In}: this being the transitive closure of its INCLUDES relationships shown in Figure 1. With the exception of Person, all of these machines have behavior and so, in accordance with Section 2.6, the total behavior for Coordinator is the CSP composition of the behaviors of these machines. 3.3

Attribute Handling

The convention in Protocol Modeling is that when an object (an assembly of machines) accepts an event the values of the event attributes transfer to matching attributes of the object. So, when a Create Worker event is accepted by the model, the values of {Person Name, Address, Date of Birth} will be given to the new Worker instance created. It is possible to define more complex updates with explicit update logic where required. We shall show examples of this later in the paper. 3.4

Derived States

As described in Section 2.4, some of the machines in a model can have derived rather than stored states. The Want Log In machine at the top right of Figure 1 5

A poset consists of a set together with a transitive binary relation that indicates that, for certain pairs of elements in the set, one of the elements precedes the other.

122

A. McNeile and E. Roubtsova

is an example, as is the machine Employee Log In in Figure 3. The ! prefixing the name of the machine tells ModelScope that it has to execute a function to determine the state of the machine. The code that calculates the state for the Want Log In machine is shown in Figure 2 and that for Employee Log In in Figure 3 (below the diagram). In the graphical form we use the double outline to the states to indicate that the state is derived. As mentioned in Section 2.4, machines with derived states are not “topologically connected” as the state value is not driven by transitions. The state value @any means “any state”. package AOMCase; import com.metamaxim.modelscope.callbacks.*; public class WantLogIn extends Behaviour {

Ties this java class with the machine “Want Log In”

public String getState() { //Login is wanted if there is at least one outstanding Assignment Request for this Employee Instance[] myAssignmentRequests = this.selectByRef("Assignment Request", "Internal Resource"); boolean logInWanted = false; for (int i = 0; i < myAssignmentRequests.length; i++ ) { if (myAssignmentRequests[i].getState("Assignment Request").equals("outstanding")) { logInWanted = true; } Gets all the “Assignment Request” } machines associated with this return logInWanted ? "log in wanted" : "log in not wanted"; “Internal Resource” (= Employee) } Returns the state of the machine.

}

Checks if this “Assignment Request” is still outstanding

Fig. 2. State Derivation of the “Want Log In” Machine

3.5

Modal Machines

As described in Section 2.5, some machines may have modal semantics for describing workflow. An example is the machine Want Log In which determines that an employee has outstanding requests for mission assignments and should therefore log into the system to attend to them. The ModelScope definition of the machine is below. The entry TYPE DESIRED defines this as a modal machine. BEHAVIOUR !Want Log In # Makes a login desired if there is an # outstanding Assignment Request for the Employee TYPE DESIRED STATES log in wanted, log in not wanted TRANSITIONS log in wanted*Log In=@any

As already noted, this machine has a derived state as indicated by the ! prefixing its name. 3.6

Actors

The machines of a model represent the objects of the domain and capture how events change the states of these objects. We also have to consider who is responsible for an event and this is modeled using the concept of Actors 6 . Different 6

Essentially the same as the concept of Actor in UML Use Cases.

Aspect-Oriented Development Using Protocol Modeling

123

events in the same machine may be the responsibility of different actors. As an example, consider the events in the Employee Log In machine in Figure 1. Responsibility for the Create Employee event, which sets up a new Employee in the system, falls to the System Admin Department 7 . However, the Log In event, which is also in the alphabet of this machine, is done by the employee him\herself in order to access the system. Actors are modeled completely separately from the machines and their behavior, and serve to configure the user interface so that each Actor gets an interface containing only the behaviors and events from the model that are appropriate to his\her responsibility. An example of an ACTOR definition is given below. ACTOR System Admin BEHAVIOURS CMS Employee, Crisis Type, Mission Type, Needed Mission EVENTS Create Worker, Set PDA Number, Set Login, Reset, Create Crisis Type, Create Mission Type, Make Needed

Actors form a separate layer that configures the user interface for the different users of the system. The Actor layer does not change the behavior of the underlying protocol model.

4

Building a Protocol Model

The starting point for building a protocol model can vary depending on the nature and stage of the project. Sometimes a general understanding of the area and the purpose of modeling is all that is available; and sometimes a detailed requirements document has been prepared. We will describe the process that is followed when starting from a written document such as that provided for the Crisis Management System [20] (hereafter referred to as “the CMS Spec.”), as this is quite typical. Before describing the process, one aspect of Protocol Modeling needs to be emphasized as it differs significantly from traditional approaches: the intention and best practice in building a protocol model is that it is executable and testable throughout the process of building an evolving model. This is useful and desirable even if the final code of the system is being hand-crafted rather than generated. We discuss the reasons for doing this later, in Section 8.2, and it is also well explored in the authors’ paper [4]. The process of building a protocol model is described below as a number of steps, but this is somewhat artificial. While the ordering of the steps does give the flavor of the normal strategy for building a model, in practice the process is very iterative and decisions can be revisited and changed at any time. 4.1

Step 1: Model the Domain

The starting point for building a protocol model is typically a Domain Model, such as that shown in Figures 4 and 5 of the CMS Spec. Using this, we proceed as follows to get to a first version of the model: 7

See Section 2.4.2 of the CMS Spec.

124

A. McNeile and E. Roubtsova

– Create an instantiable machine (using keyword OBJECT) for every concrete object in the model. – Specify the ATTRIBUTES for each machine. These are normally given as part of the Domain Model. – Define the lifecycle of each object, in terms of its STATES and the EVENTS that bring an instance into existence and change its state. The lifecycle will not be part of a standard Domain Model, which is normally just a static model. To find out the lifecycle, other artifacts such as Use Cases or Business Processes (Activity Diagrams) are used, or discussions held with domain experts. This will result in a first cut protocol model, which can be executed. At this stage the executable model allows domain objects to be instantiated and taken through their lifecycles. 4.2

Step 2: Model Associations

As well as describing the dynamics of the creation and state changes of objects, a protocol model also describes the dynamics of associations between objects: how associations between objects are created and dissolved. Associations are created by events that appear in the lifecycle of more than one object. For example, the Domain Model in Figure 4 of the CMS Spec. shows associations between Crisis and Crisis Type, and between Crisis and Coordinator. These associations are created by the event Create Crisis that appears in the lifecycles of Crisis, Crisis Type and Coordinator. The second step of building a model is to add events to the basic model formed in Step 1 to create and dissolve the associations in the model. Often, many of these will be already be there as a result of Step 1 but this is not always the case. In addition, the attributes of the objects in the model are checked to ensure that they contain appropriate foreign keys for the associations, thus the Crisis object should have attributes to hold the identifier of the associated Crisis Type and Coordinator. The result is a model in which the associations between objects can be created and dissolved. 4.3

Step 3. Model Inheritance

The third step is to model the inheritance. This involves refactoring the model by using abstract, non-instantiable, machines (using keyword BEHAVIOUR) to factor out attributes and/or behaviour that is common to multiple objects. Very often, the Domain Model identified the candidate inheritance relationships and these can be copied in the protocol model. Thus, the inheritance structure for various kinds of people and workers shown on the left hand side of Figure 5 in the CMS Spec. has been used to create an identical mixin structure in the protocol model shown in Figure 6. Note the following: – It is not necessarily a good idea to copy all inheritance relationships in the Domain Model. For instance, the Domain Model shows (Figure 4 in the CMS

Aspect-Oriented Development Using Protocol Modeling

125

Spec.) Car Crash as a specialization of Crisis Type. However, copying this would “hard wire” the different types of crisis that the system can handle into the model. Instead, we have made the Crisis Types “soft”, so that new types can be introduced into the system at run-time (using the Create Crisis Type event). – Protocol Modeling has natural support for multiple inheritance, whereas Domain Models are commonly built using only single inheritance and are correspondingly constrained in the specialization/generalizarion relationships that can be shown. For instance, Mobile Employee and Vehicle should (in our view) both be specializations of Resource, but this would require Mobile Employee to specialize from two parents. This constraint does not exist in Protocol Modeling, and in our model Mobile Employee INCLUDES (=specializes) both CMS Employee and Internal Resource.

Employee Log In (Refined version) 2

Security Password := Set Login.Password;

1

Entered Password := Log In.Password; Tries:= Tries + 1;

uninitialized

Set Login

Log In

logged out

Entered Password := “”; Tries:= 0;

trying

3

Log In Set Login 1

Security Password := Set Login.Password;

logged in

violation Log Out

Reset

package AOMCase; import com.metamaxim.modelscope.callbacks.*; public class EmployeeLogIn extends Behaviour {

State calculation. Returns exactly one of the values highlighted in red, indicating which state the machine is in.

public String getState() { // Derived State calculation if (this.getString("Security Password").equals("")) return "uninitialized"; if (this.getInteger("Tries") == 0) return "logged out"; if (this.getInteger("Tries") = 3) return "violation"; return "trying"; } public void processSetLogin (Event event, String subscript) { this.setString(“Security Password", event.getString("Password")); }

1

public void processLogIn (Event event, String subscript) { this.setString("Entered Password", event.getString("Password")); this.setInteger("Tries", this.getInteger("Tries") + 1); }

2

public void processLogOut (Event event, String subscript) { this.setString("Entered Password",""); this.setInteger("Tries",0); }

Store the entered password as the security it password d against i t which hi h to t compare when someone tries to log in.

Store the entered password to compare against the security password and add one to the number of tries.

3

public void processReset (Event event, String subscript) { this.setString("Entered Password",""); this.setInteger("Tries",0); } }

Fig. 3. Refined Employee Log In Machine

Reset values.

126

4.4

A. McNeile and E. Roubtsova

Step 4. Refine Machine Behavior

Normally the behavior built into a model in the early versions is a simplification of the actual requirement, and is refined and improved in later steps. This refinement can involve refining the definition of a machine already defined in the model, or adding new machines. For instance, in Figure 5, the machine Employee Log In (near the top right of the diagram) is a na¨ıve description of logging on, as it assumes that the Log In event will always work. This may be a reasonable assumption at early stages, so that basic testing of the model can take place, but does not take into account the fact that the password must be checked, or that there is a limit on the number of attempts that may be made, or the possibility that no password has yet been setup. To model these, the simple machine shown in Figure 5 is replaced by the one shown in Figure 3. This has the same two states as the original (logged in and logged out) but adds new states unitialized (for the case where no password has been set up), trying (for the case where the user is trying to enter a correct password) and violation (for the case where the user has exceeded his\her attempt limit). The new machine has a derived state rather than a stored one, but whether a state is derived or stored is private to a machine so does not complicate the substitution. Finally, note that the new machine requires a new event Reset to reset the machine if it is in the violation state.

package AOMCase; import com.metamaxim.modelscope.callbacks.*; public class AccomplishInternalMission extends Event {

Ties this java class with the event “Accomplish Internal Mission”

public void handleEvent() { //Send the Accomplish Internal Mission event to the model to change its state to accomplished this.submitToModel(); //Unassign all Resources for this Mission Instance[] myAssignedResources = this.getInstance("Mission").selectByRef("Internal Resource", "Mission"); for (int i = 0; i < myAssignedResources.length; i++) { Event releaseResource = this.createEvent("Release Internal Resource"); releaseResource.setInstance("Internal Resource", myAssignedResources[i]); releaseResource.submitToModel(); } Sends a “Release” event to release the Gets all the “Internal Resource” } “Internal Resource” from the “Missiom”. machines associated with this “Mission”. }

Fig. 4. Automated Events to Release Resources on Mission Accomplishment

4.5

Step 5. Model Event Automation

The steps so far have assumed that all events are initiated from outside the system. However, systems commonly initiate some events internally. For example, when a Mission is reported as accomplished, the System could automatically release all resources assigned to the mission. This kind of event automation requirement is addressed by associating a piece of logic with an event, executed when an event is accepted by the model that generates further automated events. This is indicated by prefixing the EVENT entry with !. Thus, !Accomplish Internal Mission has logic associated with it as shown in Figure 4.

Aspect-Oriented Development Using Protocol Modeling

127

Other examples of use of this technique in the CMS model are: – Adding a Witness if the initial report of the Crisis contains a witness report (attached to !Create Crisis). – Determining what kinds of Internal and External Mission are needed for a Crisis and creating recommendations to the Coordinator for such Missions (attached to !Make Recommendations). – Finding a suitable Internal Resource for a newly confirmed Mission and creating a Request Allocation (attached to !Confirm Mission). – Finding another suitable Internal Resource if a request for assignment is declined (attached to !Decline Request). 4.6

Step 6. Define the Actors

As pointed out Section 3.6, the actor responsibility for events is modeled separately from the underlying protocol machine model, using ACTORS. This is normally done once the model is substantially complete but before validating against Use Cases. 4.7

Step 7. Validate against Use Cases

The final stage is to validate the model against Use Cases. Generally, we take the view that Use Cases should be viewed as test cases whose satisfaction is necessary (but not sufficient) for acceptability of the model. Sometimes validation of the protocol model behavior against Use Case description can reveal the need to nuance the behavior of the system by adding modal machines, as described in Section 2.5. For example, Use Case 3 Step 1a.1 in the CMS Spec. says that “System requests the CMS Employee to login” and this is represented as a modal machine, Want Log In, which determines that the employee needs to log into the system in order to either accept or reject requests to be assigned to a mission. In ModelScope, an event that has been determined to be needed by a modal machine is highlighted in green in the user interface.

5

Protocol Model of the CMS Case Study

Our protocol model of the CMS case study is illustrated graphically in Figures 5 and 6. This graphical representation is intended as an overview and shows all the machines of the protocol model, their states and their protocol (what events are allowed in each state). It does not, however, show how data are handled: it omits attribute definitions, calculations for derived states and attributes, and the algorithms for generation of automated events. The full source of the model, including the full definition of data handling, can be downloaded from the Metamaxim website [6]8 . The ModelScope execution tool is also available from this site. 8

The model is available at: www.metamaxim.com/download/models/CMS.zip

128

A. McNeile and E. Roubtsova

Worker

Person

Want Log In created

Create Worker

log in not wanted

Delete Worker

log in wanted

Log In

deleted

Employee Log In

Victim

Set Login

added Add Victim

CMS Employee

Create Worker Create Worker

Create Worker created

External Worker

See also Figure 3. Log In

logged out

logged in Log Out

Coordinator Create Crisis Create Worker

Mobile Employee

Worker Location Create Worker

created Set PDA Number

Create Worker

Report Location

First Aid Worker

created created

Status Update

Super Observer

Car

created Create Worker

Vehicle

Truck

created

Ambulance

Internal Resource

Create Vehicle

Request Assignment Create Internal Resource

Add Witness Details

Witness created

available

complete

Add Witness

Assign Internal Resource assigned

Release Internal Resource

Report Verification Request Report Verification unchecked

Video Verification

report correct

Request Video Verification

Report Correct verification requested

Add Witness

report fake

External Resource System

Video Correct verification requested

unchecked

Report Fake

video correct

Create External Resource

Request Report Verification

Create Phone Company created

Video Fake

Add Witness video fake

Make Needed External, Recommend External Mission

Phone Company

Surveillance

Request Video Verification

Create Surveillance

Fire Station

created

Police Station created

Fig. 5. Protocol Model of the Crisis Management System (1 of 2)

Aspect-Oriented Development Using Protocol Modeling

Mission Type

Crisis Closable

Mission Set Recommendation

Make Needed, Recommend Internal Mission Create Mission Type

missions recommended Make Recommendations

created created

Make Needed, Make Needed External, Create Crisis

Crisis Type

Crisis

outstanding missions

Add Witness, Add Victim, Recommend Internal Mission, Recommend External Mission

Create Crisis

Create Crisis Type

Close Crisis

no outstanding missions

Create Crisis

notified

created

Close Crisis

closed

Mission Recommendation

External Mission Recommend External Mission

Accomplish External Mission

Confirm Mission created

accomplished

confirmed

Recommend not Mission resourced Confirm Mission confirmed Make Needed, created Recommend Internal Mission, Create Worker Accomplish Reject Mission Mission

Internal Mission Request Assignment, Assign Internal Resource

Recommend Internal Mission

Confirm Mission confirmed

created

rejected

Accomplish Internal Mission

accomplished

Mission Resourcing Status

accomplished resourced

Request Assignment

Accomplish Internal Mission

not resourced

Assignment Request Decline Request

declined

outstanding

A or D not wanted

Accept Request

Accept Request

Want Accept A or D wanted

accepted

Decline Request

Needed External Mission

not logged in

Needed Mission

Make Needed External

Logged In Check logged in Restricted Event

Make Needed needed

needed

Fig. 6. Protocol Model of the Crisis Management System (2 of 2)

129

130

5.1

A. McNeile and E. Roubtsova

CMS Domain Model

Most of the machines in our model correspond exactly to the classes in the Domain Model given in [20]. These are the shaded machines shown in Figures 5 and 6 of this paper, and their INCLUDE structure, shown using semi-hatched arrows, corresponds to the inheritance hierarchy of the Domain Model. The other, non-shaded, machines Figures 5 and 6 of this paper fall into two categories. Some are further domain objects that we have identified as needed to support functionality required in the CMS application. Others represent behavior that is sensibly modeled separately from the main behavior of an object and then included as a separate machine. In some cases this separated behavior is shared by more than one domain object, in which case it is included in all those to which it is relevant. Two examples from Figure 5 in the CMS model are: – The machine Internal Resource that is included in Mobile Employee and Vehicle. This machine models the ability of an object to be requested for, and then possibly assigned to, a mission. – The machine Worker Location that is included in Mobile Employee and External Worker. This machine models the ability of a mobile worker to report his\her current location. In both cases, the included machine handles an aspect of behavior that is separate and essentially orthogonal to that of the host machine. Because a protocol machine recognizes events from its own alphabet and ignores other events, it is both possible and natural to identify such behavioral aspects, concerned with different subsets of the overall alphabet of the object, and model them as separate machines. The resulting structure of behavioural aspects supports multiple inheritance of both data and behavior. In this sense, behavioral aspects in Protocol Modeling are not a “bolt on” added to model cross-cutting concerns, but the prime tool of modeling. 5.2

CMS Use Cases

As we described in Section 4.7, we use Use Cases to validate that the behavior in the model is able to address the various ways in which it is intended that the system will be used. We have verified our protocol model against all the Use Cases using this technique. We illustrate below how our protocol model meets the requirements expressed in three of the key Use Cases in the CMS Spec. UC1: “Resolve Crisis” . UC1.1 Coordinator captures witness report. Event Create Crisis allows a Coordinator to set up a Crisis and capture a Witness report at the same time. Further reports may be added using event Add Witness.

Aspect-Oriented Development Using Protocol Modeling

131

UC1.2, UC1.3 System recommends to Coordinator the missions that are to be executed based on the current information about the crisis and resources. Coordinator selects one or more missions recommended by the system. When the Coordinator creates a Crisis, the included machine Mission Set Recommendation is also created. Using the event Make Recommendations the Coordinator can ask the System to create an appropriate set of Internal Mission and External Mission machines (the types of mission recommended for a crisis is based on information previously set up to define the needed Mission Types for each Crisis Type). Each instantiated mission machine includes a Mission Recommendation machine that keeps track of whether the mission is confirmed or rejected. This machine offers two events, Confirm Mission and Reject Mission, allowing the Coordinator to select which of the system recommended missions are actually to be executed. Because the behavior for recommending or rejecting missions is identical for both internal and external missions, we use a common behavior Mission Recommendation and generic events Confirm Mission and Reject Mission for both. UC1.4 For each internal resource required by a selected mission, System assigns an internal resource. When the Coordinator uses Confirm Mission, the system finds an available Mobile Employee with the right expertise (found in his attributes) and creates an Assignment Request machine to request assignment of the employee to the mission. This machine allows the Employee to either Accept Request or Decline Request. If the Employee declines the request, the System automatically finds another candidate and instantiates a new Assignment Request machine for this candidate. UC1.5 For each external resource required by a selected mission, System requests an external resource. This step is similar to UC1.4. UC1.6. Resource notifies System of arrival at mission location. When an instance of machine Mobile Employee is created an instance of the included machine Worker Location is created too. This machine allows an Employee to use event Report Location to notify the system of his\her arrival at mission location. UC1.7. Resource executes the mission. An Employee uses event Status Update to update his\her own status and the status of the mission. UC1.8. Resource notifies System of departure from mission location. An Employee uses the event Report Location to report departure. UC1.9. In parallel to steps 6-8, Coordinator receives updates on the mission status from System. The information available from the events Report Location, Status Update and Accomplish Mission are available to the Coordinator.

132

A. McNeile and E. Roubtsova

UC1.10. In parallel to steps 6-8, System informs Resource of relevant changes to mission (crisis) information. The information available from the events Report Location, Status Update and Accomplish Mission are available to the Employees. UC1.11. Resource submits the final mission report to System. The Employee uses event Accomplish Mission to submit a final report. UC1.12. In parallel to steps 4-8, Coordinator receives new information about the crisis from System. The events Add Witness and Add Victim of machine Crisis are used to add further information about the crisis. UC1.13. Coordinator closes the file for the crisis resolution. The Coordinator uses event Close Crisis in machine Crisis to close the file. Event Close Crisis is possible when there are no outstanding missions. This state is derived by machine Crisis Closable. UC2: “Capture Witness Report”. UC2.1, UC2.2. Coordinator provides witness information to System as reported by the witness. Coordinator informs System of location and type of crisis as reported by the witness. These are modeled by the protocol machine Witness with the corresponding events Add Witness and Add Witness Details. UC2.2a.1, UC2.2a.2. System contacts PhoneCompany to verify witness information. PhoneCompany sends address\phone information to System and the extended requirement UC2.5a. PhoneCompany information does not match information received from Witness. These are modeled as machine Report Verification which is instantiated with acceptance of event Add Witness. UC2.2a.2 and UC2.5a represent different outcomes of witness verification modeled as events Report Correct and Report Fake leading to the corresponding states report correct and report fake. UC2.3a.1, UC2.3a.2 System requests video feed from SurveillanceSystem. SurveillanceSystem starts sending video feed to System and UC2.3a.3 System starts displaying video feed for Coordinator. These are modeled by machine Video Verification which is instantiated with acceptance of event Add Witness. UC2.5b.Camera vision of the location is perfect, but Coordinator cannot confirm the situation that the witness describes or the Coordinator determines that the witness is calling in a fake crisis.

Aspect-Oriented Development Using Protocol Modeling

133

This requirement represents a negative outcome of the verification. The video verification should definitely contain a positive outcome of verification which is omitted from the requirements. UC10: “Authenticate User”. This use case presents a commonly recognized Security aspect, modeling password protected access to functionality of a system. UC10.1. System prompts CMSEmployee for login id and password. This is captured by the state not logged in of protocol machine Employee Log In either that shown in Figure 5 or its refined version shown in Figure 3. UC10.2. CMSEmployee enters login id and password into System. This requirements specifies attributes of event Log In, namely Login and Password. UC10.2a. CMSEmployee cancels the authentication process. This is modeled by two possibilities. One possibility is that the employee has not yet succeeded in supplying a correct password. In this case he is not logged on and can just walk away. The other possibility is that he has succeeded in supplying a correct password. He is now logged in, so can log out. UC10.3.System validates the login information. These requirements are modeled by the refined version of Employee Log In shown in Figure 3. The Log In event is allowed provided the system is not states logged in or violation. The state of Employee Log In is computed by comparing the security password in the system with the password entered in the Log In event. If they do not match but the maximum number of tries (3) has not been exceeded, Employee Log In is in the state trying. If the passwords are identical and the maximum number of tries has not been exceeded Employee Log In is in the state logged in. UC10.3a, UC10.3a.1, UC10.3a.1a. System validates the login information. System fails to authenticate the CMSEmployee. CMSEmployee performed three consecutive failed attempts. If the security password in the system with the password entered do not match and the maximum number of tries (3) has been exceeded, Employee Log In is in the state violation. The state can only be reset to logged out using the Reset event. 5.3

Some Observations

A requirements document is never perfect, and building a protocol model helps identify gaps and inconsistencies. In particular, the discipline of identifying the protocol states of every object, and determining the events that cause entry and exit from every identified state, helps to ensure the completeness and coherence of the behavioral requirements. The illustrations of this from the CMS case are:

134

A. McNeile and E. Roubtsova

– No means is provided for defining how the system should determine what missions to recommend for a crisis (UC1.2, UC1.3). The system must have knowledge of the relationship between crisis types and mission types to do this. – Video verification (UC2.3a.2 and UC2.5b) should require a positive confirmation of verification. No means of doing this is given. – The need for a Reset (or a time out) (UC10) if the number of password tries is exceeded, is not discussed in requirement document.

6

From Model to System

While the protocol model of a system is an executable artifact, it is not, in general, deployable as the final system. Work is required to create an implementation that has the appropriate physical characteristics. Information from the protocol model can be directly used in this process, and an example is the extraction of an Entity Relationship Model. The attributes of the machines, given in the ATTRIBUTES entries of the machines in the model, are examined to identify those that represent “foreign key” pointers. These are the attributes that are typed using other machines: for instance, Expertise: Mission Type in Mobile Employee. Such foreign key attributes

Surveillance

Phone Company Crisis Type

1

1 1

0 …*

0 …*

Witness

Victim

Person Report Verification Video Verification

Person

1

1

0…*

0…*

0…*

Needed External Mission

Needed Mission

0…* 1

0…*

1

0…*

Crisis 0…*

1

Mission Set Recommendation Crisis Closable 0…*

1

Mission Type

1

1

1 0…*

1 0…*

Coordinator

First Aid Worker Mobile Employee Internal Resource Mobile Employee Worker Location Resource CMSInternal Employee Worker Location Worker CMS Employee Person Worker Employee Log In WantPerson Log In Employee Log In Want Log In

Mission Recommendation

0…*

0…*

Internal Mission

p y CMS Employee Worker Person Employee Log In Want Log In

Super Observer

External Mission

Mission Recommendation Mission Resourcing Status

1

1

Police Station 1 0…*

1

1

Fire Station External Resource System External Resource System

0…* 0…*

Assignment Request 0…* 1

1

0…1 0…1

Ambulance Car Vehicle Truck Internal Resource Vehicle Internal Resource Vehicle Internal Resource

Fig. 7. Entity-Relation Model of the Crisis Management System

Aspect-Oriented Development Using Protocol Modeling

135

can be used to create the “entity relationship” model shown in Figure 7, for instance the Expertise attribute results in the relationship marked with a star. This model can then be used as the basis of database design using traditional design techniques. The extraction of this model from the protocol model can be automated. The techniques and mechanisms used to convert a protocol model into a final system design depends on a number of factors, including the technology platform and the need to integrate with a pre-existing software architecture. Sometimes the process can be entirely mechanized and sometimes it cannot. Discussion of this is beyond the scope of this paper.

7

Aspect-Orientation of Protocol Modelling

In this section we discuss the claim of Protocol Modeling to be an aspect-oriented approach, and the way in which aspects have been used in our solution to the case study. 7.1

CSP Composition as Weaving

The basis for any claim to support aspects is a notion of weaving, whereby two independently defined parts of a model are combined but without explicit invocation, such a method or subroutine call. The mechanism for composition in Protocol Modeling is CSP composition, as described in Section 2.6. The semantics of CSP composition can be thought of as “trace weaving” whereby the sets of traces of individual protocol machines are woven to form the set of traces of the system as a whole. Because it works by synchronizing machines on events that are in the alphabets of both, CSP weaving uses events as join points. It is in these terms that we discuss the aspect orientation of Protocol Modeling. 7.2

Quantification of Event

Events in a protocol model may be described at different levels of abstraction using GENERIC events. This has two uses: – Where a number of different event types have the same treatment and effect in a given context. The difference between those event types may be abstracted away in contexts where the difference is immaterial. – To facilitate re-use, by allowing the creation of a generic definition that has different interpretations in different contexts. An example is of the first of these is Restricted Event, defined as: GENERIC Restricted Event # Events only allowed when an Employee is logged in MATCHES Accept Request, Decline Request

This abstraction is used in the machine Logged In Check at the bottom left of Figure 6 to model the fact that certain events are restricted (not possible) unless an Employee is logged into the system, but Logged In Check does not itself need to differentiate between the different kinds of restricted event.

136

A. McNeile and E. Roubtsova

An example of the second is Create Internal Resource, defined as: GENERIC Create Internal Resource # Events that can create an Internal Resource MATCHES Create Worker, Create Vehicle

When the model is run in ModelScope the following messages relating to it are generated as the model is compiled: Generic Generic Generic Generic Generic

‘Create ‘Create ‘Create ‘Create ‘Create

Internal Internal Internal Internal Internal

Resource’ Resource’ Resource’ Resource’ Resource’

in in in in in

object object object object object

‘Ambulance’ expands to: Create Vehicle ‘Car’ expands to: Create Vehicle ‘First Aid Worker’ expands to: Create Worker ‘Super Observer’ expands to: Create Worker ‘Truck’ expands to: Create Vehicle

Here the compiler is interpreting this generic event appropriately for the context9 . Most of the weaving that takes place in a protocol model is defined in terms of the event types of the domain. In this case, the weaving is completely symmetric and there is no formal way of distinguishing the “base behavior” and the “advice”. However, as these examples show, the use of generic events provide for a degree of quantification, whereby a single join point in the model, specified as the label on a transition, can match multiple labels in other machines and/or can match a different label depending on context. When generic events are used, there is asymmetry between the machines that are woven and we can identify the machine that uses the generic as representing the “advice”. In the CMS case study there are 4 uses of generic events. 7.3

Symmetric Approach

One view of aspect-oriented software development is that every major feature of the system: core concern (business logic), or cross-cutting concern (additional features), is an aspect, and by weaving them together (a process also called composition), you finally produce a whole out of the separate aspects. This approach is known as the symmetric (or pure) aspect approach. However, asymmetric (or hybrid) approaches, where a base model is built using one technique and aspects are applied to it using a specialist aspect language, are more commonly used perhaps since then there is less of a paradigm shift between object and aspect orientation10 . Within this classification, Protocol Modeling is clearly a symmetric aspectoriented approach, as there is no difference in syntax and semantics between a protocol machine that models an aspect and any other protocol machine in the model. 7.4

Derived States as Join Points Refinements

It is worth mentioning that using derived states can help provide economy and clarity in the expression machine behavior and interaction under composition. 9 10

This uses a technique in Protocol Modeling called conditional repertoire entries, which is described fully in [7]. This is a form of polymorphism. See the Wikipedia entry on “Aspect” at: http://en.wikipedia.org/wiki/Aspect (computer science)

Aspect-Oriented Development Using Protocol Modeling

137

package AOMCase; import com.metamaxim.modelscope.callbacks.*; public class LoggedInCheck extends Behaviour { public String getState() { //Determines whether the Employee is logged in or not return (this.getInstance("Internal Resource").getState("Employee Log In").equals("logged in")) ? "logged in" : "not logged in"; } }

Fig. 8. State Derivation in Logged In Check

For instance, the state derivation function of the machine Logged In Check shown in Figure 8 abstracts over the states of the machine Employee Log In (the refined version shown in Figure 3). Thus, the state not logged in of Logged In Check represents any of the states {logged out, trying, violation} of Employee Log In. This machine can then be used to make a more succinct definition of the constraints that being logged in versus not logged in has on the behavior of the system as it only expresses these two states. 7.5

Mixins as Aspects

When modeling a system, the structure of the model will be dominated by the model architect’s view of the key elements of the model and their relationships and connections. The more a core modeling language imposes and constrains the structure of a model, the less likely that all the elements of a problem and their relationships can be accommodated, as the structure chosen for some elements necessarily means that others cross-cut. This is sometimes referred to, for instance by Ossher and Tarr, as the “Tyranny of the Dominant Decomposition”[17]. This problem is immediately manifested with single inheritance structures, where the single hierarchy of the class structure is the tyrant, and the modeler has to resort to using a asymmetric approach, with a specialist aspect language being used to model those elements which clash with the main structure of the model. This is, in general, not the case with a mixin-based inheritance approach supporting multiple inheritance. As Filman and Friedman observe: “In using inheritance to achieve aspects, single superclass inheritance systems require all aspects to match the class structure of the original program, while multiple inheritance systems allow quantification independent of the programs dominant decomposition. Mixins with multiple inheritance are thus a full aspect-oriented programming technology”[25]. A similar observation is made by Apel et al. [28]. The use of mixin-based inheritance in Protocol Modeling qualifies it as aspectoriented. This is true, in particular, because the means by which mixins are combined is CSP composition, and this entails weaving of trace behavior. However, the aspects are pervasive in the model rather than being invoked as an exceptional technique to handle cross-cutting concerns. To avoid structural tyranny it is necessary to minimize the structure constraints imposed by the inheritance scheme on a model, and the partial ordering

138

A. McNeile and E. Roubtsova

of Protocol Modeling (see Section 3.2) is the minimum structuring possible. As applied to the CMS case study, examination of the structures in Figures 5 and 6 shows that multiple inheritance, measured formally as the definition of machine type that INCLUDES more than one other machine type, is used 7 times.

8

Protocol Modeling in Practice

This section describes various practical considerations in the use of Protocol Modeling, both positive and negative. 8.1

Barriers to Protocol Modeling

The difficulties with application of Protocol Modeling fall into two categories: one associated with the Protocol Modeling paradigm (1) and the other with the nature of the problem which is to be addressed (2). 1. Paradigm Related. The Protocol Modeling paradigm is not well aligned to the prevalent paradigm of current mainstream modeling languages (UML) and programming languages (Java, C#, C++): – The use of pure mixin-based approach, contrasting with the prevalent focus on inheritance. – The use of process algebraic composition (CSP). – The idea that the state of a state-transition machine may be calculated, rather than simply driven by transitions. – The idea of using modal semantics to model workflow. These entail different ways of thinking so becoming fluent in the technique requires time and effort, analogous to that required to convert from imperative programming to OO programming. Moreover, the conceptual distance between Protocol Modeling and current programming languages means that mapping a protocol model to an implementation is not trivial. For instance, if the target programming language does not support multiple inheritance, other means (which could include Aspect Oriented Programming techniques) may be required to implement a model. 2. Problem Related. The second consideration is the nature of the problem being addressed. Protocol Modeling has its own domain of applicability, which can be roughly characterized as discrete event-based systems which are based on what Jackson, in his work on “Problem Frames” [22], refers to as an analogic model. Examples of systems that do not conform to this characterization are: a word processing system, a compiler and a chess game; and attempts to apply Protocol Modeling to such problems will be problematic and unlikely to give a useful solution.

Aspect-Oriented Development Using Protocol Modeling

8.2

139

Model Execution and Testability

Protocol models can be directly executed (tested) after any step of model evolution, and this is supported by the ModelScope [6] tool, providing run-time machine composition and a generic (metadata driven) user interface. The input of the tool is the textual presentation of a protocol model described in Section 3, and Figure 9 shows the user interface as it appears when executing the CMS case study. The tests are recorded in a test-file. The value of providing stakeholders with working (executable) artifacts early in the development process is well recognized. By presenting a working representation of the intended system, model execution offers the potential to make early modeling accessible to stakeholders even those who are not familiar with technical modeling notations, and thus widens the circle of participants in review activities. Such widening of the review activities can help to expose and eliminate misunderstandings between the development and user communities early in the development lifecycle, when mistakes are still relatively cheap to correct, and thus reduce risk and improve quality. The use of ModelScope in this context is discussed fully in [4].

Fig. 9. ModelScope Generic User Interface

The tests are used to validate the model against use cases. Tests can also validate other properties formulated by the developer. For example, “A Crisis case can be closed only if all its missions have been accomplished”. Testing can help to find counter examples to the properties formulated by the developer and this usually means that the model needs a correction. 8.3

Model Evolution

In practice, it is not possible to collect all the requirements for a model at once, so models evolve. Evolution of a protocol model normally entails adding or deleting protocol machines. As all protocol machines are equally composed, the changes are local.

140

A. McNeile and E. Roubtsova

Typically, a behavior model is built in phases, each phase scoped by a Use Case or part of a Use Case. The compositional nature of Protocol Modeling makes this kind of incremental approach attractive and natural. In the CMS case study, initial phases of modeling might be as follows: – Phase 1: Events and machines for Crisis Type, Crisis, Mission Type and Mission. Events and machines for Person, Worker, CMS Employee, Coordinator, and Mobile Employee. Development of support for steps 1 - 2 of Use Case 1. – Phase 2: Events and machines for Needed Mission, Mission Recommendation and development of support for steps 3 - 5 of Use Case 1. – Phase 3: Events and machines for Internal Resource and Assignment Request. Development of support for steps 1 - 2 of Use Case 3. – Phase 4: Events and machines for Witness, Victim, Phone Company, Surveillance, Report Verification and Video Verification. Development of support for the steps 1 - 2 of Use Case 2. In general, each increment will go through the stages of development described in Section 4. After each increment the model is tested and, at key stages, validated with users for correct interpretation of requirements. The validation process allows users and other stakeholders to play scenarios through the model. 8.4

Scalability

Scalability concerns the ability of a technique to be applied to large, complex problems without exhibiting non-linear growth in complexity [1]. In a compositional modeling approach such as Protocol Modeling, scalability can be discussed in terms of the following questions: 1. How does the size of the state space of the solution grow as more complex problems are modeled? In particular, can the approach prevent the phenomenon of “state space explosion” resulting from combinatorial effects? 2. Is the author of the model able to maintain intellectual control over a model as its size grows? We discuss these in turn. 1. State Space. The ability of state transition approaches to scale to complex behavior requires avoidance of the “state-space explosion”, whereby the number of states that have to be used to describe a problem increases geometrically rather than linearly with the size of the problem. Protocol Modeling is not vulnerable to this phenomenon, as the new states of an object needed to describe new behavior are added in new machines. This is in contrast with some other state-transition approaches, such as that suggested by Mellor and Balcer [32], which do not support composition so that all important state combinations of an object must be represented as a single machine. The size of state space of individual protocol machines is dictated by the preferences of designers. Usually, the machines of a model follow the psychological restriction that a person cannot control and reason at one moment more than nine elements. This can be seen in the model in Figures 5 and 6 whose individual machines do not use more than five states.

Aspect-Oriented Development Using Protocol Modeling

141

2. Intellectual Control. In Protocol Modeling, the key to maintaining intellectual control over a model as it grows is the ability to do “local reasoning”: to reason reliably about the behavior of the whole from examination of a part in isolation. If the use of aspect technologies results in specifications becoming distributed through multiple design artifacts (the base behavior or code definitions and separate aspects that have been added to them) in such a way that no reliable deductions about the behavior of the whole can be made from examination of a part, then there is little chance of maintaining intellectual control over a complex model. Local reasoning in Protocol Modeling is based on the following property of CSP composition: If we take a sequence, S, of events that is accepted by the composition (M1  M2 ) of the two machines M1 and M2 , then the subsequence, S  , of S obtained by removing all events in S that are not in the alphabet of M1 would be accepted by the machine M1 by itself. This property is sometimes known as observational consistency [18] between a composite and its component machines. The fact that CSP composition gives observational consistency was established by Hoare [10]; however, Hoare’s formulation was based on the composition of algebraic processes and did not consider machines that access the local storage of other machines (in particular, to derive their state) and a proof extended to cover composed protocol machines is given in [3]. These ideas are very closely related to the categorization of aspects suggested by Katz [31]: – Spectative aspects can change the values of variables local to the aspect, but do not change either the value of any variable or the flow of method calls of the underlying system. – Regulative aspects can affect the flow of control of the underlying system by restricting operations, delaying some operations, or preventing the continuation of a computation. – Invasive aspects can change the values of variables and therefore the behavior in the underlying system. Katz was also concerned with the issue of how to reason about software behavior in the presence of aspects, and argues that Invasive aspects make reasoning hard or impossible. The fact that CSP composition cannot break trace behavior means that protocol machines cannot be Invasive. Another way of stating the observational consistency property is: composing another machine with M1 cannot “break its trace behavior” by overriding a constraint that M1 says must be true. The property can be used to support local reasoning thus: if the sequence S  was not acceptable to M1 , the original sequence S could not have been acceptable to (M1  M2 ). This means that we can use properties of M1 (or M2 ) alone to argue about the behavior of M1  M2 . This is key to retaining intellectual control. When creating a model, the author needs to ensure that the protocol constraints in each machine of the model are true by examining each machine separately, as composition preserves the constraints specified by each machine. This allows intellectual control to be maintained over a model even if it comprises a large number of fine grained machines.

142

8.5

A. McNeile and E. Roubtsova

Correctness

By correctness we mean the use of formal proof techniques to establish behavioral properties in a model. These are properties such as liveness or absence of deadlock and are normally addressed using model proving techniques. This is a large topic, and we only give a summary here. Our view is that the approach needed to establish behavioral correctness depends on the nature of the system. The key determinant is whether the system is: 1. Deterministic in which case local reasoning about models combined with model execution (testing) is generally sufficient for ensuring correctness. This is because with a deterministic system you can repeat tests. 2. Non-deterministic in which case you must use global reasoning (model checking) to ensure correctness. This is because the execution path of the system cannot be determined in advance or controlled during execution, and consequently repeatability of behavior cannot be assured. This makes systematic testing hard or impossible. Within the realm of Protocol Modeling, models fall into two classes corresponding to the above: – Protocol models that only use the deterministic parallel composition of CSP11 . – Protocol models that use composition operators that introduce non-determinism, such as the composition operator of Robin Milner’s CCS (or the π-calculus) [26]. We discuss these in turn. 1. Deterministic Models. The CMS case study (at least as we have modeled it for this paper) falls into the first class of deterministic models. Here, the ability to apply local reasoning to the model and use a tool such as ModelScope is generally enough to establish correctness. Both techniques are essentially needed. The CSP parallel composition and its property of local reasoning guarantees that traces of parts will not be reordered by the the composition. Model execution provides an extra check that the composition of Protocol Machines produces desired behavior and does not unnecessary behavioral constraints. CSP composition always works, in that it never produces a composite that fails in execution (generates a run-time error). However, it is possible to create machines that interlock with each other. Consider the two machines: P = x.y and Q = y.x where “.” indicates sequencing of events. In this case P  Q will refuse both x and y and so will not be able to engage in any event. This will not generate a run time error: it just will not do anything. 11

As Hoare himself notes: “. . . the concurrent operator by itself does not introduce non-determinism.” [11].

Aspect-Oriented Development Using Protocol Modeling

143

It might be possible to devise a static analyzer that could detect such situations. However, as there are often cases in a model where refusal of the events is the intention (e.g., as Logged In Check purposefully refuses Restricted Events when the Employee is not authenticated by the system) such an analyzer could only detect candidate problems: for instance, using model checking to find states of the system in which composition causes all exit transitions to be refused. We have not found this to be necessary as, in practice, model testing is sufficient to detect such mistakes in the model by exercising the required Use Cases. 2. Non-Deterministic Models. When modeling software that is required to be distributed across multiple (real or virtual) unsynchronized processors it is necessary to use composition operators that result in non-deterministic behavior and then correctness must, in general, be established using model proving techniques. Model proving generally requires that the multiple machines of a protocol model be combined into a single machine for the purpose of global analysis of the possible execution paths: for instance to establish that no path ends in a state from which there no exit transition (a deadlock). This is usually done with the help of specialist model-proving tools. This application of model proving to Protocol Modeling is a subject of current research and beyond the scope of this paper, but the following general statements can be made: – Protocol models that comprise a fixed population of machines lend themselves well to traditional model proving techniques. The general approach is to form a state space of the model as whole as the Cartesian product of the state spaces of the constituent machines of model, and then draw the valid transitions between the states of this global state space according to the rules of the composition operators (normally both CSP and CCS) used in the model. The resultant overall machine can then be analyzed for the presence (or absence) of topological properties corresponding to desired (or pathological) behavioral properties. The proving is a mechanical process that can be carried out by a software tool. – As described in Section 7, derived states can be used to abstract over the data and states of a model and hence maximize the economy of the state space required. This reduces the chance that model proving becomes untractable because of the size of the global state space that needs to be constructed and explored. – Because, as noted in Section 2.4, derived state machines are not “topological” extra steps are sometimes needed in the model proving process to convert these machines into a form that allows them to be included in the analysis. These techniques have useful application. For instance, the combination of model proving and the ideas described in Section 2.5 for representing modality makes it possible to conduct formal progress analysis on distributed (multi-party) collaborative workflows whereby it is possible to establish analytically that a collaboration will always reach a successful conclusion. Another example of formal

144

A. McNeile and E. Roubtsova

proving techniques using protocol models is the work by McNeile on choreography realizability [2].

9

Related Work and Conclusion

In this section we make an overview of some related aspect-based modeling approaches and draw some conclusions. 9.1

Related Work

We have chosen the workflow-based Theme approach, the RAM approach using multiple behavioral views and approaches that use Statecharts for capturing of aspects, to show that composition semantics may enrich those approaches and make them more flexible. Theme. The Theme [29,13] approach is used both at requirements and the design level. At the requirements level Theme/Doc exposes the relationship between behaviors (features) in the model. The Design level Theme/UML supports modeling features and aspects in UML. Theme/Doc views are mapped onto the Theme/UML model allowing traceability of requirements. At the requirements level a designer identifies actions as verbs in textual requirements. Each action potentially becomes a theme. The actions have relations via concepts. Actions found in different themes become potential aspects. An action view of each theme is a graph that contains actions and entities. The size of this view grows with the number of entities and actions in the model. The scalability is achieved by the separation major and minor actions. “Major actions become themes, while minor actions are slotted to become methods within a theme” [13]. The action view “drives composition semantics for design in Theme/UML” [13]. The action view is analyzed to produce the Theme/UML specification of actionsaspects as a combination of a class and sequence diagrams. So, actions in the Theme approach are not elementary, they are activities. If a Theme/action is reused in the model, the pointcuts are specified in the Theme/UML view. The evolution of the model is handled by re-generating the views for the new set of requirements. This we see as a shortcoming of this approach. Reusable Aspect Models (RAM). In the Reusable Aspect Models (RAM) [19] approach a model of a concern or functionality “contains up to three different kinds of views: a structural view, state views and message views, which are grouped together in an aspect model, a special UML package” [19]. The structural view is expressed using a UML class diagram where the specified public methods of classes are annotated with “+”. The structural view of a concern may present only classes and associations relevant to the concern. The structural view may contain “incomplete classes, i.e. entities that are not directly or indirectly bound to model elements of some other aspect models, and methods whose name and signature are yet to be determined”. These incomplete

Aspect-Oriented Development Using Protocol Modeling

145

classes are called “mandatory instantiation parameters” and they are recognized by | character attached to their name and as UML template parameters on the right hand side of the structural view compartment [19]. The classes may later be composed by the weaver with other classes when the aspect is instantiated or bound to a base model. The class diagrams are composed using the algorithm proposed in France et al. [27]. The composed elements at an aspect model and a target model must be instances of the same metamodel class and have matched signature, i.e two elements with the same signature represent the same concept and composed. For each class (complete or incomplete) defined in the structural view one state view is defined. “Using a UML state diagram, the state view of an entity describes the internal states of that entity that are relevant within the concern. A state is relevant if it affects the messages that the entity is capable of processing. In UML terms, the state view compartment describes the usage protocol of the entity. To be complete, the state diagram must contain each method defined in the structural view for the entity at least once [19]”. For incomplete classes, an aspect state diagram consists of two parts: a pointcut and an advice. “The pointcut defines the states and transitions that have to exist in the target state diagram, i.e. the state diagram with which the aspect state diagram is composed.” The advice defines the state diagram that replaces the occurrence of the pointcut in the target state diagram. “States that are not directly or indirectly bound to states defined in a standard state diagram are mandatory instantiation parameters of the state view [19]”. So far, weaving of state views is not supported. For each public method defined in the structural view, there is at most one message view. “Each message view describes, using a UML sequence diagram, the sequencing of message interchanges that occur between entities when providing the functionality offered by the public method. Hence, if the functionality does not involve any message exchanges, but only computation internal to the entity, no message view compartment is shown for that method.” A message view has two parts: a pointcut and an advice. The message views are woven on the basis of the algorithm known as Generic weaving with Kermeta [9,36]. The result of weaving of sequence diagrams is a sequence diagram. The RAM approach generates aspect dependencies. The dependencies are declared in the aspect heading. “If A depends on B, A explicitly states that it reuses the functionality provided by B by instantiating B. If an aspect A depends on an aspect B, i.e. an incomplete class X (or | X) in the structural view of an aspect A needs to be composed with a complete class Y defined in B, the state view X in A might also need to refine the state view Y. In this case, A has to define a binding directive that maps the incomplete entities of As structural view, state view or message view into the structural view, state view or message view of the aspect defining Y. Instantiations and binding directives can be one-to-many or many-to-one, if needed” [19]. Aspect dependencies are

146

A. McNeile and E. Roubtsova

kept unresolved until the aspects are woven with the final application model. An aspect A can have complex dependencies in the form of a directed acyclic graph. The weaving algorithm resolving aspect dependencies is recursive. It processes the directed acyclic graph of dependencies step by step in depth-first order. All aspects should be woven with a base application model. Before weaving each aspect model goes through consistency checks, then the adherence of aspect models to the instantiation and binding rules is checked. The third of consistency checks is performed within the independent aspect model and within the final base model.“For each object life line in the sequence diagram, the incoming messages to that object are presented in sequence to the state diagram describing the protocol of the corresponding class. If the state diagram refuses a message, consistency is violated” [19]. We should notice that the refuse semantics used for consistency checkers is different from the semantics of refuse in Protocol Modeling. In Protocol Modeling “refuse” is not a violation, it is a normal situation when a protocol machine being in its current state cannot accept an event. RAM models are not executable. The authors plan to extend the approach “by adding yet another kind of view that describes the detailed execution paths for individual methods. Detailed method algorithms could be expressed, for instance, with UML activity diagrams or SDL. With this additional view, RAM would be capable of generating final application models that are fully executable [19].” Approaches using Statecharts. There are several approaches using statecharts for capturing aspects. Mahoney et al. [23] use the semantics defined by D. Harel [12]: “When event a occurs in state A, if condition C is true at the time, the system transfers to state B ”. Moreover, the authors exploit the AND-composition of several independent (orthogonal) statecharts and “the key feature of orthogonal statecharts is that events from every composed statechart are broadcast to all others. Therefore, an event can cause transitions in two or more orthogonal statecharts simultaneously” [23]. We should notice that this semantics does not define what happens if one of orthogonal statecharts is in a such a state where it cannot accept the broadcast event. This incomplete semantics does not allow use of CSP or CCS composition for orthogonal statecharts. The most that can be said is that the result of the composition of orthogonal statecharts is a computation tree that represents partial behavior of the system when the orthogonal statecharts are in suitable states to accept broadcasted events. The UML Specification [24] includes two behavioral semantics for finite state transition systems: Behavioral State Machines (BSM) and Protocol State Machines (PSM) and several approaches [16,34] use these as a basis for defining aspect semantics. High-Level Aspects (HiLA) [16] uses UML State Machines with declarative specification of concerns such as synchronization of orthogonal regions or historybased behaviors. The authors use Behavioral State Machines (BSM) semantics. The semantic model used for Behavior State Machine Execution in UML2

Aspect-Oriented Development Using Protocol Modeling

147

(which was first included in UML at version 1.5) is based on the “Recursive Design” method of Shlaer and Mellor [33] whose work has been mainly in the real-time/embedded systems domain. The approach is based on using state machines to model so-called “active objects”: objects whose instances execute autonomously and asynchronously (i.e., as if executing on independent threads) resulting in system behavior that is inherently non-deterministic [35]. The authors of paper [16] notice that “UML state machines work fine as long as the only form of communication among states is the activation of the subsequent state via a transition. More often than not, however, an active state has to know how often some other state has already been active and/or if other states (in other regions) are also active. Unfortunately, behavior that depends on such information cannot be modeled modularly in UML state machines.” We agree with this observation, which our use of derived states avoids. The asynchronous and non-deterministic composition semantics of BSMs make reasoning about behavior difficult. Complete analysis of the behavior of the model must allow, in general, for arbitrary queuing of events between objects and for the accumulation of deferred events. If a model comprises a number of communicating objects this results in a large number of possible execution states for the system as a whole, and reasoning on models is impossible without model checking algorithms. This does not make sense when models are being developed, as they are in most projects, in an iterative manner and subject to frequent change; and it is hard to reconcile this semantic basis with the characteristics of the business information systems domain, where behavioral issues are related to transactional integrity and business rules, and strictly deterministic behavior of business logic is important to ensure repeatability, auditability and testability12 . While there is some native support in Shlaer/Mellor for behavior abstraction through the use of “polymorphic events”, this has been included neither in the UML BSM standard nor is there any method to compose multiple machines to form the behavior of a single classifier. This places severe limits on the ability of BSMs to describe generalization/specialization of behaviors or to support behavior re-use. As described in [32], a single object class is modeled with a single state machine, and only concrete classes are modeled. This also means that crosscutting behaviors (aspects) have to be addressed by other means, potentially further complicating model analysis. As noted above, UML also supports Protocol State Machines (PSM). These are not related to Shlaer/Mellor and have semantics that define the legal lifecycles of a classifier (an object, interface, or port) in terms of the allowable order of invocation of its operations. PSMs can (to a limited extent) be composed. “A classifier may have several protocol state machines. This happens frequently, for example, when a class 12

We note that the commercial tools that support this approach (such as those from Telelogic, Kennedy Carter and Mentor Graphics) are not well adapted for use in the business information systems domain and are positioned by their vendors to target the real time/embedded market.

148

A. McNeile and E. Roubtsova

inherits several parent classes having a protocol state machine, when the protocols are orthogonal” [24]. In this context, “orthogonal” means that they have a disjoint alphabets. The occurrence of an event that a PSM cannot handle is viewed as a precondition violation and the consequent behavior of the PSM is left open: “The interpretation of the reception of an event in an unexpected situation (current state, state invariant, and pre-condition) is a semantic variation point : the event can be ignored, rejected, or deferred, an exception can be raised, or the application can stop on an error. It corresponds semantically to a pre-condition violation, for which no predefined behavior is defined in UML” [24]. Only if such a situation was interpreted as a refusal could CSP style composition be supported, but this does not seem to be intention of the specification. PSM semantics are simpler and more abstract than the BSM semantics, and this makes them more widely usable and easier to analyze. However, as evidenced by the language used to describe them, PSMs are clearly positioned in UML as contracts of legal usage; and this gives it a different meaning and role from that of BSMs. While a contract must specify what is legal, it is neither concerned with the mechanism by which non-legal behavior is avoided, nor is it required to specify the effect of violation. In other words, a contract cannot be used as the instrument that guarantees its own satisfaction. It would therefore be a logical error to execute PSMs directly or to generate code from them, and this seems to make use as a means of specifying behavioral aspects problematic. 9.2

Conclusion

In this paper we have shown an approach to aspect modeling using Protocol Modeling, a mixin-based behavioral modeling technique. Protocol Modeling embodies semantics needed to capture and compose behavioral aspects, including events represented as data, machines with state and local storage, state derivation and formal parallel composition techniques. This enables behavioral aspects and behavior inheritance to be handled by a common mechanism and thus provides a unified view of these different abstraction techniques.

References 1. Bondi, A.: Characteristics of Scalability and their impact on Performance. In: Proceedings of the 2nd international workshop on Software and performance, Ottawa, Ontario, Canada, pp. 195–203 (2000) 2. McNeile, A.: Protocol Contracts with application to Choreographed Multiparty Collaborations. In: Service Oriented Computing and Applications (in Publication, 2010) 3. McNeile, A., Roubtsova, E.: CSP parallel composition of aspect models. In: AOM 2008: Proceedings of the 2008 AOSD Workshop on Aspect-Oriented Modeling, pp. 13–18. ACM DL (2008) 4. McNeile, A., Roubtsova, E.: Executable Protocol Models as a Requirements Engineering Tool. In: Proceedings of the 41st Annual Simulation Symposium (anss-41 2008), Washington, DC, USA, pp. 95–102. IEEE Computer Society, Los Alamitos (2008)

Aspect-Oriented Development Using Protocol Modeling

149

5. McNeile, A., Roubtsova, E.: Composition Semantics for Executable and Evolvable Behavioural Modeling in MDA. In: BM-MDA 2009: Proceedings of the 1st Workshop on Behaviour Modelling in Model-Driven Architecture, pp. 1–8. ACM DL (2009) 6. McNeile, A., Simons, N.: http://www.metamaxim.com/ 7. McNeile, A., Simons, N.: Protocol Modelling. A Modelling Approach that Supports Reusable Behavioural Abstractions. Software and System Modeling 5(1), 91–107 (2006) 8. McNeile, A., Simons, N.: A Typing Scheme for Behavioural Models. Journal of Object Technology 6(10), 81–94 (2007) 9. Morin, B., Klein, J., Barais, O., J´ez´equel, F.-M.: A Generic Weaver for Supporting Product Lines. In: EA 2008: Proceedings of the 13th international Workshop on Early Aspects, pp. 11–18. ACM, New York (2008) 10. Hoare, C.: Communicating Sequential Processes. Prentice-Hall International, Englewood Cliffs (1985) 11. Hoare, C.: Why ever CSP? Electronic Notes in Theoretical Computer Science 162, 209–215 (2006) 12. Harel, D., Gery, E.: Executable Object Modelling with Statecharts. IEEE Computer 30(7), 31–42 (1997) 13. Baniassad, E., Clarke, S.: Theme: An Approach for Aspect-Oriented Analysis and Design. In: ICSE 2004. Proceedings. 26th International Conference on Software Engineering, pp. 158–167. IEEE, Los Alamitos (2004) 14. Roubtsova, E., McNeile, A.: Abstractions, Composition and Reasoning. In: AOM 2009: Proceedings of the 13th workshop on Aspect-Oriented Modeling, Charlottesville, Virginia, USA. ACM DL (2009) 15. Bracha, G., Cook, W.: Mixin-based inheritance. In: Proc. of the ASM conference on Object-Oriented Programming, Systems, Languages, Applications, OOPSLA/ECOOP 1990, ACM SIGPLAN Notices, vol. 25(10), pp. 179–183 (1990) 16. Zhang, G., H¨ olzl, M., Knapp, A.: Enhancing UML State Machines with Aspects. In: Engels, G., Opdyke, B., Schmidt, D.C., Weil, F. (eds.) MODELS 2007. LNCS, vol. 4735, pp. 529–543. Springer, Heidelberg (2007) 17. Ossher, H., Tarr, P.: Multidimentional Separation of Concerns and the Hyperspace Approach. In: Proc. Architectures and Component Technology: The State-of-the Art in Software Development (January 2000) 18. Ebert, J., Engels, G.: Observable or invocable behaviour - You have to choose. Technical report. Universit¨ at Koblenz, Koblenz, Germany (1994) 19. Kienzle, J., Al Abed, W., Klein, J.: Aspect-oriented Multi-view Modeling. In: Proceedings of the International Conference on Aspect-Oriented Software Development, AOSD 2009, Charlottesville, Virginia, USA, pp. 87–98. ACM DL (2009) 20. Kienzle, J., Guelfi, N., Mustafiz, S.: Crisis Management Systems: A Case Study for Aspect-Oriented Modeling. In: Katz, S., Mezini, M., Kienzle, J. (eds.) Transactions on AOSD VII, LNCS, vol. 6210, pp. 1–22. Springer, Heidelberg (2010) 21. Jackson, M.: System Development. Prentice Hall, Englewood Cliffs (1983) 22. Jackson, M.: Problem Frames: Analyzing and Structuring Software Development Problems. Addison-Wesley Longman Publishing Co., Inc., Boston (2001) 23. Mahoney, M., Bader, A., Elrad, T., Aldawud, O.: Using Aspects to Abstract and Modularize Statecharts. In: The 5th Aspect-Oriented Modeling Workshop In Conjunction with UML 2004 (2004) 24. OMG. Unified Modeling Language, Superstructure, v2.2. OMG Document formal/09-02-02 (2009)

150

A. McNeile and E. Roubtsova

25. Filman, R., Friedman, D.: Aspect-Oriented Programming is Quantification and Obliviousness. In: Tarr, P., Bergmans, L., Griss, M., Ossher, H. (eds.) Proceedings of Workshop on Advanced Separation of Concerns, OOPSLA 2000. Department of Computer Science. University of Twente, The Netherlands (2000) 26. Milner, R.: A Calculus of Communicating Systems, LNCS, vol. 92. Springer, Heidelberg (1980) 27. Reddy, R., Ghosh, S., France, R., Straw, B.: Directives for composing aspectoriented design class models. In: Rashid, A., Aksit, M. (eds.) Transactions on Aspect-Oriented Software Development I. LNCS, vol. 3880, pp. 75–105. Springer, Heidelberg (2006) 28. Apel, S., Leich, T., Saake, G.: Mixin-Based Aspect Inheritance. Technical Report No. 10/2005, University of Magdeburg, Germany (2005) 29. Clarke, S., Baniassad, E.: Aspect-Oriented Analysis and Design: The Theme Approach. Addison Wesley, Reading (2005) 30. Cook, S., Daniels, J.: Designing Object Systems. Object-Oriented Modelling with Syntropy. Prentice Hall, Englewood Cliffs (1994) 31. Katz, S.: Aspect Categories and Classes of Temporal Properties. In: Rashid, A., Aksit, M. (eds.) Transactions on Aspect-Oriented Software Development I. LNCS, vol. 3880, pp. 106–134. Springer, Heidelberg (2006) 32. Mellor, S., Balcer, M.: Executable UML: A Foundation for Model Driven Architecture. Addison Wesely, London (2002) 33. Shlaer, S., Mellor, S.: Object Life Cycles - Modeling the World in States. Yourdon Press/Prentice Hall (1992) 34. Elrad, T., Algawud, O., Baber, A.: Aspect-oriented modelling-Briging the gap Between Design and Implementation. In: Proceedings of the First ACM International Conference on Generative PRogramming and Component Engineering GPCE), Pittsburg, pp. 1189–1202 (2002) 35. Santen, T., Seifert, D.: Executing UML State Machines. Technical Report 2006-04, Fakult¨ at f¨ ur Elektrotechnik und Informatik, Technische Universit¨ at Berlin (2006) 36. Drey, Z., Faucher, C., Fleurey, F., Mah´e, V., Vojtisek, D.: Kermeta language (2009), http://kermeta.org/documents/manual/htm_chunked

Using VCL as an Aspect-Oriented Approach to Requirements Modelling Nuno Am´ alio, Pierre Kelsen, Qin Ma, and Christian Glodt University of Luxembourg, 6, r. Coudenhove-Kalergi, L-1359 Luxembourg {nuno.amalio,pierre.kelsen,qin.ma,christian.glodt}@uni.lu Abstract. Software systems are becoming larger and more complex. By tackling the modularisation of crosscutting concerns, aspect orientation draws attention to modularity as a means to address the problems of scalability, complexity and evolution in software systems development. Aspect-oriented modelling (AOM) applies aspect-orientation to the construction of models. Most existing AOM approaches are designed without a formal semantics, and use multi-view partial descriptions of behaviour. This paper presents an AOM approach based on the Visual Contract Language (VCL): a visual language for abstract and precise modelling, designed with a formal semantics, and comprising a novel approach to visual behavioural modelling based on design by contract where behavioural descriptions are total. By applying VCL to a large case study of a car-crash crisis management system, the paper demonstrates how modularity of VCL’s constructs, at different levels of granularity, help to tackle complexity. In particular, it shows how VCL’s package construct and its associated composition mechanisms are key in supporting separation of concerns, coarse-grained problem decomposition and aspect-orientation. The case study’s modelling solution has a clear and well-defined modular structure; the backbone of this structure is a collection of packages encapsulating local solutions to concerns. Keywords: modularity, separation of concerns, aspect-oriented modelling, design by contract, VCL.

1

Introduction

Software systems are becoming larger, more complex and part of our everyday lives. They need to evolve in order to keep up with their complex and dynamic environments. To help reduce complexity, improve reusability, and simplify evolution, software engineering emphasises the principle of separation of concerns [1]. By tackling the modularisation of crosscutting concerns, aspect-orientation enhances traditional approaches to modularity, providing techniques to achieve designs with a good level of separation of concerns that effectively separate and isolate non-orthogonal (or crosscutting) concerns. This enables concerns to be understood and analysed in isolation, and then composed in a modular fashion. Aspect-oriented modelling (AOM) raises the level of abstraction of aspectoriented software development by applying aspect-orientation to the construction of models of software systems. S. Katz et al. (Eds.): Transactions on AOSD VII, LNCS 6210, pp. 151–199, 2010. c Springer-Verlag Berlin Heidelberg 2010 

152

N. Am´ alio et al.

Visual languages like UML are limited at separating concerns, not supporting concerns that are crosscutting [2]. There has been substantial work on AOM (section 11). Most existing AOM approaches: (a) extend UML to enable aspectorientation, (b) are designed to enable code generation, (c) are based on multiple partial view descriptions of behaviour (using scenarios and state diagrams) or total descriptions based on OCL, (d) are not designed with a formal semantics (precluding, this way, formal verification), (e) are asymmetric, treating aspects differently from other modules, and (f) involve complex weaving algorithms to compose models. This paper presents an AOM approach based on the Visual Contract Language (VCL) [3,4,5]. VCL is a visual language for abstract and precise modelling at the level of system requirements or high-level system designs. It embodies a novel approach to visual behavioural modelling based on design by contract [6] where its behavioural descriptions are total. VCL expresses operations and invariants visually; UML needs to resort to textual OCL to do this. Unlike UML and other mainstream languages, VCL is designed to have formal semantic foundations to enable formal semantic analysis. Its semantic is expressed in Z [7], using the ZOO semantic domain of object-orientation [8,9], which has been applied to UML-based models in [10,11,9]. VCL is accompanied by a tool, the Visual Contract Builder1 , which is being developed as part of the VCL effort. VCL is novel in its modular approach to modelling based on different levels of granularity. At a more finer-grained level, VCL’s contracts and constraints are modules that can be combined using logical operators. It is, however, through its coarse-grained construct of packages that VCL realises AOM. VCL packages are reusable functional units encapsulating structure and behaviour that can be used or extended by other packages. They enable the definition of modules that localise solutions to concerns. VCL is symmetric in the way it treats classical modules and aspects, not making a distinction between them. VCL packages constitute modules that can be described, understood and analysed in isolation and then used as a piece in multiple contexts to make larger packages addressing multiple concerns. In VCL, package compositions have a declarative nature, not involving complex weaving algorithms. This paper shows how VCL tackles the complexity of large-scale systems with a large case study, the car-crash crisis management system (CCCMS) [12]. It illustrates VCL’s package construct and associated composition mechanisms, showing how they support separation of concerns, coarse-grained problem decomposition and aspect-orientation. The resulting VCL model has a clear and well-defined modular structure; the backbone of this structure is a collection of packages encapsulating local solutions to concerns. This paper is organised as follows. Section 2 explains the process that we followed to model the CCCMS using the VCL-based AOM approach presented here. Section 3 presents the high-level requirements model of the CCCMS. Section 4 overviews the detailed VCL system requirements model. Sections 5 to 8 build parts of the overall VCL model. Section 9 discusses the paper’s results. 1

http://vcl.gforge.uni.lu

Using VCL as an Aspect-Oriented Approach to Requirements Modelling

High-Level Requirements Modelling using architecture models and use cases

153

Detailed Requirements Modelling usingVCL

Fig. 1. Process used to model the CCCMS using VCL

Section 10 evaluates our approach with respect to a number of qualitative criteria. Section 11 discusses related work. The final section presents the conclusions.

2

Process

VCL is a language that emphasises precision and is suited to describe requirements (or high-level design) models of software systems. The process used to model the CCCMS in our VCL-based AOM approach consists of two big steps (figure 1): 1. High-level requirements modelling. This identifies subsystems and their highlevel functionality. It uses notations other than VCL, such as architectural diagrams, and UML use case and sequence diagrams. 2. Detailed requirements modelling. This builds VCL models of the identified subsystems, describing their structure and behaviour. Figure 1 highlights the iterative nature of this process. It was necessary to iterate through these different levels of modelling; forwards and backwards. The high-level model is the basis of modelling in VCL; often, the detailed VCL model provides useful feedback to elaborate the high-level model. Crosscutting concerns are identified through the iterative process of figure 1, being identified in both modelling stages: – During high-level modelling, cross-cutting concerns manifest themselves by appearing repeatedly in use cases. Such concerns are then modularised as VCL packages in the detailed model. – During VCL modelling, cross-cutting concerns emerge when we observe a behavioural pattern occurring repeatedly. In this case, it is necessary to go back and update the high-level requirements model. The following describes these two levels of modelling in detail. 2.1

High-Level Requirements Modelling

The high-level requirements phase consists of the following steps: 1. Build high-level architectural models. Architectural models describe the system’s subsystems and their main units of functionality (features). This helps structuring the overall model to reflect this decomposition.

154

N. Am´ alio et al.

2. Build use case models. Main functional units (features) coming from architectural model are refined into UML use cases. 3. Derive system operations. System operations are derived by drawing UML sequence diagrams describing use case scenarios, highlighting the interaction between the environment and the system (see [13]). Derived system operations are then described in detail in VCL. 2.2

Detailed Requirements Modelling in VCL

The high-level requirements model is the basis for modelling in VCL. For each subsystem, we build a VCL model, which comprises a collection of VCL packages; one package represents the overall subsystem. The method followed to build VCL packages is as follows: 1. Build or reuse VCL packages addressing generic concerns. From the highlevel requirements model, we derive a set of generic concerns, some of which are crosscutting. These generic concerns are modularised as VCL packages; there is at least one package for each generic concern. VCL packages should be designed to be independent in order to achieve low-coupling. 2. Build VCL packages to address problem domain concerns. Problem domain concerns (crosscutting or not) are derived from the high-level requirements model. They are modularised in VCL as packages. The aim is to model relevant fragments of the problem domain in isolation, abstracting away from other concerns of the system and trying to achieve low-coupling. 3. Build composite packages. Larger packages are built incrementally from the individual packages using VCL’s composition mechanisms. They may represent the configuration of generic concerns, compositions to represent generic or problem domain concerns, and compositions linking domain and aspects packages. Ultimately, there is a VCL package for each subsystem.

3

High-Level Requirements Model of CCCMS

The process highlighted above (section 2, figure 1) was used to build the VCLbased requirements model of the CCCMS [12]. The complete model is given in [14]. The following describes the high-level requirements model of CCCMS. 3.1

Subsystems and Their Functional Features

The diagram of figure 2 describes the systems architecture of the CCCMS, highlighting a decomposition into subsystems. This reflects architectural decisions that have been taken by balancing the case study’s requirements. The CCCMS’s subsystems are as follows: – MobCCCMS is a system that runs on mobile devices to assist in real-time resources deployed to rescue missions. It addresses the mobility non-functional requirement (NFR) (see [12]). This consists of user interfaces to provide resources with sensible information for the execution of rescue missions.

Using VCL as an Aspect-Oriented Approach to Requirements Modelling

155

CCCMS MobCCCMS

CentralCCCMS

Fig. 2. Systems diagram showing subsystems of CCCMS. MobCCCMS (Mobile CCCMS) is deployed on mobile devices and used in real-time by resources sent to missions. CentralCCCMS (Central CCCMS) is used at crisis management headquarters. Subsystems exchange information through messages.

MobCCCMS

CentralCCCMS

MappingMobile LocationTracking

CrisisManagement

MissionManagement

ResourceManagement

MappingCentral

GUIMobile

GUICentral

Authentication

AccessControl

SystemsAdministration

(a) M obCCCM S

(b) CentralCCCM S

Fig. 3. Diagrams describing features of the CCCMS’s subsystems

– CentralCCCMS is the system used at the crisis management control-centre by crisis coordinators. It addresses the persistence NFR of [12]; all data related with domain functionality is held in this subsystem. The high-level functional units (features) of the CCCMS’s subsystems are identified in the block diagrams of figure 3; each block represents a feature. Table 1 describes these features indicating the requirements they address. 3.2

Use Cases and System Sequence Diagrams

Use cases were organised around the subsystems and their features. Each subsystem comprises a set of use cases. The use case model of [12] was re-factored to take subsystems and their features into account, to clarify some omissions and ambiguities that we found in the requirements, and to enable a clear derivation of system operations from the use cases. Figure 4 presents sample use case diagrams belonging to the use case model of CCCMS [14] for the features MappingMobile and CrisisManagement. In [14], the scenarios of each use case are described using UML sequence diagrams to derive system operations. Figure 5 presents sample system sequence diagrams for use cases of feature CrisisManagement. All messages going from external actors into the system, identify system operations. System sequence diagrams of figure 5 highlight crosscutting functionality; in this case the functionality related to authentication and the Login system operation.

156

N. Am´ alio et al. Table 1. Features of CCCMS’s subsystems, and their requirements

Subsystem M obCCCM S M obCCCM S M obCCCM S CentralCCCM S CentralCCCM S CentralCCCM S CentralCCCM S CentralCCCM S CentralCCCM S CentralCCCM S CentralCCCM S

Feature Mapping Mobile Location Tracking GU IM obile

Description Requirements Handling of maps on mobile de- Mobility NFR of [12]. vices. Tracking location of resources. Mobility NFR of [12].

Displays information for re- Accuracy NFR sources deployed to missions. of [12]. Crisis Manage- Management of crisis. Use cases of [12]. ment Resource Man- Management of resources. Use cases of [12]. agement Mission Man- Management of missions. Use cases of [12]. agement Mapping Handling of maps in control cen- Accuracy NFR tre. of [12]. GU ICentral Graphical user interfaces for cri- Use cases of [12]. sis coordinators. Authentication Authentication of users. Security NFR of [12]. Access Control Access-control security policies. Security NFR of [12]. Systems Ad- Tasks related to administration of Use cases of [12]. ministration users and access control policies.

Central CCCMS - Crisis Management Capture Witness Reports

Mob CCCMS - Mapping Mobile

<uses> DisplayCrisisSite

Create Crisis

Crisis Coordinator

DisplayRoute

Mapping System

(a) M appingM obile feature

Authenticate

<uses>

Crisis Coordinator

DisplayCurrentLocation

<uses>

Check Witness Reports Surveillance System

(b) CrisisM anagement feature

Fig. 4. Sample use case diagrams of CCCM S

4

Detailed VCL Model

The process described in section 2.2 is used to build detailed VCL models for subsystems MobCCCMS and CentralCCCMS, taking into account all features and their system operations identified in the high-level requirements model (section 3). Each subsystem is represented as a VCL package. A subsystem package is built by incorporating packages representing the subsystem’s concerns. Figure 6 presents VCL package diagrams for subsystems CentralCCCMS and MobCCCMS. In VCL, packages are represented as clouds to allude to the fact that they

Using VCL as an Aspect-Oriented Approach to Requirements Modelling sd Check Witness Report

sd Capture Witness Report

Video Surveillance System

Central CCCMS

Crisis Coordinator

sd Authentication(Nat maxPwMisses)

Central CCCMS

Crisis Coordinator

Authentication () : LoginResult

Authentication () : LoginResult

Central CCCMS

Crisis Coordinator

ref

ref

157

loop (maxPwMisses)

CreateWR ()

Login(UID, Passwd)

GetWRs () ViewWR ()

LoginResult

ReqVideoSurveillance () ReqVideoSurveillance ()

sd Create Crisis

break [LoginResult = success]

CancelVSReq ShowVideoSurveillance () CancelVSReq

Central CCCMS

Crisis Coordinator

CreateCrisisFromWR ()

ref

AssociateWrWithCrisis ()

Authentication () : LoginResult

IgnoreWR ()

blockUser(UID)

CreateCrisis ()

Fig. 5. Sequence diagrams describing scenarios of CrisisManagement feature. Diagrams highlight (in red) authentication crosscutting functionality.

CentralCCCMS CrisisWithAspects

ResourceWithAspects

MissionWithAspects

AuthenticationOps

MappingDisplayCentralCCCMS

SecAuthorisationMgmt

MobCCCMS LocationTrackingMobCCCMS MissionInfoDisplay CrisisInfoDisplay

MobCCMSGUI

MappingDisplayMobCCCMS

Fig. 6. Package diagrams defining packages representing CentralCCCMS (left) and MobCCCMS (right) subsystems

define a world of their own. A VCL package diagram highlights the package being defined (in bold) and the packages being extended. Package extension means incorporation; state structures and operations defined in the incorporated package become part of the composite package2 . Package diagrams of figure 6 highlight constituent individual VCL packages that are also, themselves, composite packages. All VCL packages of the overall model of CCCMS are defined in [14]. Each subsystem has its own VCL model with its set of constituent packages, some of them common to both subsystems. The next sections present fragments of the overall VCL model to illustrate the process described in section 2.2. They highlight VCL’s capabilities to support abstract modelling in an aspect-oriented way, illustrating VCL and its package 2

Semantically, incorporation means conjunction; structures of composite are those of packages it incorporates, plus those that composite defines as its own.

158

N. Am´ alio et al.

UID

maxPwMisses:Nat

uid

Name

name

pw

Password

pwMisses

UsersMgmt Users

Nat

⃝UserStatus IDOfUsersUnique MaxPwMissesInv

User

status

loggedIn blocked

loggedOut

Fig. 7. Package diagram of package UsersMgmt, which extends Users (left). Structural diagram of package Users defining User blob (right).

construct in their capability to capture generic concerns, support flexible problem decomposition, and enable a plug-and-play style of modular composition where modules are plugged to make a whole. The following sections show how VCL packages modularise generic concerns (section 5), how VCL packages are used to customise generic packages to some context (section 6), how VCL packages modularise concerns of the problem domain, which can either be crosscutting or not (section 7), and how VCL packages can be composed to make larger packages, ultimately to arrive at a package of a subsystem (section 8).

5

Packages That Localise Generic Concerns

VCL packages can modularise solutions to generic concerns to enable their use in various settings. They constitute a functional unit that can be reused and has state of its own; each package comprises a definition of structure (described using structural and constraint diagrams) and behaviour (described using contracts). The following shows the VCL modularisation of the following generic crosscutting concerns: authentication of users, access control, management of session activity, security management, logging, mapping and video-surveillance. In [14] we also address the location tracking concern. To illustrate VCL’s formal Z semantics, we provide in [14] the Z representation of some of the packages developed in the next sections. 5.1

Users

Common to both authentication and access control, are concerns related with users. This section defines packages to represent and manage users. Package definitions. To represent user information and manage users, we introduce packages Users and UsersMgmt; both describe user-related concerns. Figure 7 (left) defines package UsersMgmt, which extends Users; this means that the former incorporates the latter and adds something of its own. The Z model resulting from these VCL packages is given in [14].

Using VCL as an Aspect-Oriented Approach to Requirements Modelling

IDOfUsersUnique




UsersHaveSameId

UsersHaveSameId

㱺 UsersEqual

UsersEqual

u1 : User

u1 : User

u2 : User

u2 : User

u1

uid

u2.uid

159

u1

u2

Fig. 8. Constraint diagram defining constraint IDOfUsersUnique

Structure. Packages encapsulate structures, which are defined in the package’s VCL structural diagram (SD). SDs’ main construct is the blob, a rounded contour denoting a set, that represents some system entity. There are two types of blobs: domain (bold line) and value (normal line). Domain blobs are part of the state of the overall system; they are dynamic and need to be maintained by the system. Value blobs define an immutable set of values that do not need to be maintained by the system. To represent objects (members of some blob) VCL uses rectangles. Figure 7 presents SD of package Users. Domain blob User represents users of a system; it is to be used by other packages requiring user-related functionality. Value blob UserStatus defines a set by enumerating its elements inside its contour (symbol  says that a blob is defined by what it encloses); it says UserStatus comprises distinct elements named loggedIn, loggedOut and blocked. The labelled arrows emanating from User are called property edges; they define properties possessed by all elements of the set. User objects have a user identifier (uid), the actual name of the user (name), a password (pw), a record of the number of password misses (pwMisses) kept for security reasons, and a login status (status), representing the fact that a user may be logged-out, logged-in or blocked because the number of password tries exceeded the allowed maximum. The object (rectangle) linked to User defines a local constant visible only in the scope of this blob; maxPwMisses of blob Nat (natural numbers) represents the maximum number of allowed consecutive password misses. In VCL, elongated hexagons represent constraints. The one connected to User defines a local invariant (in OO terms a class invariant), which restricts the number of valid instances of this blob. Invariant IDOfUsersUnique is defined in the constraint diagram of figure 8, which expresses graphically, in a style akin to the predicate-calculus (see [5,3] for details), that if two users have the same id, then they must be the same user. Behaviour. VCL’s unit of behaviour is the operation. VCL packages comprise a collection of structures, such as blobs and property edges; operations manipulate the information stored in these structures. Contracts define operations, describing what they must do. In VCL, operations may be local or global. They are local when they describe the internal behaviour of a single structure. A global operation describes the collective behaviour of a collection of structures. The global operations of a package define the behaviour that the package offers to the outside world.

160

N. Am´ alio et al.

CreateUser

New

EditUser

User Edit

User

RemoveUser

GetUserGivenID

ChangeUserPassword Delete ChangePassword

GetID

Fig. 9. Behavioural diagrams of package Users (left) and UsersMgmt (right)

GetID

GetUserGivenID uid? : UID

u! : User uid u!

uid?

u? : User uid u?

uid! : UID

uid!

Fig. 10. Constraint diagrams defining local observe operations GetUserGivenID and GetID of blob User in package Users

VCL behavioural diagrams (BDs) identify the operations of a package. There are two types of operations: update and observe (or query). Update operations perform changes of state in the system; they involve a pair of states: before-state (described by pre-condition) and an after-state (described by post-condition). They are defined in VCL contract diagrams. Query operations observe some state of the system and they involve a single state. They are defined in constraint diagrams, differing from ordinary constraints in that they return values (the observations). In BDs, update operations are represented as contracts (double-lined elongated hexagons labelled with the name of the operation); observe operations are represented as constraints (single-lined elongated hexagons); in VCL’s tool, double-clicking on operations represented in a BD takes the user to their definition. Local operations are connected to the structure whose behaviour they operate upon. Global operations stand alone. Figure 9 presents BDs of package Users (left) and UsersMgmt (right). BD of package Users introduces observe operations GetUserGivenID and GetID of blob User, which yield, respectively, a user object given a user identifier and a user identifier from a user object. Package UsersMgmt defines operations for managing users; it introduces global operations CreateUser, EditUser, RemoveUser and ChangeUserPassword, and local operations of blob User. Because they involve a single state, query operations are defined using constraint diagrams. Constraint diagrams of figure 10 define observe operations GetUserGivenID (left) and GetID (right) of blob User. They differ from the normal constraint of figure 8 in that they output a value (the observation). GetUserGivenID receives a user id as input (uid?) and outputs the corresponding User object (u!).3 In VCL, inputs are decorated with ?; outputs with !. GetID receives a user object as input (u?) and outputs a user id (uid!). 3

In VCL contract and constraint diagrams, objects say the set to which they belong; such sets must be visible in the package of the contract or constraint.

Using VCL as an Aspect-Oriented Approach to Requirements Modelling New

Delete

uid? : UserID

pw? : Password

name? : Name

u! : User

ChangePassword u? : User

pwNew? : Password

pwOld? : Password

uid u!

status

u? : User

161

uid? u?

name pw

name?

pwMisses

pw?

loggedOut

0

u?

pw

u?

pw

status [
] pwOld?

pwNew?

loggedIn

Fig. 11. Contract diagrams defining local operations New, Delete and ChangePassword of blob User

VCL contract diagrams describe update operations. They have a name, a declarations compartment, and a predicate compartment sub-divided into preand post- condition compartments. Predicate compartments have a differential meaning regarding an active unit (object, link or blob), which is represented in bold: (a) an active unit on the left (precondition), but not on the right means deletion; (b) an active unit that is on the right compartment (postcondition), but not on the left means creation; (c) the state of an active unit is updated if it is both on left and right compartments. Figure 11 presents contract diagrams for local operations New, Delete and ChangePassword of blob User. They are as follows: – New receives as inputs a user id (uid?), a password (pw?), and an actual name of a user (name), and assigns these to the properties of the newly created User object (u!) (an active object) in the postcondition compartment; u! is an output of the contract. – Delete receives the User object to delete (input u?), and states as a precondition that u? may be deleted provided its status is not logged-in. – ChangePassword takes as inputs a user (u?), old password (pwOld?) and new password (pwNew?). Precondition requires that user’s new password matches old password. Postcondition sets user’s password (pw) to new password. Global operations incorporate (or extend) local ones, and they define some extra behaviour of their own (in the form of pre- and post- conditions). This form of contract composition is achieved through contract importing. A contract placed on the declarations compartment means that it is being imported. Figure 12 presents contract diagrams for global operations CreateUser, RemoveUser and ChangeUserPassword. These contracts import, respectively, local operations New, Delete and ChangePassword of blob User. The meaning of contract importing is conjunction. When a contract imports other contracts, this means that the overall contract is formed as the conjunction of all imported contracts plus the part that the importer defines as its own; pre- and post- conditions of imported contracts are conjoined with pre- and post- conditions of importer. There is no implicit or required ordering in the

162

N. Am´ alio et al.

CreateUser uid? : UID

RemoveUser pw? : PassWord

name? : Name User

ChangeUserPassword

uid? : UID User

uid? : UID Delete

New

User User

pwNew? : Password

pwOld? : Password GetUserGivenId [u?/u!]

GetUserGivenId [u?/u!] User

ChangePassword

Fig. 12. Contract diagrams defining global operations CreateUSer, RemoveUser and ChangeUserPassword of package UsersMgmt

conjunctions underlying contract importing (in logic, conjunction is commutative). VCL operations specify a computation, when operations are conjoined that means that corresponding computations are performed in parallel synchronised on the communication channels being shared. The actual sequential ordering of operations is a decision to be taken at lower levels of abstraction, such as implementation. Contracts may import constraints as well as other contracts. A constraint is imported when placed on the declarations compartment; in this case, the constraint’s state refers to the contract’s before-state (the precondition). Usually, we place query operations in the declarations part to convey the fact that they are operations, and because they usually operate on the before state. We place constraints describing pre- or post- conditions in the appropriate predicate compartment. In contracts, inputs and outputs are communication channels; those having the same name in importer and imported contracts are shared. Sharing means that whatever goes through the channel in composite also goes through the channel with same name in parts; whenever channel names are shared, the bindings involved in the communication do not have to be made explicit. In figure 12, inputs defined in contract CreateUser are shared with imported contract User.New of figure 11. When a communication channel (input or output) is declared in imported contract, but not in composite that means that declared input is existentially quantified in composite contract and is not made available to the outside world. In contract CreateUser, output u! of User.New is existentially quantified. Contracts of figure 12 are as follows: – CreateUser takes inputs uid?, name? and pw? corresponding to inputs with same name in operation User.New (see figure 11). Output u! of User.New is existentially quantified in CreateUser. Pre- and post-conditions are those of User.New. – RemoveUser takes as input a user id (uid?) of user to delete. The declarations compartment imports query operation GetUserGivenId (defined in package Users, see [14]) and the local contract Delete of blob User. The importing of the observe operation includes a renaming expression; the output u! is renamed to u? to enable synchronisation with operation Delete, which uses

Using VCL as an Aspect-Oriented Approach to Requirements Modelling

163

this input. As input u? is not explicitly declared, it is existentially quantified. Precondition is predicate of GetUserGivenId conjoined with precondition of Delete; postcondition is that of Delete. – ChangeUserPassword takes as inputs a user id (uid?), old password (pwOld?) and new password (pwNew?). The last two inputs match those of imported contract ChangePassword of User. Imported query GetUserGivenId includes a rename expression to enable synchronisation with ChangePassword. Precondition is predicate GetUserGivenId conjoined with ChangePassword’s precondition; postcondition is that of ChangePassword. 5.2

Authentication

The authentication security concern deals with authentication of users to enable them to gain access to the system’s resources. The VCL packages addressing this concern provide a solution based on password control; they are as follows: – Authentication represents the core of authentication; it constitutes an aspect. – AuthenticationOps includes authentication operations, enabling users to login and logout from a system. – AuthenticationMgmt includes operations to enable management and administration of authentication. The Z model resulting from these VCL packages is given in [14]. Package Authentication. It modularises the core of a general solution to the concern of user authentication. This package focuses on structure; it is to be extended by other packages to provide authentication-related functionality. Package Authentication (figure 13, left) extends package Users. To avoid clutter and improve usability of SDs, a system of views (part of the design of VCL’s tool) is provided. SDs have a global and a local view. The global view highlights a package’s main entities and the relations that exist between them; the local view highlights the details of some blob. Figure 13 (centre) presents the global view of Authentication package’s SD. SD of figure 13 refers to blob User of Users and introduces domain blob Session (set of sessions users can open in the system). In SDs, Relational edges or associations are labelled directed lines connecting pairs of blobs (direction is indicated by arrow symbol). They describe relations between concepts, denoting IDOfSessionsUnique Users

SID

sid Authentication User Users

HasSession
1

0..1

startTm

Session

Time

Session HasSessionIffLoggedIn

lastTmActive

Fig. 13. Package Authentication extends Users (left). Global structural diagram of Authentication (centre). Local structural diagram for blob Session (right).

164

N. Am´ alio et al.

IsLoggedIn

UserIsLoggedIn

User

cu? : User


IsLoggedIn

UserIsLoggedIn status cu?

User

loggedIn

IsLoggedIn

Fig. 14. Behavioural diagram of Authentication (left). Contract diagrams defining observe operations IsLoggedIn of blob User (centre), and global UserIsLoggedIn of package Authentication (right).

AuthenticationOps Authentication

⃝LoginResult loginOk wrongPW

Login

Logout

isBlocked User

Session

HasSession

Fig. 15. Package AuthenticationOps extends Authentication (left). SD of AuthenticationOps introduces blob LoginResult (centre). Global view of AuthenticationOps package’s behaviour diagram (right).

a mathematical relation between sets. In the diagram, HasSession is a relational edge between User and Session; its UML-style multiplicity constraint says that a user has at most one session and that a session has one user. In VCL SDs, zooming yields the local details of blobs (their local view ). Figure 13 (right) presents Session’s local SD. Session objects have a session identifier (sid); they record their starting time (startTm) and the last time they were active (lastTmActive). Constraint IDOfSessionsUnique represents Session’s local invariant requiring uniqueness of sids (see [14]); its definition is similar to the constraint diagram of figure 8, which requires uniqueness of User identifiers. Authentication’s BD (figure 14, left) introduces observe operations UserIsLoggedIn (global) and local IsLoggedIn of blob User, where the former promotes the latter. These operations check whether some user is logged or not; they are defined in figure 14 (centre, and right). Package AuthenticationOps. It provides login and logout operations. Its package diagram (figure 15, left) says that it extends Authentication. Its SD (figure 15, centre) introduces value blob LoginResult, representing the set of values to be output as a result of a Login operation. As SDs, BDs are articulated with a zooming system based on views to reduce clutter. The local view shows local behaviour of a particular modelling element; the global view highlights the package’s overall behaviour. Figure 15 (right) presents global BD of package AuthenticationOps, identifying the following operations: – Login: it authenticates users granting them access to the system by opening a system session. – Logout: it is used by users to terminate their system sessions.

Using VCL as an Aspect-Oriented Approach to Requirements Modelling LogInOk

165

Logout

u? : User

r!: LoginResult

u? : User

pw? : Password

loggedOut LoginOK

pwMisses u?

0

u?

u?

status

status

status

status loggedIn

User

LoginNotOK

u?

pw

pw?

Logout

loggedIn

loginOk

r!

loggedOut

Fig. 16. Local behaviour diagram of blob User in package AuthenticationOps (left). Contract diagrams of User operations LoginOk and Logout. LoginNotOK u? : User

LoginBlocked

pw? : PassWord

r!: LoginResult

u? : User

u?

LogInBlocked

r!: LoginResult

r!

status

LogInWrongPWToBlocked




pw? : PassWord

isBlocked

blocked

LogInWrongPw

LoginWrongPW u? : User

loggedOut

status

LoginWrongPWToBlocked

pw? : PassWord

r!: LoginResult

u?

pw?

pw [
]

u?

pwMisses [ a2; apply requestVideo(user: ’coord’) => {a3,a4}; apply ignoreDisconnection => a4; apply fakeWitnessInfo => a2a3; apply fakeCrisisDetected => a4; apply fakeCrisisDetected => requestVideo::a3; }

// // // // // // //

1a. 2a. 3a. 4a. 5a. 5b. 5b.

Fig. 4. Composition unit to build the Capture Witness Report complete process

Fragment weave in Adore is an endogenous process, and thus it is possible to weave a fragment into another fragment to produce a larger fragment. The last line of the composition unit weaves a fragment into another one. Such a composition is performed before using the targeted fragment into other weaving actions. In this case, it means that the fakeCrisisDetected fragment is woven into the requestVideo fragment. The resulting fragment is then woven into the targeted orchestration as required by the extension #3a. The orchestration model obtained for the complete use case after composition is really large, and represented in appendix7 . We show only part of the obtained result in Fig. 5 to ameliorate the readability of the result. This figure shows the before/after composition views that focuses on activities {a3 , a4 , a50 } of the captureWitnessReport orchestration. 3.2

Behavioral Merge

When several fragments {f1 , . . . , fn } must be woven into a process using the same hook, the algorithm automatically performs a preliminary merge of the fragment set to compute a merged fragment. The merge algorithm performs a unification of the fragments’ special activities (P, S and hook) to build the merged fragment [10]. The merge algorithm relies on logical unification and substitution [11]. The process is then deterministic: for a given set of fragment, there will be only one possible merged result. {ω(f1 , a), . . . , ω(fn , a)} ≡ ω(merge({f1 , . . . , fn }), a) 7

The interested reader can browse all the composition results by visiting the case study web site. The figure 17 in annexe depicts the resulting orchestration after weaving all the fragments. But readability is difficult.

210

S. Mosser, M. Blay-Fornarino, and R. France

(a) Capture Witness Report before behavioral composition (Extract)

(b) Capture Witness Report after behavioral composition (Extract) Fig. 5. Illustrating the fragment weave process on Capture Witness Report

From the composition unit described in Fig. 4, the algorithm identifies that two fragments must be woven on the a4 activity: fakeCrisisDetected (Fig. 6a) and ignoreDisconnection8 (Fig. 6b). A merge of these two fragment is then required before weaving the merged fragment using a4 as hook. 3.3

Pointcut Matching Mechanism

Adore does not focus on automatic pointcut matching as it is usual for business processer modeler to explicit the points they want to control in a given process. However, the Adore meta-model intrinsically relies on set theory and first order logic. One can then use these formal tools to automate the pointcut matching phase of the system design. We can take as an example the logError non-functional fragment, previously described. This fragment should be woven on activities which can potentially throw a fault. An activity a is a candidate for such a weaving since there exists another activity b linked to a by a f ail relation (on any ϕ fault). This statement can be formally defined using the following rule: a ∈ A , ∃b ∈ A , ∃ϕ ∈ F aults, f ail(a, ϕ) ≺ b

8

The h

disconected

−→

S red arrow represents the catch of an error thrown by h.

Workflow Design Using Fragment Composition

(a) 5b: f akeCrisisDetected

211

(b) 4a: ignoreDisconnection

(c) merge({f akeCrisisDetected, ignoreDisconnection}) Fig. 6. Illustrating the fragment merge process through a simple example

4

Analyzing ADORE Models to Identify Inconsistencies

The large size and conceptual complexity of applications such as the Cccms is the main motivation for using aspect-oriented orchestration modeling approaches such as Adore. Separation of concerns reduces the complexity when focusing (locally) on one or a few fragments, but, at the same time, increases complexity when looking (globally) at the model as a whole. To tame this complexity we proposed to analyze the fragments and composed models to detect inconsistencies and bad-smells. The Adore framework supports consistency checking at different phases. In the first phase (P1 ), consistency checks are performed within each individual fragment and orchestration model separately. In the second phase (P2 ), consistency checking involves analyzing the set of matched joint points to discover symmetric composition of fragments. In the third phase (P3 ) consistency checks involve checking the consistency of behavioral merge results9 . The last consistency checks are performed on the final orchestration models (P4 ). 9

This is an interesting property of the Adore framework: the behavioral merge only produces new fragments at shared join points. As a consequence, the consistency check mechanism is only triggered on merged fragments, and thus avoiding combinatorial explosion of fragment combinations to check.

212

S. Mosser, M. Blay-Fornarino, and R. France Table 2. Adore identification when detecting inconsistencies Rule \ step of Checks R1 Concurrent Ending R2 Equivalent Calls R3 Lack of Response R4 Design Weakness R5 Reflexive composition R6 Recursive Condition R7 Missing Weave R8 Uninitialized Variable R9 Invocation Cycle

P1 &P3 P2 P4 error – bad–smell bad–smell – bad–smell bad–smell – error bad–smell – bad–smell – error – – error – – bad–smell – bad–smell – error bad–smell – bad–smell

Each check is described as a rule. A rule can be applied at different phases of the composition process. The result is interpreted differently according to the consistency checking phase. For instance, incompleness is interpreted as bad smell at phases P1−3 and as an error at phase P4 . Table 2 summarizes how Adore interprets result of rule violations according to the phase. We applied these rules on the Cccms case study. Here we only present the rules that have helped to detect errors in our design of the application or that indicated deficiencies in the requirements. We classify these rules according to their relationships with the principles of aspect-oriented modeling. Separation of Concerns. Adore focuses on separation of activities modeling according to non-functionnal aspects and extensions to main scenarios. A side effect of separating our concerns is concurrent response spawn, redundant invocations, ... R1 : No Concurrent Ending This rule checks whether an Adore model is deterministic or not. A deterministic Adore model has only one well-defined response activity for one path in the activity graph. Such a situation must not exist in the base and fragment orchestrations. But concurrent responses can occur after composition, as a result of interactions between fragments. Such a non-deterministic situation is considered as an error at phase P1 and as a bad-smell at P4 . A design choice must be done by the modeler to fix it (e.g. introducing new activities, explicitly keeping the nondeterministic behavior). In the Capture Witness Report use case (#2), main success scenario failures are defined in extensions. For example, scenario extensions #5a and #5b are defined in parallel. The first one defines a failure when the Phone Company actor cannot verify witness informations. The second one defines another failure when the Coordinator actor declares this crisis as a fake one. Since those two different situations are handled by two different actors in parallel, the system is non-deterministic at the requirements level. We illustrate the situation in Fig. 7. Activity a131 represents failure defined in extension #5a and activity a139 represents the failure defined in extension #5b.

Workflow Design Using Fragment Composition

213

Fig. 7. R1 violation: Concurrent response spawn {a139 , a131 } (extract)

As defined in the requirements document, there is no order between these two activities. As a consequence, the process behavior is non-deterministic when the two conditions are evaluated to false at the same time. In this particular case, as there is no error handling policy in the main orchestration (resolveCrisis), we decide to let the process be non-deterministic: the first encountered exception will be propagated to the caller without any more reasoning. This rule was particularly useful in detecting “bad” join points (e.g. some invocations to user interfaces with a cmsEmployee as parameter do not correspond to interactions that should be protected by authentication). R2 : No Unanticipated Equivalent Calls. Multiple fragments can introduce service invocations that are equivalent by weaving a same fragment on several activities or by requesting a same service in different fragments. A rule that brings these equivalent services to the attention of the modeler can cause the modeler to consider how the model can be refactored to avoid unnecessary redundant invocations of services. To illustrate this rule, we focus on the statistics logging non-functional propertie. To record statistical information on response time of each rescue team, we weave the fragment logTime (cf. Fig. 3) around each invocation activity involving a cmsEmployee. When this fragment is woven on two immediately consecutive activities, it results in the situation depicted in Fig. 8 (extract of the Execute Rescue Mission use case). The activities a341 and a354 return the same time. The business process can be refactored by unifying these two activities. A knowledge is added in the system to optimize the orchestrations involving these useless concurrency calls (this pattern was detected three times in the Cccms). Another interesting illustration can be found in the Capture Witness Report use case. This rule has also detected that the Coordinator can inform the system that the crisis is a fake one by analyzing witness answers, or by looking at the video feed, if available. Consequently, the Coordinator ’s approval will be requested twice when a video feed is available. In this case, we consider that the redundancy of the situation is handled by the ui service: it will not broadcast to the coordinator the same question multiple times.

214

S. Mosser, M. Blay-Fornarino, and R. France

Fig. 8. R2 violation: Unanticipated Equivalent Call {a341 , a354 }

Model Incompleteness. By nature fragments defined a partial point of view on existing entities. As a consequence, fragments do not necessarily have to be complete, i.e., they only need to specify the variables and the activities that are relevant within the concern that is modeled. R3 : Always a response. This rule checks whether a path exists between an entry point (message reception or predecessors) and an exit point (response sending, error throwing or successors), under all possible branching conditions or error handling expressed inside the control-flow. An Adore model that satisfies this rule is said to be complete with respect to paths from entry to exit points. At phases P1 and P3 , a fragment or orchestration model addresses specific concerns and thus may not be a complete model; this happens when a path from an entry point to an exit point is not in the scope of the concern addressed by the model. One can reasonably expect though that the result of a composition is a complete model and thus if the result of a composition violates this rule, the violation is classified as an error at phase P4 . Use case #6 (Execute SuperObserver Mission 10 .) provides examples of incomplete models in phase 1. In the main success scenario, step 7 is defined as: “7. System acknowledges the mission creation to SuperObserver.” The following step is defined as: “8. System informs SuperObserver that mission was completed successfully.”. In the base orchestration that realizes this use case, step 8 is done only if the mission creation has been acknowledged, but the textual use case does not define what happens if the mission is not acknowledged. Figure 9a shows a partial view on the orchestration that realizes this main scenario (orchestration cms::handleSupObsMission). Adore detects there is no path from a7 to an exit activity when the guard is evaluated as ¬ack. The extension #7a is defined as a fragment represented in Fig. 9b. When this fragment is woven to handleSupObsMission, it automatically completes the process and makes it valid (as the composition result does not violate R3 ). R4 : No Design Weakness. This rule checks for common design weaknesses, specifically, unused variables, exceptions that are not caught, and call signature 10

The intention of the SuperObserver actor is to observe the situation at the crisis site to be able to order appropriate missions.

Workflow Design Using Fragment Composition

215

(a) execSupObsMissions inconsistent initial orchestration (Extract)

(b) Extension 7a fix the inconsistency (h ≡ a7 ) Fig. 9. Illustrating the Lack Of Response (R3 ) inconsistency

mismatches. These weaknesses are considered as bad-smells. Fixing such weaknesses is not mandatory for the modeler who can decide to ignore the violations. The orchestration that we defined for use case #1 (“Resolve Crisis”) provides examples of design weaknesses. It states that “Resource submits the final mission report to System”. But this report is never used again in the use case. In the same use case, step 1 requests that the Coordinator capture witness report. This step refers to use case #2 (“CaptureWitnessReport”), which can fail when a fake crisis is detected. The weakness is that there is no extension defining how the system should manage witness report when a fake crisis is detected (i.e., this exception is not caught).

216

S. Mosser, M. Blay-Fornarino, and R. France

Weaving NF-fragments adds error throwing activities. But in the requirements document there is no information how to deal with these errors. This rule has identified this set of missing information in the requirements. Pointcut interactions. Other aspect-oriented approaches often use pattern matching mechanisms to identify join points. In our approach the modeler has to denote the join points explicitly or to use logical predicates to identify activities. Adore can explicitly visualize and reason on this information to detect wrong matches and unintentional fragment compositions. At phase P2 , the set of compositions directives is analyzed by the engine. We focus in this section on the fragment weaving directives, denoted as ω(f, a). R5 : No reflexive composition Pointcut matching can lead to try to weave a fragment on itself. We forbid this weaving as it does not make sense in Adore. This situation can be identified using the following predicate: ∀ω(f, a) ∈ Directives , a ∈ Activities(f ) If such a weaving directive is identified, a bad-smell warning is raised, and the directive is retracted from the directives set. This detection was useful when introducing the persistence concern through the logUpdate fragment. We first match all service invocations using a cmsEmployee variable, but such an invocation is defined inside logUpdate itself! R6 : No recursive composition This rule is an extension of the previous one. It identifies circular weaving of fragments, detected as non-convergent critical pairs. We define this rule as the transitive closure of the following predicate: ∀ω(f, a) ∈ Directives , a ∈ Activities(f ),  ∃ω(f  , a ), a ∈ Activities(f ) We met this difficulty by a bad definition of pointcuts for security and persistence. We just said that all invocations with input a variable of type cmsEmployee must be submitted to access control and be logged. Consequently, password entry should be logged and some log activities require authentication. We modified pointcuts as presented before to handle this issue. Fragments and Pointcuts interactions R7 : No missing weave. When a fragment f is woven on an activity a that is equivalent to another activity a that is not yet woven with f , Adore displays a suggestion that the modeler may have forgotten to weave f on the activity a. As an example, consider use case #1 “Resolve Crisis” 11 . An extension (#5a) defines the process behavior when there is no available external resource. But extension #4a requests an external resource when there is no available internal resource. As a consequence, the error processing mechanism defined in extension #5a must also be triggered when extension #4a is used. 11

The intention of the Coordinator actor is to resolve a car crash crisis by asking employees and external workers to execute appropriate missions.

Workflow Design Using Fragment Composition

217

(a) Extract of handleAMission orchestration (UC #1)

(b) Ext. 4a: unavailableIntResource composition cms::handleAMission { apply unavailableIntResource => a41; // Ext 4a. apply unavailableExtResource => {a51, a5x}; // Ext 5a. } Fig. 10. Illustrating the Forgotten Weave directives (R7 ): a2 ≡ a51

Another illustration can be found in use case #2. We weave fragment unavailableIntResource (Fig. 10a) into the base orchestration handleAMission (Fig. 10b). The Adore platform detects that this fragment inserts an activity (a2 ) which is equivalent to an initial activity (a51 ). As a51 is used as a target for another fragment (unavailableExtResource, Fig. 11a), Adore informs the modeler that she is potentially forgetting a composition directive. In this particular case, we decide to compose the two fragments to deal with the conflicting situation (no available resource at all).

218

S. Mosser, M. Blay-Fornarino, and R. France

(a) UnavailableExtRes fragment

(b) handleAMission orchestration

Fig. 11. Illustrating the Uninitialized variables (R8 ) inconsistency

R8 : No Uninitialized Variable. This rule checks whether a variable is used before being initialized. Ensuring this property before composition is not sufficient to ensure it after composition: Faulty interactions can lead to a composition result that violates this rule. Such a situation is typical when handling error in an orchestration. We define this property using the following predicate: ∀a ∈ A , ∀v ∈ Inputs(a), ∃a ∈ A , v ∈ Outputs(a ) ∧ path(a → a) Following the requirement document, in use case #1, each worker must submit a report to the system. But in extension 5a, which describes how the lack of an external resource is handled, there is no information on how to deal with the missing report. We define the fragment unavailableExtRes (Fig. 11a) to represent the extension #5a. When the algorithm weaves this fragment with the targeted orchestration cms::handleAMission (Fig. 11b), the S activity is unified with a5r . As a consequence (even if an error is thrown by a5X ) the process will try to memorize the expected report (a5r ), but this variable may not be initialized by a5X . In this case, we decided to perform the initialization of the erep variable in the fragment. R9 : No Invocation Cycle This rule checks whether fragments introduce a cycle of invocations. If there is no guarded activities in the execution path, we consider it as an error if not as a bad-smell. Several cycles of invocations were detected in the initial orchestrations and in the orchestration resulting from weaving. This rule has detected an unexpected cycle of invocations in the first version of orchestrations integrating security. We prohibited the user to reconnect when she remains idle a too long time. Modifying the associated pointcut modified the computed set of fragment weaving and consequently eliminated the cycle.

Workflow Design Using Fragment Composition

5

219

Quantitative Analysis

In this section, we highlight the need of separation of concerns when designing a large set of business processes. We collect quantitative data (obtained from Adore) representing the initial system and then make a comparison with data collected after composition (with or without NF-fragments). We use a set of software metrics inspired by state-of-the-art research about business process quality [12]. The analysis we present in this section is based on data that is relevant only in the context of the Aom case study. The raw data for metrics computation are available on the case study web site, and the complete quantitative analysis is publicly available12 . 5.1

Coarse-Grained Structural Complexity: |A |

Definition: Software engineering community usually uses Loc (“lines of code”) to measure corse-grained software size. As the Loc metric is not directly suitable when dealing with business processes we translate this coarse-grained complexity using the activity set cardinality (denoted as |A |). Results: Our results according to this metric for the Cccms case study are depicted in Fig. 12. We represent for each process the associated |A |, and compare three different versions of the Cccms: (i) the initial system (main success scenario), (ii) the business-only system (including the scenarios extensions) and (iii) the final system (including both business extensions and non-functional concerns). The cardinality set average is multiplied by five between the initial system (7.83 activities in average) and the final one (39.25 activities in average).

Fig. 12. Evolution of the |A | indicator 12

http://spreadsheets.google.com/pub?key=tgS6qbzqo5CxTxlcTXbtsPA

220

S. Mosser, M. Blay-Fornarino, and R. France

Analysis: This chart clearly shows that the number of activities involved in the Cccms realization grows really fast. Talking about the evolution cost, up to 10.000 elementary actions13 need to be performed on the initial models to build the final ones. The composition algorithm takes in charge the complexity of building the complete process. In the next section, we focus on this induced complexity by looking at the provenance of entities inside computed processes. 5.2

Entity Provenance

Definition: This section is a corollary of the previous one. Based on the coarsegrained complexity of process, we identify how many activities came from the initial orchestration, the business fragments and finally the non-functional fragments. This indicator allows us to quantitatively qualify which part of the final system was initially defined in the requirements. We normalized these values  using the final cardinality (|A  |) to obtain an activity provenance percentage. Results: Figure 13 represents these indicators for activities in the context of the Cccms. We can immediatly notice than in average, more than 50% of a final process is defined as non-functional activities. Extrema values are interesting too: the cms::assignIntRes (use case #3) process contains only 8% of initial business activities. On the contrary the cms::execRescMission process (use case #7) is composed of more than 70% of initial activities.These values conform to the requirement documents, as scenario #3 defines only two steps in the main scenario and nine in its extensions. On the contrary, scenario #7 defines seven steps and only three in its extension.

Fig. 13. Activities provenance in the final Cccms

13

e.g., creating a variable or defining a new relation. A complete list of Adore elementary actions is available on the tool website.

Workflow Design Using Fragment Composition

221

Analysis: These indicators enforce the straightforward mapping between textual use cases and designed process. A large process with small extensions will be defined as a large orchestration and few fragments. But it also demonstrates the need of automatic composition, as in some case up to 75% of a process is defined as extensions of a main scenario. 5.3

Cognitive Load: Process Surface and Labyrinthine Complexity

Definition: The cognitive load indicator aims to quantify the intrinsic complexity of a business process. It is defined as an coarse-grained approximation of the Control Flow Complexity indicator [13], based on two simple concepts: the process surface and the labyrinthine complexity. Surface is computed as a product between process width (i.e. number of activities executed in parallel) and process height (i.e. longest path between an entry point and a exit point). The labyrinthine complexity represents the number of different path available in the process. Inspired by [14] who defines cognitive load of programs as a linear function (based on structural complexity), we define the cognitive load of an Adore process as the multiplication of its surface and its labyrinthine complexity, normalized by the number of activities inside the process (|A |). This indicator allows us to apprehend both computational and psychological complexities as defined by Cardoso et al [15]. CognitiveLoad(p) =

Surf ace(p) × Labyrinthine(p) |Ap |

Results: We focus in this part on the business-driven Cccms, i.e. the initial system and its business extensions14 . For each process (excepting the handleAWorker one, as its cognitive load is 247.5), Figure 14 represents the sum of initial process and used fragments cognitive load, and the cognitive load of the final process. For five processes (50%), the final load is clearly higher than the sum of initial process and used fragments loads. For the other processes, the final cognitive load follows the same magnitude than the cumulated one. Analysis: This indicator clearly illustrates the immediate advantage of separation of concerns to tame the complexity of designed artifacts. But it also highlights one of the weakness of the Adore platform (and more generally the Aom approach). Designing small processes (or process without multiples extensions) using the separation of concerns paradigm may introduce an overload in the design process. This overload is not visible in terms of result, but can be summarized in the following sentence: “When should one write several small concerns and then express a composition when he/she can directly express the expected result ?”. Such a typical useless composition is illustrated in use case Execute Rescue Mission (#7), as the main scenario is implicitly designed to handle the sole extension defined on it: a request is sent in the main scenario, and the response to this request is handled inside the extension. 14

We consider than non-functional concerns should not be handled manually in an Aom approach.

222

S. Mosser, M. Blay-Fornarino, and R. France

Fig. 14. Cognitive load indicator (Main Success Scenario + Business Extensions)

6

Implementation and Approach Limitations

In this section, we briefly describe the current implementation of the Adore platform. We also describe some intrinsic limitations of the approach. 6.1

Tool Support

Adore user interface is implemented as an Emacs major mode, as shown in Fig. 15. This mode hides in a user-friendly way the set of shell scripts used to interact with the underlying engine. The concrete Adore engine is implemented as a set of logical predicates, using the Prolog language. Rules described in section 4 are also implemented as Prolog predicates. A dedicated compiler (defined using Antlr15 ) implements an automatic transformation between Adore concrete syntax and the associated Prolog facts used internally by the engine (Fig. 16). As visualizing processes is important in design phase, Adore provides a transformation from its internal facts model to a Graphviz16 code which can then be compiled into a Png file. It produces as a result a graphical representation of Adore models, as depicted in all the figures showing Adore models (e.g., Fig. 6, Fig. 3). Raw data (e.g., number of activities, relations, process width) can be extracted as a Xml document. This document can then be processed (manually or using technology like Xslt) to produce before/after graphics and benchmark the approach, as shown in section 5. 15 16

http://www.antlr.org/ http://www.graphviz.org/

Workflow Design Using Fragment Composition

223

Fig. 15. Adore editor, as an Emacs major mode

Fig. 16. Prolog facts, generated by the Adore compiler

6.2

Composition Algorithms

The Adore surface language allows modelers to define composition units. These compositions are compiled as Prolog facts and analyzed by the engine. When the modeler asks Adore to run the compositions, it determines for a given composition the different algorithms (i.e. fragment weave, behavioral merge) that need to be triggered and execute it.

224

S. Mosser, M. Blay-Fornarino, and R. France

We consider as an example a subpart of the captureWitnessReport composition (depicted in Fig. 4), which illustrates all the existing algorithms implemented in Adore. We focus here on the a4 activity, where the modeler asks to weave two different fragments (ignoreDisconnection & fakeCrisisDetected): composition cms::captureWitnessReport { apply ignoreDisconnection => a4; apply fakeCrisisDetected => a4; } To perform such a composition, the logical engine will execute a sequence of actions, represented in Listing 1.1. It starts by cloning the two initial fragments into temporary entities (lines 1 & 2). The identification of a shared join point triggers the merge of the two involved fragments into a new one (line 3). Finally, this merged fragment is woven on the initial process (line 4), and a graph simplification algorithm is triggered (line 5) to make the result more understandable by humans (retracting useless relations). doClone ( ignoreDisconnection , tmp_1 ) , doClone ( fakeCrisisDetected , tmp_2 ) , doMerge ([ tmp_1 , tmp_2 ] , merged_1 ) , doWeave ([ weave ( merged_1 , [ c m s _ c a p t u r e W i t n e s s R e p o r t _ a 4 ])]) , d o P r o c e s s S i m p l i f i c a t i o n( c m s _ c a p t u r e W i t n e s s R e p o r t) ,

1

3

5

Listing 1.1. Internal algorithms usage (automatically computed)

6.3

Pointcuts

Adore does not provides any surface mechanisms to deal with pointcuts expressiveness. One can starts the engine in interactive mode and directly use Prolog to query the model using logical unification. Losing the surface language implies that the modeler know the Prolog programming language. But the immediate benefits are the unbounded possibilities of pointcut description offered by Prolog. We consider as an example the pointcut associated with the logUpdate fragment. This fragment must be applied on services invocation which use a variable of type cmsEmployee or worker as input. Based on the Adore formal model, such a pointcut can be expressed as the following logical rule (a ∈ A ): Kind(a) = invoke ∧ ∃v ∈ InputV ars(a), T ype(v) = (cmsEmployee ∨ worker) Using Prolog, it is very easy to implement such a rule, as shown in Listing 1.2. We provide on the website a Prolog toolbox 17 to automate recurring patterns identification. 17

Such as the findVarUsageByType predicate which identify activities that use a specific type in their associated variables.

Workflow Design Using Fragment Composition

1

3

5

225

cut4logUpdate ( Acts ) : findall ([ A ] , ( findVarUsa ge B yT y pe ( cmsEmployee , in , A ) , hasForKind (A , invoke )) , CmsEmployees ) , findall ([ A ] , ( findVarUsa ge B yT y pe ( worker , in , A ) , hasForKind (A , invoke )) , Workers ) , merge ( CmsEmployees , Workers , Raws ) , sort ( Raws , Acts ). Listing 1.2. Prolog code associated to the logUpdate non-functional concern

We provide in Adore a meta-predicate (Listing 1.3) used to automate the pointcut mechanism. This predicate calls the user-defined pointcut predicates and then automatically build the associated weave directives.

2

build ( FragmentName , PointcutPredicate , Directives ) : call ( PointcutPredicate , List ) , findall ( weave ( FragmentName , E ) , member (E , List ) , Directives ). Listing 1.3. Adore Meta–predicate used to automate pointcut matching

One can then define a pointcut as a unary predicate and asks Adore to build the composition directives associated with it, as shown in (Listing 1.4). 1

3

? - build ( logUpdate , cut4logUpdate , L ) , length (L , Count ). L = [ weave ( logUpdate , [ a13 ]) , weave ( logUpdate , [ a20 ]) ,|...] , Count = 72. Listing 1.4. Computing composition directives associated with logUpdate

6.4

Approach Intrinsic Limitations

Abstraction at workflow level. Our approach aims to support aspect-oriented modeling at the level of workflows. The weaving of aspects inside an activity is not managed by the Adore framework. In other words, we consider atomic activities and service as black boxes and do not provide any mechanisms to enhance them internally. Moreover, when designing such a big system as Cccms, other Aom features are needed to design structural information about services and data. This is another limitation of the Adore platform and one of our perspectives. Scalability. The section 5 demonstrated the scalability of the approach in the Cccms context. The possibility to vizualise and analyze partial composition such as behavioral merge results help taming the complexity of business processes design. One of the limitations of Adore is to provide visualizations only for separate entities: when a system involves many processes, it is necessary to have a holistic point of view on compositions and business processes to grasp it. So other visualization methods are needed to tackle complexity of compositions at the global system level.

226

S. Mosser, M. Blay-Fornarino, and R. France

Incremental composition. Adore works on set of fragments and directives to build final models. The complete approach relies on the existence of all the needed artifacts during compositions. To support incremental composition, modelers add new composition directives and then run the composition algorithms on this new directives. There is no tool support to let the modeler customize manually the final process and keep trace of such actions. These actions will be lost when re-running the algorithms. Pointcut abstraction level. Adore framework does not support complex pointcut definition using a surface language. As soon as we need quantification we need to use directly the logical back-end. This approach is powerful and supports almost all kind of quantification. But the cost is a definitive lost of abstraction mechanisms. We do not consider it as an insurmountable drawback since business process modeler normally use explicit targets when they use process indicators. Weaving and fragment instanciation. The Adore engine relies on the Prolog unification to binds hook variables with real ones. However, when the algorithm cannot unify the variable by itself, modeler must designate the substitutions between variables. This can be a complex task if unified services have a big set of parameters. Reflexivity. There is no real reflective support in Adore. It only allows the usage of a self keyword to represent the current orchestration. We counterbalance this lack of reflexivity using fragment parameters. This is not a definitive solution, and integrating such concern in the Adore meta-model is an ongoing work.

7

Related Work

SOA and AOP. Several approaches fill the gap between orchestrations and Aop (e.g., [16], [17],[18]). These approaches rely on the Bpel language and impose to use dedicated Bpel execution engines to interpret the aspects. Adore preaches technological independence and exposes itself as a model to support composition [10]. Instead of interpreting aspectized Bpel code, Adore focuses on design of workflows by composition and weaving of fragments. When workflow designs are complete, we aim to generate complete orchestrations of services, executable in any industrial engine. This step of transformation is managed by means of correspondences between service models and web services urls. This transformation was used in the national project (Faros consortium) to automatically integrate contacts in an orchestration18. SOA and AOM. Many modeling languages (e.g., UML profiles and domainspecific languages) have been proposed to specify non-functional properties in SOA. In [20] the authors propose a MDD framework consisting of (1) a UML profile to graphically specify and maintain non-functional aspects, and (2) a 18

A technical report in French explains the transformation process [19]. A video demonstration of the transformation chain is also available on the project website: http://www.adore-design.org/doku/examples/faros/start

Workflow Design Using Fragment Composition

227

MDD tool to transform profiled UML model to application code. The semantic of NF-properties is managed by model to code transformations. Reasoning on compositions of NF-properties is then managed at profile definition and transformation level. In [21], they extend this work to non-functional properties in business process models and propose an aspect-oriented language to weave these properties inside a BPMN model. They do not address behavioral composition. To our knowledge, no study have proposed behavioral composition of business processes at business model level, but in sequence or state diagrams [22,23]. Architectures and AOSD. Architecture Description Languages (ADL) domain supports formal notations in order to define structure and behavior of software architectures. For instance in [24], authors use OCL to define invariant properties for component architectures and FSP Language to specify external component behaviors. This framework allows to partially check the architecture type consistency at structural and behavioral level. However, these approaches imply to use several formalisms, and the result of composing specifications is not easy to understand. Such works could be a target for Adore to insure properties such as termination. In [25], the authors manage the integration, in component assemblies, of new concerns represented as architectural aspects. This work relies on transformation rules describing precisely how to weave an architectural aspect in an assembly. Transformation engine manages the composition of the aspects. The behavioral modifications are then the consequences of architecture changes. This differs from our approach in that we focus on behavioral composition and keep the same formalism to express advices and base models. In [26], at component level, the authors express a similar point of view defining aspect components as encapsulation of advice codes. Pointcut specifications. The definition of pointcut languages play a central role in aspect-oriented approaches. But we did not directly contribute to this issue. In this case study we used Prolog unification to match join points. The approach is really powerful but a little bit biased as pointcuts are defined at code level. However, when an activity is identified as a join point, we use Prolog unification, improved with type checking and knowledges, to unify fragment parameters. In this case study, adding semantic markers (e.g., non-functional, business, toBeMonitored) [27,28] and definition of dependent advices [29] would have simplified the expression of pointcuts. These definitions can then rely on abstractions such as: “business fragments are weaved with other business fragments only if they have to be monitored” or “update fragments on resource r requires the usage of the create fragment on the same resource”. Shared Join Points. One of the strengths of Adore is to focus on the socalled Shared Join Points (Sjp[7]) interactions spawn. When a set of fragments must be weaved at a same bloc of activities, the merging algorithm ensures the same result independently of the fragment order. The result of a merging can be visualized and analyzed using the set of rules presented in section 4. When interactions are detected, the modeler will enter knowledge at a fine-grained

228

S. Mosser, M. Blay-Fornarino, and R. France

level (where coarse-grained is fragment re-ordering) to solve the conflict and then ease the interaction. Fragment dependencies. Aspect dependencies is defined in [30] as : “one aspect explicitly needs another aspect”. According to this definition, Adore does not support fragment dependencies; we do not offer operators to define such relations between fragments, whereas work such as Ram [31] supports explicit expression of dependencies between aspects. In this case study, we needed to register the creation of resources to be able to trace resource state changes. The pointcuts for these two fragments determine complementary sets of join points, but we do not expose special operators to deal with these dependencies. If we reread this definition in terms of “an aspect that requires that the referenced aspects are woven previously” [32], Adore supports dependencies throughout weaving on fragments. Aspects weaved on another aspect reinforce this last one [30]. However, these aspects are not really dependent as each one also works correct in isolation. We used several times weaving on fragments as several nonfunctional fragments crosscut business fragments. Fragment Interactions. Fragments as well as aspects can interact in multiple ways [30]. In section 4, we presented rules that detect unexpected interactions leading to unpredictable, duplicated or undesirable behavior but neither mutual exclusions nor conflicts among fragments. However, when determining joint points to require user to re-authenticate when he remains idle for thirty minutes, we first weaved authentication itself. Consequently we had introduced a cycle that has been detected by our detection rules. Multi-view modeling. In [31], authors propose Ram, an aspect-oriented modeling approach that provides multi-view modeling. We only support with Adore behavioral point of view. However, the consistency of the design will be greatly improved extracting service interfaces from orchestration and fragment definition and applying composition algorithm such as Kompose [33] to obtain the service models (using Uml class diagrams for example). Workflow Modeling and Simulation. Inspired by grid-computing community, Adore proposes an algorithm (fully described in [34]) to automatically enhance a process with set concerns. Considering a process p handling a scalar data d, the algorithm can automatically transform p into a process handling a set of data d ≡ {d1, . . . , nn }. Some workflow engines such as Moteur [35] support simulation. We are working on transformation from Adore representation to Gwendia language [36] to simulate the models resulting from the design, in order to analyze execution traces. Visualization & Assessment. Visualization of compositions is a very interesting problem when talking about composition assessment [37]. As Adore allows users or programs to extract information from its internal representation, it is possible to extract process metrics and structural information from the engine.

Workflow Design Using Fragment Composition

229

We are currently linking Adore with Mondrian (an agile visualization tool [38]) to allow modeler to graphically visualize and asses their composition from an holistic point of view.

8

Conclusions and Further Work

This paper describes how to use the Adore method to model the Crisis Management System Case Study as an SOA. In the approach, use cases are modeled as service orchestrations. For each use case, the main scenario is realized as a base orchestration, and the use case extensions and non-functional properties are modeled as fragments. The Adore framework supports composition mechanisms to automatically weave fragments into the base model. It also offers consistency checks to identify problematic interactions between fragments and base models. A quantitative analysis of the approach has been performed based on a set of metrics inspired by state-of-the-art research on measuring business process complexity. It demonstrates the benefits of separation of concerns to tame the complexity of creating and evolving models of large business processes in which many functional and non-functional concerns must be addressed. It also established that automatic merging and weaving of fragments are essential to deal with this complexity. The case study provides some evidence that the Adore method is scalable. The orchestrations produced by the compositions in the case study are moderately large and complex as indicated by the size metrics we have gathered. Introducing non-functional concerns complexify the processes in a really deep way. The automated composition shields the developer from the complexity of composing orchestrations. From a utility standpoint, we were able to realize all the use cases without encountering any methodological problems. Adore intrinsically supports evolution of base orchestrations. We illustrate this feature in the context of this case study by considering each scenario extension as an evolution of the associated main success scenario. The introduction of non-functional properties that impacts processes behaviors such as persistence or statistical logging follows the same methodology. An important Adore goal is to support end-user design of orchestrations, where an end-user is a business process modeler. As a consequence, the modeling language utilizes concepts and expressions that should be familiar to business process modelers. Once a process modeler has specified where fragments are to be woven into the base model, Adore composes the fragments and base models automatically and provides indications of possible problems arising out of interactions between fragments and base orchestrations. Some rules only identify design bad-smells, but others detect errors that make the composed result inconsistent. Such inconsistencies are detected and exposed to the process modeler, who can then fix it. As a consequence, we do not ensure an a-priori orchestration correctness property. It is interesting to notice that these rules were able to detect requirement weaknesses in the context of this case study.

230

S. Mosser, M. Blay-Fornarino, and R. France

One of the limitations of Adore is that it does not support unweaving of fragments. Such unweaving is needed to support exploratory design of orchestrations. We plan to investigate this area (and others discussed in the limitation section) in our future work.

References 1. MacKenzie, M., Laskey, K., McCabe, F., Brown, P., Metz, R.: Reference Model for Service Oriented Architecture 1.0. Technical Report wd-soa-rm-cd1, OASIS (February 2006) 2. White, S.A.: Business Process Modeling Notation (BPMN). IBM Corp. (May 2006) 3. Jordan, D., Evedmon, J., Alves, A., Arkin, A., Askary, S., Barreto, C., Bloch, B., Curbera, F., Ford, M., Goland, Y., Gu´ızar, A., Kartha, N., Liu, K., Khalaf, R., Konig, D., Marin, M., Mehta, V., Thatte, S., Van der Rijn, D., Yendluri, P., Yiu, A.: Web services business process execution language version 2.0. Technical report, OASIS (2007) 4. Mustafiz, S., Kienzle, J.: Drep: A requirements engineering process for dependable reactive systems, pp. 220–250 (2009) 5. Mosser, S., Blay-Fornarino, M., Montagnat, J.: Orchestration Evolution Following Dataflow Concepts: Introducing Unanticipated Loops Inside a Legacy Workflow. In: International Conference on Internet and Web Applications and Services (ICIW) AR=28%, Venice, Italy, IEEE Computer Society, Los Alamitos (May 2009) 6. on Software Evolution, E.W.G.: Terminology. Technical report, ERCIM (2010) 7. Nagy, I., Bergmans, L., Aksit, M.: Composing Aspects at Shared Join Points. In: NODe/GSEM. LNI, vol. 69, pp. 19–38. GI (2005) 8. Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W.G.: An overview of aspectj. In: Knudsen, J.L. (ed.) ECOOP 2001. LNCS, vol. 2072, pp. 327–353. Springer, Heidelberg (2001) 9. Performance indicators. In: BERA Dialogues (1990) 10. Mosser, S., Blay-Fornarino, M., Riveill, M.: Web Services Orchestrations Evolution: A Merge Process for Behavioral Evolution. In: Morrison, R., Balasubramaniam, D., Falkner, K. (eds.) ECSA 2008. LNCS, vol. 5292, pp. 35–49. Springer, Heidelberg (2008) 11. Stickel, M.E.: A unification algorithm for associative-commutative functions. J. ACM 28(3), 423–434 (1981) 12. Vanderfesten, I., Cardoso, J., Mendling, J., Reijers, H.A., Van Der Aalst, W.M.: Quality Metrics for Business Process Models. In: BPM and Workflow Handbook, pp. 179–190 (2007) 13. Cardoso, J.: Evaluating the process control-flow complexity measure. In: ICWS, pp. 803–804. IEEE Computer Society, Los Alamitos (2005) 14. Laue, R., Gruhn, V.: Complexity Metrics for Business Process Models. In: Abramowicz, W., Mayr, H.C. (eds.) BIS. LNI, vol. 85, pp. 1–12. GI (2006) 15. Cardoso, J., Mendling, J., Neumann, G., Reijers, H.A.: A discourse on complexity of process models. In: Eder, J., Dustdar, S. (eds.) BPM Workshops 2006. LNCS, vol. 4103, pp. 117–128. Springer, Heidelberg (2006) 16. Charfi, A., Mezini, M.: Aspect-oriented web service composition with ao4bpel. In (LJ) Zhang, L.-J., Jeckle, M. (eds.) ECOWS 2004. LNCS, vol. 3250, pp. 168–182. Springer, Heidelberg (2004)

Workflow Design Using Fragment Composition

231

17. Courbis, C., Finkelstein, A.: Weaving aspects into web service orchestrations. In: ICWS, pp. 219–226. IEEE Computer Society, Los Alamitos (2005) 18. Verheecke, B., Vanderperren, W., Jonckers, V.: Unraveling crosscutting concerns in web services middleware. IEEE Software 23(1), 42–50 (2006) 19. Blay-Fornarino, M., Ferry, N., Mosser, S., Lavirotte, S., Tigli, J.Y.: D´emonstrateur de l?application SEDUITE. Technical Report F.4.4, RNTL FAROS (September 2009) 20. Wada, H., Suzuki, J., Oba, K.: A model-driven development framework for nonfunctional aspects in service oriented architecture. Int. J. Web Service Res. 5(4), 1–31 (2008) 21. Wada, H., Suzuki, J., Oba, K.: Early aspects for non-functional properties in service oriented business processes. In: SERVICES 2008: Proceedings of the 2008 IEEE Congress on Services - Part I, Washington, DC, USA, pp. 231–238. IEEE Computer Society, Los Alamitos (2008) 22. Klein, J., Fleurey, F., J´ez´equel, J.M.: Weaving multiple aspects in sequence diagrams. In: Rashid, A., Aksit, M. (eds.) Transactions on AOSD III. LNCS, vol. 4620, pp. 167–199. Springer, Heidelberg (2007) 23. Nejati, S., Sabetzadeh, M., Chechik, M., Easterbrook, S., Zave, P.: Matching and merging of statecharts specifications. In: ICSE 2007: Proceedings of the 29th international conference on Software Engineering, Washington, DC, USA, pp. 54–64. IEEE Computer Society, Los Alamitos (2007) 24. Barais, O., Duchien, L.: In: SafArchie Studio: An ArgoUML extension to build Safe Architectures, pp. 85–100. Springer, Heidelberg (2005) ISBN: 0-387-24589-8 25. Barais, O., Lawall, J., Meur, A.F.L., Duchien, L. (eds.): Software Architecture Evolution, pp. 233–262. Springer, Heidelberg (2008) 26. Pessemier, N., Seinturier, L., Duchien, L., Coupaye, T.: A Component-Based and Aspect-Oriented Model for Software Evolution. International Journal of Computer Applications in Technology 31, 94–105 (2008) 27. Mussbacher, G., Whittle, J., Amyot, D.: Semantic-based interaction detection in aspect-oriented scenarios. In: RE 2009: Proceedings of the 2009 17th IEEE International Requirements Engineering Conference, RE, Washington, DC, USA, pp. 203–212. IEEE Computer Society, Los Alamitos (2009) 28. Chitchyan, R., Greenwood, P., Sampaio, A., Rashid, A., Garcia, A., Fernandes da Silva, L.: Semantic vs. syntactic compositions in aspect-oriented requirements engineering: an empirical study. In: AOSD 2009: Proceedings of the 8th ACM international conference on Aspect-oriented software development, pp. 149–160. ACM, New York (2009) 29. Bodden, E., Chen, F., Rosu, G.: Dependent advice: a general approach to optimizing history-based aspects. In: AOSD 2009: Proceedings of the 8th ACM international conference on Aspect-oriented software development, pp. 3–14. ACM, New York (2009) 30. Sanen, F., Truyen, E., Joosen, W.: Classifying and documenting aspect interactions. In: Proceedings of the Fifth AOSD Workshop on Aspects, Components, and Patterns for Infrastructure Software, pp. 23–26 (2006) 31. Kienzle, J., Al Abed, W., Klein, J.: Aspect-oriented multi-view modeling. In: AOSD 2009: Proceedings of the 8th ACM international conference on Aspect-oriented software development, pp. 87–98. ACM, New York (2009) 32. Apel, S., K¨ astner, C., Batory, D.: Program refactoring using functional aspects. In: GPCE 2008: Proceedings of the 7th international conference on Generative programming and component engineering, pp. 161–170. ACM, New York (2008)

232

S. Mosser, M. Blay-Fornarino, and R. France

33. France, R., Fleurey, F., Reddy, R., Baudry, B., Ghosh, S.: Providing support for model composition in metamodels. In: EDOC 2007 Entreprise Distributed Object Computing Conference, Annapolis, MD, USA (2007) 34. Mosser, S., Blay-Fornarino, M., Montagnat, J.: Orchestration Evolution Following Dataflow Concepts: Introducing Unanticipated Loops Inside a Legacy Workflow. In: International Conference on Internet and Web Applications and Services (ICIW) AR=28%, Venice, Italy. IEEE Computer Society, Los Alamitos (May 2009) 35. Glatard, T., Montagnat, J., Lingrand, D., Pennec, X.: Flexible and efficient workflow deployement of data-intensive applications on grids with MOTEUR. International Journal of High Performance Computing Applications (IJHPCA) IF=1.109 Special issue on Special Issue on Workflows Systems in Grid Environments 22(3), 347–360 (2008) 36. Montagnat, J., Isnard, B., Glatard, T., Maheshwari, K., Blay-Fornarino, M.: A data-driven workflow language for grids based on array programming principles. In: Workshop on Workflows in Support of Large-Scale Science(WORKS 2009) (November 2009) 37. Pfeiffer, J.H., Gurd, J.R.: Visualisation-based tool support for the development of aspect-oriented programs. In: AOSD 2006: Proceedings of the 5th international conference on Aspect-oriented software development, pp. 146–157. ACM, New York (2006) 38. Meyer, M., Gˆırba, T., Lungu, M.: Mondrian: an agile information visualization framework. In: SoftVis 2006: Proceedings of the 2006 ACM symposium on Software visualization, pp. 135–144. ACM, New York (2006)

Fig. 17. Orchestration representation for the Capture Witness Report use case (#2) after weaving of all the fragments

Workflow Design Using Fragment Composition

Annexes 233

Modeling the Car Crash Crisis Management System Using HiLA Matthias H¨olzl1 , Alexander Knapp2 , and Gefei Zhang1 1

Ludwig-Maximilians-Universit¨at M¨unchen {matthias.hoelzl, gefei.zhang}@pst.ifi.lmu.de 2 Universit¨at Augsburg [email protected]

Abstract. An aspect-oriented modeling approach to the Car Crash Crisis Management System (CCCMS) using the High-Level Aspect (HiLA) language is described. HiLA is a language for expressing aspects for UML static structures and UML state machines. In particular, HiLA supports both a static graph transformational and a dynamic approach of applying aspects. Furthermore, it facilitates methodologically turning use case descriptions into state machines: for each main success scenario, a base state machine is developed; all extensions to this main success scenario are covered by aspects. Overall, the static structure of the CCCMS is modeled in 43 classes, the main success scenarios in 13 base machines, the use case extensions in 47 static and 31 dynamic aspects, most of which are instantiations of simple aspect templates.

1 Introduction The UML has become the customary modeling language for many software development projects; state machines are among the most popular techniques for describing reactive and interactive systems [10]. Therefore, an approach based on UML state machines suggests itself for modeling the behavior of the Car Crash Crisis Management System (CCCMS). However, experience shows that state machine models become complex even for relatively simple systems. Often this complexity is not inherent in the problem itself or even in its description as state-based system, but it is induced by a lack of abstraction mechanisms in UML state machines. This becomes particularly obvious for systems exhibiting mutually interacting use cases: many of the interrelations between different use cases can only be modeled by introducing global state or by pervasive modifications of the state machine structure. To address these problems, we have developed the HiLA approach: the HiLA language is an extension of UML state machines with aspects; it supports both high-level aspects which are based on the dynamic execution behavior of state machines, and lowlevel aspects defined as graph transformations of the static structure of models. HiLA allows the modeler to represent different use cases (or, more generally, different concerns) as separate aspects operating on a single base state machine. This separation of concerns is possible even if the different concerns interact, as long as the behavior of the interaction can be expressed using high-level aspects. S. Katz et al. (Eds.): Transactions on AOSD VII, LNCS 6210, pp. 234–271, 2010. c Springer-Verlag Berlin Heidelberg 2010 

Modeling the Car Crash Crisis Management System Using HiLA

235

By closely aligning state machine models with use case descriptions, the HiLA language not only reduces the complexity of the dynamic models, but also gives rise to a modeling technique that is not easily applicable when working with standard UML state machines: the state machine models can systematically be generated from the analysis results, in particular from use cases. To achieve this, we model each base use case with a state machine, and we model each use case extension as a set of aspects that are applied to one or more base machines. This is a similar technique to the one described by Jacobson’s rendering of use case slices as aspects [15]. The development of the static design model is more traditional, and takes into account both the analysis model and the requirements of the dynamic models. The systematic transition between analysis and behavioral design offers several advantages: it provides a concrete method to move from use cases to state machines; the resulting state machines are easy to understand since they correspond directly to requirements; and the approach provides excellent traceability from requirements to behavioral model and vice versa, which simplifies the validation that all requirements are addressed by the design and simplifies subsequent changes to system requirements. While the part of the CCCMS we modeled is much smaller than most real applications, it is complex enough to demonstrate the advantages that HiLA models and the HiLA approach offer over traditional UML-based approaches to behavioral modeling. However, as we will further elaborate in Sect. 5, HiLA is designed to address certain modeling problems, e.g., complex mutual exclusion requirements or history-dependent behaviors, which are not needed to model the CCCMS case study. For our exposition, we assume that the reader is familiar with the syntax and semantics of UML in general (see [6] for an introduction). In particular, we make use of UML’s template mechanism (see [23, Sect. 17.5] for its specification). The remainder of this paper is structured as follows: Sect. 2 briefly reviews UML state machines and gives an overview of the HiLA language. The modeling of the CCCMS in HiLA is detailed in Sect. 3; Sect. 4 demonstrates how the resulting HiLA model can be validated. The method of applying HiLA to the CCCMS case study, and the HiLA language itself are evaluated in Sect. 5. Related work is discussed in Sect. 6. We conclude by summarizing our approach in Sect. 7.

2 A Brief Overview of HiLA Our modeling language of choice is the UML [23], the lingua franca of object-oriented analysis and design. The static structure of our CCCMS is modeled by class diagrams, its dynamic behavior by state machines, enhanced with HiLA. In the following, we review the basic concepts of UML state machines (see, e.g., [10]) and introduce HiLA. 2.1 UML State Machines A UML state machine provides a behavioral view of its context. Figure 1 shows a state machine of a process which contains two parallel threads. After creation, the process is first initialized in the state Init, then the two threads run in parallel in the state Running, until they receive the events astop and bstop while they are in the states A3 and B3,

236

M. H¨olzl, A. Knapp, and G. Zhang

respectively. In this case, each thread waits for the other to receive its stop signal in waiting states A4 and B4, respectively, before the threads terminate conjointly. In more detail, a UML state machine consists of regions which contain vertices and transitions between vertices. A vertex is either a state, where the state machine may dwell in and which may show hierarchically contained regions, or a pseudo state regulating how transitions are compound in execution. Transitions are triggered by events and describe, by leaving and entering states, the possible state changes of the state machine. The events are drawn from an event pool associated with the state machine, which receives events from its own or from different state machines. The context of a state machine, a UML classifier, describes the features, in particular the attributes, which may be used and manipulated during execution. A state of a state machine is simple, if it contains no regions (such as Init and all states contained in Running in Fig. 1); a state is composite, if it contains at least one region; a composite state is said to be orthogonal, if it contains more than one region, visually separated by dashed lines (such as Running). Each state may show an entry behavior (like actB2 in B2), an exit behavior (like actA2 in A2), which are executed on activating and deactivating the state, respectively; a state may also show a do activity (like in Init) which is executed while the state machine sojourns in this state. Transitions are triggered by events (a12, a23), show guards (condB), and specify actions to be executed when a transition is fired (actA23). Completion transitions (transition leaving Init) are triggered by an implicit completion event emitted when a state completes all its internal activities. Events may be deferred (as a12 in Init), i.e., put back into the event pool, if they are not to be handled currently but only later on. By executing a transition, its source state is left and its target state entered; transitions, however, may also be declared to be internal to a state (b3 / actB3), thus skipping the activation–deactivation scheme. An initial pseudo state, depicted as a filled circle, represents the starting point for the execution of a region. A final state, depicted as a circle with a filled circle inside, represents the completion of its containing region; if all regions of a state machine are completed, the state machine terminates. Junction pseudo states, also depicted as filled circles (see lower region of Running), allow for case distinctions. Transitions to and from different regions of an orthogonal composite state can be synchronized by fork and join pseudo states, presented as bars. For simplicity, we omit the other pseudo state kinds (entry and exit points, shallow and deep history, and choice).

Running a32 A1 Init do / init a12 / defer

a12

A2 exit / actA2

a23 / actA23

aStop

A4

B3 bStop b3 / actB3 b32

B4

A3

a31 B1

b12

B2 entry / actB2 [else]

[condB]

b23

Fig. 1. State machine of a process containing two parallel threads

Modeling the Car Crash Crisis Management System Using HiLA

237

During runtime, a state gets active when entered and inactive when exited as a result of a transition. The set of currently active states is called the active state configuration. When a state is active, so is its containing state. The active state configuration is thus a set of trees starting from the states in the top-level regions down to the innermost active substates. The execution of a state machine consists in changing its active state configuration in dependence of the current active states and a current event dispatched from the event pool. We call the change from one state configuration to another an execution step. First, a maximally consistent set of prioritized, enabled compound transitions is chosen. Transitions are combined into compound transitions by eliminating their linking pseudo states; for junctions, this means to combine the guards on a transition path conjunctively, for forks and joins to form a fan-out and fan-in of transitions. A compound transition is enabled if all of its source states are contained in the active state configuration, its trigger is matched by the current event, and its guard is true. Two enabled compound transitions are consistent if they do not share a source state; an enabled compound transition takes priority over another enabled compound transition if its source states are below the source states of the other transition in the active state configuration. For each compound transition in the set, its least common ancestor (LCA) is determined, i.e. the lowest composite state containing all the compound transition’s source and target states. The compound transition’s main source state, i.e., the direct substate of the LCA containing the source states, is deactivated, the compound transition’s actions are executed, and its target states are activated.

2.2 HiLA An initial version of the High-Level Aspects (HiLA) language, an aspect-oriented extension of UML state machines, was defined in [34]. This section contains an introduction to a further development of HiLA. We first illustrate the main features of HiLA by means of use case 10 “Authenticate User” of the CCCMS, and then give a brief overview of the general syntax and informal semantics of HiLA. Our models consist of a UML basic static structure and a set of UML base state machines. The basic static structure usually contains one or more classes; each base state machine is attached to one of these classes and specifies its behavior.1 HiLA offers two kinds of aspects to modify such a model: Static (or low-level, transformational) aspects directly specify a model transformation of the basic static structure or of the base state machines. Dynamic (high-level) aspects only apply to state machines and specify additional or alternative behavior to be executed at certain “appropriate” points of time in the base machine’s execution. These points of time are when a transition is being fired with the state machine in certain state configurations, or if firing the transition would lead to certain state configurations. The transitions are specified by the pointcut of the dynamic aspect, the behavior to execute by its advice. Dynamic aspects have been introduced in order to avoid certain intricacies arising when relying on model transformations only, e.g., the notorious confluence problem [30] which is mitigated in HiLA by the concurrent execution of all applying aspects [33]. 1

In particular, all classes with state machines are active.

238

M. H¨olzl, A. Knapp, and G. Zhang

We illustrate the static and dynamic aspect language of HiLA by means of their application to use case 10 of the CCCMS. The main success scenario of this use case according to the case study specification [17] reads as follows: 1. System prompts CMSEmployee for login id and password. 2. CMSEmployee enters login id and password into System. 3. System validates the login information.

userid: String pwd: String

System «signal» input(u: String, p: String) «signal» ok

(a) Static structure for use case 10 (simplified)

Prompt

input(u, p) / userid = u; pwd = p

Validate

ok

(b) Base state machine for System from Fig. 2(a) (simplified)

Fig. 2. Use Case 10, main success scenario

Let us assume that the static structure for this use case looks as in Fig. 2(a) and that the main success scenario is modeled by the state machine in Fig. 2(b).2 The class System contains receptions for entering the user id and password and for accepting a successful login attempt. The behavior of System is a direct reflection of the use case description: first the user is prompted to input his credentials (state Prompt), which are then validated (Validate). If the credentials are correct, a signal ok is created by the validation mechanism (not modeled here), upon which the use ends in success. The first extension is specified as follows: 2a. CMSEmployee cancels the authentication process. Use case ends in failure.

«aspect» CancelLogin «transformation pointcut» System

«aspect» WhilstOnDoGoto «pointcut» «whilst» {trigger = cancel} *

«transformation advice» System failure(): void «signal» cancel

(a) Static aspect

«advice» / failure

goto Final

(b) Dynamic aspect

Fig. 3. Aspects for extension 2a of Use Case 10

As is the general strategy in our modeling approach, this extension is represented by aspects; in this case, a combination of one static and one dynamic aspect, as shown in 2

The real situation is given in Figs. 8 and 29.

Modeling the Car Crash Crisis Management System Using HiLA

239

Fig. 3. The pointcut of the dynamic aspect in Fig. 3(b) matches whilst; the base state machine is in any (*) state configuration and the event cancel occurs; it advises the base state machine to execute the advice: perform failure as an effect and go to the Final state of the base machine. The static aspect in Fig. 3(a) adds the reception cancel and the operation failure (and also the implementation of failure) to System. In fact, both the low-level static and the high-level dynamic aspects represent instances of rather general patterns which occur widely in practice and in particular in the CCCMS. To provide a more compact an conspicuous notation, we abstract these and similar aspects into templates, employing the general UML mechanism to parameterize constructs. C «aspect» Op IntroduceOperation «transformation pointcut»

C «aspect» Prop IntroduceProperty «transformation pointcut»

C

C

«transformation advice» C

«transformation advice» C Prop

Op

(a) Extend class C with operation Op

C «aspect» IntroduceClass «transformation pointcut» «transformation advice» C

(b) Extend class C with (c) Introduce class C to property Prop the system

Fig. 4. Low-level (static) aspect templates

The templates used for low-level aspects are shown in Fig. 4. Template IntroduceOperation in Fig. 4(a) introduces a new operation Op into an existing class C; template IntroduceProperty in Fig. 4(b) introduces a property; and template IntroduceClass in Fig. 4(c) represents the creation of a new class. (All these aspects have no effect when the element to be introduced already exists.) The static aspect in Fig. 3(a) can therefore be rendered simply as shown in Tab. 1. Table 1. Use Case 10, extension 2a: Fig. 3(a) as template instantiations Template

Binding

IntroduceOperation C → System Op → signal cancel IntroduceOperation C → System Op → failure(): void

Templates to abbreviate commonly used concepts are even more useful for high-level aspects as illustrated by Fig. 5(a)–(c). These templates all adhere to the following form: Whilst a certain state is active3 , On occurrence of a certain trigger, If a certain condition holds, Do a specified action and then Goto a specified state. The regular naming 3

or Before a certain state becomes active, or After a certain state was active.

240

M. H¨olzl, A. Knapp, and G. Zhang

Whilst On Goto

«aspect» WhilstOnGoto «pointcut» «whilst» {trigger = On}

«aspect» BeforeIfDoGoto «pointcut» «before»

Before If Do Goto

«aspect» WhilstOnDoGoto «pointcut» «whilst» {trigger = On}

Before

Whilst On Do Goto

Whilst

Whilst

{If} «advice» goto Goto

(a) When state Whilst is active, if On is the current event, go to state Goto

«advice» / Do

«advice» / Do

goto Goto

(b) Before activating state Before, if condition If is true, execute the action Do and go to state Goto

goto Goto

(c) When state Whilst is active, if the current event is On, execute the action Do, and go to state Goto

Fig. 5. High-level aspect templates

scheme ensures that the templates are easy to remember and to use; convenient variants and variations are readily formed. Figure 3(b) is an instance of WhilstOnDoGoto with Whilst → *, On → cancel, Do → failure and Goto → Final (instantiating a template parameter X with * is meant as an abbreviation for instantiating X with all states in the base machine). The second and last extension of use case 10 is handling failed authentication attempts: 3a. System fails to authenticate the CMSEmployee. 3a.1. Use case continues at step 1. 3a.1a. CMSEmployee performed three consecutive failed attempts. 3a.1a.1. Use case ends in failure. Modeling such behavior requires the ability to track the execution history of the state machine. For this purpose HiLA offers history properties.

«aspect» ThreeFails «history» «aspect» : WhilstOnGoto Whilst −> Validate On −> fail Goto −> Prompt

(a) Aspect fail

Validate [3] f3 = # [0]

«aspect» : BeforeIfDoGoto Before −> Prompt If −> f3 >= 1 Do −> failure() Goto −> Final

(b) Aspect 3fail

Fig. 6. Dynamic aspects for extension 3a of Use Case 10

The dynamic aspect in Fig. 6(a) uses the template notation: a failed authentication attempt leads back to state Prompt. (From here on we will employ template notation whenever adequate.) However, the dynamic aspect in Fig. 6(b) is additionally equipped

Modeling the Car Crash Crisis Management System Using HiLA

241

with a history property. The history variable f3 stores the number of such subsequences in the execution history in which state Validate was active three (multiplicity [3]) times without the final state being active (multiplicity [0]). The history variable f3 is used in the enclosed aspect template instance to ensure that after three consecutive failed authentication attempts (f3 >= 1) the machine terminates. 2.3 General Concrete Syntax and Informal Semantics of Dynamic Aspects The general concrete syntax of high-level aspects is shown in Fig. 7; the oblique identifiers are place holders. State* is a set of states. The selector may be either before, after or whilst. A pointcut labeled with after selects all transitions leaving any state in State* while the state machine is in a state configuration containing all states in State* . Similarly, a pointcut labeled with before selects each transition T entering any state contained in State* , but only in active state configurations where after taking T all states in State* will become active. A pointcut labeled with whilst always has an annotation Trigger = e; conceptually it selects the compound transition from State* to State* with trigger e, but if this transition does not already exist it is created by the pointcut. Alternatively, the selector may be empty and a set of states and transitions ST* may be specified. In this case, the pointcut matches all (existing) transitions in ST* . Note that for any given event and environment, a whilst aspect is only enabled when no existing transition is enabled for this event and environment; moreover, only whilst aspects can cause transitions in situations where no originally existing transition reacts to the given event and environment. Pointcuts with selector before or after, or with empty selector only match existing transitions. The pointcut may contain a constraint. In this case, the advice is only executed when the constraint is satisfied at the time of matching the pointcut. The third case shown in Fig. 7(a) takes into account the active state configurations of all state machines belonging to one of the specified Classes; Mult , selector and State are functions of Class. If Mult is not specified, then Mult := *. In the case the selector is before, the pointcut selects a transition in the currently active state machine if that transition would cause Mult instances of each specified Class to be in active state

Par1 Par2

«aspect» Name «pointcut» selector State*

selector : Class

ST*

State* [Mult] {Constraint} «advice»

AdvBody

Label 1 Label 2 Label 3

(a) Class aspects

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

(b) History properties

Fig. 7. Concrete syntax of HiLA aspects

242

M. H¨olzl, A. Knapp, and G. Zhang

configuration State* with satisfied Constraint . If the selector is after, then the pointcut matches transitions that are about to be fired, while there are Mult instances of each specified Class in active state configuration State* with satisfied Constraint . In general, the advice of a dynamic aspect is a state machine, where the final states may be labeled. When an advised transition is taken, the advices of all aspects that advise this transition are executed concurrently. When all advices have reached a final state, execution of the base machine is resumed, normally with a compound transition from the final states of the advices to the target state of the advised transition. The labels on final states can modify this resumption transition: if one or more final states are labeled goto T and all other states are unlabeled the target of the resumption transition is the state T; if concurrently active final states are labeled goto T and goto T’ with T  = T’ the state machine is erroneous. Note that this does not preclude final states with different labels, but in an error-free state machine they may not be active simultaneously. In HiLA, properties of the execution history are specified by history properties. The basic idea behind history properties is that they provide a declarative way to specify the value of a variable that depends on the execution history of the state machine; other aspects can then use that value in their pointcut or advice to enable history-sensitive behavior. History properties are defined in history aspects, which are identified by the label history, as shown in Fig. 7(b). A history property contains a name, followed by an operator and a pattern consisting of active state configurations and guards. The pattern matches contiguous subsequences of the execution history. The value of the history property is the result of applying the function defined by the operator to the subsequences selected by the pattern. In particular, operator # (“number of”) returns the number of matches of the pattern by the base machine’s execution history where the guards evaluate to true. The pattern language is regular, as presented in [34], patterns can be concatenated by an arrow (→), as presented in [32].

3 Modeling the CCCMS We model the domain of the CCCMS in UML class diagrams and its behavior in UML state machines, “the most popular language for modeling reactive components” [10]. The method that we follow in the modeling task of the state machines is to first derive a base state machine from the main success scenarios of the use cases and then to enrich these bases by HiLA aspects for all the extensions of the primary scenario. In our description, we concentrate on use case 1 of the CCCMS. Use case 1 “Resolve Crisis” (and its included use cases) describes the overall flow of events in resolving a car crash crisis: On a crisis, a coordinator first gathers crisis information; the CCCMS recommends missions based on this information and the coordinator selects missions accordingly. For each mission, internal and external resources are selected, and these resources execute their mission. When execution has finished, the coordinator closes the crisis. 3.1 Overview and Static Structure In our model, we directly represent this main course of actions by handling the different phases of a car crash crisis resolution in a chain of separate objects which reflect

Modeling the Car Crash Crisis Management System Using HiLA

Coordinator

VideoFeed 0..*

0..1

newInfo(ci: CrisisInfo): void rcvRecommendations(recs: Set<MissionDescription>): void rcvChecklist(cl: Checklist): void «signal» operating(m: Mission) «signal» inExecution(m: Mission) «signal» waiting(m: Mission) «signal» finished(m: Mission)

SurveillanceSystem createVideoFeed(loc: Location): VideoFeed 1 1

ERS request(md: MissionDescription, t: Type, sender: Request): void PhoneCompany

243

1

findInfo(wi: Set<WitnessInfo>): Set<WitnessInfo>

System createCrisis(): void getCoordinator(): Coordinator getPhoneCompany(): PhoneCompany getAvailableResources(): Set «signal» crisis() 1 0..*

«enumeration» 1 CrisisType type

CrisisInfo

0..* cInfo

Checklist

0..1 cl

WitnessInfo Location

0..* wInfo 1

0..*

Crisis active: Boolean = false emergencyLevel: Integer pInfo: Set<WitnessInfo>

1 addWitnessInfo(wi: WitnessInfo): void validateInfo(wi: Set<WitnessInfo>): void createChecklist(): Checklist createAdviser(Set<WitnessInfo>): Adviser addCrisisInfo(ci: CrisisInfo): void setEmergencyLevel(): void «signal» wInfoFinished() «signal» witnessInfo(wi: WitnessInfo) «signal» phoneInfo(pi: Set<WitnessInfo>) «signal» phoneInfoOK() «signal» locationAndType(loc: Location, t: CrisisType) «signal» crisisInfo(ci: CrisisInfo) «signal» cInfoFinished()

Fig. 8. Class diagram: around System Request md: MissionDescription t: Type «signal» accept(r: Resource) 0..1 1 resource

Mission

1

0..* Change

Crisis

1

Resource description: MissionDescription change(c: Change): void generateReport(): Report

Employee request(md: MissionDescription, sender: Assignment): void 1..* 0..1 resource 1 1 0..1 «enumeration» «enumeration» Assignment Expertise Type md: MissionDescription intlRequest 0..* extlRequest 0..* sd: Employee exp: Expertise createAssigner(): void select(): Employee 0..* md 0..* md «signal» accept(r: Resource) 1 MissionDescription 1 asmnt md selected 0..* 0..* recommendations 1..* 1 1 Assigner Adviser m: MissionDescription missions: Set<Mission> e: Employee createMission(md: MissionDescription): void getRecommendations(): Set<MissionDescription> 0..1 0..* getResource(): Set Report close(): void finalReport «signal» selectMissions(md: Set<MissionDescription>) «signal» change(c: Change) «signal» newInfo(info: Info) «signal» report(r: Report) «signal» arrival(r: Resource) «signal» departure(r: Resource) External 1..*

Fig. 9. Class diagram: around Adviser

TaskInfo

Task

requestInfo(info: CrisisInfo) «signal» taskCreated() «signal» taskSucceeded() «signal» rcvTasks(t: Set) «signal» rcvChecklist(cl: Checklist)

SuperObserver

Employee

Checklist

MissionDescription

1 so

cl

1 md

RemoveObstacleMission

0..1 cInfo CrisisInfo

execute(): void findHospital(iInfo: InjuryInfo): Hospital «signal» leavingCrisisSite() «signal» victimDroppedOff() «signal» completed() «signal» injuryInfo(iInfo: InjuryInfo)

RescueMission

Fig. 10. Class diagram: around Mission

0..* tasks TaskDescription

SuperObserverMission currentTask: TaskDescription execute(): void generateChecklist(): Checklist generateTasks(): Set createTask(td: TaskDescription): void «signal» crisisInfo(info: CrisisInfo) «signal» task(t: TaskDescription) «signal» info(ti: TaskInfo) «signal» taskCreated() «signal» taskSucceeded() «signal» soLeft()

Mission assignments: Set requests: Set resources: Set execute(): void createAssignment(md: MissionDescription, e: Expertise): Assignment createRequest(md: MissionDescription, t: Type): Request resourceSufficient(): boolean «signal» arrival(r: Resource) «signal» departure(r: Resource)

HelicopterTransportMission

hpt

Hospital

1..* VictimHistory vid: String

searchHistory(vid: String): void

HospitalResourceSystem

toHospital(hpt: Hospital): void

FirstAidWorker

iInfo InjuryInfo vid: String

hrs 1..*

faw 1

Employee

MissionInfo

Report

244 M. H¨olzl, A. Knapp, and G. Zhang

Modeling the Car Crash Crisis Management System Using HiLA

245

the respective states of the CCCMS. A crisis is reported to an instance of class System which just represents the phase of waiting for an incident. A System then creates a Crisis. In this Crisis, the coordinator gathers the necessary crisis information: the witness reports and other crisis details. From this information, a Crisis creates an Adviser which supervises the remainder of the crisis resolution. An Adviser recommends appropriate missions to the coordinator, accepts a selection of these missions, creates Mission objects, allocates the necessary resources to each Mission, delegates mission execution to the resources, and collects changes to the mission. This division of labor has two driving factors: On the one hand, we take the stance that each use case has a primary interaction object; this accounts in particular for moving from System, the primary interaction object for the overall use case 1 “Resolve Crisis”, to Crisis that handles the included use case 2 “Capture Witness Report”. On the other hand, inside use cases several tasks have to be done in parallel, where the necessary degree of concurrency is not known up-front. This concurrency justifies, e.g., the creation of several Mission objects which all have to be executed in parallel. A domain model of the CCCMS can thus be derived from the use case descriptions using rather conventional techniques (see, e.g., [5,26]) obeying both the use case structuring and the required parallelism. The overall static structure, enriching the domain model by particular associations between the entities and operations as well as receptions for these entities, again follows straightforwardly from an analysis of the requirements;4 in both cases, it is mainly enough to concentrate on the primary (success) scenarios. We, therefore, forego a detailed account of the design steps of the static structure but merely show the resulting class diagrams in Fig. 8, Fig. 9, and Fig. 10. 3.2 Modeling the Main Success Scenario of Use Case 1 The main success scenario of use case 1 “Resolve Crisis” is modeled in the following, where we first cite the textual description of each step from the case study report [17] and then show how the step is modeled.

crisis / createCrisis() Idle

Fig. 11. Class System: base machine

The starting point of a crisis management process is System; its behavior is modeled in Fig. 11: a System is idle until it receives a crisis notification (event crisis), upon which it creates a Crisis. The Crisis instance then assumes the responsibility to manage the crisis by being the primary point of interaction with Coordinator, while the system is ready for other crisis notifications. It is the transition from System to Crisis where the handling of “Resolve Crisis” really starts. 4

As customary we do not make class constructors explicit.

246

M. H¨olzl, A. Knapp, and G. Zhang

1. Coordinator captures witness report (UC 2). We do not detail the behavior of use case 2 “Capture Witness Report” here, which is handled by Crisis; see Appendix A.1. In particular, after successful termination of this step, the information of Crisis will be up to date and an Adviser being attached to the Crisis for handling the remaining steps for crisis resolution will have taken over. 2. System recommends to Coordinator the missions that are to be executed based on the current information about the crisis and resources. 3. Coordinator selects one or more missions recommended by the system.

GenerateRecommendations do / recommendations = getRecommendations(System.getAvailableResources()))

SendRecommendations do / System.getCoordinator(). rcvRecommendations(recommendations) selectMissions(ml) / selected = ml CreateMissions do / ForEach md In selected missions.add(createMission(md)) change(c) / ForEach r In getResources() r.change(c)

WaitFor Changes

newInfo(info)

/ System.getCoordinator(). newInfo(info) report(r) / finalReport = r

Report Received close

Fig. 12. Class Adviser: base machine

For these steps, it is the Adviser who represents the System. The Adviser, see Fig. 12, generates a set of recommendations (in state GenerateRecommendations where we omit the details of how getRecommendations proceeds) and passes the recommendations on to the Coordinator (in state SendRecommendations). An event selectMissions causes the Adviser to store the descriptions of the selected missions in selected. In CreateMissions, it creates a new Mission for the description of each selected mission, and adds it to the set missions. (We abstract from the detail of how to decide whether a “super observer mission”, a “rescue mission”, a “helicopter transport mission”, or a “remove obstacle mission” should be created for a given mission description, but hide this in the operation createMission.) The base state machine for Mission is shown in Fig. 13. The next steps from 4 to 11 are executed for each mission in parallel:

Modeling the Car Crash Crisis Management System Using HiLA

247

«create» init(mdes: MissionDescription) / md = mdes CreateAssignments do / ForEach r in md.intlRequest assignments.add(createAssignment(md, r)) CreateRequests do / ForEach r in md.extlRequest requests.add(createRequest(md, r)) arrival(res) / resource.add(res) InExecution entry / System.getCoordinator().inExecution(this); arrival(res) / resources.add(res) Listening departure(res) / resources.remove(res) Execute entry / execute(); finished / System.getCoordinator(). finished(this)

Fig. 13. Class Mission: base machine

4. For each internal resource required by a selected mission, System assigns an internal resource (UC 3). 5. For each external resource required by a selected mission, System requests an external resource (UC 4). Each Mission creates first Assignment objects (in state CreateAssignments) and then Request objects (in state CreateRequests) to allocate internal and external resources, respectively. 6. Resource notifies System of arrival at mission location. 7. Resource executes the mission (UC 5). 8. Resource notifies System of departure from mission location. Upon arrival of a resource, the Mission starts execution (InExecution). The details of how a Mission executes (asynchronously calling its abstract method execute) depend on the type of Mission; see Appendices A.5 and A.6. Meanwhile, the mission also keeps track of the arrived and departed resources: in state Listening it waits for the resources to report their arrivals and departures, and updates its attribute resources accordingly. We suppose some resource sends (according to its mission description) to the Mission a finished signal to stop its execution when the mission is accomplished. 9. In parallel to steps 6–8, Coordinator receives updates on the mission status from System. Each Mission continuously informs the coordinator when it is in execution or finished. Note that the missions are now the representatives of the overall CCCMS, i.e., the System.

248

M. H¨olzl, A. Knapp, and G. Zhang

10. In parallel to steps 6–8, System informs Resource of relevant changes to mission/crisis information. This part of informational action is done by the Adviser (see Fig. 12). After creating the missions, the adviser gets ready for change notifications (WaitForChanges), and simply passes received change information onto the resources. 11. Resource submits the final mission report to System. If the Adviser receives a final report (by the event report), it stops waiting for change notifications, and waits for the coordinator to close this crisis resolution session. (We assume here that there is exactly one such final report, although there may be many resources.) 12. In parallel to steps 4–8, Coordinator receives new information about the crisis from System. When the Adviser receives any new information (by newInfo), it passes the information onto the coordinator. 13. Coordinator closes the file for the crisis resolution. After receiving the final report, the adviser waits for the coordinator to close the file (in state ReportReceived), and then terminates (final state). 3.3 Modeling the Extensions of Use Case 1 We model extensions of use case 1 “Resolve Crisis” by HiLA aspects. Several times we not only have to extend the behavioral part of the CCCMS, but also have to extend first the underlying static structure. As for the main success scenario, we start with a citation of the extension from the case study report [17] and then describe the model. In fact, most of the extensions require only rather simple aspects and we will make ample use of instantiations of the templates given in Fig. 5 for state machines and in Fig. 4 for static structures. We mainly use a tabular format for presenting these instantiations succinctly; in these tables x → y stands for bind x -> y. 1a. Coordinator is not logged in. 1a.1. Coordinator authenticates with System (UC 10). 1a.2. Use case continues with step 1.

Table 2. Use Case 1, extension 1a: Introducing a new operation to class System Template

Base Binding

IntroduceOperation Fig. 8 C → System Op → validateCoordinator(u: String, i: String): void

When the coordinator is not logged in, use case 10 has to be executed. We therefore add dynamic aspect CoordinatorLogin (see Fig. 14) and its static counterpart (see Tab. 2):

Modeling the Car Crash Crisis Management System Using HiLA

249

«aspect» CoordinatorLogin «pointcut» «before» Idle {coordinator == null} «advice» : Login Op −> validateCoordinator()

Fig. 14. Use Case 1, extension 1a: Ensuring the Coordinator is logged in

Before the Idle state of System becomes active, the system checks whether the coordinator is not logged in (coordinator == null). If this is the case, the Login sub-state machine is triggered and use case 10 “Authenticate User” (see App. A.9) steps in. 4a. Internal resource is not available after step 4. 4a.1. System requests an external resource instead (i.e., use continues in parallel with step 5). We have to expect a signal assignmentFailed in state Listening of class Mission (see Fig. 13) and to create a new request for an external resource on reception of this signal. We assume that for each kind of expertise there is a type of external resources as substitution, and call this type the externalType of the expertise. The necessary extensions can be completely covered by instantiating our templates, see Tab. 3. Table 3. Use Case 1, extension 4a: Template instantiations Template

Base

Binding

IntroduceOperation Fig. 10 C → Mission Op → signal assignmentFailed IntroduceOperation Fig. 10 C → Mission Op → createRequest(t: Type) IntroduceProperty Fig. 10 C → Mission Prop → externalType: Type[1] WhilstOnDoGoto

Fig. 13 Whilst → Listening On → assignmentFailed Do → createRequest(exp.externalType) Goto → Listening

5a. External resource is not available after step 5. 5a.1. Use continues in parallel with step 2. The fact that an external resource is unavailable is determined by the extensions of UC 4 “Request External Resource”, where two exceptional responses of the external resource are introduced: partial approval or denial, see App. A.3. We define an instance of aspect WhilstOnDoGoto for (the state machine of) the main success scenario of UC 4, which is given in Fig. 25, to inform the Mission and the System that the resource is unavailable (event denial), as well as to ask the Crisis object to create another Adviser

250

M. H¨olzl, A. Knapp, and G. Zhang

instance for the use case to “continue in parallel with step 2”. The new adviser will have the knowledge of the unavailable resource and will recommend different missions to the coordinator than the current one did, details are hidden in the static operation System.getAvailableResources. Table 4. Use Case 1, extension 5a: Template instantiations Template

Base

Binding

IntroduceOperation Fig. 10 C → Mission Op → signal resourceUnavailable IntroduceOperation Fig. 8 C → System Op → signal missionFailed(m: Mission) WhilstOnDoGoto

Fig. 25 Whilst → WaitForAcceptance On → denial Do → mission.resourceUnavailable; System.missionFailed(mission); md.adviser.crisis.createAdviser()

6a. System determines that the crisis location is unreachable by standard transportation means, but reachable by helicopter. 6a.1. System informs the Coordinator about the problem. 6a.2. Coordinator instructs System to execute a helicopter transport mission (UC 9). 6a.3. Use case continues with step 6. We introduce two additional transitions to Fig. 13 by instantiating WhilstOnDoGoto twice: one instance passes on the request to the coordinator (System.getCoordinator(). needHelicopter()) that the resource is requiring a helicopter (helicopterRequired) when the mission is waiting for the resources to arrive at the mission location (state WaitForArrival). The other reacts to the coordinator’s instruction startHelicopterMission and creates a new instance of HelicopterCall to start the helicopter transport mission. HelicopterCall hmd: MissionDescription createHelicopterMissionDescription(rs: Set): MissionDescription createMission(md: MissionDescription): Mission

(a) Class diagram «create» init (rs) / hmd = createHelicopterMissionDescription(rs); createMission(hmd)

(b) State machine Fig. 15. Class HelicopterCall

The class HelicopterCall is modeled in Fig. 15. A HelicopterCall objects create a mission description, in which a helicopter transport mission to transport a set of resources to a certain location is described, and creates a mission according to this description. The necessary signals and properties are introduced in Tab. 5. All the remaining extensions of UC 1 follow the same patterns. We summarize the necessary instantiations in Table 6. In particular, the fact that a resource is “unable to

Modeling the Car Crash Crisis Management System Using HiLA

251

Table 5. Use Case 1, extension 6a: Template instantiations Template

Base

IntroduceOperation Fig. 8 IntroduceOperation Fig. 10 IntroduceOperation Fig. 10

WhilstOnDoGoto

Fig. 10 Fig. 13

WhilstOnDoGoto

Fig. 13

IntroduceClass

Binding C → Coordinator Op → signal needHelicopter(r: Resource) C → Mission Op → signal helicopterRequired(r: Resource) C → Mission Op → signal startHelicopterMission(r: SetResource) C → HelicopterCall (Fig. 15) Whilst → WaitForArrival On → helicopterRequired(r) Do → System.getCoordinator().needHelicopter(r) Goto → WaitForArrival Whilst → WaitForArrival On → startHelicopterMission(r: SetResource) Do → createHelicopterCall(r) Goto → WaitForArrival

contact System” (in extensions 6b and 8a) is not explicitly modeled, we simply model the consequence of this fact, i.e., that “SuperObserver notifies System”. The use case continuing “in parallel with step 2” is modeled by asking the Crisis object to create a new Adviser. If parallelism is not required (like in extension 7b), we simply go to state RecommendMissions to generate new missions to recommend to the coordinator. Table 6. Use Case 1: other extensions Ext. Template Base 6b IntroduceOperation Fig. 9 WhilstOnDoGoto

6c

IntroduceOperation Fig. 9 WhilstOnDoGoto

7a

Fig. 12

IntroduceOperation Fig. 9 WhilstOnGoto

8a

Fig. 13

IntroduceOperation Fig. 9 WhilstOnDoGoto

7b

Fig. 13

Fig. 12

IntroduceOperation Fig. 9 WhilstOnDoGoto

Fig. 13

Binding C → c, c ∈ {Assignment, Request} Op →signal soNotifyArrival(r: Resource) Whilst → WaitForArrival On → soNotifyArrival(r) Do → arrived.add(r) Goto → OneArrived C → Resource Op →signal updateRequired() Whilst → WaitForArrival On → after t time Do → resource.updateRequired() Goto → WaitForArrival C → Adviser Op → signal moreMissionsRequired Whilst → WaitForChanges On → moreMissionsRequired Do → crisis.createAdviser() Goto → WaitForChanges C → Adviser Op → missionFailed(m: Mission) Whilst → WaitForChanges On → missionFailed(m) Goto → RecommendMissions C → c, c ∈ Assignment, Request} Op →signal soNotifyDeparture(r: Resource) Whilst → WaitForDeparture On → soNotifyDeparture(r) Do → left.add(r) Goto → OneLeft

252

M. H¨olzl, A. Knapp, and G. Zhang Table 6. (continued) Ext. 8b

Template

Base

Binding C → c, c ∈ {Assignment, Request} Op →signal delayReasonRequired WhilstOnDoGoto Fig. 13 Whilst → WaitForDeparture On → after t time Do → resource.delayReasonRequired() Goto → WaitForDeparture 9a, 12a IntroduceOperation Fig. 9 C → Adviser Op → signal changeRequired WhilstOnDoGoto Fig. 12 Whilst → WaitForChanges On → changeRequired Do → crisis.createAdviser Goto → Final 11a WhilstOnGoto Fig. 12 Whilst → WaitForChanges On → after t time Goto → Final IntroduceOperation Fig. 9

3.4 Modeling System Monitoring In a crisis management system like the CCCMS, monitoring is often indespensible. HiLA, with its support for aspect-oriented modeling of history-based and cross-statemachine features, provides valuable help in high-level modeling of system monitoring. In the following, we demonstrate how HiLA simplifies monitoring modeling by means of two examples, derived vom Use Case 9 “Execute Remove Obstacle Mission”. This use case is originally not specified in [17]. We concretize it for illustration purposes as follows: Use Case “Execute Remove Obstacle Mission” 1. Tow truck notifies System of arrival at mission location. 2. Tow truck informs System that the obstacle has been removed. 3. Use case ends in success. The static structure of the class RemoveObstacleMission is given in Fig. 16(a), the state machine for the above main success scenario in Fig. 16(b). The mission keeps track of the tow trucks currently on-site in towTrucks, and is either Operating or Waiting depending on if these are sufficient to pull the obstacle (towTrucks.size() >= towTrucksNeeded). History-based Monitoring. Monitoring features often require reactions on some special run of the system. HiLA’s history properties, in particular, their concatenations, can be very helpful for this purpose. For example, the aspect modeled in Fig. 17 introduces a monitoring feature to the base machine defined in Fig. 16(b): if a mission switches too frequently between Operating and Waiting resources are arriving and leaving too frequently to allow smooth execution of the allocated tasks. This indicates a problem and therefore the management system should be alerted. To achieve this, a history property a is defined as the number of the occurrences of the pattern containing four transitions between Operating and Waiting (as indicated

Modeling the Car Crash Crisis Management System Using HiLA Mission

253

External

RemoveObstacleMission towTrucksNeeded: int

towTrucks 0..*

TowTruck pull(): void «signal» finished()

(a) Class diagram [towTrucks.size() >= towTrucksNeeded]

Operating arrival(res) / towTrucks.add(res)

[else]

departure(res) / towTrucks.remove(res)

[towTrucks.size() >= towTrucksNeeded]

arrival(res) / towTrucks.add(res) [else]

Waiting departure(res) / towTrucks.remove(res)

(b) Base machine Fig. 16. Class RemoveObstacleMission

by the arrow between these states and the multiplicity 4). The pointcut of the aspects matches points of time just before Operating gets active; if such an occurrence can be found in the execution history (a>=1), an alarm is raised. «aspect» MissionAlarm «history» a=#

Operating

Waiting

[4]

«pointcut» «before» Operating {a >= 1} «advice» Alarm

Fig. 17. Aspect raising an alarm if the Mission switches very often between Operating and Waiting, to be applied to Fig. 16(b)

Cross-object Monitoring. There are also many situations where we are more concerned with the interaction between multiple objects than with the behavior of a single object. For example, it may be required that if there are too many tow trucks, an alarm should be raised. We first define a state machine for tow trucks, see Fig. 18: it first approaches to the obstacle to remove, and then pulls it. The static structure of tow trucks was given in Fig. 16(a). Now we model the monitoring feature. Because of the importance of synchronization and mutual exclusion behaviors, such as needed for monitoring tow trucks, HiLA supports them with a compact notation: Fig. 19(a) shows an aspect template that recognizes situations immediately before M or more objects of type C are about to be simultaneously in state A with the condition If being true. The condition If may be specific in each

254

M. H¨olzl, A. Knapp, and G. Zhang

Approaching

Pulling do / pull()

finished

Fig. 18. Class TowTruck: base machine

instance of M, which we call N. If this situation was about to happen, the transitions that would lead into the undesirable state are not taken and instead transitions into a new state Alarm are executed. The instantiations needed to implement the monitoring feature are given in Fig. 19(b). A: State C: Class N: String M: Integer «aspect» If: Boolean MutexObj «pointcut» «before» N:C A [M..*] {If} «advice» Alarm

(a) Template for coordinating multiple state machines

«aspect» : MutexObj A −> Pulling C −> TowTruck N −> tt M −> tt.towTrucksNeeded If −> tt.md.equals(this.md)

(b) Instantiations for monitoring tow trucks

Fig. 19. HiLA modeling of monitoring

There are several noteworthy points about these kinds of pointcuts: – The change into the undesirable state configuration with at least M active instances of type C may be caused by a single object or by multiple objects transitioning in a synchronized way; all these cases are covered by the pointcut in Fig. 19. – The semantics of this pointcut is rather difficult to express in traditional UML, even when using OCL constraints. OCL does not offer access to the event queue and therefore it is not possible to easily specify the situation that would happen if the next event was dispatched without aspects being applied. – While HiLA specifies the semantics of aspects between state machines it does not force a particular implementation strategy on users. For example, a simulated system might rely on knowledge of global state to check whether the pointcut applies, while a distributed system might use semaphores or other synchronization primitives to implement these constraints.

4 Validation of the Model The use of UML state machines for modeling reactive and interactive systems has led in particular to a considerable amount of work on their formal analysis, be it by theorem

Modeling the Car Crash Crisis Management System Using HiLA

255

proving (like PVS [3] or KIV [4]) or model checking (like UMC [12] or Hugo/RT [18]). Through its weaving process, HiLA inherits these formal methods: The application of aspects to a UML state machine results in another UML state machine which can be analyzed by standard tools. We exemplify the possible validation of (the weaving of) HiLA models by means of the (simplified) Use Case 10 “Authenticate User,” see Sect. 2.2, and the model checking component of Hugo/RT. According to our method, we start out with the base state machine in Fig. 2(b) that just reflects the basic login steps of the main success scenario: prompting for user id/password, accepting an input, and validating it; only a successful validation resulting in an ok signal is reflected in this model (in the following we ignore how the input provided by the user is stored). The Use Case extensions, represented by the aspects in Figs. 3 and 6, require the possibility of canceling the login procedure and the handling of a failing validation. In particular, it has to be possible to attempt to login at least, but also at most, three times unsuccessfully. Thus, the (woven) state machine should exhibit the following property, stated in linear temporal logic (LTL): F (inState(Prompt) and F (not inState(Prompt) and F (inState(Prompt) and F (not inState(Prompt) and F (inState(Prompt))))))

The temporal modality F is to be read as “eventually” or “it is the case in the future”; thus, it should be possible that the state machine first goes to state Prompt, then to some other state, then to Prompt again, then to some other state, and finally to Prompt again. Note that the property only refers to states in the base state machine. Obviously, the desired behavior is not possible in the original base state machine in Fig. 2(b), and this is also confirmed by Hugo/RT: Hugo/RT translates the state machine and the assertion into the input language of a back-end model checker, in this case SPIN [14]. SPIN then verifies that there is no possible run of the state machine with the prescribed sequence of being in Prompt and being not in Prompt.

cancel / failure() cancel / failure() Prompt

input(userid, pwd)

Validate

ok

fail

Fig. 20. Weaving result for sub-machine login from Fig. 2(b) and the aspects in Fig. 3(b), Fig. 6(a)

The result of weaving in the aspects in Fig. 3(b) and Fig. 6(a) is shown in Fig. 20. Canceling a login process and the failing of a login attempt are represented rather straightforwardly by additional transitions (triggered by cancel and fail). In this resulting state machine the property stated above is possible, as confirmed by Hugo/RT and SPIN; the following property, however, stating the possibility to try to login four times, is also satisfied:

256 F F F F

M. H¨olzl, A. Knapp, and G. Zhang (inState(Prompt) and F (not inState(Prompt) and (inState(Prompt) and F (not inState(Prompt) and (inState(Prompt) and F (not inState(Prompt) and (inState(Prompt))))))))

By employing a history property, the aspect in Fig. 6(b) ensures that at most three failing attempts in a row can be made. The weaving result is shown in Fig. 21. The history property f3 needs an additional counter variable v counting the failing validations in a row. This counter v is reset on canceling and also on a successful login. If three failing login attempts have been counted, the history property f3 is set, and on every possible entry into Prompt this history property is checked, prohibiting entry if it is set. Now, Hugo/RT and SPIN confirm that on the one hand it is possible to have three unsuccessful attempts to login, but no more attempts are then possible. cancel / failure() cancel / failure() BeforePrompt1 entry / gt1 = null; [f3] / gt1 = final; [else]

[gt1 == null]

Prompt

[gt1 == final]

input(userid, pwd)

[gt2 == null]

Validate ok entry / if (v < 3) v++; if (v == 3) f3 = true;

entry / v = 0;

[gt2 == final] BeforePrompt2 entry / gt2 = null; [f3] / gt2 = final;

fail

[else]

Fig. 21. Weaving result for sub-machine login from Fig. 2(b) and Figs. 3(b) and 6

It is in general not only useful to check that certain properties are indeed enforced by applying aspects, but also, conversely, that certain properties are being preserved. A rather simple example for preservation of properties is that the base state machine can terminate: F (inState(Final))

Hugo/RT and SPIN verify that this property also holds for the woven state machine (in fact this could also be checked by inspection; however, here more is true: all executions of the woven state machine inevitably lead to the Final state). As demonstrated for the authentication use case, we can currently only check the result of the weaving process; it would be desirable to compositionally validate the base state machine and the aspects in a dynamic fashion, without take into account the weaving result which can be rather complex and sometimes slightly unintuitive.

5 Evaluation of the HiLA Approach In the following sections, we will evaluate how well the HiLA approach to modeling worked for the CCCMS case study, which language features of HiLA we used in the modeling task, and how well they addressed the issues presented by the domain.

Modeling the Car Crash Crisis Management System Using HiLA

257

5.1 The HiLA Approach to Modeling In our opinion, one of the main advantages of aspect-oriented methods is that they allow a closer correspondence between requirements, model and executable code. Therefore, one important criterion for evaluating HiLA is how well our proposed approach could be applied to the requirements specified in the CCCMS case study and how directly individual state machines and aspects can be traced to use cases and use case extensions. Overall, we were pleasantly surprised how well our proposed approach worked for the CCCMS case study, in particular since the use cases were developed without special consideration for, and most likely even without knowledge of, HiLA. In general, each base state machine corresponds to a single use case and each use case extension is modeled by one or more aspects; each aspect belongs to a single use case, and the behavior of most use case extensions could be modeled with high-level aspects. This affords excellent traceability from requirements to design, albeit at a certain increase in the number of interacting model elements. In practical applications less strict adherence to this method might be advisable since it can reduce the composition complexity. Tool support for interactively switching on and off aspect weaving would be rather helpful. Many structural patterns repeatedly appear in different use case extensions of the CCCMS case study, e.g., “while waiting in some state S, if event e happens, do something not foreseen in the base use case.” Since HiLA provides a highly expressive template language for defining aspects, most of the extensions can be concisely summarized in tabular form (see Tables 2–6). We employ a regular naming scheme for templates and reuse these templates in most of our HiLA models. With some experience, it becomes therefore easy to see which behavioral modifications are required by the listed extensions. In effect, we use the template language of HiLA for tailoring aspects to different contexts and base state machines, and thereby achieve a high degree of aspect reuse. While modeling the CCCMS we sometimes had to deviate from the simple, systematic approach described in the previous paragraph. These deviations were necessary to accommodate the unbounded parallelism that is present throughout the case study: state machines themselves can only provide a statically fixed number of parallel regions, the dynamic “spawning” of new parallel regions cannot be represented in the state machine formalism. Therefore, we have to model dynamically created concurrent regions as concurrent objects; each object corresponds to one parallel “thread” of execution, the behavior of the thread is given by the object’s state machine. Note, however, that even in the case of unbounded parallelism HiLA still provides the necessary expressiveness of composition by featuring cross-object pointcuts, as demonstrated in Sect.3.4. This pattern for managing unbounded parallelism is the reason why the active part of the system is represented by different objects over time and, consequently, some base use cases are modeled by several state machines. For example, the single System instance creates a new instance of Crisis for every crisis report received by the system, the state machines of the concurrently executing Crisis instances are the responsibles for handling all simultaneously active crises. A similar situation presents itself for use case extensions. Except for a certain pattern of extensions for UC 1, each extension is described by a set of aspects that can be modeled without modification to the base state machine and without knowledge of other extensions. However, the case is not so simple for extensions 5a.1, 7a.1, 7b.1, 9a.1

258

M. H¨olzl, A. Knapp, and G. Zhang

and 12a.1 of UC 1: step 2 of the base use case (“system recommends missions to coordinator”) is specified as a straightforward, serial part of the main work flow and would therefore be modeled as part of the base state machine. In contrast to the sequential behavior of the base use case, the extensions specify “use case continues in parallel with step 2” and thereby lead to unbounded parallelism in the base state machine. We therefore have to model the recommendation, selection and change monitoring of missions in a new class Adviser and start a concurrent Adviser instance every time new missions have to be created. We point out one other potential pitfall that did not arise in the CCCMS scenario: some modeling shortcuts, such as replacing several linearly connected states with a single default transition, are not applicable when working with the proposed HiLA approach. For example, in UC 2, step 2a.3 (“system validates information received from the phone company”), which is represented by the transition from Validate to OK in Fig. 29, it is tempting not to use an explicit event phoneInfoOK and a transition into the subsequent state OK, but to model success by a completion transition from Validate to the join (as we are focusing on the main success scenario). However, indulging this temptation greatly complicates the aspect that introduces the additional possibility that the phone company does not match the witness info, as required by extension 5a. The success of an approach that relates behavioral design models as closely to use cases as HiLA depends heavily on the quality of the requirements analysis. The CCCMS illustrates that it is not necessary to develop requirement models in a specialized manner in order to profit from the abstraction mechanisms provided by the HiLA language: for large parts of the CCCMS the relation between HiLA models and requirements is immediately apparent, and even the necessary deviations from a “pure” approach exhibit a large degree of regularity and are easy to understand; the application of these patterns to other use cases is straightforward. Nevertheless, the correspondence between requirements and design models could have been further improved by writing use cases in a way that takes into account the limitations that state machines place on parallelism, i.e., by separating all situations exhibiting unrestricted parallelism into separate use cases. Another issue that arises when going from an informal description, such as use cases, to an executable formalism like state machines is that there may be imprecisions or possibilities for misunderstandings in the informal text. The CCCMS case study was for the most part free from such imprecisions, which shows the care that went into its creation. Nevertheless, there were a few isolated examples, where the descriptions of different use cases do not seem to match exactly, e.g., UC 1, extension 5a is triggered when an external “resource is not available after step 5.” UC 4, which is referenced by step 5, may either end “in success,” “in degraded success,” or “in failure.” It is, however, not made clear whether any of these conditions is the same as a resource not being available, and if so, how “degraded success” should be handled in UC 1.

5.2 The HiLA Language The requirements of the CCCMS could be satisfied with relatively basic language features of HiLA: we used a number of high-level aspects and aspect templates for state

Modeling the Car Crash Crisis Management System Using HiLA

259

machines, as well as some low-level aspects to either introduce new classes or to add operations or properties to existing classes. HiLA was developed with particular emphasis on concurrent systems that require complex synchronization and mutual exclusion [34]. The original CCCMS scenario relies on central control. We therefore supplemented one of the under-specified use cases, UC 9 “Execute Remove Obstacle Mission,” in order to demonstrate HiLA’s expressivity of composition, in particular its features to control and limit parallelism. In addition, the CCCMS exhibits only very simple history-based behavior; again HiLA is designed to efficiently cope with scenarios that require more sophisticated handling of execution histories and we have provided examples in Sect. 2.2 and 3.4. The HiLA language allows modelers to easily define templates that represent commonly used aspects for their scenarios. This can be seen in Sect. 3: roughly 80% of the aspects needed to model the use case extensions of the CCCMS can be expressed as instantiations of a small number of aspect templates. This expressivity of the modeling language is not without risks: it is tempting to overuse templates which can quickly lead to inscrutable models, in which (parameterized) aspects no longer correspond to single requirements, and where changes to a single aspect template may have unforeseen consequences throughout the model. Certain aspects, e.g., aspects that need to introduce new guards into existing transitions, can only be modeled by graph transformations of state machine models. No such example is necessary for the CCCMS, but had we modeled UC 2 as described above (in Sect. 5.1 on p. 258) such an introduction would have been necessary. Applying several graph transformations to a base state machine raises concerns about the confluence of the transformations and therefore the well-formedness of the final result [30]. This is a problem that our approach shares with all other approaches that make use of graph transformations. However, as can be seen in this case study, we can model many scenarios without resorting to this mechanism. Note that we use static aspects for class diagrams, but only to introduce new classes, methods or properties. In these cases, confluence is normally not problematic and well-formedness of the result easily checked. When only high-level aspects are applied to state machines, the problem becomes much less pressing: in most cases, the concurrent execution of advices reduces the number of spurious conflicts between aspects; in particular, there are no conflicts when several mutually independent aspects are applied to the same transition. Cases where several aspects interfere in HiLA generally represent a real conflict between different behaviors that has to be resolved by the modeler. Moreover, conflicting modifications of control flow by several concurrently active aspects can faithfully be detected at run time and a conservative static approximation can point out all potential conflicts of this kind at design time. Still, there are interactions which we currently do not detect reliably, e.g., consumption of an event that is deferred by the base state machine or another aspect. While these situations appear much less frequently than (spurious) interactions between graph transformations, it is our intention to improve the HiLA tools to detect and warn about this last class of indeterministic behavior. The HiLA language is amenable to testing and verification. Templates allow us to test the behavior of aspects by applying them to simple base state machines, and by applying compositions of several aspects simultaneously. Monitors, see Sect. 3.4, can be used to

260

M. H¨olzl, A. Knapp, and G. Zhang

specify test goals in the same language in which the model is written. Moreover, since HiLA is integrated with the Hugo/RT model translation tools for state machines, it is straightforward to apply model-checking techniques to HiLA models, and therefore to validate models against behavioral specifications. Currently, this is only possible after weaving is done and therefore not compositional. Independent verification of individual aspects remains a challenge and is a subject for future research. HiLA can easily be extended, for example, by allowing the modeler to distinguish between applying advice at the start of the transition execution, i.e., before the effect of the transition takes place, or at the end of the transition (after its effect). Similarly, more complex annotations than goto can be defined for final states. However, these extensions potentially complicate the weaving process and the semantics of aspects; since we have not yet found it necessary to use them in practical applications, we have refrained from adding them to the language.

6 Related Work The idea of high-level aspects was first seen in dynamic aspect-oriented programming languages such as JAsCo [28] and Object Teams [13]. Using history properties to quantify over the execution history is reminiscent to the trace aspects of Arachne [9]. Considering state machines, aspects for Mealy automata are propsed by [2]. In comparison, the weaving algorithm of HiLA is much more elaborate, mainly due to the richer language constructs of the UML. Because of the wider acceptance of the UML, our approach is also more tightly connected to common practice. State-based aspects in reactive systems are also supported by JPDD [25] and Telelogic TAU [35], both of which do not rely soly on graph transformation, but facilitate specification of high-level pointcuts in flat state machines. In comparison, HiLA was designed to be applicable to parallel and hierarchical UML state machines, where in general concurrent threads are contained, and concerns such as thread synchronization increase the difficulty of correct and modular modeling. We believe that HiLA provides valuable help to address these problems. Addressing the complete UML, Theme/UML [7] models different features in different models (called themes) and uses UML templates to define common behavior of several themes. General composers such as GeKo [21] and MATA [29] can be used for weaving. The aspects of these approaches are low level, which means modeling nontrivial features often requires rather complex aspects, and comprehension of the aspects amounts to understanding the weaving result. Aspect interference is an intrinsic problem of aspect-oriented techniques. It has been addressed in a large amount of publications, for an overview see [1,19]. Notations of precedence declaration are proposed in, e.g., [16,22,24,35]. Techniques to detect interference proposed so far include detecting shared fields addressed by read and write operations [27], a formal foundation of AOP languages using Conditional Program Transformations [19], and graph transformations [1,30]. These approaches focus on sequential programming languages. In comparison, HiLA exploits the concurrency of state machines and weaves aspects into parallel regions to solve the problem of join points being changed by other aspects or the result of weaving depending on the weaving order.

Modeling the Car Crash Crisis Management System Using HiLA

261

Weaving into parallel constructs is also proposed in [8], where an approach to concurrent event-based AOP (CEAOP) is defined. Concurrent aspects can be translated into Finite Sequential Processes and checked with the LTSA model-checker. Many similarities exist between CEAOP and the work presented in this paper; however, the two approaches take complementary viewpoints in the sense that our work is primarily concerned with a state-based view of AOP that allows, e.g., the definition of mutual exclusion in state machines, whereas the CEAOP is mostly concerned with aspects over event sequences. CEAOP provides operators to combine aspects, e.g., by executing different aspects in sequence or in parallel; our approach is more restricted since our aspects are always executed in parallel. Furthermore, pointcuts in CEAOP are actually similar to sequences of pointcuts according to the usual definition, and pieces of advice are executed at different points of this sequence. This makes it easy to define stateful aspects. While our history mechanism can also be used to define these kinds of aspects, the definition has to be given in several parts and is more cumbersome than in CEAOP. On the other hand, the history mechanism in our approach can take into account values of context variables which significantly increases the expressive power; it seems that this possibility does currently not exist in CEAOP. Besides crisis management systems, HiLA was also applied to model adaptive web applications and computer games, see [32,33].

7 Conclusions We have presented the HiLA approach for aspect-oriented modeling and applied it to the CCCMS case study. The expressiveness of HiLA has allowed us to methodologically transform the use case descriptions of the CCCMS into state machines; each main success scenario is modeled by a base state machine, each extension of this scenario is represented by a set of aspects. This method affords a high degree of traceability from the resulting model to the requirements. Additionally, since we rely exclusively on state machine models for the behavior, we can apply well-known formal methods, like model checking, for validating system properties. Acknowledgements. We thank the reviewers for their insightful and thorough comments. This work has been partially sponsored by the DFG project M AEWA (WI 841/7– 2) and the EU project S ENSORIA (IST-2 005-016004).

References 1. Aksit, M., Rensink, A., Staijen, T.: A Graph-Transformation-Based Simulation Approach for Analysing Aspect Interference on Shared Join Points. In: Proc. 8th Int. Conf. AspectOriented Software Development (AOSD 2009), pp. 39–50 (2009) 2. Altisen, K., Maraninchi, F., Stauch, D.: Aspect-Oriented Programming for Reactive Systems: Larissa, a Proposal in the Synchronous Framework. Sci. Comp. Prog. 63(3), 297–320 (2006) 3. Arons, T., Hooman, J., Kugler, H.-J., Pnueli, A., van der Zwaag, M.B.: Deductive Verification of UML Models in TLPVS. In: Baar, T., Strohmeier, A., Moreira, A., Mellor, S.J. (eds.) UML 2004. LNCS, vol. 3273, pp. 335–349. Springer, Heidelberg (2004)

262

M. H¨olzl, A. Knapp, and G. Zhang

4. Balser, M., B¨aumler, S., Knapp, A., Reif, W., Thums, A.: Interactive Verification of UML State Machines. In: Davies, J., Schulte, W., Barnett, M. (eds.) ICFEM 2004. LNCS, vol. 3308, pp. 434–448. Springer, Heidelberg (2004) 5. Blaha, M., Rumbaugh, J.: Object-Oriented Modeling and Design with UML, 2nd edn. Prentice Hall, Englewood Cliffs (2004) 6. Booch, G., Jacobson, I., Rumbaugh, J.: The Unified Modeling Language User Guide, 2nd edn. Addison-Wesley, Reading (2005) 7. Clarke, S., Baniassad, E.: Aspect-Oriented Analysis and Design. Addison-Wesley, Reading (2005) 8. Douence, R., Le Botlan, D., Noy´e, J., S¨udholt, M.: Concurrent Aspects. In: Proc. 5th Int. Conf. Generative Programming and Component Engineering (GPCE 2006), pp. 79–88. ACM, New York (2006) 9. Douence, R., Fritz, T., Loriant, N., Menaud, J.-M., S´egura-Devillechaise, M., S¨udholt, M.: An Expressive Aspect Language for System Applications with Arachne. In: Mezini, Tarr (eds.) [20], pp. 27–38 10. Drusinsky, D.: Modeling and Verification Using UML Statecharts. Elsevier, Amsterdam (2006) 11. Engels, G., Opdyke, B., Schmidt, D.C., Weil, F. (eds.): MODELS 2007. LNCS, vol. 4735. Springer, Heidelberg (2007) 12. Gnesi, S.: Formal Specification and Verification of Complex Systems. In: Proc. 8th Int. Wsh. Formal Methods for Industrial Critical Systems (FMICS 2003). Electr. Notes Theor. Comput. Sci., vol. 80 (2003) 13. Herrmann, S.: Object Teams: Improving Modularity for Crosscutting Collaborations. In: Aksit, M., Mezini, M., Unland, R. (eds.) NODe 2002. LNCS, vol. 2591, pp. 248–264. Springer, Heidelberg (2003) 14. Holzmann, G.J.: The SPIN Model Checker: Primer and Reference Manual. Addison-Wesley, Reading (2003) 15. Jacobson, I., Ng, P.-W.: Aspect-Oriented Software Development with Use Cases. AddisonWesley, Reading (2004) 16. Kienzle, J., G´elineau, S.: AO Challenge — Implementing the ACID Properties for Transactional Objects. In: Filman, R.E. (ed.) Proc. 5th Int. Conf. Aspect-Oriented Software Development (AOSD 2006), pp. 202–213. ACM, New York (2006) 17. Kienzle, J., Guelfi, N., Mustafiz, S.: Crisis Management Systems: A Case Study for AspectOriented Modeling. Trans. Aspect-Oriented Software Development (TAOSD) 7, 1–22 (2010) 18. Knapp, A., Merz, S., Rauh, C.: Model Checking Timed UML State Machines and Collaborations. In: Damm, W., Olderog, E.-R. (eds.) FTRTFT 2002. LNCS, vol. 2469, pp. 395–416. Springer, Heidelberg (2002) 19. Kniesel, G.: Detection and Resolution of Weaving Interactions. In: Rashid, A., Ossher, H. (eds.) Transactions on Aspect-Oriented Software Development V. LNCS, vol. 5490, pp. 135– 186. Springer, Heidelberg (2009) 20. Mezini, M., Tarr, P.L. (eds.): Proc. 4th Int. Conf. Aspect-Oriented Software Development (AOSD 2005). ACM, New York (2005) 21. Morin, B., Klein, J., Barais, O., J´ez´equel, J.-M.: A Generic Weaver for Supporting Product Lines. In: Proc. 13th Int. Wsh. Software Architectures and Mobility (EA 2008), pp. 11–18. ACM, New York (2008) 22. Nagy, I., Bergmans, L., Aksit, M.: Composing Aspects at Shared Join Points. In: Hirschfeld, R., Kowalczyk, R., Polze, A., Weske, M. (eds.) Proc. Net.ObjectDays (NODe 2005). Lect. Notes Informatics, vol. 69, pp. 19–38. Gesellschaft f¨ur Informatik (2005) 23. Object Management Group. OMG Unified Modeling Language (OMG UML), Superstructure, Version 2.2. OMG Available Specification, OMG (2009), http://www.omg.org/spec/UML/2.2/Superstructure

Modeling the Car Crash Crisis Management System Using HiLA

263

24. Reddy, Y.R., Ghosh, S., France, R.B., Straw, G., Bieman, J.M., McEachen, N., Song, E., Georg, G.: Directives for Composing Aspect-Oriented Design Class Models. In: Rashid, A., Aksit, M. (eds.) Transactions on Aspect-Oriented Software Development I. LNCS, vol. 3880, pp. 75–105. Springer, Heidelberg (2006) 25. S´anchez, P., Fuentes, L., Stein, D., Hanenberg, S., Unland, R.: Aspect-Oriented Model Weaving Beyond Model Composition and Model Transformation. In: Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., V¨olter, M. (eds.) Proc. 11th Int. Conf. Model Driven Engineering Languages and Systems (MoDELS 2008). LNCS, vol. 5301, pp. 766–781. Springer, Heidelberg (2008) 26. Sommerville, I.: Software Engineering, 8th edn. Addison-Wesley, Reading (2007) 27. St¨orzer, M., Forster, F., Sterr, R.: Detecting Precedence-Related Advice Interference. In: Proc. 21st IEEE/ACM Int. Conf. Automated Software Engineering (ASE 2006), pp. 317– 322. IEEE, Los Alamitos (2006) 28. Vanderperren, W., Suv´ee, D., Verheecke, B., Cibr´an, M.A., Jonckers, V.: Adaptive Programming in JAsCo. In: Mezini, Tarr (eds.) [20], pp. 75–86 29. Whittle, J., Jayaraman, P.K.: MATA: A Tool for Aspect-Oriented Modeling based on Graph Transformation. In: Proc. 11th Int. Wsh. Aspect-Oriented Modeling, AOM@MoDELS 2007 (2007) 30. Whittle, J., Moreira, A., Ara´ujo, J., Jayaraman, P.K., Elkhodary, A.M., Rabbi, R.: An Expressive Aspect Composition Language for UML State Diagrams. In: Engels, et al. (eds.) [11], pp. 514–528 31. Zhang, G.: Towards Aspect-Oriented Class Diagrams. In: Proc. 12th Asia-Pacific Software Engineering Conf (APSEC 2005), pp. 763–768. IEEE, Los Alamitos (2005) 32. Zhang, G.: Aspect-Oriented Modeling of Adaptive Web Applications with HiLA. In: Kotsis, G., Taniar, D., Pardede, E., Khalil, I. (eds.) Proc. 7th Int. Conf. Advances in Mobile Computing & Multimedia (MoMM 2009), pp. 331–335. ACM, New York (2009) 33. Zhang, G., H¨olzl, M.: HiLA: High-Level Aspects for UML State Machines. In: 14th Wsh. Aspect-Oriented Modeling (AOM@MoDELS 2009), Denver (2009) 34. Zhang, G., H¨olzl, M.M., Knapp, A.: Enhancing UML State Machines with Aspects. In: Engels, et al. (eds.) [11], pp. 529–543 35. Zhang, J., Cottenier, T., van den Berg, A., Gray, J.: Aspect Composition in the Motorola Aspect-Oriented Modeling Weaver. Journal of Object Technology 6(7), 89–108 (2007)

264

M. H¨olzl, A. Knapp, and G. Zhang

A Remaining Use Cases of the CCCMS A.1 Use Case 2: Capture Witness Report Main success scenario. Modeled in Fig. 22. The phone information of the witness as found by the phone company is stored in pInfo. It is then compared with witnessInfo (hidden in the operation validateInfo). State Validate is only left when validateInfo determines that the phone information is OK (event phoneInfoOK). The transitions to the join vertex and then to AssignLevel are only enabled when both OK and CrisisInfoReceived are active. Table 7. Use Case 2: extensions Ext. Template Base 1a, 2a IntroduceOperation Fig. 8

3a

Binding C → Crisis Op → signal disconnect WhilstOnGoto Fig. 22 Whilst → s, s ∈ {CollectInfo, WaitForLocationAndType} On → disconnect Goto → Final IntroduceOperation Fig. 8 C → SurveillanceSystem Op → static covers(loc: Location): Boolean IntroduceOperation Fig. 8 C → Coordinator Op → rcvVideoFeed(vf: VideoFeed): void AfterIfDo Fig. 22 After → CreateChecklist If → SurveillanceSystem.covers(location) Do → System.getCoordinator.rcvVideoFeed(

4a

IntroduceOperation Fig. 8

5a

5b

SurveillanceSystem.createVideoFeed(location)) C → Crisis Op → signal disconnect WhilstOnGoto Fig. 22 Whilst → CollectCrisisInfo On → disconnect Goto → CrisisInfoReceived IntroduceOperation Fig. 8 C → Crisis Op → signal phoneInfoWrong WhilstOnGoto Fig. 22 Whilst → Validate On → phoneInfoWrong Goto → Final IntroduceOperation Fig. 8 C → Crisis Op → signal s, s ∈ {fake, deny} WhilstOnGoto Fig. 22 Whilst → GatherInfo On → s, s ∈ {fake, deny} Goto → Final

Extensions. The extensions of Use Case 2 are modeled by instantiating the aspect templates given in Figs. 4 and 5. The bindings are given in Table 7. We model that “Coordinator cannot confirm the situation” by an additional signal deny. Moreover, we point out that multiple instances of IntroduceOperation are defined to extend class Crisis by signal disconnect (1a, 2a, 4a). The reason is that we propose to model the extensions separately from each other, and while modeling one extension we therefore assume no knowledge of other extensions. According to our definition of transformation aspects (see [31]), only one instance of the signal is actually introduced to the class.

CollectInfo

wInfoFinished

witnessInfo(wi) / addWitnessInfo(wi)

GatherInfo

locationAndType(loc, t) / location = loc; type = t

phoneInfo(info) Validate / pInfo = info do / validateInfo(pInfo)

Fig. 22. Class Crisis: base machine

cInfoFinished

/ System.getCoordinator().rcvChecklist(cl)

crisisInfo(info) / addCrisisInfo(info)

CollectCrisis Info

crisisInfo(info) / addCrisisInfo(info)

WaitFor CrisisInfo

WaitFor LocationAndType

ContactPhoneCompany do / System.getPhoneCompany(). findInfo(wInfo) OK

CrisisInfo Received

CreateChecklist do / cl = createChecklist()

phoneInfoOK

CreateAdviser do / createAdviser()

AssignLevel do / active = true; setEmergencyLevel()

Modeling the Car Crash Crisis Management System Using HiLA 265

266

M. H¨olzl, A. Knapp, and G. Zhang

A.2 Use Case 3: Assign Internal Resource Main success scenario. Modeled in Fig. 23. We assume that all “internal resources” are employees. The Assignment object (see Fig. 23(a)) passes on the mission description, received from the adviser for its own creation, along with references of the most appropriate employee (selected in SelectEmployee), and of this Assignment object itself (this), to an Assigner object, which then (see Fig. 23(b)) sends a request to the employee and waits for acceptance (signal accept).

«create» init(md, em, an) / m = md; e = em; a = an

«create» init(description, expertise) / md = description; exp = expertise; resource = null; SelectEmployee do / sd = select(exp) / createAssigner(md, sd, this)

(a) Class Assignment: base machine

SendRequest do / e.request(m, a)

WaitFor Acceptance accept(r) / if (asmnt.resource == null) asmnt.resource = r

(b) Class Assigner, base machine

Fig. 23. Classes for allocation of internal resources

Extensions. The feature “in very urgent cases, steps 1 and 2 can be performed for several CMSEmployees concurrently, until one of the contacted employees accepts the mission” is not formulated as an extension in [17]. However, we consider this an exceptional feature and decided to model it in a separate aspect. This feature is modeled by the aspect Urgent (Fig. 24(a)), which alternates the “normal” behavior specified in the main success scenario. If the emergency level is greater than 10, which we assume is the threshold for the crisis to be “very urgent”, then, instead of selecting the most appropriate employee (before SelectEmployee), we create an Assigner object for each employee with the desired expertise (exp.employees). Each of these assigners then sends in parallel a request to “its” employee. Extension 1a is modeled by the aspect in Fig. 24(b). Again, we instantiate the template Login given in Fig. 29 on page 271. The needed operations are introduced by instantiations of aspect templates as given in Table 8. The extensions 1b and 2a are modeled by instantiating the template given in Fig. 24(c) with T -> t, t ∈ {reject, after t time}. When the assigner is waiting for acceptance, and receives one of these two signals, then it tries to find a backup (getBackup) for the resource it wanted. If one can be found (bp != null), then another assigner is created to contact the backup, otherwise the use case ends in failure. The extension of the static structure is also given in Table 8.

Modeling the Car Crash Crisis Management System Using HiLA

«aspect» Urgent «pointcut»

«aspect» EmployeeLogin «pointcut»

«before» Select Employee

«before» SendRequest {!e.isLoggedIn()}

{md.adviser.crisis.emergencyLevel > 10} «advice» CreateSelector do / ForEach e in exp.employees createAssigner(md, e, this)

«advice» : Login Op −> validateEmployee()

(a) Extension 0

(b) Extension 1a «aspect» AssignmentFailed

«pointcut»

T

«whilst» {trigger = T} WaitFor Acceptance

«advice» CallBackup do / bp = getbackup(e)

goto Final [bp != null] / asmnt.createAssigner(m, bp, asmnt) [else] / failure = true goto Final

(c) Extensions 1b and 2a: bind T -> t, t ∈ {reject, timeout} Fig. 24. Use Case 3

Table 8. Introducing static elements for modeling Use Case 3 Ext. 1a

Template IntroduceProperty IntroduceProperty IntroduceOperation IntroduceOperation IntroduceOperation

1b, 2a IntroduceProperty IntroduceOperation IntroduceOperation

Base Binding Fig. 9 C → Assigner Prop → u: String Fig. 9 C → Assigner Prop → p: String Fig. 9 C → Assigner Op → signal input(u: String, i: String) Fig. 9 C → Assigner Op → validateEmployee(u: String, i: String): void Fig. 9 C → Employee Op → isLoggedIn(): Boolean Fig. 9 C → Assigner Prop → failure: Boolean = false Fig. 9 C → Assigner Op → getBackup(e: Employee): Employee Fig. 9 C → Assigner Op → signal reject

267

268

M. H¨olzl, A. Knapp, and G. Zhang

A.3 Use Case 4: Request External Resource Main success scenario. Modeled in Fig. 25. The Request object passes the mission description, the desired type of external resource, as well as a reference (this), to the ExternalRequestSystem (ERS), and waits for some resource to accept.

«create» init(description, type) / md = description; t = type; ERS.request(md, t, this); WaitFor Acceptance accept(r) / resource = r

Fig. 25. Class Request: base machine

Extensions. Again, the extensions are modeled with instances of aspect templates (see Figs. 4 and 5) with bindings defined in Table 9. Exit codes are introduced to indicate different results of this use case; two WhilstOnDoGoto aspects set the right exit code upon the corresponding response from the resource. Table 9. Use Case 4: extensions Ext. Template 2a, 2b IntroduceClass

«enumeration» ExitCode success degradedSuccess failure

Base Fig. 9 Fig. 9

Binding C → ExitCode = success IntroduceProperty C → Request Prop → exitCode: ExitCode IntroduceOperation Fig. 9 C → Assignment Op → s, s ∈ { signal partialApproval, signal denial } WhilstOnDoGoto Fig. 25 Whilst → WaitForAcceptance On → partialApproval Do → exitCode = degradedApproval Goto → Final WhilstOnDoGoto Fig. 25 Whilst → WaitForAcceptance On → denial Do → exitCode = failure Goto → Final

A.4 Use Case 5: Execute Mission Not modeled, for this is an abstract use case. A.5 Use Case 6: Execute SuperObserver Mission Main success scenario. Modeled in Fig. 26. In the use case description [17], SuperObserver is supposed to select missions to execute. Since the term Mission is already in

Modeling the Car Crash Crisis Management System Using HiLA

269

use, we assume that it is (sub-)tasks that should be suggested to and then selected by SuperObserver for execution.

SendChecklist do / cl = getChecklist() so.rcvCheckList(cl) crisisInfo(info) / cInfo = info GenerateTasks do / tasks = generateTasks()

RequestInfo do / so.requestInfo(currentTask)

/ so.rcvTasks(tasks)

info

WaitFor task(t) Notification / currentTask = t

CreateTask do / task = createTask() taskCreated / so.taskCreated() WaitFor Feedback success / so.taskSucceeded() Task task(t) Completed / currentTask = t soLeft

Fig. 26. SuperObserverMission.execute: base machine

«aspect» «pointcut»

«whilst» {trigger = creationFailed} Create Task

«advice» [replacementPossible()]

[else]

GenerateReplacement do / tasks = replace() so.rcvTasks(tasks);

goto WaitForNotification

SuggestNationalCrisisCenter do / so.suggestNCC

Fig. 27. Use Case 6, extensions 7a/b

Extensions. Extensions 7a and 7b are modeled in Fig. 27 with introduction of static elements as defined in Table 10. Extension 8a is modeled by the instantiations only, also given in Table 10.

270

M. H¨olzl, A. Knapp, and G. Zhang Table 10. Use Case 6: Introducing static elements used by the dynamic aspects

Ext. Template Base Binding 7a, 7b IntroduceOperation Fig. 10 C → SuperObserverMission Op → signal creationFailed() IntroduceOperation Fig. 10 C → SuperObserverMission Op → replacementPossible(): Boolean IntroduceOperation Fig. 10 C → SuperObserverMission Op → replace(): Set IntroduceOperation Fig. 10 C → SuperObserver Op → signal suggestNCC 8a IntroduceOperation Fig. 10 C → SuperObserverMission Op → signal taskFailed(t: Task) IntroduceOperation Fig. 10 C → SuperObserver Op → signal taskFailed(t: Task) IntroduceOperation Fig. 8 C → Coordinator Op → signal taskFailed(t: Task) WhilstOnDoGoto Fig. 26 Whilst → WaitForFeedback On → taskFailed(task) Do → so.taskFailed(task); System.getCoordinator.taskFailed(task) Goto → TaskCompleted

A.6 Use Case 7: Execute Rescue Mission Main success scenario. Modeled in Fig. 28. The “optional” steps that FirstAidWorker determines victim’s identity upon which the system requests the victim’s medical history information from all connected HospitalResourceSystems are modeled by the iInfo.vid != null branch after WaitForInjuryInfo, where vid stands for victim ID. Extensions. The (only) extension is modeled by the instantiations of aspect templates as described in Table 11. Table 11. Use Case 7, extension 4a Template

Base

Binding

IntroduceOperation Fig. 10 C → FirstAidWorker Op → victimHistory(his: History) IntroduceOperation Fig. 10 C → RescueMission Op → signal victimHistory(his: History) WhilstOnDoGoto

Fig. 28 Whilst → FindBestHospital On → victimHistory(his) Do → faw.victimHistory(his) Goto → FindBestHospital

A.7 Use Case 8: Execute Helicopter Transport Mission Not modeled, since its scenarios are not described in the case study. A.8 Use Case 9: Execute Remove Obstacle Mission Originally not specified in [17], a sample description of the use case and its design are given in Sect. 3.4.

Modeling the Car Crash Crisis Management System Using HiLA

271

WaitFor InjuryInfo injuryInfo(iInfo) [iInfo.vid == null]

[iInfo.vid != null] / ForEach h In hrs h.getHistory(iInfo.vid)

FindBestHospital do / hpt = findHospital(iInfo) / faw.toHospital(hpt) WaitFor Departure leavingCrisisSite WaitFor DropOff victimDroppedOff() WaitFor Completion completed()

Fig. 28. RescueMission.execute: base machine

A.9 Use Case 10: Authenticate User The full model of use case 10 (see Fig. 29 and Tab. 12) is similar to the simplified model described in Sect. 2.2. However, as the use case is used twice (in use cases 1 and 3), the login procedure is rendered as a sub-state machine that takes the validation procedure as template parameter. In particular, the extensions 2a and 3a are covered by Figs. 3 and 6. Op

Login input(userid, pwd) Validate Prompt / u = userid; p = pwd do / Op

ok

Fig. 29. Base sub-state machine for Login Table 12. Use Case 10: Introducing new operations to class System Template

Base Binding

IntroduceOperation Fig. 8 C → System Op → signal input(u: String, i: String) IntroduceOperation Fig. 8 C → System Op → signal ok

Aspect-Oriented Design with Reusable Aspect Models Jörg Kienzle1 , Wisam Al Abed1 , Franck Fleurey2 , Jean-Marc Jézéquel3 , and Jacques Klein4 1

4

School of Computer Science, McGill University, Canada 2 SINTEF IKT, Oslo, Norway 3 INRIA, Centre Rennes - Bretagne Atlantique, Rennes, France CRP Gabriel Lippmann and University of Luxembourg, Luxembourg

Abstract. The idea behind Aspect-Oriented Modeling (AOM) is to apply aspect-oriented techniques to (software) models with the aim of modularizing crosscutting concerns. This can be done within different modeling notations, at different levels of abstraction, and at different moments during the software development process. This paper demonstrates the applicability of AOM during the software design phase by presenting parts of an aspect-oriented design of a crisis management system. The design solution proposed in this paper is based on the Reusable Aspect Models (RAM) approach, which allows a modeler to express the structure and behavior of a complex system using class, state and sequence diagrams encapsulated in several aspect models. The paper describes how the model of the “create mission” functionality of the server backend can be decomposed into 23 inter-dependent aspect models. The presentation of the design is followed by a discussion on the lessons learned from the case study. Next, RAM is compared to 8 other AOM approaches according to 6 criteria: language, concern composition, asymmetric and symmetric composition, maturity, and tool support. To conclude the paper, a discussion section points out the features of RAM that specifically support reuse.

1

Introduction

The idea behind Aspect-Oriented Modeling (AOM) is to apply aspect-oriented techniques to (software) models with the aim of modularizing crosscutting concerns. This can be done within different modeling notations, at different levels of abstraction, and at different moments during the software development process. In [1,2,3], we have proposed Reusable Aspect Models (RAM), an aspectoriented multi-view modeling approach that 1) integrates existing class diagram, sequence diagram and state diagram AOM techniques into one coherent approach; 2) packages aspect models for easy and flexible reuse; 3) supports the creation of complex aspect dependency chains; 4) performs elaborate consistency checks to verify correct aspect composition and reuse; 5) defines a detailed weaving algorithm that resolves aspect dependencies to generate independent aspect models and ultimately the final application model. S. Katz et al. (Eds.): Transactions on AOSD VII, LNCS 6210, pp. 272–320, 2010. c Springer-Verlag Berlin Heidelberg 2010 

Aspect-Oriented Design with Reusable Aspect Models

273

So far we have applied RAM only to one big case study: AspectOptima [4,5,6], a product line of transaction middleware implementations consisting of 17 aspects. From previous work we had acquired in-depth knowledge in object-oriented implementations of transaction middleware, and as a result the identification of the crosscutting concerns in transaction middleware was therefore pretty straightforward. Nevertheless, this first experience has provided us with many insights on AOM, and we evolved RAM to be able to deal with complex aspect dependencies and interactions in a way that does not compromise the reusability of the individual aspect models. In [7], the authors propose a common case study, a crisis management system (CMS), to evaluate the strength and weaknesses of different AOM approaches. In this paper, we present how we applied RAM to design parts of the functionality of the crisis management system backend according to the requirements listed in [7]. The design solution shown here is useful for software developers who want to learn about aspect-oriented design in general, as well as for developers who want to understand the details of the RAM approach. Please note that the complete models of all aspects involved in this case study can be downloaded from [8]. The outline of the paper is as follows. Section 2 presents a set of selected models of our design of the CMS backend, while at the same time explaining the main concepts of RAM. The design is split into resource management, communication, workflow, logistics, and “base design”, each presented in a separate subsection. Section 3 discusses the insights we gained when applying RAM to the CMS. Section 4 presents an in-depth comparison of RAM to 8 other AOM approaches based on 6 criteria. Section 5 comments on how RAM facilitates aspect model reuse, and the last section draws some conclusions.

2

Crisis Management System Design

In this section, we present the aspect-oriented design of the backend of the car crash crisis management system (CCCMS) using the aspect-oriented modeling approach Reusable Aspect Models (RAM) [1,2,3]. Just like in the original document that describes the CCCMS, we are focusing on the design of the create mission functionality that is executed at the CCCMS server backend. The create mission functionality provided by the backend is triggered in the following context: for every crisis, at least one super observer, an expert in car crashes, is assigned to the scene to observe the emergency situation and identify the tasks necessary to cope with the crisis. These tasks are called missions. In [7], the super observer’s activities are described in use case 6. The super observer sends the mission requests to the backend (use case 6, step 4), which has to allocate suitable resources (humans, vehicles, etc.) to fulfill the mission (use case 1, step 4). Once appropriate resources have been identified, the involved workers have to be contacted with the mission assignment (use case 3, step 1). The object-oriented design of the create mission functionality is presented in [7] in Fig. 8.

274

J. Kienzle et al.

In RAM, any concern or functionality that is reusable is modeled in an aspect model. This is different from asymmetric aspect techniques, which usually only encapsulate crosscutting concerns within aspects. The RAM way of looking at this is that even if an aspect is only used once in the same application, it is (or can be) reused again in other applications. In this case, the structure and behavior models of a reusable aspect cut across the models of the application(s) in which the aspect is reused. The philosophy in RAM is to decompose aspects that provide high-level functionality into aspects that provide lower level functionality. For this case study, we decided to split the create mission functionality into 4 separate reusable concerns at a high level of abstraction: resource management, communication, workflow management and logistics, and two CCCMS-specific concerns: initialization and create mission. Subsection 2.1 presents the aspect models involved in the resource management concern in detail and at the same time explains the basic concepts of RAM. The communication, workflow management and logistics concerns are presented in subsections 2.2, 2.3, 2.4 with less details for space reasons. Finally, subsection 2.5 shows how the initialization and create mission concerns reuse the previous aspects to achieve the desired application functionality, and subsection 2.6 presents a design summary and comments on possible improvements. Please note that the complete models of all aspects involved in this case study can be downloaded from [8]. 2.1

Resource Management

Resource management is one of the key concerns of the CCCMS. At all time, the system should be aware of the availability of resources — human resources such as first aid workers, drivers, doctors, etc. as well as vehicles, rescue equipment, etc. The system should also keep track of other relevant information, such as the condition and location of the resources in order to allow the most efficient and effective deployment of the resources in case of a crisis. At a high level, resource management can be split into resource search, i.e. finding an available resource that exhibits a desired capability, and resource allocation, i.e., allocating a set of resources to a task. The design of resource allocation is explained first, since it is conceptually simple. At the same time the notation of the Reusable Aspect Models modeling approach is introduced. 2.1.1 Allocating Resources We are going to present the three aspects that make up the design of the resource allocation aspect in a bottom-up way: first, the lower level aspects ZeroToManyAssociation and Allocatable, and then ResourceAllocation itself. ZeroToManyAssociation In our Reusable Aspect Models (RAM) approach, an aspect model is a special UML package that encapsulates all model elements related to the structure and/or behavior of a concern. The current version of RAM [2] supports aspect models that use class diagrams, state diagrams and sequence diagrams.

Aspect-Oriented Design with Reusable Aspect Models aspect ZeroToManyAssociation structural view

Set

|Data
+ add(|Associated a) + remove(|Associated a) + Set getAssociated()

state view |Data

1 mySet

0..*

|Associated

state view Set

Advice

Pointcut

|Data |Associated

|Associated

int size ~ Set create() ~ add(|Associated ) ~ remove(|Associated) ~ delete()

275

add AddAllowed Default Instantiation AddAllowed → * RemoveAllowed → * Any→ *

RemoveAllowed

remove

delete

Any

Any

getAssociated Advice

caller: Caller

Pointcut

new := create(..)

new: |Data

caller: Caller new := create(..)

new: |Data

message view |Data.add

target: |Data

remove[size>0] /size--

Default Instantiation caller → * Caller → * new → *

mySet := create()

mySet: Set

Advice

Pointcut

add(|Associated a)

create/size:=0

Existing

RemoveAllowed

message view initializeAssociation

caller: Caller

add/size++

AddAllowed

target: |Data

caller: Caller

add(|Associated a)

mySet: Set

insert(a)

Default Instantiation caller → *, Caller → *, target → * message view |Data.remove

Pointcut

target: |Data

caller: Caller

remove(|Associated a)

Advice caller: Caller

target: |Data

remove(|Associated a) remove(a)

Default Instantiation caller → *, Caller → *, target → * message view cleanup

Pointcut target: |Data

caller: Caller delete(..)

mySet: Set

Advice caller: Caller

target: |Data delete(..)

mySet: Set

delete()

Default Instantiation caller → *, Caller → *, target → *

Fig. 1. The ZeroToManyAssociation Aspect

Fig. 1 presents the aspect model ZeroToManyAssociation that shows the design of a concern that occurs very frequently in applications, and that is also used in resource allocation: an object of some class A needs to be associated with many objects of another class B. While in UML, this situation can be shown with a standard association that has the multiplicity 0..*, it is usually implemented during the detailed design phase using an intermediate set (or list or array) object contained in the object of class A. To associate an object b with an object a, b is inserted into the set contained in a.

276

J. Kienzle et al.

Structural View The class diagram representing the structure of the design of ZeroToManyAssociation is presented in the structural view compartment of Fig. 1. It defines three classes: |Data, |Associated and the template class Set. The Set class implements a set abstraction: it provides a constructor and destructor, as well as operations to insert elements into and remove elements from the set. It is parametrized with the |Associated class, thus creating a “Set of |Associated”. Many object-oriented programming language libraries provide such classes, e.g. the generic Set class in Java, or the set class in the C++ standard template library. |Data and |Associated are partial classes. A partial class needs to be completed before it can be used in an application. Partial classes, for instance, do not define constructors and destructors, and hence it would be impossible to create instances of the class. All partial classes of an aspect are therefore exported as mandatory instantiation parameters of the aspect, and shown as UML template parameters on the top right corner of the aspect package. In order to use the aspect and weave it with a target model, the mandatory instantiation parameters must be mapped to model elements from the target model. The public interface of a RAM aspect is comprised of all the public operations declared by classes inside the aspect. In UML, the public operations are marked with a +. In the ZeroToManyAssociation example, only the operations add, remove and getAssociated provided by |Data are publicly accessible. The operations of the Set class are part of the intra-aspect interface of ZeroToManyAssociation, i.e. they can only be called from other objects that are part of the aspect. The intra-aspect operations are tagged in RAM using the UML package modifier ∼. Message Views To provide the functionality related to a concern, the model elements within an aspect model must collaborate at run-time. In RAM, collaboration between objects is shown in the message view compartments using sequence diagrams. A RAM aspect must specify a message view for each public operation that involves message exchanges between objects. If a public operation does not have a corresponding message view, it is assumed that it only modifies or reads the state of the object1 . The message view initializeAssociation, shown in the first message view compartment of the aspect in Fig. 1, shows that whenever a constructor is invoked on an object of the class |Data (see pointcut sequence diagram), then the constructor also creates an instance of the class Set and stores a reference to it in mySet (see advice sequence diagram). This guarantees that there will never be a |Data object without a Set object that belongs to it. The cleanup message view makes sure that the set is deallocated when the |Data object disappears. The message view add describes that adding an object of the class |Associated is 1

This is, for instance, the case for the method getAssociated, which simply returns the set mySet to the caller.

Aspect-Oriented Design with Reusable Aspect Models

277

done by inserting a reference to it into the set referenced by mySet. Removing objects from the association, described in the message view remove, follows the same pattern. State Views RAM also allows the modeler to show how the state of an object dictates the messages it accepts in state views with the help of state diagrams. For each class in the structural view that defines operations, a corresponding state view has to be specified. The state diagram must contain at least one transition for each operation that the class defines. In Fig. 1, for example, the Set state view describes the protocol of the Set class. It specifies that after being created, an instance of Set accepts calls to the add operation, and, if not empty, calls to remove, until the instance is destroyed. The |Data state view looks different: just like the message views, it has a pointcut state diagram and an advice state diagram. The reason for this is that |Data is a partial class. It is impossible to specify a complete state diagram, with initial state and end state, for a partial class. It is possible, however, to define states that are relevant with respect to the operations that the partial class offers. The |Data class, for example, has 3 states that are important: AddAllowed, RemoveAllowed and Any. They represent the states in which a |Data instance accepts calls to add, remove, and getAssociated, respectively. Instantiation In order to use the ZeroToManyAssociation aspect in a target model, it has to be instantiated by mapping the mandatory instantiation parameters of the aspect to model elements in a target model. In our example, the mandatory instantiation parameters, shown as UML template parameters on the top right corner of the aspect package, are the classes |Data and |Associated. For instance, to associate a capability with zero to many resources, a modeler would write the following instantiation: |Data → Resource, |Associated → Capability. At run-time, a capability c can now be associated with a resource r by calling c.add(r). Allocatable Another simple low-level aspect of resource management is Allocatable, shown in Fig. 2. Notice how Allocatable provides the functionality of being able to tag an |Allocatable object as being allocated by calling allocate, free it again by calling deallocate, and query its state using isAllocated. The Allocatable aspect is really simple, in the sense that it contains only one class |Allocatable. The three public operations of |Allocatable form the interface of the aspect. None of the public operations of |Allocatable involve object interactions, and therefore this aspect does not contain any message views, nor do its classes need to worry about declaring an intra-aspect interface.

278

J. Kienzle et al.

aspect Allocatable structural view

state view |Allocatable |Free

|Allocatable

|Allocatable bool allocated + bool isAllocated() + allocate() + deallocate()

|Busy

Pointcut Any

allocate |Free

Advice |Busy

deallocate

isAllocated Any

|Free, |Busy Default Instantiation Any→ *

Fig. 2. The Allocatable Aspect

The state view of |Allocatable specifies that an instance of the class |Allocatable has at least two states, here named |Free and |Busy, and that the instance must be in the |Free state to be able to execute allocate, and in the |Busy state to execute deallocate. ResourceAllocation ResourceAllocation, shown in Fig. 3, is an example of a higher level aspect that depends on the low-level functionality of both Allocatable and ZeroToManyAssociation. ResourceAllocation is in charge of allocating resources to a task, and tagging the resources as being allocated. To this aim, the structural view of ResourceAllocation defines the two partial classes |Resource and |Task. |Task provides the public operations allocateResources, deallocateResources, and getResources. The structural view also contains an instantiation directive for the aspects ZeroToManyAssociation and Allocatable. It maps |Data to |Task and |Associated to |Resource, thus reusing the functionality provided by ZeroToManyAssociation to associate each |Task object with a set of |Resources. ResourceAllocation also reuses Allocatable to be able to mark a resource as being allocated by mapping |Allocatable to |Resource. A similar instantiation has to be done in the |Task state view in order to specify how the AddAllowed and RemoveAllowed states of ZeroToManyAssociation relate to the states |NoAllocation and |Allocated. The message view allocateResources also reuses functionality provided by Allocatable and ZeroToManyAssociation. It demonstrates how behavior of lower level aspects is reused. The sequence diagram describes that when requested to allocate a set of resources to a task, the task object loops through the set of resources, calling allocate (provided by Allocatable) for each of them and subsequently adding it (provided by ZeroToManyAssociation) to the set of resources associated with the task. Although it would be possible to provide specific instantiation directives to reuse the message views of ZeroToManyAssociation and Allocatable, it is in this case also possible to use a shortcut. Since the message views in ZeroToManyAssociation and Allocatable both define default instantiation directives that map caller, Caller and target to any model element in the target model (see Fig. 1 and Fig. 2), it is enough to simply state that the

Aspect-Oriented Design with Reusable Aspect Models

aspect ResourceAllocation depends on Allocatable, ZeroToManyAssociation structural view |Resource


ZeroToManyAssocation instantiation |Data → |Task |Associated → |Resource getAssociated → getResources Allocatable instantiation |Allocatable→ |Resource

|Task
+ allocateResources(Set r) + Set getResources() + deallocateResources()

279

|Task |Resource

state view |Resource is Allocatable.|Allocatable state view |Task

Pointcut

|NoAllocation

|Allocated

allocateResources |NoAllocation

Advice

|Allocated

deallocateResources

Any Any

Default Instantiation Any→ *

getAssociated

|NoAllocation |Allocated

allocateResources

ZeroToManyAssociation instantiation AddAllowed→ |Allocated RemoveAllowed→ |NoAllocation

message view allocateResources affected by ZeroToManyAssociation.add, Allocatable.allocate target: |Task

caller: Caller

allocateResources(Set r)

caller: Caller

Advice

target: |Task

allocateResources(Set r) loop [res within r]

Pointcut

res: |Resource

allocate()

Default Instantiation caller → *, Caller → *, target → *

add(res)

message view deallocateResources affected by getResources, remove, deallocate target: |Task

caller: Caller

caller: Caller

Advice

target: |Task

deallocateResources()















r := getResources()

deallocateResources()

Pointcut

loop [res within r]

Default Instantiation caller → *, Caller → *, target → *

res: |Resource

deallocate() remove(res)

Fig. 3. The ResourceAllocation Aspect

message view allocateResources is affected by the message views allocate and add. The weaver will know how to combine the models correctly. The state view |Task specifies that while it is possible to incrementally allocate resources to a task by calling allocateResources multiple times, a call to deallocateResources always frees all of the resources. Weaving The weaver in RAM supports aspect hierarchies of arbitrary depth. Given an aspect A that depends on lower level aspects B and C, the weaver must first create an independent model of A before A can be woven into a base application model or be reused in a higher level aspect. The independent model of A is an aspect model that contains all the structural entities, states and message exchanges defined in the aspects A depends on, i.e., in B and C. Weaving is performed in pairs. If no specific weave order is specified for B and C, the weaver

280

J. Kienzle et al.

chooses one randomly, e.g. first weaving B with A, and then C with the result of the previous weaving. Since B and C can themselves depend on other aspects, our weaving algorithm is recursive in nature, processing the dependency graph in depth-first order. The dependency graph of ResourceAllocation Resource is shown in Fig. 4. In order to create an indeAllocation pendent aspect model of ResourceAllocation, the weaver first weaves the aspect Allocatable into ZeroToMany Allocatable Association ResourceAllocation in order to get a model of ResourceAllocation that is independent of Allo- Fig. 4. Resource Allocation catable. Second, ZeroToManyAssociation is wo- Dependencies ven into the resulting model to finally obtain a model of ResourceAllocation that is independent of both Allocatable and ZeroToManyAssociation. Fig. 5 shows the independent model of ResourceAllocation after weaving. Note how the structural views have been merged, and how the advice of the |Data state view added transitions to the advice of the |Task state view at the states identified by the pointcut of the |Data state view. Encapsulation and Information Hiding In order to make information hiding possible in aspect hierarchies, the RAM aspect weaver automatically removes the public interface of the model elements of an aspect when it is woven into a target model by changing the visibility of the model elements from public to package. This effectively “moves” the operations from the public interface of the aspect to the intra-aspect interface. The aspect interface of the independent ResourceAllocation aspect, just like the dependent one, therefore contains 3 public operations. The public operations of the lower level aspects had their visibility changed from public to package as they were copied into the woven model. As a result, model elements in higher level aspects that instantiate ResourceAllocation cannot directly use the functionality provided by Allocatable and ZeroToManyAssociation. Consequently, information hiding principles are maintained even in the woven model and exposure of internal design decisions of ResourceAllocation is prevented. Some times, however, a modeler may want to “re-expose” lower level operations at the higher level. This situation occurs when an operation of the lower level aspect directly implements a functionality that the higher level aspect needs to provide. In the ResourceAllocation aspect, for example, it should be possible to query all the resources that are allocated to a task. This functionality is already provided by the operation getAssociated in ZeroToManyAssociation. In RAM, the modeler can explicitly “re-expose” lower level operations by first declaring the re-exposed operation in the appropriate class. The same operation name can be chosen, but a different name can also be used if it better reflects the semantics of the operation in the context of the high-level aspect. Second, when instantiating the lower level aspect in the high-level aspect, the lower level operation is simply mapped to the high-level operation. Concretely, if a modeler wishes to “re-expose” getAssociated in ResourceAllocation, he can add

Aspect-Oriented Design with Reusable Aspect Models

aspect ResourceAllocation

|Task |Resource

structural view |Task


~ create() ~ add(|Resource ) ~ remove(|Resource) ~ delete()

Pointcut

|Busy

0..*

Advice

allocate

Any

|Resource - bool allocated ~ bool isAllocated() ~ allocate() ~ deallocate()




1 mySet

+ allocateResources(Set r) + Set getResources() + deallocateResources() ~ add(|Resource a) ~ remove(|Resource a)

|Free

|Resource

Set

state view |Resource

281

|Free

isAllocated

|Busy

|Free, |Busy Binding Any→ *

Any

deallocate state view Set insert/size++

state view |Task |NoAllocation

create/size:=0

remove[size>0] /size--

|NoAllocation |Allocated Advice

allocateResources Binding Any→ *

getResources

message view allocateResources target: |Task

|Allocated

deallocateResources

Any

allocateResources(Set r)

add

Any

Pointcut

caller: Caller

allocateResources

|NoAllocation

|Allocated

Existing delete

remove

Advice caller: Caller

target: |Task

allocateResources(Set r) loop [res within r]

Pointcut

res: |Resource

allocate()

Default Instantiation caller → *, Caller → *, target → *

add(res)

mySet: Set

add(res)

message view deallocateResources target: |Task

caller: Caller deallocateResources()

Advice caller: Caller

target: |Task

deallocateResources()















r := getAssociated()

Pointcut loop [res within r]

Default Instantiation caller → *, Caller → *, target → *

res: |Resource

deallocate() remove(res)

remove(res)

mySet: Set

Fig. 5. The Independent ResourceAllocation Aspect

282

J. Kienzle et al.

a public operation getResources in the |Task class and map getAssociated to getResources in the instantiation directives as shown in Fig. 3. This tells the weaver to rename the getAssociated operation during the weaving process and to not change its visibility modifier. For more details on the weaving algorithm, the reader is referred to [2]. For details on automated encapsulation, the reader is referred to [3]. 2.1.2 Finding Resources In the context of the CCCMS, the resource search concern encapsulates the functionality of finding the most appropriate set of resources that are available and that have the required capabilities to carry out a mission. Solving the general problem of finding an optimal set of resources that fulfill a given criteria is very hard, and a research area in itself. Since resource search is not the main focus of this paper, we make an assumption that simplifies the problem considerably: a resource has exactly one capability. With this assumption, fulfilling a request for n resources with capability c can be done simply by finding all available resources that have capability c and choosing n of them. This is the essence of the functionality of the simple ResourceSearch aspect shown in Fig. 6. Resource Search The structural view of ResourceSearch defines three classes: |Capability, |Resource and Request. |Resource is a partial class representing resources, |Capability is a partial class that represents the expertise, quality or function a resource can have or is able to perform. The specified association between the two partial classes makes sure that every resource has exactly one capability. In order to keep track of all the resources that have a certain capability, ZeroToManyAssociation is instantiated. The Request class is central to the ResourceSearch aspect. To perform a search, a request must be created, and the desired capabilities and number added to it. The find operation performs the actual search for resources, and returns a set of available resources that have the desired capabilities. Internally, the Request class is designed using the Map aspect. The Map aspect is again a concern that occurs very frequently in applications. It basically provides the functionality of a hash table, mapping key objects to value objects. It, therefore, represents a design implementing a qualified association in UML. The internal design of the aspect is similar to the ZeroToManyAssociation aspect, and hence not shown here for space reasons. The interested reader can look at the model by downloading the set of all CCCMS models from [8]. The initiateAssociation and cleanup message views make sure that, whenever a resource is created with a capability c, the resource is also added to or removed from the set of resources associated with c. Finally, the most interesting message view is find. The request object first starts by creating a set of resources to store the result of the search. Then, it obtains the set of capabilities requested using the getCapabilities functionality, which is actually the getKeys functionality provided by Map. For each requested capability, it queries the number

Aspect-Oriented Design with Reusable Aspect Models

aspect ResourceSearch depends on Allocatable, ZeroToManyAssociation, Map structural view

|Capability

myCapability 1


+ Set findResources()

|Request

Allocatable instantiation |Allocatable
|Resource

state view |Resource create

Pointcut

Pointcut

create

create

ZeroToManyAssociation instantiation AddAllowed
Any RemoveAllowed
Any Any
Any

findResources

Any

Allocatable instantiation |Free
Existing |Busy
Existing

Existing

Advice

Any state view Request

Map instantiation |Key
|Capability |Value
Integer |Data
Request

Advice

Binding Existing
*

Existing

state view |Capability


+ |Resource create



(.., |Capability myCapability, ...)


+ Request create() + Set find() + add(|Capability cap, Integer num) + Set getCapabilities() + int getNumber(|Capability c) + delete()

ZeroToMany instantiation |Data
|Capability |Associated
|Resource

|Resource |Capability

|Resource

delete

Map instantation AddAllowed
Existing Any
Existing

Existing find message view findResources is ZeroToManyAssociation.getAssociated message view initializeAssociation and Cleanup not shown for space reasons

Advice

message view find instantiates getAssociated, getValue, getKeys, isAllocated, insert caller: Caller

target: Request

caller: Caller

solution := find()

Binding caller
* Caller
* target
*

Pointcut

target: Request

solution := find() solution := create()

solution: Set

keys := getKeys()

loop [k within keys] i := getValue(key)

i: Integer

num := getValue()

k: |Capability resSet := getAssociated()

counter := 0 loop [r within resSet and








counter < num]

r: |Resource allocated := isAllocated()

opt [not allocated]

insert(r)

counter := ++

message view add is Map.add message view getCapabilities is Map.getKeys message view getNumber instantiates Map.getValue caller: Caller

target: Request

result := getNumber(c)

Pointcut

Advice

caller: Caller

Binding caller
* Caller
* target
*

target: Request

result := getNumber(c) i := getValue(c) result := getValue()

Fig. 6. The ResourceSearch Aspect

i: Integer

283

284

J. Kienzle et al. aspect OptimalResourceSearch depends on ResourceSearch structural view

|Capability

- real fitness + create(.., real Fitness, ..) + setFitness(real Fitness) + real getFitness()

Request
+ Set findFittest()

state view |ResourceWithFitness SetAllowed

Pointcut

Default Instantiation SetAllowed → * Existing → *

Existing

|ResourceWithFitness |Capability

|ResourceWithFitness

Public ResourceSearch instantiation |Resource → |ResourceWithFitness |Capability → |Capability Request → |Request

Advice SetAllowed setFitness

ResourceSearch instantiation Existing → Existing

Existing

getFitness

state view |Capability is ResourceSearch.|Capability state view Request

Pointcut Any

Advice Any

ResourceSearch binding Any → Existing

findFittest

message view findFittest affected by getResources, getCapabilities, getNumber, isAllocated caller: Caller

target: Request

solution := findFittest()

caller: Caller

solution := findFittest() solution := create()

Pointcut Default Instantiation caller → *, Caller → *, target → *

Advice

target: Request solution: Set

keys := getCapabilities() loop [k within keys]

temp := create()

temp: PriorityQueue

num := getNumber(k)

k: |Capability

resSet := findResources() loop [r within resSet ]

r: |ResourceWithFitness allocated := isAllocated()

opt [not allocated]

fit := getFitness() insert(r, fit )

loop [ i = 0; i < num; i++ ]

chosenRes := removeFirst() insert(chosenRes) delete()

Fig. 7. The OptimalResourceSearch Aspect

of requested resources of that capability by calling the getNumber functionality, which uses the getValue functionality provided by Map. Then, a set of resources having the requested capability is obtained using findResources, which is actually getAssociated provided by ZeroToManyAssociation. For each resource in this set, isAllocated provided by Allocatable is called to check if the resource is still available, and if it is, the resource is inserted into the result set. When enough resources of the current capability have been found, the next capability of the request is looked at. This continues until the entire request has been handled.

Aspect-Oriented Design with Reusable Aspect Models

285

Optimal Resource Search The OptimalResourceSearch aspect, shown in Fig. 7, illustrates a slightly more advanced searching algorithm. It associates with each resource a fitness value — a real number between 0 and 1— that stores how good a resource is in performing its associated capability. It provides the findFittest functionality that fulfills a request by finding the most adequate available resources. As shown in the message view findFittest of Fig. 7, the available resources that have the required capability are first sorted according to their fitness value using a priority queue, and then the top-most resources are chosen to fulfill the request. Optimal ResourceSearch

Resource Allocation

Networked Command

Resource Search

ZeroToMany Association

Socket Communication

Map

Allocatable

Map

Serializer

Command

Fig. 8. Dependencies of the Resource Management and Communication Aspects

2.1.3 Dependency Summary The dependencies between the aspects involved in the resource management design are shown in Fig. 8. It shows clearly that ZeroToManyAssociation and Allocatable are concerns that crosscut the design of resource management, since both ResourceSearch and ResourceAllocation depend on them. 2.2

Communication

The main functionality of the communication infrastructure is to allow remote resources, such as first aid workers or vehicles, to communicate with the CCCMS backend. The assumption here is that humans that need to communicate with the backend are carrying a laptop or a PDA (Personal Digital Assistant) that can establish a secure wireless connection (for instance using Virtual Private Network (VPN) technology) to access the CCCMS network. The super observer is an example of a human resource that uses his PDA to communicate new missions to the backend. Fig. 8 shows a high-level overview of the dependencies among the aspects that handle communication within the CCCMS. The designs of the individual aspects are not shown here for space reasons. The ideas are briefly explained below, and the full models can be downloaded from [8]. The main idea of the design of the communication infrastructure is to send messages and data over the network in form of commands. The Command aspect implements the command design pattern [9], the essence of which is to encapsulate a method call in an instance of a Command object. The value of the parameters of the invocation is stored inside fields of the Command class. Every

286

J. Kienzle et al.

command class has an execute operation that triggers the execution of the actual command. The Serializer aspect implements the serializer design pattern [10], which ensures that the state of any Serializable object can be flattened into a stream of bytes in order to be written to a Backend. Conversely, it also offers the functionality of recreating the Serializable object from a stream of bytes read from a Backend. The SockedCommunication aspect implements socket-based communication on top of the Serializer aspect. Its design is heavily inspired by how Java does socket-based communication. It defines a SocketServer class that provides the functionality of listening for incoming connections using a server thread, and a Socket class that can be instantiated by a client to establish a connection with a server, or that is automatically instantiated by the server when a connection is accepted. A Socket has an associated Receiver and Sender object that provide the functionality to receive and send |Sendable objects, respectively. Finally, the NetworkedCommand aspect ties the different aspects together. It defines a |RemoteCommand class, which is both a |Sendable (provided by SocketCommunication) and a Command (provided by Command ). It also defines the CommandChannel class that provides the functionality to send a remote command to a host identified by a string. At the same time, creating a CommandChannel also instantiates a server socket and starts a thread in order to listen for incoming connections. When an incoming connection is established, another thread is instantiated in order to listen for incoming commands and execute them. This functionality is provided by the CommandListener class. Finally, in order to not have to establish new connections for each command, the CommandChannel object stores all existing connections in a hash table provided by the Map aspect. 2.3

Workflow Management

The main functionality of the reusable concern workflow management is to allow the modeler to define and later on execute workflows, which control the sequence and conditions that coordinate activities. In the CCCMS requirements document, for example, the use cases define the different activities that constitute the workflow for missions that can be carried out by CCCMS workers. Fig. 9 shows a summary of the dependencies among the aspects that provide workflows to the CCCMS. The central aspect of workflow management is the aspect Executable, which only defines a partial class |Executable and a partial class |Context. An |Executable represents an activity within a workflow. The execute operation triggers the execution of the activity. The class also contains an operation waitForTermination that suspends the calling thread until the execution of the activity is completed. The method getOutcome returns a boolean that communicates if an activity is completed successfully or not. The aspects SequencialExecution, ParallelExecution, LoopedExecution, and ConditionalExecution are control structures which allow the modeler to create complex control flows of activities. For instance, the aspect SequencialExecution contains an ordered set of |Executable instances and provides the functionality

Aspect-Oriented Design with Reusable Aspect Models

287

Workflow Engine

Looped Execution

Conditional Execution

Workflow

Parallel Execution

Map

Executable

Composite

Sequential Execution

ZeroToMany Association

Fig. 9. Dependencies of the Workflow Management Aspects

of executing them in sequence. It also uses the composite pattern [9] by instantiating the Composite aspect to pose itself as an |Executable, and hence inherits the operations of the latter. Another example of control structure is the aspect ConditionalExecution. This aspect implements a “If Then Else” block, where the |Executable in the “then part” or the “else part” is executed depending on a condition. The condition itself is also an |Executable, which is evaluated by executing it and then querying the outcome with the getOutcome operation. The Workflow aspect implements basic workflows. This aspect contains a class Workflow which is associated with a root activity. This root activity can be any |Executable, and hence complex workflows can be built using the control structures presented above. The Workflow aspect also defines the |Variable class, which an activity can use to store results for following activities. The variables are all linked to the |Context in which a workflow executes. The class |Context uses the functionality of the Map aspect to store the variables indexed by their name. Finally, the WorkflowEngine aspect provides the functionality of executing workflows. The class WorkflowExecution links an execution context with a workflow, and also implements the interface Runnable. The class WorkflowEngine implements a virtual machine which, when requested to do so, launches the execution of a workflow within a given context. It does this by instantiating a new thread, which starts by calling the run operation of WorkflowExecution, which in turn starts executing the root activity of the associated workflow. 2.4

Logistics

An orthogonal concern within the CCCMS is logistics: a crisis usually affects a certain physical area, and missions to address the crisis situation need to be executed at specific locations, or involve transporting victims, goods or other resources from one location to another. Treating the logistics concern of the CCCMS in its entirety is out of the scope of this paper. However, it is interesting

288

J. Kienzle et al.

to show how the logistics concern interacts with resource management in general, and resource search in particular. Locatable Fig. 10 shows the design of a simple aspect called Locatable. It allows a modeler to augment the state of any class with a physical location. It defines getter and setter operations that can be used to query or to update the location of the object, and a travelTime operation that calculates how long it would take the object to reach a certain destination location.

aspect Locatable structural view

|Locatable

|Locatable - Location myLocation + |Locatable create(.., Location myLocation, ..) + Location getLocation() + updateLocation(Location location) + int travelTime(Location destination)

state view |Locatable Any

Pointcut

travelTime

getLocation Any

updateLocation

Advice Default Instantiation Any→ *

Fig. 10. The Locatable Aspect

The logistics concern also includes a Timing aspect which allows the modeler to store a deadline in the state of an object. The RAM model of the Timing aspect is even simpler than Locatable, and therefore not shown here for space reasons. Conflict Resolution Aspects As mentioned before, the logistics concern has an impact on resource management. For instance, when a resource such as a vehicle is put under control of the CCCMS, its location has to be initialized, and continuously updated whenever the resource changes position. Searching for resources is also affected by logistics. In order to determine if a resource is fit to fulfill a certain mission, it not only has to be capable of performing the task, but it must also be able to reach the location of a time-constrained mission within the deadline. This kind of situation, i.e., a situation in which the simultaneous application of two or more aspects requires one or several of the aspect’s state and behavior to be altered in order to provide a semantically correct functionality, has been called aspect interference or aspect conflicts [11]. In RAM, a modeler that detected a conflict between two aspect models A and B can express the adaptations that have to be made to both aspects in order to obtain a semantically correct woven model. In order to keep aspects A and B reusable and independent, the structural and behavioral modifications that are necessary to cope with the aspect conflicts are specified in a separate conflict resolution aspect model. The conflict resolution aspect model, of course,

Aspect-Oriented Design with Reusable Aspect Models

289

depends on the aspects whose conflicts it resolves. The conflicting aspect models, however, do not have to be changed, and hence remain independent from each other. They are, therefore, still individually reusable. A conflict resolution aspect model is different from a standard aspect model, because it defines a set of modification views instead of standard views. Each modification view contains a conflict criteria condition that specifies under which condition the conflict occurs. If the condition is verified, the adaptation defined in the remainder of the view is woven with the structure and behavior of one of the conflicting aspects. conflict resolution aspect Locatable / Timing / OptimalResourceSearch modification OptimalResourceSearch.findFittest affected by getLocation, travelTime, getDeadline Pointcut target: Request r: |Resource

Advice target: Request

fit := getFitness()

r: |Resource

fit := getFitness() destination := getLocation()

conflict criteria OptimalResourceSearch.|Resource = Locatable.|Locatable OptimalResourceSearch.Request = Locatable.|Locatable OptimalResourceSearch.Request = Timing.TimeConstrained

time := travelTime(destination) deadline := getDeadline()

fit := max(0, fit * (1 - time/deadline))

Fig. 11. Locatable / Timing / OptimalSearch Conflict Resolution

Fig. 11 illustrates this idea. It describes the modifications that have to be applied to the findFittest message view of the OptimalResourceSearch aspect (shown in Fig. 7) in order to deal with locations and deadlines. The modifications are only applied in the case where the resources are locatable (as defined by the Locatable aspect), the request is locatable (because the physical location of the mission is known), and there is a deadline associated with the request (as defined by the TimeConstrained class specified in the Timing aspect). This condition is specified in the conflict criteria box of the modification view. If the RAM weaver detects that the conflict condition is verified, then the modifications are automatically applied to the findFittest message view, i.e. the specified pointcut is matched within the advice sequence diagram of findFittest, and all occurrences of the pointcut (in our case there is only 1 match) are replaced by the advice specified in the conflict resolution model. In our case, this amounts to decreasing the fitness value returned by the getFitness operation according to the time it takes the resource to reach the mission location. 2.5

Base Design

All the aspects described in sections 2.1 to 2.4 are general in the sense that they do not specify any classes or operations that only apply to the CCCMS. Rather, they attempt to capture the structure and behavior of resource management, communication, workflow and logistics in a reusable way, independent of each other, and independent of a specific application or context.

290

J. Kienzle et al.

aspect Initialize depends on OptimalResourceSearch, Locatable, Timing structural view Worker - String name + Worker create(String name) + String getName()

Vehicle - String licensePlate + Vehicle create(String licensePlate) + String getPlate()

Expertise - String name + Expertise create(String name ) + String getName()

OptimalResourceSearch instantiation |Resource → Worker, Vehicle |Capability → Expertise, VehicleClass Request → Mission Locatable instantiation |Locatable → Worker, Vehicle, Mission

VehicleKind - String name + VehicleClass create(String name) + String getName()

MissionKind - String name + create(String name) + String getName() + initRequiredResources(Mission m)

myKind 1

Initializer
+ init()

RescueMissionKind
+ RescueMissionKind create(String name, MissionWorkflow m) + initRequiredResources(Mission m) + MissionWorkflow getWorkflow()

Timing instantiation TimeConstrained → Mission

Mission - String description + create(String description, MissionKind myKind) + String getName() + MissionKind getKind() + delete() myFlow

MissionWorkflow 1
+ MissionWorkflow create()

message views and state views not shown for space reasons

Fig. 12. The Initialize Aspect

In order to use these aspects to build the design model of the CCCMS, the general aspects have to be carefully mapped to CCCMS-specific model elements. Traditionally, the models that contain the application-specific elements have been called the base. The base model of the CCCMS is huge, and hence we again use the decomposition possibilities offered by RAM to modularize even application-specific concerns into separate aspect models. As a result, the only “special” property of a base aspect model is the fact that all of the classes it defines are complete, and hence it does not declare any mandatory instantiation parameters. As mentioned in the introduction, we are going to concentrate on the functionality of the CCCMS that is triggered when a super observer orders the execution of a new mission to help resolve the crisis. The design of this functionality is provided in the CreateMission aspect. In order for CreateMission to execute, however, the backend system has to be initialized: several objects need to be created (such as workers and vehicles), associations need to be established (such as between workers and their expertise), and workflows need to be instantiated. The Initialize aspect takes care of this. Initialize Fig. 12 shows the structural view of Initialize. At its heart, it defines the Mission and MissionKind classes. Every mission has an associated mission kind. MissionKind is actually an abstract class, and concrete classes must be defined for each kind of mission. Currently, only one concrete kind is defined: RescueMissionKind.

Aspect-Oriented Design with Reusable Aspect Models

291

Initialize also defines the Worker and Vehicle classes, which are two examples of resources, and the Expertise and VehicleKind classes, which represent capabilities that resources can have. Locatable is instantiated to associate a location with workers, vehicles and missions. Timing is instantiated in order to associate deadlines with missions. OptimalResourceSearch is instantiated to establish a mapping between resources, i.e. workers and vehicles, and capabilities, i.e. expertise and vehicle kinds. The state views and message views of the Initialize aspect are not shown for space reasons. The most important message view is the init operation of the Initializer class, which performs the actual initialization of all the objects in the system. It creates capabilities, e.g firstAid, superObserver or ambulance, and resources, e.g. wisam, who is a superobserver located initially at the crisis control center, joerg, a first aid worker located initially at the hospital, or a1, an ambulance stationed at the hospital. In addition, it creates a workflow engine, and workflows for each mission as specified in the use cases of the requirements document. For instance, a rescue mission workflow is created by instantiating SequencialExecution, and then adding in sequence the individual activities, which would also have to be defined in separate aspect models, as specified in use case UC7 [12]. In a real CCCMS system, initialization should of course not be “hard coded”. Usually, information about resources such as workers and vehicles would be stored in a database, and during system start-up, the in-memory data structures would be initialized with data from the database. Even mission workflows could be initialized in such a way, or even dynamically created at run-time using a mission workflow editor. Database access and dynamic mission editing — yet more concerns of the CCCMS — are, however, out of the scope of this paper. CreateMission Fig. 13 shows the design of the CreateMission aspect. Its design links together the resource management, communication and workflow concerns. The structural view of CreateMission defines a CreateMissionCommand, a CreateMissionReceiver, a ReceiverQueue and a WaitForCreateMissionStep class. The following describes how objects of these classes collaborate to achieve the create mission functionality. On the backend, when a new crisis is created, a CreateMissionReceiver object is instantiated and the operation initialize is invoked. As shown in the initialize message view, this results in instantiating a ReceiverQueue object, which is a blocking queue of Mission objects thanks to the instantiation of the BlockingQueue aspect. The CreateMissionReceiver object stores the reference to this queue object in a hash table indexed by crisis number. This functionality is provided by the Map aspect. Finally, it creates a CommandListener object to listen for incoming commands. When a super observer is dispatched to observe the crisis, the super observer mission workflow is instantiated and given to the workflow execution engine to execute. At some point, after the super observer reached the crisis location, the workflow execution engine executes the performStep operation of a

292

J. Kienzle et al.

aspect CreateMission depends on Locatable, Initialize, ResourceAllocation, NetworkedCommand, BlockingQueue, Map, OptimalResourceSearch, WorkflowEngine

structural view

CreateMissionReceiver
+ initialize(Crisis cr) - Mission getMission(Crisis cr)

Mission ReceiverQueue

ResourceAllocation instantiation |Task → Mission |Resource → Initialize.Vehicle |Resource → Initialize.Worker

WaitForCreateMissionStep
+ performStep()

Initialize instantiation Initialize.Mission → Mission Initialize.MissionKind → MissionKind Map instantiation Map.|Data → CreateMissionReceiver Map.|Key → Crisis Map.|Value → ReceiverQueue

Locatable instantiation Locatable → CreateMissionCommand NetworkedCommand instantiation |RemoteCommand → CreateMissionCommand Advice target: Create MissionReceiver

caller: Caller

target: Create MissionReceiver

WorkflowEngine instantiation |Context → Mission |Activity → WaitForCreateMissionStep

BlockingQueue instantiation |Element → Mission BlockingQueue → ReceiverQueue

message view initialize affected by Map.add caller: Caller

CreateMissionCommand Crisis cr MissionKind k String d + CreateMissionCommand

create(Location l, MissionKind k) + execute()

initialize(cr)

initialize(cr)

create()

q: ReceiverQueue

add(cr, q) create()

Pointcut

l: CommandListener Advice

message view execute affected by Map.getValue, BlockingQueue.insert caller: Caller

target: Create MissionCommand

caller: Caller

target: Create MissionCommand

: CreateMission Receiver newMission: Mission

newMission := create(k, d, l, 300) execute()

execute() q := getValue(cr)

Pointcut Default Instantiation caller → *, Caller → *, target → *

q: ReceiverQueue insert(newMission)

message view performStep



affected by getValue, take, getKind, initRequiredResources, findFittest, allocateResources, launch caller: Caller

target: WaitFor CreateMissionStep performStep()

caller: Caller

target: WaitFor CreateMissionStep

performStep()

: CreateMission Receiver

q := getValue(cr)

q: ReceiverQueue

m := take()

Pointcut

m: Mission

Advice kind := getKind()

Default Instantiation caller → *, Caller → *, target → *

kind: MissionKind

initRequiredResources(m) solution := findFittest() allocateResources(solution) newWorkflow := getWorkflow()

theEngine: WorkflowEngine launch(newWorkflow, m)

Fig. 13. The CreateMission Aspect

Aspect-Oriented Design with Reusable Aspect Models

293

WaitForCreateMissionStep. As described in the performStep message view, this results in calling the take operation of the blocking queue corresponding to the crisis that the super observer is handling. As a result, the workflow execution is suspended, effectively waiting for the super observer to send a create mission command. When a super observer wants to create a mission, he uses his PDA to instantiate the CreateMissionCommand class with the appropriate parameters, and sends the command to the backend. This functionality is provided by NetworkedCommand. On the backend, the command listener receives the command, and invokes the execute operation on it. As shown in the message view execute, this results in the instantiation of a Mission object, which is subsequently inserted into the blocking queue of the corresponding crisis. As a result, the workflow execution engine thread is awakened, and it continues the sequence of execution described in the performStep message view. It asks the MissionKind object associated with the retrieved mission to initialize the required resources for this mission. This operation, provided by the Initialize aspect, initializes the mission object, which is also a request, with the capability requests that describe the resources needed to complete the mission. Then, performStep invokes the findFittest operation provided by OptimalResourceSearch on the mission object. The found set of resources is then allocated to the mission using the functionality provided by ResourceAllocation. Finally, the workflow that needs to be executed in order to process the new mission is obtained from the MissionKind object, and passed to the workflow execution engine to be executed. 2.6

Design Summary and Comments

Fig. 14 summarizes the dependencies among all the aspects that are part of the CCCMS backend design of the create mission functionality. In total, there are 23 aspects. Only 2 aspects, i.e. CreateMission and Initialize, are applicationspecific in the sense that they contain model elements that are specific to crisis management systems. All other aspects are CCCMS independent, and could hence be reused in many other applications. One of the central classes of the CCCMS that is part of many concerns is the Mission class. It not only stores the CCCMS-specific mission information, but is also a Request of ResourceSearch, a Task of ResourceAllocation, a Locatable, a TimeConstrained, and a Context of Workflow. The central message view of the CCCMS design is the performStep message view of the WaitForCreateMissionStep class of CreateMission. After receiving the information about the mission that is to be created from the super observer using NetworkedCommand, the best resources are determined using OptimalResourceSearch, allocated using ResourceAllocation, and then the new mission workflow is launched using WorkflowEngine. The woven class diagram that our weaver generates after weaving all dependent aspects into the structural view of CreateMission is shown in Fig. 15. The

Looped Execution

Conditional Execution

Workflow Management Aspects

Executable

Workflow

Workflow Engine

Parallel Execution

Timing

Initialize

ZeroToMany Association

Allocatable

Resource Search

Optimal ResourceSearch

Blocking Queue

Resource Management Aspects

Resource Allocation

Create Mission

Generic / Design Pattern Aspects

Fig. 14. Design Summary

Composite

Sequential Execution

Locatable

Crisis Management Aspects

Map

Networked Command

Serializer

Socket Communication

Communication Aspects

Command

294 J. Kienzle et al.

0..*

Resource

1 mySet

Resource


~ ReceiverQueue create() ~ add(Mission e) ~ Mission take() ~ Mission peek() ~ destroy()

ReceiverQueue

1

RemoteCommand

Map

1 myMap

- Crisis cr - MissionKind k - String d - Location myLocation + CreateMissionCommand

create(Location myLoc, MissionKind k) + execute() ~ Location getLocation() ~ updateLocation(Location location) ~ int travelTime(Location destination) - readFrom(SocketReceiver r) - writeTo(SocketSender w)

CreateMissionCommand

Crisis

CreateMissionReceiver

ServerSocket

~ execute(Mission c)




SocketReceiver


myR 1

Socket

1


~ Socket create(String host, int port) ~ SocketReceiver getReceiver() ~ SocketSender getSender() ~ destroy()

Fig. 15. The Woven Structural View of CreateMission

myReceiver 1

~ CommandChannel create() ~ send(|RemoteCommand c, String host) - run() ~ add(String k, Socket v) ~ remove(String k) ~ Set<String> getKeys() ~ Socket getValue(String k)

CommandChannel


+ CommandListener


create(Receiver myR) - run()

CommandListener

+ run()







~ RemoteCommand receive() ~ RemoteCommand readRoot() - int readInt() - String readString() ... (other value types) - RemoteCommand readObject()

WaitForCreateMissionStep


~ ServerSocket create(int port) ~ Socket accept()

+ initialize(Crisis cr) - Mission getMission(Crisis cr) ~ add(Crisis key, ReceiverQueue val) ~ remove(Crisis key) ~ Set getKeys() ~ ReceiverQueue getValue(Crisis k)




- boolean outcome entry ~ execute(Mission c) 1 ~ reset() ~ waitForTermination() ~ boolean getOutcome()

1 mySender

1 myMap

String

~ send(RemoteCommand s) ~ writeRoot(RemoteCommand s) - writeInt(int w) - writeString(String s) ... (other value types) - writeObject(RemoteCommand s)

SocketSender


Map

Resource Mission Capability Set - String description
myCapability
1 - Location myLocation ~ Set findResources() 1 mySet ~ create() 1 - int deadline 1 ~ add(Resource a) Variable String Map ~ add(Resource) ~ create(String description, MissionKind myKind, myMap ~ remove(Resource a) ~ remove(Resource)





Location myLocation, int deadline) ~ Set getAssociated() ~ destroy() ~ String getName() ~ Location getLocation() ~ MissionKind getKind() 1 1 ~ updateLocation(Location location) Integer Capability Map ~ destroy() myMap ~ int travelTime(Location destination) ~ allocateResources(Set r) ~ Set getResources() Initializer MissionKind ~ deallocateResources() myKind - String name
~ add(Resource a) 1 ~ create(String name) ~ remove(Resource a) + init() ~ String getName() ~ Set findFittest() ~ initRequiredResources(Mission m) ~ Set find() Worker Vehicle Expertise VehicleKind ~ add(Capability cap, Integer num) - String name - String licensePlate - String name - String name ~ Set getCapabilities() ~ Worker create(String name, ~ Vehicle create(String licensePlate, ~ Expertise create(String name ) ~ VehicleClass create(String name) ~ int getNumber(Capability c) Capability cap, real fitness, Capability cap, real fitness, Location ~ String getName() ~ String getName() ~ Location getLocation() 1 Location myLoc) myLoc) ~ updateLocation(Location location) myContext ~ String getName() ~ String getPlate() ~ int travelTime(Location destination) ~ int getDeadline() WorkflowEngine ~ Variable getVariable(String name)
~ putVariable(Variable v, String name) WorkflowExecution ~ create() 0..* ~ launch(MissionWorkflow w, Mission c)
1 1 Mission Map ~ destroy() ~ create(MissionWorkflow w, Mission c) myFlow RescueMissionKind MissionWorkflow myMap ~ add(Mission k, WorkflowExecution v) ~ run()
1 1
~ remove(Mission k) ~ destroy() ~ RescueMissionKind create(String name, MissionWorkflow m) myWorkflow ~ MissionWorkflow create(Activity entry) ~ Set<Mission> getKeys() ~ initRequiredResources(Mission m) ~ Activity getEntry() ~ WorkflowExecution getValue(Mission k) ~ MissionWorkflow getWorkflow() Runnable Activity

- bool allocated - real fitness - Location myLocation + |Resource create



(.., |Capability myCapability, ...) 0..* + |Capability getCapability() ~ bool isAllocated() ~ allocate() ~ deallocate() ~ setFitness(real Fitness) ~ real getFitness() ~ Location getLocation() ~ updateLocation(Location location) ~ int travelTime(Location destination)

Set - int size ~ create() ~ add(Resource) ~ remove(Resource) ~ destroy()

Aspect-Oriented Design with Reusable Aspect Models 295

296

J. Kienzle et al.

interested reader can compare this design class diagram with the one provided in the case study description document in Fig. 92 [7]. 2.6.1 Design Improvements The design presented in this paper is of course only an initial design, and could be enhanced significantly. The remainder of this subsection comments on weaknesses of our current design, and presents suggestions for improvement. Improvement of Current Aspects The low-level aspects of our design provide minimal functionality, just enough for being useful in the CCCMS context. For example, the ZeroToManyAssociation aspect does not provide query operations that can be used to determine if two objects are currently associated or not. Similarly, the BlockingQueue aspect does not provide query operations to determine the current length of the queue. The workflow management concern described in subsection 2.3 is also only a basic design, implemented specifically for the create mission functionality. In practice, the complete CCCMS might require more advanced workflow capabilities to efficiently capture the scenarios associated to all kind of missions. For example, the workflow management concern could support the definition of procedures in order to share parts of workflows between different types of missions. In practice, support for defining and calling procedures could be added by defining an additional Procedure aspect. Other possible extensions include the ability to define explicit parameters for the workflow activities, the support for local variables or advanced synchronization mechanisms (see http://www.workflowpatterns.com/ for a extensive list of potential workflow features). We believe that most of these features can be captured in RAM aspects in order to enrich the initial version developed for this case study. Adding New Aspects In the current CCCMS design, the resources are stored in lists in memory (see ResourceSearch aspect). In a realistic CCCMS system, a database management system is required in order to persist all application data such as resources, missions, etc. Implementing this persistence layer would require specific data management aspects for data access, caching and transaction management. It has been shown at the programming language level that aspects can be used to encapsulate database access [13], and it should be possible to model the structure and behavior of such functionality with RAM. One other important feature of the crisis management system is its connectivity with external services such as police departments, fire departments, hospitals, weather or traffic centers. These connections and the management of events coming from these external systems have not been covered in the design of the create mission functionality. A set of RAM aspects should be defined to provide such functionality. 2

The main reason why our generated class diagram has more classes than the one provided in the case study document is that ours shows the design of one-to-many associations and qualified associations using Set, List and Map classes.

Aspect-Oriented Design with Reusable Aspect Models

3

297

Lessons Learned from the Case Study

So far, we have not done an in-depth empirical analysis of the practicality of aspect-oriented design in general, and RAM in particular. Working on this case study has nevertheless given us some insight into the usability of our approach. These insights are presented in this section, split into the categories aspectoriented design process, importance of tool support, and support for variability. 3.1

Aspect-Oriented Design Process

In typical object-oriented design, we usually start by designing a small part of the functionality of the system in detail, and then keep on adding functionality iteratively to the existing design, growing our design models gradually. When approaching this case study from an aspect-oriented perspective, we found ourselves starting off with the domain model from the requirements document that contained classes representing the most important CCCMS concepts. We then proceeded by identifying related concepts, and breaking the domain model apart, creating aspects along the way. To each aspect model that now contained some parts of the classes of the domain model we added the detailed design classes that were needed to implement the functionality of the aspect. As a result, our domain model was slowly shrinking, while the number of aspect models was increasing. Whenever possible we would try and reuse already existing aspect models, especially the design pattern aspects that had already been created for other designs. It was not easy to group related concepts based on the domain model, and then encapsulate them in RAM aspects. The process required a good deal of thought and debate. Several times we had created an aspect model that was later on split into several aspect models, because longer thought had revealed that the aspect was actually providing two distinct functionalities. For instance, initially we had created a ResourceManagement aspect that provided operations to search for resources as well as to allocate them. Only while working on the detailed design of ResourceManagement we realized that searching and allocating were actually two sub-functionalities that can easily be separated. It also happened that we had designed an aspect model that was later on discovered to not provide a sufficiently distinct functionality from the aspects that it depended on, and as a result we merged it with a higher level aspect. For example, we had a ResourceToCapabilityMapping aspect that ensured that every resource is associated with exactly one capability at creation time, and vice versa. In the end we decided that such an aspect was not adding much functionality beyond what ZeroToManyAssociation already provides, and therefore it was merged with ResourceSearch. It was also not always easy to apply good information hiding principles during the CCCMS design. Ideally, a modeler using an aspect A would not have to know about the aspects that A depends on. Our experience shows us that a lot of care needs to be put into the design of the interface of A in order to make this possible.

298

J. Kienzle et al.

RAM currently does not provide any algorithm or heuristic on how to discover aspect models during the design, or how simple or complex each aspect model should be, or how to design good aspect model interfaces. The initial hurdle that a modeler has to overcome in order to identify RAM design aspects starting from a requirements document is not small. This struggle is not necessarily a bad thing, though, as it forces the modeler to think deeply about the problem, to look at the design from many angles and perspectives, thus increasing the modeler’s understanding of the problem and the designed solution. Model Scalability. The CCCMS is a system of considerable size. However, so far we only concentrated on the design of the create mission functionality. Nevertheless, we decomposed the problem into 23 different aspect models. Complexity of Individual Aspect Models Each individual aspect model is small in size. Most models fit entirely on one letter page, some require two pages to print. The structural views of our models contain on average 3 classes. Not surprisingly, Initialize, which defines the main CCCMS-specific data structures, contains 9 class definitions. The public interfaces of our aspects define on average 8 operations. The state views specify on average 3 states, and the message views depict interaction sequences that involve on average 5 object instances. Again, the init operation of the Initialize aspect, which takes care of creating and initializing the CCCMS data structures, defines the message view with the most object instances. Based on our experience, the small size of our aspect models makes them easy to work with. Of course it is easier to understand how a small number of objects work together to achieve a very specific functionality than it is to understand the structure and behavior of the full application. Even if a modeler only looks at the objects that are related to a specific functionality in a non-aspect-oriented design, these objects define state and behavior that are related to many concerns, which is confusing. The model elements inside our aspect models only define the state and behavior relevant to a specific functionality, and hence the modeler is not distracted by unrelated information. During our design activities, we observed yet another reason why the small size of RAM models is beneficial to a modeler: all information pertaining to a given functionality can be visualized simultaneously on one screen or on one sheet. This allows the modeler to understand the internal workings of an aspect without having to piece information together from multiple windows or sources, which saves considerable time. Composition Complexity Our tool helps the modeler to reuse one aspect within the context of another in a consistent way. Complex aspects can depend on many lower level aspects, e.g., A can depend on B, C and D. Nevertheless, composition is always specified in pairs, e.g. A+B, A+C and A+D. Reasoning about pair-wise composition is relatively simple: the modeler must always only look at two views simultaneously, e.g. the structural view of A and B, in order to specify the desired instantiation or binding directives.

Aspect-Oriented Design with Reusable Aspect Models

299

In some rare cases, the order in which the pair-wise compositions are performed matters. To address these situations, RAM allows to specify an ordering for the composition. Conflicts that occur between B, C and D if applied to the same model elements can be resolved by writing conflict resolution aspect models (see section 2.4) that are automatically applied by the weaver when a modeler reuses the conflicting aspects together. Although lots of effort has been put into limiting composition complexity for the users of RAM, in-depth empirical experiments have to be conducted in the future to determine if modelers are faced with challenges when having to specify compositions of many aspects in real-world sized systems. Inheritance vs. Merging. At several times during the design of the CCCMS, our object-oriented design background made us want to use generalization/specialization relationships (inheritance) to implement a design solution for a particular situation. For instance, we wanted to create an abstract superclass CCCMSResource, with subclasses Worker and Vehicle, because we would like Worker and Vehicle to share common attributes and operations. Since RAM supports one-to-many mappings during instantiation, the same effect can be achieved simply by mapping both Worker and Vehicle to ResourceWithFitness. Both former classes, as a result, “inherit” the attributes and operations of ResourceWithFitness. A similar situation occurred within the workflow management aspects, where we initially had the intention of creating a ControlStructures super class to group together our many workflow control structures. It is not clear to us, for now, if weaving can completely replace inheritance. Further experiments are necessary to find an answer to this question. 3.2

Importance of Tool Support

After having completed a major part of the design of the CCCMS, a new member joined our design team. In order to understand the details of the design of one aspect, he had to also look at and understand the structure and behavior of the instantiated aspect models. Sometimes, he had to dig even deeper, and look at aspects that were two levels below the aspect he wanted to understand in order to get a feeling of how the design was supposed to work. The RAM tool provides essential help in such a situation, because it allows a modeler to create an independent model of any aspect. Since the independent model contains all the model elements of the instantiated aspects, the modeler can look at the “full picture” of the aspect under study, and is able to understand the design in detail. For example, a modeler trying to understand the structure of OptimalResourceSearch does not see any association between Capability and ResourceWithFitness. Even an inspection of ResourceSearch does not reveal that Capability is linked to a set of Resources. It is only when looking at ZeroToManyAssociation that the association between |Data and |Asssociated appears. In the independent aspect model of OptimalResourceSearch generated by our tool, however, the association between the two classes is readily visible. Having realized the importance of the tool support that a designer can rely on, we are planning in the future to extend our tool with additional features that

300

J. Kienzle et al.

could improve the usability of RAM. As a first step, we are planning to extend the tool to color-code model elements in an independent aspect model depending on the aspect(s) they originated from. Ultimately, the goal is to implement a tool in which it would be possible to interactively “unfold” instantiated aspects in order to see the structure and behavior they provide in detail. Correctness Checks. The RAM weaver performs extensive consistency checks within the generated independent aspect model and within the final base model. Our tool compares, for each object life line in the final generated sequence diagrams, that the ordering in which the object accepts incoming messages corresponds to the ordering of the messages accepted by the woven state diagram. If the state diagram refuses a message, consistency is violated. This signals to the developer that the instantiations and bindings (or the ordering of the instantiations and bindings) of the state and message views contradict each other and have to be revisited. Although this does not guarantee correctness of the compositions, the probability of detecting erroneous composition directives is significant: the modeler has to specify the same composition from two points of view: the state view and the message view. The only situation in which the tool cannot detect the error is the one where the modeler specifies the same wrong composition in both views. The consistency checks provided by RAM have helped us to detect composition problems during the design of the CCCMS. It is not clear, however, how effective these checks are when models grow even bigger. In-depth empirical experiments have to be conducted in the future to determine if modelers are faced with challenges when having to specify compositions of many aspects in real-world sized systems. 3.3

Support for Variability

Often, a given functionality can be implemented (and hence modeled) in different ways. Likewise, in a product line approach, several applications with similar but not identical functionality are to be modeled. When applying an aspectoriented approach, a high-level functionality (or a super-set of features in a product line) can be decomposed into many lower level functionalities (or many individual features), each one modeled in a separate aspect. When the aspectoriented approach is applied over several abstraction layers (high–medium–lowlevel functionalities or features–subfeatures–subsubfeatures), it is necessary to express the rules that govern the correct use of the aspect models. Since RAM encourages the use of multiple abstraction layers, we extended RAM with a software product line approach to handle variabilities, i.e. to model the set of correct configurations of aspects that are available in an aspect framework or product line. We have not presented the feature model support of RAM in this paper for space reasons. The 23 aspects that constitute the design of one functionality, e.g. create mission, of one specific CCCMS backend are already sufficiently complex to illustrate the power of RAM. The only optional variant we partially designed

Aspect-Oriented Design with Reusable Aspect Models

301

and presented is Logistics. One could imagine instantiating a CCCMS backend design that does not support keeping track of the location of resources, and does not optimize the allocation of resources based on travel time to the mission location. In the AspectOptima [14] case study, which describes a product line of transaction support systems, the need for variability support becomes apparent. Indeed, the 15 aspect models can be combined in 10 different ways to generate the model of a concrete transaction support product. While the designer of a model of a product line composed of many interdependent and potentially conflicting aspect models has a very difficult task, using the product line model to derive a specific model of a product is very simple. Our tool presents to the user of the product line a feature diagram describing all variation points of the product line. Once the user made his choice, our tool weaves the corresponding aspect models together to create the detailed design model for the specific product. For instance, for the current CCCMS design, a user could instruct the tool to include the feature Logistics, or to generate a model without the Logistics feature enabled. If Logistics is not chosen, then the Initialize aspect does not instantiate Locatable and Timing, and as a result the LocatableTimingOptimalResourceSearch conflict resolution aspect is not activated, and consequently OptimalResourceSearch looks for resources based on capability ratings only.

4

In-Depth Comparison to Related Work

The goal of this section is to present an in-depth comparison of RAM with related work. In [15], a freely available 71 page technical report, Schauerhuber et al. present an overview of 8 different AOM approaches. The surveyed approaches are: 1. The Aspect-Oriented Design Model of Stein et al. [16,17] In [17], Stein et al. introduce a way to express various conceptual models of pointcuts (called JPDDs for Join Point Designation Diagrams) in aspectoriented design. Structural and behavioral modeling is achieved by employing for instance class diagrams, state charts, and sequence diagrams. Their objective is not to perform the weaving at the modeling level, but rather to generate code for aspect-oriented programs (such as generating AspectJ [18] code) from an aspect-oriented design as shown in [19]. 2. The JAC Design Notation of Pawlak et al. [20,21] The JAC Design Notation is a lightweight UML 1.x extension that was created to make it possible to model a design that uses the JAC Framework, a middleware (including IDE and modeling support) for the development of J2EE applications that require support for persistence, security, fault tolerance, load balancing and other concerns. The approach only supports class diagrams, and hence modeling of behaviour is not supported. Nevertheless,  pointcut  stereotypes can be used to decorate associations that link an  aspect  class to a base class. Instructions written in a proprietary, textual language are used to statically describe which operations of a base

302

3.

4.

5.

6.

J. Kienzle et al.

class are advised by operations defined in the aspect class. The main use of the approach being design documentation, model weaving is not supported. Aspect-Oriented Software Development with Use Cases of Jacobson et al. [22] The AOSD with Use Cases approach defines a software development process that emphasizes the separation of concerns from requirements elicitation with use cases down to the implementation. High-level models specified in the form of use cases slices are successively refined and mapped to design models that use class diagrams to represent structure and sequence diagrams to represent behaviour. In the end, the design is mapped to aspect-oriented code. As a consequence, model weaving is not needed, and hence not supported. The power of the approach is its support for traceability: explicit  trace  dependencies among artifacts produced at various stages of software development are used to link models that pertain to the same concern. Behavioral Aspect Weaving with the Approach of Klein et al. [23,24] This approach proposes a weaver for scenarios (sequence diagrams or Message Sequence Charts). An aspect is defined as a pair of scenarios. For instance, to weave an aspect sequence diagram into a target sequence diagram, the aspect sequence diagram is composed of a pair of sequence diagrams: one sequence diagram representing the pointcut (specification of the behavior to detect), and the other sequence diagram representing the advice that specifies the expected behavior at the join point. Similar to AspectJ, where an aspectual behavior can be inserted ’around ’, ’before’ or ’after ’ a join point, an advice in this behavioral weaving approach may extend the matched behavior, replace it with a new behavior, or remove it entirely. The approach defines a two-phased process weaving: 1) a generic detection where the pointcut is used to determine all the join points in the target model and 2) a generic composition mechanism where the advice model is composed with the target model at the join points previously detected. RAM uses this approach to weave the message views of the RAM aspect models. The Motorola WEAVR Approach of Cottenier et al. [25,26] The Motorola WEAVR approach and tool have been developed in an industrial setting. Behavior is modeled using the Specification and Description Language (SDL), a formalism related to state diagrams. In order to be able to reuse aspects, mappings have to be defined (equivalent to our instantiations) that link a reusable aspect to the application-specific context in which it is to be deployed. The WEAVR approach focuses exclusively on SDL, and supports model execution and code generation. The AOSD Profile of Aldawud et al. [27,28] The AOSD profile is a UML 1.x profile that can be used to model the structure of a concern using class diagrams and the behaviour using state diagrams. The AOSD profile is mostly aimed at modeling an aspect-oriented program, since model-weaving is currently not supported. Aspects are represented by an  aspect  stereotype, which is derived from the meta-class Class. Concurrent state machines are used to specify crosscutting behavior in orthogonal regions. The behaviour defined in different orthogonal regions is combined using event broadcasting.  crosscut 

Aspect-Oriented Design with Reusable Aspect Models

303

dependencies between aspects and base classes or aspects and aspects dictate the ordering in which events are propagated between the orthogonal regions. 7. The Theme/UML Approach of Clarke et al. [29] Theme/UML introduces a theme module that can be used to represent a concern at the modeling level. Themes are declaratively complete units of modularization, in which any of the diagrams available in the UML can be used to model one view of the structure and behavior the concern requires to execute. In Theme/UML, class diagrams and sequence diagrams are typically used to describe the structure and behavior of the concern being modeled. The binding to a base model is done by template parameter instantiation. 8. Aspect-Oriented Architecture Models of France et al. [30,31] The symmetric model composition technique proposed by France et al. [30,31] supports composition of model elements that present different views of the same concept. This composition technique has been implemented in a tool called Kompose [32,42]. The model elements to be composed must be of the same syntactic type, i.e., they must be instances of the same meta model class. An aspect view may also describe a concept that is not present in a target model, and vice versa. In these cases, the model elements are included in the composed model. The process of identifying model elements to compose is called element matching. To support automated element matching, each element type (i.e., the element’s meta-model class) is associated with a signature type that determines the uniqueness of elements in the type space: two elements with equivalent signatures represent the same concept and thus are composed. Currently, Kompose focuses mainly on the merging of class diagrams. RAM uses this approach to compose the structural views of the RAM aspect models. In [15], the authors present how to model the Observer Design Pattern using each of these 8 approaches, and show how to apply the observer pattern in the context of a model of a library management system. The authors then proceed to compare the 8 approaches according to 6 criteria: a) language, b) concern composition, c) asymmetric concern composition, d) symmetric concern composition, e) maturity, and f) tool support. In the following subsections, mimicking the presentation of [15], we show how to model the Observer Design Pattern aspect with RAM and how to apply the observer aspect to the library management system. We then proceed to evaluate RAM based on the 6 criteria presented in [15]. Note that for each of the 6 criteria, a table is proposed in [15] to summarize the evaluation of the 8 AOM approaches. In this section, we present the same tables for RAM, and point out the advantages or the disadvantages of RAM in comparison to the other approaches. Using this information, the interested reader can compare RAM with the 8 AOM approaches presented in [15]. Note that there are other AOM approaches that RAM could be compared to, such as UML Package Merge [33] which defines how the contents of one package are extended by the contents of another package, Whittle and Araujo’s approach [34], which represents behavioral aspects with scenarios, and the Whittle and Jayaraman approach called MATA [35].

304

4.1

J. Kienzle et al.

Observer Design Pattern and Library Management System

The classic Observer Design Pattern [9] is a software design pattern in which an object, called the subject, maintains a list of dependents, called observers. Whenever the subject’s state changes, it notifies all observers by calling one of the their operations. The observer design pattern has been used in many publications to demonstrate different aspect-oriented programming and aspectoriented modeling techniques. The Observer RAM aspect model is shown in Fig. 16. The structural view contains two partial classes, the |Subject and the |Observer class. The ZeroToManyAssociation aspect described in subsection 2.1 in Fig. 1 is reused to associate one subject to many observers. The Observer class defines the two public operations startObserving and stopObserving that allow an observer instance to register, rsp. deregister, with a subject instance. The two corresponding message views show that the operations add and remove, introduced by ZeroToManyAssociation, are used to update the set of observers of a subject. The Subject class defines the |m operation which represents operations that modify the state of the subject instance. The message view |m specifies that every call to |m is to be affected by the notification message view. Notification states that a call to callToBeObserved should be followed by a call to notify, which successively loops through all the registered observers (obtained by calling getAssociated provided by ZeroToManyAssociation) invoking the |update operation. The default instantiation states that all calls to instances of the class |Subject are to be observed, which means in our case that every call to |m is observed. The state view |Observer specifies that after invoking startObserving on an observer instance, any number of calls to |update are allowed to execute, until the stopObserving operation is executed. Fig. 17 shows how the Observer aspect is applied in the context of the Library Management System model. The observer instantiation directives in the structural view specify that instances of the BookCopy class are the subject of observation, and that instances of the BookManager class are the observers. The modifying operations are borrowBook and returnCopy, and the operation that should be called whenever a subject’s state is modified is updateBook. The structural view also shows that, in order to design the library management system, we were able to reuse many of the aspects that we designed for the CMS. Allocatable is used to remember the availability of a book copy. Locatable is reused to provide customers with an address. Finally, ZeroToMany is used to associate a book with many book copies as well as to associate a book with many authors. Books, customers and authors also reuse Named, an aspect from the AspectOptima framework that associates a name in form of a string with a class. The message view buyBook describes how, whenever a new copy of a book is bought, the book manager registers as an observer of the book copy by invoking startObserving. The most interesting message views are borrowCopy and returnCopy. They are both affected by the notification message view of the Observer aspect. The result of this is presented in Fig. 18, which illustrates the final

Aspect-Oriented Design with Reusable Aspect Models

aspect Observer depends on ZeroToMany structural view

|Subject
~ notify() + |m(..)

state view |Subject

|Observer

Pointcut

Advice

notify

Any

ZeroToMany instantiation AddAllowed → Any RemoveAllowed → Any Any→ Any

Any

Default Instantiation Any→ *

|m

startObserving Advice

Pointcut

state view |Observer |Uninterested

|Observing

|Subject |Observer |update |m

ZeroToMany instantiation |Data → |Subject |Associated → |Observer


+ startObserving(|Subject) + stopObserving(|Subject) ~ |update(|Subject)

|Uninterested

|update

|Uninterested |Observing

|Observing Default Instantiation |Uninterested→ * |Observing→ *

stopObserving message view |m affected by notification message view notification affected by getAssociated caller: Caller

target: |Subject

Advice

caller: Caller

|m(..)

target: |Subject |m(..)





notify()




Pointcut

observers := getAssociated()

Default Instantiation caller → *, Caller → *, target → *

loop [o within observers]

o: |Observer |update(target)

message view startObserving affected by add caller: Caller

target: |Observer

Advice caller: Caller

startObserving(s)

target: |Observer

s: |Subject

startObserving(s) add(s)

Pointcut

Default Instantiation caller → *, Caller → *, target → *

message view stopObserving affected by remove caller: Caller

target: |Observer

stopObserving(s)

Advice

caller: Caller

target: |Observer

s: |Subject

stopObserving(s) remove(s)

Pointcut

305

Default Instantiation caller → *, Caller → *, target → *

Fig. 16. The Observer Design Pattern Aspect modeled with RAM

306

J. Kienzle et al.

base Library depends on Observer, Named, ZeroToMany, Locatable structural view

BookCopy

Customer
+ String getName() + setName(String) + Location getAddress() + setAddress(Location)

borrowedBy 0..1

Observer instantiation |Subject → BookCopy |Observer → BookManager |update → updateBook |m → borrowCopy, returnCopy Locatable instantiation |Locatable → Customer getLocation → getAddress setLocation → setAddress Allocatable instantiation |Allocatable → BookCopy isAllocated → getAvailability ZeroToMany instantiation |Data → Book |Associated → Author ZeroToMany instantiation |Data → Book |Associated → BookCopy add → addCopy remove → removeCopy

int copyId + create(int id) + delete() + boolean getAvailability() + borrowCopy(Customer c) + returnCopy(Customer c)

Book String ISBN + create(String n, String i) + String getTitle() + String getISBN() + addCopy(BookCopy b) + removeCopy(BookCopy b)

Author
+ String getName() + setName(String)

BookManager
+ addBook(Book) + removeBook(Book) + searchBook(Book) + buyBook(BookCopy) + discardBook(BookCopy) ~ updateBook(BookCopy)

Public Named instantiation |Named → Customer Public Named instantiation |Named → Book Public Named instantiation |Named → Author

state view BookCopy

Existing

Observer.|Subject instantiation Any → Existing

borrowCopy Available

Taken returnCopy

create Any

delete

getAvailability state view Customer, Author, Book are uninteresting and have been skipped for space reasons

state view BookManager buyBook create

searchBook delete

Any removeBook addBook

discardBook

message view buyBook affected by startObserving

caller: Caller

manager: BookManager

buyBook(BookCopy b)

message view borrowCopy affected by notification, allocate







startObserving(b)

caller: Caller

book: BookCopy

borrowCopy(Customer c)

message view returnCopy affected by notification, deallocate

caller: Caller

book: BookCopy

returnCopy(Customer c)

message view updateBook affected by getAvailablity

caller: Caller

manager: BookManager

updateBook(BookCopy b)

Fig. 17. The Library Management System







allocate()







deallocate()

b: BookCopy

a := getAvailability()

Aspect-Oriented Design with Reusable Aspect Models message view borrowCopy

307

book: BookCopy

caller: Caller

borrowCopy(Customer c)







allocate()





notify()




observers := getAssociated() loop [o within observers]

o: BookManager updateCopy(book) a := getAvailability()

Fig. 18. Woven borrowCopy Message View

message view of borrowCopy after our weaver resolved all aspect model dependencies and created an independent base model. 4.2

Language

The first criteria that [15] use to compare different AOM approaches are the language criteria. The evaluation results for RAM for this criteria are presented in Table 1. A RAM aspect is specified with UML 2.x. The concepts of pointcut and advice are explicitly present in a RAM aspect. Consequently, the UML metamodel has been extended. A RAM aspect is composed of a class diagram, sequence diagrams and state diagrams. In [2] and in this paper, some guidelines have been stated on how to do aspect-oriented design using RAM, but we do not propose a full process description or a methodology yet. In [15], scalability is defined as “the ability to cope with small as well as large modeling projects”, and scalability is “investigated with respect to first, which high-level modeling elements of an approach support scalability, e.g., UML packages, and/or highlevel diagram types, and second, if scalability has been proven or not proven in real-world projects or by modeling examples that go beyond the composition of two concern modules”. In this context, by defining the depends on relationship between aspects, RAM proposes a way to describe a system with models at different levels of abstraction. The scalability of RAM has been demonstrated by 2 big case studies: AspectOptima and now also the CMS. The RAM aspects are

я

я

Tra raceability (L..T)

я

D

я

external

я

internal

~

AlignmenttoPh hase(L.A)

SD,SMD S , SM

RefinementMap pping (L.R)

CD C

highͲlevel modeling Sccalability elements (L..S) provenwith examples

guidlines

De esign Prrocess (L..DP) process description

Dia iagrams (L..D) Behavioral Diagrams (L.D)

я

Structural Diagrams (L.D)

UML1.X RAM

Platform Innnfluences(L.II.)

Metamodel Exxtension Mechanism Me UMLProfile (L..E)

я

Mo Modeling Laanguage (L..L) UML2.0

Table 1. “Language” applied to RAM

308

J. Kienzle et al.

woven according to the instantiation and binding directives expressed explicitly in the models. While this provides internal traceability, RAM currently does not provide external traceability, which is defined in [15] as “how aspect-oriented design models relate to the full software development life cycle”. Discussion: In [15], the authors identify several issues related to the 8 AOM approaches studied: 1. “Behavioral Diagrams are Catching up”: Only half of the studied approaches support behavioral diagrams. RAM stands out in this respect, because it currently supports the use of two kinds of behavioral diagrams (state and sequence diagrams). 2. “Missing Guidance in the Design Process”: Only the Theme/UML and AOSD with Use Cases approaches are integrated into the software development process, the other study approaches did not provide guidance on how the design models are created. RAM does not yet propose a methodology, but the large case studies used to describe RAM have allowed us to elaborate a set of design guidelines. 3. “Missing Full External Traceability”: Except from Theme/UML and AOSD with Use Cases, no approach supports external traceability. RAM also does not support external traceability. 4. “Moderate Scalability”: Only half of the studied approaches provide information hiding means for aspect models. Most studied approaches only showed examples containing a small number of aspects. Only Theme/UML, AOSD with Use Cases, and the Motorola WEAVR approach present examples that weave 3 or more aspects together. RAM clearly provides superior scalability. Each RAM aspect model defines a precise aspect interface, and the weaver performs automatic information hiding when the aspect is reused in some other model. The scalability of RAM has been demonstrated using 2 big case studies, where over 20 aspects were woven together to produce the final application model. 4.3

Concern Composition

The comparison of RAM with the other approaches according to the concern composition criteria is presented in Table 2. In RAM, a concern module is a special UML package that encapsulates all model elements related to the structure and/or behavior of a concern. The current version of RAM [2] supports aspect models that use class diagrams, state diagrams and sequence diagrams. RAM uses two composition mechanisms: 1. A compositor (CMP) to merge the class diagrams. This compositor is the symmetric model composition technique proposed by France et al. [30,31] which has been implemented in Kermeta in a tool called Kompose [32]. 2. A weaver where the aspects are expressed with a pair Pointcut-Advice (PA) to weave the behavioral diagrams.

Aspect-Oriented Design with Reusable Aspect Models

309

Table 2. “Concern Composition” applied to RAM

By supporting these two composition mechanisms, RAM supports both symmetric (composition base-base) and asymmetric (weaving aspect-base) paradigms. Currently, the effects of the weaving of a RAM aspect into a base model or into another aspect are not visually represented in the woven model. Note that we are currently working on using the same techniques as presented in [36,37] to automatically add tags (such as introduced, updated, ...) on the model elements of the woven model to clearly identify the effect of the weaving of an aspect model, if desired. The composition approach proposed by RAM for the behavioral diagrams is decomposed into two steps: a step of detection of the join points corresponding to the pointcut model, and a step of composition of the advice model at the level of the join points previously detected. This weaving process is static, in the sense that the weaving is not preformed while the models are executed, but rather during a separate weaving process. However, since the weaving is applied to behavioral models, the weaving of RAM aspects modifies the system run-time behavior. Also, the sequence diagram weaving technique employed by RAM [23] composes aspects based on the semantics of the sequence diagrams as opposed to the syntax. The final model that the RAM weaver produces is a “standard” UML diagram. Finally, RAM allows a modeler to specify the interaction between aspects (using explicit dependencies among aspects), and RAM provides means to the detection and the resolution of aspect conflicts. Discussion: In [15], the authors identify several issues related to the 8 AOM approaches studied: 1. “Popularity of Asymmetric Concern Composition”: Schauerhuber et al. note that “up to now little interest has been shown in evaluating when asymmetric and symmetric approaches have prevailing advantages and shall be employed ”. RAM combines symmetric and asymmetric composition approaches. Based on our experience, both paradigms are needed for an AOM approach to be general and reusable.

310

J. Kienzle et al.

2. “Composition often Deferred to Implementation”: [15] notes that composition at the modeling level is only supported by half of the surveyed approaches. RAM aspects can be composed at the modeling level. 3. “Moderate Support for Modeling Interactions”: Schauerhuber et al. argue that for an unambiguous specification of a system it is necessary to make module interaction explicit. They note that only the Motorola WEAVR approach explicitly specifies dependencies between aspects. In RAM, dependencies between aspects are clearly specified using explicit depends on links among aspect modules. This allows the weaver to automatically resolve indirect dependencies. As a result, aspect reuse is very simple: reusing a high-level aspect does not require the modeler to be aware of the low-level aspects that the high-level aspect depends on. 4. “Conflict Resolution Based on an Ordering for Composition, Only”: Only the approach of France et al. can detect syntactical conflicts among aspects. None of the surveyed approaches provide a sophisticated conflict resolution mechanism apart from specifying the composition order. RAM has strong support for conflict detection and resolution as explained in the following paragraphs. Aspect Model Conflicts. When several aspect models are applied within the same product model, conflicts can occur. A conflict between aspects A and B refers to the situation in which the correct model expressing the composition of the aspects A and B cannot be obtained by simply weaving A and B into the target model. In these situations, one or both of the aspect models’ structure and behavior must be modified to take into account the co-existence of the other aspect model. RAM does not allow to detect aspect conflicts automatically. However, our weaving tool can warn the modeler that two aspects are potentially conflicting. Conflicts occur only in a certain well-defined conditions: when the two aspects A and B are such that at least one of the pointcuts of A matches at least one of the elements within the pointcuts or advice of B. The following two special cases fall into this category: • When model elements from two aspects are bound to the same base model

elements, and one of the aspects removes structure or functionality from the elements it is applied to, and the other aspect expressed the presence of the removed functionality in one of its pointcuts. • When model elements from two aspects are bound to the same base model elements, and one of the aspects defines behavior that uses a template method call in its pointcut that matches a call in an advice of the other aspect. By cross-checking each aspect with each other aspect, our tool generates warnings listing the aspects that potentially conflict. However, our tool never reports a conflict between aspects A and B if A directly or indirectly depends on B, even if A’s pointcut matches elements of B’s pointcuts or advice or some of the generic elements of A are bound to the elements of B. In this case, we assume that the modeler who expressed the dependency is aware that both aspects apply

Aspect-Oriented Design with Reusable Aspect Models

311

to common modeling elements, and has designed A in a way that takes this into account. As a result, our tool only generates conflict warnings for aspect model pairs which are not linked by a dependency relationship. Once identified, conflicts can be resolved by the modeler by designing a conflict resolution aspect model as explained in section 2.4. The conflict resolution model contains conflict criteria conditions that specifies under which conditions the conflict occurs, and modification compartments that model the required adaptations that have to be applied to the conflicting models to resolve the conflict. Whenever all of the aspects that a conflict resolution model depends on are used within a target model, our tool automatically checks the conflict criteria specified in the conflict resolution model. If the condition is verified, the adaptations expressed in the modification are automatically applied to the target model. We did not identify many conflicts within the CCCMS. The only conflict is the one between OptimalResourceSearch, Locatable and Timing. The conflict resolution model shown in Fig. 11 demonstrates how OptimalResourceSearch is adapted in order to take resource and mission location into account when determining the best match for a given request. 4.4

Asymmetric Concern Composition

Table 3 shows the evaluation of RAM with respect to the asymmetric concern criteria. The asymmetric concern composition operator of RAM (the sequence diagram weaver [23,24] and GeKo [36,38]) allows a modeler to use any model element in the pointcut, and therefore any model element can be used as a join point. As a result, RAM supports the specification of both static and dynamic structural join points (for instance, class and objects respectively), but also static behavioral join points (such as message). However, RAM does not allow the specification of dynamic behavioral join points, which can only be detected at runtime. The join points in RAM are explicitly and formally defined (see [23,24,36]). The pointcuts are standardized, since a pointcut is an instance of

Table 3. “Aspectual Subject” and “Aspectual Kind” applied to RAM

312

J. Kienzle et al.

a given metamodel. For instance, for sequence diagram model weaving, a pointcut is a standardized sequence diagram. In RAM, a pointcut is graphical and not textual, and RAM partially supports refinement of pointcuts. The quantification method is declarative, but simple enumeration of join points is also possible. Finally, an advice can be added before or after a join point, but it can also replace a join point. The level of abstraction can be high, when a user of RAM specifies that an aspect depends on another aspect, but also low, because a join point detection mechanism can precisely define where the join points are. The “Aspectual Kind” table in Fig. 4 shows that in RAM an advice can be behavioral or structural, depending on the nature of the model used. A RAM aspect can express composite advice. The level of abstraction of a RAM aspect can be low (level of the model elements used), but also high because an aspect can depend on other aspects. Discussion: In [15], the authors identify several issues related to the 8 AOM approaches studied: 1. “Missing Formal Definition of Join Point Models”: Half of the surveyed approaches only implicitly define the join point model via their pointcut mechanism. The remaining approaches provide a join point model description in terms of natural language. The weavers used in RAM formally define the join point model for class, sequence and state diagrams. 2. “Modeling Aspectual Subjects at a Low Level of Abstraction”: [15] stresses that while all approaches allow a modeler to express low-level design, only half of the surveyed approaches support the creation of aspect models with a higher level of abstraction. RAM’s support for multi-abstraction level modeling is very elaborate: RAM aspects can form complex hierarchies, which allows a RAM aspect providing high-level functionality to depend on lowlevel functionality provided by other aspects. In addition, aspect models define clear aspect interfaces which hide dependencies on lower level aspects from the outside world. For the other points mentioned in [15] in the section discussing the asymmetric concern composition criteria, there are no real differences between RAM and the other approaches. 4.5

Symmetric Concern Composition

Asymmetric composition approaches make a distinction between aspect and base model elements, whereas symmetric approaches do not make this distinction [39]. Table 4 shows the evaluation of RAM for symmetric concern composition. To merge class diagrams, RAM uses the symmetric model composition technique proposed by France et al., which has been implemented in Kermeta in a tool called Kompose [32]. Consequently, concerning the symmetric composition technique, the features of both the approach proposed by France et al. and RAM are similar, and the comments on the France et al. approach presented in [15] are also valid for RAM.

Aspect-Oriented Design with Reusable Aspect Models

313

RAM

4.6

я

я

я

Ab bstraction (S.A A) low

high

B) Bind(S.B

Inttegration Strrategy Overidee(S.O)

Merge((S.M)

noͲmatcch

ements oral Ele Behavio Composseable Elementts (S.BCE) matchͲb byͲ name Maatch matchͲb byͲ Me ethod signaturre (S.MM)

Structurral Composseable Elementts (S.SCE) Co omp.

Table 4. “Symmetric Concern Composition” applied to RAM

я я я я я

Maturity

Table 5 shows the summary of the maturity evaluation of RAM. Until now, RAM has been applied to two big case studies and several small academic examples. The current version of the AspectOptima case study has 18 RAM aspect models and 5 conflict resolution models. The CCCMS model presented in this paper has 23 aspect models and 1 conflict resolution model. RAM has been published in the main conference of the domain (AOSD, [2]), plus a workshop and a master thesis [6,1]. Moreover, the AOM weaving techniques on which RAM is based on (France approach, Klein approach) have been largely published in high quality conferences or journals [30,31,23,24]. The most recent publication related to RAM was in 2009 [2]. Table 5. “Maturity” applied to RAM

Discussion: In [15], the authors identify several issues related to the 8 AOM approaches studied: 1. “Missing Complex Examples”: In [15], the authors state “The majority of the surveyed approaches have demonstrated their techniques on the basis of rather trivial examples in which not more than two concerns are composed. In this respect, Jacobson, Cottenier et al., and Clarke et al. set a good example by demonstrating their approaches with non-trivial modeling problems.” RAM has been demonstrated with the AspectOptima and Crisis Management System cases studies, which are large and non-trivial case studies coming from two different domains.

314

J. Kienzle et al.

2. “Lack of Application in Real-World Projects”: The approach of Pawlak et al. has been applied to 3 industrial projects. The Motorola WEAVR is currently used inside Motorola for software development. So far, RAM has not been applied in the context of a real-world project. 4.7

Tool Support

In order to use aspect-oriented modeling techniques to build real-world size models, tool support is essential. We have implemented a RAM tool prototype within the Kermeta [40] environment, an imperative, object-oriented language suitable for the specification of model transformations. Kermeta runs within the Eclipse Modeling Framework, which allows us to use the Eclipse tools to edit, store and visualize models. The RAM prototype is available online3 . Table 6 summarizes the features our tool currently supports. To weave our class diagrams, we use the symmetric model composition technique proposed by France et al. [30,31], which has been implemented in Kermeta in a tool called Kompose [32]. To weave our behavior models, we use the implementation of a sequence diagram weaver proposed in [23,24].

я

я

ode Co eneration Ge (T..G)

omposition Co pport(T.C) Sup

RAM

odeling Mo pport(T.M) Sup

Table 6. “Tool Support” applied to RAM

In order to also support the weaving of state diagrams, we are currently working on replacing the Kompose and sequence diagram weaver with GeKo [38], a generic aspect-oriented model composition and weaving approach that can be used to weave any kind of model with a well-defined meta model. Discussion: In [15], the authors comment on “Missing Tool Support for Composition and Code Generation” for the 8 surveyed approaches. While modeling support in many approaches is implicitly available due to the use of UML’s profile mechanism, support for code generation and composition is rare. The approach of Cottenier et al. is the only one that allows for modeling, composition, and code generation. The approaches by France et al. and Klein et al. provide model weaving only. Even if the tool supporting RAM is currently only a prototype, since RAM is based on Kompose (France et al.) and the Sequence Diagram Weaver (Klein et al.), the tool can generate independent aspect models and final application models consisting of class and sequence diagrams. Once the final application model is generated, it can be mapped to code using “standard” 3

http://se2c.uni.lu/tiki-index.php?page=AspectOptima+Modeling

Aspect-Oriented Design with Reusable Aspect Models

315

mapping techniques. Our prototye tool does not provide this functionality, but since we output the model in XMI, it is possible to load the generated model in a standard UML tool that supports code generation. However, the behavioral models of RAM only specify message exchanges between objects, as well as optional, alternative and looping control flows. As a result, only code skeletons for all classes and operations can be generated. When working with real-world size models, scalability of the tool itself is of great importance. Since our weaving algorithm performs composition in pairs, we do not face algorithmic challenges when augmenting the number of aspects in a design. For each additional aspect model that is instantiated, only one additional weaving step must be performed. However, the independent aspect models, and of course the final application model, grow as more aspects are added to the system. Currently, our tool requires all models, i.e. the source, the aspect and the target model, to fit into main memory. The performance of our prototype is currently not optimal. The creation of the independent model of the CreateMission aspect takes several minutes. There are many factors that contribute to this slow performance: 1. The version of Kermeta we are running is interpreted. We are hoping to be able to run the prototype with the compiled version soon. 2. We are exporting, in XMI, all intermediately generated independent aspect models. This step speeds up the weaving for aspects that are reused several times, since the independent aspect model is only generated once, but slows down the weaving for aspects that are used only once. Currently, we generate all the models for debugging reasons, but our recursive weaving algorithm could be adapted to only save independent aspect models that are reused again at a later time. 3. We are outputting lots of debugging information into the Eclipse console. This step could be omitted.

5

Discussion on Reuse

A comparison criteria that has been explicitly excluded from the study presented in [15] is reusability. The authors argue justifiably that reusability cannot reasonably be measured without empirical studies. Reuse is one of the main strength of RAM, since RAM has been designed to allow the modeler to develop highly reusable aspect models. We have not performed in-depth studies to back up this claim with empirical evidence. However, we successfully reused aspect models within the design of the CCCMS. Using the CCCMS models as example, this section points out the features of RAM that specifically support reuse. 5.1

Encapsulation and Information Hiding

In RAM, a special UML package encapsulates all model elements that define the structure and behavior of an aspect. This aspect package is the unit of reuse. The interface of the aspect consists of the set of public operations defined by the

316

J. Kienzle et al.

classes in the structural view of the aspect. By hiding design decisions that are likely to change behind a well-designed interface, information hiding principles as defined by [41] can be applied to aspects, sometimes even more effectively as for objects [3]. For instance, in the CCCMS, the ResourceSearch aspect shown in Fig. 6 defines an interface that allows a user to create requests, to add the desired capabilities, and to perform a resource search. Internal design decisions, such as the fact that a request is implemented using a map, are hidden from the outside world. 5.2

Reuse Hierarchies

RAM supports the creation of elaborate aspect dependency chains. This makes it possible to model aspects that provide complex functionality by decomposing them into aspects that provide simpler functionality. Vice versa, aspects providing simpler functionality can be reused in several aspects of complex functionality. As a result, scattering and tangling of models can be prevented at all levels of abstraction. 5.3

Consistent Reuse with Tool Assistance

To make reuse possible, it is important that instantiations and bindings observe strict rules: if an aspect A provides a functionality whose design needs a simpler functionality provided by an aspect B, then A depends on B. In this case, and only then, A is allowed to instantiate views of B, or bind A’s model elements to model elements defined in B. Circular dependencies are forbidden. Each aspect model that defines partial classes clearly identifies those classes as mandatory instantiation parameters. To help the modeler when reusing an existing aspect model, our tool (see subsection 3.1) ensures that compatible model elements are provided for all mandatory instantiation parameters when the aspect is instantiated. Flexibility is achieved by allowing any model element to optionally be instantiated or extended through bindings, if desired. Finally, to facilitate the composition process, an aspect model can also define bindings that are used as defaults when an aspect model is instantiated. In the case where A reuses B and the modeler designing A decides to override the bindings specified in B with his own instantiation directives, our tool ensures that the new directives are compatible [2]. Thanks to the above, reusing an aspect model in a consistent way within another model is simple. Indirect dependencies of aspects are hidden from the user of an aspect: when a developer reuses an aspect A by instantiating it, our tool takes care of performing the indirect instantiations and bindings of aspects that A depends on. To fully exploit the benefits of reuse, aspect dependencies are kept unresolved until the aspects are woven with the final model. As a result, if A directly or indirectly depends on B, then a change that is made to B is automatically propagated to A when the final model is created. In case there are any conflicts between aspect models that are reused and that have been identified by the designers of the reused aspects, the tool automatically applies the appropriate conflict resolution aspect models.

Aspect-Oriented Design with Reusable Aspect Models

317

Keeping aspect dependencies unresolved also facilitates maintenance: in the case where the design of a low-level aspect is improved, the new design is propagated automatically to all higher level aspects that depend on the improved aspect when the higher models are re-woven. 5.4

Reuse in the CCCMS

Among the 23 aspect models we created for this case study, all aspects except Initialization and CreateMission are generally reusable in the sense that they do not contain any CCCMS-specific model elements. They could be reused in any application that requires the functionality that they provide. But even within the CCCMS design, reuse of aspects is happening at several abstraction levels. Map is an example of a low-level aspect that is reused in many higher level aspects: it is reused in ResourceSearch, where a request is implemented using Map; it is reused in NetworkedCommand, where a map is created that stores existing channels to communicate with remote hosts for future use; it is reused in Workflow, where a map is used to associate a variable to its name; and finally, it is reused in CreateMission, where a map is used to find the receiver queue corresponding to a given crisis. Many of the aspects grouped under the name “Generic / Design Pattern Aspects” in Fig. 14 are used frequently in other applications as well. That is the reason why most programming languages provide standard libraries that offer such functionality, especially if the functionality can easily be encapsulated in an object. An indication that our low-level aspect models are reusable is the fact that when designing the CCCMS we were actually able to reuse some of the models designed for our first big case study to which we applied the RAM approach: the AspectOptima case study [5,14]. For instance, Map and ZeroToManyAssociation are low-level aspects that are also used within the AspectOptima RAM models [2]. ZeroToManyAssociation was also reused in the Observer aspect model as well as the Library Management System model presented in section 4. Within the CCCMS design, an example of an aspect that is not in the “Generic / Design Pattern Aspects” group that is reused is Locatable: it is instantiated several times in Initialization to associate a location with workers, vehicles and missions. Locatable was also reused in the Library Management System to associate an address with a customer. If we had completed more of the design, we would have probably reused even more higher level aspects. For example, the resource management aspects could be reused in a CCCMS that supports missions with several scenarios that can lead to their fulfillment. In this case, when a super observer orders the execution of a specific mission, the backend would have to determine the most appropriate scenario for the mission under the current crisis conditions. ResourceSearch could be reused to accomplish that task: the resource would be the scenario, and the capability of the resource is the kind of mission that a scenario can deal with. Finally, the aspects grouped under “Communication Aspects” in Fig. 14 are encountered in many distributed applications. For instance, multi-player turn-based games often use the NetworkedCommand design to send player movements to the other players.

318

6

J. Kienzle et al.

Conclusion

This paper presented an aspect-oriented design of parts of the crisis management systems case study based on the Reusable Aspect Models approach. In total, 23 aspect models forming a hierarchy of inter-dependent aspects were created to model the create mission functionality of the crisis management system backend. This experience confirms that the features of RAM allow a modeler to design aspects that provide complex functionality by decomposing them into aspects that provide simpler functionality. Vice versa, aspects providing simpler functionality can be reused in several aspects of complex functionality. As a result, scattering and tangling of models can be prevented at all complexity levels. The crisis management system case study was specifically proposed in [12] as a case study for aspect-oriented modeling and aspect-oriented software development in general. In addition to demonstrating the power of aspect-oriented modeling during the software design phase, the results presented in this paper can be analyzed in the light of the results obtained using other AOM approaches applied to the crisis management system. Not only will this allow us to compare RAM to other aspect-oriented design approaches more accurately than we did in this paper, it will also give us more insight into how to bridge the gap between aspect-oriented approaches that work at the requirements engineering phase and approaches such as RAM that work at the detailed design phase. Understanding this transition is a key step towards the creation of an aspect-oriented software development process.

Acknowledgement This work was partially supported by the SPLIT project (FNR and CNRS funding), the DiVA project (EU FP7 STREP, contract 215412, http://www.ictdiva.eu/) and the Natural Sciences and Engineering Research Council of Canada.

References 1. Klein, J., Kienzle, J.: Reusable Aspect Models. In: 11th Aspect-Oriented Modeling Workshop, Nashville, TN, USA, September 30 (2007) 2. Kienzle, J., Abed, W.A., Klein, J.: Aspect-Oriented Multi-View Modeling. In: Proceedings of the 8th International Conference on Aspect-Oriented Software Development - AOSD 2009, March 1-6, pp. 87–98. ACM Press, New York (2009) 3. Abed, W.A., Kienzle, J.: Aspect-Oriented Modeling and Information Hiding. In: 14th Aspect-Oriented Modeling Workshop, Denver, CO, USA, October 4, pp. 1–6 (2009) 4. Kienzle, J., Gélineau, S.: AO Challenge: Implementing the ACID Properties for Transactional Objects. In: AOSD 2006, pp. 202–213. ACM Press, New York (2006) 5. Kienzle, J., Bölükbaşi, G.: AspectOPTIMA: An Aspect-Oriented Framework for the Generation of Transaction Middleware. Technical Report SOCS-TR-2008.4, McGill University, Montreal, Canada (2008) 6. Bölükbaşi, G.: Aspectual Decomposition of Transactions. Master’s thesis, School of Computer Science, McGill University, Montreal, Canada (June 2007)

Aspect-Oriented Design with Reusable Aspect Models

319

7. Kienzle, J., Guelfi, N., Mustafiz, S.: Crisis Management Systems: A Case Study for Aspect-Oriented Modeling. Transactions on Aspect-Oriented Software Development 7, 1–22 (2010) 8. Kienzle, J.: Reusable Aspect Models of the Crisis Management System (2009), http://www.cs.mcgill.ca/~joerg/SEL/RAM_Case_Study.html 9. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns. Addison Wesley, Reading (1995) 10. Riehle, D., Siberski, W., Bäumer, D., Megert, D., Zülighoven, H.: Serializer, pp. 293–312 (1997) 11. Chitchyan, R., Fabry, J., Katz, S., Rensink, A.: Special Section on Dependencies and Interactions with Aspects. Transactions on Aspect-Oriented Software Development 5, 133–134 (2009) 12. Kienzle, J., Guelfi, N., Mustafiz, S.: Crisis Management Systems – A Case Study for Aspect-Oriented Modeling. Technical Report SOCS-TR-2009.3, McGill University, Montreal, Canada (2009) 13. Rashid, A.: Aspect-Oriented Database Systems. Springer, Heidelberg (2004) 14. Kienzle, J., Duala-Ekoko, E., Gélineau, S.: AspectOPTIMA: A Case Study on Aspect Dependencies and Interactions. Transactions on Aspect-Oriented Software Development 5, 187–234 (2009) 15. Schauerhuber, A., Schwinger, W., Kapsammer, E., Retschitzegger, W., Wimmer, M., Kappel, G.: A survey on aspect-oriented modeling approaches. Technical report, Business Informatics Group, Vienna University of Technology (2006), http://www.wit.at/people/schauerhuber/publications/aomSurvey/ 16. Stein, D., Hanenberg, S., Unland, R.: A UML-based aspect-oriented design notation for aspectJ. In: AOSD, pp. 106–112 (2002) 17. Stein, D., Hanenberg, S., Unland, R.: Expressing different conceptual models of join point selections in aspect-oriented design. In: AOSD 2006: Proceedings of the 5th international conference on Aspect-Oriented Software Development, pp. 15–26. ACM Press, New York (2006) 18. Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W.G.: An overview of aspectj. In: Knudsen, J.L. (ed.) ECOOP 2001. LNCS, vol. 2072, pp. 327–353. Springer, Heidelberg (2001) 19. Hanenberg, S., Stein, D., Unland, R.: From aspect-oriented design to aspectoriented programs: tool-supported translation of jpdds into code. In: AOSD 2007 (2007) 20. Pawlak, R., Duchien, L., Florin, G., Legond-Aubry, F., Seinturier, L., Martelli, L.: A uml notation for aspect-oriented software design. In: First Workshop on AspectOriented Modeling with UML, AOSD 2002 (2002) 21. Pawlak, R., Seinturier, L., Duchien, L., Martelli, L., Legond-Aubry, F., Florin, G.: Aspect-oriented software development with java aspect components. aspectoriented software development. In: Filman, R.E., Elrad, T., Clarke, S., Aksit, M. (eds.), ch. 16, pp. 343–369 (2005) 22. Jacobson, I., Ng, P.W.: Aspect-Oriented Software Development with Use Cases. Addison-Wesley, Reading (2004) 23. Klein, J., Hélouet, L., Jézéquel, J.M.: Semantic-based weaving of scenarios. In: AOSD 2006: Proceedings of the 5th international conference on Aspect-Oriented Software Development, Bonn, Germany, ACM, New York (2006) 24. Klein, J., Fleurey, F., Jézéquel, J.M.: Weaving multiple aspects in sequence diagrams. Transactions on Aspect-Oriented Software Development (TAOSD) III, 167– 199 (2007)

320

J. Kienzle et al.

25. 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) 26. Cottenier, T., Berg, A.V.D., Elrad, T.: The motoroal weavr: Model weaving in a large industrial context. In: Industry Track of the 5th International Conference on Aspect-Oriented Software Development (AOSD 2006), Bonn, Germany, ACM, New York (2006) 27. Aldawud, O., Elrad, T., Bader, A.: Uml profile for aspect-oriented software development. In: 3rd International Workshop on Aspect Oriented Modeling, In conjonction of AOSD 2003, Boston, Massachusetts (March 2003) 28. Elrad, T., Aldawud, O., Bader, A.: Expressing aspects using uml behavioral and structural diagrams. In: Filman, R.E., Elrad, T., Clarke, S., Aksit, M. (eds.) Aspect-oriented software development (2005) 29. Clarke, S., Baniassad, E.: Aspect-Oriented Analysis and Design: The Theme Approach. Addison Wesley, Reading (2005) ISBN: 0-321-24674-8 30. France, R., Ray, I., Georg, G., Ghosh, S.: Aspect-oriented approach to early design modelling. IEE Proceedings Software, 173–185 (August 2004) 31. Reddy, R., Ghosh, S., France, R.B., Straw, G., Bieman, J.M., Song, E., Georg, G.: Directives for composing aspect-oriented design class models. Transactions on Aspect-Oriented Software Development (TAOSD) I, 75–105 (2006) 32. Fleurey, F., Baudry, B., France, R., Ghosh, S.: A generic approach for automatic model composition. In: 11th Workshop on Aspect-Oriented Modeling, AOM at Models 2007 (2007) 33. OMG: Uml superstructure, v2.1.1 (OMG Document number formal/07-02-05) 34. Whittle, J., Araújo, J.: Scenario modelling with aspects. IEE Proceedings - Software 151(4), 157–172 (2004) 35. Whittle, J., Jayaraman, P.: Mata: A tool for aspect-oriented modeling based on graph transformation. In: 11th Workshop on Aspect-Oriented Modeling, AOM at Models 2007 (2007) 36. Morin, B., Klein, J., Kienzle, J., Barais, O., Jézéquel, J.M.: Geko: A generic aspect model weaver. Transactions on Aspect Oriented Software Development, TAOSD (2010) (Under Submission (major changes)) 37. Klein, J., Kienzle, J., Morin, B., Jézéquel, J.M.: Aspect model unweaving. In: Schürr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, pp. 514–530. Springer, Heidelberg (2009) 38. Morin, B., Klein, J., Barais, O., Jezequel, J.-M.: A generic weaver for supporting product lines. In: Early Aspects Workshop at ICSE, Germany, ACM, New York (2008) 39. Harrison, W.H., Ossher, H.L., Tarr, P.L., Harrison, W.: Asymmetrically vs. symmetrically organized paradigms for software composition. Technical report, Research Report RC22685, IBM Thomas J. Watson Research (2002) 40. Muller, P.-A., Fleurey, F., Jézéquel, J.-M.: Weaving executability into objectoriented meta-languages. In: MODELS/UML 2005. LNCS, Springer, Heidelberg (2005) 41. Parnas, D.L.: On the criteria to be used in decomposing systems into modules. Communications of the ACM 15(12), 1053–1058 (1972) 42. France, R., Fleurey, F., Reddy, R., Baudry, B., Ghosh, S.: Providing Support for Model Composition in Metamodels. In: Entreprise Distributed Object Computing Conference, EDOC 2007, Annapolis, MD, USA (2007)

A Graph-Based Aspect Interference Detection Approach for UML-Based Aspect-Oriented Models Selim Ciraci, Wilke Havinga, Mehmet Aksit, Christoph Bockisch, and Pim van den Broek University of Twente, P.O. Box 217, 7500 AE Enschede, The Netherlands {s.ciraci,w.havinga,m.aksit,c.m.bockisch}@ewi.utwente.nl, [email protected]

Abstract. Aspect-Oriented Modeling (AOM) techniques facilitate separate modeling of concerns and allow for a more flexible composition of the resulting models than traditional techniques. While this improves the understandability of each submodel, in order to reason about the behavior of the composed system and to detect conflicts among submodels, automated tool support is required. We propose a technique and tool support for fully automatic detection of conflicts between aspects at the model level; more specifically, our approach works on models defined in UML with an extension for modeling pointcuts and advice. As back-end we use a graph-based model checker, for which we have defined an operational semantics of UML diagrams, pointcuts and advice. In order to simulate the system, we automatically derive a graph model from the diagrams. The simulation result is another graph, which represents all possible program executions, and which can be verified against a declarative specification of invariants. To demonstrate our approach, we discuss a UML-based AOM model of the “Crisis Management System” (CMS) and a possible design and evolution scenario. The complexity of the system makes conflicts among composed aspects hard to detect: already in the case of five simulated aspects, the state space contains 9991 different states and 99 different execution paths. Nevertheless, using appropriate pruning methods, the state space only grows polynomially with the number of aspects. In practical cases, the order of the polynomial is very small, e.g., 2 in the case of the simulated CMS; therefore, the automatic analysis scales.

1

Introduction

The goal of Aspect-Oriented Modeling (AOM) [37, 8] is to improve the modularity of software designs, and this is commonly supported by allowing the specification of different (partial) views on the same system, which may overlap after composition. This improves the potential for separate views of the system to evolve in isolation, i.e., without affecting multiple models in several places. Consequently, AOM bears the potential to increase the global understandability of a model, as smaller submodels — the partial views — can be inspected separately. S. Katz et al. (Eds.): Transactions on AOSD VII, LNCS 6210, pp. 321–374, 2010. c Springer-Verlag Berlin Heidelberg 2010 

322

S. Ciraci et al.

One downside of the flexible composition mechanisms in AOM is that local understandability is reduced. Detailed understanding of single facets of the behavior in the composed system is difficult because the details of the composition are, on purpose, hidden from the beholder. Therefore, it is difficult to ensure the absence of conflicts1 in the composed system by manual inspection. This downside reduces the benefit of an improved modular structure facilitated by AOM, which is a common theme among comments from industry, e.g., in [13]. This disadvantage is especially important when considering that each separate view of the model may evolve in isolation, and each may be maintained by different engineers. Through the separation it becomes harder to ensure that the composed system works together as intended. For these reasons, we believe that it is important to support the AOM development process by means of tools that detect conflicts in situations when aspects semantically interact with each other. That is, it must be possible to detect semantic interference among aspects. Several techniques exist for automatically detecting conflicts between aspects at the implementation level [3,24], but detecting conflicts early at the model level has a number of advantages: – Models are more abstract than code. Therefore, fixing errors in the design prospectively is cheaper than fixing errors in the code. – When errors are recognized and fixed at the model level, one source of the code’s deviation from the model is eliminated. Thus, model versioning and consistency enforcement activities can be avoided. – In the case of model-based code generation, aspect interference detection at the code level may even become unnecessary. – As the AOM model is independent of the technique and language later used to implement the system, model-based conflict detection is also independent of these concerns. Conflict-detection approaches require an abstract semantic model of the overall system. Only a few approaches have been proposed in the past to provide such an abstract model in the design phase and for systems containing aspects. In their case, the abstract model has to be defined separately, i.e., in addition to the design model, for each new system [33, 32] in a specific, limited AOM approach. To achieve the itemized benefits of model-level conflict detection in an AOM approach without additional efforts for the designer, we propose a technique for automatic, tool-supported detection of semantic interference among aspects at the model level that is independent of the AOM approach used in the design phase. This paper provides tool support that is applicable to any AOM approach extending the UML, which is the majority. Different AOM approaches differ in the way how the UML is extended and in the crosscutting concerns they can successfully modularize. 1

In the context of this paper, conflicts are understood as undesired execution sequences. This occurs either because methods are wrongly executed or not executed, or because the order of method executions is wrong.

A Graph-Based Aspect Interference Detection Approach

323

To achieve such tool support, we specialize the graph-based model checker GROOVE [23] to simulate UML-based aspect-oriented models and verify that the execution orders conform with the desired behavior of the software system. The simulation is a foundation of the verification as it generates all the execution sequences supported by the input UML-based aspect-oriented models. To facilitate the simulation, an operational semantics of the UML is modeled as graph transformations; triggering the relevant transformations allows us to simulate the runtime behavior of the model. To account for aspect-oriented extensions of the UML, we furthermore include graph transformations that allow the implicit inclusion of advice at join points. This mechanism makes our approach independent of the actual pointcut and pointcut-advice bindings whose expressiveness is determined by the used AOM approach. The output of the simulation is a state space, which is a tree with some merged branches, explicitly showing which software artifacts have executed in which execution sequence. In terms of temporal logic formulas, the user can define requirements for the order of method executions that must always be satisfied in the execution, i.e., invariants of the system. The model checker, which we are using, evaluates these formulas for each execution sequence in the state space in order to identify execution sequences that violate the constraint. That is, our model checker allows us not only to detect that conflicts are possible, but it also shows under which conditions the conflicts take effect. Conflict detection is mission critical in large software systems like a “Crisis Management System” (CMS) which cannot afford to expose unanticipated behavior. Thus, in this paper, we will demonstrate how to apply our verification approach to the aspect-oriented modeling of the CMS case study. Therefore, we had to concretize the model provided in the common case study; specifically, we have modeled the concerns that relate to the crisis-managing scenarios as aspects. With our graph-based model checker, we have been able to detect semantic interference among two independently developed scenarios. The size of the simulated state space, namely 9991 states, 10234 transitions and 99 execution paths, shows that tool support is crucial to verify the behavior of a system like the CMS. The size of the state space of our simulation grows polynomially with the number of aspects. In practical cases, the order of the polynomial is even very small, for example in the simulation of the CMS, the number of states is of the order O(n2 ). Therefore, the simulation also scales to reasonably large systems. The contributions of this paper are threefold: 1. For a graph-based model checker, we have defined graph-transformation rules that constitute an operational semantics for aspect-oriented models. The semantics is an accurate representation of the core runtime behavior of the models. It requires to resolve pointcuts and advice according to the semantics of the actually used AOM approach, and is, thus, applicable to all such approaches.

324

S. Ciraci et al.

2. Applying this operational semantics with a model checker, we can automatically detect violations of invariants at the modeling level. In an AOM design, this can be used to detect semantic interferences among aspects. As input, our tool only requires a declarative description of invariants and a graph-based representation of the AOM model, which can be derived in an automated way from UML models; different aspect-oriented extensions to UML can be mapped to this graph-based representation. 3. We show that our approach is applicable to large-scale software by the example of the “Crisis Management System”. Therefore, we discuss a possible design and evolution scenario of this system where aspects conflict in nonobvious ways. With our approach, it is possible to detect these interferences at the model level. The structure of this paper is as follows. We outline our approach at a very high level in Section 2. In Section 3, we discuss an AOM model for the “Crisis Management System”, including an overview of AOM in general and Theme/UML in particular, which we use to show AOM models throughout this paper. Our approach is discussed in detail in Section 4; we start by presenting a motivating example in Section 4.1, followed by a presentation of the graph model used in the simulation and its relation to UML diagrams in Section 4.2; in Section 4.3, we present the means by which our model supports aspect-oriented models. In Sections 4.4 and 4.5, we discuss the operational semantics of our model and the verification of invariants in the simulated state space. We discuss the application of our approach to the CMS case study and present performance figures in Section 5. In Section 6, we present related work before we reflect on our approach and conclude in Section 7.

2

An Approach for Graph-Based Model Checking of AOM for Aspect Interference Detection

In this section, we explain how our approach works from the perspective of an application designer, e.g. the engineers designing the Crisis Management System that is the subject of this special issue. Figure 1 shows the activities involved in using our tooling. The first step relevant to our approach (marked ‘1’ in the diagram) is that the designer creates UML-based models of the system. In this paper, we focus especially on class and sequence diagrams, which model the structure and (partially) the order in which interactions with and within the system should occur. It is important to verify these models in particular, because, as we will show, interference may already occur at this level. Especially in the presence of aspects, this may not be straightforward to “detect” manually. Of course, additional models may also be created in (or before) the design phase, but we do not focus on those in this paper. As shown in figure 1, the class and sequence diagrams may use AOM-specific extensions; in this paper, we have used Theme/UML [12], which

A Graph-Based Aspect Interference Detection Approach

325

UML-based models Class diagrams Sequence diagrams

AOM-specific extensions

<using> <using> <using>

Theme/UML

...

1

...

2

Write UML models and constraints

3

Convert UML to DCML model

Application designer

Simulate DCML-model using Groove

4 Model-check state-space

Tool-supported Conflict rule specifications Application constraints/ invariants (CTL)

Fig. 1. An overview of our verification approach

is an existing AOM approach (not developed by the authors of this paper). Other AOM extensions may also be used, as long as these can be mapped to the Design Configuration Modeling Language (DCML) model that is used in second step — this will of course involve some effort from the designer of the respective AOM approach. Our design of the Crisis Management System, focusing particularly on class and sequence diagrams, is discussed in detail in section 3. The next step, marked ‘2’ in the diagram, is to convert the UML-based diagrams to DCML, an existing modeling approach that defines an operational semantics for UML-based models. The conversion of “standard” UML class- and sequence models is described in prior work [9]; to support an AOM extension to UML, it is necessary to augment the conversion step with conversion rules that interpret the aspect-related extensions. This is discussed in subsection 4.3, taking the Theme/UML-based models as an example of how such a mapping can be defined. Once the UML/AOM models have been converted to DCML, step 3 is to use an existing tool chain to simulate the execution semantics of these models; this is discussed in subsection 4.5. Using the results from the simulation step, the last step (marked ‘4’ in the diagram) is to model check the simulation results with regard to the constraints that have been specified by the application designer in step 1. Section 5 discusses how our entire approach is applied to the Crisis Management System case study.

326

3 3.1

S. Ciraci et al.

Designing the Crisis Management System Using AOM A Brief Overview of AOM Approaches

To date, a substantial number of AOM approaches have been proposed [37, 8]. Many of these modeling approaches define UML extensions that support the modular expression of crosscutting elements [17, 12, 5]. Although each modeling approach facilitates the expression of crosscutting behavior in different ways, these approaches share many common characteristics. Typically, a user first identifies crosscutting concerns in the system under design. This can be done manually or supported by tools, such as EA-miner [36]. Then, the system is designed using a mix of regular UML-based models (such as class diagrams, sequence diagrams, etc.) and aspect-specific extensions that model crosscutting (structural or behavioral) elements. In this paper, we focus on the use of such UML-based approaches. 3.2

On the Use of Theme/UML

For the purpose of designing the Crisis Management System we chose to use Theme/UML [12], a representative member of the UML-based approaches mentioned above. The use of specific AOM approaches is however not the focus of this paper, as the problem of semantic interference among aspects is inherent to all AOM approaches. In section 4, we discuss the requirements under which AOM-specific UML extensions can be mapped to our approach in general, and the mapping for Theme/UML in specific. Since the mapping typically appears to affect only a small part of the modeling approach (e.g. mapping the specific ways in which pointcuts and advice are modeled), we expect this to be possible with reasonable effort. For a detailed description, please refer to publications about Theme/UML [6, 11, 12]. Here, we only discuss the main principles of using Theme/UML, as needed to follow the discussion in this paper. Seen from a user perspective, Theme/UML adds two important features to UML models: it allows (1) the separation of structural concerns, and (2) the expression of crosscutting behavior. Structural elements (such as — potentially partial — class definitions) can be separated into “themes”, which can then be composed into a coherent system by means of a composition specification. For example, a simple composition specification might simply merge the partial classes (defined in several themes) based on their names. This way, Theme/UML supports the modular expression of crosscutting structure. Crosscutting behavior can be expressed by allowing the use of “template parameters”, such as class parameters or method parameters in various models — most importantly, in sequence diagrams. A “template parameter” may be bound by a composition specification to zero or more actual classes or methods, for example indicating that a particular sequence of events should be initiated whenever one of the bound parameter methods is invoked. In this sense, such composition (“parameter binding”) specifications can be considered a “pointcut”, whereas a

A Graph-Based Aspect Interference Detection Approach

327

sequence of events that is specified (using a sequence diagram) to follow the invocation of such a bound parameter can be considered an “advice”. 3.3

Concern Identification

There are many alternative ways to define a modular structure for the Crisis Management System described in the case study. Typically, the choice for particular design alternatives would be driven by evaluating relevant trade-offs against the characteristics that are deemed most important by the various stakeholders. For example, the convenience of a given design may be judged with respect to optimized performance, ease of configuration or use, enforcement of security, etc. In this subsection, we describe one possible design, which will be used as an example throughout this paper. As the design as such is not our main focus, we do not describe all the trade-offs made to reach this design in detail, however. Several concerns that are relevant to the CMS are: – Coordination. To facilitate dealing with crisis situations in an efficient manner, an automated system should actively support the coordination of mission- and resource assignment. By coordination, we mean the support for standardized scenarios — which may vary based on the type and severity of a crisis — for requesting resources, defining missions, dealing with reports and requests for assistance from workers, etc. – Resource allocation. To support the handling of crises with a limited amount of resources, the system should support means to optimally allocate available resources. Since optimal strategies may depend on (e.g. national) policies as well as circumstances (number of concurrent crises, scarcity of certain resources), the system should support multiple allocation strategies, as well as pre-emption of resources in low-resource situations, if appropriate. – Real-time monitoring. To satisfy the requirement of real-time status reports on the availability of resources, mission progress, etc., it is necessary to keep the necessary statistical information up-to-date while the system is running. This way, it is ready to be used at any time without significant delays, such as would be involved in querying a complex data structure of substantial size for various relevant information. To keep such information readily available, real-time monitoring is thus an important concern. In this paper, we focus especially on the concern of coordination support, as “supporting coordination of crises resolution processes” is a primary requirement for this system (as defined in the case study, section 2). For the CMS to properly facilitate this, it should support standardized scenarios that deal with recurring types of crises, such as the Car Crash Scenario described in the case study. This way, a scenario prescribes the actions that should be taken to remedy a specific crisis. Since the definition of such reusable scenarios is likely to be the most unstable part of the CMS, it makes sense to explicitly modularize scenarios. For example, scenarios will be subject to change based on national policies. In addition, new

328

S. Ciraci et al.

scenarios may be introduced at a later stage, and scenarios may also be extended in an incremental way to incorporate knowledge acquired in its previous applications. Later in this section, we give examples of various incremental evolution steps. Within the context of the CMS, a scenario can be seen as a reactive controlling process, because it gathers all kinds of information from its environment and reacts to these “events”. As to how such a system should be designed, several publications state that it is best to separate the coordination of behavior from the behavior itself [20, 2]. In this sense, the coordination of a scenario can be seen as a crosscutting concern: several scenarios may need to react to the same event, while conversely, one scenario may depend on multiple information-gathering (and event-generating) modules. In the context of reactive systems, the notion that coordination of behavior can be seen as a crosscutting concern has been identified before [4]. Since this is the case, the coordination of a scenario can be modeled as an aspect that intercepts events that are of importance to the scenario, and invokes the intended actions prescribed by the scenario. This way, the coordination of behavior is properly separated from the behavior itself, as well as decoupled from the different information-gathering and event-generating modules. In the next subsection, we show how the Car Crash scenario can be modeled following this principle. 3.4

Crisis Management System Main Class Diagram

Figure 2 shows the important structural elements of our design. The structure at the top of the diagram shows a collection of classes modeling a hierarchy of states. Potentially reusable actions are modeled as states, each of which implements a specific part of desired system behavior. For example, an instance of class ResourceAllocate defines behavior that checks whether a requested resource is available, and if so, allocates it to a scenario. ResourceDispatch implements instructing a specific resource (i.e., assigning it a mission to carry out). Note that this part of the structure does not implement a complete state machine; the coordination of these states, i.e. defining transitions between them as the result of particular events, is implemented by aspects that model specific scenarios. The bottom half of figure 2 shows the structure of other relevant system components. The class Server has an interface to receive external as well as internal events. External events originate from the environment and are generated by a client (not modeled here) through a user interface. Internal events are signaled by the system itself, for example, if it runs low on resources of a specific kind. Furthermore, the server keeps track of resource allocations through a class ResourceManager, as well as a list of common data for each crisis scenario, as found in the domain model specified in the case study.

A Graph-Based Aspect Interference Detection Approach

329

States::State +executeSateAction()

States::InitialReportReceived

States::ResourceAllocate

States::AssistanceRequested

States::FinalReport

+InitialReportReceived()

+ResourceAllocate()

+AsistanceRequested()

+FinalReport()

States::ScenarioAccepted

States::ResourceDispatch

+ScenarioAccepted()

+ResourceDispatch()

States::RequestFailed

1

1

Scenario::ScenarioInternalEvent

Server -scenarioBcast

+externalEvent() +internalEvent() 1 1

+firePreEmpt() +fireRequestDeallocate()

Scenario::ScenarioOutSideEvent Scenario::ScenarioData Crisis

*

Resource::ResourceManager +allocateResource() +deallocateResource() 1

-resources

* Resource::Resource

*

*

+startScenario() +requestResource() +failureReported() +completionReported() +arrivalReported() +requestAssistance()

-startTime : long -endTime : long -currentState : State -requestedResources : Vector -type : int -workerReports : Vector +ScenarioData() #setBeginTime() #setEndTime() #addWorkerReport() +addRequestedResource() +addAllocatedResource() +scenarioStart() +getLocation()

-type : ResourceTypes +dispatch() : bool

-allocatedResources

CMSEmployee

ExternalResource

-name

-location +getLocation()

CrisisManager

-scenarioOutSideEvents

*

1 -scenarioDatas 1 -resManager

1

1

SuperObserver

MedicalRS

GovernmentRS

PoliceRS

LogisticRS

FireDeptRS

Fig. 2. Class diagram of the Crisis Management System

330

3.5

S. Ciraci et al.

Modeling Gathering of Statistical Information as an Aspect

The real-time gathering of statistical information about the system is a crosscutting concern, as it needs to track state changes all over the system, e.g. to facilitate real-time reporting on mission status. Figure 3 shows the design of such a monitoring aspect using Theme/UML. The pattern class MonitorStatus defines the monitoring interface; it is possible to implement different styles of monitoring, such as logging to a file or database (implemented by classes FileLog and DataBaseLog). The sequence diagram shown in Figure 3(c) shows an implementation that logs to a file. After any bound mission-state-changing operation is invoked, this sequence diagram specifies that the relevant state information should be written to a log file. The binding specification shows how this theme is bound to all the classes in the main package, i.e. all the state implementations shown in the class diagram in figure 2. «pattern class» MonitorStatus -log : Log #executeStateAction(in executingScenarioData : ScenarioData) : void +_executeStateAction(in executingScenarioData : ScenarioData) : void +afterInvoke() : void FileLog Log

+openLog() : void +writeLog(in logData : string) : void +closeLog() : void

+openLog() : void +writeLog(in logData : string) : void +closeLog() : void

Main

[State,executeStateAction]

DataBaseLog +openLog() : void +closeLog() : void +writeLog(in logData : string) : void

(a)

MonitorStatus

(b)

MonitorStatus.executeStateAction(executeSenarioData:ScenarioData «pattern class»monitor : MonitorStatus

log : FileLog

executeStateAction(executeScenarioData) _executeStateAction(executeScenarioData)

afterInvoke() writeLog(stateInformation)

(c)

Fig. 3. Monitoring of states using different storing mediums realized through Theme MonitorState: a) The classes of this theme. b) The binding specification. c) The sequence diagram for template parameter executeStateAction().

A Graph-Based Aspect Interference Detection Approach

3.6

331

Modeling the Car Crash Scenario as an Aspect

We realize the Car Crash scenario as exemplified in the case study, as a distinct aspect shown in figure 4. This figure, which defines the Car Crash “theme”, consists of two parts. The first part (Figure 4-(a)) is the definition of the pattern class CarCrashScenario, which keeps track of the current state the system is in and which may also define behavior that is specific to the low-level implementation of this scenario. The second part is a sequence diagram that defines how to react to selected events. Some Theme/UML-specific extensions are visible in this sequence diagram: the sequence diagram is parameterized : it refers to a template parameter and the template class CarCrashScenario, both of which should be bound with other “themes” by means of a composition specification. The meaning of the template parameter in the sequence diagram is that the actions specified by the sequence diagram will be executed whenever a method bound to that parameter

«pattern class»CarCrashScenario -[ScenarioOutSideEvent,fireStart] +adviceFireStart(in scenarioType : ScenarioOutSideEvent, in scenarioData : ScenarioData) : void +allocationStart(in scenarioType : ScenarioOutSideEvent, in scenarioData : ScenarioData) : void #_fireStart(in scenarioType : ScenarioOutSideEvent, in scenarioData : ScenarioData) : void #_fireRequest(in scenarioType : ScenarioOutSideEvent, in scenarioData : ScenarioData) : void «templateParameter» +fireStart(in scenarioType : ScenarioOutSideEvent, in scenarioData : ScenarioData) : void «templateParameter» +fireRequest(in scenarioType : ScenarioOutSideEvent, in scenarioData : ScenarioData) : void +beforeInvoke()

Main

CarCrashScenario

(a)

(b)

CarCrashScenariom.fireStart(sType:int, sData:ScenarioData) «pattern class» ccs : CarCrashScenario «templateParameter» fireStart(sType, sData)

sData : ScenarioData

beforeInvoke()

adviceFireStart(sType, sData) opt [sType=CarCrashScenario] scenarioStart() ScenarioAccepted()

state : ScenarioAccepted

ScenarioAccepted()

_fireStart(scenarioType, scenarioData)

(c)

Fig. 4. Car Crash Scenario expressed using Theme/UML: a) The pattern class CarCrashScenario. b) The binding specification for the theme Car Crash Scenario. c) The sequence diagram for the template parameter fireStart().

332

S. Ciraci et al.

is invoked. Figure 4-(c) shows the binding specification for the theme Car Crash Scenario, where the pattern class CarCrashScenario is bound to the class ScenarioOutSideEvent and the template pattern fireStart() is bound to the actual operation fireStart(). The meaning of the sequence diagram is that it responds (only) to events that indicate a scenario should be started, specified by the invocation of fireStart. The remainder of the sequence diagram forms the advice, which is executed at each fireStart join point (invocation): if the scenario type specified by the event is indeed a CarCrash scenario (indicated by the guard condition “scenarioType=CarCrashScenario”, in the diagram), it changes the state of the scenario to “scenario accepted”, and invokes the actions defined by that state. Of course, each event has exactly one scenario type, and in that sense the guard condition based on the scenario type can be considered to be mutually exclusive with such guard conditions that may be defined by other scenarios. Figure 5 shows the handling of allocation and deallocation as implemented by the car crash scenario. As shown in figure 5(a), the scenario attempts to allocate resources, and if this fails (the result of allocation is a null-object), it simply switches to state RequestFailed. Figure 5(b) shows that resources can also be deallocated, which is only allowed after they have been allocated but not been dispatched yet. In this case, the scenario also moves to state RequestFailed.

CarCrashScenario, firedeallocate(sType:int, sData:ScenarioData, resource: Resource)

CarCrashScenario,fireRequest (sType:int, sData:ScenarioData) «pattern class» ccs : CarCrashScenario

: ResourceManager

«pattern class» ccs : CarCrashScenario

sData : ScenarioData

: ResourceManager

beforeInvoke()

beforeInvoke()

opt allocationStart(sType, sData) [scenarioType=CarCrashScenario]

opt [scenarioType==CarCrashScenario] deallocationStart(sType, sData, resource)

alt [res!=null]

sData : ScenarioData

«templateParameter» fireDeallocate(sType, sData, resource)

«templateParameter» fireRequest(sType, sData)

res:=allocateResource(type,sData) resource

removeAllocatedResource(resource)

addAllocatedResource(res)

deallocateResource(resource) [res==null]

scenarioFailed() RequestFailed()

scenarioFailed() currentState : ResourceFailed

executeStateAction(sData)

_fireRequest(sType, sData)

(a)

RequestFailed(resource)

currentState : executeStateAction(sData)RequestFailed

_fireRequest(scenarioType, scenarioData)

(b)

Fig. 5. Sequence diagrams showing the resource allocation (a) and deallocation (b) of car crash scenario

A Graph-Based Aspect Interference Detection Approach

3.7

333

Incremental Evolution: Adding New Scenarios

It is to be expected that, over time, new scenarios will be added to the CMS, and existing ones might evolve as well. Here, we briefly discuss an additional scenario: suppose that there is an accident that involves the president of the nation. In such a case, since the number of resources is limited and may already be assigned to other crises, it may be required to pre-empt resources assigned to low-priority crises. Diagram 6 defines such a scenario. In principle, the crisis is handled in a similar way as discussed in section 3.6. However, if insufficient resources are available, an internal system event is generated, asking all running crises to preempt necessary resources, if appropriate. The higher priority scenario should then be able to allocate those resources. For the pattern class PresidentialEmergencyScenario, the request for pre-emption is shown in Figure 6-(b) with the call to the operation Server.ScenarioBroadCastEvent(). «pattern class»PresidentialEmergencyScenario -[ScenarioOutSideEvent,fireRequest] +adviceFireStart(in scenarioType : ScenarioOutSideEvent, in scenarioData : ScenarioData) : void +allocationStart(in scenarioType : ScenarioOutSideEvent, in scenarioData : ScenarioData) : void #_fireStart(in scenarioType : ScenarioOutSideEvent, in scenarioData : ScenarioData) : void #_fireRequest(in scenarioType : ScenarioOutSideEvent, in scenarioData : ScenarioData) : void «templateParameter» +fireStart(in scenarioType : ScenarioOutSideEvent, in scenarioData : ScenarioData) : void «templateParameter» +fireRequest(in scenarioType : ScenarioOutSideEvent, in scenarioData : ScenarioData) : void +beforeInvoke()

Main

PresidentEmergency Scenario

(a)

(b)

PresidentialEmergencyScenario.fireStart(spType:int, spData:ScenarioData) «pattern class» ccs : PresidentialEmergencyScenario

: Server

scenarioBCast : ScenarioBroadcastEvent

«templateParameter» fireStart(spType, spData)

spData : ScenarioData

beforeInvoke() adviceFireStart (spType, spData) opt [scenarioType = PresidentialEmergency] ScenarioBroadCastEvent(rpType, eventData) firePreEmpt(sType, sData)

scenarioStart()

_fireStart (scenarioType, scenarioData)

(c)

Fig. 6. Presidential Emergency scenario expressed using Theme/UML: a) The pattern class PresidentialEmergencyScenario. b) The binding specification for the theme Presidential Emergency Scenario. c) The sequence diagram for the template parameter fireStart().

334

S. Ciraci et al.

The sequence diagram in Figure 7 shows how the pattern class PresidentialEmergencyScenario allocates resources. This is very similar to the way the resource allocation of the car crash scenario; however, the major difference is that here failures during resource allocation are not handled. There should always be resources available for an resource allocation request by the presidential emergency scenario due to the request for resource pre-emption. Thus, there is no need for failure handling in resource allocation for this scenario. PresidentialEmergencyScenario.fireRequest(spType:int, spData:ScenarioData) «pattern class» ccs : PresidentialEmergencyScenario «templateParameter» fireRequest(spType, spData) : ResourceManager

spData : ScenarioData

beforeInvoke() adviceFireStart:= allocationStart(spType, spData) opt [spType=PresidentialEmergencyScenario] gotResource:=allocateResource(type) resource gotResource:=allocateResource(type) resource addAllocatedResource(gotResource) ResourceAllocate()

currentState : ResourceAllocate

executeSateAction(sData)

_fireRequest(scenarioType, scenarioData)

Fig. 7. The sequence diagram from theme Presidential Emergency Scenario showing the resource allocation of the pattern class

3.8

Incremental Evolution: Resource Allocation Based on Location

Resources are allocated by calling the method allocateResource in class ResourceManager, shown in the class diagram of the Crisis Management System 2. The default implementation of this method simply looks for the first available resource of the correct type, and allocates that. This resource allocation strategy is of course very naive. To address this, as an incremental evolution step various resource allocation strategies would be modeled as a “pluggable” aspect that intercepts calls to this method, and implements various different strategies for the allocation of resources. For example, the default implementation just searches for the first unallocated resource of the correct type that is

A Graph-Based Aspect Interference Detection Approach

«pattern class» LocationAllocationStrategy

Main

[ResrouceManager, allocateResource]

+adviceAllocateResource(in resourceType : int, in scenarioData : ScenarioData) : void #_allocateResource(in resourceType : int, in scenarioData : ScenarioData) : Resource +beforeInvoke() «templateParameter» +allocateResource(in resourceType : int, in scenarioData : ScenarioData) : Resource -findResource(in scenarioData : ScenarioData, in resourceType : int) : Resource

(a)

335

MonitorStatus

(b)

LocationAllocationStrategy.allocateResource(rType:int, sData:ScenarioData) «pattern class» Lra :LocationAllocationStrategy

resource : Resource

: Server

scenarioBCast : ScenarioBroadcastEvent

«templateParameter» resource:=allocateResource (rType, sData) beforeInvoke()

resource:=_allocateResource (rType, sData) resource:= findResource(sData, rType)

res opt alloc:=isAllocated() [res!=null]

opt

result

ScenarioBroadCastEvent(deallocType, eventData)

presult=true]

fireDeallocate(sType, sData, resource)

resource

resource resource

(c)

Fig. 8. Location-based resource allocation strategy design using Theme/UML: a) The pattern class LocationAllocationStrategy. b) The binding specification. c) The sequence diagram for the template parameter allocateResource().

available, and allocates that. More elaborate management schemes might take resource location, employee scheduling constraints, costs, etc. into account. Figure 8 shows the implementation of a resource allocation strategy that takes the location (proximity to the place of the crisis) of resources into account. It does this by attempting to allocate a resource found within a given maximum distance. If no such resource can be found (i.e., after attempting the allocation, the resource still refers to a “null”-object), an optional part of the sequence diagram in figure 8(c) is executed, which will attempt to obtain resources by first deallocating them from lower priority tasks. 3.9

Aspect Interference in the Crisis Management System

In the sections above, we have defined a system that allows the modular specification and evolution of multiple scenarios and separates the coordination

336

S. Ciraci et al.

specification from modules that implement low-level behavior. However, since these scenarios may be developed independently of each other, by different actors, and since scenarios may also evolve over time, it could easily occur that multiple scenarios interfere with each other. In the example above, the Presidential Crisis scenario sends an event that asks other scenarios to pre-empt non-critical (to them) resources. However, the Car Crash scenario as defined earlier does not take this into account correctly, because it simply moves to a failure state that violates application constraints, as will be shown in the following sections.While the small size of our example case makes this conflict relatively easy to discover, interactions among scenarios are more complex and less obvious when more realistically sized projects are considered. Furthermore, the potential for inconsistencies or unintended interactions increases as the system evolves. Since multiple scenarios may need to react to one event, and each scenario is interested in multiple kinds of events, it becomes very hard to keep track of all potential interactions manually. For this reason, the help of automated tools that can detect (potential) interference is necessary. In the next section, we discuss an approach that facilitates this.

4

A Graph-Based Approach to Conflict Detection on UML-Based AOMs

UML-based AOM allows the software system to be decomposed into partial views. However, understanding the behavior of the composed system is difficult. Once the structure of the software is designed and the behavior is expressed in terms of execution sequences, the understanding of the overall execution sequences become even harder as one needs to trace (combine) through many sequence diagrams due to pointcuts, polymorphism and conditional executions. For example, one needs to ensure that the composed models do not violate an invariant of the software system and execute in the right sequence. We use graphbased model checking to automate the trace and verification process, in terms of the GROOVE graph production system. In graph-based model checking, the behavior of the system is modeled as graph transformation rules and runtime states of a system are modeled as graphs. Here, applying a transformation rule results in one or more graphs that represent different states of the system [23]. The graph production tool automatically applies the transformation rules, which simulates the behavior of the modeled system. The simulation generates a state space (with transitions) showing the possible states the system can reach. The requirements of the system are expressed as temporal logic formulas which are verified over the generated state space. In our case, the state space contains all the execution sequences supported by the input UML sequence diagrams. The verification is realized by expressing the desired execution sequence as a CTL formula. Aspects, polymorphism and conditional execution are the main factors altering the execution sequences. The UML diagrams should be simulated as close

A Graph-Based Aspect Interference Detection Approach

337

to the actual execution of an OO software system in order to fully capture the effects of these on the execution. Therefore, we defined a language, called the Design Configuration Modeling Language (DCML), of graph-based models that is an OO-like runtime representation of UML class and sequence diagrams. We modeled graph transformation rules that add OO-like execution semantics to the UML sequence diagrams so that the runtime relation can be simulated with graph-based model checking. Similarly, we also modeled the effects of aspect weaving as performed by an aspect-oriented runtime system. This section details the application of graph-based model checking to semantic interference detection. In the next subsection, a motivating example from the CMS software system is presented. The DCML model is detailed. Subsection 4.3 details how aspects are modeled in DCML. In subsection 4.4, examples of graph transformation rules modeling object- and aspect-oriented execution semantics are presented. Finally, subsection 4.5 explains how execution sequences can be expressed with temporal logic formulas and how these are verified. 4.1

Motivating Example: Ensuring the State Constraints of Scenarios

The design of the CMS follows a state pattern so that each scenario can track its status as detailed in Section 3. The CMS system has the constraint (or invariant) that the crisis scenarios are responsible for executing the state corresponding to the event they received. For example, a scenario receiving the start event fireStart() should execute the actions implemented in the method ScenarioAccepted.executeStateAction(). The addition of the presidential emergency scenario and the location-based resource allocation strategy caused the events firePreEmpt() and fireDellocate() to be used. The old scenarios in the system, like the car crash scenario, did not handle these events; these scenarios may not execute the right state actions, which in turn may cause the software to crash. The designers need to trace through the sequence diagrams and ensure that the old scenarios make the call to the right subclass of the class State to prevent such errors. However, the error about the state changes may occur under different compositions of the software system which may be missed by the designer. For example, first presidential emergency scenario resource allocation, then executing the car crash scenario may not cause problem but the reverse order may cause a problem. Because of this, all possible compositions in all possible execution orders should be generated. In our approach, the simulation generates the state space containing all possible execution orders and compositions the design models support and the constraints of the software system in terms of execution orders are verified over this state space. 4.2

Design Configuration Modeling Language

Figure 9 shows the meta model of DCML. In this figure, Var stands for variable, Decl stands for declaration, Impl stands for implementation and Oper stands for

338

S. Ciraci et al.

operation (DCML uses the term “operation”; one could also read “method”). The DCML meta model has two parts, the structure part and the dynamic part. Both parts and their elements are quickly presented in the following. For a more detailed discussion with additional examples, we refer to the appendix, which describes the DCML elements in detail.

-returnVal

-attributes

-final : bool -static : bool

-operations -referenceType

StaticCall -statement

-superType -body OperImpl

*

return

-possible_next 1 ConditionaFrame

-executes

-conditionalValue : bool

CreateAction

ListLookup -previousExecution

InstanceCall SuperCall

LoopFrame ThisCall

Value

ListType

Object -encapsulates -self

Action

CallAction

-instance

-executingType

-next

PrimitiveType

ObjectType -final : bool -abstract : bool -interface : bool

-instance

OperDecl

-name : string -calledSignature

-referenceVar

-signature

Type -name : string

-name : string

-parameter Signature

instanceValue -Type

VarDecl

-elementLookup

-paramValue, assignedValue

OperFrame

Fig. 9. The DCML meta-model

Structure part of DCML. The structure part covers the elements of the metamodel for modeling the classes, the interfaces and the relations between these. This part is generated from the class diagram. Because classes and interfaces are types at runtime, they are represented by nodes labeled ObjectType (object-type nodes). If the object-type node is representing an interface, then the attribute interface is set to true. The equivalent of the generalization relation is the edge labeled super type. Figure 10-(a) shows a class diagram where the class State is generalized by the class ResourceAllocate. Figure 10-(b) shows the DCML representation of this class diagram; here, the two object-type nodes represent the classes in the class diagram. Further kinds of nodes, edges, and specializations in the structure part are: Node VarDecl – a variable declaration. Edge Type – connects a variable declaration node with a type node to model the variable’s type. Edge attributes – connects an object-type node with variable-declaration nodes which represent the type’s attributes. Node OperDecl – an operation declaration. Specialization OperImpl – added to OperDecl nodes for operation with implementation. Edge operations – connects an object-type node with operation-declaration nodes which represent the type’s operations. Node Signature – a unique operation signature.

A Graph-Based Aspect Interference Detection Approach

339

State +executeStateAction(in executingScenarioData : ScenarioData) : void

ResourceAllocate +executeStateAction(in executingScenarioData : ScenarioData) : void

(a)

(b)

Fig. 10. a) An example UML class diagram. b) The DCML model of the class diagram shown in (a).

Edge parameter – connects a signature with the variable declarations that represent the signature’s parameters. Edge returnType – connects a signature with a type node that represent the signature’s return type, if it has one. Dynamic Part of DCML. The dynamic part, which is generated from the sequence diagrams, covers the elements for modeling the objects, the values and the life line’s of the operations. A life line in a sequence diagram shows the actions the object executes when it receives a call. In the DCML meta model (Figure 9), the specializations of the abstract element Action represent the actions of sequence diagrams. An action node can be connected to another action node by an edge labeled next; in this way, the order between the actions of a life line is represented in DCML. The first action of a life line is connected to an operation implementation node by an edge labeled body in DCML to show that these actions are executed when this operation receives a call. The sequence diagram presented in Figure 11-(a) shows that in the life line of the operation addAllocatedResource() first a call the operation ResourceAllocate.executeStateAction() and then a return action is executed. Figure 11-(b) shows the lifeline of the operation addAllocatedResource() in DCML. Here, the emphasized node represents the call action of this life line; it is the first action of this lifeline because it is connected to the operation implementation node with an edge labeled body. The outgoing edge labeled calledSignature from this node shows that the call action is to the signature executeStateAction. Following the outgoing edge labeled next from the call action node, it can be seen that the call action is succeeded by a return action. The frame of an executing operation is represented by nodes labeled OperFrame in DCML. These nodes are used to identify, during simulation, the object that is currently executing, the scope of the executing object, the type that contains the called operation and the statement that is being executed. When UML diagrams are converted to DCML models, the conversion algorithm automatically adds the operation frame node which marks the first action of the sequence diagram as the action that is being executed. Thus, the simulation starts executing from that action.

340

S. Ciraci et al.

s : Scenario::ScenarioData

currentState : States::ResourceAllocate

addAllocatedResource:=addAllocatedResource(res) executeSateAction:=executeSateAction(executingScenarioData)

Fig. 11. a) A sequence diagram showing the actions executed by the operation ScenarioData.addAllocatedResource(). b) These actions represented in DCML.

Further kinds of nodes, edges, and specializations in the dynamic part are: Specialization InstanceCall, CreateOper, SuperCall, ThisCall, StaticCall – added to CallAction nodes to distinguish between calls to instances, object creation, calls to the super implementation, self calls and calls to static operations. Edge referenceVar – connects a call-action node with a variable declaration node to show that the operation is invoked on this value. Node ConditionalFrame represents alternative and optional frames. Node LoopFrame represents loop frames. Edge possible next connects a conditional frame to an action node to represent the frame fragment. Node Value – represents a value. Specialization Object added to Value nodes to specify that the value is an object. Edge instanceValue – connects a variable-declaration node with a value node which represents the variable’s value. Edge self – connects an operation-frame node with object node representing the active object during the execution of the frame. A DCML model can be generated from more than one sequence diagram and, thus, a variable can have more than one instance value. During simulation, the values of the variables at the executing frame are resolved with the encapsulated edges. 4.3

Aspects in the Design Configuration Modeling Language

DCML treats aspects as a specialization of the object types called aspect types which are shown as nodes labeled AspectType (aspect-type nodes). Because of

A Graph-Based Aspect Interference Detection Approach

341

ObjectType Pointcut -toMethod : string -toObjectType : string

Before

-pointcuts *

After -advice

1

1

AspectType -precedence : int

-advice 1

1

1

Action

1

1

-next

Fig. 12. The meta-model containing elements for representing aspects in DCML models

this specialization, it is possible to specify attributes and operations for aspect types. Figure 12 shows elements used for representing aspects in DCML models. It is possible to give precedence to aspect types in DCML; if a precedence value is given to an aspect, then the integer attribute precedence is set to the given precedence value. The pointcuts of aspects are represented with nodes connected to aspect-type nodes with edges labeled pointcuts. Depending on the advice execution, these nodes are labeled Before, for before advices, and After, for after advices. Note that a pointcut node can have only one before or after advice. Thus, two pointcut nodes are required to define before and after advices for the same method. UML-based AOM approaches extend the UML class and sequence diagrams, thus, in order to use our approach for conflict detection in an AOM model, a mapping from these extensions to the DCML elements must be provided. For Theme/UML, which we choose to model the design of the CMS, the mapping to DCML is realized as shown in the itemization below: – The pattern classes are represented as aspect types. Currently, the execution semantics we modeled do not support aspect instances; thus, the operations and the attributes declared in template classes are converted to static operations and attributes of the aspect types. – The operation beforeInvoke() of the template operations is represented as before pointcut. Similarly, the operation afterInvoke() is represented as after pointcut. These pointcuts are connected to the aspect-type node representing the template class by the edge labeled pointcuts. – The life line of the operations beforeInvoke() and afterInvoke() is represented as the advice of a before or after pointcut. – The names in the binding specification are converted to the values of the attributes toMethod and toClass of a pointcut node. We also support to match names against patterns rather than just comparing them for equality. Figure 13 shows the DCML model of the “theme” CarCrashScenario, fireAdviceStart; the Theme/UML diagrams of this “theme” are shown in Figure 4. Here, the pattern class CarCrashScenario is represented by the aspect-type node that has the same name. Looking at the sequence diagram of this theme, it can be seen that the operation beforeInvoke() is called after the invocation of the template method fireAdviceStart(); so, a before pointcut is added to the

342

S. Ciraci et al.

aspect-type CarCrashScenario. In the life line of the operation beforeInvoke() first a call action is executed, then the operation returns. In the DCML model of this theme, the call action node and the return action node (labeled return) represent these actions. Because the call action is executed first in the life line, the before pointcut node is connected to the call action node by the edge labeled advice. The specification presented in Figure 4-(c) states that the “theme” CarCrashScenario should be bound to the class ScenarioOutSideEvent and to the method fireStart(). Following this, the attribute toObjectType of the before pointcut node is set to ScenarioOutSideEvent and the attribute toMethod of the same node is set to fireStart.

Fig. 13. The DCML model of the “theme” CarCrashScenario

4.4

Execution Semantics via Graph Transformations

A DCM is simulated by automatically triggering the appropriate graph transformation rules that represent the OO and aspect-oriented execution semantics of the UML models. We formed a graph-production system (a collection of graph transformation rules [23]), consisting of 57 graph transformation rules that model the OO-like execution semantics for UML sequence diagrams. In addition to these, we modeled execution semantics for before and after pointcuts with 8 transformation rules. For brevity, we summarize how these execution semantics work and detail the transformation rules modeling the semantics for before pointcuts in this section (interested readers can download the graph production system [1] and find detailed explanation of these semantics in [9]). Before the discussion on the execution semantics, we introduce graph transformations and how they are modeled in GROOVE. A graph transformation rule has a left-hand side, L, a right-hand side, R and a set of negative application conditions N . The rule transforms a source graph G to a target graph H by searching for an occurrence of L in G where none of the elements in N occurs. In order to say L occurs in G all the nodes and edges in L should also be found in G [14]. When L of a transformation rule occurs in G where none of the elements in N occurs then the transformation rule is said to match; a rule can have multiple matches. For each match, L is replaced by R which results in the transformed graph H .

A Graph-Based Aspect Interference Detection Approach

343

In GROOVE, both the left-hand and the right-hand sides of a graph transformation rule are represented in the same graph. The modifications the rule applies to the host graph are specified using keywords. The keyword new (or the color green and solid bold lines) is used for the edges/nodes that are added. The keyword del (or the color blue and dashed thin lines) is used for the edges/nodes that are deleted. The keyword not (or the color red and dashed bold lines) is used for negative application conditions [18]. OO-like execution Semantics for UML sequence diagrams. We modeled to the following execution semantics for the simulation of the UML sequence diagrams: Program Counter: When the simulation of an action is complete, the transformation rule modeling the semantics of the program counter advances the simulation to the next action. Operation Call: The operation call involves finding the receiver object of the call and, then, traversing the inheritance hierarchy to find the latest implementation of the operation. For example, if the object receiving the call implements the called operation, then the inheritance hierarchy is not traversed. If, on the other hand, this object does not implement the operation, the super-type of this object is traversed. The semantics of the operation call are implemented with 5 graph transformation rules (these transformation rules are detailed in the appendix). These rules match when the simulation reaches an instance call action node (i.e. the executes edge of the current operation frame is pointing to a node with the label InstanceCall) This-Call: Because in a this-call the receiver object is the same as the object from which the call is originated, the semantics search for the operation implementation in the object type of the currently executing object. If the operation is not implemented there, the traversal in the inheritance hierarchy starts. This-calls are also implemented with 5 transformation rules and they match to the host graph when the simulation reaches a node representing the self-calls. Super-Call: Similar to the execution semantics of the this-calls, the receiver object and the object the call is originated from do not change in super-calls. However, the implementation of the operation is searched in the super-type of the currently executing object. If the operation implementation cannot be located at the super-type then the traversal in the inheritance hierarchy starts. The semantics of the super-calls are also implemented with 5 transformation rules. These rules match when the simulation reaches a node representing super-calls. Static Operation Call: 3 transformation rules are implemented for static operation calls, which match when the simulation reaches an action node representing a static-call. These rules locate the static operation implementation in the class referred by the call. Parameter Pass: Parameter passing is simulated after the object-type implementing the called operation is located for all kinds of calls. The semantics

344

S. Ciraci et al.

for parameter pass iterate the list of parameters and copy the values/references to the frame of the called object. Parameter passing is implemented with 3 transformation rules. Return Value Pass and Assignment: When the simulation reaches a node representing a return action, the semantics of the operation return are executed. These semantics are implemented with 4 transformation rules, where 2 are used for copying the value/reference of the return value to the frame the call is originated from, 1 is used for deleting the operation frame of the returning frame and 1 is used for assigning the return value to the variable specified in the call. Object Creation: Object creations are simulated with 3 transformation rules, which match to the host graph when the simulation reaches a node representing the create actions. The first transformation rules adds the created object to the frame of the currently executing object and the remaining two are responsible for calling the constructor. Conditional Execution: The transformation modeling the semantics of conditional execution picks the first action of one of the frame fragments of alternative frames and advances the program counter to that action, when the simulation reaches an conditional frame node. For optional frames, the rule either advances the program counter such that actions within the frame fragment are simulated or the transformation rule for the program counter advances the simulation to the next action (skipping the actions within the frame fragment). Loops: Loops are realized with 2 transformation rules, which match when the simulation reaches a loop frame node. One of these transformation rules arranges the program counter so that the simulation loops over the actions within the frame fragment. The second transformation rule tests whether the loop is repeated by the user-specified amount and, if so, it terminates to loop. This rule is a generated rule. The user specifies the iteration count for the loop in the sequence diagram (this done within the guard of the loop). During the conversion from UML to DCML, the conversion algorithm generates a copy of this rule for each loop frame in the sequence diagram. Polymorphism: When an instance call can be received by more than one object, the rule modeling the semantics of polymorphism matches. This rule changes the value of the reference variable to an object that is an instance of one of the type compatible classes. A typical scenario for polymorphism occurs when there are two or more sequence diagrams showing the same call received by different objects. Execution Semantics of Pointcuts and Before Advices. The design of the CMS requires the scenarios to intercept the entry and exit points of the event methods. Because of this, we modeled the semantics for pointcuts and before/after advices. In this section, we detail the semantics of the pointcuts and before advices; the semantics of the after advices are similar. As discussed before, the pointcuts in DCML specify the name of the operation that is going to be intercepted. The execution semantics of a pointcut evaluate whether the

A Graph-Based Aspect Interference Detection Approach

345

simulation is at the entry point of the operation specified in the pointcut. If this evaluation yields true, then the advice code of the pointcut is executed before the operation. Similarly, the semantics for the after pointcut evaluate whether the simulation has finished executing the operation specified by the pointcut. The advice code of these pointcuts is executed just after the return action of the intercepted operation.

(a)

(b) Fig. 14. The transformation rules modeling the semantics of before pointcut

Figure 14 shows the two transformation rules that identify the join points for before pointcuts. At the entry point of an operation, the transformation rule shown in Figure 14-(a) evaluates whether there is a before pointcut that can intercept this operation. If there is, then it marks the intercepted operation and intercepting pointcut with a node labeled Joinpoint (joint point node), node n8. To evaluate whether a before pointcut can intercept the operation, the rule checks for two conditions: 1) the execution should be at an entry point of an operation, 2) The name of this operation and the name of the object-type should match the names specified in the pointcut. These conditions are realized by the transformation rule as follows: – The entry point of an operation, in DCML, is the point where the program counter, the edge labeled executes, connects the operation frame node to

346

S. Ciraci et al.

an operation implementation node. The left-hand side of the transformation rule shown in Figure 14-(a) matches when the simulation is at an entry point of an operation identified with the node n8 representing the operation frame that is currently executing and the edge labeled executes connecting this operation frame to the operation implementation node n15. – The transformation rule uses attribute operations to evaluate the pointcut at an entry point of an operation. In the transformation rule, the nodes x274 and x276 represent the name of the operation and the value of the attribute toMethod, respectively. These nodes are generic value nodes and they can match to any value of the attribute. The node p272 is a production node; this is the node where the attribute operation is specified. The outgoing edge labeled string:eq specifies that the attribute operation is string comparison. This edge is connected to the attribute node holding the value bool:true; this states that the two string arguments of the operation should be equal for the rule to match. The outgoing edges from a production node whose labels start with arg are used for specifying the arguments of the attribute operation. The arguments of the production node p277 are specified as the name of the operation (node x274) and the value of the attribute toMethod (node x276) in Figure 14-(a). In this way, the rule evaluates whether the name of the operation to be executed is the same as the name in the pointcut specification. The evaluation of the name of the object type is also realized using the string comparison attribute operation (this attribute operation is specified in the production node p277). Thus, the transformation rule only matches when the string values of the pointcut specification are equal to the object-type and operation that is to be executed. The transformation rule shown in Figure 14-(b) evaluates whether there are other aspects that can intercept the same operation as the aspect identified by the rule presented in Figure 14-(a). This rule also uses attribute operations to evaluate the pointcut. The main difference between this rule and the rule presented in Figure 14-(a) is that this rule forms a list of join points. Assume that there are two aspects that can intercept the currently executing operation. The transformation rule shown in Figure 14-(a) identifies one of these aspects and marks it by adding a join point node. Then, the transformation rule shown in Figure 14-(b) identifies the second aspect and adds another join point node (node n12). However, this join point node is connected to another join point node (node n13) by an edge labeled next. In this way, a list with two join points is formed. The beginning of the join point list is always the join point added by the transformation rule of Figure 14-(a). This rule extends the join point list by adding items to the end of the list. The edge labeled ptr is used for marking the last item in the join point list. The rule connects the edge labeled next to a join point node that has the self-edge labeled ptr. Since the newly added join point is now the last item on the pointcut list, the rule adds the self-edge labeled ptr to the new join point node (node n12 and deletes it from the previous join point node (node n13). Note that the transformation rules shown in Figure 14 work on aspects that do not specify a precedence. The execution semantics for

A Graph-Based Aspect Interference Detection Approach

347

aspects with precedence are handled by another two transformation rules. These two rules also use attribute operations to compare the precedence value of the aspect-type nodes.

(a)

(c)

(b)

(d)

Fig. 15. a) Transformation rule for starting the execution of the join point list. b) The transformation rule that starts the execution of the advice code for a pointcut. c) The transformation rule that advances to the next join point in the join point list. d) The transformation rule that resumes the execution of the intercepted operation.

After the join points are identified and the join point list is formed, the join point list is traversed and the advice code of the pointcuts is executed. The execution semantics of these are modeled in the 4 transformation rules shown in figure 15. The transformation rule shown in Figure 15-(a) adds a new operation frame, node n2, for traversing the join point list. This operation frame is connected to the first join point of the join point list, node n4, with edge labeled executes; thus, the dispatching of the advices starts from this join point. The operation frame node n8 is the frame of the operation that is intercepted by the aspects. The edge labeled previousFrame connects the new operation frame to this node so that when the traversal of the join point list is finished the intercepted operation can resume its execution. The transformation rule shown Figure 15-(b) dispatches the advice code for the current join point. This is the join point node connected to the operation frame node n3 with the edge labeled executes. The dispatching is realized by

348

S. Ciraci et al.

adding an operation frame node, node n6. The self of this new operation frame node is the aspect-type node, node n0, where the pointcut is declared. The node n7 represents the first action of the advice. The new operation frame is connected to this node with the edge labeled executes; thus, the execution of the advice code starts from this action. The edge labeled previousFrame is connected to frame where the join point dispatched the advice. When the advice code returns, the execution is given back to this operation frame; so the traversal of the join point list resumes. When the advice code returns, the transformation rule shown in Figure 15-(c) matches. This rule advances to the next join point in the list. When there are no more items to be traversed in the join point list, the transformation rule in Figure 15-(d) matches. This rule deletes the operation frame in which the join point list is traversed and resumes the execution of the intercepted operation. The graph formalism is expressive enough to define more complex pointcuts such as pointcuts based on stack frames. One can extend the approach with a new pointcut model by adding a node type for specifically identifying the pointcut (possibly a sub-class of the node PointCut) to the DCML meta model with the matching criteria. Then, the semantics of the interception condition are modeled with transformation rules similar to the transformation rules presented in Figure 14. 4.5

State Space Generated from Simulation

In graph-based model, the simulation of a model generates a state space called graph transformation system (GTS) [23]. A GTS is, again, a graph, where the nodes represent distinct runtime states and the directed edges represent graph transformation rules that were applied to transit from one state to another. When multiple rules can be applied at a certain state, one edge is created for each rule. To remind the reader, the state space generated from the simulation of the DCM shows all the execution sequences supported by the input sequence diagrams. Figure 16 shows an excerpt from a GTS demonstrating the simulation of UML models of the CMS with the aspects CarCrashScenario and PresidentialAccidentScenario. The execution starts in the state labeled start. The labels of the transitions are the names of the applied graph transformation rules. It is important to note that some of the labels are parameterized, like the transformation rule executeMethod(operation name, object-type name). A rule with a parameterized name specifies a set of node attributes whose values should be output in the transition labeled instead of the parameters. When applied, GROOVE extracts the values from the target graph and replaces the parameters with the extracted value. We designed special transformation rules, called the informative transformation rules, that use this mechanism to display information about the operations/aspects that have executed during simulation. For example, the edge between nodes start and S2, labeled executeMethod(“fireStart”, “ScenarioOutSideEvent”), shows that the simulation is at the entry point of the operation

A Graph-Based Aspect Interference Detection Approach

349

Fig. 16. Excerpt from a graph transition system showing advice execution and a conditional execution in the advice

ScenarioOutSideEvent. fireStart(). Other informative transformation rules are as follows: – executes(t): shows that class t has received a call. – returnframe(m, t): the return point of the method m of the class t. – PolymorphicReconfiguration(f, t): A receiver of the call has been changed from the instance of class f to an instance of the class t. This informative transformation rule matches right before the call is simulated. – conditionalExecutes(g): shows that the conditional execution has selected the frame fragment with guard g . In the sample GTS shown in Figure 16, we see that after state S2 the simulation continues in two branches. Each of these branches starts with a transition labeled beforePointCutStart. This label is the name of the transformation

350

S. Ciraci et al.

rule shown in Figure 14-(a). The theme CarCrashScenario and the theme PresidentialEmergencyScenario both specify a before pointcut to the operation fireStart(). So the transformation rule beforePointCutStart can match at two different places; one for aspect CarCrashScenario and the other one for aspect PresidentialEmergencyScenario. Application of this rule to one of these aspects adds a join point node specific for that aspect. This in turn causes the branching in the GTS. In fact, when more than one aspect specifies a pointcut to the same operation, each application of the rule beforePointCutStart to one of these aspects adds a branch to the GTS. Because there are two aspects with a pointcut to the same operation, the transition labeled beforePointCutStart is followed by the transition labeled beforePointCutNext once in each branch. The label beforePointCutNext is the name of the transformation rule shown in Figure 14-(b) and, as discussed before, it adds join points to the end of the join point list. Here, this rule matches once in each branch because after the application of the transformation rule beforePointCutStart there is another aspect that has a pointcut to the operation fireStart(). It can be seen from the transition between state S15 and S17 that at the left branch first the advice of the aspect PresidentialEmergencyScenario is executed. Thus, the transformation rule beforePointCutStart has matched to this aspect in this branch and the join point node marking this aspect is the first item in the join point list. Following this, the next item in the join point list should be the join point of the aspect CarCrashScenario. This can be confirmed at the sample GTS where after the advice code of the aspect PresidentialEmergencyScenario returns (i.e. after the transition labeled returnframe(”adviceFireStart”, ”PresidentialEmergencyScenario”)) there is a transition labeled executeMethod(”fireStart”, ”CarCrashScenario”) between the states S43 and S47 in the left branch. The left branch is further divided into two branches after the state S17 because of the optional frame in operation adviceFireStart of PresidentEmergencyScenario (Figure 6-(c)). The semantics of the conditional execution (alternative and optional frames) are modeled with a transformation rule named ConditionalAdapt and each application of this rule adds a branch to the GTS that executes one of the frame fragments. In the sample GTS, it can be seen that after state S20 the actions within the frame fragment are executed because the operation ScenarioData.ScenarioStart() is executed in this branch. The branch after the state S19 constitutes to the execution path where the parameter scenarioType is not equal to PresidentEmergencyScenario. 4.6

Conflict Detection Using CTL

In order to identify the conflicts or requirement violations, the requirement is expressed as a temporal logic formula. Because the state space generated by the simulation contains all possible behaviors of the system, the verification of the temporal logic formula finds all the states that do not satisfy it. In our case, we are interested in searching for execution sequences that are paths in the state space. Computation Tree Logic (CTL) is a suitable formalism to search for paths in the GTS. A CTL formula is formed with atomic propositions that are ordered

A Graph-Based Aspect Interference Detection Approach

351

with temporal and logical operators (such as and (∧), or (∨) and not !). There are two types of temporal operators in CTL: 1. Quantifiers over all paths (i.e. branches of the tree): Operator A(x) used for quantifying over all paths and operator E(x) used for quantifying on at least one path. 2. Quantifiers specific to a path (i.e. a branch of the tree): these operators are used to express orders in a path: (a) (b) (c) (d)

F(x): means that eventually in the subsequent path x has to hold. G(x): in the entire subsequent path x has to hold. N(x): at the next state x has to hold. (x U y): x has to hold until at some state y holds.

There are two approaches to detect a constraint (invariant) violation of the software system in the state space generated: 1) using the quantifiers over all paths express the constraint execution sequence, 2) using the quantifier over a path express the violation of the constraint execution sequence. For the simulation of the UML-based AOMs, the second approach is more suitable for finding the execution sequence that causes a problem in the system as the verification would mark the states after which the violation has occurred. A violation of the constraint can be expressed using the negation. For example, if the constraint requires that after method a() eventually the method b() should execute, a violation of this constraint is an execution sequence where after method a() the method b() does not execute; this is expressed in CTL as EF (a()∧!(EF (b()))). Similarly, if the constraint states that after method a() method b() never executes, a violation of this constraint is an execution sequence where after a() eventually the method b() executes, which is expressed in CTL as EF (a()∧(EF (b()))). In Section 4.1, the execution constraint of the scenarios on the state pattern is described. One such example of the constraint on the states is that the car crash scenario should go to the scenario accept state, by executing the method ScenarioAccepted.executeStateAction() when it receives a start event fireStart. The violation of this constraint is the execution sequence where the method CarCrashScenario. fireStart() executes and, before it returns, the method ScenarioAccepted.executeStateAction() does not execute. Using the informative transformation rules presented in Section 4.5, this execution sequence can be expressed as a CTL formula as follows: EF (executeM ethod(”adviceF ireStart”, ”CarCrashScenario”) ∧ (EF (conditionalExecutes(”scenarioT ype = P residentialEmergencyScenario”) ∧ !(EF (executeM ethod(”executeStateAction”, ”ScenarioAccepted”) ∧ (EF (returnf rame(”adviceF ireStart”, ”CarCrashScenarioScenario”))))) ∧ (EF (returnf rame(”adviceF ireStart”, ”CarCrashScenarioScenario”))))))

352

5

S. Ciraci et al.

Application of the Approach to the Case Study

In this section, we describe two evolutions of the CMS that introduce semantically interfering aspects. These new aspects depend on a functionality that was not used in the initial version of the CMS software. Thus, it is important to verify that the old aspects (that are interfering with the new ones) obey the invariants of this functionality. 5.1

Evolution of CMS

While adding a new scenario, it is important that the modified parts do not violate the invariants of the software system. In order to prevent resulting errors, whether the invariants are violated or not must be verified. Especially, great attention should be paid to verifying invariants of mission critical systems like a CMS because errors could have catastrophic effects. The CMS software can be deployed at different crisis domains. Not every type of crisis in a domain can be known when the software is deployed. Due to this, CMS software is designed to be extendable such that new crisis management scenarios and resource allocation strategies can easily be incorporated into the

: Serve

scenarioOutsideEvents

ScenarioEvent:=ScenarioEvent(eventType, scenarioData, evetData) fireStart:=fireStart(scenarioType1, scenarioData)

ScenarioEvent:=ScenarioEvent(eventType, scenarioData, evetData) fireStart:=fireRequest(scenarioType1, scenarioData)

ScenarioEvent:=ScenarioEvent(eventType, scenarioData, evetData) fireStart:=fireStart(scenarioType2, scenarioData)

ScenarioEvent:=ScenarioEvent(eventType, scenarioData, evetData) fireStart:=fireRequest(scenarioType2, scenarioData)

Fig. 17. The class Server receiving 4 events from the user

A Graph-Based Aspect Interference Detection Approach

353

system. However, before incorporating these into the system, the validity of the following two conditions should be ensured: 1) the new scenario and the new allocation strategy do not violate the invariants of the CMS software, 2) the old scenarios respect the invariants of the CMS so that they do not cause problems with the new scenario. For verifying the second condition, one has to consider all possible interactions between different crisis scenarios. Assume that initially the stakeholders wanted to deploy the CMS software to manage only car accidents. To fulfill this deployment, the pattern class CarCrashScenario was designed, implemented as an aspect with the same name and shipped with the CMS software to the stakeholders. As the stakeholders gained experience with car accidents, they noticed that some car accidents have a high priority and the crisis resources should be first allocated to these accidents. One such accident is the presidential accident, which always dispatches an ambulance to the crisis scene. Thus, if all the ambulances are allocated by other car crash scenarios, one of the crash scenarios should pre-empt the resources it has allocated. To manage presidential accidents, a new pattern class called PresidentialEmergencyScenario is added to the design of the CMS. The CMS already supports prioritization of the crisis scenarios and pre-emption of resources: by calling the operation ScenarioBroadcastEvent.firePreEmpt() a scenario may request other scenarios to release the resources. This feature is used by the newly added scenario. In an environment where pre-emption is required, the pattern classes of the scenarios are required to implement a “before invoke” operation for the operation firePreEmpt(). The “before invoke” operation realizes how the pre-emption is realized in the crisis scenario. The initial version of the CMS allocated the first available resource to a crisis (Figure 5). The efficiency can be improved if a resource that is closer to the crisis can be dispatched, even if the resource is already dispatched to another crisis. To address this requirement, the designers introduced a new pattern called LocationAllocationStrategy that implements the resource allocation according to the location of the resources (Figure 8. This pattern class makes use of the resource deallocate broadcast event operation ScenarioBroadcastEvent.fireRequestDeallocate() to notify a scenario about deallocation. The scenarios are required to implement a “before invoke” operation to listen to this broadcast event. This before invoke operation should re-request deallocated resources. As shown in Section 3, the newly added strategy and crisis scenario are modeled as new “themes” without modifying the UML diagrams of the initial version of the CMS. These newly added “themes”, however, semantically interfere with the car crash scenario because they depend on the old scenarios to handle requests correctly. In the remaining parts of this section, we will show how these interferences can be simulated and how possible system invariant violations can be captured.

354

5.2

S. Ciraci et al.

Simulation of the UML Models of the CMS

The sequence diagram in Figure 17 shows the class Server receiving 4 events from the users. Two of these events request a new crisis scenario to be initialized and the other two require the newly initialized scenarios to allocate the resources. To apply graph-based model checking, we used this sequence diagram, the class diagram of the CMS software (these two diagrams constitute the “theme” main), the UML diagrams of the “theme”, Monitoring, Car Crash Scenario, Presidential Emergency Scenario and the Location-based allocation strategy. The generated DCML model from these diagrams contains 715 graph elements (nodes and edges). In this DCML model, the pattern classes are mapped to the aspect types CarCrashScenario, PresidentialEmergencyScenario, Monitoring and LocationAllocationStrategy. The simulation of this model generated a state space consisting of 47015 states, 47681 transitions; the simulation took 2.38 minutes2 . Since every possible order of the aspects is a different branch, each invoke of the operations fireStart and fireResourceAllocate adds two branches to the GTS. In addition to this, the conditional paths also add two branches for each advice invocation. Furthermore, the GTS contains one node for each simulation step of the non-aspect-oriented semantics. 5.3

Verification of the Constraints of the CMS After Evolution

Using the state space generated by the simulation of the UML diagrams, we evaluate the following invariants of the presidential emergency scenario so that introduction of this aspect does not introduce errors: – The states of the presidential emergency scenario should match to the outside events it responds to: The subclasses of the class State reflect the states of a crisis scenario. Each subclass is responsible for creating a report about the scenario (e.g. the time the change in the state occurs), which are then logged for statistical purposes. Thus, it is very important for a scenario to instantiate the right subclass of the class State for the outside events. For example, the advice operation PresidentEmergency. adviceFireStart() for the outside event fireStart() should set its state to an instance of the class InitialReportReceived. The following CTL formula finds the states where this advice operation does not set its state to an instance of the class InitialReportReceived: EF (executeM ethod(”adviceF ireStart”, ”P residentialEmergencyScenario”) ∧ (EF (conditionalExecutes(”scenarioT ype = P residentialEmergencyScenario”) ∧ !(EF (executeM ethod(”executeStateAction”, ”ScenarioAccepted”) ∧ (EF (returnf rame(”adviceF ireStart”, ”P residentialEmergencyScenario”))))) ∧ (EF (returnf rame(”adviceF ireStart”, ”P residentialEmergencyScenario”))))))

2

The simulation was executed on a laptop with Core 2 Duo 2.4 GHz CPU 4GB Ram running Windows 7 Ultimate 64-bit and JDK 1.6 Update 6.

A Graph-Based Aspect Interference Detection Approach

355

This formula evaluates to true for states after which the operation PresidentialEmergencyScenario.adviceFireStart() eventually executes and, then, eventually this operation returns before the constructor of the class InitialReportReceived is called. Note that the state actions are only executed when the scenario type is executed within the optional frame and with the proposition conditionalExecutes(”scenarioType = PresidentialEmergencyScenario”) the formula searches the path where these actions are executed. The verification did not find any states that satisfy this formula, meaning that the advice operation adviceFireStart sets the scenario PresidentialEmergency to the correct state. We verified that all the advice operations of the class PresidentialEmergencyScenario set the correct states with the same formula by changing the advice operation name and its respective state class name. – The states of the presidential emergency scenario should be monitored. The aspect-type Monitoring intercepts the returns from the operation executeStateAction of all the sub-classes of the class State to log the state information. This behavior should not be harmed by introduction of the aspecttype PresidentialEmergencyScenario. If there is an execution sequence where the operation executeStateAction does not execute after the advice code of the aspect-type PresidentialEmergencyScenario, then the monitoring of this aspect does not behave as it should. With the following CTL formula, the execution sequence where the monitoring of the advice PresidentialEmergencyScenario. adviceFireStart() fails can be searched: EF (executeM ethod(”adviceF ireStart”, ”P residentialEmergencyScenario”) ∧ (EF (conditionalExecutes(”scenarioT ype = P residentialEmergencyScenario”) ∧ (EF (returnf rame(”executeStateAction”, ”InitialReportReceived”) ∧ !(EF (executeM ethod(”af terInvoke”, ”M onitorStatus”))) ∧ (EF (returnf rame(”adviceF ireStart”, ”P residentialEmergencyScenario”))))))))

This formula looks for an execution sequence where the aspect PresidentialEmergencyScenario changes its state to InitialReportReceived by calling the operation executeStateAction(). However, the aspect MonitorStatus does not execute. The verification did not find any states that satisfy this formula so the monitoring of adviceFireStart() works. By changing the operation adviceFireStart() and the class InitialReportReceived to the other advice operations and their respective states, we verified that the aspect PresidentialEmergencyScenario is monitored correctly. – The scenario presidential emergency should not release its resources when it receives the request for pre-emption. A scenario releases a resource by calling the operation ResourceManager.deallocateResource(). Thus, if the operation deallocatedResource() is called from the aspect-type PresidentialEmergencyScenario within the advice for the operation firePreEmpt(), then the invariant is violated. This execution sequence can be expressed with the following CTL formula:

356

S. Ciraci et al.

EF (executeM ethod(”adviceF ireP reEmpt”, ”P residentialEmergencyScenario”) ∧ (EF (executeM ethod(”deallocateResource”, ”ResourceM anager”) ∧ (EF (returnf rame(”adviceF ireP reEmpt”, ”P residentialEmergencyScenario”))))))

This formula looks for a path where before the advice code at the aspect PresidentialEmergencyScenario for the operation firePreEmpt() returns, the operation the deallocateResource() executes. Here, the labeled returnframe( ”adviceFirePreEmpt”, ”PresidentialEmergencyScenario”) designates the exit point of an operation. The verification did not find any states that satisfy this formula. So, we can conclude that the invariant is not violated. This invariant is not violated because in the “theme” presidential emergency scenario the designers specified a sequence diagram, which shows the “before invoke” for the operation firePreEmpt() only returns. – The resource allocation for the scenario presidential emergency should always complete. This invariant is violated if the advice for the method fireResourceAllocate() of the aspect-type PresidentialEmergencyScenario does not complete successfully. The transitions labeled returnframe (operation name, object-type) only occur when the operation successfully returns. Thus, with the following CTL formula, we can search an execution sequence where the advice starts executing but does not return: EF (executeM ethod(”allocationStart”, ”P residentialEmergencyScenario”) ∧ !(EF (returnf rame(”allocationStart”, ”P residentialEmergencyScenario”)))

Note that here allocationStart() is an operation called by the advice for the operation fireRequest() as shown in Figure 7. The verification was able to find states that satisfied this formula; thus, the invariant was violated. The advice can fail when the resource manager runs out of resources. When there is not any resource to allocate the operation allocateResource() returns null. The sequence diagram shown in Figure 7 does not specify any frame fragments that are executed when resource allocation fails (i.e. when null is returned). Thus, the execution of the advice did not complete successfully because it threw a null pointer exception. We can confirm this because after receiving the resources the advice calls ScenarioData to log the resources. With a null resource, the call to Resource.getType() fails. We used the following CTL formula to confirm that the call to the operation getType() fails: EF (executeM ethod(”allocationStart”, ”P residentialEmergencyScenario”) ∧ (EF (executeM ethod(”getT ype”, ”Resource”) ∧ !(EF (returnf rame(”getT ype”, ”Resource”))))))

– The scenario car crash should deallocate its resources if the resource is not already dispatched. In any of the paths, if the aspect-type CarCrashScenario does not execute after the operation firePreEmpt(), then this invariant is violated. We can express this path as follows:

A Graph-Based Aspect Interference Detection Approach

357

EF (executeM ethod(”f ireP reEmpt”, ”ScenarioInternalevent”) ∧ !(EF (executes(”CarCrashScenario”) ∧ (EF (returnf rame(”f ireP reEmpt”, ”ScenarioInternalevent”))))))

The verification found states that satisfy this formula, which means that pre-emption is not handled by the aspect-type CarCrashScenario. The UML diagrams for the “theme” CarCrashScenario do not specify a sequence diagram with a before or after invocation of the operation firePreEmpt() because pre-emption was not a requirement of the initial version of the crisis management system. As a result, there is no pointcut for this operation in the aspect-type CarCrashScenario. – The scenario car crash should deallocate its resources if it receives a request to deallocate. The location-based resource allocation strategy allocates resources according to their location. Thus, a previously allocated resource may be allocated to another crisis. The deallocation request is sent to the scenarios using the method ScenarioInternalEvent.fireDeallocate(). The scenarios should intercept this call and deallocate the resource by calling the method ResourceManager.deallocateResource(). The car crash scenario violates this constraint if it does not intercept the event fireDeallocate() or does not call the method deallocateResource() after intercepting the event, which can be expressed with the following CTL formula: EF (executeM ethod(”f ireDeallocate”, ”ScenarioInternalevent”) ∧ !(EF (executeM ethod(”f ireDeallocate”, ”CarCrashScenario”))) ∨ !(EF (executeM ethod(”f ireDeallocate”, ”CarCrashScenario”) ∧ (EF (executeM ethod(”deallocateResource”, ”ResourceM anager”))))) (EF (returnf rame(”f ireDeallocate”, ”ScenarioInternalevent”))))

The verification did not find any states that satisfy this formula, so the car crash scenario does not violate this constraint. The UML diagrams of the “theme” CarCrashScenario in Figure 5-(b) show that this scenario intercepts the call to the method fireDeallocate() and calls the method ResourceManager.deallocateResource(). – After receiving the deallocation resource the car crash scenario should request a new resource. If in any path the aspect-type CarCrashScenario does not make a call to the method ResourceManager.allocateResource() within the advice for the method fireDeallocate(), this invariant is violated. This violation can be expressed in CTL as: EF (executeM ethod(”f ireDeallocate”, ”ScenarioInternalevent”) ∧ (EF (executeM ethod(”f ireDeallocate”, ”CarCrashScenario”) ∧ (EF (executeM ethod(”allocateResource”, ”ResourceM anager”) ∧ (EF (returnf rame(”f ireDeallocate”, ”CarCrashScenario”) ∧ (EF (returnf rame(”f ireDeallocate”, ”ScenarioInternalevent”))))))))))

358

S. Ciraci et al.

The verification was able to find states that satisfy this formula, meaning that the invariant is violated. A closer look at the design of the car crash scenario shows that after receiving the deallocation request, it goes to the request failed state. The deallocation request in the initial version of the crisis management system was only used to cancel the scenario. However, with the introduction of the location-based resource allocation strategy, the constraint on the deallocation request is changed. The verification shows that with the evolution 3 constraints of the crisis management system are violated. The main reason for this failure is the incremental evolution: the “theme”s allowed the crisis management system to be evolved without modifying the existing UML models. However, the evolutions do require the UML models of the initial version of the crisis management system to be modified. A designer not evaluating the composed system may clearly miss these errors and introduce bugs to the implementation. 5.4

State Space Size and Methods for Pruning the State Space

The size of the state space depends on the number of actions in the sequence diagrams and the number of alternative execution sequences. Because the number of simulated actions may change in each alternative execution sequence, the exact size of the state space may not be calculated. Nonetheless, an upper bound on the state space size can be provided as: O(nk × cnk × s). Here, n is the number of aspects, k is the number of operations with shared join points, c is the maximum number of alternative/optional frames in the aspects and s is the number of actions in the sequence diagrams. On average, the state space size is much less than this upper bound because GROOVE detects isomorphic states in branches and merges them into one branch. Nevertheless, if there are many aspects on shared join points, the state space becomes too large. Therefore, we offer the use of the following methods for pruning the state space: – Simulating with reduced number of aspects: By simulating a subset of the aspects that are important for the verification, the size of the state space may be reduced greatly. However, the important aspects for an invariant are selected manually and, as a result, an aspect that causes interference may be left out. – Simulating with reduced number of operations with shared join points: The operations which are intercepted by more than one aspect are likely to cause interference problems. However, not all of these methods need to be simulated to verify an invariant. If one can select a subset of these operations important to the invariant, then one of the dominating factors in the size of the generated state space would be reduced. This method shares the same disadvantage of the previous method, as manual selection may miss an operation that violates the invariant. – Using aspect precedence: For certain invariants, the execution order of the aspects may not be important. Thus, the state space can be reduced

A Graph-Based Aspect Interference Detection Approach

359

by specifying the precedence of the aspects. For example, this is applicable for scenarios of the CMS because scenarios are mission critical and extra attention must be paid in verifying whether they obey the invariants. – Identifying mutually exclusive conditions: As discussed in Section 4.5, the transformation rule ConditionalAdapt just picks one of the conditional paths. When the conditions are mutually exclusive, semantically impossible executions may be generated due to this. The size of the state space may be reduced by specifying which conditional frame fragments are mutually exclusive in the sequence diagrams. Using the stereotype >, the designers can specify this. When the simulation reaches an exclusive conditional path, it picks one of the execution paths but adds edges describing the picked execution path to the value of the variable declaration the condition is taken upon. Thus, exclusive conditional statements that take conditions upon the same value are only allowed to pick the path that is different from the marked path. For example, the conditional paths of the aspects CarCrashScenario and PresidentialEmergencyScenario are exclusive in that, when one of them executes the actions within the frame fragment the other one immediately returns (skips the actions in the frame fragment). Without mutually exclusive conditional paths, the simulation may generate a branch where actions within the frame fragment are executed for both aspects (i.e. an execution sequence where the parameter scenarioType is equal to CarCrashScenario and PresidentialScenario). This execution sequence is omitted when the condition on the parameter scenarioType is specified as mutually exclusive. To test the effects of these state-space-reduction mechanisms on the design of the CMS, we simulated different configurations of the UML models without the reduction mechanisms and with the reduction mechanisms. Tables 1–3 report the state size, the simulation time and the total memory used by the JavaVM in each configuration of the UML models of CMS. Here, the first column shows the number of aspects in the simulated configurations; below the details of the configuration are provided: – 3 Aspects: in this configuration the UML models of the “theme”s Monitoring, Car Crash Scenario and Presidential Emergency Scenario are simulated – 4 Aspects: the “theme” Location Based Resource Allocation is added. – 5 Aspects: the “theme” Fire Scenario is added. This scenarios sequence diagrams are very similar to the diagrams of the “theme” Car Crash Scenario. When aspect precedence is used, the size of the state space reduces by a factor of 9 compared to the size of the state space without any reduction methods. Because with precedence, only one execution order for aspects is generated. In this case, the number of states is bounded above by O(cnk × s). For the configuration with 5 aspects when exclusive “ifs” are used with aspect precedence, in total, the state space contains 99 branches. This is because in the sequence diagram given in Figure 17, the subsequent invocations to the operations fireStart() and fireResourceAllocate() used the same value. After the first

360

S. Ciraci et al. Table 1. State space size without reduction mechanism # of Aspects # of States # of Transitions Simulation Memory used time in min. in Mb 3 14815 15303 1.1 50 4 111943 113643 6.23 67 5 798600 831499 20.13 134 Table 2. State space size with Precedence as reduction mechanism # of Aspects # of States # of Transitions Simulation Memory used time in min. in Mb 3 6993 7251 0.38 46 4 47015 47681 2.38 54 5 106167 108357 7.13 61

Table 3. State space size with Precedence and Exclusive “ifs” as reduction mechanism # of Aspects # of States # of Transitions Simulation Memory used time in min. in Mb 3 1633 1697 0.12 43 4 7489 7635 0.46 48 5 9991 10234 0,71 49

invocation of the operation fireStart(), 5 branches are generated with exclusive “ifs” (in 4 of these branches one of the aspects executed the actions within the frame fragment, and in the fifth none of the aspects has executed this code). The first invocation of the operation fireResourceAllocate() does not cause branches because the parameter eventType is the same as the parameter passed to the operation fireStart(). After this, the second invocation of the operation fireStart() causes another 5 branches. This time exclusive “ifs” caused branches because the variable eventType2 is passed and no path decision is made according to the value of this variable (Figure 17). Similar to the first invocation, the second invocation to the operation fireResourceAllocate() does not generate any branches because the variable eventType2 is passed to this operation. Thus, the number of states in the worst case for mutual exclusive “ifs” is bounded above by O(nk ). This worst case happens when all k operations are invoked with a distinct value. However, for practical cases, the number of states is much less because not every operation invocation uses a distinct value. For example, in the CMS, four operation invocations are simulated with two distinct values. This reduced the state space size to be bounded above by O(n2 × cnon−mutual × s) where cnon−mutual is the number of conditions that are not mutually exclusive. Note that the growth on the state space size on the configuration with 4 aspects is due to the design of the aspect LocationAllocationStrategy. This aspect intercepts all the calls to the methods ResourceManager.allocateResource() and ResourceManager.deallocateResource(). The advice code for the method

A Graph-Based Aspect Interference Detection Approach

361

allocateResource() has two optional frames as shown in Figure 8-(c); thus, each interception of this method adds 3 branches to the state space. In the simulation there are in total 3 calls to the method allocateResource() which adds 27 branches to the state space that were not in the simulation of the configuration with 3 aspects. However, the state space size does not grow by a factor 27 because some of these branches are isomorphic and are merged during simulation.

6

Related Work

In the following, we discuss the related work from 4 different perspectives: Representing UML models. In the literature, graph-based approaches are used to formally define the semantics of UML class and object diagrams [26], to detect inconsistencies in UML diagrams caused by evolution [31], to formalize refactorings [30], to recover design information [35] and to correctly evolve design patterns [41]. These approaches provide a graph-based model for object-oriented systems focusing on the static structure; in contrast, DCML is tailored more to model the dynamic structure of the software. In our previous studies [10], we used graph transformation rules to correctly evolve UML models by following the constraints of software structures like design patterns (e.g. we defined transformation rules to add a strategy using the strategy pattern). In contrast to DCML, the graph-based model used in this study is static, captures the class diagram and one sequence diagram. It also lacks the model elements that are used for execution semantics. Execution Semantics for UML models. Although the meta-model of UML is documented and the modeling language is widely known, the lack of formal semantics makes it hard to reason about the models. In the literature, formal semantics for different types of UML diagrams are proposed. Whittle [39] provides a formal semantics of use-case charts that enable the specification of use-case scenarios. Use cases capture the software system’s behavior from the stakeholders’ view, and use-case charts model them as three-level diagrams. The first level is an activity diagram where the nodes are the use cases; the second level is also an activity diagram where the nodes are scenarios of a use case in the previous level; and the third level is constituted by interaction diagrams of the scenarios of the second level. Because the usecase charts formally specify the scenarios, they can be simulated. Therefore, a hierarchical state machine synthesis algorithm is proposed [40] and the tool UCSIM that executes this algorithm and simulates the generated state machines has been developed [21]. Graph transformations have been used to specify formal execution semantics of UML state charts [27] [29]. For example, Kung et al. [27] generate a graph grammar that models the execution semantics for a given state chart. These semantics, however, work only for providing verification/visualization for a single state chart. Dynamic meta modeling is also proposed as a way to add operational semantics to the UML diagrams [15]. In this approach, the meta model of

362

S. Ciraci et al.

the UML class diagram is extended with a dynamic meta model that uses the collaboration diagram notations. The state-chart diagrams specify the behavior of the system; for example, in order to trigger a transition, a method has to be called which in turn can trigger another event in the state chart of the called method. Using graph transformations, the operational semantics such as state transitions or method call triggers are modeled. Using a state space generator such as GROOVE and these graph transformations [16], it is possible to simulate the behavior of the software system and generate the state space of the system. Then, the requirements of the system can be verified in the generated state space. The main difference between the approaches presented in this section and our semantics is that we provide semantics that are close to actual aspectoriented software execution. Moreover, the semantics we provide are generic and can be applied to any sequence diagram. Object-oriented verification. Programming languages generally have a welldefined syntax, but their execution semantics are often informally specified. To formalize the execution semantics of object-oriented programs, Kastenberg et al. model execution semantics of the TAAL language (a simplified version of Java) as graph transformations [22]. Here, the idea is that a program in the TAAL language can be compiled into a graph model and simulated using graph transformation rules. Using graph-based model checking, the properties of the execution can be verified. In our approach, we apply graph-based model checking to UML models by modeling the execution semantics of UML, in particular of sequence diagrams (which define valid/desired sequences of actions) in combination with class diagrams. The semantics defined by Kastenberg et al. are specific for TAAL and cannot suitably be adapted to represent UML-based models, without major effort. As compared to this, we have defined an (automated) mapping from the UML meta-model to DCML. In addition, their approach does not support aspectbased functionality (such as explicit mappings for pointcuts, join points, etc.). Visser et al. propose to apply model checking to main stream programming languages, such as Java [38]. They propose a system (Java Path Finder) to model-check programs expressed in Java Bytecode. Their approach is applied to programs at the implementation level; this is an explicit design choice. As compared to this, we want to detect interference at the UML design level, while also supporting the use of aspects at this level. Aspect-oriented verification. A few approaches exist that aim to prove the correctness (usually with regard to specific properties) of programs or models in the presence of aspects. For example, Katz et al. propose an approach that checks whether a given program, which may include crosscutting definitions (such as pointcut-advice constructs), conforms to one or more scenarios [24]. In this approach, the system and aspects must be specified as a set of scenarios in a formal language. The verification is carried out by detecting the join points of the aspectual scenarios and finding out if there are undesired interferences at these points. Our approach, on the other hand, does not

A Graph-Based Aspect Interference Detection Approach

363

require the user to specify anything about the program beyond UML models; interference is detected based on the operational semantics of these models. An approach related to the above facilitates the automated derivation of proof obligations from requirements models that are specified using an aspect-oriented requirements engineering approach [25]. For example, the approach generates temporal logic formulas that have to be satisfied (proven) in later design stages. This allows to check the consistency between early and later design stages. As compared to this, the approach presented in this paper verifies the consistency of several models at the same modeling level (i.e. at the concrete design stage). As such, the approaches could be used to complement each other. At the level of aspect-oriented requirements engineering, [7] proposes an approach that uses semantic annotations to make aspect composition specifications less fragile. The work is related to ours, as these specifications later drive the generation of models; it is however not aimed at (model-)checking the correctness of the resulting system with regard to the intended semantics of the composed system. Rather it supports the user to actually compose the intended elements in the first place (cf. the fragile pointcut problem [28]). In this paper, we did not focus on addressing problems related to fragile pointcuts; we do however discuss this issue (at the program level) in other work [34, 19]. The authors of [33, 32] aim at detecting the possible semantic interferences that can occur in models expressed using the Aspect-UML language. To this aim, the static language elements of Aspect-UML are mapped to the specification language Alloy. The operational semantics of Aspect-UML models, however, have to be expressed manually using the dynamic state-based specification language Alloy. There are at least three differences between our approach and the one proposed in [33]. Firstly, in our approach, we derive the formal representation of models based on the static and dynamic semantics of the UML, and on a graph-based generic pointcut model. As such, our approach is less AOM specific. Secondly, we derive the operational semantics of models from the UML models directly; the modeler does not need to define the dynamic behavior of models in the specific language of the verifier. Thirdly, Alloy is designed intentionally as a limited model checker that mainly adopts the small scope hypothesis; that is, the errors are searched only within a limited scope. The GROOVE model checker, however, incorporates various verification tools including a possibility for a full state space exploration. In [3], Aksit et al. introduce an approach for the detection of interference between aspects that is also based on graph transformations. There are two major differences with the work presented in this paper: first, the paper focuses on modeling the operational semantics of aspect-specific behavior (i.e., advice code) within the Composition Filters approach. Thus, the approach works at the program level and focuses on (only) the aspect-related part of the program. Second, the paper focuses on detecting interference at shared join points, i.e., it detects situations where the behavior of the program

364

S. Ciraci et al.

differs based on the order in which advices at shared join points are executed. As compared to this, the work presented in our paper does not focus on detecting interference at (only) shared join points, and takes the semantics of the entire (UML-based) model into account.

7

Discussions and Conclusions

In this article, we have analyzed the example CMS case, identified two crisis scenarios as aspects, defined a model using Theme/UML, and verified its correctness at the modeling level with respect to a possible semantic interference among the scenarios. We will now evaluate our approach from the following three perspectives: Expressivity: The expressiveness of the tool is determined by the base modeling language UML, and the adopted join point model as described in section 4.4. In the current version, our tool supports UML class and sequence diagrams. A large library of rules is defined for the static and operational semantics of UML. The join point model currently supports before and after pointcut specifications. Since our model is based on a general purpose graphverification system (GROOVE), further extensions and tailoring should be possible within the limits of the selected approach. Our system is also supported by UML-to-graph translators, pruning techniques and model checkers. The sophistication of the graph model and the operational semantics, the simulation and the complexity of the model-checking process are hidden from the user. The user supplies UML-based AOM models to the system, and has to use CTL formulas to specify the invariants. The user is warned if the state space becomes too large, so that the available pruning methods can be investigated. Our system was able to detect the UML-level semantic errors among the aspects of the CMS model. Of course, the capability of our approach is by definition limited to the expressiveness of the selected UML models and the join point model. Scalability: In the CMS, scenarios are represented as aspects. The space and time complexity of the detection algorithm depends on the simultaneously active aspects that interfere with each other. In most aspect-oriented applications, the number of potentially conflicting aspects is expected to be low. However, depending on its context of usage, the CMS system should be able to handle, say, 10-20 scenarios simultaneously. Within the context of the example case, without taking any measures, the tool is capable of handling approximately four scenarios. Since this is rather limited, we have decided to use the available pruning methods. We first applied a precedence order among the scenarios and investigated if such an ordering caused any artificial restriction. This did not cause any problem because the invariants that are used in the verification process as shown in section 4.3 are independent of the aspect execution order. As shown in Table 3, this pruning method has reduced the generated states more than a factor 9. To further reduce the

A Graph-Based Aspect Interference Detection Approach

365

state space, we have identified the critical operations which cause branching in the state space. As shown in Figure 16, such information is easily obtainable from the tool. We have then tagged the branches that should be mutually exclusive. As a result, the state space is reduced with a factor over 300; and the state space growth with the number of aspects n is bounded above by O(n2 ). Concluding, from this practical experience, we observe that our approach is applicable to verifying models without pruning up to a limited set of interfering aspects. Nevertheless, as in the case of the CMS, the pruning process may reduce the complexity of the verification dramatically. From the perspective of the tool, a model which consists of a high-level of interfering aspects and that cannot be pruned, is considered either ill-designed and therefore must be re-factored, or is beyond the capability of the tool. We assume this will be an exception in practice. Applicability to AOM tools: Our tool is only applicable to UML-based AOM models, which can be translated to our internal representation. First of all, this requires mapping UML-specific parts of the AOM to our metamodel. Secondly, the aspect and pointcut designators of the AOM must be mapped to our pointcut model as specified in Figure 12. Based on these evaluations, we can conclude that the tool proves its applicability to the CMS example case. We think that the tool is capable of handling a large category of aspect interference problems that can be experienced in the current UML-based AOM approaches. As discussed in the article, there may be certain complex cases to which the tool cannot scale. These, however, are considered as exceptional cases rather than routine.

References 1. Gace: Graph-based adaptation, configuration and evolution modeling, http://trese.cs.utwente.nl/willevolve/ 2. Ak¸sit, M., Wakita, K., Bosch, J., Bergmans, L., Yonezawa, A.: Abstracting object interactions using composition filters. In: Guerraoui, R., Nierstrasz, O., Riveill, M. (eds.) ECOOP-WS 1993. LNCS, vol. 791, pp. 152–184. Springer, Heidelberg (1994) 3. Aksit, M., Rensink, A., Staijen, T.: A Graph-Transformation-Based Simulation Approach for Analysing Aspect Interference on Shared Join Points. In: AOSD 2009: Proceedings of the 8th ACM International Conference on Aspect-Oriented Software Development, Charlottesville, Virginia, USA, pp. 39–50. ACM, New York (2009) 4. Altisen, K., Maraninchi, F., Stauch, D.: Aspect-oriented programming for reactive systems: Larissa, a proposal in the synchronous framework. Science of Computer Programming 63(3), 297–320 (2006) 5. Ara´ ujo, J., Whittle, J., Kim, D.-K.: Modeling and composing scenario-based requirements with aspects. In: Proc. 12th Int’l Requirements Engineering Conference, pp. 53–62. IEEE, Los Alamitos (September 2004) 6. Baniassad, E., Clarke, S.: Theme: An approach for aspect-oriented analysis and design. In: Proceedings of the 26th International Conference on Software Engineering, pp. 158–167. IEEE Computer Society, Washington (2004)

366

S. Ciraci et al.

7. Chitchyan, R., Rashid, A., Rayson, P., Waters, R.: Semantics-based composition for aspect-oriented requirements engineering. In: Proceedings of the 6th international conference on Aspect-oriented software development, pp. 36–48. ACM, New York (2007) 8. Chitchyan, R., Rashid, A., Sawyer, P., Garcia, A., Alarcon, M.P., Bakker, J., Tekinerdogan, B., Clarke, S., Jackson, A.: Survey of aspect-oriented analysis and design approaches. Technical Report AOSD-Europe-ULANC-9, AOSD-Europe (May 2005) 9. Ciraci, S.: Graph Based Verification of Software Evolution Requirements. PhD thesis, University of Twente (December 2009) 10. Ciraci, S., van den Broek, P., Aksit, M.: Framework for computer-aided evolution of object-oriented designs. In: COMPSAC, pp. 757–764 (2008) 11. Clarke, S., Walker, R.J.: Composition patterns: An approach to designing reusable aspects. In: Proc. 23rd Int’l Conf. Software Engineering (ICSE), May 2001, pp. 5–14 (2001) 12. Clarke, S., Walker, R.J.: Generic aspect-oriented design with Theme/UML. In: Filman, R.E., Elrad, T., Clarke, S., Ak¸sit, M. (eds.) Aspect-Oriented Software Development, pp. 425–458. Addison-Wesley, Boston (2005) 13. D¨ urr, P.E.A.: Resource-based Verification for Robust Composition of Aspects. PhD thesis, University of Twente, Enschede (June 2008) 14. Ehrig, H.: Introduction to the algebraic theory of graph grammars. In: Claus, V., Ehrig, H., Rozenberg, G. (eds.) Graph Grammars 1978. LNCS, vol. 73, pp. 1–69. Springer, Heidelberg (1979) 15. Engels, G., Heckel, R., Sauer, S.: Dynamic Meta Modeling: A Graphical Approach to Operational Semantics of Behavioral Diagrams in UML (1999) 16. Engels, G., Soltenborn, C., Wehrheim, H.: Analysis of UML Activities Using Dynamic Meta Modeling. In: Bonsangue, M.M., Johnsen, E.B. (eds.) FMOODS 2007. LNCS, vol. 4468, pp. 76–90. Springer, Heidelberg (2007) 17. France, R., Ray, I., Georg, G., Ghosh, S.: Aspect-oriented approach to early design modelling. IEE Proceedings Software 151(4), 173–185 (2004) 18. Habel, A., Heckel, R., Taentzer, G.: Graph grammars with negative application conditions. Fundam. Inf. 26(3-4), 287–313 (1996) 19. Havinga, W.K., Nagy, I., Bergmans, L.M.J., Ak¸sit, M.: A graph-based approach to modeling and detecting composition conflicts related to introductions. In: de Moor, O. (ed.) Proceedings of International Conference on Aspect Oriented Software Development, AOSD 2007, Vancouver, Canada, March 2007. ACM International Conference Proceedings Series, pp. 85–95. ACM Press, New York (2007) 20. Helm, R., Holland, I., Gangopadhyay, D.: Contracts: specifying behavioral compositions in object-oriented systems. ACM Sigplan Notices 25(10), 169–180 (1990) 21. Jayaraman, P.K., Whittle, J.: Ucsim: A tool for simulating use case scenarios. In: ICSE COMPANION 2007: Companion to the proceedings of the 29th International Conference on Software Engineering, Washington, DC, USA, 2007, pp. 43–44. IEEE Computer Society, Los Alamitos (2007) 22. Kastenberg, H., Kleppe, A.G., Rensink, A.: Defining OO Execution Semantics Using Graph Transformations. In: Gorrieri, R., Wehrheim, H. (eds.) FMOODS 2006. LNCS, vol. 4037, pp. 186–201. Springer, Heidelberg (2006) 23. Kastenberg, H., Rensink, A.: Model Checking Dynamic States in GROOVE. In: Valmari, A. (ed.) SPIN 2006. LNCS, vol. 3925, pp. 299–305. Springer, Heidelberg (2006) 24. Katz, E., Katz, S.: Verifying scenario-based aspect specifications. In: Fitzgerald, J.S., Hayes, I.J., Tarlecki, A. (eds.) FM 2005. LNCS, vol. 3582, p. 432. Springer, Heidelberg (2005)

A Graph-Based Aspect Interference Detection Approach

367

25. Katz, S., Rashid, A.: From aspectual requirements to proof obligations for aspectoriented systems. In: Proceedings 12th IEEE International Requirements Engineering Conference, pp. 48–57 (2004) 26. Kleppe, A., Rensink, A.: On a Graph-Based Semantics for UML Class and Object Diagrams. In: Proceedings of the 7th International Workshop on Graph Transformation and Visual Modeling Techniques. Electronic Communications of the EASST, vol. 10, p. 16 (2008) 27. Kong, J., Zhang, K., Dong, J., Xu, D.: Specifying behavioral semantics of UML diagrams through graph transformations. J. Syst. Softw. 82(2), 292–306 (2009) 28. Koppen, C., St¨ orzer, M.: PCDiff: Attacking the fragile pointcut problem. In: Gybels, K., Hanenberg, S., Herrmann, S., Wloka, J. (eds.) European Interactive Workshop on Aspects in Software (EIWAS) (September 2004) 29. Kuske, S.: A Formal Semantics of UML State Machines Based on Structured Graph Transformation. In: Gogolla, M., Kobryn, C. (eds.) UML 2001. LNCS, vol. 2185, pp. 241–256. Springer, Heidelberg (2001) 30. Mens, T., Taentzer, G., Runge, O.: Analysing refactoring dependencies using graph transformation. Software and Systems Modeling 6(3), 269–285 (2007) 31. Mens, T., van der Straeten, R., D’Hondt, M.: Detecting and Resolving Model Inconsistencies Using Transformation Dependency Analysis. In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 200–214. Springer, Heidelberg (2006) 32. Mostefaoui, F., Vachon, J.: Design-level Detection of Interactions in Aspect-UML models using Alloy. Journal of Object Technology 6, 137–165 (2007) 33. Mostefaoui, F., Vachon, J.: Verification of Aspect-UML models using Alloy. In: Proceedings of the 10th international workshop on Aspect-oriented modeling, pp. 41–48. ACM, New York (2007) 34. Nagy, I., Bergmans, L., Havinga, W., Aksit, M.: Utilizing Design Information in Aspect-Oriented Programming. In: Robert Hirschfeld, A.P., Kowalczyk, R., Weske, M. (eds.) Proceedings of International Conference NetObjectDays, NODe 2005, Erfurt, Germany, September 2005. Lecture Notes in Informatics, vol. P-69, Gesellschaft f¨ ur Informatik, GI (2005) 35. Rich, C., Wills, L.: Recognizing a program’s design: a graph-parsing approach. IEEE Software 7(1), 82–89 (1990) 36. Sampaio, A., Chitchyan, R., Rashid, A., Rayson, P.: EA-Miner: a tool for automating aspect-oriented requirements identification. In: Proceedings of the 20th IEEE/ACM international Conference on Automated software engineering, pp. 352– 355. ACM, New York (2005) 37. Schauerhuber, A., Schwinger, W., Kapsammer, E., Retschitzegger, W., Wimmer, M., Kappel, G.: A survey on aspect-oriented modeling approaches. Relatorio tecnico, Vienna University of Technology (2007) 38. Visser, W., Havelund, K., Brat, G., Park, S., Lerda, F.: Model checking programs. Automated Software Engineering 10(2), 203–232 (2003) 39. Whittle, J.: Precise specification of use case scenarios. In: Dwyer, M.B., Lopes, A. (eds.) FASE 2007. LNCS, vol. 4422, pp. 170–184. Springer, Heidelberg (2007) 40. Whittle, J., Jayaraman, P.K.: Generating hierarchical state machines from use case charts. In: RE 2006, Washington, DC, USA, 2006, pp. 16–25. IEEE Computer Society, Los Alamitos (2006) 41. Zhao, C., Kong, J., Dong, J., Zhang, K.: Pattern-based design evolution using graph transformation. J. Vis. Lang. Comput. 18(4), 378–398 (2007)

368

S. Ciraci et al.

Appendix – DCML Elements and Execution Semantics In this appendix, all elements of the DCML and the execution semantics for operation dispatch are discussed in detail. For convenience, we have copied the figures used in this discussion to the appendix which are already used throughout the paper. Figure 18 repeats the DCML meta model.

-returnVal

OperDecl

-name : string

-attributes

-final : bool -static : bool

-operations -referenceType

StaticCall -statement

-superType -body

Action

OperImpl

*

-possible_next 1 ConditionaFrame

return

-executes

-conditionalValue : bool CallAction

CreateAction

ListLookup -previousExecution

InstanceCall SuperCall

-instance

LoopFrame ThisCall

Value

ListType

Object -encapsulates -self

-next

PrimitiveType

ObjectType -final : bool -abstract : bool -interface : bool

-executingType

-calledSignature

-referenceVar

-signature

Type -name : string

-instance

-parameter Signature

instanceValue -Type

VarDecl -name : string

-elementLookup

-paramValue, assignedValue

OperFrame

Fig. 18. The DCML meta-model

Structural Part of DCML The structure part covers the elements of the meta-model for modeling the classes, the interfaces and the relations between these. This part is generated from the class diagram. Because classes and interfaces are types at runtime, they are represented with nodes labeled ObjectType (object-type nodes). If the object-type node is representing an interface, then the attribute interface is set to true. The equivalent of the generalization relation is the edge labeled supertype. Figure 19-(a) shows a portion of the class diagram from the CMS with three classes, namely State, ResourceAllocation and ScenarioData. Figure 19-(b) shows the DCML representation of this class diagram; here, the three object-type nodes represent the classes in the class diagram. For example, the object-type node with the attribute name ResourceAllocation (i.e. the name of object-type node) is the class with the same name represented in DCML. The class ResourceAllocate generalizes the class State in the class diagram. This is shown in DCML with the edge labeled SuperType connecting the object-type nodes representing these classes. The nodes labeled VarDecl represent the variable declarations (variable declaration node); the type of the variable is modeled by the edge labeled Type, connecting the variable declaration node to a type node. An object-type node connected to a variable declaration node with an edge labeled attributes represents that the variable is an attribute of the object type. For example, the class ScenarioData has the attribute currentState and the type of this attribute is the class State as shown in Figure 19. In the DCML equivalent of this class diagram

A Graph-Based Aspect Interference Detection Approach

369

State «abstract» +executeSateAction(in executingScenarioData : ScenarioData) : void

ResourceAllocate +ResourceAllocate(in res : ResourceAllocate) +executeStateAction(in executingScenarioData : ScenarioData) : void ScenarioData -currentState : State +addAllocatedResource(in res : Resource) : void

(a)

(b)

Fig. 19. a) An example UML class diagram. b) The DCML model of the class diagram shown in (a).

in Figure 19, this is also shown: the object-type node named ScenarioData and the variable declaration node named currentState are connected by the edge labeled attributes. DCML separates the operation signatures from the operation declarations. The operation declaration nodes (nodes labeled OperDecl) are used for representing the abstract operations and operations without implementations. The object-type node connected to an operation declaration node with an edge labeled operations represents the object-type which declares the operation. The implemented operations, on the other hand, are represented by nodes labeled both OperImpl and OperDecl (operation implementation nodes). In Figure 19(a), the class State has an abstract operation; thus, the object-type node State is connected to an operation declaration node in the DCML model of this class diagram (Figure 19-(b)). Each unique signature in the class diagram is represented by signature nodes (nodes labeled Signature). The parameters of a signature are represented by variable declaration nodes connected to the signature node with an edge labeled parameter and the return type of the signature is represented by connecting the signature node to a type node. In Figure 19-(a), there are two operations with the same signature named executeStateAction that take one parameter of type ScenarioData and do not return a value. In the DCML model of this class diagram, this signature is represented by the signature node named executeStateAction. Note that the operation declaration node of the object-type State and the operation implementation node of the object-type ResourceAllocate are both connected to this signature node by an edge labeled signature. This shows that in the object-type State an operation with a signature named executeStateAction is declared and in the sub-type ResourceAllocate this operation is implemented. In this manner, operation overriding is modeled by connecting the operation implementation node of a sub-type to a signature node to which an operation implementation node of the super-type is connected.

370

S. Ciraci et al.

s : Scenario::ScenarioData

currentState : States::ResourceAllocate

addAllocatedResource:=addAllocatedResource(res) executeSateAction:=executeSateAction(executingScenarioData)

Fig. 20. A sequence diagram showing the actions executed by the operation ScenarioData.addAllocatedResource()

Dynamic Part of DCML The dynamic part, which is generated from the sequence diagrams, covers the elements for modeling the objects, the values and the life lines operations. A life line in a sequence diagram shows the actions the object executes when it receives a call. In the DCML meta-model (Figure 18), the specializations of the abstract element Action represents the actions of sequence diagrams. For example, the nodes labeled CallAction represent call actions and the nodes labeled return represent return actions. An action node can be connected to another action node by an edge labeled next; in this way, the order between the actions of a life line is represented in DCML. The first action of a life line is connected to an operation implementation node by an edge labeled body in DCML to show that these actions are executed when this operation received a call. The sequence diagram presented in Figure 20 shows the life line of the operation addAllocatedResource(). The first action executed in this life line is a call action. This action is followed by a return action where the operation addAllocatedResource() returns. Figure 21 shows the DCML model generated from this sequence diagram (and the class diagram in Figure 19). In this figure, the emphasized node represents the call action belonging to the life line of the operation addAllocatedResource. Because in the sequence diagram this call action is the first action executed in the life line of the operation addAllocatedResource(), the emphasized node is connected to the operation implementation node representing the operation addAllocatedResource() by an edge labeled body. This call action node is connected to the signature node named executeStateAction by an edge labeled calledSignature to show that the call action is to the signature executeStateAction. Following the outgoing edge labeled next from the call action node, it can be seen that the call action is succeeded by a return action. In DCML, call actions have 5 specializations representing different kinds calls: the calls to instances (InstanceCall), create actions (CreateOper), super operation calls (SuperCall), self calls (ThisCall) and static operation calls (StaticCall). The call action to the operation ResourceAllocate.executeStateAction in the sequence diagram shown in Figure 20 is an instance call because this call is received by an instance labeled currentState of the class ResourceAllocate. Because this call action is an instance call, the emphasized node in Figure 21, which represents it, is also labeled InstanceCall.

A Graph-Based Aspect Interference Detection Approach

371

Fig. 21. A snapshot from the simulation of the sequence diagram shown in Figure 20

The classifier names are represented as variables which hold the objects in DCML because DCML only supports communication between objects through encapsulation. So, the classifier currentState in the sequence diagram of Figure 20 is represented as a variable declaration node with the same name in the DCML model of this sequence diagram as shown in Figure 21. The type of this variable is set the object type named State because the class ScenarioData has an attribute named currentState whose type is the class State as shown in Figure 19. If the class ScenarioData did not contain such an attribute, then the type of the variable currentState would be set to ResourceAllocate. Note that the emphasized call action node is connected to this variable declaration node by an edge labeled referenceVar to show that the call references the value of this variable. The values of the variables are represented by connecting the variable declaration nodes to value nodes (nodes labeled Value with edges labeled instanceValue). Following the edge labeled instanceValue from the variable declaration node named currentState in Figure 21, it can be seen that the variable is holding an object. This object is an instance of the class ResourceAllocate; this is represented by the edge labeled instanceValue connecting the object-type node named ResourceAllocate. The object node representing an instance of the class ScenarioData is connected to the object node representing an instance of the class ResourceAllocate by an edge labeled encapsulates. This means that in the scope of this instance of the class ScenarioData, the variable currentState holds an instance of the class ResourceAllocate. A DCML model can be generated from more than one sequence diagram and, thus, a variable can have more then one instance value. During simulation, the values of the variables at the executing frame are resolved by the encapsulated edges. In UML 2.0 sequence diagrams, conditional execution of the actions is represented by frames whose operators are alt or opt (alt stands for alternative and opt stands for optional). A frame can have one or more fragments which contain the actions. A fragment with a guard shows that the actions within the fragment are

372

S. Ciraci et al.

executed when the guard is true. In DCML, these frames are represented with nodes labeled ConditionalFrames (conditional frame node). The first action of each fragment is connected to the conditional frame node with an edge labeled possible next. For example, an optional frame would be modeled in DCML, with a conditional frame node that is connected two action nodes: the edge labeled possible next connects the conditional frame node to the first action within the frame and the edge labeled next connects it to the first action node that comes after the frame. The frame of an executing operation is represented by nodes labeled OperFrame in DCML. These nodes are used to identify, during simulation, the object that is currently executing, the scope of the executing object, the type that contains the called operation and the statement that is being executed. The self of an operation frame is represented in DCML by connecting the operation frame node to an object node by an edge labeled self. In figure 21, for example, the self of the operation frame is an instance of the class ScenarioData. The action that is currently executing is represented by the edge labeled executes; for the DCML model in Figure 21 the currently executing action is an instance call. When UML diagrams are converted to DCML models, the conversion algorithm automatically adds the operation frame node which marks the first action of the sequence diagram as the action that is being executed. Thus, the simulation starts executing from that action. Execution Semantics of Operation Dispatch The execution semantics for operation dispatch consists of finding the latest implementation of the operation in the inheritance hierarchy and passing the arguments that are executed in the following manner: 1) calculating the type of the object the reference variable is holding; that is, the reference type of the call 2) starting from the reference type traversing the inheritance hierarchy upwards until an object-type that declares the operation is found 3) passing the arguments 4) checking that the latest declaration implements the operation. Figure 22 presents the 4 transformation rules that realize steps 1, 2 and 4 of the operation dispatch. For brevity, step 3 is not detailed further. Below we describe how these steps are realized by the four transformation rules of the figure: 1. The rule in Figure 22-(a) is used for finding the reference type of the call. This is done by finding the object-type whose instance the reference variable of the call action is holding. In this figure, the reference variable is node n3 (i.e. the variable declaration node that is connected to the call node with an edge labeled referenceVar) and the object it is holding is node n9. When applied, this rule adds two nodes and edges. From these, the edge labeled receivingTypeStart marks the object-type from which the traversal in the inheritance hierarchy starts. The edge labeled receivingTypeIter marks the object-type that is traversed.

A Graph-Based Aspect Interference Detection Approach

(a)

(c)

(b)

(d)

373

Fig. 22. Graph transformation rules for finding the newest implementation of the called operation: (a) Calculates the target reference type and marks it (b) finds the latest declaration of the operation (c) moves the mark up one level in the inheritance hierarchy, (d) checks whether the latest declaration implements the operation

2.1 The rule in Figure 22-(b) marks the latest declaration of the operation. This declaration is the object-type node with an operation declaration node that has the same signature as the signature called by the action. In the depicted transformation rule, the traversed object-type node is node n5 and the called signature is node n1. The rule matches when the traversed type has an operation declaration node (n3) that is connected to the same signature node as the called signature. The rule marks the declaration by adding an edge labeled calledDeclaration between the call node (n0) and the operation declaration node. 2.2 If the traversed object-type (i.e. the object-type where the edge labeled receivingTypeIter is pointing to) does not have the operation declaration then its super-type should be traversed. The transformation rule in Figure 22-(c) deletes the edge labeled receivingTypeIter and adds another edge with the same label pointing to the super-type of the traversed object-type. This rule has a lower priority then the rule presented in the previous step, therefore, they do not match at the same time. 4. After finding the operation declaration and preparing the arguments, the operation can be dispatched. However, before dispatching, we must be sure that the operation is implemented. The transformation rule in Figure 22-(d)

374

S. Ciraci et al.

matches when the operation declaration node marked in step 2 is also an operation implementation node (i.e. that is also labeled OperImpl). When this rule matches, it marks the operation implementation to be ready for dispatch by adding the edge labeled receivingInstanceOperImpl.

Fig. 23. Graph transformation rule that dispatches the operation after the object-type that implements the operation is discovered by the rules presented in Figure 22

After the object type that implements the operation is discovered, the operation can be dispatched as presented by the graph transformation rule in Figure 23. Here, the dispatching is done by creating a new operation frame node (n0), that is connected to the dispatched operation implementation (the node labeled OperImpl) with an edge labeled executes. The self of the new frame is the object receiving the call; thus, the rule adds the edge labeled self between the newly added frame (n0) and the object the reference variable holds (n2). The frame from which the call is initiated from is connected to the new frame with an edge labeled previousFrame. With this edge, the frame that will be returned when the execution of the called operation finishes is marked.

Discovery of Stable Abstractions for Aspect-Oriented Composition in the Car Crash Management Domain Dimitri Van Landuyt, Eddy Truyen, and Wouter Joosen DistriNet, Katholieke Universiteit Leuven Celestijnenlaan 200A B-3001 Leuven, Belgium            

Abstract. In this paper, we illustrate our method for the discovery of stable domain abstractions for the purpose of designing robust and reusable pointcut interfaces in the car crash management system (CCMS). A pointcut interface represents an abstraction of the join points in the base application to which aspects are composed. Although many techniques and notations to model explicit pointcut interfaces exist, there is currently a lack of methodological guidance how to design pointcut interfaces which are (i) robust in light of software evolution and (ii) can be reused by multiple aspects. Based on use case engineering and domain modeling techniques, our method provides a systematic approach for discovering domain abstractions that are suitable for aspectual composition. Furthermore, it provides architectural guidelines to design pointcut interfaces that are based on these stable domain abstractions. The underlying principle of our method is that the composition between aspect and base modules will be more robust and more reusable when specified in terms of stable domain abstractions, instead of low-level implementation details. In this paper, we provide concrete evidence from the CCMS of how our method can be adopted to realize the above-mentioned goals. Specifically, we illustrate how ripple effects from the base application to the aspects are avoided, and how this contributes to pointcut interface stability. Second, we show how duplication is avoided in the specification of the pointcut interfaces, and how this leads to effective reuse of the pointcut interfaces by multiple aspects.

1 Introduction In this paper, we present the results of applying our method for the discovery of stable domain abstractions for the purpose of designing effectively reusable pointcut interfaces [1] in the car crash management system (CCMS) [2]. The concept of a pointcut interface was introduced by Gudmundson and Kiczales [3]. It has been refined as a part of the crosscutting programming interface (XPI) from the work of Griswold, et al. [4]. According to Gudmundson [3], a pointcut interface is an interface between the base and the aspects that are applied to it. This interface contains a number of pointcut definitions that represent abstraction points in the base. A pointcut interface is maintained together with the module that it refers to. To support this idea at the architectural level, Kulesza, et al. [5] introduce extension join points (EJPs) which establish a contract between the base modules and the aspectual modules. S. Katz et al. (Eds.): Transactions on AOSD VII, LNCS 6210, pp. 375–422, 2010. © Springer-Verlag Berlin Heidelberg 2010

376

D. Van Landuyt, E. Truyen, and W. Joosen

Although many techniques and notations exist to model pointcut interfaces [3,4,5], there is still a lack of methodological guidance how to design pointcut interfaces that are both reusable within an application domain and resilient to evolution. More specifically, it is a common practice to design pointcut interfaces in late development stages, e.g. at implementation time. As a consequence, the resulting pointcuts are often monolithic and implementation-specific, which leads to problems of limited reusability and stability. To prevent these issues, we argue in favor of a top-down approach that focuses on the aspects and their compositions earlier in the development life-cycle (analysis and architecture). Therefore, the main contribution of our method is situated in the dimension of approach/process and much less in the dimension of modeling notations and representations. Sommerville [6] defines stable domain abstractions as “fundamental concepts in the application domain that change slowly”. In a realistic development setting, the problem domain is often the only common ground between the different developers and therefore, such domain abstractions form an important means of communication between the different members of the development team. In Domain-Driven Design [7], the terminology and concepts defined in the domain model are used consistently throughout the software development life-cycle by all stakeholders involved in the software project. As a result, a ubiquitous vocabulary emerges that forms a stable and well-defined set of terms for communicating between the different stakeholders over the course of evolution. There is a large and heterogeneous body of related work that is based on the principle that leveraging domain abstractions in software leads to quality improvements, both in the generic software engineering context [6,8] and the specific context of aspectoriented composition [9,10,5]. For example, Kelly et al. [8] have conducted a quantitative study that investigates design stability in a scientific software system through three decades of software evolution. In its conclusions, this study attributes the perceived design stability in this system to the persistent use by all developers of a stable vocabulary that is based on domain abstractions and application domain knowledge. Discovery of stable domain abstractions for AO composition. Our method applies the same principle to the design of pointcut interfaces. The underlying principle of our method is that the composition between aspect and base modules will be more reusable and more resilient to evolution when specified in terms of domain abstractions, instead of low-level implementation details. More specifically, the following are the goals of our method: – Goal #1: the first goal of our method is to design pointcut interfaces that are minimally overlapping, i.e. there is no duplication in the corresponding pointcut expressions, or in other words there is effective reuse of pointcut (sub-)expressions. This leads to higher reuse of these pointcut interfaces. – Goal #2: second, to design robust pointcut interfaces that are not fragile to changes in the base application, the goal is to apply the well-known tenets of high cohesion and low coupling in the design of pointcut interfaces; i.e. aggregating related crosscutting dependencies in separate modules to ensure high cohesion, and defining abstract interfaces to ensure low coupling. The main premise of our method is that both goals can be achieved by building pointcut interfaces that are based on stable abstractions in the problem domain. The study

Discovery of Stable Abstractions for Aspect-Oriented Composition

377

conducted by Hoffman et al. [10] provides empirical evidence that supports this premise. More specifically, this study indicates that explicitly designing pointcut interfaces leads to higher reusability and robustness of aspectual compositions. Section 4.2 illustrates and discusses both goals in the specific context of the CCMS. Evidently, it is impossible to take into account all potential future changes in a certain problem domain. Due to the often-changing market demands and stakeholder requirements in any realistic software development project, it is very feasible that the problem domain evolves to the degree that this evolution triggers changes in what was previously perceived as a stable domain abstraction. In Domain-Driven Design, consistent use of the domain model as a persistent and ubiquitous vocabulary brings this to the forefront, and eventually, such problems are resolved by updating the domain model accordingly. This process is called continuous learning; however, it may take many iterations, eventually, the domain model is expected to converge to a stable domain vocabulary. Similarly, the discovery and exploitation of stable domain abstractions by our method should be considered a continuous learning activity which may span one or more development iterations, but nonetheless yields in a set of stable domain abstractions. This philosophy matches as well with the Twin Peaks model to software engineering [11]. Especially, the second goal of our method related to pointcut fragility should be considered in this context. The activity diagram in Figure 1 presents an overview of our method. As mentioned above, it is a top-down pointcut interface design method which entails (i) the systematic re-engineering of use case models to discover and document those domain abstractions that are suitable for aspectual composition, and (ii) the design of pointcut interfaces in architecture which are based on these domain abstractions. The method starts in the requirements engineering phase of the software development life-cycle with classical requirements elicitation (use case models) and domain modeling activities (domain models) (activity 1). Then, it employs systematic restructuring of the use case models: first, the identification and separation of crosscutting concerns (activity 2) and then, generalization of the intrinsic commonalities with respect to the aspectual requirements (activity 3). These activities introduce abstract extension points in the use case models which represent common join points that are shared by multiple aspect use cases. These are in turn enriched with contextual information by analyzing data flow requirements through each extension point. With this information, domain abstractions are defined and anchored in the domain model (activity 4). This results in an inventory of well-defined domain abstractions that are suitable for aspectual composition. As such, the main contribution of our method is situated in activities 3 and 4. More specifically, activity 3 helps the requirements engineer to identify essential commonalities in the base use cases w.r.t. the individual aspects. Activity 4 in turn exploits these commonalities by defining domain abstractions suitable for aspectual composition from them. The most important part of activity 4 involves documenting these abstractions as part of the domain analysis (e.g. by extending the domain model) (activity 4), so that they become part of the ubiquitous vocabulary and can be reused, for example when introducing new aspects. The activities related to architectural design (activities 5–7) focus specifically on introducing pointcut interfaces and aspectual compositions in architecture. Therefore,

378

D. Van Landuyt, E. Truyen, and W. Joosen



 







 
  
     

 
 

 
  
  

  
   
 

   



 
 
 
  

!"
  
 

   

#$ 


  %  
  

&'      

  





 
  

Fig. 1. UML activity diagram providing an overview of the method

our method should be considered an extension to existing state-of-the-art architecture design methods. In the CCMS, we have used Attribute-Driven Design [12], mostly because we are most experienced with it. The concrete realization of these activities depends highly on many factors such as the chosen architecture creation method, architectural description languages (ADLs), pointcut languages, target platform, etc. As we focus on illustrating pointcut interface design and aspectual composition in the specific scope of the selected methods, notations and techniques for designing the CCMS, the nature of the description of these activities differs from that of the earlier activities. Activity 5 of the method introduces the additional architectural constraint of abstraction compatibility which involves ensuring that the architecture is compatible with the domain abstractions. In this case study, imposing this architectural constraint mostly meant that in some cases additional information (the contextual information) is exposed through the boundaries of a component interface. Activity 6 consists of the actual design of the pointcut interfaces and their implementation in a state-of-the-art aspectoriented architecture description language. In the CCMS, we have used the Unified Modeling Language (UML) and AspectJ for this. Finally, activity 7 introduces the aspectual compositions that bind the base to the advice through the pointcut interface. For this purpose, we have adopted the AO-ADL [13] for modeling aspectual connectors, and AspectJ for specifying them in further detail. Please refer to [1] and [14] for further details of the method and its guiding principles. Additionally, we have published a technical report [15] that gives a detailed account of applying our method to the CCMS, and we refer to this throughout the paper.

Discovery of Stable Abstractions for Aspect-Oriented Composition

379

The remainder of this paper is structured as follows: Section 2 describes the selection and refinement activity of requirements from the CCMS for our method. Then, Section 3 presents the application of the seven activities of the method over a subset of the car crash management case study in detail. Section 4 provides an in-depth analysis and discussion of the results. Section 5 discusses related work. Finally, Section 6 concludes the paper.

2 Pre-processing the Inputs To ensure applicability of our method in the CCMS, we performed a pre-processing activity. This involved (i) selecting suitable requirements from the original requirement documentation and (ii) meeting four criteria related to incompleteness, ambiguity and implicitness to improve the quality of the inputs. 2.1 Selection of Suitable Requirements To serve its goal of being a common case study for a large variety of aspect-oriented modeling approaches, the provided documentation of the crisis management system [2] offers a wide range of requirement artifacts including domain models, use case models, activity diagrams and feature models. Also, it provides architecture and design artifacts such as deployment diagrams and class diagrams. As not all of these are appropriate inputs for our method, we started by selecting the suitable requirements. The selection criteria were: – Type of artifact: as discussed previously in Section 1, our method starts from domain and use case models, and thus, we omitted the other artifacts (feature models, deployment diagrams, etc). – Concreteness: we found that the provided requirements were most concrete in the description of the specific car crash management system and were more vague in the description of the generic software product-line for crisis management systems. Therefore, we selected only those requirements specific to car crash management, and we did not pursue the product-line view for crisis management systems any further. – Non-functional requirements: because it is based on use case engineering, our method is limited to functional concerns; i.e. concerns that can be expressed in use cases1 . More specifically, these are the concerns that manifest themselves in terms of interactions between actor and system. However, the provided requirements documentation [2] presents a number of non-functional requirements that, when made explicit, affect the system’s functionality as well; i.e. they can be expressed in the use cases. Because they represent a large part of the complexity of the case study, we did not omit these non-functional requirements, yet we chose to make them explicit in the use cases. Section 2.2.2 discusses and illustrates this. In total, we selected (i) the provided car crash management domain model (both diagrams), (ii) the full use case model and detailed use case descriptions of the car crash management system, and (iii) the following non-functional requirements: “Availability”, “Persistence”, (partially) “Mobility”, (partially) “Safety”, and (partially) “Accuracy”. For more details about this requirement selection step, please refer to [15]. 1

This limitation of our method is discussed further in Section 4.6.

380

D. Van Landuyt, E. Truyen, and W. Joosen

2.2 Refinement of the Requirements To ensure the applicability of our method, we evaluated the presented requirements in terms of four criteria. These criteria are related to the quality of the inputs, more specifically incompleteness, inconsistency, ambiguity, etc. This section describes each criterion, outlines the overall strategy for refining the requirements accordingly, and provides detailed examples from the CCMS. It was an ongoing concern during this activity not to modify or extend the original requirements, but only to refine them. Because of this, we generally favored omitting inconsistencies and ambiguities above providing our own interpretation wherever possible. Finally, full documentation of the delta with respect to the original requirements is documented in [15]. As we refer to these figures throughout the section, we first present the resulting use case diagram (Figure 2) and domain model (Figure 3). Note that Figure 3 only presents the domain concepts related to car crash management. This diagram presents a number of abstract concepts, such as that of   , and   . These abstract concepts are refined in eight complementary domain diagrams. For example, Figure 4 below presents the domain diagram related to the victim transportation mission, which is one concrete type of   . The remaining seven domain diagrams are related to (i) vehicles, (ii) media, (iii) CCMS personnel, (iv) external resource providers, (v) external information providers, (vi) the super-observer mission, and (vii) the firstaid mission. These can be found in [15]. 2.2.1 Criterion #1: Completeness of Domain Analysis We found that the provided domain model was largely incomplete; several important concepts in the problem domain (e.g. a    , or a    ) were not documented explicitly. However, these concepts were used throughout the textual description of the use cases or the non-functional requirements. As our method is based heavily on domain analysis to discover and represent suitable domain abstractions, this issue hinders its successful application. Refinement Strategy: To address this, we applied an additional domain analysis iteration, which involved going through the use cases and non-functional requirements and cross-checking whether the terminology and concepts used in their textual description are also defined in the domain model. If not, we completed the domain analysis with these concepts and their interrelationships by extending the domain model. Example: As pointed out above, the original domain model lacked the definition of, for example, the     and the     concepts. However, this terminology is central to, for example, the use case ‘Capture Witness Report’, which describes a    starting a     which is redirected to a 

, which in turn creates a     that describes the car crash. To address this incompleteness in the domain model, we introduced these concepts and their interrelationships explicitly, as shown in Figure 3. 2.2.2 Criterion #2: Concreteness of the Requirements The provided requirements w.r.t. the specific car crash management system suffered from a number of ambiguities, inconsistencies or perhaps deliberate gaps. Possibly as a

Discovery of Stable Abstractions for Aspect-Oriented Composition

381

Fig. 2. The use case diagram after this refinement step

result of pursuing a generic software product-line for crisis management systems, some requirements were described rather generically. Especially the non-functional requirements were defined condensely, mostly in the form of one generic sentence that outlines the overall meaning or goal of the requirement. However, a clear specification of the impact that these requirements have on the use cases was lacking. This issue hinders the application of our method for two reasons: 1. the core activities of our method involve identifying potential commonalities and semantic overlaps between the different use cases, which might be hindered by ambiguity and inconsistency, and 2. the method only acts upon requirements expressed in use case models, and therefore it would not take into account the above-mentioned non-functional requirements.

382

D. Van Landuyt, E. Truyen, and W. Joosen

Fig. 3. Domain diagram for ‘car crash management’

Fig. 4. Domain diagram for the ‘victim transportation mission’

Refinement Strategy: We addressed this in the following manner: 1. we have taken additional domain-analytic decisions to clear out the ambiguities, and 2. wherever possible, we made the selected non-functional or infrastructural requirements maximally explicit in the use cases. Examples: We provide a number of examples below, that illustrate both types of refinement: – The “Adaptability” requirements from the original requirement documentation state that the system should be able to manage a potentially large variety of   s2, and recommend alternative resources in case of shortage or unavailability of suitable resources. This is achieved by allowing multiple  2

Originally called   , but renamed for clarity.

Discovery of Stable Abstractions for Aspect-Oriented Composition

383

  to offer the same

. More concretely, a  conceptually represents the asset offered by a    which is required in order to accomplish a certain   . For example, Figure 4 shows that the main  required for a         is that of       . In the current version of the CCMS, this is done by means of a helicopter; the    is the    . To illustrate the resulting adaptability of this mechanism, it would be straightforward to introduce the   to provide the       resource, and, when the     is unavailable, dispatch an   to the crash site. – The “Real-time Update” requirement from the original requirement documentation states that the main   s are required to keep the system up-to-date in real-time. In order to be able to react to car crashes within a limited time frame, the CCMS must at all times keep track of each   ’s whereabouts. Therefore, the       of a    is made explicit in the domain model, and the use cases are updated to allow the resource providers to update their availability state, by means of the ‘indicate availability’ use case (cf. Figure 2). – The “Adaptability” requirements state that the “system shall recommend alternate strategies [..] when the crisis conditions change (e.g. weather conditions, [..])”. However, the original domain model did not define this concept of a . Therefore, we introduced this concept in the domain model, and defined it as follows: a  represents a set of specific   s which—once executed— effectively address the car crash crisis. At any point in time, the system considers a set of alternative strategies to address the car crash. The 

 is given the responsibility to select the  he considers most suitable in the given situation. For this, we introduced the use case ‘select strategy’ (cf. Figure 2). Furthermore, as Figure 2 shows, we introduced specific use case steps for triggering the re-evaluation process (by means of use case inclusion) whenever the system observes a change in the crisis conditions. – Also, because of above-mentioned “Adaptability” requirements, we introduced     into the domain models and use cases, as well as the    which is an !       that affects the system’s functionality by regularly sending weather updates for the car crash location, as described in the ‘update weather info’ use case shown in Figure 2. Apart from being a concrete realization of the “Adaptability” requirement, this also addresses the “Safety” and “Dependability” requirements from the original requirements documentation. 2.2.3 Criterion #3: Use Case Granularity The original use case model for the CCMS presented one main use case (‘resolve crisis’) which delegates several of its sub-tasks to other use cases by means of use case inclusion. This particular use case style has a negative impact on the cohesion and modularity of the use cases, as many unrelated use steps are needlessly grouped together. Furthermore, this situation in which there is basically one main use case hinders the successful application of our method, since it involves the generalization of multiple base use cases.

384

D. Van Landuyt, E. Truyen, and W. Joosen

Refinement Strategy: We addressed this issue by splitting up the main ‘resolve crisis’ use case in multiple finer-grained use cases, in such a way that use case steps that serve the same goal are grouped. As these steps conceptually belong together, this improves the modularity and cohesion of the use cases. Example: Concretely, the use case ‘resolve crisis’ originally presented the decision logic of both (i) how the system should react to an incoming witness call and (ii) how this car crash is addressed (e.g. by delegating certain tasks to resource providers, etc). We have split this decision logic up in two separate use cases: the steps related to answering the witness call are moved to the ‘capture witness report’ use case and the steps specific to the selection of a suitable strategy to address the crash are covered by the ‘select strategy’ use case. This is shown in Figure 2. 2.2.4 Criterion #4: Use Case Hierarchy The original use case model contained a use case hierarchy around the ‘execute mission’ use case. However, the presence of pre-existing use case hierarchies is not a direct impediment to the application of our method (it deliberately checks for existing generalizations); this particular abstract use case failed to capture actual commonalities in functionality (i.e. common use case steps) for its child use cases: the generalization hierarchy mostly served to denote a commonality in goal of its children, but not in function. Refinement Strategy: Therefore, we removed this particular generalization from the case study. Example: As mentioned above, we removed the existing generalization hierarchy from the use cases (around the ‘execute mission’ use case). This had no real impact, as the existing generic use case did not describe actual functionality (it did not contain use case steps).

3 Application of the Method This part of the paper illustrates the application of the seven activities of the method (shown earlier in Figure 1) in the CCMS (Sections 3.1 to 3.7). 3.1 Activity 1: Define Domain Model and Use Cases In general, the first activity of our method involves the definition of a domain model and specification of the use cases. For the CCMS, we selected the models from the case study that resulted after the pre-processing activity described above in Section 2. To illustrate our method in detail, we select a subset of Figure 2 which serves as a running example throughout this section. This subset is shown in Figure 5. The domain models presented earlier in Figures 3 and 4 are relevant for this subset. Use Case 1 presents the ‘select strategy’ use case3 . As shown in Figure 5, this use case is triggered (by means of use case inclusion) by the ‘execute victim transportation mission’, and ‘execute first-aid mission’ use cases. More specifically, whenever one of 3

We have simplified this use case for presentation reasons. The full use case can be found in [15].

Discovery of Stable Abstractions for Aspect-Oriented Composition

385

Fig. 5. Subset of the CCMS

these missions fails or leads to new information regarding the car crash, it might be necessary to revise the current car crash resolution strategy and prompt the 

 to select a different alternative. 3.2 Activity 2: Identify and Separate Crosscutting Concerns in Use Cases This activity consists of two sub-activities: (i) the identification of crosscutting concerns in use cases, and (ii) the separation of these crosscutting concerns in the use cases by employing the use case extension relationship. 3.2.1 Identification of Crosscutting Concerns The first sub-activity of activity 2 involves the identification of crosscutting concerns in the use cases. Many existing approaches cover the identification of early aspects [16], and to apply this activity of the method, it might suffice to apply one of these approaches. In this case study, the identification of crosscutting concerns involved searching for recurring patterns in the use case steps, or identifying use case steps that do not directly contribute to the main goal of the use case. For example, steps 2 and 2b of Use Case 1 are related to checking whether the 

 is authenticated and authorized before selecting a new . These steps re-occur in many of the use cases and are not directly related to the main goal of the use case. Therefore, this leads to the definition of the authentication check and authorization check concerns. Use Case 2 given below presents the ‘select strategy’ use case again, after annotating the use case steps that are affected by crosscutting concerns. Overall, this use case

386

D. Van Landuyt, E. Truyen, and W. Joosen

Use Case 1: The ‘select strategy’ use case. – Primary actor: Coordinator – Basic flow: User Action

5. Coordinator selects one Strategy.

System Response 1. The System searches for a Coordinator (based on expertise and availability). 2. The System checks whether the Coordinator is authenticated and/or authorized. 3. The System sets the Coordinator’s availability status to “Unavailable”. 4. The System presents the Coordinator with a number of alternative recommended Strategies based on the current information about the crisis and resources. 6. The System logs this event. 7. The System sets the Coordinator’s availability status to “Available”.

– Alternative flow: 2b. Authentication and/or authorization check of the Coordinator has failed: include ‘Authenticate and Authorize’.

is affected by four crosscutting concerns: authentication check, authorization check, resource provider availability and statistical logging. Use case steps specific to the authentication check concern are underlined, and the authorization check concern is indicated by italics. Use case steps specific to the statistical logging concern are given in both bold and italics. Finally, use case steps in bold are specific to the resource provider availability concern. In total, we identified six crosscutting concerns over the use cases of the subset. Below, we summarize these crosscutting concerns: 1. Authentication check. This concern involves checking whether or not the main actor of a use case is authenticated in the system (e.g. step 2 of Use Case 2). If this check is unsuccessful, the actor is required to authenticate by means of the ‘authenticate and authorize’ use case which requests his credentials (e.g. username and password). 2. Authorization check. Similar to authentication check, before allowing a certain action to be performed by an authenticated actor, the system must also authorize this actor (e.g. step 2 of Use Case 2). This includes checking the access rights associated to the actor, the action he is performing and the resources involved in that action. 3. Strategy revision. As discussed in Section 2, the system must constantly re-assess the current strategy to remain effective in a constantly changing environment. Whenever the CCMS receives new information about a car crash, it must assess alternative strategies. This involves many different factors, such as the safety risk involved with a strategy, the urgency of certain missions (e.g. transporting a victim to the hospital), and many more.

Discovery of Stable Abstractions for Aspect-Oriented Composition

387

Use Case 2: The ‘select strategy’ use case, after annotating the crosscutting concerns. – Primary actor: Coordinator – Basic flow: User Action

5. Coordinator selects one Strategy.

System Response 1. The System searches for a Coordinator (based on expertise and availability). 2. The System checks whether the Coordinator is authenticated and/or authorized. 3. The System sets the Coordinator’s availability status to “Unavailable”. 4. The System presents the Coordinator with a number of alternative recommended Strategies based on the current information about the crisis and resources. 6. The System logs this event. 7. The System sets the Coordinator’s availability status to “Available”.

– Alternative flow: 2b. Authentication and/or authorization check of the Coordinator has failed: include ‘Authenticate and Authorize’.

4. Real-time update. The system must at all time have a recent view on the car crash situation and keep a close eye on its evolution. Therefore, many of the actors are required to update car crash information regularly. More specifically, the evolution of the car crash must be communicated to the CCMS in real-time. This concern has a large impact on the effectiveness of the CCMS system; when acting upon outdated information, it becomes very unlikely that the system will respond to the current state of the car crash in a suitable manner. 5. Resource provider availability. In order to respond swiftly to time-critical crises such as car crashes, the system must keep close track of its resource providers. By doing so, it can assess the availability of resource providers in a limited time frame and with little communication overhead. To this end, the CCMS system requires these resource providers (and other actors) to actively keep their availability information up to date at all time. This availability mechanism has a significant benefit over requesting the availability state of the resource providers in real-time; i.e. when a car crash has occurred. Indeed, the decision time will be drastically shorter, especially when scaling the CCMS to a large number of resource providers. The functionality related to this concern is summarized as follows: when the resource provider starts a certain action, the system automatically sets his availability status to ‘Unavailable’ (e.g. step 3 of Use Case 2). When the action is finished, it is set back to ‘Available’ (e.g. step 7 of Use Case 2). 6. Statistical logging. To analyze the overall performance, efficiency and effectiveness of the CCMS, a minute-to-minute log must be kept to allow auditing and post-fact

388

D. Van Landuyt, E. Truyen, and W. Joosen

analysis of what went wrong in case of system failure. More specifically, a detailed log must be kept of all interactions between the actors and the system, as well as the strategy followed by the system and the progress of that strategy (e.g. step 6 of Use Case 2).

Concern authentication check authorization check real-time update strategy revision resource provider avail. statistical logging

Table 1. A boolean concern diffusion matrix that indicates for each use case by which of the crosscutting concerns it is affected

Use Case ‘authenticate and authorize’ ‘select strategy’ 1 1 1 ‘execute first-aid mission’ 1 1 1 1 1 ‘execute victim transportation mission’ 1 1 1 1 1

1 1 1 1

Table 1 presents the concern diffusion matrix [17] which shows the mapping of these concerns to the use cases of the subset. It indicates for each use case by which concerns it is affected. From this matrix, it is straightforward to spot both tangling and scattering of these concerns over the use cases. For example, the authentication check concern is scattered over three use cases of the subset —‘select strategy’, ‘execute firstaid mission’, and ‘execute victim transportation mission’— and is tangled in these use cases with other concerns, such as authorization check, resource provider availability, and statistical logging. In the remainder of this paper, we will group the authentication check and authorization check concerns, because they are highly similar. 3.2.2 Separation of Crosscutting Concerns The second sub-activity of activity 2 involves separating the crosscutting concerns in the use cases. For this, we adopt the approach of Jacobson [18], which employs the use case extension relationship to separate use case steps specific to a crosscutting concern in an extension use case. This is a use case that is specific to a crosscutting concern and extends a base use case at a specific extension point, which is a label or a pointer that points to a specific use case step. In this paper, the terms extension use case and aspect use case are used interchangeably4. For this activity, we have defined a systematic algorithmic procedure [14] that loops over the base use cases affected by a crosscutting concern. For each such use case, it searches for a pre-existing aspect use case that offers the use case steps specific to the crosscutting concern. If no such aspect use case is found, it creates an aspect use case 4

Note that these are not necessarily the same: the extension relationship can also be used for separating use case steps that are related to the base concern. However, in this paper, this situation does not occur.

Discovery of Stable Abstractions for Aspect-Oriented Composition

389

that offers these use case steps. The algorithm then introduces an extension point in the base use case. An important part of this activity involves naming these extension points suitably. This is done by consulting the domain model to come up with a name that characterizes the use case step it refers to. Finally, the algorithm removes the use case steps corresponding with the crosscutting concern, and introduces an extension relationship between the aspect use case and the base use case. Figure 6 illustrates the application of this algorithm for the authentication check and authorization check concerns over the use case subset. For simplicity, we do not depict the association between the actors and the use cases. As part of this figure, Figure 6a presents a graphical representation of the mapping between use cases and crosscutting concerns, presented earlier in Table 1 which is the starting point for the algorithm. The result of the first run of the algorithm is shown in Figure 6b. In this run, the algorithm separates the use case steps 2 and 2b of use case ‘select strategy’ which are specific to the authentication check and authorization check concerns. More specifically, these steps are moved into a newly introduced aspect use case, ‘check authentication and authorization’. Subsequently, an extension point is introduced that is named coordinator selection. This name is selected because the extension point points to step 1 of use case ‘select strategy’ that involves the selection of a suitable coordinator. Then, an extension relationship is introduced from the aspect use case to the base use case, through this extension point. Figure 6c presents the result after separating the steps of use case ‘execute first-aid mission’ which are specific to authentication check and authorization check. As these steps are very similar to—if not the same as—the steps separated in the second run, this time no additional aspect use case is created. Again, the algorithm introduces an extension point named first-aid mission briefing and an extension relationship. Finally, Figure 6d presents the result after separating the steps of use case ‘execute victim transportation mission’ which are specific to the authentication check and authorization check concerns. Similar to the previous run, the algorithm introduces an extension point named victim transportation mission briefing and a corresponding extension relationship to it. Use Case 3 given below presents the ‘select strategy’ use case again, after separating the crosscutting concerns that affect it: authentication check, authorization check, resource provider availability and statistical logging. Additionally, Use Case 4 presents the newly introduced aspect use case ‘set resource provider status available’. The remaining aspect use cases are analogous and can be found in [15]. Figure 7 presents the resulting use case diagram after separating all six crosscutting concerns. The main purpose of this figure is to illustrate the unavoidable trade-off between the modularity of the crosscutting concerns and maintainability of the use case models. Although the crosscutting concerns are presented modularly in Figure 7—they are not scattered or tangled—,it becomes clear that the crosscutting nature of these concerns has manifested itself in terms of a large number of use case extension relationships (high coupling between aspect and base use cases). This has a negative impact on the manageability, comprehensibility and scalability of these models. 3.3 Activity 3: Generalization of Crosscutting Extends Relationships To address the manageability drawbacks discussed above, this activity leads to the introduction of use case generalization hierarchies. More specifically, the goal is to

390

D. Van Landuyt, E. Truyen, and W. Joosen

(a) Starting point, after annotating (b) After separating authentication the crosscutting concerns in the use and authorization check from the cases. ‘select strategy’ use case.

(c) After separating authentication and authorization check from the ‘select strategy’ use case. aspect use case.

(d) After separating authentication check and authorization check from the ‘execute victim transportation mission’ use case.

Fig. 6. Illustration of the separation of the authentication and authorization check concerns

Discovery of Stable Abstractions for Aspect-Oriented Composition

391

Fig. 7. Use Case Diagram - after separation of crosscutting concerns

generalize the extension points wherever feasible. The main merit of this generalization activity is that it forces the requirements engineer to either consult or revisit the analysis of the problem domain (the domain models) and come up with abstractions rooted in the problem domain, suitable to compose the aspects. As introduced in [14], an algorithmic procedure is offered to the requirements engineer for this activity. This algorithm iterates over each aspect use case C, and then considers for each couple of base use cases (A, B) extended by that aspect use case whether or not there is an essential commonality with respect to that aspect use case. The main question that drives this search for commonalities is “what do use cases A and B have in common, so that they are both extended by the same aspect use case C?”. If there is such an essential commonality, it is exploited by introducing a use case generalization hierarchy. More importantly, both specific extension points are generalized and a suitable name for the resulting abstract extension point is selected. Coming up with a suitable name either involves consulting the existing domain model or performing additional domain analysis to capture the exact semantics of the commonality in the name of the extension point. In the latter case, activity 4 will augment the domain model with these new concepts. Finally,

392

D. Van Landuyt, E. Truyen, and W. Joosen

Use Case 3: The ‘select strategy’ use case after separation of the crosscutting concern. – Primary actor: Coordinator – Basic flow: User Action

System Response 1. Extension point: coordinator selection. The System searches for a Coordinator (based on expertise and availability). 2. The System presents the Coordinator with a number of alternative recommended Strategies based on the current information about the crisis and resources.

3. Extension point: strategy selection. Coordinator selects one Strategy.

Use Case 4: The newly introduced ‘set resource provider status available’ aspect use case. – Primary actor: System – Extends: ’select strategy’ after coordinator selection

’execute first-aid mission’ after first-aid mission briefing ’execute victim transportation mission’ after victim transportation mission briefing

– Basic flow: User Action

System Response 1. The System sets the availability status of the Resource Provider to “Available”.

the multiple concrete extension relationships are replaced by one extension relationship to the abstract extension point in the introduced abstract use case. To illustrate the algorithm for the resource provider availability concern, let’s consider the ‘set resource provider available’ aspect use case presented in Section 3.2. As shown in Figure 8a, this aspect use case extends the three base use cases ‘select strategy’, ‘execute first-aid mission’, and ‘execute victim transportation mission’, at their respective extension points strategy selection, first-aid mission executed, and victim transportation mission executed. The first couple of use cases under consideration by the algorithm is ‘execute first-aid mission’ and victim transportation mission executed5 . These use cases indeed share an essential commonality that explains why they are both extended by the same aspect use case: both use cases represent the execution of a   . Therefore, an abstract use 5

Note that the the order of use case couples considered by the generalization algorithm does not affect the results, although it may appear so from this high-level description. Please refer to [14] for more details.

Discovery of Stable Abstractions for Aspect-Oriented Composition

393

(a) Starting point, which is a subset of Figure 7.

(b) After generalizing base use cases ‘execute first-aid mission’ and ‘execute victim transportation mission’ into the abstract use case ‘execute mission’.

(c) After generalizing base use cases ‘execute mission’ and ‘select strategy’ into the abstract use case ‘perform car crash management action’. Fig. 8. Illustration of the generalization algorithm for the base use cases extended by the the set resource provider available aspect use case

394

D. Van Landuyt, E. Truyen, and W. Joosen

case ‘execute mission’ is introduced that exploits this commonality. More importantly, both specific extension points first-aid mission executed, and victim transportation mission executed are generalized into the abstract extension point mission executed, and both extension relationships are replaced by one extension relationship to the abstract ‘execute mission’ use case. The result is presented in Figure 8b. Then, the algorithm considers whether there is an essential commonality between the ‘select strategy’ use case and the abstract ‘execute mission’ use case with respect to the ‘set resource provider availability concern’. As both use cases semantically represent the execution of a car crash management action6 —a specific action contributing to the resolution of the car crash—there is indeed a commonality: both use cases share the same goal. Therefore, another generalization is applied, leading to the use case ‘perform car crash management action’ which generalizes mission executed and strategy selection extension points into the more generic action performed extension point. Figure 8c presents the result after applying the generalization algorithm for the resource provider availability concern. Note that we illustrated the algorithm for only one aspect use case related to resource provider availability. Similarly, the ‘set resource provider unavailable’ use case extends the ‘perform crisis management action’ use case, but at a different extension point: action initiation. Use Case 5: The abstract ‘perform crisis management action’ use case. – Primary actor: CMS Employee – Basic flow: User Action

System Response 1. Extension point: action initiation. (Abstract) The System initiates the crisis management action by providing the CMS Employee with all details.

2. Extension point: action performed. (Abstract) The CMS Employee performs the crisis management action successfully and reports this to the system. – Alternative flow: 2.b. Extension point: action failed. (Abstract) The CMS Employee attempts to perform the crisis management action but fails, and reports this to the system.

Figure 9 presents the result of applying the generalization algorithm for the six crosscutting concerns of the subset. As a result of this, the ‘select strategy’ use case is a specialization of the newly introduced abstract use case ‘perform crisis management action’. We present this abstract use case below, then the specific ‘select strategy’ use case and finally, the ‘set resource provider status available’ aspect use case that result from this activity. 6

For brevity, we abbreviate ‘car crash management action’ to ‘action’ in this case study.

Discovery of Stable Abstractions for Aspect-Oriented Composition

395

Use Case 6: The ‘select strategy’ use case after generalization. – Primary actor: Coordinator – Specializes: Perform Crisis Management Action – Basic flow: User Action System Response 1. (Implements parent, step 1): The System searches for a Coordinator (based on expertise and availability). The following two steps implement parent, step 2: 2. The System presents the Coordinator with a number of alternative recommended Strategies based on the current information about the crisis and resources. 3. Coordinator selects one Strategy. – Alternative flow: 1b. (Implements parent, steps 2.b) No suitable Coordinator is found. The use case fails.

Use Case 7: The ‘set resource provider status available’ aspect use case after generalization. – Primary actor: System – Extends: ’perform a crisis management action’ after action performed – Basic flow: User Action

System Response 1. The System sets the availability status of the Resource Provider to “Available”.

Use Case 5 presents the abstract ‘perform crisis management action’ use case, which offers three extension points: action initiation, action performed and action failed. It defines a common frame to which all child use cases must adhere: all abstract use case steps must be implemented, and the specified order and more importantly the semantics of the parent use case steps must be respected. The specific use case ‘select strategy’ (Use Case 6) is an example of this. By implementing, for example, the parent’s use case step 2 at its own step 2, it automatically inherits and thus exposes the extension point action performed at this step. As a result, any aspect use case that extends the abstract use case at this extension point (in this case ‘set resource provider status available’ shown in Use Case 7) will by inheritance also extend its child use cases. Comparing the amount of extension relationships in Figure 9 to that of Figure 7, we can show that this activity has reduced the aspect–base coupling from 19 to 7. Section 4.1 discusses the ramifications of this in further detail.

396

D. Van Landuyt, E. Truyen, and W. Joosen

Fig. 9. Use Case Diagram - after generalization

3.4 Activity 4: Define Discovered Domain Abstractions During this activity, the abstract extension points introduced in the previous activities lead to the definition of domain abstractions for aspect-oriented compositions. These domain abstractions are added to the domain model, meaning that this activity involves extending the domain model with these concepts, and introducing their interrelations to already-existing concepts. For this, the required contextual information by the aspects is made explicit. Contextual information is derived by analyzing the data flow requirements from base use cases to the aspect use case, through the extension point. It captures the information required by the aspect in order for it to function correctly. To illustrate, consider the action performed extension point of the ‘perform car crash management action’ abstract use case. This extension point is used by the ‘set resource provider status available’ and ‘log action’ aspect use cases. The former use case involves updating the status of the    that performs the action, and thus information about the specific CMS employee must be accessible to this aspect. The latter use case must create a log entry that describes the car crash management action that was performed, and therefore, the particular action itself must be part of the contextual information as well. The definition of the resulting action performed domain abstraction is presented below. The contextual information is underlined.

Discovery of Stable Abstractions for Aspect-Oriented Composition

Name action formed

397

Description per- This domain abstraction denotes the successful execution of a – car crash management action, by a – Resource Provider or a CMS Employee.

Below, we list the remaining domain abstractions for aspect-oriented composition (for the use case subset). The contextual information is underlined. Name update received

Description This domain abstraction denotes that – a source of Car Crash information (either an External Resource Provider or an External Information Provider) has presented the system with – an update (new information) regarding the car crash.

authentication success

This domain abstraction denotes successful authentication of – a CMS Employee.

authentication failed

This domain abstraction denotes authentication failure of – a CMS Employee.

authorization success

This domain abstraction denotes successful authorization of – a CMS Employee.

authorization failed

This domain abstraction denotes authorization failure of – a CMS Employee.

action initiation This domain abstraction denotes the initiation of a – car crash management action, by a – Resource Provider or a CMS Employee. action failed

This domain abstraction denotes the failure of a – car crash management action, by a – Resource Provider or a CMS Employee.

As a domain abstraction represents a key concept in the problem domain that captures its relationships to the other concepts, it makes sense to update the domain model by including the domain abstractions. Figure 10 shows how we extended the domain model with the abstractions related to car crash management actions. The classes in gray are introduced in the domain model during activity 4, and the associations from these classes to existing classes indicate the necessity of contextual information to

398

D. Van Landuyt, E. Truyen, and W. Joosen

Fig. 10. Extended domain diagram after making explicit the concepts related to the ‘car crash management action’. Elements in gray are newly introduced during activity 4

anchor the abstraction in the domain model. All domain model adaptations at this point in the method are documented in [15]. 3.5 Activity 5. Architectural Design Using Domain Abstractions In general, this activity either starts with a pre-existing initial architecture, or with the design of such an architecture from scratch. For this, any state-of-the-art software architecture methodology can be employed. The core activity in software architecture design is the introduction of a decomposition; i.e. dividing the system in software modules such as classes or software components. The end result is a software architecture that fulfills both the functional requirements (e.g. the use cases), as well as the nonfunctional requirements and software qualities (also those non-functional requirements not explicitly considered by our method in Section 2, cf. the discussion in Section 4.6). What our methods essentially adds is the architectural constraint of abstraction compatibility; the architect must ensure that the domain abstractions can in fact be implemented in the architecture. For the car crash management system, we have designed the initial architecture from scratch, applying the Attribute-Driven Design method [12]7 . More specifically, we have decomposed the CCMS architecture according to the component-based paradigm [19]. As the realization of these activities of the method depends on the choice of architecture creation method, we only illustrate one possible strategy to comply to the abstraction compatibility constraint, more specifically in a component-based setting. Figure 11 presents a simplified component-and-connector view of the resulting CCMS architecture, showing only the relevant elements for the selected use case subset 7

Mainly because we are most experienced with this particular architecture creation method.

Discovery of Stable Abstractions for Aspect-Oriented Composition

399

Fig. 11. Initial architecture for the Car Crash Management System (component–connector view)

(structured in the multi-tiered architectural pattern). Note that at this point, the components providing advice functionality (e.g the " component) are already designed as part of the architecture. However, they are not composed yet to the base components, as this takes place during activity 7. A detailed description of all software components, interface specifications and the rationale behind the architectural decisions can be found in [15]. In a component-based architecture such as that of the CCMS, complying to the abstraction compatibility constraint involves checking whether or not the necessary contextual information is accessible through the component interfaces. In the worst case, some component interfaces must be adapted so that they expose the necessary contextual information. We illustrate this for the action performed domain abstraction. As defined in Section 3.4, the necessary contextual information for this abstraction consists of both (i) the crisis management action itself, which can easily be obtained by employing reflection on the actual join point and (ii) the    that executes the action. Line 3 of Listing 1 shows that the first version of the    interface of the      component did not offer the means to find out the specific    caller of the  method; i.e. there was no parameter or explicit method to find out this information. Therefore, the    interface was changed under the influence of the constraint abstraction compatibility. More specifically, an explicit 

 parameter was added to the  method, as shown in Lines 7–8 of Listing 1.

400

D. Van Landuyt, E. Truyen, and W. Joosen

 

   #                 $   %#&&'

'

                      $   ( 

  %#&&'

1 2 3 4 5 6 7 8 9

Listing 1. The specification of the   interface, before and after ensuring the constraint of abstraction compatibility.

3.6 Activity 6. Specify Pointcut Interfaces Next, pointcut interfaces are defined in the architecture. For each domain abstraction, a pointcut interface is designed that represents the particular abstraction and exposes the related contextual information for aspectual composition. More specifically, the pointcut interface is named after the domain abstraction it represents, and the contextual information of the domain abstraction leads to the specification of the pointcut parameters. Figure 12 presents these pointcut interfaces in the component-and-connector view of the architecture. This figure shows for each component which pointcut interface(s) it implements. To represent a pointcut interface in the UML, we adopted the ‘lollipop’ notation for interfaces and we stereotype it with ‘p.i.’ (short for pointcut interface).

     !  #   

    $  % ) $*   &$

( %% ++ $(*% ,, $* -&   $  (*%% ++ $(*% ,, $* -&  . $/  0(*%% ++ $(*% '

1 2 3 4 5 6 7 8 9

Listing 2. The action performed pointcut interface in AspectJ

In this paper, we use AspectJ for detailed specification of the pointcut interfaces at the level of architecture. This does not imply that their actual implementation must be in AspectJ. The AspectJ specification of the action performed pointcut interface is presented in Listing 2. The name of this pointcut interface matches the name of the domain abstraction it represents, and the contextual information is made available to the aspects as follows: (i) the CMS employee that performs the action is exposed through the   pointcut parameter, and (ii) the car crash management action can be obtained by means of reflection on the specific join point. In line with the terminology

Discovery of Stable Abstractions for Aspect-Oriented Composition

401

Fig. 12. Architecture for the Car Crash Management System (component-connector view) after pointcut interface design

related to a classical interface, the signature of this named pointcut (line 2) is what constitutes the actual pointcut interface, while Lines 3–6 present the implementation of this interface. This pointcut interface matches – after the coordinator has selected a strategy (when the  method of the   interface is called), as specified in lines 3–4; – after a victim transformation mission was executed by a helicopter pilot (when the    method of the - interface is called), as specified in lines 5–6; or – after a first-aid mission was executed by a first-aid worker (when the

 .  method of the - interface is called), as specified in lines 5–6. The AspectJ ‘’ pointcut designator is used to expose the contextual information available at the specific join points through the parameters of the named pointcut. To illustrate the ‘select strategy’ use case from the running example, we zoom in on the 

 0  and the      components. A simplified version of the sequence diagram for the ‘select strategy’ use case is presented in Figure 13. The use case starts when a strategy revision is triggered (message 1). As a result, the      component calculates all strategies suitable to manage the car crash (message 2). If this results in multiple alternative strategies,

402

D. Van Landuyt, E. Truyen, and W. Joosen

Fig. 13. Sequence diagram for the ‘Select Strategy’ use case. The UML note notation is used to indicate the join points for the action initiation, action performed, and action failed pointcut interfaces, as well as the specific contextual information exposed through these.

the system finds an available coordinator (message 3) and requests him to select the most suitable strategy (messages 4 to 5). Optionally, if the selection process takes too long (e.g. the selected coordinator is non-responsive), an exception is raised (message 6). If only one strategy is possible, and it is different than the one being followed, the system selects this strategy automatically (message 7). Finally, the system adopts the new strategy (message 8). Message 9 is an exception, raised when the system is unable to find any suitable coordinator. Figure 13 illustrates the concrete join points for the three pointcut interfaces in the ‘select strategy’ use case: action initiation, action performed, and action failed. It also depicts the contextual information that is exposed through these pointcut interfaces. Note that this figure is not strictly required for our method; it only serves to illustrate the concrete join points exposed by this pointcut interface in a behavioral view.

Discovery of Stable Abstractions for Aspect-Oriented Composition

        



 

   

   

403




     



 

     

Fig. 14. The ‘set employee availability’ aspectual connector (AO-ADL notation)

3.7 Activity 7. Compose Aspects to Architecture The final activity of our method involves the specification of aspect-oriented compositions in the architecture. For this case study, we have adopted the AO-ADL modeling notation [13] to specify aspectual connectors, mainly because it matches well with the component-based nature of the architecture. In general, aspect-oriented compositions bind pointcuts to actual advice. The AO-ADL connector also specifies a pointcut, the composition pointcut. In our implementation strategy, this composition pointcut is specified in terms of one or more of the pointcut interfaces defined in the previous activity. Figure 14 presents the aspectual connector for the resource provider availability aspect. This connector composes two pointcut interfaces—action initiation and action performed—to the        in order to realize the functionality related to the resource provider availability aspect (which entails both the ‘set resource provide unavailable’ and ‘set resource provider available’ aspect use cases). Listing 3 presents a possible implementation for this connector in AspectJ. In this specific implementation, the connector is implemented as an AspectJ aspect called     . Lines 3 and 8 present the composition pointcuts, which are specified in terms of the earlier-defined pointcut interfaces, actionInitiation and actionPerformed. After actionInitation, the      component is called to set the availability status of the employee  (which is part of the

       #  $ % )   !  &      $% # 0- $%&     $(  %1 '  $ % )   !  &   $  %# 0- $%&     $(-   %1 ' ' Listing 3. The ‘SetEmployeeAvailability’ connector in AspectJ

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

404

D. Van Landuyt, E. Truyen, and W. Joosen

contextual information available through the parameterized pointcut) to “Unavailable” (lines 4–5). After actionPerformed, this status is changed back to “Available” (lines 9–10). Note that we employ AspectJ to illustrate aspectual composition, but it is not a mandatory choice as many other techniques exist to specify AO compositions. For example, in the context of model-driven AO architecture, aspectual compositions could be specified in terms of join point designation diagrams (JPDDs) [20].

4 Discussion The discussion part of the paper is structured as follows: First, Section 4.1 summarizes the main facts and figures about applying our method in the CCMS case study and makes a first analysis of how our method deals with the complexity that emerges from a large number of crosscutting dependencies. Then, we evaluate how well the two key goals of our method (as defined in Section 1) are achieved in the CCMS. More specifically, Section 4.2 discusses the results of applying the method in terms of the effective pointcut interface reuse, and Section 4.3 discusses pointcut interface stability. Finally, the remainder of the discussion part of this paper highlights several other topics related to the application of our method in the CCMS: – Section 4.4 evaluates whether or not the results of applying our method in CCMS are compatible w.r.t. the use case generalization hierarchy from the original requirements. – Section 4.5 discusses a current limitation of our method regarding the loss of composition order information, and how this can be addressed. – Section 4.6 discusses the types of crosscutting concerns for which we found our method to work. – Finally, Section 4.7 discusses the practical usability of our method. 4.1 Summary of Main Artifacts and Complexity Management Table 2 shows the main facts and figures about the main artifacts that have been produced during the application of the method. The pre-processing step and activity 1 have resulted in the definition of 10 different UML diagrams (nine class diagrams, each of which presents a different view on the problem domain and one use case diagram) and 11 textual use case descriptions. Subsequently during activity 2, nine crosscutting concerns have been identified and separated in the use cases. This has resulted into 9 aspect use cases which are connected together by means of 64 extends relationships at 36 extension points. In activity 3, a generalization of the use cases has been performed, leading to a reduction to 16 extends relationships at 18 extension points in 16 base use cases. Activity 4 has then led to the definition of 18 domain abstractions based on the 18 extension points already defined in activity 3. During architecture design, these 18 domain abstractions are then taken as important input, ultimately leading to the design of 18 pointcut interfaces which are used by 8 aspectual connectors. The specification of each aspectual connector consists of a single pointcut that itself is specified in terms of the pointcut interfaces.

Discovery of Stable Abstractions for Aspect-Oriented Composition

405

Table 2. Main facts and figures from applying method to CCMS case study Activity Activity 1 Activity 2 Activity 3 Activity 4

# base # aspect # extension # extends # domain use cases use cases points relations abstractions 11 n/a n/a n/a n/a 11 9 36 63 n/a 16 9 18 16 n/a 16 9 18 16 18

Activity 5 Activity 6 Activity 7

18 software components and 28 traditional interfaces 18 pointcut interfaces 8 aspectual connectors

# pointcut interfaces used for more than one aspect Total person hours spent on the case study

5

286.5

Five pointcut interfaces have been used in the specification of more than one aspect. The first author of this paper has applied the method to the case study over a period of 38 working days, spending in total approximately 286.5 person hours on the case study. Table 2 shows that activity 2 leads to a large number of crosscutting dependencies between base and aspect functionality (63 extends relationships at 36 extension points). This complexity can be managed more efficiently by applying the well-known tenets of high cohesion and low coupling: aggregating related crosscutting dependencies in separate modules to ensure high cohesion, and defining abstract interfaces to ensure low coupling. In the spirit of focusing early on the hard problems of [12], the goal of activity 3 is to apply these two tenets during use case engineering. Table 2 indeed shows that it is certainly not a bad idea to manage crosscutting dependencies in use cases as opposed to, for example, source code: the number of external crosscutting dependencies have been reduced drastically from 63 to only 16 extends relationships. Also, later software development stages benefit from this use case engineering effort as the number of pointcut signatures that directly refer to base methods are reduced from 36 to 18. All other pointcuts can be implemented by combining these 18 pointcut signatures. This contrasts with the worst-case scenario in which, without applying activities 3 and 4, 36 singular pointcuts refer directly to base methods. We illustrate this scenario in Section 4.2. Activity 3 relies heavily on use case generalization to achieve its goal. We consider that the use of this standard object-oriented technique has some fairly negative points and some very positive points. On the one hand, the disadvantage of this technique is an increase in the number of base use case hierarchies. Another disadvantage is that additional book-keeping effort is needed to maintain consistency between child and parent use cases: when evolving the parent use cases, such an inheritance hierarchy breaks easily. This problem is a variant of the fragile base class problem [21]. On the other hand, the increase of base use case hierarchies also corresponds with the notion that fragility issues between base and aspect use cases are shifted to inheritance

406

D. Van Landuyt, E. Truyen, and W. Joosen

relationships within base use cases. The big advantage that ensues from this shift of complexity is that the scope of base use cases fragility can be better contained than aspect fragility due to the more static relations between child and parent use cases. As will be illustrated in Section 4.3, this advantage also propagates to the architectural design of the aspect-oriented compositions. Our method thus applies an object-oriented technique to reduce an aspect-oriented composition problem. 4.2 Pointcut Interface Reuse A pointcut interface is effectively reused when it represents common    pointcut (sub-)expressions that can be used in the composition specification of more than one aspect in pointcut
 pi interface the CCMS. Figure 15 illustrates this existing type of reuse graphically. There is K new
 E potential for this type of reuse when gray reuse Y the join points exposed by the pointcut interface are of interest for mulFig. 15. Pointcut interface reuse tiple aspects, as well as the exposed contextual information. This type of reuse indicates how well Goal #1 (as defined in Section 1) is achieved: by reusing pointcut interfaces for multiple aspects, (partial) duplication is avoided in the specification of the corresponding aspect-oriented compositions. We evaluate pointcut interface reuse as follows: – First, we show how many of the pointcut interfaces from the CCMS are effectively reused in the composition of more than one aspect. – Then, we illustrate how duplication is avoided in the corresponding pointcut expressions by zooming in on two aspectual connectors from the CCMS, and comparing to how they would look like without applying our method. 4.2.1 Effective Pointcut Interface Reuse in the CCMS As already indicated in Table 2, we have observed pointcut interface reuse for 5 of the 18 pointcut interfaces that were introduced by the method. Table 3 presents these five pointcut interfaces, and lists the aspects that are composed to it. In the next paragraph, we show that for each of these occurrences of pointcut interface reuse, duplication in the corresponding pointcut expressions was avoided. 4.2.2 Illustration of Duplication Avoidance Below, we illustrate pointcut interface reuse for two specific connectors from the CCMS:     , which is the connector for the resource provider availability aspect, and -", which is the connector for the statistical logging aspect. First, we show how these connectors would be defined if we applied the method up to activity 2 and then jumped directly to activities 5 to 7, thus skipping the core activities of the method (activities 3 and 4). Then, we show the same connectors which result from applying the method with activities 3 and 4. Note that for presentation purposes,

Discovery of Stable Abstractions for Aspect-Oriented Composition

407

Table 3. The five pointcut interfaces to which more than one aspect is composed Pointcut Interface employee selection action failure update received action initiation action performed

Aspects composed to it statistical logging, resource provider availability statistical logging, resource provider availability statistical logging, real-time update, strategy revision statistical logging, resource provider availability, authentication check, authorization check statistical logging, resource provider availability, authentication check, authorization check

we limit the specification of these connectors to the subset of the CCMS described in Section 3. For their full specification, please consult [15]. Without activities 3 and 4. Listings 4 and 5 present the AspectJ specification8 of both the connectors      and -". These are designed directly from Figure 7, where each extension point is mapped to a pointcut interface. We have underlined duplicated pointcut (sub-)expression(s) in these specifications. With activities 3 and 4. Listings 6 and 7 shows the same connectors, but this time we have applied activities 3 and 4. As illustrated in Section 3.6, these are designed directly from Figure 9, again by mapping each extension point to a pointcut interface. When we compare these connectors to their counterparts presented above, it is possible to

       #  $ % ) 

  $% ,,

    2 

$% ,,       2 

$% # 0- $%&     $(  %1 '  $ % )   $  % ,,

    !$% ,,       !$% # 0- $%&     $(-   %1 ' ' Listing 4. The ‘SetEmployeeAvailability’ connector without applying activities 3 and 4 8

For brevity, we do not refer to the classes in which the named pointcuts are defined.

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

408

D. Van Landuyt, E. Truyen, and W. Joosen

   -"#  $% )     $*% ,,     / $*% ,,  3  $*% ,,  3  / $*% ,, 

  $*% ,,   $*% ,,

    2 

$*% ,,

    !  $*% ,,

    !$*% ,,       2 

$*% ,,       !  $*% ,,       !$*% ,,     $*% # 0-"$%&4 "$ 5



%1 ' '

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

Listing 5. The ‘UpdateLog’ connector without applying activities 3 and 4

identify a substantial reduction in duplication; The common join points that are shared by these aspects are now presented as first-class pointcut entities (the actionInitiation and actionPerformed pointcut interfaces), and reused in the composition specifications of these aspects, which are shown below in Listing 6 and 7.

       #  $ % )       $% # 0- $%&     $(  %1 '  $ % )    $  % # 0- $%&     $(-   %1 ' ' Listing 6. The ‘SetEmployeeAvailability’ connector after applying activities 3 and 4

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

Discovery of Stable Abstractions for Aspect-Oriented Composition

   -"#   $% )     $*% ,,     / $*% ,,  3  $*% ,,  3  / $*% ,,   $*% ,,       $*% ,,    $*% ,,   / $*% ,,     $*% # 0-"$%&4 "$ 5



%1 ' '

409

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

Listing 7. The ‘UpdateLog’ connector after applying activities 3 and 4

4.2.3 Discussion The main advantage related to pointcut interface reuse is that needless repetition of the common pointcut (sub-)expressions is avoided. Indeed, similar to issues related to code clones, duplication in pointcut interfaces leads to maintainability problems of these interfaces: the developer may adapt one instance of the duplicated fragment, but forget to apply the same adaptations to its clones. By representing these common pointcut expressions as a single abstraction, we avoid such maintainability issues, and enable systematic reuse of pointcut interfaces for the specification of multiple aspect-oriented compositions. 4.3 Pointcut Interface Stability Pointcut interface stability is related to how susceptible the pointcut interfaces and aspectual compositions are to changes in the base application. Goal #2 of the method (as defined in Section 1) specifies that, ideally, the chosen abstraction from which the pointcut interface is derived is sufficiently stable to shield the aspects and their compositions from typical changes in the base. If this stability cannot be achieved, ripple effects may occur from the base to the aspects, and with them the issues related to pointcut fragility [22], etc. Therefore, we evaluate pointcut interface stability by introducing new requirements, and observing whether or not these changes cause ripple effects to the pointcut interfaces, the aspectual connectors or the aspect modules. For this, we select new requirements that affect already-existing crosscutting concerns. If these requirements can be supported by re-implementing an existing pointcut interface (which typically involves expanding the pointcuts to a larger join point set in the base application) without causing ripple effects to the aspects, that pointcut interface was indeed sufficiently stable to deal with the new requirements. This is illustrated in Figure 16.

410

D. Van Landuyt, E. Truyen, and W. Joosen

The evaluation methodology for pointcut interface stability is as Aspect follows: – First, we introduce new requirements that affect already-existing pointcut pi pi interface K crosscutting concerns. E existing – Then, we observe whether or Y new Base Base not these requirements affect the specification of the aspects. For this, we again show the correFig. 16. Pointcut interface stability sponding pointcut interfaces and aspectual connectors for the running example and compare how they are affected by the new requirements if we did not apply activities 3 and 4 of our method. 4.3.1 New Requirements: Tow Trucks as Resource Providers To illustrate pointcut interface stability, we selected additional requirements9 from the original requirements documentation [2]: the CCMS must “manage the use of tow trucks to remove obstacles and damaged vehicles from the crisis scene.”. In the domain model, these requirements lead to the introduction of the 4 0   as a new   ,      as its main , and a        as a new type of   . In the use case model, these requirements lead to the introduction of two new use cases: ‘request vehicle transportation’ and ‘execute vehicle transportation mission’. In the architecture, the tow truck company is represented as an external system that is contacted whenever the car crash resolution strategy requires vehicles to be removed from the crash site. This is presented in Figure 17. More specifically, the CCMS requests the company to perform a vehicle transportation mission, provides details about the car crash location, the vehicle(s) involved, and the urgency of the mission through the 6      interface. The     interface is used by the 4 0   component as a callback interface, to accept or decline the proposed mission. Also, the 4 0   component uses the  interface to keep the CCMS up-to-date about the progress of the mission.

Fig. 17. Subset of the architecture, after introducing the    

(new elements are depicted in gray) 9

As pointed out in Section 2, we originally did not select these requirements because they were not clearly defined in the presented use cases.

Discovery of Stable Abstractions for Aspect-Oriented Composition

411

4.3.2 Illustration of Pointcut Interface Stability We focus specifically on the pointcut interfaces and aspectual composition for the resource provider availability aspect. First, we show how these would be defined if we applied the method up to activity 2 and then jumped directly to activities 5 to 7, thus skipping the core activities of the method (activities 3 and 4). Then, we show the same artifacts which result from applying the method with activities 3 and 4. Without activities 3 and 4. Without an explicit generalization step, the resource provider availability aspect would be composed to a number of specific pointcut interfaces, as shown above in Listing 4. The new requirement leads to the introduction of two new pointcut interfaces: vehicleTransportationMissionBriefing and vehicleTransportationMissionExecuted, the second of which is presented below in Listing 8. Also, the aspectual connector      is adapted to include these, as shown in Listing 9.

     !  #   

       !$ 40  4% ) $* -&    $40 (*%% ++ $&*% '

1 2 3 4 5 6

Listing 8. The specific pointcut interface vehicle transportation mission executed in AspectJ

       #  $ % ) 

  $% ,,

    2 

$% ,,       2 

$% ,,       2 

$% # 0- $%&     $(  %1 '  $ % )   $  % ,,

    !$% ,,       !$% ,,       !$% # 0- $%&     $(-   %1 ' '

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

Listing 9. The ‘SetEmployeeAvailability’ connector without applying activities 3 and 4. The adaptations because of the new requirements are underlined

412

D. Van Landuyt, E. Truyen, and W. Joosen

With activities 3 and 4. After applying activities 3 and 4 of the method, the new requirements only affect the implementation of the actionInitiation and actionPerformed pointcut interfaces. More specifically, their corresponding join point sets are extended to include the relevant join points related to the new requirement. Below, Listing 10 shows this for the     pointcut interface, which was presented earlier in Listing 2. The adaptations to the specification of this pointcut interface are underlined.

     !  #   

    $  % ) $*   &$

( %% ++ $(*% ,, $* -&   $  (*%% ++ $(*% ,, $* -&  . $/  0(*%% ++ $&*% ,, $* -&    $40 (*%% ++ $&*% '

1 2 3 4 5 6 7 8 9 10 11

Listing 10. The action performed pointcut interface in AspectJ. The underlined pointcut subexpression indicates the adaptations due to the new requirements.

The composition for the resource provider availability aspect which was shown above in Listing 6 is not affected by the new requirements. 4.3.3 Discussion Because the selected requirements are highly analogous to the other mission types, the illustrated evolution scenario is rather trivial. However, it illustrates the problem: changes in the base application cause ripple effects to the aspects (in this case, the composition specifications) if no abstraction layer is introduced between them. Note that we also performed this stability evaluation for a more invasive set of requirements related to a crosscutting concern called criminal activity monitoring. Without activities 3 and 4, these modifications caused ripple effects affecting not only the composition specifications (as in the simple example above), but also to the advice itself. With activities 3 and 4, these changes were absorbed by the pointcut interfaces, and thus the impact of these modifications on the architecture as a whole is better contained after applying our method. Full details of this example can be found in [15]. The key advantage of this type of stability is related to the responsibility assignment in the development team: as the pointcut interface exposes interesting join points from the base, it conceptually belongs to the base. Therefore, it makes sense that it is maintained as part of the base application. If the base developer introduces changes in

Discovery of Stable Abstractions for Aspect-Oriented Composition

413

the base application, he is responsible for adapting the affected pointcut interfaces as well. As such, less base code changes will ripple through to the AO compositions of aspect modules. We believe adopting our method which will therefore better support situations of parallel development, or reuse of independently developed aspects from an aspect library. Furthermore, it has been shown that such ripple effects are typically very difficult to anticipate and propagate easily to unrelated modules [23]. Our method fits into a number of approaches that advocate the use of explicit pointcut interfaces to prevent these problems by introducing a certain degree of aspect-awareness or aspect-readiness at the level of architecture. Section 5 elaborates on these approaches further. Evidently, we cannot foresee future requirements and evolutions in any problem domain. Therefore, this notion of stability should only be considered in the context of continuous development, similar to the philosophy of Domain-Driven Design [7] (as discussed in Section 1). 4.4 Use Case Generalization As mentioned in Section 2, we have in this case study explicitly ignored the alreadyexisting generalization hierarchy in the use cases. The main reason for this was that the original use case inheritance relationship was not defined very clearly; i.e. it was used to express a commonality in goal, but not in functionality. However, this inheritance hierarchy is fully compatible with one of the use case hierarchies introduced by our method. More specifically, the method has re-introduced the ‘execute a mission’ use case as a generalization of the use cases describing the execution of three specific missions, ‘execute super-observer mission’, ‘execute firstaid mission’, and ‘execute victim transportation mission’. The observation that the original use case inheritance hierarchy is ‘re-discovered’ by our method validates that our method indeed succeeded in identifying a useful generalization for the car crash management system. However, the method has introduced multiple such use case generalization hierarchies, all of which represent useful abstractions for the car crash management domain. These hierarchies are depicted in Figure 18 which presents the use case diagram for the entire CCMS after activity 3. 4.5 Aspect Precedence As mentioned in Section 1 and illustrated in Section 4.2, our method guides the design of pointcut interfaces that are based on stable domain abstractions so that they become effectively reusable to specify the composition of multiple aspects. One consequence of pointcut interface reuse is that there is an increased number of join points shared by multiple aspects. As pointed out in literature [24,25], a large number of shared join points might lead to aspect interference or aspect interaction problems [26]. When specifying aspectual compositions, composition order or aspect precedence is of high importance: when two aspects are composed to the same pointcut interface (in other words, the same join point), which aspect should precede the other? This is especially true for regulative and invasive aspects, as defined in the aspect classification scheme proposed by Katz et al. [27]. An invasive aspect can change the state of the base

414

D. Van Landuyt, E. Truyen, and W. Joosen

Fig. 18. Use Case Diagram for the entire CCMS - after generalization

application, while a regulative aspect can only affect the control flow (e.g. allowing or disallowing an action). It is a current limitation of our method that this precedence information is lost after applying the concern separation activity (activity 2). The reason for this is that the UML does not provide a means for specifying the order of extension use cases that share an extension point. Luckily, the order in which the aspects should be applied can be derived directly from the original use case specifications: for example, for the ‘select strategy’ use case (Use Case 1 in Section 3.1), the authentication check and authorization check concerns clearly precede the resource provider availability concern, simply because the steps related to these two concerns precede the steps related to the latter in the textual use case specification. Therefore, this problem can easily be addressed by documenting the order of the extension use cases elsewhere; e.g. as meta-data to the domain abstractions defined in

Discovery of Stable Abstractions for Aspect-Oriented Composition

415

activity 4. Additionally, in the later phases of the development life-cycle (architecture, design, implementation, and deployment), a technique is required to enforce this composition order. In literature, multiple such techniques have been proposed [28,29]. 4.6 Type of Crosscutting Concerns As outlined in Section 1, our method employs use case engineering to guide both the identification of crosscutting concerns and the discovery of stable domain abstractions suitable to compose these aspects. Being centered around, use case engineering puts certain limitations on the types of crosscutting concerns that can be addressed successfully by the method: – Non-functional concerns: Because it is based on use case engineering, the method mostly deals with functional requirements. This explains why we have explicitly omitted those non-functional requirements from the original requirement specifications [2] that were difficult or impossible to express in the use cases (cf. Section 2). These concerns include Availability, Reliability, Real-time (partially), Mobility (partially), etc. Having said this, these concerns are in fact not entirely ignored in this case study as they were the key drivers behind the choice of architectural style and software structure of the CCMS base architecture in activity 5 (cf. Section 3.5). – Single-dimensional concern separation: It is considered good practice to focus on the main business requirements in the specification of use cases, and thus to ignore other facets of the system such as the user interface, persistence of data or algorithms below the system–actor boundary. In other words, use case specifications mostly describe the main business concern, car crash management in this case study. As a consequence, the crosscutting concerns identified in use cases are by nature closely related to the business logic of the system. Typically, these crosscutting concerns add a certain value, in the sense that they help realizing the main business concern. As an example, the witness identity verification concern is a functional concern that improves the efficiency of the system, as it filters out prank calls and avoids the system to waste resources on such witness reports. This focus on business-related concerns shows very well in the resulting architecture (see Figure 12): the pointcut interfaces, the aspectual compositions, and the components that offer advice functionality are mostly part of the business tier of the architecture. This orientation towards a single dimension of concern separation is fundamentally different from a number of approaches in literature [30,31] which focus on separating multiple orthogonal dimensions of concerns. Therefore, such approaches can be considered complementary to our method. Investigating how closely our approach is tied to the specific choice of use cases as requirement representation technique is part of future work. Possibly, a similar approach could be articulated for different requirement representation techniques such as problem frames, viewpoints or goals. 4.7 Usability of the Method In earlier work [14], we have presented our method as a set of algorithmic procedures. Their main purpose is to ease the adoption of the method across multiple case studies.

416

D. Van Landuyt, E. Truyen, and W. Joosen

More specifically, with improved tool support, the method could be executed semiautomatically. Indeed, as discussed in [14], only a few steps in these algorithmic procedures require human effort, and most of the repetitive steps can easily be automated. An additional advantage of our method in terms of usability is that it is based on use case engineering, which is a very well-known requirements engineering technique, both in the academic world and in industry. For example, one of the previous case studies in which we applied the method [32] is based on a research project in digital publishing with a number of industrial partners in the news publishing domain. In this project, use cases were the main means to discuss and communicate requirements. Another usability advantage of our method is that it does not advocate a tabula rasa in terms of software engineering methodology: it mostly represents an extension to existing software engineering techniques and practices, rather than a full replacement. More specifically, activities 1 and 5 of the method both entail applying state-of-the-art engineering practices: activity 1 involves requirements engineering and domain analysis, and activity 5 represents the application of a software architecture design methodology. Earlier, Table 2 presented the total amount of person hours spent on the case study (286.5 person hours). Figure 19 presents a further breakdown of this amount of man hours per activity10 . This figure indicates how much of this effort can be accounted to specifically applying the method (activities 2 to 4, and 6 to 7): in total, 64.8 man hours were spent on activities specific to the method, which is around 23% of the total amount of man hours. This relative amount of effort is consistent with the amount of effort that was needed for applying our method in previous case studies [1].

  



  

  



 





  

Fig. 19. Breakdown of the man hours spent on the case study per activity 10

These numbers were obtained by consulting and analyzing the versioning system logs kept during the application of our method in the CCMS case study. Further details about how these numbers were obtained and analyzed can be found in [15].

Discovery of Stable Abstractions for Aspect-Oriented Composition

417

One usability downside of the method, however, is the fact that it relies heavily on use case generalization hierarchies, which is not so common in practice. Use case generalization is not clearly defined in the UML specifications, and as a consequence, few UML tools support it correctly. Another usability disadvantage of our method is the fact that the quality of the input artifacts (use case and domain model) matters for its applicability (as discussed in Section 2). However, we argue that it is generally considered good practice to address ambiguity, vagueness, and conflicts in early development stages, regardless of the applied software engineering methodology.

5 Related Work We distinguish between related work in the following four categories. Early aspects. As our method is situated at the transition between requirements and architecture, it is related to various Early Aspects [16] approaches that map aspectual requirements to architecture. The most relevant approaches in this space include COMPASS [33], Goal-Driven Discovery of Aspects [34], Theme [35], Jacobson’s AOSD with Use Cases approach [18] and Aspect-Oriented Architecture Models (AAM) [36]. The common goal of all the above Early Aspects approaches is achieving improved aspect traceability across the software life cycle and supporting trade-off analysis [37,34] for conflicting requirements. Our method is complementary to these approaches as we focus on discovering stable architectural abstractions for aspect-oriented composition, starting from the requirements level. Ideally, our method is applied after a first iteration of these Early Aspects approaches. As our method is highly based on use case engineering, it is closely related to Jacobson’s AOSD with Use Cases approach [18]. Similar to what Jacobson has suggested, use case extension is a use case relationship that is well-suited for the purpose of separating base use cases and aspect use cases. However, Jacobson’s approach does not include the discovery of suitable abstractions for AO composition. Furthermore, the approach of Jacobson, et al. [18], involves defining a base architecture without taking crosscutting concerns into account. In our approach, the domain abstractions ensure the architectural design in activity 5 takes crosscutting concerns into account from its initial inception by means of the abstraction mismatch constraint (cf. Sect. 3.5). As this constraint potentially has a large impact on the architecture (it may affect the design of individual software components, their provided interfaces, the selected paradigm and component model and so on), it is necessary to address this constraint explicitly and document its consequences during architectural design. Domain Abstractions for AO composition. There is a significant body of related work on aspect-oriented composition techniques that exploit domain abstractions, both in the overall context of aspect-oriented software development (AOSD) and the specific scope of explicit pointcut interfaces. Tekinerdogan et al. [9] were among the first to identify the importance of domain analysis for deriving stable abstractions for aspects. In particular, their Synthesis-Based Software Architecture method [38] proposes domain analysis techniques for building canonical models that represent the stable abstractions in a particular domain.

418

D. Van Landuyt, E. Truyen, and W. Joosen

Furthermore, Hoffman et al. [10] have conducted an empirical study that compares systems with and without explicit pointcut interfaces. One of the key conclusions is that the use of an explicit interface to model crosscutting concerns facilitates the creation of reusable aspect libraries. Finally, Kulesza et al. [5] point out that domain analysis methods and experience in the development of applications in the same domain are good sources of inspiration for designing EJPs (which is a concrete technique to implement pointcut interfaces) and this is to support extensibility and variability of the resulting software in a software product line context. Some of these approaches [9] focus mostly on deriving solution domain abstractions for aspects. In opposition, our work takes the approach of deriving problem domain abstractions for aspects. Clearly both views are necessary and complementary to each other. Therefore, exploring the integration of these two distinct types of approaches is considered future work. Stability of AO compositions. Most of the recent work on explicit pointcut interfaces at the implementation level, a concept originally proposed by Gudmundson and Kiczales [3], has to do with the fragile pointcut problem [39]. This problem refers to the situation when pointcuts suffer from unintended join point matches or accidental join point misses after base code has evolved [22]. The XPI approach [4] deals with this problem by attaching design rules to pointcut interfaces. These design rules are contract-like invariants about the structure of the base code, which can be automatically maintained over the course of system evolution. Similarly to design rules in XPI, TranSAT [40] defines pointcut masks which are preconditions for weaving aspects to base modules in order to ensure correctness of the resulting designs. Open modules [41] deal with the problem by making the base code modules directly responsible for maintaining the implementation of the pointcut interfaces. The main contribution of these works thus lies in the fact that the correctness of pointcut interface implementations can be maintained in the face of changes in the base code. However, these works generally define very little guidance on how to identify the right abstractions so that a pointcut interface becomes useful for as many client aspects as possible. Our domain-driven method aims to provide such guidance, thus mostly making a complementary contribution at the client-side of the pointcut interface. The work on model-based pointcuts [42] tackles the fragile pointcut problem by declaring pointcuts in terms of a conceptual model of the base program. The definition of the conceptual model is based on the Intentional Views approach [43]. Intentional views describe concepts of interest to a programmer by grouping program entities that share some structural property. Again, we believe our method provides the missing guidance on identifying what are the relevant properties to expose in such an intentional view. Monteiro et al. [44] deal with this problem by cataloging the typical refactorings and common bad smells in aspect-oriented programs. This catalog helps the programmer to avoid this problem by documenting for each type of refactoring the (potential) effects on the dependent aspects. The empirical study by Greenwood et al. [45] observes multiple ripple effects in the aspect-oriented architecture of the HealthWatcher system that can be attributed to

Discovery of Stable Abstractions for Aspect-Oriented Composition

419

pointcut fragility. Their conclusion is that AO architecture techniques should take this problem into account when performing architectural trade-off. The study of Molesini et al. [46] confirms this. What these works have in common is that they advocate a certain degree of aspectawareness or aspect-readiness to prevent the fragile pointcut problem. Our method is similar in the sense that it involves anchoring the pointcuts to stable abstractions in the problem domain, thus avoiding implementation-level fragilities.

6 Conclusion In this paper, we presented a detailed account of applying our method for the discovery of stable domain abstractions for the purpose of designing effectively reusable pointcut interfaces [1] in the common case study for aspect-oriented design [2], a car crash management system. For this, we have applied the seven activities of the method—from requirements engineering to architecture design. We illustrated each of these activities in the car crash management system. By systematically re-engineering the use case models based on domain analysis techniques (activities 1 to 4), our method has discovered a total of eighteen domain abstractions for nine crosscutting concerns. After mapping these domain abstractions to pointcut interfaces in architecture (activities 5 to 7), this has led to the introduction of eight aspectual connectors in architecture to compose the aspect behavior to the base application through these pointcut interfaces. Based on these results, we discussed the results in terms of the two key goals of our method: pointcut interface reuse, and pointcut interface stability. We illustrate the main advantage of applying our method in terms of these two goals. Additionally, we provided a discussion in terms of (i) the compatibility of the domain abstractions discovered by our method with those provided by the authors of the case study, (ii) a current limitation of the method regarding the loss of information related to composition order or aspect precedence, (iii) the types of crosscutting concerns for which we found our method to work well, and (iv) the practical usability of the method. The car crash management system is definitely not a trivial case study. Therefore, we feel that this was a very useful validation: first, as it is a case study less familiar to us, we were less likely to be influenced or biased by already-existing artifacts or even domain analysis insights. Second, it allowed us to verify the results of case studies conducted earlier [1], and thus it increases our confidence in our method. Although we applied the method specifically within the car crash management domain, we believe that many of the introduced domain abstractions would indeed be valuable as well in the scope of a generic crisis management system or even a software product line, which adds confidence to the stability and reusability of the discovered domain abstractions.

Acknowledgements This research is supported by the Interuniversity Attraction Poles Programme Belgian State, Belgian Science Policy, by the Research Fund K.U.Leuven, and by the SBO project grant AspectLab-II from the Flemish Institute for the advancement of scientifictechnological research in industry (IWT).

420

D. Van Landuyt, E. Truyen, and W. Joosen

References 1. Van Landuyt, D., Op de beeck, S., Truyen, E., Joosen, W.: Domain-driven discovery of stable abstractions for pointcut interfaces. In: AOSD 2009: Proceedings of the 8th international conference on Aspect-oriented software development, pp. 1–10. ACM, New York (2009) 2. Kienzle, J., Guelfi, N., Mustafiz, S.: Crisis Management Systems: A Case Study for AspectOriented Modeling. Transactions on Aspect-Oriented Software Development 7, 1–22 (2010) 3. Gudmundson, S., Kiczales, G.: Addressing practical software development issues in aspectj with a pointcut interface. In: Advanced Separation of Concerns (2001) 4. Sullivan, K.J., Griswold, W.G., Song, Y., Cai, Y., Shonle, M., Tewari, N., Rajan, H.: Information hiding interfaces for aspect-oriented design. In: Wermelinger, M., Gall, H. (eds.) ESEC/SIGSOFT FSE, pp. 166–175. ACM, New York (2005) 5. Kulesza, U., Alves, E., Garcia, R., Lucena, C.J.P.D., Borba, P.: Improving extensibility of object-oriented frameworks with aspect-oriented programming. In: Morisio, M. (ed.) ICSR 2006. LNCS, vol. 4039, pp. 231–245. Springer, Heidelberg (2006) 6. Sommerville, I.: Software Engineering, vol. 8. Pearson, London (2008) 7. Evans, E.: Domain-Driven Design: Tackling Complexity in the Heart of Software. AddisonWesley, Reading (2004) 8. Kelly, D.: A study of design characteristics in evolving software using stability as a criterion. IEEE Trans. Software Eng. 32(5), 315–329 (2006) 9. Tekinerdogan, B., Aksit, M.: Deriving design aspects from conceptual models. In: ECOOP 1998: Workshop on Object-Oriented Technology, London, pp. 410–413. Springer, Heidelberg (1998) 10. Hoffman, K.J., Eugster, P.: Towards reusable components with aspects: an empirical study on modularity and obliviousness. In: Schäfer, W., Dwyer, M.B., Gruhn, V. (eds.) ICSE, pp. 91–100. ACM, New York (2008) 11. Nuseibeh, B.: Weaving together requirements and architectures. IEEE Computer 34(3), 115– 117 (2001) 12. Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice, 2nd edn. AddisonWesley, Reading (2003) 13. Fuentes, L., Gamez, N., Pinto, M., Valenzuela, J.A.: Using connectors to model crosscutting influences in software architecture. In: Oquendo, F. (ed.) ECSA 2007. LNCS, vol. 4758, pp. 292–295. Springer, Heidelberg (2007) 14. Van Landuyt, D., Truyen, E., Joosen, W.: Automating the discovery of stable abstractions for reusable aspects. In: Early Aspects at ICSE 2009: Proceedings of the international conference on software engineering, Vancouver, British Columbia, Canada, pp. 1–7. ACM, New York (2009) 15. Van Landuyt, D., Truyen, E., Joosen, W.: Discovery of stable domain abstractions for reusable pointcut interfaces: common case study for ao modeling. Technical report, Department of Computer Science, K.U.Leuven (2009), !""   "   "  ""#$%&   16. Baniassad, E.L.A., Clements, P.C., Araújo, J., Moreira, A., Rashid, A., Tekinerdogan, B.: Discovering early aspects. IEEE Software 23(1), 61–70 (2006) 17. van den Berg, K.G., Conejero, J.M., Hernández, J.: Analysis of crosscutting in early software development phases based on traceability. In: Rashid, A., Aksit, M. (eds.) Transactions on AOSD III. LNCS, vol. 4620, pp. 73–104. Springer, Heidelberg (2007) 18. Jacobson, I., Ng, P.W.: Aspect-Oriented Software Development with Use Cases, 1st edn. Addison-Wesley, Reading (December 2004) 19. Szyperski, C.: Component Software: Beyond Object-Oriented Programming. AddisonWesley Professional, Reading (December 1997)

Discovery of Stable Abstractions for Aspect-Oriented Composition

421

20. Stein, D., Hanenberg, S., Unland, R.: Expressing different conceptual models of join point selections in aspect-oriented design. In: AOSD 2006: Proceedings of the 5th international conference on Aspect-oriented software development, pp. 15–26. ACM, New York (2006) 21. Mikhajlov, L., Sekerinski, E.: A study of the fragile base class problem. In: Jul, E. (ed.) ECOOP 1998. LNCS, vol. 1445, pp. 355–382. Springer, Heidelberg (1998) 22. Tourwe, T., Brichau, J., Gybels, K.: On the existence of the aosd-evolution paradox. In: SPLAT: Software engineering Properties of Languages for Aspect Technologies (2003) 23. Rashid, A., Cottenier, T., Greenwood, P., Chitchyan, R., Meunier, R., Coelho, R., Sudholt, M., Joosen, W.: Aspect-oriented software development in practice: Tales from aosd-europe. Computer 43, 19–26 (2010) 24. Durr, P., Bergmans, L., Aksit, M.: Reasoning about semantic conflicts between aspects. In: EIWAS 2005: The 2nd European Interactive Workshop on Aspects in Software, pp. 10–18 (2006) 25. Douence, R., Fradet, P., Südholt, M.: A framework for the detection and resolution of aspect interactions. In: GPCE, pp. 173–188 (2002) 26. Sanen, F., Chitchyan, R., Bergmans, L., Fabry, J., Sudholt, M., Mehner, K.: Aspects, dependencies and interactions (2008) 27. Katz, S.: Aspect categories and classes of temporal properties. In: Rashid, A., Aksit, M. (eds.) Transactions on Aspect-Oriented Software Development I. LNCS, vol. 3880, pp. 106–134. Springer, Heidelberg (2006) 28. Greenwood, P., et al.: Interactions in ao middleware. In: Proc. Workshop on ADI, ECOOP (2007) 29. Zhang, J., Cottenier, T., Berg, A.V.D., Gray, J.: Aspect composition in the motorola aspectoriented modeling weaver. Journal of Object Technology 6(7) (2007) 30. Tarr, P., Ossher, H., Harrison, W., Sutton, S.M., Sutton Jr., S.M.: N degrees of separation: Multi-dimensional separation of concerns. In: ICSE, pp. 107–119 (1999) 31. Atkinson, C., Kühne, T.: Aspect-oriented development with stratified frameworks. IEEE Software 20(1), 81–89 (2003) 32. Van Landuyt, D., Op de beeck, S., Kemper, B., Truyen, E., Joosen, W.: Building a nextgeneration digital publishing platform using aosd, !""    " "    " 33. Chitchyan, R., Pinto, M., Rashid, A., Fuentes, L.: Compass: Composition-centric mapping of aspectual requirements to architecture. Transactions on Aspect-Oriented Software Development IV, 3–53 (2007) 34. Niu, N., Easterbrook, S.: Analysis of early aspects in requirements goal models: A conceptdriven approach. Transactions on Aspect-Oriented Software Development 3, 40–72 (2007) 35. Clarke, S., Baniassad, E.: Aspect-Oriented Analysis and Design: the Theme Approach. Addison-Wesley, Reading (2005) 36. France, R.B., Ray, I., Georg, G., Ghosh, S.: Aspect-oriented approach to early design modelling. IEEE Proceedings - Software 151(4), 173–186 (2004) 37. Rashid, A., Moreira, A., Araújo, J.: Modularisation and composition of aspectual requirements. In: AOSD 2003: Proceedings of the 2nd international conference on Aspect-oriented software development, pp. 11–20. ACM, New York (2003) 38. Tekinerdogan, B., Aksit, M.: Synthesis based software architecture design. In: Software Architectures and Component Technology, pp. 143–173. Kluwer Academic Publishers, Dordrecht (2002) 39. Koppen, C., Stoerzer, M.: Pcdiff:attacking the fragile pointcut problem. In: First European Interactive Workshop on Aspects in Software, EIWAS 2004 (2004) 40. Barais, O., Cariou, E., Duchien, L., Pessemier, N., Seinturier, L.: Transat: A framework for the specification of software architecture evolution. In: International Workshop on Coordination and Adaptation Techniques for Software Entities, Oslo, Norway (June 2004)

422

D. Van Landuyt, E. Truyen, and W. Joosen

41. Aldrich, J.: Open modules: Modular reasoning about advice. In: Black, A.P. (ed.) ECOOP 2005. LNCS, vol. 3586, pp. 144–168. Springer, Heidelberg (2005) 42. Kellens, A., Mens, K., Brichau, J., Gybels, K.: Managing the evolution of aspect-oriented software with model-based pointcuts. In: Thomas, D. (ed.) ECOOP 2006. LNCS, vol. 4067, pp. 501–525. Springer, Heidelberg (2006) 43. Mens, K., Kellens, A., Pluquet, F., Wuyts, R.: Co-evolving code and design with intentional views: A case study. Computer Languages, Systems & Structures 32(2-3), 140–156 (2006) 44. Monteiro, M.P., Fern, J.M.: Towards a catalogue of refactorings and code smells for aspectj. In: Rashid, A., Aksit, M. (eds.) Transactions on Aspect-Oriented Software Development I. LNCS, vol. 3880, pp. 214–258. Springer, Heidelberg (2006) 45. Greenwood, P., Bartolomei, T., Figueiredo, E., Dosea, M., Garcia, A., Cacho, N., Sant’Anna, C., Soares, S., Borba, P., Kulesza, U., Rashid, A.: On the impact of aspectual decompositions on design stability: An empirical study, pp. 176–200 (2007) 46. Molesini, A., Garcia, A.F., von Flach Garcia Chavez, C., Batista, T.V.: On the quantitative analysis of architecture stability in aspectual decompositions. In: Working IEEE/IFIP Conference on Software Architecture, pp. 29–38 (2008)

Author Index

Aksit, Mehmet 321 Al Abed, Wisam 272 Alf´erez, Mauricio 69 Am´ alio, Nuno 151 Amyot, Daniel 23 Ara´ ujo, Jo˜ ao 23, 69 Blay-Fornarino, Mireille 200 Bockisch, Christoph 321 Ciraci, Selim

321

Fleurey, Franck 272 France, Robert 200 Fuentes, Lidia 69 Glodt, Christian 151 Guelfi, Nicolas 1 Havinga, Wilke 321 Heidenreich, Florian 69 H¨ olzl, Matthias 234 J´ez´equel, Jean-Marc 272 Joosen, Wouter 375

Kelsen, Pierre 151 Kienzle, J¨ org 1, 272 Klein, Jacques 272 Knapp, Alexander 234 Kulesza, Uir´ a 69 Ma, Qin 151 McNeile, Ashley 115 Moreira, Ana 23, 69 Mosser, S´ebastien 200 Mussbacher, Gunter 23 Mustafiz, Sadaf 1 Rashid, Awais 69 Roubtsova, Ella 115 S´ anchez, Pablo 69 Santos, Jo˜ ao 69 Truyen, Eddy

375

van den Broek, Pim 321 Van Landuyt, Dimitri 375 Zhang, Gefei 234 Zschaler, Steffen 69